idnits 2.17.1 draft-ietf-hip-rfc5204-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5204, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2010) is 4991 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) ** Obsolete normative reference: RFC 5205 (Obsoleted by RFC 8005) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft QUALCOMM Inc. 4 Obsoletes: 5204 (if approved) L. Eggert 5 Intended status: Standards Track Nokia 6 Expires: February 21, 2011 August 20, 2010 8 Host Identity Protocol (HIP) Rendezvous Extension 9 draft-ietf-hip-rfc5204-bis-00 11 Abstract 13 This document defines a rendezvous extension for the Host Identity 14 Protocol (HIP). The rendezvous extension extends HIP and the HIP 15 registration extension for initiating communication between HIP nodes 16 via HIP rendezvous servers. Rendezvous servers improve reachability 17 and operation when HIP nodes are multi-homed or mobile. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 21, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 56 3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 5 58 3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6 59 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7 60 4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 61 4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8 62 4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8 63 4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9 64 4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10 65 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10 66 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10 67 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11 68 4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11 69 4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 The Host Identity Protocol (HIP) Architecture [RFC4423] introduces 80 the rendezvous mechanism to help a HIP node to contact a frequently 81 moving HIP node. The rendezvous mechanism involves a third party, 82 the rendezvous server (RVS), which serves as an initial contact point 83 ("rendezvous point") for its clients. The clients of an RVS are HIP 84 nodes that use the HIP Registration Extension [RFC5203] to register 85 their HIT->IP address mappings with the RVS. After this 86 registration, other HIP nodes can initiate a base exchange using the 87 IP address of the RVS instead of the current IP address of the node 88 they attempt to contact. Essentially, the clients of an RVS become 89 reachable at the RVS's IP address. Peers can initiate a HIP base 90 exchange with the IP address of the RVS, which will relay this 91 initial communication such that the base exchange may successfully 92 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 the HIP specification 104 [RFC5201] and the HIP Registration Extension [RFC5203], this document 105 defines and uses the following terms: 107 Rendezvous Service 108 A HIP service provided by a rendezvous server to its rendezvous 109 clients. The rendezvous server offers to relay some of the 110 arriving base exchange packets between the initiator and 111 responder. 113 Rendezvous Server (RVS) 114 A HIP registrar providing rendezvous service. 116 Rendezvous Client 117 A HIP requester that has registered for rendezvous service at a 118 rendezvous server. 120 Rendezvous Registration 121 A HIP registration for rendezvous service, established between a 122 rendezvous server and a rendezvous client. 124 3. Overview of Rendezvous Server Operation 126 Figure 1 shows a simple HIP base exchange without a rendezvous 127 server, in which the initiator initiates the exchange directly with 128 the responder by sending an I1 packet to the responder's IP address, 129 as per the HIP specification [RFC5201]. 131 +-----+ +-----+ 132 | |-------I1------>| | 133 | I |<------R1-------| R | 134 | |-------I2------>| | 135 | |<------R2-------| | 136 +-----+ +-----+ 138 Figure 1: HIP base exchange without rendezvous server. 140 The End-Host Mobility and Multihoming with the Host Identity 141 Protocol specification [RFC5206] allows a HIP node to notify its 142 peers about changes in its set of IP addresses. This specification 143 presumes initial reachability of the two nodes with respect to each 144 other. 146 However, such a HIP node MAY also want to be reachable to other 147 future correspondent peers that are unaware of its location change. 148 The HIP Architecture [RFC4423] introduces rendezvous servers with 149 whom a HIP node MAY register its host identity tags (HITs) and 150 current IP addresses. An RVS relays HIP packets arriving for these 151 HITs to the node's registered IP addresses. When a HIP node has 152 registered with an RVS, it SHOULD record the IP address of its RVS in 153 its DNS record, using the HIP DNS resource record type defined in the 154 HIP DNS Extension [RFC5205]. 156 +-----+ 157 +--I1--->| RVS |---I1--+ 158 | +-----+ | 159 | v 160 +-----+ +-----+ 161 | |<------R1-------| | 162 | I |-------I2------>| R | 163 | |<------R2-------| | 164 +-----+ +-----+ 166 Figure 2: HIP base exchange with a rendezvous server. 168 Figure 2 shows a HIP base exchange involving a rendezvous server. It 169 is assumed that HIP node R previously registered its HITs and current 170 IP addresses with the RVS, using the HIP Registration Extension 171 [RFC5203]. When the initiator I tries to establish contact with the 172 responder R, it must send the I1 of the base exchange either to one 173 of R's IP addresses (if known via DNS or other means) or to one of 174 R's rendezvous servers. Here, I obtains the IP address of R's 175 rendezvous server from R's DNS record and then sends the I1 packet of 176 the HIP base exchange to RVS. RVS, noticing that the HIT contained 177 in the arriving I1 packet is not one of its own, MUST check its 178 current registrations to determine if it needs to relay the packets. 179 Here, it determines that the HIT belongs to R and then relays the I1 180 packet to the registered IP address. R then completes the base 181 exchange without further assistance from RVS by sending an R1 182 directly to the I's IP address, as obtained from the I1 packet. In 183 this specification, the client of the RVS is always the responder. 184 However, there might be reasons to allow a client to initiate a base 185 exchange through its own RVS, like NAT and firewall traversal. This 186 specification does not address such scenarios, which should be 187 specified in other documents. 189 3.1. Diagram Notation 191 Notation Significance 192 -------- ------------ 194 I, R I and R are the respective source and destination IP 195 addresses in the IP header. 197 HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the 198 responder's HITs in the packet, respectively. 200 REG_REQ A REG_REQUEST parameter is present in the HIP header. 202 REG_RES A REG_RESPONSE parameter is present in the HIP header. 204 FROM:I A FROM parameter containing the IP address I is 205 present in the HIP header. 207 RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with the 208 appropriate registration key is present in the HIP 209 header. 211 VIA:RVS A VIA_RVS parameter containing the IP address RVS of a 212 rendezvous server is present in the HIP header. 214 3.2. Rendezvous Client Registration 216 Before a rendezvous server starts to relay HIP packets to a 217 rendezvous client, the rendezvous client needs to register with it to 218 receive rendezvous service by using the HIP Registration Extension 219 [RFC5203] as illustrated in the following schema: 221 +-----+ +-----+ 222 | | I1 | | 223 | |--------------------------->| | 224 | |<---------------------------| | 225 | I | R1(REG_INFO) | RVS | 226 | | I2(REG_REQ) | | 227 | |--------------------------->| | 228 | |<---------------------------| | 229 | | R2(REG_RES) | | 230 +-----+ +-----+ 232 Rendezvous client registering with a rendezvous server. 234 3.3. Relaying the Base Exchange 236 If a HIP node and one of its rendezvous servers have a rendezvous 237 registration, the rendezvous servers relay inbound I1 packets (that 238 contain one of the client's HITs) by rewriting the IP header. They 239 replace the destination IP address of the I1 packet with one of the 240 IP addresses of the owner of the HIT, i.e., the rendezvous client. 241 They MUST also recompute the IP checksum accordingly. 243 Because of egress filtering on the path from the RVS to the client 244 [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source 245 IP address, i.e., the IP address of I, with one of its own IP 246 addresses. The replacement IP address SHOULD be chosen according to 247 relevant IPv4 and IPv6 specifications [RFC1122][RFC3484]. Because 248 this replacement conceals the initiator's IP address, the RVS MUST 249 append a FROM parameter containing the original source IP address of 250 the packet. This FROM parameter MUST be integrity protected by an 251 RVS_HMAC keyed with the corresponding rendezvous registration 252 integrity key [RFC5203]. 254 I1(RVS, R, HIT-I, HIT-R 255 I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) 256 +----------------------->| |--------------------+ 257 | | RVS | | 258 | | | | 259 | +---------+ | 260 | V 261 +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ 262 | |<---------------------------------------------| | 263 | | | | 264 | I | I2(I, R, HIT-I, HIT-R) | R | 265 | |--------------------------------------------->| | 266 | |<---------------------------------------------| | 267 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 269 Rendezvous server rewriting IP addresses. 271 This modification of HIP packets at a rendezvous server can be 272 problematic because the HIP protocol uses integrity checks. Because 273 the I1 does not include HMAC or SIGNATURE parameters, these two end- 274 to-end integrity checks are unaffected by the operation of rendezvous 275 servers. 277 The RVS SHOULD verify the checksum field of an I1 packet before doing 278 any modifications. After modification, it MUST recompute the 279 checksum field using the updated HIP header, which possibly included 280 new FROM and RVS_HMAC parameters, and a pseudo-header containing the 281 updated source and destination IP addresses. This enables the 282 responder to validate the checksum of the I1 packet "as is", without 283 having to parse any FROM parameters. 285 4. Rendezvous Server Extensions 287 This section describes extensions to the HIP Registration Extension 288 [RFC5203], allowing a HIP node to register with a rendezvous server 289 for rendezvous service and notify the RVS aware of changes to its 290 current location. It also describes an extension to the HIP 291 specification [RFC5201] itself, allowing establishment of HIP 292 associations via one or more HIP rendezvous server(s). 294 4.1. RENDEZVOUS Registration Type 296 This specification defines an additional registration for the HIP 297 Registration Extension [RFC5203] that allows registering with a 298 rendezvous server for rendezvous service. 300 Number Registration Type 301 ------ ----------------- 302 1 RENDEZVOUS 304 4.2. Parameter Formats and Processing 306 4.2.1. RVS_HMAC Parameter 308 The RVS_HMAC is a non-critical parameter whose only difference with 309 the HMAC parameter defined in the HIP specification [RFC5201] is its 310 "type" code. This change causes it to be located after the FROM 311 parameter (as opposed to the HMAC): 313 Type 65500 314 Length Variable. Length in octets, excluding Type, Length, and 315 Padding. 316 HMAC HMAC computed over the HIP packet, excluding the 317 RVS_HMAC parameter and any following parameters. The 318 HMAC is keyed with the appropriate HIP integrity key 319 (HIP-lg or HIP-gl) established when rendezvous 320 registration happened. The HIP "checksum" field MUST be set 321 to zero, and the HIP header length in the HIP common header 322 MUST be calculated not to cover any excluded parameter 323 when the HMAC is calculated. The size of the 324 HMAC is the natural size of the hash computation 325 output depending on the used hash function. 327 To allow a rendezvous client and its RVS to verify the integrity of 328 packets flowing between them, both SHOULD protect packets with an 329 added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity 330 key established while registration occurred. A valid RVS_HMAC SHOULD 331 be present on every packet flowing between a client and a server and 332 MUST be present when a FROM parameter is processed. 334 4.2.2. FROM Parameter 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | 342 | Address | 343 | | 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Type 65498 348 Length 16 349 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 351 A rendezvous server MUST add a FROM parameter containing the original 352 source IP address of a HIP packet whenever the source IP address in 353 the IP header is rewritten. If one or more FROM parameters are 354 already present, the new FROM parameter MUST be appended after the 355 existing ones. 357 Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC 358 protecting the packet integrity, especially the IP address included 359 in the FROM parameter. 361 4.2.3. VIA_RVS Parameter 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 | Address | 370 | | 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 . . . 374 . . . 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 | Address | 378 | | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Type 65502 383 Length Variable 384 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 386 After the responder receives a relayed I1 packet, it can begin to 387 send HIP packets addressed to the initiator's IP address, without 388 further assistance from an RVS. For debugging purposes, it MAY 389 include a subset of the IP addresses of its RVSs in some of these 390 packets. When a responder does so, it MUST append a newly created 391 VIA_RVS parameter at the end of the HIP packet. The main goal of 392 using the VIA_RVS parameter is to allow operators to diagnose 393 possible issues encountered while establishing a HIP association via 394 an RVS. 396 4.3. Modified Packets Processing 398 The following subsections describe the differences of processing of 399 I1 and R1 while a rendezvous server is involved in the base exchange. 401 4.3.1. Processing Outgoing I1 Packets 403 An initiator SHOULD NOT send an opportunistic I1 with a NULL 404 destination HIT to an IP address that is known to be a rendezvous 405 server address, unless it wants to establish a HIP association with 406 the rendezvous server itself and does not know its HIT. 408 When an RVS rewrites the source IP address of an I1 packet due to 409 egress filtering, it MUST add a FROM parameter to the I1 that 410 contains the initiator's source IP address. This FROM parameter MUST 411 be protected by an RVS_HMAC keyed with the integrity key established 412 at rendezvous registration. 414 4.3.2. Processing Incoming I1 Packets 416 When a rendezvous server receives an I1 whose destination HIT is not 417 its own, it consults its registration database to find a registration 418 for the rendezvous service established by the HIT owner. If it finds 419 an appropriate registration, it relays the packet to the registered 420 IP address. If it does not find an appropriate registration, it 421 drops the packet. 423 A rendezvous server SHOULD interpret any incoming opportunistic I1 424 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to 425 itself and SHOULD NOT attempt to relay it to one of its clients. 427 When a rendezvous client receives an I1, it MUST validate any present 428 RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet 429 SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM 430 parameter is present, the packet MUST be dropped. 432 A rendezvous client acting as responder SHOULD drop opportunistic I1s 433 that include a FROM parameter, because this indicates that the I1 has 434 been relayed. 436 4.3.3. Processing Outgoing R1 Packets 438 When a responder replies to an I1 relayed via an RVS, it MUST append 439 to the regular R1 header a VIA_RVS parameter containing the IP 440 addresses of the traversed RVSs. 442 4.3.4. Processing Incoming R1 Packets 444 The HIP specification [RFC5201] mandates that a system receiving an 445 R1 MUST first check to see if it has sent an I1 to the originator of 446 the R1 (i.e., the system is in state I1-SENT). When the R1 is 447 replying to a relayed I1, this check SHOULD be based on HITs only. 448 In case the IP addresses are also checked, then the source IP address 449 MUST be checked against the IP address included in the VIA_RVS 450 parameter. 452 5. Security Considerations 454 This section discusses the known threats introduced by these HIP 455 extensions and the implications on the overall security of HIP. In 456 particular, it argues that the extensions described in this document 457 do not introduce additional threats to the Host Identity Protocol. 459 It is difficult to encompass the whole scope of threats introduced by 460 rendezvous servers because their presence has implications both at 461 the IP and HIP layers. In particular, these extensions might allow 462 for redirection, amplification, and reflection attacks at the IP 463 layer, as well as attacks on the HIP layer itself, for example, man- 464 in-the-middle attacks against the HIP base exchange. 466 If an initiator has a priori knowledge of the responder's host 467 identity when it first contacts the responder via an RVS, it has a 468 means to verify the signatures in the HIP base exchange, which 469 protects against man-in-the-middle attacks. 471 If an initiator does not have a priori knowledge of the responder's 472 host identity (so-called "opportunistic initiators"), it is almost 473 impossible to defend the HIP exchange against these attacks, because 474 the public keys exchanged cannot be authenticated. The only approach 475 would be to mitigate hijacking threats on HIP state by requiring an 476 R1 answering an opportunistic I1 to come from the same IP address 477 that originally sent the I1. This procedure retains a level of 478 security that is equivalent to what exists in the Internet today. 480 However, for reasons of simplicity, this specification does not allow 481 the establishment of a HIP association via a rendezvous server in an 482 opportunistic manner. 484 6. IANA Considerations 486 This section is to be interpreted according to the Guidelines for 487 Writing an IANA Considerations Section in RFCs [RFC2434]. 489 This document updates the IANA Registry for HIP Parameters Types by 490 assigning new HIP Parameter Types values for the new HIP Parameters 491 defined in Section 4.2: 493 o RVS_HMAC (defined in Section 4.2.1) 495 o FROM (defined in Section 4.2.2) 497 o VIA_RVS (defined in Section 4.2.3) 498 This document defines an additional registration for the HIP 499 Registration Extension [RFC5203] that allows registering with a 500 rendezvous server for rendezvous service. 502 Number Registration Type 503 ------ ----------------- 504 1 RENDEZVOUS 506 7. Acknowledgments 508 The following people have provided thoughtful and helpful discussions 509 and/or suggestions that have improved this document: Marcus Brunner, 510 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino 511 Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin 512 Stiemerling, and Juergen Quittek. 514 8. References 516 8.1. Normative References 518 [RFC1122] Braden, R., "Requirements for Internet Hosts - 519 Communication Layers", STD 3, RFC 1122, October 1989. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 525 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 526 October 1998. 528 [RFC3484] Draves, R., "Default Address Selection for Internet 529 Protocol version 6 (IPv6)", RFC 3484, February 2003. 531 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 532 Henderson, "Host Identity Protocol", RFC 5201, April 2008. 534 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 535 Protocol (HIP) Registration Extension", RFC 5203, 536 April 2008. 538 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 539 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 540 April 2008. 542 8.2. Informative References 544 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 545 Defeating Denial of Service Attacks which employ IP Source 546 Address Spoofing", BCP 38, RFC 2827, May 2000. 548 [RFC3013] Killalea, T., "Recommended Internet Service Provider 549 Security Services and Procedures", BCP 46, RFC 3013, 550 November 2000. 552 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 553 (HIP) Architecture", RFC 4423, May 2006. 555 [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming 556 with the Host Identity Protocol", RFC 5206, April 2008. 558 Authors' Addresses 560 Julien Laganier 561 QUALCOMM Incorporated 562 5775 Morehouse Drive 563 San Diego, CA 92121 564 USA 566 Phone: +1 858 858 3538 567 EMail: julienl@qualcomm.com 569 Lars Eggert 570 Nokia Research Center 571 P.O. Box 407 572 Nokia Group 00045 573 Finland 575 Phone: +358 50 48 24461 576 EMail: lars.eggert@nokia.com 577 URI: http://research.nokia.com/people/lars_eggert/