idnits 2.17.1 draft-eggert-hip-rvs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1376. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1392), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 17) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages 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.) ** There are 4 instances of too long lines in the document, the longest one being 3 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 593 has weird spacing: '...address with ...' -- 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 (July 12, 2004) is 7200 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) == Unused Reference: '9' is defined on line 1301, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1316, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 -- Possible downref: Normative reference to a draft: ref. '2' -- 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' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '11') (Obsoleted by RFC 4301) == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-00 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Eggert 2 Internet-Draft NEC 3 Expires: January 10, 2005 J. Laganier 4 LIP / Sun Microsystems 5 July 12, 2004 7 Host Identity Protocol (HIP) Rendezvous Extensions 8 draft-eggert-hip-rvs-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 10, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document discusses rendezvous extensions for the Host Identity 42 Protocol (HIP). Rendezvous mechanisms extend HIP for communication 43 with HIP Rendezvous Servers. Rendezvous Servers improve operation 44 when HIP nodes are multi-homed or mobile. The first part of his 45 document motivates the need for rendezvous mechanisms; the second 46 part describes the protocol extensions in detail. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Communication Between HIP Nodes . . . . . . . . . . . . . . . 5 52 3. Communication Between Mobile or Multi-Homed HIP Nodes . . . . 7 53 3.1 Mobility and Multi-Homing with DNS Updates . . . . . . . . 7 54 3.2 Mobility and Multi-Homing with Rendezvous Servers . . . . 8 55 4. HIP Extensions for Rendezvous Servers . . . . . . . . . . . . 10 56 4.1 Additional Control Fields in the HIP Base Header . . . . . 10 57 4.1.1 RVS Control Field . . . . . . . . . . . . . . . . . . 10 58 4.1.2 CONCEAL_IP Control Field . . . . . . . . . . . . . . . 10 59 4.2 Additional HIP Parameters for Communication with 60 Rendezvous Servers . . . . . . . . . . . . . . . . . . . . 11 61 4.2.1 RVA_REQUEST Parameter Format and Processing . . . . . 11 62 4.2.2 RVA_REPLY Parameter Format and Processing . . . . . . 11 63 4.2.3 RVA_HMAC Parameter Format and Processing . . . . . . . 12 64 4.2.4 FROM Parameter Format and Processing . . . . . . . . . 13 65 4.2.5 TO Parameter Format and Processing . . . . . . . . . . 14 66 4.2.6 VIA_RVS Parameter Format and Processing . . . . . . . 15 67 4.3 Use of Existing HIP Messages and Parameters . . . . . . . 15 68 4.3.1 ECHO_REQUEST and ECHO_REPLY Parameters . . . . . . . . 15 69 4.3.2 REA Parameter . . . . . . . . . . . . . . . . . . . . 16 70 4.3.3 NES Parameter . . . . . . . . . . . . . . . . . . . . 16 71 5. Diagram Notation . . . . . . . . . . . . . . . . . . . . . . . 17 72 6. Establishing Rendezvous Associations . . . . . . . . . . . . . 17 73 7. Establishing HIP Associations via Rendezvous Servers . . . . . 19 74 7.1 Sending a Redirect in Reply to I1 . . . . . . . . . . . . 19 75 7.2 Relaying I1 Only . . . . . . . . . . . . . . . . . . . . . 20 76 7.2.1 Passing I1 Through an ESP SA . . . . . . . . . . . . . 20 77 7.2.2 Rewriting I1 Destination IP Address . . . . . . . . . 21 78 7.2.3 Rewriting I1 Source and Destination IP Addresses . . . 22 79 7.3 Relaying Additional HIP Packets . . . . . . . . . . . . . 23 80 7.3.1 Concealing the Responder IP Address . . . . . . . . . 24 81 7.3.2 Concealing the Initiator IP Address . . . . . . . . . 25 82 7.3.3 Concealing Initiator and Responder IP Addresses . . . 26 83 7.4 Cascading Rendezvous Servers . . . . . . . . . . . . . . . 27 84 7.5 Opportunistic Initiators . . . . . . . . . . . . . . . . . 29 85 7.6 Implication on the HIP integrity checks . . . . . . . . . 29 86 7.6.1 Checksum . . . . . . . . . . . . . . . . . . . . . . . 29 87 7.6.2 HMAC and SIGNATURE . . . . . . . . . . . . . . . . . . 29 88 7.6.3 Example . . . . . . . . . . . . . . . . . . . . . . . 29 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 93 10.2 Informative References . . . . . . . . . . . . . . . . . . . 31 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 95 A. Document Revision History . . . . . . . . . . . . . . . . . . 32 96 Intellectual Property and Copyright Statements . . . . . . . . 33 98 1. Introduction 100 The current Internet uses two global namespaces: domain names and IP 101 addresses. The Domain Name System (DNS) provides a two-way lookup 102 service between the two [1]. Domain names are symbolic identifiers 103 for sets of IP addresses. 105 IP addresses have two uses. First, they are topological locators for 106 network attachment points. Second, they act as names for the 107 attached network interfaces. Saltzer [10] discusses these naming 108 concepts in detail. 110 Routing and other network-layer mechanisms are based on the locator 111 aspects of IP addresses. Transport-layer protocols and mechanisms 112 typically use IP addresses in their role as names for communication 113 endpoints. 115 This dual use of IP addresses limits the flexibility of the Internet 116 architecture. The need to avoid readdressing in order to maintain 117 existing transport-layer connections complicates advanced 118 functionality, such as mobility, multi-homing, or network 119 composition. 121 The Host Identity Protocol (HIP) architecture [2] defines a new third 122 namespace. The Host Identity namespace decouples the name and 123 locator roles currently filled by IP addresses. Instead of mapping 124 domain names directly into IP addresses, HIP maps domain names into 125 Host Identities, and Host Identities into IP addresses. 126 Transport-layer mechanisms operate on Host Identities instead of 127 using IP addresses as endpoint names. Network-layer mechanisms 128 continue to use IP addresses as pure locators. 130 Without HIP, nodes establish transport-layer connections by first 131 looking up the fully-qualified domain name (FQDN) of a peer in the 132 DNS. A successful DNS lookup returns the peer's IP addresses. A 133 node uses one of the returned IP addresses to initiate 134 transport-layer communication with a peer node. 136 HIP nodes will also look up the domain name of desired peers in the 137 DNS. When a successful lookup includes a peer's Host Identities, HIP 138 nodes perform a HIP Base Exchange before establishing transport-layer 139 connections. The HIP Base Exchange authenticates the end hosts and 140 can bootstrap encryption of the subsequent communication with IPsec 141 [11]. The HIP specification [3] discusses the details of the Base 142 Exchange and the related protocol exchanges. 144 After the Base Exchange, HIP nodes use Host Identities instead of IP 145 addresses for transport-layer connections with a peer. The HIP layer 146 in the network stack internally translates Host Identities (HI) into 147 network-layer IP addresses. This additional mapping between Host 148 Identities and IP addresses (HI->IP) is logically separate from the 149 first mapping between fully-qualified domain names and Host 150 Identities (FQDN->HI). 152 For application and transport-layer compatibility, the FQDN->HI 153 mapping must remain in the DNS. However, the HI->IP mapping is 154 internal to the HIP layer and may be performed in a number of ways. 155 Different lookup mechanism may support communication between two 156 mobile or multi-homed HIP nodes better [4]. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [5]. 162 2. Communication Between HIP Nodes 164 In the current Internet, the DNS provides a FQDN->IP mapping. With 165 HIP, it must continue to provide a mapping based on domain names. 166 This allows transport-layer connections to bind to Host Identities 167 instead of IP addresses transparently. 169 Instead of mapping domain names directly into IP addresses 170 (FQDN->IP), with HIP the DNS maps them to Host Identities (FQDN->HI). 171 In a second step, another lookup that is internal to the HIP-layer 172 translates the Host Identities into IP addresses for network-layer 173 delivery (HI->IP). 175 Several alternative approaches are possible for maintaining the 176 HI->IP information. The DNS can maintain this mapping along with the 177 FQDN->HI mapping. Alternatively, a database separate from the DNS 178 can manage this information. This section discusses the different 179 approaches and their implications on communication between two HIP 180 nodes. 182 The HIP architecture and protocol specifications suggest storing Host 183 Identities along with a node's IP addresses in the DNS [2][3]. The 184 index for both tables will be domain names. Logically, the DNS will 185 thus contain two separate mappings: FQDN->HI and FQDN->IP. 187 Figure 1 shows the lookup steps and HIP Base Exchange when a node's 188 Host Identities are stored alongside its IP addresses. In step #1, 189 the initiator I performs a DNS lookup on R's domain name FQDN(R). 190 The DNS server responds with both R's Host Identities HI(R) and its 191 IP addresses IP(R) in step #2. 193 The initiator I uses both pieces of information to perform the HIP 194 Base Exchange with R in step #3. (The details of the Base Exchange, 195 specified in [3], are not relevant to this discussion and will thus 196 be omitted.) 198 #1 FQDN(R) +----------+ 199 +-------------------->| DNS | 200 | +-------------------| | 201 | | #2 HI(R), IP(R) | FQDN->HI | 202 | | | FQDN->IP | 203 | | +----------+ 204 | V 205 +-----+ #3 HIP Base Exchange +-----+ 206 | |-------------------------------->| | 207 | I |<--------------------------------| R | 208 | |-------------------------------->| | 209 | |<--------------------------------| | 210 +-----+ +-----+ 212 Figure 1: HIP Lookup and Base Exchange 214 Note that the DNS does not currently store the HI->IP mapping 215 directly. Instead, a DNS lookup on a domain name returns both its 216 FQDN->HI and FQDN->IP entries. The HIP stack then implicitly 217 constructs the HI->IP mapping based on the HI and IP information 218 returned by the DNS lookup. In the example in Figure 1, the FQDN(R) 219 lookup in step #1 returns both HI(R) and IP(R) in step #2. HIP 220 implicitly constructs the HI(R)->IP(R) mapping based on the 221 assumption that HI(R) is reachable at IP(R). 223 One disadvantage of this approach is that a node's domain name is 224 required to obtain both its Host Identities and its IP addresses. 225 Even if a HIP node already knows the Host Identity of a HIP peer 226 through other means, it cannot currently obtain the peer's IP 227 addresses through the DNS. The DNS does not maintain an explicit 228 HI->IP table, but instead indexes Host Identities only by domain 229 names. 231 A reverse HI->FQDN DNS mapping could address this limitation. HIP 232 nodes would then look up a HIP peer's domain name through its Host 233 Identity. They would then use the returned domain name to find the 234 peer's IP addresses in a second lookup. However, the DNS may not be 235 structurally suited to maintain the reverse HIP->FQDN mapping. As 236 the main Internet-wide database, the DNS is already being overloaded 237 with functionality that might be better handled with new mechanisms 238 [12]. Finally, the additional reverse lookup would increase the 239 latency of the HIP Base Exchange. 241 3. Communication Between Mobile or Multi-Homed HIP Nodes 243 HIP decouples domain names from IP addresses. Because transport 244 protocols bind to Host Identities, they remain unaware if the set of 245 IP addresses associated with a Host Identity changes. This change 246 can have various reasons, including, but not limited to, mobility and 247 multi-homing. 249 Proposed extensions for mobility and multi-homing [4] allow a HIP 250 node to notify its peers about changes in its set of IP addresses. 251 These extensions require an established HIP association between two 252 nodes, i.e., a completed HIP Base Exchange. 254 In addition to notifying its current peers about changes in its IP 255 addresses, a HIP node must also update its HI->IP mapping in response 256 to IP address changes. Otherwise, HIP Base Exchanges from new peers 257 could fail because they try to contact the node at an IP address it 258 is no longer reachable at. 260 3.1 Mobility and Multi-Homing with DNS Updates 262 If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP 263 table, nodes can dynamically update their DNS entry in a secure 264 fashion [6][7]. The DNS server maintaining the information will then 265 sign and distribute the updated zone. 267 #2 FQDN(R) +----------+ 268 +-------------------->| DNS | 269 | +-------------------| |<------+ 270 | | #3 HI(R), IP(R) | FQDN->HI | | #1 Update 271 | | | FQDN->IP | | FQDN(R)->IP(R) 272 | | +----------+ | whenever IP(R) 273 | V | changes. 274 +-----+ #4 HIP Base Exchange +-----+ 275 | |-------------------------------->| | 276 | I |<--------------------------------| R | 277 | |-------------------------------->| | 278 | |<--------------------------------| | 279 +-----+ +-----+ 281 Figure 2: HIP Lookup and Base Exchange with DNS Updates 283 Figure 2 shows an example of this scenario. In step #1, R registers 284 its FQDN(R)->IP(R) entry in the DNS. It will dynamically update the 285 DNS entry whenever its IP addresses IP(R) change. Because the DNS 286 always contains R's current IP addresses, node I can perform a HIP 287 Base Exchange with R at its new IP address (steps #2-4). 289 One drawback of using dynamic DNS updates in this way is the cost of 290 updating secure zones. Re-signing an entire zone whenever the IP 291 addresses of one entry change places a high cost on the DNS server. 292 Using dynamic DNS to update HI->IP mappings may thus not be 293 appropriate when changes of IP addresses are frequent. 295 A simple, operational change could help limit the costs of frequent 296 DNS updates. Instead of recomputing a zone after each dynamic 297 update, a DNS server could aggregate the modifications and only 298 perform zone updates periodically. The disadvantage of this approach 299 is that HIP nodes may be unreachable until the DNS server distributes 300 the updated zone. 302 Another concern with using the DNS to support HIP node mobility is 303 the propagation time of updated DNS entries. DNS servers frequently 304 cache DNS responses to reduce the load on the primary servers. 305 During the time-to-live associated with a DNS response, DNS servers 306 may answer additional requests for the same DNS entry from their 307 local caches instead of contacting the primary servers. Thus, even 308 after a HIP node updates its DNS entry, the DNS can still serve the 309 old entry until the cached responses expire. This can lead to 310 communication problems, because peers may try to contact a HIP node 311 at an IP address it is no longer reachable at. 313 3.2 Mobility and Multi-Homing with Rendezvous Servers 315 The HIP architecture tries to greatly reduce the frequency of Dynamic 316 DNS updates by introducing Rendezvous Servers [2]. Instead of 317 registering its current set of IP addresses in its HI->IP entry in 318 the DNS, a HIP node may instead register the IP addresses of its 319 Rendezvous Servers. Because the IP addresses of Rendezvous Servers 320 are assumed to change only infrequently, this approach can 321 significantly reduce the load on DNS servers. 323 Rendezvous Servers maintain a mapping between the Host Identities of 324 HIP nodes for which they provide service and the node's current IP 325 addresses. HIP nodes must notify their Rendezvous Servers about any 326 changes in their IP addresses. This approach effectively relocates 327 the HI->IP information - and the burden of keeping it current - from 328 the DNS to the Rendezvous Servers. This can reduce update costs 329 under the assumption that Rendezvous Servers provide more efficient 330 ways of maintaining HI->IP tables. 332 When a packet destined for one of its HIP nodes arrives at a 333 Rendezvous Server, it relays the packet to one of the HIP node's 334 current IP addresses. Due to the specifics of the HIP, only the 335 first packet of a HIP Base Exchange will require such relaying [2]. 336 Subsequent packet of the HIP Base Exchange and all further data 337 packets will directly flow between the HIP nodes, bypassing the 338 Rendezvous Server. 340 #3 FQDN(R) +----------+ #2 Register IP(RVS) in 341 +--------------------->| DNS | FQDN(R)->IP(RVS). 342 | +--------------------| |<------------------+ 343 | | #4 HI(R), IP(RVS) | FQDN->HI | | 344 | | | FQDN->IP | | 345 | | +----------+ | 346 | | | 347 | | #1 Update IP(R) in HI(R)->IP(R) | 348 | | +--------+ whenever IP(R) changes. | 349 | | | RVS |<------------------------------+ | 350 | | | | | | 351 | V +->| HI->IP |--+ | | 352 +-----+ | +--------+ | +-----+ 353 | |---+ +------------------------->| | 354 | I | #5 First Message of HIP Base Exchange | R | 355 | | | | 356 | |<--------------------------------------------| | 357 | |-------------------------------------------->| | 358 | |<--------------------------------------------| | 359 +-----+ #6 Remainder of HIP Base Exchange +-----+ 361 Figure 3: HIP Lookup and Base Exchange with Rendezvous Server 363 Figure 3 shows a HIP lookup and Base Exchange involving a Rendezvous 364 Server. Here, HIP node R is using Rendezvous Server RVS. In step 365 #1, it updates RVS with its current IP addresses IP(R). Then, in 366 step #2, R registers the Rendezvous Server's IP addresses IP(RVS) in 367 its FQDN(R)->IP(RVS) DNS entry. 369 In step #3, a second HIP node I issues a DNS lookup on FQDN(R) to 370 obtain R's Host Identities HI(R) and IP addresses. The lookup 371 returns R's Host Identities HI(R) in step #4. The DNS reply also 372 includes the IP addresses of the Rendezvous Server IP(RVS) (instead 373 of IP(R), because R's current addresses are unknown to the DNS.) 375 In step #5, node I initiates the HIP Base Exchange. It addresses the 376 first packet of the HIP Base Exchange to IP(RVS). Upon receipt, the 377 Rendezvous Server relays the packet to one of R's current IP 378 addresses IP(R). The remainder of the HIP Base Exchange then occurs 379 directly between I and R in step #6. 381 When Rendezvous Servers maintain the HI->IP information, they may 382 support more efficient update operations compared to dynamic DNS 383 updates (Section 3.1). Unlike the DNS, Rendezvous Servers do not 384 provide a lookup service. Instead, they use the HI->IP information 385 to actively relay traffic between HIP nodes. 387 This approach changes the role of the IP addresses stored in a DNS 388 entry. Traditionally, nodes were directly reachable at the IP 389 addresses listed in their DNS entry. HIP Rendezvous Server change 390 this basic property by replacing the IP addresses of their client 391 nodes in the DNS with their own. The IP addresses in a DNS entry 392 hence no longer directly designate interfaces of an endpoint. 393 Instead, they identify interfaces of a node that can relay packets to 394 the endpoint. 396 4. HIP Extensions for Rendezvous Servers 398 The following sections describe HIP extensions for communication with 399 Rendezvous Servers. These extensions allow: 401 o A HIP Rendezvous Server to advertise its RVS capabilities to its 402 correspondents. 404 o A HIP node to create a Rendezvous Association (RVA) with its 405 Rendezvous Server, i.e., to register its current set of IP 406 address(es). 408 o two HIP nodes to establish a HIP Association (HA) between them via 409 one or more Rendezvous Server. 411 4.1 Additional Control Fields in the HIP Base Header 413 RVS mechanisms make use of two new Control Fields in the HIP Control 414 Field: RVS_CAPABLE and CONCEAL_IP Control Fields. This new fields 415 are used to, respectively, advertise Rendezvous Server capabilities, 416 and query downstream RVS for concealing source IP addresses. 418 4.1.1 RVS Control Field 420 The RVS_CAPABLE Control Field ("R") allows a Rendezvous Server to 421 advertise its rendezvous capabilities to the HIP nodes it associates 422 with. 424 4.1.2 CONCEAL_IP Control Field 426 The CONCEAL_IP Control Field ("C") is used by a HIP node to query 427 downstream Rendezvous Servers to conceal its IP address. The RVS 428 conceals the sender's IP address of a HIP packet by (1) replacing the 429 packet's source IP address field with its own address, and by (2) 430 omitting to add a FROM parameter containing the sender's IP address. 432 A RVS receiving a HIP packet with the CONCEAL_IP Control Field set 433 MUST NOT augment the packet with a FROM parameter while relaying it. 434 If the relaying cannot be accomplished without FROM parameter, the 435 RVS MUST drop the packet, and MAY notify the original sender. 437 4.2 Additional HIP Parameters for Communication with Rendezvous Servers 439 4.2.1 RVA_REQUEST Parameter Format and Processing 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Lifetime | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | RVA Type #1 | RVA Type #2 | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | RVA Type #n | padding | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Type 100 454 Length Length in octets, excluding Type, Length and Padding 455 Lifetime This field encode, the desired RVA validity time. 456 RVA Type This field encode, in order of preference, the 457 preferred rendezvous service types. 459 4.2.2 RVA_REPLY Parameter Format and Processing 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Lifetime | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | RVA Type #1 | RVA Type #2 | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | RVA Type #n | padding | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Type 102 474 Length Length in octets, excluding Type, Length and Padding 475 Lifetime This field encode the offered RVA validity time 476 RVA Type This field encode, in order of preference, the 477 preferred rendezvous service types. 479 The following RVA Type are defined: 481 Type number RVA Type 482 ----------- -------- 483 0 Reserved 484 1 RELAY_I1 485 2 RELAY_I1R1 486 3 RELAY_I1R1I2 487 4 RELAY_I1R1I2R2 488 5 RELAY_ESP_I1 489 6 REDIRECT_I1 491 4.2.3 RVA_HMAC Parameter Format and Processing 493 The RVA_HMAC is an OPTIONAL parameter whose only difference with the 494 HMAC parameter defined in [3] is the Type code: 496 Type 65320 497 Length 20 498 HMAC 160 low order bits of a HMAC keyed with the appropriate 499 HIP integrity keys (HIP_lg or HIP_gl) of the corresponding 500 Rendezvous Association or HIP Association. This HMAC is 501 computed over the HIP packet excluding RVA_HMAC and any 502 other following parameter. The checksum field MUST be set 503 to zero and the HIP header length in the HIP common header 504 MUST be calculated not to cover any excluded parameter when 505 the Authenticator field is calculated. 507 To allow a HIP node and any of its RVS to verify the integrity of 508 packets flowing between them, both use an RVA_HMAC parameter keyed 509 with a HMAC of HIP_lg and HIP_gl integrity keys. One RVA_HMAC SHOULD 510 be present on every packets flowing between a HIP node and any of its 511 RVS and MUST be present when FROM and TO parameters are processed. 513 On the receiving side, when an RVA_HMAC is validated, it SHOULD be 514 removed from the packet and if so, packet length and checksum MUST be 515 recomputed accordingly. 517 4.2.4 FROM Parameter Format and Processing 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type | Length | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 | Address | 526 | | 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Type 65100 (under signature) or 65300 (after signature) 531 Length 16 532 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 534 A Rendezvous Server MAY add a FROM parameter containing the original 535 source IP address of a HIP packet (I1, R1, I2 or R2) whose source IP 536 address has been rewritten. If one or more FROM parameters are 537 already present, the new FROM parameter MUST be appended after the 538 existing ones. Each time an RVS inserts a FROM parameter, it MUST 539 also insert additional parameters that will be used to validate this 540 and the subsequent HIP packets. These parameters are: 542 o An ECHO_REQUEST, containing a chunk of opaque data allowing to 543 validate, in a possible subsequent answer, a TO parameter which 544 MUST be protected by an ECHO_RESPONSE containing the same opaque 545 data. 547 o A valid RVA_HMAC, protecting the packet integrity. 549 When a HIP node validates a FROM parameter, it is removed from the 550 packet and recorded for later use (i.e., for building the 551 corresponding TO parameter to be piggybacked onto a subsequent 552 answer). The packet's source IP address is also replaced by the 553 address included in the first occurrence of FROM parameter. 555 For each FROM parameter, a HIP node MAY add to its replies a TO 556 parameter containing the IP address included in the FROM. These 557 replies will be sent via the RVS, which MUST remove the outer TO 558 parameter from the packet and replace its destination address with 559 the address contained in the TO parameter before relaying it. 561 4.2.5 TO Parameter Format and Processing 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | | 569 | Address | 570 | | 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Type 65102 (under signature) or 65302 (after signature) 575 Length 16 576 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 578 A HIP node MAY add one or more TO parameter containing the final 579 destination IP address of a HIP packet (I1, R1, I2 or R2) whose 580 destination IP address needs to be rewritten by an RVS. This is 581 essentially equivalent to loose source-routing. If one or more TO 582 parameters are already present, the new TO parameter MUST be appended 583 after the existing ones. Each time a node inserts a TO parameter, it 584 MUST also insert additional parameters that will be used by the RVS 585 for validation. These parameters are: 587 o An ECHO_RESPONSE, containing a chunk of opaque data allowing the 588 RVS to validate the address contained in the TO parameter. 590 o A valid RVA_HMAC, protecting the packet integrity. 592 When the RVS validates a TO parameter, SHALL remove it from the 593 packet, and SHALL replace the packet destination IP address with the 594 address included in the TO parameter. Packet length and checksum 595 MUST then be recomputed accordingly. 597 For each FROM parameter, a HIP node MAY add to its replies a TO 598 parameter containing the IP address included in the FROM. These 599 replies will be sent via the RVS, which MUST remove the outer TO 600 parameter from the packet and replace its destination address field 601 with the address contained in the TO parameter before relaying it. 603 4.2.6 VIA_RVS Parameter Format and Processing 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 | Address | 612 | | 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 . . . 616 . . . 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | | 619 | Address | 620 | | 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Type 65500 625 Length Variable 626 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 628 At some point a, HIP endpoint might be in position to begin to send 629 HIP packets directly towards the remote HIP endpoint's IP address, 630 without further assistance from one or more of its RVS(s). In that 631 case, it MAY include in these packets a subset of the IP address(es) 632 of its Rendezvous Servers by either: 634 o Add its IP address into an existing VIA_RVS parameter situated at 635 the end of the HIP packet, while modifying accordingly the size of 636 the parameter. 638 o Appending a newly created VIA_RVS parameter at the end of the HIP 639 packet if it does not already contain a VIA_RVS parameter. 641 Note that the main goal of the using the VIA_RVS parameter is to 642 allow operators to diagnose possible issues encountered while 643 establishing a HIP association via a RVS. 645 4.3 Use of Existing HIP Messages and Parameters 647 4.3.1 ECHO_REQUEST and ECHO_REPLY Parameters 649 A FROM parameter MAY be augmented by including an ECHO_REQUEST 650 parameter to the carrying packet. The contents of the ECHO_REQUEST 651 might then be echoed back in ECHO_RESPONSE. 653 A TO parameter SHOULD be augmented and authenticated by including an 654 ECHO_REPLY parameter to the carrying packet. The contents of the 655 ECHO_REPLY MUST be copied from a previously received ECHO_RESPONSE. 657 All the HIP packets requiring RVS relaying facility to carry an 658 answer packet SHOULD be augmented by the RVS with an ECHO_REQUEST 659 parameter. 661 A possible packet answered via the RVS, thus requiring relaying 662 facility, SHOULD be authenticated by an ECHO_REPLY parameter. The 663 contents of the ECHO_REPLY MUST be copied from a previously received 664 ECHO_RESPONSE. 666 On the receiving side, when a HIP node validates an ECHO_REPLY 667 located after the signatures, it MUST remove it from the packet and 668 recompute packet length and checksum accordingly. 670 4.3.2 REA Parameter 672 A HIP node associated via an RVS MAY use a REA parameter to make its 673 correspondent aware of its veritable current IP address. If used, 674 the REA parameter MUST be used in conformance with the guidelines 675 specified in [4]. In addition, a HIP node MAY initiate the protocol 676 later during the base exchange by using the REA parameter in the R2 677 packet. This R2-with-REA packet MUST be treated as a 678 UPDATE-with-REA, i.e., trigger a Routability Return check by 679 generating and sending a new SPI stored in a NES parameter included 680 in an UPDATE packet. 682 4.3.3 NES Parameter 684 A HIP node receiving a REA packet later than I2 MUST perform a 685 Routability Return check before sending data to the new IP address. 686 This check is performed by replying to an incoming REA with a NES 687 parameter containing a new SPI to be used, as described in [4]. 689 5. Diagram Notation 691 Notation Significance 692 -------- ------------ 694 I, R I and R are the respective source and destination IP 695 addresses of the IP header 697 HIT-I, HIT-I and HIT-R are respectively the Initiator and the 698 HIT-R Responder HIT of the packet 700 R The RVS_CAPABLE Control Field is set into the Control 701 Field of the HIP header 703 C The CONCEAL_IP Control Field is set into the Control 704 Field of the HIP header 706 REA:I A REA parameter containing the IP address i is 707 present in the HIP header 709 FROM:I A FROM parameter containing the IP address I is present 710 in the HIP header 712 TO:I A TO parameter containing the IP address I is present 713 in the HIP header 715 VIA_RVS:RVS A VIA_RVS parameter containing IP addresses RVS 716 is present in the HIP header 718 EREQ An ECHO_REQUEST parameter is present in the HIP header 720 EREP An ECHO_REPLY parameter is present in the HIP header 722 RREQ A RVA_REQUEST parameter is present in the HIP header 724 RREP A RVA_REPLY parameter is present in the HIP header 726 6. Establishing Rendezvous Associations 728 A HIP node that wants to register its IP address with its RVS MAY 729 simply establish a HIP association with it. It MUST then keep its IP 730 address current with the server by sending UPDATE packets whenever 731 its set of IP addresses changes. 733 However, for the sake of economizing RVS resources, which can 734 possibly be used by several thousands of different HIP nodes, we 735 define a new sort of "soft state" HIP association called a Rendezvous 736 Association (RVA). In order to maintain this RVA established, a HIP 737 Association need not remain established. 739 A HIP node MAY establish an RVA with its RVS by establishing a HA 740 while adding an RVA_REQUEST parameter in an I2, possibly preceded by 741 an I1 containing the same RVA_REQUEST. The possibility offered to 742 initiate the protocol in I1 allows a HIP node to query a RVS for the 743 set of offered rendezvous service types before completing the 744 establishment of the Rendezvous association (in case the desired 745 service type isn't available on this RVS). A RVS MUST then reply 746 with, respectively, an R2 possibly preceded by an R1, which will both 747 have the RVS_CAPABLE control field set, and contain a RVA_REPLY 748 parameter specifying the characteristics of the offered RVA (validity 749 time, type, etc.). Then, the RVS and the HIP node MAY delete most of 750 the HIP Association state, retaining only the Lifetime, Initiator's 751 HIT and IP address(es), as well as HIP_lg and HIP_gl integrity keys. 753 When a HA is established via an RVS, the integrity of HIP packets 754 flowing between a HIP node and its RVS is protected by an additional 755 RVA_HMAC keyed with these keys. 757 I1(I, RVS, HIT-I, 758 HIT-RVS) +------+ 759 +-------------------------->| | 760 |+--------------------------| | 761 || R1(RVS, I, HIT-RVS, | | 762 || HIT-I, R) | | 763 || | RVS1 | 764 || I2(I, RVS, HIT-I, | | 765 || HIT-RVS, RREQ) | | 766 || +----------------------->| | 767 || |+-----------------------| | 768 || || R2(RVS, I, HIT-RVS, +------+ 769 || || HIT-I, R, RREP) 770 |V |V 771 +-----+ 772 | | 773 | I | 774 | | 775 +-----+ 777 Figure 12: Establishing a Rendezvous Association 779 There is nothing to prevent an RVS node to advertise its RVS 780 capabilities to the peers it associates with, nor to establish an RVA 781 with another RVS. 783 If a HIP node wants to associate with several cascaded Rendezvous 784 Servers RVS_i (0 < i < n+1), it SHALL sequentially create RVAs 785 (RVA_i) with each of them, starting from the "nearest" (RVS_1) to the 786 "farthest" (RVS_n). Apart from RVA_1, a node SHOULD create any such 787 RVA_i (1 < i < n+1) by sending an I1 to RVS_i via each of the RVS 788 which precede it, i.e., RVS_j (1 < j < i). 790 This is achieved by using (i - 1) different TO parameters containing, 791 in order, the IP address of each RVS preceding RVS_i, i.e., RVS_j (1 792 < j < i). This process is similar to IP loose source-routing. 793 Hence, A RVS accepting to be part of a cascade MAY relay an incoming 794 I1 from one its clients to any given address and HIT. Those I1s MUST 795 be protected by a valid RVA_HMAC parameter. 797 I1(I, RVS1, HIT-I, I1(RVS1, RVS2, HIT-I, 798 HIT-RVS2, TO:RVS2) +------+ HIT-RVS2, EREQ1) 799 +-------------------------->| |----------------------------+ 800 |+--------------------------| |<--------------------------+| 801 || R1(RVS1, I, HIT-RVS2, | | R1(RVS2, RVS1, || 802 || HIT-I, R, EREQ1) | | HIT-RVS2, HIT-I, || 803 || | RVS1 | R, EREP1) || 804 || I2(I, RVS1, HIT-I, | | || 805 || HIT-RVS2, RREQ, | | I2(RVS1, RVS2, HIT-I, || 806 || EREP1, TO:RVS2) | | HIT-RVS2, RREQ, EREQ1) || 807 || +----------------------->| |------------------------+ || 808 || |+-----------------------| |<----------------------+| || 809 || || R2(RVS1, I, HIT-RVS2, +------+ R2(RVS2, RVS1, || || 810 || || HIT-I, R, RREP, HIT-RVS2, HIT-I, || || 811 || || EREQ1) R, RREP, EREP1) || || 812 |V |V |V |V 813 +-----+ +------+ 814 | | | | 815 | I | | RVS2 | 816 | | | | 817 +-----+ +------+ 819 Figure 13: Establishing Cascaded Rendezvous Associations 821 7. Establishing HIP Associations via Rendezvous Servers 823 7.1 Sending a Redirect in Reply to I1 825 Instead of having the RVS relay incoming I1s to the correct 826 Responder, one possibility is to answer with a redirect packet when a 827 HIP packet destined for one of the Rendezvous Server's HIP nodes 828 arrives. This redirect packet contains the IP address and packet 829 signature of the Responder. 831 The Responder cannot sign the redirect packets delivered by the RVS 832 in real time. When the RVA is set up, the Responder sends the signed 833 redirect packet to the RVS, who stores it until the RVA expires. 835 This redirect packet can be implemented by using a REA parameter 836 embedded into a NOTIFY packet that includes a SIGNATURE2 parameter 837 for protection. Note that this may expose the Initiator to replay 838 attacks, but this is not very different from the situation where the 839 Initiator receives a signed R1 whose signature omits Receiver HIT. 841 However, because an initiator might be unaware of the HI of the 842 responder, knowing only its HIT, it might not be able to verify this 843 SIGNATURE2. Hence, it is necessary to include in this redirect 844 packet the HI of the responder, thus allowing the initiator to verify 845 the signatures based on a previously known HIT. 847 7.2 Relaying I1 Only 849 7.2.1 Passing I1 Through an ESP SA 851 If a HIP node and one of its Rendezvous Servers maintain a HIP 852 Association, the Rendezvous Server MAY tunnel I1s incoming to this 853 node's HIT into the corresponding ESP SA. The main drawbacks of this 854 approach are that, (1) middleboxes cannot see the encrypted I1 855 passing from an RVS to its clients, and (2) the source IP address of 856 I1 is lost. In particular, (2) implies that the RVS MUST transmit to 857 the responder the original source IP address by either of the 858 following: 860 o add a FROM parameter to the HIP header 862 o include the whole original IP header in the ESP payload (very 863 similar to ESP tunnel mode) 865 o route back the subsequent R1 via the RVS 866 ESP(RVS, R, 867 I1(I, RVS, HIT-I, 868 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I)) 869 +----------------------->| |--------------------+ 870 | | RVS | | 871 | | | | 872 | +---------+ | 873 | V 874 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA_RVS:RVS) +-----+ 875 | |<---------------------------------------------| | 876 | | | | 877 | I | I2(I, R, HIT-I, HIT-R) | R | 878 | |--------------------------------------------->| | 879 | |<---------------------------------------------| | 880 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 882 Figure 14: Rendezvous Server Forwarding I1 Through an ESP SA 884 7.2.2 Rewriting I1 Destination IP Address 886 When a HIP packet destined for one of its HIP nodes arrives at a 887 Rendezvous Server, it relays the packet to one of the HIP node's 888 current IP addresses. In most case, it is expected that only the 889 first packet of a HIP Base Exchange (i.e., I1) will require such 890 relaying [2]. Subsequent packet of the HIP Base Exchange and all 891 further data packets will directly flow between the HIP nodes, 892 bypassing the Rendezvous Server. 894 In the simplest case, the Rendezvous Server can relay an I1 towards 895 its true destination by merely replacing the destination IP address 896 of the I1 by one of the destination HIT owner's IP address(es). 897 Note, however, that such I1s might be subject to egress filtering on 898 the Rendezvous Server's network [8], thus causing I1 packet to be 899 dropped (source IP address does not belong to the RVS network). 901 I1(I, R, HIT-I, 902 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I) 903 +----------------------->| |--------------------+ 904 | | RVS | | 905 | | | | 906 | +---------+ | 907 | V 908 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA_RVS:RVS) +-----+ 909 | |<---------------------------------------------| | 910 | | | | 911 | I | I2(I, R, HIT-I, HIT-R) | R | 912 | |--------------------------------------------->| | 913 | |<---------------------------------------------| | 914 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 916 Figure 15: Rendezvous Server Rewriting I1 Destination IP Address 918 7.2.3 Rewriting I1 Source and Destination IP Addresses 920 Because of egress filtering, a HIP Rendezvous Server might need to 921 replace the original source IP address of an I1 by its own IP 922 address, thus concealing the Initiator's IP address to the Responder. 924 While this might be desirable, one of the extension described in this 925 document allows a Rendezvous Server to piggy-back incoming HIP 926 packets with an OPTIONAL FROM parameter containing the original 927 source IP address of the packet. A HIP node receiving a packet 928 containing such a FROM parameter has two possibilities for answering 929 back. It might answer back either: 931 o Directly to the IP address included in the FROM parameter, thus 932 disclosing its IP address. 934 o Via the Rendezvous Server IP address, adding to the HIP header a 935 TO parameter containing the IP address included in the FROM 936 parameter, thus being able to conceal its IP address to its 937 correspondent. 939 I1(I, RVS, HIT-I, 940 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I) 941 +----------------------->| |--------------------+ 942 | | RVS | | 943 | | | | 944 | +---------+ | 945 | V 946 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA_RVS:RVS) +-----+ 947 | |<---------------------------------------------| | 948 | | | | 949 | I | I2(I, R, HIT-I, HIT-R) | R | 950 | |--------------------------------------------->| | 951 | |<---------------------------------------------| | 952 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 954 Figure 16: Rendezvous Server Rewriting I1 Source and Destination IP 955 Addresses 957 7.3 Relaying Additional HIP Packets 959 It might be useful to relay further HIP packets (i.e., R1, I2 and R2) 960 via the RVS, for example for concealing HIP nodes IP addresses until 961 they have authenticated each other. 963 Because these packets are larger than I1 (they contain public keys 964 and signatures), the relaying of such packet create an opportunity 965 for denial of service attacks. To defend against these attacks, the 966 Rendezvous Server needs to differentiate between legitimate HIP 967 packets (i.e., I1 and subsequent HIP packets triggered by an I1) and 968 illegitimate ones. 970 For the sake of reducing the load incurred on the RVS, an RVS is not 971 required to keep track of IP addresses and other pieces of state 972 associated with ongoing HIP exchanges. Such behavior is OPTIONAL. 973 Instead, the relaying facility MAY make use of ECHO_REQUEST and 974 ECHO_RESPONSE parameters. 976 Each time a packet is being relayed, the RVS MAY augment it with an 977 ECHO_REQUEST parameter containing a chunk of opaque data. The 978 receiver of such a packet SHOULD augment any packet answering to this 979 packet with an ECHO_REPLY parameter containing the same chunk of 980 opaque data. This opaque data allows an RVS to find and validate the 981 answered packet IP addresses and HITs. When successfully validated, 982 ECHO_REPLY parameters SHOULD be removed from the packet before 983 relaying. 985 7.3.1 Concealing the Responder IP Address 987 As mentioned before, a Responder MAY want to conceal its IP 988 address(es) to an Initiator whose Host Identity has not yet been 989 validated by an I2. Such a Responder SHOULD set the CONCEAL_IP 990 Control Field in the HIP packets (R1 and R2) it sends. The 991 Rendezvous Server then MUST replace the source IP address of relayed 992 HIP packets with its own one without appending a FROM parameter. 994 The Responder MUST NOT include a REA parameter before it receives a 995 valid I2. This situation also requires the Responder to send back 996 via the RVS an R1 to the Initiator. Then, the Initiator will sends 997 via the RVS an I2 to the Responder, causing the Responder to send 998 directly to the Initiator an R2 containing a REA parameter with its 999 current IP address(es). 1001 [4] does not describe any method to initiate the readdressing 1002 protocol in an R2 (by adding a REA parameter). A Responder MAY 1003 initiate the readdressing protocol in R2. The Initiator SHOULD then 1004 perform a Routability Return check by answering with an UPDATE packet 1005 including a NES. The Responder will then use the new SPI to sends 1006 ESP packet to the Initiator. 1008 I1(I, RVS, I1(RVS, R, HIT-I, 1009 HIT-I, HIT-R) +---------+ HIT-R, FROM:I, EREQ) 1010 +-------------------->| |----------------------+ 1011 |+--------------------| |<--------------------+| 1012 || R1(RVS, I, HIT-R, | | R1(R, RVS, HIT-R, || 1013 || HIT-I, C, EREQ) | | HIT-I, C, TO:I, || 1014 || | RVS | EREP) || 1015 || | | || 1016 || | | I2(RVS, R, HIT-I, || 1017 || I2(I, RVS, HIT-I, | | HIT-R, FROM:I, || 1018 || HIT-R, EREP) | | EREQ) || 1019 || +----------------->| |-------------------+ || 1020 || | +---------+ | || 1021 |V | V |V 1022 +-----+ R2(R, I, HIT-R, HIT-I, REA:R, EREP) +-----+ 1023 | |<--------------------------------------------| | 1024 | |-------------------------------------------->| | 1025 | | UPDATE(I, R, HIT-I, HIT-R, NES:SPI-I) | | 1026 | I | | R | 1027 | | ESP(R, I, SPI-R) | | 1028 | |<--------------------------------------------| | 1029 | |-------------------------------------------->| | 1030 +-----+ ESP(I, R, SPI-I) +-----+ 1032 Figure 17: Responder Concealing its IP address 1034 7.3.2 Concealing the Initiator IP Address 1036 Similarly, an Initiator might want to conceal its IP address(es) to a 1037 Responder whose Host Identity has not yet been validated by R2. Such 1038 an Initiator set the CONCEAL_IP Control Field in the HIP packets (I1 1039 and I2) it sends. 1041 The Rendezvous Server then replace the source IP address of relayed 1042 HIP packets with its own one without appending a FROM parameter. 1044 The Initiator MUST NOT include a REA parameter before he received a 1045 valid I2. This situation also requires the Responder to send back 1046 via the RVS an R1 to the Initiator. Then, the Initiator will sends 1047 via the RVS an I2 to the Responder. This will cause the Responder to 1048 send via the RVS to the Initiator an R2 containing a REA parameter 1049 with its current IP address(es). 1051 [4] does not describe any method to initiate the readdressing 1052 protocol in an R2 (by adding a REA parameter). A Responder MAY 1053 initiate the readdressing protocol in R2. The Initiator SHOULD then 1054 perform a Routability Return check by answering with an UPDATE packet 1055 including a NES. The Responder will then use the new SPI to sends 1056 ESP packet to the Initiator. 1058 The Initiator should then initiate a "classic" readdressing protocol 1059 by sending UPDATE packets including a REA parameter, as per [4]. 1061 I1(RVS, R, HIT-I, 1062 I1(I, RVS, HIT-I, HIT-R, C) +-----+ HIT-R, C, EREQ) 1063 +-------------------------->| |---------------------------+ 1064 |+--------------------------| |<-------------------------+| 1065 || R1(RVS, I, HIT-R, | | R1(R, RVS, HIT-R, || 1066 || HIT-I, REA:R, EREQ) | | HIT-I, REA:R, EREP) || 1067 || | RVS | || 1068 || I2(I, RVS, HIT-I, | | I2(RVS, R, HIT-I, || 1069 || HIT-R, C, EREP) | | HIT-R, C, EREQ || 1070 || +----------------------->| |------------------------+ || 1071 || |+-----------------------| |<----------------------+| || 1072 || || R2(RVS, I, HIT-R, +-----+ R2(R, RVS, HIT-R, || || 1073 || || HIT-I, REA:R, EREQ) HIT-I, REA:R, EREP)|| || 1074 |V |V |V |V 1075 +-----+ +-----+ 1076 | | | | 1077 | I | | R | 1078 | | | | 1079 +-----+ +-----+ 1081 Figure 18: Initiator Concealing its IP address 1083 At this point, the functionality described here has not been verified 1084 to not introduce new opportunities for DoS and DDoS attacks, because 1085 the responder is unaware of the original source IP address of a 1086 packet. Hence, it is questionable if a responder accepting concealed 1087 initiator(s) should be able, while establishing an RVA with it RVS, 1088 to negotiate a rate-limit on the throughput of relayed I1s. This 1089 might be done by adding a Rate Limit field in the RVA_REQUEST and 1090 RVA_REPLY parameter. 1092 7.3.3 Concealing Initiator and Responder IP Addresses 1094 This situation combines the two variant of IP address concealing 1095 described previously: both Initiator and Responder want to conceal 1096 their IP addresses until their correspondent's Host Identity is 1097 validated by, respectively, a R2 and an I2. All the HIP packets 1098 prior to, and including, R2, MUST be exchanged via the RVS with the 1099 CONCEAL_IP Control Field set. 1101 The Rendezvous Server then replace the source IP address of relayed 1102 HIP packets with its own one without appending a FROM parameter. 1104 Both Initiator and Responder MUST NOT include a REA parameter before 1105 they received and validated, respectively, an R2 or a I2. This 1106 situation also requires the Responder to send back via the RVS R1 and 1107 R2 to the Initiator. Then, the Initiator will sends via the RVS an 1108 I2 to the Responder. This will cause the Responder to send via the 1109 RVS to the Initiator an R2 containing a REA parameter with its 1110 current IP address(es). 1112 [4] does not describe any method to initiate the readdressing 1113 protocol in an R2 (by adding a REA parameter). A Responder MAY 1114 initiate the readdressing protocol in R2. The Initiator SHOULD then 1115 (1) perform a Routability Return check by answering with an UPDATE 1116 packet including a NES as in [4], and (2), SHOULD initiate a 1117 readdressing protocol with the same update, as in [4]. The Initiator 1118 and Responder MUST then use the new SPIs for future ESP packets. 1120 I1(RVS, R, HIT-I, 1121 I1(I, RVS, HIT-I, HIT-R, C) +-----+ HIT-R, C, EREQ) 1122 +-------------------------->| |---------------------------+ 1123 |+--------------------------| |<-------------------------+| 1124 || R1(RVS, I, HIT-R, | | R1(R, RVS, HIT-R, || 1125 || HIT-I, C, EREQ) | | HIT-I, C, EREP) || 1126 || | RVS | || 1127 || I2(I, RVS, HIT-I, | | I2(RVS, R, HIT-I, || 1128 || HIT-R, C, EREP) | | HIT-R, C, EREQ || 1129 || +----------------------->| |------------------------+ || 1130 || |+-----------------------| |<----------------------+| || 1131 || || R2(RVS, I, HIT-R, +-----+ R2(R, RVS, HIT-R, || || 1132 || || HIT-I, C, EREQ) HIT-I, REA:R, EREP)|| || 1133 |V |V |V |V 1134 +-----+ +-----+ 1135 | | | | 1136 | I | | R | 1137 | | | | 1138 +-----+ +-----+ 1140 Figure 19: Initiator and Responder Concealing their IP addresses 1142 7.4 Cascading Rendezvous Servers 1144 In some situations, it might be useful to use cascaded Rendezvous 1145 Servers to establish RVS associations. A typical scenario would be a 1146 small number of "trusted" Rendezvous Servers and a larger number of 1147 "untrusted" Rendezvous Servers. Only the trusted Rendezvous Servers 1148 are aware of the IP addresses of the Responders. The untrusted 1149 servers know only the IP addresses of other (un)trusted Rendezvous 1150 Servers. Untrusted Rendezvous Servers are changed periodically, in 1151 order to lower the opportunity for flooding-type attacks on their IP 1152 addresses. 1154 In the case of cascaded Rendezvous Servers, the parameters added to 1155 the HIP base exchange, like FROM, TO, VIA_RVS, ECHO_REQUEST/REPLY or 1156 RVA_HMAC, MUST be "aggregated" or "clustered" on a per-type basis. 1157 This means that, when an RVS needs to add onto a HIP packet a 1158 parameter which is already present in it, this parameter MUST be 1159 added just after the existing parameter(s) of the same type. For 1160 instance, a FROM parameter MUST be added just after the existing 1161 FROM(s) parameter(s). The same applies to TO, VIA_RVS, 1162 ECHO_REQUEST/REPLY or RVA_HMAC. 1164 Another solution to cascaded Rendezvous Servers may be to encapsulate 1165 the original packet into a PAYLOAD and then piggyback it with 1166 additional parameters. This scheme has not been evaluated further. 1168 I1(RVS2, R, HIT-I, 1169 I1(I, RVS, I1(RVS1, RVS2, HIT-R, EREQ1, 1170 HIT-I, HIT-I, HIT-R, EREQ2, FROM:I, 1171 HIT-R) +------+ EREQ1, FROM:I) +------+ FROM:RVS1) 1172 +--------->| |------------------->| |---------+ 1173 | | RVS1 | | RVS2 | | 1174 | +--------| |<-------------------| |<------+ | 1175 | | +------+ R1(RVS2, RVS2, +------+ | | 1176 | | HIT-I, HIT-R, | | 1177 | | EREP1, EREQ2, | | 1178 | | TO:I) | | 1179 | | R1(RVS1, I, HIT-R, R1(R, RVS2, HIT-R, | | 1180 | | HIT-I, REA:R, HIT-I, REA:R, | | 1181 | | EREQ2, EREQ1) EREP1, EREP2, | | 1182 | | TO:I, TO:RVS2) | | 1183 | V | V 1184 +-----+ I2(I, R, HIT-I, HIT-R, EREP2, EREP1) +-----+ 1185 | |-------------------------------------------->| | 1186 | I |<--------------------------------------------| R | 1187 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 1189 Figure 20: Two Cascaded Rendezvous Servers Relaying an I1-R1 Message 1190 Pair 1192 7.5 Opportunistic Initiators 1194 Because an opportunistic initiator uses the unspecified IPv6 address 1195 (i.e., ::0) as a placeholder for the Responder HIT in I1s it sends, 1196 an RVS cannot use this Responder HIT to demultiplex incoming 1197 "opportunistic" I1s. The only way to properly relay such an 1198 opportunistic I1 to the appropriate responder is to lease per-client 1199 (hence per-HIT) relay IP addresses. That way, the RVS MAY use the 1200 destination IP address as an indicator to determine the correct 1201 responder. 1203 In order to avoid trivial spoofing attacks with R1s, a HIP node 1204 receiving an opportunistic I1 from a Rendezvous Server SHOULD reply 1205 with its R1 via the same Rendezvous Server. 1207 7.6 Implication on the HIP integrity checks 1209 The establishment of HIP associations through one or more Rendezvous 1210 Servers causes HIP packets flowing between the HIP nodes to be 1211 modified during transmission. Several kinds of modifications to both 1212 the IP and HIP headers are possible. The HIP protocol uses two kinds 1213 of packet integrity checks: hop-by-hop and end-to-end. The HIP 1214 checksum is a hop-by-hop check and SHOULD be verified and recomputed 1215 by each of the on-path HIP middleboxes (e.g., Rendezvous Servers). 1216 The HMAC and SIGNATURE are end-to-end checks and MUST be computed by 1217 the sender and verified by the receiver. 1219 7.6.1 Checksum 1221 The checksum field of a HIP header to be modified MUST be verified 1222 before applying the modification and recomputed accordingly after. 1224 7.6.2 HMAC and SIGNATURE 1226 The HMAC and SIGNATURE field of a HIP header MUST be computed and 1227 verified based on a "sender view" or "receiver view" of the HIP 1228 header. In particular, this implies that SIGNATURE and HMAC MUST NOT 1229 cover FROM and TO parameters added or removed by Rendezvous Servers 1230 and that the HIP pseudo-header used to compute and verify them MUST 1231 contain the IP addresses as seen by the remote HIP peer. In case of 1232 IP address concealment, this means that the IP address(es) of the 1233 Rendezvous Servers MUST be used in the pseudo-header in place of the 1234 IP address(es) of the end hosts. 1236 7.6.3 Example 1238 Here is an example showing how to compute the different integrity 1239 checks (end-to-end and hop-by-hop) when two Rendezvous Servers are 1240 cascaded and when both peers conceals their IP addresses (packet 1241 flowing along the path I -> RVS1 -> RVS2 -> R) 1243 End-to-end integrity checks: HMAC and SIGNATURE are computed with a 1244 pseudo-header containing (two times) RVS1 as place holder for source 1245 and destination IP addresses. The rationale being that the initiator 1246 is concealing its IP address behind that of RVS1. Therefore, R will 1247 verify the signature using RVS1 as the source IP address in the 1248 pseudo-header. Similarly, the responder is concealing its IP address 1249 behind that of RVS1, so I will verify the signature using RVS1 as a 1250 source IP address in the pseudo-header. 1252 hop-by-hop integrity checks: Checksum is computed hop-by-hop; first 1253 with I and RVS1, then with RVS1 and RVS2, and finally with RVS2 and 1254 R. 1256 8. Security Considerations 1258 The security aspects of different HIP rendezvous mechanisms are 1259 currently being investigated. They will be discussed in a future 1260 revision of this document. 1262 9. Acknowledgments 1264 The following people have provided thoughtful and helpful discussions 1265 and/or suggestions that have improved this document: Marcus Brunner, 1266 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Simon Schuetz, 1267 Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen 1268 Quittek. 1270 10. References 1272 10.1 Normative References 1274 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 1275 13, RFC 1034, November 1987. 1277 [2] Moskowitz, R., "Host Identity Protocol Architecture", 1278 draft-moskowitz-hip-arch-05 (work in progress), October 2003. 1280 [3] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 1281 Protocol", draft-moskowitz-hip-09 (work in progress), February 1282 2004. 1284 [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host 1285 Identity Protocol", draft-nikander-hip-mm-01 (work in progress), 1286 January 2004. 1288 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1289 Levels", BCP 14, RFC 2119, March 1997. 1291 [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1292 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1293 1997. 1295 [7] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1296 Update", RFC 3007, November 2000. 1298 [8] Killalea, T., "Recommended Internet Service Provider Security 1299 Services and Procedures", BCP 46, RFC 3013, November 2000. 1301 [9] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 1302 Denial of Service Attacks which employ IP Source Address 1303 Spoofing", BCP 38, RFC 2827, May 2000. 1305 10.2 Informative References 1307 [10] Saltzer, J., "On the Naming and Binding of Network 1308 Destinations", RFC 1498, August 1993. 1310 [11] Kent, S. and R. Atkinson, "Security Architecture for the 1311 Internet Protocol", RFC 2401, November 1998. 1313 [12] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, 1314 February 2003. 1316 [13] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", 1317 draft-nikander-esp-beet-mode-00 (work in progress), October 1318 2003. 1320 Authors' Addresses 1322 Lars Eggert 1323 NEC Network Laboratories 1324 Kurfuersten-Anlage 36 1325 Heidelberg 69115 1326 DE 1328 Phone: +49 6221 90511 43 1329 Fax: +49 6221 90511 55 1330 EMail: lars.eggert@netlab.nec.de 1331 URI: http://www.netlab.nec.de/ 1332 Julien Laganier 1333 Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL) 1334 180, Avenue de l'Europe 1335 Saint Ismier CEDEX 38334 1336 FR 1338 Phone: +33 476 188 815 1339 EMail: ju@sun.com 1340 URI: http://research.sun.com/ 1342 Appendix A. Document Revision History 1344 +-----------+-------------------------------------------------------+ 1345 | Revision | Comments | 1346 +-----------+-------------------------------------------------------+ 1347 | 00 | Compared to draft-eggert-hip-rendezvous-00: Minor | 1348 | | fixes to figures and their descriptive text. Added | 1349 | | RVS protocol specification. Removed sections related | 1350 | | to communications between HIP and non-HIP nodes. Use | 1351 | | boilerplate from RFC 3668. | 1352 +-----------+-------------------------------------------------------+ 1354 Intellectual Property Statement 1356 The IETF takes no position regarding the validity or scope of any 1357 Intellectual Property Rights or other rights that might be claimed to 1358 pertain to the implementation or use of the technology described in 1359 this document or the extent to which any license under such rights 1360 might or might not be available; nor does it represent that it has 1361 made any independent effort to identify any such rights. Information 1362 on the procedures with respect to rights in RFC documents can be 1363 found in BCP 78 and BCP 79. 1365 Copies of IPR disclosures made to the IETF Secretariat and any 1366 assurances of licenses to be made available, or the result of an 1367 attempt made to obtain a general license or permission for the use of 1368 such proprietary rights by implementers or users of this 1369 specification can be obtained from the IETF on-line IPR repository at 1370 http://www.ietf.org/ipr. 1372 The IETF invites any interested party to bring to its attention any 1373 copyrights, patents or patent applications, or other proprietary 1374 rights that may cover technology that may be required to implement 1375 this standard. Please address the information to the IETF at 1376 ietf-ipr@ietf.org. 1378 Disclaimer of Validity 1380 This document and the information contained herein are provided on an 1381 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1382 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1383 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1384 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1385 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1386 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1388 Copyright Statement 1390 Copyright (C) The Internet Society (2004). This document is subject 1391 to the rights, licenses and restrictions contained in BCP 78, and 1392 except as set forth therein, the authors retain all their rights. 1394 Acknowledgment 1396 Funding for the RFC Editor function is currently provided by the 1397 Internet Society.