idnits 2.17.1 draft-ietf-hip-rvs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 627. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 11, 2005) is 6865 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1498' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC3007' is defined on line 557, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: A later version (-09) exists of draft-ietf-hip-dns-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-dns (ref. 'I-D.ietf-hip-dns') == Outdated reference: A later version (-01) exists of draft-koponen-hip-registration-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.koponen-hip-registration' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-02 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-01 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft DoCoMo Euro-Labs 4 Expires: January 12, 2006 L. Eggert 5 NEC 6 July 11, 2005 8 Host Identity Protocol (HIP) Rendezvous Extension 9 draft-ietf-hip-rvs-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 12, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines a rendezvous extension for the Host Identity 43 Protocol (HIP). The rendezvous extension extends HIP and the HIP 44 registration extension for initiating communication between HIP nodes 45 via HIP rendezvous servers. Rendezvous servers improve reachability 46 and operation when HIP nodes are multi-homed or mobile. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 53 3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5 54 3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 5 55 3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 6 56 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7 57 4.1 RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 58 4.2 Parameter Formats and Processing . . . . . . . . . . . . . 7 59 4.2.1 RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 7 60 4.2.2 FROM Parameter . . . . . . . . . . . . . . . . . . . . 8 61 4.2.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9 62 4.3 Modified Packets Processing . . . . . . . . . . . . . . . 9 63 4.3.1 Processing Outgoing I1 Packets . . . . . . . . . . . . 9 64 4.3.2 Processing Incoming I1 packets . . . . . . . . . . . . 10 65 4.3.3 Processing Outgoing R1 Packets . . . . . . . . . . . . 10 66 4.3.4 Processing Incoming R1 packets . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 72 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 74 A. Document Revision History . . . . . . . . . . . . . . . . . . 14 75 Intellectual Property and Copyright Statements . . . . . . . . 15 77 1. Introduction 79 The Host Identity Protocol architecture [I-D.ietf-hip-arch] 80 introduces the rendezvous mechanism to help a HIP node to contact a 81 frequently moving HIP node. The rendezvous mechanism involves a 82 third party, the rendezvous server (RVS), which serves as an initial 83 contact point ("rendezvous point") for its clients. The clients of 84 an RVS are HIP nodes that use the HIP Registration Protocol 85 [I-D.koponen-hip-registration] to register their HIT->IP address 86 mappings with the RVS. After this registration, other HIP nodes can 87 initiate a base exchange using the IP address of the RVS instead of 88 the current IP address of the node they attempt to contact. 89 Essentially, the clients of an RVS become reachable at the RVS' IP 90 addresses. Peers can initiate a HIP base exchange with the IP 91 address of the RVS, which will relay this initial communication such 92 that the base exchange may successfully complete. 94 2. Terminology 96 This section defines terms used throughout the remainder of this 97 specification. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 In addition to the terminology defined in [I-D.koponen-hip- 104 registration], this document defines and uses the following terms: 106 Rendezvous Service 107 A HIP service provided by a rendezvous server to its rendezvous 108 clients. The rendezvous server offers to relay some of the 109 arriving base exchange packets between the initiator and 110 responder. 112 Rendezvous Server (RVS) 113 A HIP registrar providing rendezvous service. 115 Rendezvous Client 116 A HIP requester that has registered for rendezvous service at a 117 rendezvous server. 119 Rendezvous Registration 120 A HIP registration for rendezvous service, established between a 121 rendezvous server and a rendezvous client. 123 3. Overview of Rendezvous Server Operation 125 Figure 1 shows a simple HIP base exchange without a rendezvous 126 server, in which the initiator initiates the exchange directly with 127 the responder by sending an I1 packet to the responder's IP address, 128 as per the HIP base specification [I-D.ietf-hip-base]. 130 +-----+ +-----+ 131 | |-------I1------>| | 132 | I |<------R1-------| R | 133 | |-------I2------>| | 134 | |<------R2-------| | 135 +-----+ +-----+ 137 Figure 1: HIP base exchange without rendezvous server. 139 Proposed extensions for mobility and multi-homing [I-D.ietf-hip-mm] 140 allow a HIP node to notify its peers about changes in its set of IP 141 addresses. These extensions presumes initial reachability of the two 142 nodes with respect to each other. 144 However, such a HIP node MAY also want to be reachable to other 145 future correspondent peers that are unaware of its location change. 146 The HIP architecture [I-D.ietf-hip-arch] introduces rendezvous 147 servers with whom a HIP node MAY register its host identity tags 148 (HITs) and current IP addresses. An RVS relays HIP packets arriving 149 for these HITs to the node's registered IP addresses. When a HIP 150 node has registered with an RVS, it SHOULD record the IP address of 151 its RVS in its DNS record, using the HIPRVS DNS record type defined 152 in [I-D.ietf-hip-dns]. 154 +-----+ 155 +--I1--->| RVS |---I1--+ 156 | +-----+ | 157 | v 158 +-----+ +-----+ 159 | |<------R1-------| | 160 | I |-------I2------>| R | 161 | |<------R2-------| | 162 +-----+ +-----+ 164 Figure 2: HIP base exchange with a rendezvous server. 166 Figure 2 shows a HIP base exchange involving a rendezvous server. It 167 is assumed that HIP node R previously registered its HITs and current 168 IP addresses with the RVS, using the HIP registration protocol 169 [I-D.koponen-hip-registration]. When the initiator I tries to 170 establish contact with the responder R, it must send the I1 of the 171 base exchange either to one of R's IP addresses (if known via DNS or 172 other means) or to one of R's rendezvous servers instead. Here, I 173 obtains the IP address of R's rendezvous server from R's DNS record 174 and then sends the I1 packet of the HIP base exchange to RVS. RVS, 175 noticing that the HIT contained in the arriving I1 packet is not one 176 of its own, MUST check its current registrations to determine if if 177 needs to relay the packets. Here, it determines that the HIT belongs 178 to R and then relays the I1 packet to the registered IP address. R 179 then completes the base exchange without further assistance from RVS 180 by sending an R1 directly to the I's IP address, as obtained from the 181 I1 packet. In this specification the client of the RVS is always the 182 responder. However, there might be reasons to allow a client to 183 initiate a base exchange through its own RVS, like NAT and firewall 184 traversal. This specification does not address such scenarios which 185 should be specified in other documents. 187 3.1 Diagram Notation 189 Notation Significance 190 -------- ------------ 192 I, R I and R are the respective source and destination IP 193 addresses in the IP header. 195 HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the 196 responder's HITs in the packet, respectively. 198 REG_REQ A REG_REQUEST parameter is present in the HIP header. 200 REG_RES A REG_RESPONSE parameter is present in the HIP header. 202 FROM:I A FROM parameter containing the IP address I is 203 present in the HIP header. 205 RVS_HMAC A RVS_HMAC parameter containing a HMAC keyed with the 206 appropriate registration key is present in the HIP 207 header. 209 VIA:RVS A VIA_RVS parameter containing the IP address RVS of a 210 rendezvous server is present in the HIP header. 212 3.2 Rendezvous Client Registration 214 Before a rendezvous server starts to relay HIP packets to a 215 rendezvous client, the rendezvous client needs to register with it to 216 receive rendezvous service by using the HIP registration extension 217 [I-D.koponen-hip-registration] as illustrated in the following 218 schema: 220 +-----+ +-----+ 221 | | I1 | | 222 | |--------------------------->| | 223 | |<---------------------------| | 224 | I | R1(REG_INFO) | RVS | 225 | | I2(REG_REQ) | | 226 | |--------------------------->| | 227 | |<---------------------------| | 228 | | R2(REG_RES) | | 229 +-----+ +-----+ 231 3.3 Relaying the Base Exchange 233 If a HIP node and one of its rendezvous servers have a rendezvous 234 registration, the rendezvous servers relay inbound I1 packets that 235 contain one of the client's HITs by rewriting the IP header. They 236 replace the destination IP address of the I1 packet with one of the 237 IP addresses of the owner of the HIT, i.e., the rendezvous client. 238 They MUST also recompute the IP checksum accordingly. 240 Because of egress filtering on the path from the RVS to the client 241 [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source 242 IP address, i.e., the IP address of I, with one of its own IP 243 addresses. The replacement IP address SHOULD be chosen according to 244 [RFC1122] and, when IPv6 is used, to [RFC3484]. Because this 245 replacement conceals the initiator's IP address, the RVS MUST append 246 a FROM parameter containing the original source IP address of the 247 packet. This FROM parameter MUST be integrity protected by a 248 RVS_HMAC keyed with the corresponding rendezvous registration 249 integrity key [I-D.koponen-hip-registration]. 251 I1(RVS, R, HIT-I, HIT-R 252 I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) 253 +----------------------->| |--------------------+ 254 | | RVS | | 255 | | | | 256 | +---------+ | 257 | V 258 +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ 259 | |<---------------------------------------------| | 260 | | | | 261 | I | I2(I, R, HIT-I, HIT-R) | R | 262 | |--------------------------------------------->| | 263 | |<---------------------------------------------| | 264 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 266 This modification of HIP packets at a rendezvous server can be 267 problematic because the HIP protocol uses integrity checks. Because 268 the I1 does not include HMAC or SIGNATURE parameters, these two end- 269 to-end integrity checks are unaffected by the operation of rendezvous 270 servers. 272 The RVS SHOULD verify the checksum field of an I1 packet before doing 273 any modifications. After modification, it MUST recompute the 274 checksum field using the updated HIP header, which possibly included 275 new FROM and RVS_HMAC parameters, and a pseudo-header containing the 276 updated source and destination IP addresses. This enables the 277 responder to validate the checksum of the I1 packet "as is", without 278 having to parse any FROM parameters. 280 4. Rendezvous Server Extensions 282 The following sections describe extensions to the HIP registration 283 protocol [I-D.koponen-hip-registration], allowing a HIP node to 284 register with a rendezvous server for rendezvous service and notify 285 the RVS aware of changes to its current location. It also describes 286 an extension to the HIP protocol [I-D.ietf-hip-base] itself, allowing 287 establishment of HIP associations via one or more HIP rendezvous 288 server(s). 290 4.1 RENDEZVOUS Registration Type 292 This specification defines an additional registration for the HIP 293 registration protocol [I-D.koponen-hip-registration] that allows 294 registering with a rendezvous server for rendezvous service. 296 Number Registration Type 297 ------ ----------------- 298 1 RENDEZVOUS 300 4.2 Parameter Formats and Processing 302 4.2.1 RVS_HMAC Parameter 304 The RVS_HMAC is a non-critical parameter whose only difference with 305 the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code. 306 This change causes it to be located after the FROM parameter (as 307 opposed to the HMAC): 309 Type [ TBD by IANA (65500 = 2^16 - 2^5 - 2^2) ] 310 Length 20 311 HMAC 160 low order bits of a HMAC keyed with the 312 appropriate HIP integrity key (HIP_lg or HIP_gl), 313 established when rendezvous registration happened. 314 This HMAC is computed over the HIP packet, excluding 315 RVS_HMAC and any following parameters. The 316 "checksum" field MUST be set to zero and the HIP header 317 length in the HIP common header MUST be calculated 318 not to cover any excluded parameter when the 319 "authenticator" field is calculated. 321 To allow a rendezvous client and its RVS to verify the integrity of 322 packets flowing between them, both SHOULD protect packets with an 323 added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity 324 key established while registration occurred. A valid RVS_HMAC SHOULD 325 be present on every packets flowing between a client and a server and 326 MUST be present when a FROM parameters is processed. 328 4.2.2 FROM Parameter 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 | Address | 337 | | 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Type [ TBD by IANA (65498 = 2^16 - 2^5 - 2) ] 342 Length 16 343 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 345 A rendezvous server MUST add a FROM parameter containing the original 346 source IP address of a HIP packet whenever the source IP address in 347 the IP header is rewritten. If one or more FROM parameters are 348 already present, the new FROM parameter MUST be appended after the 349 existing ones. 351 Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC 352 protecting the packet integrity, especially the IP address included 353 in the FROM parameter. 355 4.2.3 VIA_RVS Parameter 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 | Address | 364 | | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 . . . 368 . . . 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 | Address | 372 | | 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Type [ TBD by IANA (65502 = 2^16 - 2^5 + 2) ] 377 Length Variable 378 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address 380 After the responder receives a relayed I1 packet, it can begin to 381 send HIP packets addressed to the initiator's IP address, without 382 further assistance from an RVS. For debugging purposes, it MAY 383 include a subset of the IP addresses of its RVSs in some of these 384 packets. When a responder does so, it MUST append a newly created 385 VIA_RVS parameter at the end of the HIP packet. The main goal of 386 using the VIA_RVS parameter is to allow operators to diagnose 387 possible issues encountered while establishing a HIP association via 388 an RVS. 390 4.3 Modified Packets Processing 392 The following subsections describe the differences of processing of 393 I1 and R1 while a rendezvous server is involved in the base exchange. 395 4.3.1 Processing Outgoing I1 Packets 397 An initiator SHOULD NOT send an opportunistic I1 with a NULL 398 destination HIT to an IP address which is known to be a rendezvous 399 server address, unless it wants to establish a HIP association with 400 the rendezvous server itself and does not know its HIT. 402 When an RVS rewrites the source IP address of an I1 packet due to 403 egress filtering, it MUST add a FROM parameter to the I1 that 404 contains the initiator's source IP address. This FROM parameter MUST 405 be protected by an RVS_HMAC keyed with the integrity key established 406 at rendezvous registration. 408 4.3.2 Processing Incoming I1 packets 410 When a rendezvous server receives an I1 whose destination HIT is not 411 its own, it consults its registration database to find a registration 412 for the rendezvous service established by the HIT owner. If it finds 413 an appropriate registration, it relays the packet to the registered 414 IP address. If it does not find an appropriate registration, it 415 drops the packet. 417 A rendezvous server SHOULD interpret any incoming opportunistic I1 418 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to 419 itself and SHOULD NOT attempt to relay it to one of its clients. 421 When a rendezvous client receives an I1, it MUST validate any present 422 RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet 423 SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM 424 parameter is present, the packet MUST be dropped. 426 A rendezvous client acting as responder SHOULD drop opportunistic I1s 427 that include a FROM parameter, because this indicates that the I1 has 428 been relayed. 430 4.3.3 Processing Outgoing R1 Packets 432 When a responder replies to an I1 relayed via an RVS, it MUST append 433 to the regular R1 header a VIA_RVS parameter containing the IP 434 addresses of the traversed RVS's. 436 4.3.4 Processing Incoming R1 packets 438 The HIP base specification [I-D.ietf-hip-base] mandates that a system 439 receiving an R1 MUST first check to see if it has sent an I1 to the 440 originator of the R1 (i.e., it is in state I1-SENT). When the R1 is 441 replying to a relayed I1, this check SHOULD be based on HITs only. 442 In case the IP addresses are also checked, then the source IP address 443 MUST be checked against the IP address included in the VIA_RVS 444 parameter. 446 5. Security Considerations 448 This section discusses the known threats introduced by these HIP 449 extensions and implications on the overall security of HIP. In 450 particular, it argues that the extensions described in this document 451 do not introduce additional threats to the Host Identity Protocol. 453 It is difficult to encompass the whole scope of threats introduced by 454 rendezvous servers, because their presence has implications both at 455 the IP and HIP layers. In particular, these extensions might allow 456 for redirection, amplification and reflection attacks at the IP 457 layer, as well as attacks on the HIP layer itself, for example, man- 458 in-the-middle attacks against the HIP base exchange. 460 If an initiator has a priori knowledge of the responder's host 461 identity when it first contacts it via an RVS, it has a means to 462 verify the signatures in the HIP base exchange, which is known to be 463 thus resilient to man-in-the-middle attacks. 465 If an initiator does not have a priori knowledge of the responder's 466 host identity (so-called "opportunistic initiators"), it is almost 467 impossible to defend the HIP exchange against these attacks, because 468 the public keys exchanged cannot be authenticated. The only approach 469 would be to mitigate hijacking threats on HIP state by requiring an 470 R1 answering an opportunistic I1 to come from the same IP address 471 that originally sent the I1. This procedure retains a level of 472 security which is equivalent to what exists in the Internet today. 474 However, for reasons of simplicity, this specification does not allow 475 to establish a HIP association via a rendezvous server in an 476 opportunistic manner. 478 6. IANA Considerations 480 This section is to be interpreted according to [RFC2434]. 482 This document updates the IANA Registry for HIP Parameters Types by 483 assigning new HIP Parameter Types values for the new HIP Parameters 484 defined in Section 4.2: 486 o RVS_HMAC (defined in Section 4.2.1) 488 o FROM (defined in Section 4.2.2) 490 o VIA_RVS (defined in Section 4.2.3) 492 7. Acknowledgments 494 The following people have provided thoughtful and helpful discussions 495 and/or suggestions that have improved this document: Marcus Brunner, 496 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino 497 Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin 498 Stiemerling and Juergen Quittek. 500 Julien Laganier and Lars Eggert are partly funded by Ambient 501 Networks, a research project supported by the European Commission 502 under its Sixth Framework Program. The views and conclusions 503 contained herein are those of the authors and should not be 504 interpreted as necessarily representing the official policies or 505 endorsements, either expressed or implied, of the Ambient Networks 506 project or the European Commission. 508 8. References 510 8.1 Normative References 512 [I-D.ietf-hip-base] 513 Moskowitz, R., "Host Identity Protocol", 514 draft-ietf-hip-base-03 (work in progress), June 2005. 516 [I-D.ietf-hip-dns] 517 Nikander, P. and J. Laganier, "Host Identity Protocol 518 (HIP) Domain Name System (DNS) Extensions", 519 draft-ietf-hip-dns-01 (work in progress), February 2005. 521 [I-D.koponen-hip-registration] 522 Koponen, T. and L. Eggert, "Host Identity Protocol (HIP) 523 Registration Extension", draft-koponen-hip-registration-00 524 (work in progress), February 2005. 526 [RFC1122] Braden, R., "Requirements for Internet Hosts - 527 Communication Layers", STD 3, RFC 1122, October 1989. 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, March 1997. 532 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 533 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 534 October 1998. 536 [RFC3484] Draves, R., "Default Address Selection for Internet 537 Protocol version 6 (IPv6)", RFC 3484, February 2003. 539 8.2 Informative References 541 [I-D.ietf-hip-arch] 542 Moskowitz, R., "Host Identity Protocol Architecture", 543 draft-ietf-hip-arch-02 (work in progress), January 2005. 545 [I-D.ietf-hip-mm] 546 Nikander, P., "End-Host Mobility and Multi-Homing with 547 Host Identity Protocol", draft-ietf-hip-mm-01 (work in 548 progress), February 2005. 550 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 551 Destinations", RFC 1498, August 1993. 553 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 554 Defeating Denial of Service Attacks which employ IP Source 555 Address Spoofing", BCP 38, RFC 2827, May 2000. 557 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 558 Update", RFC 3007, November 2000. 560 [RFC3013] Killalea, T., "Recommended Internet Service Provider 561 Security Services and Procedures", BCP 46, RFC 3013, 562 November 2000. 564 Authors' Addresses 566 Julien Laganier 567 DoCoMo Communications Laboratories Europe GmbH 568 Landsberger Strasse 312 569 Munich 80687 570 Germany 572 Phone: +49 89 56824 231 573 Email: julien.ietf@laposte.net 574 URI: http://www.docomolab-euro.com/ 576 Lars Eggert 577 NEC Network Laboratories 578 Kurfuerstenanlage 36 579 Heidelberg 69115 580 Germany 582 Phone: +49 6221 90511 43 583 Fax: +49 6221 90511 55 584 Email: lars.eggert@netlab.nec.de 585 URI: http://www.netlab.nec.de/ 587 Appendix A. Document Revision History 589 +-----------+-------------------------------------------------------+ 590 | Revision | Comments | 591 +-----------+-------------------------------------------------------+ 592 | 03 | Removed architectural discussions. Fixed some | 593 | | requirements keywords. | 594 | 02 | Removed multiple relaying techniques but simple I1 | 595 | | header rewriting. Updated new HIP parameters type | 596 | | numbers (consistent with new layout and assigning | 597 | | rules from draft-ietf-hip-base.) Updated IANA | 598 | | Considerations. | 599 | 01 | Splitted out the registration sub-protocol. Simplify | 600 | | typology of relaying techniques (keep only TUNNEL, | 601 | | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. | 602 | 00 | Initial version as a HIP WG item. | 603 +-----------+-------------------------------------------------------+ 605 Intellectual Property Statement 607 The IETF takes no position regarding the validity or scope of any 608 Intellectual Property Rights or other rights that might be claimed to 609 pertain to the implementation or use of the technology described in 610 this document or the extent to which any license under such rights 611 might or might not be available; nor does it represent that it has 612 made any independent effort to identify any such rights. Information 613 on the procedures with respect to rights in RFC documents can be 614 found in BCP 78 and BCP 79. 616 Copies of IPR disclosures made to the IETF Secretariat and any 617 assurances of licenses to be made available, or the result of an 618 attempt made to obtain a general license or permission for the use of 619 such proprietary rights by implementers or users of this 620 specification can be obtained from the IETF on-line IPR repository at 621 http://www.ietf.org/ipr. 623 The IETF invites any interested party to bring to its attention any 624 copyrights, patents or patent applications, or other proprietary 625 rights that may cover technology that may be required to implement 626 this standard. Please address the information to the IETF at 627 ietf-ipr@ietf.org. 629 Disclaimer of Validity 631 This document and the information contained herein are provided on an 632 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 633 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 634 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 635 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 636 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 637 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 639 Copyright Statement 641 Copyright (C) The Internet Society (2005). This document is subject 642 to the rights, licenses and restrictions contained in BCP 78, and 643 except as set forth therein, the authors retain all their rights. 645 Acknowledgment 647 Funding for the RFC Editor function is currently provided by the 648 Internet Society.