idnits 2.17.1 draft-ietf-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 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1392. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 71 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 617 has weird spacing: '...address with ...' == Line 1012 has weird spacing: '...problem is fo...' -- 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 (October 18, 2004) is 7130 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: '10' is defined on line 1307, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1326, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-00 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '3') == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '4') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '14') (Obsoleted by RFC 5226) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group J. Laganier 3 Internet-Draft LIP / Sun Microsystems 4 Expires: April 18, 2005 L. Eggert 5 NEC 6 October 18, 2004 8 Host Identity Protocol (HIP) Rendezvous Extensions 9 draft-ietf-hip-rvs-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 18, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document discusses rendezvous extensions for the Host Identity 45 Protocol (HIP). Rendezvous mechanisms extend HIP for communication 46 with HIP Rendezvous Servers. Rendezvous Servers improve operation 47 when HIP nodes are multi-homed or mobile. The first part of his 48 document motivates the need for rendezvous mechanisms; the second 49 part describes the protocol extensions in detail. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Communication Between HIP Nodes . . . . . . . . . . . . . . . 4 56 4. Communication Between Mobile or Multi-Homed HIP Nodes . . . . 6 57 4.1 Mobility and Multi-Homing with DNS Updates . . . . . . . . 6 58 4.2 Mobility and Multi-Homing with Rendezvous Servers . . . . 8 59 5. HIP Extensions for Rendezvous Servers . . . . . . . . . . . . 10 60 5.1 Additional RVS_CAPABLE Control Field . . . . . . . . . . . 10 61 5.2 Additional HIP Parameters . . . . . . . . . . . . . . . . 10 62 5.2.1 RVA_REQUEST Parameter Format and Processing . . . . . 10 63 5.2.2 RVA_REPLY Parameter Format and Processing . . . . . . 12 64 5.2.3 RVA_HMAC Parameter Format and Processing . . . . . . . 12 65 5.2.4 FROM Parameter Format and Processing . . . . . . . . . 13 66 5.2.5 TO Parameter Format and Processing . . . . . . . . . . 14 67 5.2.6 VIA_RVS Parameter Format and Processing . . . . . . . 15 68 5.3 Use of Existing HIP Messages and Parameters . . . . . . . 16 69 5.3.1 ECHO_REQUEST and ECHO_REPLY Parameters . . . . . . . . 16 70 5.3.2 REA Parameter . . . . . . . . . . . . . . . . . . . . 16 71 6. Diagram Notation . . . . . . . . . . . . . . . . . . . . . . . 17 72 7. Establishing Rendezvous Associations . . . . . . . . . . . . . 17 73 8. Establishing HIP Associations via Rendezvous Servers . . . . . 20 74 8.1 Sending a Redirect in Reply to I1 . . . . . . . . . . . . 20 75 8.2 Passing I1 onto an ESP SA . . . . . . . . . . . . . . . . 21 76 8.3 Rewriting I1 Destination IP Address . . . . . . . . . . . 22 77 8.4 Rewriting I1 Source and Destination IP Addresses . . . . . 23 78 8.5 Rewriting I1 and R1 Source and Destination IP Addresses . 24 79 8.6 Cascading Rendezvous Servers . . . . . . . . . . . . . . . 26 80 8.7 Implication on the HIP integrity checks . . . . . . . . . 27 81 8.7.1 Checksum . . . . . . . . . . . . . . . . . . . . . . . 27 82 8.7.2 HMAC and SIGNATURE . . . . . . . . . . . . . . . . . . 27 83 8.7.3 Example . . . . . . . . . . . . . . . . . . . . . . . 28 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 86 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 89 12.2 Informative References . . . . . . . . . . . . . . . . . . . 31 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 91 A. Document Revision History . . . . . . . . . . . . . . . . . . 32 92 Intellectual Property and Copyright Statements . . . . . . . . 33 94 1. Introduction 96 The current Internet uses two global namespaces: domain names and IP 97 addresses. The Domain Name System (DNS) provides a two-way lookup 98 service between the two [1]. Domain names are symbolic identifiers 99 for sets of IP addresses. 101 IP addresses have two uses. First, they are topological locators for 102 network attachment points. Second, they act as names for the 103 attached network interfaces. Saltzer [11] discusses these naming 104 concepts in detail. 106 Routing and other network-layer mechanisms are based on the locator 107 aspects of IP addresses. Transport-layer protocols and mechanisms 108 typically use IP addresses in their role as names for communication 109 endpoints. 111 This dual use of IP addresses limits the flexibility of the Internet 112 architecture. The need to avoid readdressing in order to maintain 113 existing transport-layer connections complicates advanced 114 functionality, such as mobility, multi-homing, or network 115 composition. 117 The Host Identity Protocol (HIP) architecture [2] defines a new third 118 namespace. The Host Identity namespace decouples the name and 119 locator roles currently filled by IP addresses. Instead of mapping 120 domain names directly into IP addresses, HIP maps domain names into 121 Host Identities, and Host Identities into IP addresses. 122 Transport-layer mechanisms operate on Host Identities instead of 123 using IP addresses as endpoint names. Network-layer mechanisms 124 continue to use IP addresses as pure locators. 126 Without HIP, nodes establish transport-layer connections by first 127 looking up the fully-qualified domain name (FQDN) of a peer in the 128 DNS. A successful DNS lookup returns the peer's IP addresses. A 129 node uses one of the returned IP addresses to initiate 130 transport-layer communication with a peer node. 132 HIP nodes will also look up the domain name of desired peers in the 133 DNS, as specified in the HIP DNS Extensions[3]. When a successful 134 lookup includes a peer's Host Identities, HIP nodes perform a HIP 135 Base Exchange before establishing transport-layer connections. The 136 HIP Base Exchange authenticates the end hosts and can bootstrap 137 encryption of the subsequent communication with IPsec [12]. The HIP 138 specification [4] discusses the details of the Base Exchange and the 139 related protocol exchanges. 141 After the Base Exchange, HIP nodes use Host Identities instead of IP 142 addresses for transport-layer connections with a peer. The HIP layer 143 in the network stack internally translates Host Identities (HI) into 144 network-layer IP addresses. This additional mapping between Host 145 Identities and IP addresses (HI->IP) is logically separate from the 146 first mapping between fully-qualified domain names and Host 147 Identities (FQDN->HI). 149 For application and transport-layer compatibility, the FQDN->HI 150 mapping must remain in the DNS. However, the HI->IP mapping is 151 internal to the HIP layer and may be performed in a number of ways. 152 Different lookup mechanism may support communication between two 153 mobile or multi-homed HIP nodes better [5]. 155 2. Terminology 157 Rendezvous Server (RVS): A HIP enabled node which relays incoming HIP 158 I1 packets to the owner of the receiver HIT contained in the I1 159 header. A RVS may also relay back an R1 to an opportunistic 160 Initiator. 162 Rendezvous Association (RVA): A lightweight HIP association 163 established between a HIP node and its RVS. The associated state 164 doesn't require communication to be maintained and contains the 165 peer's HIT, two symmetric integrity keys, and the IP addresses of 166 both nodes. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [6]. 172 3. Communication Between HIP Nodes 174 In the current Internet, the DNS provides a FQDN->IP mapping. With 175 HIP, it must continue to provide a mapping based on domain names. 176 This allows transport-layer connections to bind to Host Identities 177 instead of IP addresses transparently. 179 Instead of mapping domain names directly into IP addresses 180 (FQDN->IP), with HIP the DNS maps them to Host Identities (FQDN->HI). 181 In a second step, another lookup that is internal to the HIP-layer 182 translates the Host Identities into IP addresses for network-layer 183 delivery (HI->IP). 185 Several alternative approaches are possible for maintaining the 186 HI->IP information. The DNS can maintain this mapping along with the 187 FQDN->HI mapping. Alternatively, a database separate from the DNS 188 can manage this information. This section discusses the different 189 approaches and their implications on communication between two HIP 190 nodes. 192 The HIP architecture, protocol and DNS extensions specifications 193 suggest storing Host Identities along with a node's IP addresses in 194 the DNS [3][2][4]. The index for both tables will be domain names. 195 Logically, the DNS will thus contain two separate mappings: FQDN->HI 196 and FQDN->IP. 198 Figure 1 shows the lookup steps and HIP Base Exchange when a node's 199 Host Identities are stored alongside its IP addresses. In step #1, 200 the Initiator I performs a DNS lookup on R's domain name FQDN(R). 201 The DNS server responds with both R's Host Identities HI(R) and its 202 IP addresses IP(R) in step #2 (Details can be found in [4]). 204 The Initiator I uses both pieces of information to perform the HIP 205 Base Exchange with R in step #3. (The details of the Base Exchange, 206 specified in [4], are not relevant to this discussion and will thus 207 be omitted.) 209 #1 FQDN(R) +----------+ 210 +-------------------->| DNS | 211 | +-------------------| | 212 | | #2 HI(R), IP(R) | FQDN->HI | 213 | | | FQDN->IP | 214 | | +----------+ 215 | V 216 +-----+ #3 HIP Base Exchange +-----+ 217 | |-------------------------------->| | 218 | I |<--------------------------------| R | 219 | |-------------------------------->| | 220 | |<--------------------------------| | 221 +-----+ +-----+ 223 Figure 1: HIP Lookup and Base Exchange 225 Note that the DNS does not currently store the HI->IP mapping 226 directly. Instead, a DNS lookup on a domain name returns both its 227 FQDN->HI and FQDN->IP entries. The HIP stack then implicitly 228 constructs the HI->IP mapping based on the HI and IP information 229 returned by the DNS lookup. In the example in Figure 1, the FQDN(R) 230 lookup in step #1 returns both HI(R) and IP(R) in step #2. HIP 231 implicitly constructs the HI(R)->IP(R) mapping based on the 232 assumption that HI(R) is reachable at IP(R). 234 One disadvantage of this approach is that a node's domain name is 235 required to obtain both its Host Identities and its IP addresses. 236 Even if a HIP node already knows the Host Identity of a HIP peer 237 through other means, it cannot currently obtain the peer's IP 238 addresses through the DNS. The DNS does not maintain an explicit 239 HI->IP table, but instead indexes Host Identities only by domain 240 names. 242 A reverse HI->FQDN DNS mapping could address this limitation. HIP 243 nodes would then look up a HIP peer's domain name through its Host 244 Identity. They would then use the returned domain name to find the 245 peer's IP addresses in a second lookup. However, the DNS may not be 246 structurally suited to maintain the reverse HIP->FQDN mapping. As 247 the main Internet-wide database, the DNS is already being overloaded 248 with functionality that might be better handled with new mechanisms 249 [13]. Finally, the additional reverse lookup would increase the 250 latency of the HIP Base Exchange. 252 4. Communication Between Mobile or Multi-Homed HIP Nodes 254 HIP decouples domain names from IP addresses. Because transport 255 protocols bind to Host Identities, they remain unaware if the set of 256 IP addresses associated with a Host Identity changes. This change 257 can have various reasons, including, but not limited to, mobility and 258 multi-homing. 260 Proposed extensions for mobility and multi-homing [5] allow a HIP 261 node to notify its peers about changes in its set of IP addresses. 262 These extensions require an established HIP association between two 263 nodes, i.e., a completed HIP Base Exchange. 265 In addition to notifying its current peers about changes in its IP 266 addresses, a HIP node must also update its HI->IP mapping in response 267 to IP address changes. Otherwise, HIP Base Exchanges from new peers 268 could fail because they try to contact the node at an IP address it 269 is no longer reachable at. 271 4.1 Mobility and Multi-Homing with DNS Updates 273 If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP 274 table, nodes can dynamically update their DNS entry in a secure 275 fashion [7][8]. The DNS server maintaining the information will then 276 sign and distribute the updated zone. 278 #2 FQDN(R) +----------+ 279 +-------------------->| DNS | 280 | +-------------------| |<------+ 281 | | #3 HI(R), IP(R) | FQDN->HI | | #1 Update 282 | | | FQDN->IP | | FQDN(R)->IP(R) 283 | | +----------+ | whenever IP(R) 284 | V | changes. 285 +-----+ #4 HIP Base Exchange +-----+ 286 | |-------------------------------->| | 287 | I |<--------------------------------| R | 288 | |-------------------------------->| | 289 | |<--------------------------------| | 290 +-----+ +-----+ 292 Figure 2: HIP Lookup and Base Exchange with DNS Updates 294 Figure 2 shows an example of this scenario. In step #1, R registers 295 its FQDN(R)->IP(R) entry in the DNS. It will dynamically update the 296 DNS entry whenever its IP addresses IP(R) change. Because the DNS 297 always contains R's current IP addresses, node I can perform a HIP 298 Base Exchange with R at its new IP address (steps #2-4). 300 One drawback of using dynamic DNS updates in this way is the cost of 301 updating secure zones. Re-signing an entire zone whenever the IP 302 addresses of one entry change places a high cost on the DNS server. 303 Using dynamic DNS to update HI->IP mappings may thus not be 304 appropriate when changes of IP addresses are frequent. 306 A simple, operational change could help limit the costs of frequent 307 DNS updates. Instead of recomputing a zone after each dynamic 308 update, a DNS server could aggregate the modifications and only 309 perform zone updates periodically. The disadvantage of this approach 310 is that HIP nodes may be unreachable until the DNS server distributes 311 the updated zone. 313 Another concern with using the DNS to support HIP node mobility is 314 the propagation time of updated DNS entries. DNS servers frequently 315 cache DNS responses to reduce the load on the primary servers. 316 During the time-to-live associated with a DNS response, DNS servers 317 may answer additional requests for the same DNS entry from their 318 local caches instead of contacting the primary servers. Thus, even 319 after a HIP node updates its DNS entry, the DNS can still serve the 320 old entry until the cached responses expire. This can lead to 321 communication problems, because peers may try to contact a HIP node 322 at an IP address it is no longer reachable at. 324 4.2 Mobility and Multi-Homing with Rendezvous Servers 326 The HIP architecture tries to greatly reduce the frequency of Dynamic 327 DNS updates by introducing Rendezvous Servers [2]. Instead of 328 registering its current set of IP addresses in its HI->IP entry in 329 the DNS, a HIP node may instead register the IP addresses of its 330 Rendezvous Servers. Because the IP addresses of Rendezvous Servers 331 are assumed to change only infrequently, this approach can 332 significantly reduce the load on DNS servers. 334 Rendezvous Servers maintain a mapping between the Host Identities of 335 HIP nodes for which they provide service and the node's current IP 336 addresses. HIP nodes must notify their Rendezvous Servers about any 337 changes in their IP addresses. This approach effectively relocates 338 the HI->IP information - and the burden of keeping it current - from 339 the DNS to the Rendezvous Servers. This can reduce update costs 340 under the assumption that Rendezvous Servers provide more efficient 341 ways of maintaining HI->IP tables. 343 When a packet destined for one of its HIP nodes arrives at a 344 Rendezvous Server, it relays the packet to one of the HIP node's 345 current IP addresses. Due to the specifics of the HIP, only the 346 first packet of a HIP Base Exchange will require such relaying [2]. 347 Subsequent packet of the HIP Base Exchange and all further data 348 packets will directly flow between the HIP nodes, bypassing the 349 Rendezvous Server. 351 #3 FQDN(R) +----------+ #2 Register IP(RVS) in 352 +--------------------->| DNS | FQDN(R)->IP(RVS). 353 | +--------------------| |<------------------+ 354 | | #4 HI(R), IP(RVS) | FQDN->HI | | 355 | | | FQDN->IP | | 356 | | +----------+ | 357 | | | 358 | | #1 Update IP(R) in HI(R)->IP(R) | 359 | | +--------+ whenever IP(R) changes. | 360 | | | RVS |<------------------------------+ | 361 | | | | | | 362 | V +->| HI->IP |--+ | | 363 +-----+ | +--------+ | +-----+ 364 | |---+ +------------------------->| | 365 | I | #5 First Message of HIP Base Exchange | R | 366 | | | | 367 | |<--------------------------------------------| | 368 | |-------------------------------------------->| | 369 | |<--------------------------------------------| | 370 +-----+ #6 Remainder of HIP Base Exchange +-----+ 372 Figure 3: HIP Lookup and Base Exchange with Rendezvous Server 374 Figure 3 shows a HIP lookup and Base Exchange involving a Rendezvous 375 Server. Here, HIP node R is using Rendezvous Server RVS. In step 376 #1, it updates RVS with its current IP addresses IP(R). Then, in 377 step #2, R registers the Rendezvous Server's IP addresses IP(RVS) in 378 its FQDN(R)->IP(RVS) DNS entry. 380 In step #3, a second HIP node I issues a DNS lookup on FQDN(R) to 381 obtain R's Host Identities HI(R) and IP addresses. The lookup 382 returns R's Host Identities HI(R) in step #4. The DNS reply also 383 includes the IP addresses of the Rendezvous Server IP(RVS) (instead 384 of IP(R), because R's current addresses are unknown to the DNS.) 386 In step #5, node I initiates the HIP Base Exchange. It addresses the 387 first packet of the HIP Base Exchange to IP(RVS). Upon receipt, the 388 Rendezvous Server relays the packet to one of R's current IP 389 addresses IP(R). The remainder of the HIP Base Exchange then occurs 390 directly between I and R in step #6. 392 When Rendezvous Servers maintain the HI->IP information, they may 393 support more efficient update operations compared to dynamic DNS 394 updates (Section 4.1). Unlike the DNS, Rendezvous Servers do not 395 provide a lookup service. Instead, they use the HI->IP information 396 to actively relay traffic between HIP nodes. 398 This approach changes the role of the IP addresses stored in a DNS 399 entry. Traditionally, nodes were directly reachable at the IP 400 addresses listed in their DNS entry. HIP Rendezvous Server change 401 this basic property by replacing the IP addresses of their client 402 nodes in the DNS with their own. The IP addresses in a DNS entry 403 hence no longer directly designate interfaces of an endpoint. 404 Instead, they identify interfaces of a node that can relay packets to 405 the endpoint. 407 5. HIP Extensions for Rendezvous Servers 409 The following sections describe HIP extensions for communication with 410 Rendezvous Servers. These extensions allow: 412 o A HIP Rendezvous Server to advertise its RVS capabilities to its 413 correspondents. 415 o A HIP node to create a Rendezvous Association (RVA) with its 416 Rendezvous Server, i.e., to register its current set of IP 417 address(es). 419 o Two HIP nodes to establish a HIP Association (HA) between them via 420 one or more Rendezvous Server. 422 5.1 Additional RVS_CAPABLE Control Field 424 RVS mechanisms make use of a new Control Fields in the HIP Control 425 Field: the RVS_CAPABLE Control Field. 427 The RVS_CAPABLE Control Field ("R") allows a Rendezvous Server to 428 advertise its rendezvous capabilities to the HIP nodes it associates 429 with. 431 5.2 Additional HIP Parameters 433 5.2.1 RVA_REQUEST Parameter Format and Processing 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Lifetime | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | RVA Type #1 | RVA Type #2 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | RVA Type #n | padding | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Type 100 447 Length Length in octets, excluding Type, Length and Padding 448 Lifetime This field encode, the desired RVA validity time. 449 RVA Type This field encode, in order of preference, the 450 preferred rendezvous service types. 452 The following RVA Types are defined: 454 Type number RVA Type 455 ----------- -------- 456 0 Reserved by IANA 457 1 I1_REWRITE_DST 458 2 I1_REWRITE_SRCDST 459 3 I1R1_REWRITE_SRCDST 460 4 I1_RELAY_ESP 461 5 I1R1_RELAY_ESP 462 6 REDIRECT 463 6-200 Reserved by IANA 464 201-255 Reserved by IANA for private use 466 When a Rendezvous Association of type I1_* is established between a 467 HIP RVS and its peer, the RVS will relay to the peer all inbound I1s 468 whose Responder HIT match those of the peer. The peer will then 469 reply with a R1 sent directly to the Initiator, without further 470 assistance from the RVS. 472 When a Rendezvous Association of type I1R1_* is established between a 473 HIP RVS and its peer, the RVS will relay to the peer all inbound I1s 474 whose Responder HIT match those of the peer. The peer will then 475 reply with a R1 sent to the Initiator via the RVS, which will relay 476 it to the Initiator. The Initiator will then reply directly to the 477 Responder by sending an I2, without further assistance from the RVS. 479 A RVS relays packet by either rewriting IP addresses in the IP 480 header, or alternatively, if a HIP association is present, by 481 forwarding it into the ESP SA associated with the HIP Association. 483 If the RVA is of type *_REWRITE_*, the IP addresses are rewritten by 484 the RVS. If the RVA type is I1_REWRITE_DST, only the destination IP 485 address of a relayed I1 is rewritten. On the contrary, if the RVA 486 type *_REWRITE_SRCDST, both the source and destination IP addresses 487 are rewritten. In the case of a *_REWRITE_SRCDST, the RVS will need 488 to suffix the HIP header with a FROM parameter preserving the 489 original source IP address of the relayed packet. This FROM, as well 490 as the whole HIP header, is integrity protected by an RVA_HMAC 491 parameter which contains a keyed-HMAC computed over the HIP packet, 492 similarly to what the HMAC parameter already does. 494 5.2.2 RVA_REPLY Parameter Format and Processing 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Lifetime | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | RVA Type #1 | RVA Type #2 | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | RVA Type #n | padding | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Type 102 509 Length Length in octets, excluding Type, Length and Padding 510 Lifetime This field encode the offered RVA validity time 511 RVA Type This field encode, in order of preference, the 512 preferred rendezvous service types (the same 513 type values than RVA_REQUEST parameter are used). 515 5.2.3 RVA_HMAC Parameter Format and Processing 517 The RVA_HMAC is an OPTIONAL parameter whose only difference with the 518 HMAC parameter defined in [4] is the Type code: 520 Type 65320 521 Length 20 522 HMAC 160 low order bits of a HMAC keyed with the appropriate 523 HIP integrity keys (HIP_lg or HIP_gl) of the corresponding 524 Rendezvous Association or HIP Association. This HMAC is 525 computed over the HIP packet excluding RVA_HMAC and any 526 other following parameter. The checksum field MUST be set 527 to zero and the HIP header length in the HIP common header 528 MUST be calculated not to cover any excluded parameter when 529 the Authenticator field is calculated. 531 To allow a HIP node and any of its RVS to verify the integrity of 532 packets flowing between them, both use an RVA_HMAC parameter keyed 533 with a HMAC of HIP_lg and HIP_gl integrity keys. One RVA_HMAC SHOULD 534 be present on every packets flowing between a HIP node and any of its 535 RVS and MUST be present when FROM and TO parameters are processed. 537 On the receiving side, when an RVA_HMAC is validated, it SHOULD be 538 removed from the packet and if so, packet length and checksum MUST be 539 recomputed accordingly. 541 5.2.4 FROM Parameter Format and Processing 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 | Address | 550 | | 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Type 65100 (under signature) or 65300 (after signature) 555 Length 16 556 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 558 A Rendezvous Server MAY add a FROM parameter containing the original 559 source IP address of a HIP packet (I1, R1, I2 or R2) whose source IP 560 address has been rewritten. If one or more FROM parameters are 561 already present, the new FROM parameter MUST be appended after the 562 existing ones. Each time an RVS inserts a FROM parameter, it MUST 563 also insert additional parameters that will be used to validate this 564 and the subsequent HIP packets. These parameters are: 566 o An ECHO_REQUEST, containing a chunk of opaque data allowing to 567 validate, in a possible subsequent answer, a TO parameter which 568 MUST be protected by an ECHO_RESPONSE containing the same opaque 569 data. 571 o A valid RVA_HMAC, protecting the packet integrity. 573 When a HIP node validates a FROM parameter, it is removed from the 574 packet and recorded for later use (i.e., for building the 575 corresponding TO parameter to be piggy-backed onto a subsequent 576 answer). The packet's source IP address is also replaced by the 577 address included in the first occurrence of FROM parameter. 579 For each FROM parameter, a HIP node MAY add to its replies a TO 580 parameter containing the IP address included in the FROM. These 581 replies will be sent via the RVS, which MUST remove the outer TO 582 parameter from the packet and replace its destination address with 583 the address contained in the TO parameter before relaying it. 585 5.2.5 TO Parameter Format and Processing 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type | Length | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 | Address | 594 | | 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Type 65102 (under signature) or 65302 (after signature) 599 Length 16 600 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 602 A HIP node MAY add one or more TO parameter containing the final 603 destination IP address of a HIP packet (I1, R1, I2 or R2) whose 604 destination IP address needs to be rewritten by an RVS. This is 605 essentially equivalent to loose source-routing. If one or more TO 606 parameters are already present, the new TO parameter MUST be appended 607 after the existing ones. Each time a node inserts a TO parameter, it 608 MUST also insert additional parameters that will be used by the RVS 609 for validation. These parameters are: 611 o An ECHO_RESPONSE, containing a chunk of opaque data allowing the 612 RVS to validate the address contained in the TO parameter. 614 o A valid RVA_HMAC, protecting the packet integrity. 616 When the RVS validates a TO parameter, SHALL remove it from the 617 packet, and SHALL replace the packet destination IP address with the 618 address included in the TO parameter. Packet length and checksum 619 MUST then be recomputed accordingly. 621 For each FROM parameter, a HIP node MAY add to its replies a TO 622 parameter containing the IP address included in the FROM. These 623 replies will be sent via the RVS, which MUST remove the outer TO 624 parameter from the packet and replace its destination address field 625 with the address contained in the TO parameter before relaying it. 627 5.2.6 VIA_RVS Parameter Format and Processing 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Type | Length | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | | 635 | Address | 636 | | 637 | | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 . . . 640 . . . 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | | 643 | Address | 644 | | 645 | | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Type 65500 649 Length Variable 650 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 652 At some point a, HIP endpoint might be in position to begin to send 653 HIP packets directly towards the remote HIP endpoint's IP address, 654 without further assistance from one or more of its RVS(s). In that 655 case, it MAY include in these packets a subset of the IP address(es) 656 of its RVSs for debugging purposes. 658 Similarly, a RVS relaying an I1 to the Responder or an R1 to the 659 Initiator MAY include in these packets its IP address for debugging 660 as well. 662 When the IP address of a RVS need to be included in a packet, by 663 either an end-node or the RVS itself, one of these two methods is 664 used: 666 o Add RVS IP address into an existing VIA_RVS parameter situated at 667 the end of the HIP packet, while modifying accordingly the size of 668 the parameter. 670 o Append a newly created VIA_RVS parameter at the end of the HIP 671 packet if it does not already contain a VIA_RVS parameter. 673 Note that the main goal of using the VIA_RVS parameter is to allow 674 operators to diagnose possible issues encountered while establishing 675 a HIP association via a RVS. 677 5.3 Use of Existing HIP Messages and Parameters 679 5.3.1 ECHO_REQUEST and ECHO_REPLY Parameters 681 A FROM parameter MAY be augmented by including an ECHO_REQUEST 682 parameter to the carrying packet. The contents of the ECHO_REQUEST 683 might then be echoed back in ECHO_RESPONSE. 685 A TO parameter SHOULD be augmented and authenticated by including an 686 ECHO_REPLY parameter to the carrying packet. The contents of the 687 ECHO_REPLY MUST be copied from a previously received ECHO_RESPONSE. 689 All the HIP packets requiring RVS relaying facility to carry an 690 answer packet SHOULD be augmented by the RVS with an ECHO_REQUEST 691 parameter. 693 A possible packet answered via the RVS, thus requiring relaying 694 facility, SHOULD be authenticated by an ECHO_REPLY parameter. The 695 contents of the ECHO_REPLY MUST be copied from a previously received 696 ECHO_RESPONSE. 698 On the receiving side, when a HIP node validates an ECHO_REPLY 699 located after the signatures, it MUST remove it from the packet and 700 recompute packet length and checksum accordingly. 702 5.3.2 REA Parameter 704 A HIP node associated via an RVS MAY use a REA parameter to make its 705 correspondent aware of its veritable current IP address. If used, 706 the REA parameter MUST be used in conformance with the guidelines 707 specified in [5]. 709 6. Diagram Notation 711 Notation Significance 712 -------- ------------ 714 I, R I and R are the respective source and destination IP 715 addresses of the IP header 717 HIT-I, HIT-I and HIT-R are respectively the Initiator and the 718 HIT-R Responder HIT of the packet 720 R The RVS_CAPABLE Control Field is set into the Control 721 Field of the HIP header 723 REA:I A REA parameter containing the IP address i is 724 present in the HIP header 726 FROM:I A FROM parameter containing the IP address I is present 727 in the HIP header 729 TO:I A TO parameter containing the IP address I is present 730 in the HIP header 732 VIA:RVS A VIA_RVS parameter containing IP addresses RVS 733 is present in the HIP header 735 REDIR:R A REDIRECT parameter containing IP address R of 736 Responder is present in the HIP header 738 EREQ An ECHO_REQUEST parameter is present in the HIP header 740 EREP An ECHO_REPLY parameter is present in the HIP header 742 RREQ A RVA_REQUEST parameter is present in the HIP header 744 RREP A RVA_REPLY parameter is present in the HIP header 746 7. Establishing Rendezvous Associations 748 A HIP node that wants to register its IP address with its RVS MAY 749 simply establish a HIP association with it. It MUST then keep its IP 750 address current with the server by sending UPDATE packets whenever 751 its set of IP addresses changes. 753 However, for the sake of economizing RVS resources, which can 754 possibly be used by several thousands of different HIP nodes, we 755 define a new sort of "soft state" HIP association called a Rendezvous 756 Association (RVA). In order to maintain this RVA established, a HIP 757 Association need not remain established. 759 A HIP node MAY establish an RVA with its RVS by establishing a HA 760 while adding an RVA_REQUEST parameter in an I2, possibly preceded by 761 an I1 containing the same RVA_REQUEST. The possibility offered to 762 initiate the protocol in I1 allows a HIP node to query a RVS for the 763 set of offered rendezvous service types before completing the 764 establishment of the Rendezvous association (in case the desired 765 service type isn't available on this RVS). A RVS MUST then reply 766 with, respectively, an R2 possibly preceded by an R1, which will both 767 have the RVS_CAPABLE control field set, and contain a RVA_REPLY 768 parameter specifying the characteristics of the offered RVA (validity 769 time, type, etc.). Then, the RVS and the HIP node MAY delete most of 770 the HIP Association state, retaining only the Lifetime, Initiator's 771 HIT and IP address(es), as well as HIP_lg and HIP_gl integrity keys. 773 When a HA is established via an RVS, the integrity of HIP packets 774 flowing between a HIP node and its RVS is protected by an additional 775 RVA_HMAC keyed with these keys. 777 I1(I, RVS, HIT-I, 778 HIT-RVS) +------+ 779 +-------------------------->| | 780 |+--------------------------| | 781 || R1(RVS, I, HIT-RVS, | | 782 || HIT-I, R) | | 783 || | RVS1 | 784 || I2(I, RVS, HIT-I, | | 785 || HIT-RVS, RREQ) | | 786 || +----------------------->| | 787 || |+-----------------------| | 788 || || R2(RVS, I, HIT-RVS, +------+ 789 || || HIT-I, R, RREP) 790 |V |V 791 +-----+ 792 | | 793 | I | 794 | | 795 +-----+ 797 Figure 12: Establishing a Rendezvous Association 799 There is nothing to prevent an RVS node to advertise its RVS 800 capabilities to the peers it associates with, nor to establish an RVA 801 with another RVS. 803 If a HIP node wants to associate with several cascaded Rendezvous 804 Servers RVS_i (0 < i < n+1), it SHALL sequentially create RVAs 805 (RVA_i) with each of them, starting from the "nearest" (RVS_1) to the 806 "farthest" (RVS_n). Apart from RVA_1, a node SHOULD create any such 807 RVA_i (1 < i < n+1) by sending an I1 to RVS_i via each of the RVS 808 which precede it, i.e., RVS_j (1 < j < i). 810 This is achieved by using (i - 1) different TO parameters containing, 811 in order, the IP address of each RVS preceding RVS_i, i.e., RVS_j (1 812 < j < i). This process is similar to IP loose source-routing. 813 Hence, A RVS accepting to be part of a cascade MAY relay an incoming 814 I1 from one its clients to any given address and HIT. Those I1s MUST 815 be protected by a valid RVA_HMAC parameter. 817 I1(I, RVS1, HIT-I, I1(RVS1, RVS2, HIT-I, 818 HIT-RVS2, TO:RVS2) +------+ HIT-RVS2, EREQ1) 819 +-------------------------->| |----------------------------+ 820 |+--------------------------| |<--------------------------+| 821 || R1(RVS1, I, HIT-RVS2, | | R1(RVS2, RVS1, || 822 || HIT-I, R, EREQ1) | | HIT-RVS2, HIT-I, || 823 || | RVS1 | R, EREP1) || 824 || I2(I, RVS1, HIT-I, | | || 825 || HIT-RVS2, RREQ, | | I2(RVS1, RVS2, HIT-I, || 826 || EREP1, TO:RVS2) | | HIT-RVS2, RREQ, EREQ1) || 827 || +----------------------->| |------------------------+ || 828 || |+-----------------------| |<----------------------+| || 829 || || R2(RVS1, I, HIT-RVS2, +------+ R2(RVS2, RVS1, || || 830 || || HIT-I, R, RREP, HIT-RVS2, HIT-I, || || 831 || || EREQ1) R, RREP, EREP1) || || 832 |V |V |V |V 833 +-----+ +------+ 834 | | | | 835 | I | | RVS2 | 836 | | | | 837 +-----+ +------+ 839 Figure 13: Establishing Cascaded Rendezvous Associations 841 8. Establishing HIP Associations via Rendezvous Servers 843 8.1 Sending a Redirect in Reply to I1 845 Instead of having the RVS relay incoming I1s to the correct 846 Responder, one possibility is to answer with a REDIRECT packet when a 847 HIP packet destined for one of the Rendezvous Server's HIP nodes 848 arrives. This REDIRECT packet would contains the IP address and 849 packet signature of the Responder. 851 The Responder cannot sign the redirect packets delivered by the RVS 852 in real time. When the RVA is set up, the Responder sends the signed 853 REDIRECT packet to the RVS, who stores it until the RVA expires. 855 By signing this REDIRECT packet and sending it to the RVS, the 856 Responder is authorizing the Rendezvous Server's IP address to 857 redirect Initiators to the Responder's IP address. The authorization 858 is weak because the subject of the authorization is the IP address 859 which is not bound to the HI of the Responder (similarly to what is 860 described in , the possibility to use CGAs as IP addresses for RVSs 861 might improve authorization security because the RVS might then prove 862 to Initiators ownership of the CGA IP address, and the authorization 863 issued to it to redirect to the Responder's IP address. 865 An implementation of this redirect packet is a R1 packet signed by 866 the Responder, which contains an additional REDIRECT parameter (with 867 the IP address of the Responder, and perhaps a limitation of the 868 REDIRECT validity, like 'not-before' and 'not-after' dates, or hash 869 chains) The RVS redirect an Initiator by replying to an I1 with this 870 REDIRECT R1 in which the receiver HIT field has been field with the 871 HIT of the Initiator. Note that this may expose the Initiator to 872 replay attacks, but this is not very different from the situation 873 where the Initiator receives a signed R1 whose signature also omits 874 Receiver HIT. 876 _____OFFLINE______ 877 R1(R, RVS, HIT-R 878 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-0, REDIR:R) 879 +------------------------| | 880 | | RVS |<-+-+-+-+-+-+-+-+-+-+ 881 | +---------------------| | | 882 | | R1(RVS, I, HIT-R, +---------+ + 883 | V HIT-I, REDIR:RVS->R) | 884 +-----+ I1(I, R, HIT-I, HIT-R) +-----+ 885 | |--------------------------------------------->| | 886 | |<---------------------------------------------| | 887 | I | R1(R, I, HIT-R, HIT-I) | R | 888 | | I2(I, R, HIT-I, HIT-R) | | 889 | |--------------------------------------------->| | 890 | |<---------------------------------------------| | 891 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 893 Figure 14: Initiator redirected by Rendezvous Server with a 894 Responder-signed R1 896 8.2 Passing I1 onto an ESP SA 898 If a HIP node and one of its Rendezvous Servers maintain a HIP 899 Association, the Rendezvous Server MAY tunnel I1s incoming to this 900 node's HIT into the corresponding ESP SA. The main drawbacks of this 901 approach are that, (1) middle-boxes cannot see the encrypted I1 902 passing from an RVS to its clients, and (2) the source IP address of 903 I1 is lost. In particular, (2) implies that the RVS MUST transmit to 904 the Responder the original source IP address by either of the 905 following: 907 o add a FROM parameter to the HIP header 909 o include the whole original IP header in the ESP payload (very 910 similar to ESP tunnel mode) 912 o route back the subsequent R1 via the RVS 914 ESP(RVS, R, 915 I1(I, RVS, HIT-I, 916 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I)) 917 +----------------------->| |--------------------+ 918 | | RVS | | 919 | | | | 920 | +---------+ | 921 | V 922 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS) +-----+ 923 | |<---------------------------------------------| | 924 | | | | 925 | I | I2(I, R, HIT-I, HIT-R) | R | 926 | |--------------------------------------------->| | 927 | |<---------------------------------------------| | 928 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 930 Figure 15: Rendezvous Server Forwarding I1 onto an ESP SA 932 8.3 Rewriting I1 Destination IP Address 934 When a HIP packet destined for one of its HIP nodes arrives at a 935 Rendezvous Server, it relays the packet to one of the HIP node's 936 current IP addresses. In most case, it is expected that only the 937 first packet of a HIP Base Exchange (i.e., I1) will require such 938 relaying [2]. Subsequent packet of the HIP Base Exchange and all 939 further data packets will directly flow between the HIP nodes, 940 bypassing the Rendezvous Server. The RVA established between such a 941 RVS and its peer has type I1_REWRITE_DST. 943 In the simplest case, the Rendezvous Server can relay an I1 towards 944 its true destination by merely replacing the destination IP address 945 of the I1 by one of the destination HIT owner's IP address(es). 946 Note, however, that such I1s might be subject to egress filtering on 947 the Rendezvous Server's network [9], thus causing I1 packet to be 948 dropped (source IP address does not belong to the RVS network). 950 I1(I, R, HIT-I, 951 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I) 952 +----------------------->| |--------------------+ 953 | | RVS | | 954 | | | | 955 | +---------+ | 956 | V 957 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS) +-----+ 958 | |<---------------------------------------------| | 959 | | | | 960 | I | I2(I, R, HIT-I, HIT-R) | R | 961 | |--------------------------------------------->| | 962 | |<---------------------------------------------| | 963 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 965 Figure 16: Rendezvous Server Rewriting I1 Destination IP Address 967 8.4 Rewriting I1 Source and Destination IP Addresses 969 Because of egress filtering, a HIP Rendezvous Server might need to 970 replace the original source IP address of an I1 by its own IP 971 address, thus concealing the Initiator's IP address to the Responder. 973 While this might be desirable, one of the extension described in this 974 document allows a Rendezvous Server to piggy-back incoming HIP 975 packets with an OPTIONAL FROM parameter containing the original 976 source IP address of the packet. A HIP node receiving a packet 977 containing such a FROM parameter has two possibilities for answering 978 back. It might answer an R1 back either: 980 o Directly to the IP address included in the FROM parameter. The 981 RVA established between such a RVS and its peer has type 982 I1_REWRITE_SRCDST. 984 o Via the Rendezvous Server IP address, adding to the R1 HIP header 985 a TO parameter containing the IP address included in the FROM 986 parameter. The RVA established between such a RVS and its peer 987 has type I1R1_REWRITE_SRCDST. 989 I1(I, RVS, HIT-I, 990 I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I, VIA:RVS) 991 +----------------------->| |--------------------+ 992 | | RVS | | 993 | | | | 994 | +---------+ | 995 | V 996 +-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS) +-----+ 997 | |<---------------------------------------------| | 998 | | | | 999 | I | I2(I, R, HIT-I, HIT-R) | R | 1000 | |--------------------------------------------->| | 1001 | |<---------------------------------------------| | 1002 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 1004 Figure 17: I1_REWRITE_SRCDST: Rendezvous Server Rewriting I1 Source 1005 and Destination IP Addresses 1007 8.5 Rewriting I1 and R1 Source and Destination IP Addresses 1009 It might be useful to relay further HIP packets (i.e., R1) via the 1010 RVS. For example, if the Initiator does not know the Responder's 1011 HIT, it will initiate an opportunistic exchange with the Responder 1012 via a RVS. The first problem is for the RVS to forward an I1 which 1013 doesn't have a destination HIT to the correct Responder. 1015 Because an opportunistic Initiator uses the unspecified IPv6 address 1016 (i.e., ::0) as a place-holder for the Responder HIT in I1s it sends, 1017 an RVS cannot use this Responder HIT to demultiplex incoming 1018 "opportunistic" I1s. The only way to properly relay such 1019 Opportunistic I1s is for the RVS to lease per-HIT IP addresses, so 1020 the destination IP addresses of Opportunistic I1s can be used as a 1021 key to find the correct Responder. 1023 In order to avoid trivial spoofing attacks with R1s, a HIP node 1024 receiving an opportunistic I1 from a Rendezvous Server MUST reply 1025 with its R1 via the same Rendezvous Server. Accordingly, an 1026 Initiator who has attempted an opportunistic exchange towards an IP 1027 address (those of the RVS) MUST discards all R1s received in answers 1028 which do not come from the same IP address. When sending the R1 via 1029 the RVS, the Responder MUST initiate the readdressing protocol as 1030 described in [5]. 1032 This restriction is made for security reasons. If the Initiator 1033 receives an R1 directly from the Responder, the only way to find the 1034 appropriate HIP state is to use as a key the RVS's IP address, which 1035 is possibly included in a VIA_RVS parameter. This solution MUST be 1036 avoided because the VIA_RVS parameter is not trusted (The Initiator 1037 doesn't have a priori knowledge of the public key, and the included 1038 RVS IP address hasn't been "validated" by having the routing fabric 1039 delivers the IP header with this address as source). If this 1040 restriction is not made, a passive attacker might easily hijack a HIP 1041 state in I1_SENT state: it would learn a (source,destination) tuple 1042 of IP addresses in a flowing I1, then send to the source address a 1043 self-made R1 with a VIA_RVS parameter containing the destination 1044 address; that's it, the attacker hijacked the I1_SENT state. This an 1045 opportunity for eavesdropping, MitM, as well as DoS attacks. 1047 Because these R1 packets are larger than I1 (they contain public keys 1048 and signatures), the relaying of such packet create an opportunity 1049 for denial of service attacks. To defend against these attacks, the 1050 Rendezvous Server needs to differentiate between legitimate HIP 1051 packets (i.e., I1 and subsequent HIP packets triggered by an I1) and 1052 illegitimate ones. 1054 For the sake of reducing the load incurred on the RVS, an RVS is not 1055 required to keep track of IP addresses and other pieces of state 1056 associated with ongoing HIP exchanges. Such behavior is OPTIONAL. 1057 Instead, the relaying facility MAY make use of ECHO_REQUEST and 1058 ECHO_RESPONSE parameters. 1060 Each time a packet is being relayed, the RVS MAY augment it with an 1061 ECHO_REQUEST parameter containing a chunk of opaque data. The 1062 receiver of such a packet SHOULD augment any packet answering to this 1063 packet with an ECHO_REPLY parameter containing the same chunk of 1064 opaque data. This opaque data allows an RVS to find and validate the 1065 answered packet IP addresses and HITs. When successfully validated, 1066 ECHO_REPLY parameters SHOULD be removed from the packet before 1067 relaying. 1069 I1(I, RVS, I1(RVS, R, HIT-I, HIT-0 1070 HIT-I, HIT-0) +---------+ FROM:I, EREQ) 1071 +-------------------->| |----------------------+ 1072 |+--------------------| |<--------------------+| 1073 || R1(RVS, I, HIT-R, | RVS | R1(R, RVS, HIT-R, || 1074 || HIT-I, REA:R, | | HIT-I, REA:R, || 1075 || VIA:RVS) | | TO:I, EREP) || 1076 || | | || 1077 || +---------+ || 1078 |V |V 1079 +-----+ I2(R, I, HIT-R, HIT-I) +-----+ 1080 | |-------------------------------------------->| | 1081 | |<--------------------------------------------| | 1082 | | R2(I, R, HIT-I, HIT-R) | | 1083 | I | | R | 1084 | | ESP(R, I, SPI-R) | | 1085 | |<--------------------------------------------| | 1086 | |-------------------------------------------->| | 1087 +-----+ ESP(I, R, SPI-I) +-----+ 1089 Figure 18: I1R1_REWRITE_SRCDST: Responder replying via the RVS to an 1090 Opportunistic Initiator 1092 8.6 Cascading Rendezvous Servers 1094 In some situations, it might be useful to use cascaded Rendezvous 1095 Servers to establish RVS associations. A typical scenario would be a 1096 small number of "trusted" Rendezvous Servers and a larger number of 1097 "untrusted" Rendezvous Servers. Only the trusted Rendezvous Servers 1098 are aware of the IP addresses of the Responders. The untrusted 1099 servers know only the IP addresses of other (un)trusted Rendezvous 1100 Servers. Untrusted Rendezvous Servers are changed periodically, in 1101 order to lower the opportunity for flooding-type attacks on their IP 1102 addresses. 1104 In the case of cascaded Rendezvous Servers, the parameters added to 1105 the HIP base exchange, like FROM, TO, VIA_RVS, ECHO_REQUEST/REPLY or 1106 RVA_HMAC, MUST be "aggregated" or "clustered" on a per-type basis. 1107 This means that, when an RVS needs to add onto a HIP packet a 1108 parameter which is already present in it, this parameter MUST be 1109 added just after the existing parameter(s) of the same type. For 1110 instance, a FROM parameter MUST be added just after the existing 1111 FROM(s) parameter(s). The same applies to TO, VIA_RVS, 1112 ECHO_REQUEST/REPLY or RVA_HMAC. 1114 Another solution to cascaded Rendezvous Servers may be to encapsulate 1115 the original packet into a PAYLOAD and then piggy-back it with 1116 additional parameters. This scheme has not been evaluated further. 1118 I1(RVS2, R, HIT-I, 1119 I1(I, RVS, I1(RVS1, RVS2, HIT-R, EREQ1, 1120 HIT-I, HIT-I, HIT-R, EREQ2, FROM:I, 1121 HIT-R) +------+ EREQ1, FROM:I) +------+ FROM:RVS1) 1122 +--------->| |------------------->| |---------+ 1123 | | RVS1 | | RVS2 | | 1124 | +--------| |<-------------------| |<------+ | 1125 | | +------+ R1(RVS2, RVS2, +------+ | | 1126 | | HIT-I, HIT-R, | | 1127 | | EREP1, EREQ2, | | 1128 | | TO:I) | | 1129 | | R1(RVS1, I, HIT-R, R1(R, RVS2, HIT-R, | | 1130 | | HIT-I, REA:R, HIT-I, REA:R, | | 1131 | | EREQ2, EREQ1) EREP1, EREP2, | | 1132 | | TO:I, TO:RVS2) | | 1133 | V | V 1134 +-----+ I2(I, R, HIT-I, HIT-R, EREP2, EREP1) +-----+ 1135 | |-------------------------------------------->| | 1136 | I |<--------------------------------------------| R | 1137 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 1139 Figure 19: Two Cascaded Rendezvous Servers Relaying an I1-R1 Message 1140 Pair 1142 8.7 Implication on the HIP integrity checks 1144 The establishment of HIP associations via one or more Rendezvous 1145 Servers causes HIP packets flowing between the HIP nodes to be 1146 modified during transmission. Several kinds of modifications to both 1147 the IP and HIP headers are possible. The HIP protocol uses two kinds 1148 of packet integrity checks: hop-by-hop and end-to-end. The HIP 1149 checksum is a hop-by-hop check and SHOULD be verified and recomputed 1150 by each of the on-path HIP middle-boxes (e.g., Rendezvous Servers). 1151 The HMAC and SIGNATURE are end-to-end checks and MUST be computed by 1152 the sender and verified by the receiver. 1154 8.7.1 Checksum 1156 The checksum field of a HIP header to be modified MUST be verified 1157 before applying the modification and recomputed accordingly after. 1159 8.7.2 HMAC and SIGNATURE 1161 The HMAC and SIGNATURE field of a HIP header MUST be computed and 1162 verified based on a "sender view" or "receiver view" of the HIP 1163 header. In particular, this implies that SIGNATURE and HMAC MUST NOT 1164 cover FROM and TO parameters added or removed by Rendezvous Servers 1165 and that the HIP pseudo-header used to compute and verify them MUST 1166 contain the IP addresses as seen by the remote HIP peer. In case of 1167 IP address concealment by the RVS, this means that the IP address of 1168 this RVS MUST be used in the pseudo-header in place of the IP address 1169 of the end host it conceals. 1171 8.7.3 Example 1173 Here is an example showing how to compute the different integrity 1174 checks (end-to-end and hop-by-hop) when two Rendezvous Servers are 1175 cascaded and conceals the Responder IP address (packet flowing along 1176 the path I -> RVS1 -> RVS2 -> R) 1178 End-to-end integrity checks: HMAC and SIGNATURE are computed with a 1179 pseudo-header containing RVS1 as a place holder for the destination 1180 IP address, the rationale being that RVS1 is concealing the Responder 1181 IP address. Therefore, R will verify the signature using RVS1 as the 1182 destination IP address in the pseudo-header. 1184 Hop-by-hop integrity checks: Checksum is computed hop-by-hop; first 1185 with I and RVS1, then with RVS1 and RVS2, and finally with RVS2 and 1186 R. 1188 9. Security Considerations 1190 The security aspects of different HIP rendezvous mechanisms are 1191 currently being investigated. This section describes the known 1192 threats introduced by these HIP extensions, and implications on the 1193 overall security of HIP and IP. In particular, the following tries 1194 to show that the extensions described in this document do not 1195 introduce additional threats in the Internet infrastructure. 1197 It is difficult to encompass the whole scope of threats introduced by 1198 Rendezvous Servers because their presence have implications both at 1199 the IP and HIP layer. In particular, the extensions hereby described 1200 might allow for redirection, amplification and reflection attacks at 1201 the IP layer, as well as attacks on the HIP layer itself, for example 1202 Man-in-the-Middle attacks against the cryptographic core-protocol 1203 SIGMA used by HIP. 1205 If an Initiator has an a priori knowledge of the Responder's HI when 1206 it first contacts it via the RVS, it has a means to verify the 1207 signatures in the HIP exchange, thus conforming to the SIGMA protocol 1208 which is resilient to Man-in-the-Middle attacks. 1210 If an Initiator has not an a priori knowledge of the Responder's HI 1211 (so called Opportunistic Initiators), it is almost impossible to 1212 defend the HIP exchange against MitM attacks (cannot authenticate 1213 public keys exchanged). The only solution is to mitigate hijacking 1214 threats on the HIP state by requiring an R1 answering an 1215 Opportunistic I1 to come from the IP address where the I1 was 1216 initially sent. That way we retain a level of security which is 1217 equivalent to what exists today in the Internet: By sending an IP 1218 packet to an IP address, and receiving an answered IP packet from 1219 this same IP address, I know that the routing fabric trusts my 1220 correspondent to be represented by this IP address. While it is true 1221 that such security is weak, it is better than none, and avoids to 1222 introduce additional threats at the IP layer. 1224 10. IANA Considerations 1226 IANA needs to open a new registry for the Rendezvous Association 1227 (RVA) type. Defined RVA types are: 1229 Type number RVA Type 1231 ----------- -------- 1233 0 Reserved by IANA 1235 1 I1_REWRITE_DST 1237 2 I1_REWRITE_SRCDST 1239 3 I1R1_REWRITE_SRCDST 1241 4 I1_RELAY_ESP 1243 5 I1R1_RELAY_ESP 1245 6 REDIRECT 1247 6-200 Reserved by IANA 1249 201-255 Reserved by IANA for private use 1251 Adding new reservations requires IETF consensus RFC2434 [14]. 1253 11. Acknowledgments 1255 The following people have provided thoughtful and helpful discussions 1256 and/or suggestions that have improved this document: Marcus Brunner, 1257 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Simon Schuetz, 1258 Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen 1259 Quittek. 1261 Part of this work is a product of the Ambient Networks project, 1262 partially supported by the European Commission under its Sixth 1263 Framework Programme. It is provided "as is" and without any express 1264 or implied warranties, including, without limitation, the implied 1265 warranties of fitness for a particular purpose. The views and 1266 conclusions contained herein are those of the authors and should not 1267 be interpreted as necessarily representing the official policies or 1268 endorsements, either expressed or implied, of the Ambient Networks 1269 project or the European Commission. 1271 12. References 1273 12.1 Normative References 1275 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 1276 13, RFC 1034, November 1987. 1278 [2] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1279 Architecture", draft-ietf-hip-arch-00 (work in progress), 1280 October 2004. 1282 [3] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) 1283 Domain Name System (DNS) Extensions", draft-ietf-hip-rvs-00 1284 (work in progress), October 2004. 1286 [4] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 1287 Protocol", draft-ietf-hip-base-01 (work in progress), October 1288 2004. 1290 [5] Nikander, P., "End-Host Mobility and Multi-Homing with Host 1291 Identity Protocol", draft-ietf-hip-mm-00 (work in progress), 1292 October 2004. 1294 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1295 Levels", BCP 14, RFC 2119, March 1997. 1297 [7] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1298 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1299 April 1997. 1301 [8] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1302 Update", RFC 3007, November 2000. 1304 [9] Killalea, T., "Recommended Internet Service Provider Security 1305 Services and Procedures", BCP 46, RFC 3013, November 2000. 1307 [10] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1308 Defeating Denial of Service Attacks which employ IP Source 1309 Address Spoofing", BCP 38, RFC 2827, May 2000. 1311 12.2 Informative References 1313 [11] Saltzer, J., "On the Naming and Binding of Network 1314 Destinations", RFC 1498, August 1993. 1316 [12] Kent, S. and R. Atkinson, "Security Architecture for the 1317 Internet Protocol", RFC 2401, November 1998. 1319 [13] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, 1320 February 2003. 1322 [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1323 Considerations Section in RFCs", BCP 26, RFC 2434, October 1324 1998. 1326 [15] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1327 Security Considerations", BCP 72, RFC 3552, July 2003. 1329 Authors' Addresses 1331 Julien Laganier 1332 Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL) 1333 180, Avenue de l'Europe 1334 Saint Ismier CEDEX 38334 1335 FR 1337 Phone: +33 476 188 815 1338 EMail: ju@sun.com 1339 URI: http://research.sun.com/ 1341 Lars Eggert 1342 NEC Network Laboratories 1343 Kurfuersten-Anlage 36 1344 Heidelberg 69115 1345 DE 1347 Phone: +49 6221 90511 43 1348 Fax: +49 6221 90511 55 1349 EMail: lars.eggert@netlab.nec.de 1350 URI: http://www.netlab.nec.de/ 1352 Appendix A. Document Revision History 1354 +-----------+-------------------------------------------------------+ 1355 | Revision | Comments | 1356 +-----------+-------------------------------------------------------+ 1357 | 00 | Compared to draft-eggert-hip-rvs-00: Add | 1358 | | 'Terminology' section. Remove sections about privacy | 1359 | | (goes into the HIP RG RVS draft). Wrote 'Security | 1360 | | Considerations' and 'IANA Considerations' sections. | 1361 | | Add I1/R1 relaying to support Opportunistic | 1362 | | Initiators. Complete REDIRECT packet description. | 1363 | | Compared to draft-eggert-hip-rendezvous-00: Minor | 1364 | | fixes to figures and their descriptive text. Added | 1365 | | RVS protocol specification. Removed sections related | 1366 | | to communications between HIP and non-HIP nodes. Use | 1367 | | boilerplate from RFC 3668. | 1368 +-----------+-------------------------------------------------------+ 1370 Intellectual Property Statement 1372 The IETF takes no position regarding the validity or scope of any 1373 Intellectual Property Rights or other rights that might be claimed to 1374 pertain to the implementation or use of the technology described in 1375 this document or the extent to which any license under such rights 1376 might or might not be available; nor does it represent that it has 1377 made any independent effort to identify any such rights. Information 1378 on the procedures with respect to rights in RFC documents can be 1379 found in BCP 78 and BCP 79. 1381 Copies of IPR disclosures made to the IETF Secretariat and any 1382 assurances of licenses to be made available, or the result of an 1383 attempt made to obtain a general license or permission for the use of 1384 such proprietary rights by implementers or users of this 1385 specification can be obtained from the IETF on-line IPR repository at 1386 http://www.ietf.org/ipr. 1388 The IETF invites any interested party to bring to its attention any 1389 copyrights, patents or patent applications, or other proprietary 1390 rights that may cover technology that may be required to implement 1391 this standard. Please address the information to the IETF at 1392 ietf-ipr@ietf.org. 1394 Disclaimer of Validity 1396 This document and the information contained herein are provided on an 1397 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1398 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1399 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1400 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1401 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1402 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1404 Copyright Statement 1406 Copyright (C) The Internet Society (2004). This document is subject 1407 to the rights, licenses and restrictions contained in BCP 78, and 1408 except as set forth therein, the authors retain all their rights. 1410 Acknowledgment 1412 Funding for the RFC Editor function is currently provided by the 1413 Internet Society.