idnits 2.17.1 draft-bagnulo-lisp-threat-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 652. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 8, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft Huawei Lab at UC3M 4 Intended status: Informational July 8, 2007 5 Expires: January 9, 2008 7 Preliminary LISP Threat Analysis 8 draft-bagnulo-lisp-threat-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 9, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document performs a preliminary threat analysis on the 42 Locator/ID Separation Protocol (LISP) as defined in 43 draft-farinacci-lisp-01.txt. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Application Scenario . . . . . . . . . . . . . . . . . . . . . 3 49 3. Threat analysis . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.1. Identity hijacking . . . . . . . . . . . . . . . . . . . . 5 51 3.1.1. Attacks using the LISP data packets to create state . 5 52 3.1.2. Attacks using the Map-Reply message to create state . 10 53 3.2. DoS attacks . . . . . . . . . . . . . . . . . . . . . . . 12 54 3.2.1. Flooding a third party . . . . . . . . . . . . . . . . 12 55 3.2.2. Preventing future communications . . . . . . . . . . . 13 56 3.2.3. Interrupt ongoing communication . . . . . . . . . . . 13 57 3.2.4. DoS attacks against LISP infrastructure . . . . . . . 13 58 4. Security considerations . . . . . . . . . . . . . . . . . . . 14 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 60 6. Normative References . . . . . . . . . . . . . . . . . . . . . 14 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 Intellectual Property and Copyright Statements . . . . . . . . . . 16 64 1. Introduction 66 The Locator/ID Separation Protocol (LISP) is defined in 67 draft-farinacci-lisp-01.txt [1]. The goal of this document is to 68 identify the different threats in the current LISP protocol in order 69 to understand the current level of protection of the LISP protocol 70 and identify additional security mechanisms that are needed to 71 protect it. 73 As in any ID/loc split approach, the critical operation is the 74 creation of ID to locator binding state in any device that will use 75 it later on. In the particular case of LISP the critical operation 76 is the creation of EID to RLOC mappings in the ITR and the ETR. Such 77 operation is performed in 3 different ways: 79 Using the information obtained from a LISP data packet (looking into 80 the EID and RLOC information included by the originator of the 81 packet) 83 Using the information contained in the Map-Reply message 85 Using a EID-to-RLOC database 87 This document performs threat analysis for the first two cases. The 88 third case, the one of the EID-to-RLOC database, has a different 89 trust model, and a specific threat analysis needs to be performed for 90 that case. 92 2. Application Scenario 94 We will consider the following application scenario. 96 +----+ 97 | HA | 98 +----+ 99 | EID: P1:IIDA 100 ----------------- 101 | | RLOC: P1:IIDLR1, P2:IIDLR2 102 +----+ +----+ 103 |LR1 | |LR2 | 104 +----+ +----+ 105 | | 106 | | 107 +----+ +----+ 108 |ISP1| |ISP2| 109 +----+ +----+ +----+ 110 | | +--| HC | IPC 111 +----------------+ | +----+ 112 | |--+ 113 | Internet | +----+ 114 | |-----| AT | IPAT 115 +----------------+ +----+ 116 | 117 | 118 +----+ +----+ 119 |LR3 | | HB | 120 +----+ +----+ 121 | | EID=IPB RLOC=IPLR3 122 -------------------- 124 LR: LISP Router that behaves as both as the ITR and the ETR 126 In the depicted scenario we have two LISP capable sites. One of the 127 sites, depicted on top of the figure, is multihomed to ISP1 and ISP2. 128 We assume that we are using LISP1, so one of the routable addresses 129 is used as EID, let's say that for host HA P1:IIDA is used as EID. 130 In addition, the locators for that host will be the two addresses of 131 the exit routers that are playing the role of ITR namely LR1 and LR2, 132 so RLOCs are P1:IIDLR1 and P2:IIDLR2. 134 (LR stands for LISP router since it plays both the roles of ITR and 135 ETR). 137 The other LISP capable site is the one depicted in the lower part of 138 the figure and it has a single ISP and a single ITR/ETR namely, LR3. 139 Host H3 located in this site has IPB as EID and the address of the 140 LR3, LPLR3 as RLOC. Since we are using LISP1, IPB is a routable 141 address 142 Hosts HC and AT are other hosts in the Internet, with addresses IPC 143 and IPAT respectively. 145 HA, HB and HC are victims and AT is the attacker. 147 3. Threat analysis 149 Full-time off-path attacker assumption 151 We will limit the considered attacks to those where the attacker is 152 not located along the path used to route packets of the communication 153 being attacked during the whole duration of the attack. 155 There are then two type of attacks: 157 - Off-path attacks the attacker is off-path during the whole duration 158 of the attack 160 - Time shifted attacks: the attacker is located along path during a 161 limited period, but the duration of the attack is significantly 162 longer than the period that the attacker is along the path. 164 3.1. Identity hijacking 166 In the attacks considered in this section the attacker will try to 167 hijack the identity of one victim on the eyes of another victim. 168 This means that two parties are deceived, one that thinks that is 169 communicating with the owner of a given identify, but it is 170 communicating with the attacker instead and the party whose identify 171 is being stolen. 173 As we mentioned earlier, there are two messages an attacker can use 174 to create the state required to launch an attack: the LISP data 175 packets or the Map-Reply message. In this section we will first 176 present the attacks based on using the LISP data packets and then the 177 attacks that use the Map-Reply messages. 179 3.1.1. Attacks using the LISP data packets to create state 181 3.1.1.1. Attacker initiated communication (Hijacking a client identity) 183 In this case, the attacker will initiate a communication with one 184 victim pretending to be someone else. 186 In the scenario above, the attacker AT will try to initiate a 187 communication with HA pretending to be HC. In order to do that it 188 will send a LISP packet with the following parameters: 190 - Destination RLOC (outer header destination address): P1:IIDA 192 - Destination EID (Inner header destination address): P1:IIDA 194 - Source RLOC (outer header source address): IPAT 196 - Source EID (inner header source address): IPC 198 The packet will be received by LR1 who will generate the LISP Map- 199 Reply message back to IPAT and will store the EID to RLOC mapping 200 information for the received data packet. The EID to RLOC mapping 201 information stored at LR1 contains the following information: EID = 202 IPC, RLOC=IPAT 204 In this case HA will be communicating with the attacker AT but HA 205 believes that he is communicating with HC. HC identity has been 206 stolen by AT in the eyes of HA. 208 Basically, in this case the packet that triggers all of this is (sent 209 from AT toward HA (who's EID is P1:11DA)) looks like: 211 DST SRC 212 +---------+------+ 213 | P1:IIDA | IPAT |<-- RLOC (outer) 214 +---------+------+ 215 | P1:IIDA | IPC |<-- EID (inner) 216 +---------+------+ 218 The mapping installed in LR1 is {EID, RLOC} = {IPC, IPAT}, and thus 219 HC's identity is hijacked (at least from HA's perspective) by AT 220 (since it thinks that IPAT is the RLOC associated with EID HC = 221 inaddr(IPC)). As a result, subsequent packets emitted by HA will 222 look like 224 DST SRC 225 +-----+---------+ 226 | IPC | P1:IIDA | 227 +-----+---------+ 229 and LR1 will encap as follows (giving the installed mapping): 231 DST SRC 232 +------+----------+ 233 | IPAT | P1:IIDR1 | outer 234 +------+----------+ 235 | IPC | P1:IIDA | innner 236 +------+----------+ 238 and the hijack is complete. 240 3.1.1.2. Victim initiated communication (Hijacking a server identity) 242 In the previous section, the attacker is hijacking the identity of a 243 client, since the attacker is the one that initiates the 244 communication. While this is problematic, a much more ambitious 245 attacks would to hijack the identity of a server, i.e. to hijack the 246 identity of a server when the victim initiates a communication 247 towards the server. 249 This is also possible with LISP. It would work in the following way. 251 Suppose that HC is a server that HA uses regularly (e.g. a newspaper 252 web site) 254 Suppose that AT wants that future communication initiated by HA to HC 255 are directed to AT i.e. AT wants to hijack HC identity for all the 256 communications initiated by HA. 258 In order to do that, AT performs the following actions. It first 259 needs to install false EID-to-RLOC mapping information in LR1. In 260 order to do that, it sends a data packet containing the following 261 information 263 - Destination RLOC (outer header destination address): P1:IIDA 265 - Destination EID (Inner header destination address): P1:IIDA 267 - Source RLOC (outer header source address): IPAT 269 - Source EID (inner header source address): IPC 271 The data packet could be a UDP packet that will be discarded upon 272 reception because there is no process listening in the requested 273 port. 275 LR1 will store that in order to reach IPC it must tunnel the packets 276 to IPAT. 278 However, there is no actual ongoing communication between HA and HC 279 at the moment, so the attack has no effect so far. The attacker must 280 then keep the EID to RLOC mapping information alive in LR1 for when 281 HA decides to initiate a communication to HC. The attacker can do 282 that by sending periodic data packets with the same information 283 detailed before. 285 Suppose that at any point in the future, HA decides to initiate a 286 communication with HC. It will send a data packet with destination 287 address IPC. The data packet will be intercepted by LR1 and 288 tunnelled to the attacker at IPAT, since this is the mapping 289 information available at LR1. 291 Note that these attacks affect all future communications started by 292 HA and that it affects communication initiated by HA. 294 3.1.1.3. Intercepting ongoing communications (becoming a MITM) 296 In the two previous sections, we have considered the case where the 297 attacker wants to hijack a future communication pretending to be one 298 of the involved parties. 300 In this section we will consider the case where there is an ongoing 301 communication and the attacker wants to hijack the ongoing 302 communication. 304 Suppose that there is an ongoing communication between HA and HB. In 305 this case, LR1 contains a mapping between EID=IPB and RLOC=IPLR3. 306 LR3 contain a mapping between EID= P1:IIDA and RLOC=P1:IIDLR1, P2: 307 IIDLR2. 309 Suppose now that AT sends two packets, one to LR1 and another to LR3. 311 The packet sent to LR1 will contain mapping information of EID=IPB 312 and RLOC=IPAT. The packet sent to LR3 will contain mapping 313 information EID=P1:IIDA and RLOC=IPAT. 315 (One may think that ingress filtering could help here, but note that 316 the attacker is sending packets from the claimed locator, so ingress 317 filters won't be of any use to prevent this attack) 319 If the new EI-to-RLOC information overrides the previously available 320 mapping information (this would depend on how the new mapping 321 information is managed, but it seems that in the current version, 322 latest information supersedes older information) , the result is that 323 LR1 will tunnel packets addressed to HB to the attacker at IPAT and 324 LR2 will tunnel packets addressed to HA to the attacker at IPAT. The 325 attacker has now placed himself as a man in the middle in the 326 communication. It can either modify packets or simply sniff them. 328 In this case, packets exchanged in this attack would look like this: 329 Suppose HA and HB are communicating. In this case, LR1 has 330 {IPB,IPLR3} and LR3 has {P1:IIDA, {P1:IIDLR1, P2:IIDLR2}} (P1:IIDA 331 has 2 possible RLOCs). Now, the attacker at IPAT sends 333 DST SRC 334 +---------+------+ 335 | P1:IIDA | IPAT |<-- RLOC (outer) 336 +---------+------+ 337 | P1:IIDA | IPB |<-- EID (inner) 338 +---------+------+ 340 to HA. the packet is intercepted by LR1, which results in the mapping 341 {IPB, IPAT} (so AT has half of the connection). That is, packets 342 from HA -> HB look like 344 DST SRC 345 +-----+---------+ 346 | IPB | P1:IIDA | 347 +-----+---------+ 349 LR1 builds 351 DST SRC 352 +------+-----------+ 353 | IPAT | P1:IIDLR1 | 354 +------+-----------+ 355 | IPB | P1:IIDA | 356 +------+-----------+ 358 and packets are delivered to the MITM. 360 Going the other way, AT sends 362 DST SRC 363 +-----+---------+ 364 | IPB | IPAT |<-- RLOC (outer) 365 +-----+---------+ 366 | IPB | P1:IIDA |<-- EID (inner) 367 +-----+---------+ 369 to HB. The packet is intercepted by LR3, which results in the 370 mapping {P1:IIDA, IPAT} (so AT has the other half of the connection), 371 so packets sent to P1:IIDA (HA) get delivered to AT (inaddr(IPAT)). 373 3.1.2. Attacks using the Map-Reply message to create state 375 Map-Reply messages are protected by a nonce, which is copied from the 376 LISP data packet that triggered the Map-Reply generation. Such nonce 377 protects from Map-Reply messages generated spontaneously (i.e. not 378 generated as a reply to an actual LISP data packet). While this 379 protection prevents a number of attacks, there are still a few 380 attacks that are possible, which are presented in this section. 382 3.1.2.1. Less-specific prefix attack 384 Map-Reply messages are very powerful because they can contain single 385 EIDs but also EID prefixes. Such capability allows any malicious 386 party receiving a LISP data packet to reply with a Map-Reply message 387 that includes a less specific EID prefix that contains more than its 388 own EIDs. Basically, the problem here is that the return routability 389 check only verifies the presence of a single EID and not the whole 390 EID prefix. The attack could be performed in the following way: 392 For whatever reason, HB decides to start a communication with AT. HB 393 generates a data packet containing: 395 DST SRC 396 +------+-----+ 397 | IPAT | IPB | 398 +------+-----+ 400 and LR3 will encap as follows: 402 DST SRC 403 +------+-------+ 404 | IPAT | IPLR3 | outer 405 +------+-------+ 406 | IPAT | IPB | innner 407 +------+-------+ 409 In addition, the encapsulated packet will contain a nonce NB. 411 AT will receive the packet, will store the state corresponding to HB 412 (EID=IPB, RLOC=IPLR3). In addition, AT can reply with a Map_Reply 413 message. However, AT can reply with an Map-Reply message that 414 contains amore specific prefix that contains other prefixes than its 415 own. In particular, AT can include the 0/0 prefix in the Map-Reply 416 message. The Map-Reply message is validated by the nonce NB the was 417 included in the received ISP data packet. The Map-Reply message that 418 AT will send back to LR3 will be: 420 - Nonce: NB 422 - EID mask-len: 0 424 - EID prefix: 0 426 - Locator: IPAT 428 Upon the reception of such Map-Reply message, LR3 will install the 429 EID-to-RLOC mapping which will map the whole EID space to the 430 attacker locator IPAT. All the following packets routed by LR3 will 431 be forwarded to the attacker AT. Note that this not only affects the 432 packets generated by HB but to all the packets generated by any host 433 behind LR3. Also note that this is the more extreme case, where the 434 whole EID space is hijacked, but it would also be possible to hijack 435 parts of the EID space, which would result in less severe attacks, 436 but probably more difficult to detect. 438 3.1.2.2. Time-shifted attack 440 Time-shifted attacks are those where the attacker is located along 441 the path during a short period and launches an attack that persists 442 in time long after the attacker left the on-path position. These 443 attacks have been considered relevant during the design of other 444 protocols for mapping identities and location, such as MIP. In 445 particular, in order to prevent time-shifted attacks in MIPv6 route 446 optimization, the MIPv6 specification requires the periodic 447 performance of the return routability check. The lifetime of the 448 state created using the validation information obtained using a 449 single return routability check is limited to 7 minutes in the MIPv6 450 spec. This implies that the maximum time span that a time-shifted 451 attack can be active after the attacker left the on-path position is 452 7 minutes. For additional information about the MIPv6 security 453 design, the reader is referred to [2]. 455 In the case of LISP, an attacker can launch a time-shifted attacks if 456 he is able to learn a nonce of a LISP data packet generated by the 457 victim. Once the attacker has obtained the nonce, it can then 458 generate a Map-Reply message and hijack any portion of the the EID 459 space, thanks to the aforementioned capabilities of EID aggregation 460 by the means of less-specific EID prefixes. The Map-reply message 461 would be accepted by the victim because it contains a valid nonce and 462 it will install the ED-to-RLOC mapping. The state will remain in the 463 victim even when the attacker has left the on-path position. The 464 attacker is able to keep the state alive by refreshing the state (is 465 likely that LISP provides some means for this since it should be able 466 for a genuine host to preserve the state in its peers, even when the 467 original path is unreachable) 469 The attack is then as follows: 471 The attacker is located along a path sniffing packets and looking for 472 any LISP data packet generated by the victim. 474 Once the attacker finds such a packet, it learns the nonce in the 475 LISP header. 477 The attacker generated a Map-Reply packet containing the nonce, the 478 EID prefix 0/0 and its own locator. 480 The attacker sends the Map-Reply which is processed by the victim's 481 router which installs the state. 483 From this moment, all the outgoing packets of the victim's site are 484 forwarded to the locator selected by the attacker. 486 The attacker can leave its position and move to its own locator, but 487 the attack is still active, since the state is still installed in the 488 victim's router. 490 3.2. DoS attacks 492 In this section, we describe DoS attacks related to LISP. 494 3.2.1. Flooding a third party 496 In this case, the attacker AT wants to use HA to flood a victim HC. 498 In order to do that, AT first initiates a communication with HA and 499 starts a download of a heavy flow. Once that the flow is 500 downloading, it redirects the heavy flow towards HC, flooding it. 501 This is performed in the following way. 503 AT initiates a communication with HA. In this case, AT uses IPAT as 504 EID and IPAT as RLOC. This mapping information is stored in LR1 505 since it is contained in the initial LISP data packet as described 506 previously. AT then starts downloading a heavy flow form HA. At 507 some point then, AT redirects the flow towards HC. It can do so by 508 including IPC as a RLOC for the EID IPAT that is being used in the 509 communication that is downloading the heavy flow. The IPC RLOC could 510 be included since the beginning with a low priority and now simply 511 send a LISP Map-Reply message with a higher priority to IPC. In any 512 case the result is that the flow will flood HC.(Note that it is 513 expected that AT can include additional locators associated to the 514 EID IPAT during the initial period where there is a direct 515 communication between AT and HA) 517 It should be noted that in some cases, in order to keep the flow 518 going, it is necessary that the receiver sends some ACK packets or 519 similar. In this case, it is possible that the attacker can send 520 such packets, since EID IPAT in LR1 can contain two valid RLOCs i.e. 521 IPAT and IPC. In this case, if IPC has higher priority that IPAT, 522 LR1 will send packets to IPC but will accept packets coming from IPAT 523 as valid packets from the EID IPAT. In this case, the attacker could 524 send ACK packets from its own location, and keep the flooding going 525 towards IPC. 527 3.2.2. Preventing future communications 529 This case is similar to the one described in section Victim initiated 530 communication (Hijacking a server identity), but only that instead of 531 the attackers RLOC, a black hole IP address is included as the RLOC 532 for a given EID. The result is that the traffic addressed to the EID 533 is sent to a black hole, resulting in a DoS attacks form 534 communications to that EID. 536 In addition to that, it is possible to use the Less-specific prefix 537 attack to perform a DoS attack. In this case, a larger number of 538 destinations are affected, since it affects a whole prefix. 540 Finally, it should be noted that the attacks do not affect the 541 traffic generated by a single machine, but to all the traffic routed 542 by the affected ITR i.e. to the traffic generated by all the hosts 543 behind the ITR. 545 3.2.3. Interrupt ongoing communication 547 This case is similar to the one described in the section Intercepting 548 ongoing communications (becoming a MITM) with the only difference 549 that an back hole IP address is included as RLOC for the ongoing 550 communication, terminating it. 552 3.2.4. DoS attacks against LISP infrastructure 554 Another type of DoS attacks that must be considered are the DoS 555 attacks against the LISP architecture itself. LISP infrastructure is 556 likely to become a critical part of the network, since EIDs may not 557 be reachable without the LISP service. This makes the LISP routers a 558 preferred target for attackers. 560 In particular LISP routers (ITR and ETR) are susceptible to DoS 561 attacks. LISP routers store information about EID-to- RLOC mappings. 562 They learn that information from data packets and from ICMP messages. 563 An attacker could massively generate either tunnelled data packets so 564 that the router cache is overflowed. The result is that routers will 565 not be able to store legitimate EID-to-RLOC mapping information and 566 that LISP features will be annulled. (in the case of using non 567 routable EIDs, all communication would be annulled if LISP 568 functionality is not available) 570 Current LISP proposal includes rate-limiting techniques for 571 protecting against DoS attacks. Such technique can be useful to 572 prevent LISP routers from crashing under the attack. However, this 573 technique does not prevent the actual effect of the attack, which 574 that hosts served by the LISP router under attack will not be able to 575 communicate. This is so, because the LISP router rate limiting 576 techniques, will also affect the legitimate request from internal and 577 external hosts, making communication hard if not impossible 578 (depending on the strength of the actual attack) 580 4. Security considerations 582 This note outlines security issues of the LISP protocol. 584 5. Acknowledgments 586 Pekka Nikander and Dave Meyer reviewed this document and provided 587 comments. In addition, Dave Meyer wrote the text containing the 588 packet description of attacks described in sections 3.1.1.1 and 589 3.1.1.3. Dino Farinacci provided clarifying comments about how LISP 590 works. 592 6. Normative References 594 [1] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, "Locator/ID 595 Separation Protocol (LISP)", draft-farinacci-lisp-01 (work in 596 progress), June 2007. 598 [2] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 599 Nordmark, "Mobile IP Version 6 Route Optimization Security 600 Design Background", RFC 4225, December 2005. 602 Author's Address 604 Marcelo Bagnulo 605 Huawei Lab at UC3M 606 Av. Universidad 30 607 Leganes, Madrid 28911 608 SPAIN 610 Phone: 34 91 6249500 611 Email: marcelo@it.uc3m.es 612 URI: http://www.it.uc3m.es 614 Full Copyright Statement 616 Copyright (C) The IETF Trust (2007). 618 This document is subject to the rights, licenses and restrictions 619 contained in BCP 78, and except as set forth therein, the authors 620 retain all their rights. 622 This document and the information contained herein are provided on an 623 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 624 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 625 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 626 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 627 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 628 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 630 Intellectual Property 632 The IETF takes no position regarding the validity or scope of any 633 Intellectual Property Rights or other rights that might be claimed to 634 pertain to the implementation or use of the technology described in 635 this document or the extent to which any license under such rights 636 might or might not be available; nor does it represent that it has 637 made any independent effort to identify any such rights. Information 638 on the procedures with respect to rights in RFC documents can be 639 found in BCP 78 and BCP 79. 641 Copies of IPR disclosures made to the IETF Secretariat and any 642 assurances of licenses to be made available, or the result of an 643 attempt made to obtain a general license or permission for the use of 644 such proprietary rights by implementers or users of this 645 specification can be obtained from the IETF on-line IPR repository at 646 http://www.ietf.org/ipr. 648 The IETF invites any interested party to bring to its attention any 649 copyrights, patents or patent applications, or other proprietary 650 rights that may cover technology that may be required to implement 651 this standard. Please address the information to the IETF at 652 ietf-ipr@ietf.org. 654 Acknowledgment 656 Funding for the RFC Editor function is provided by the IETF 657 Administrative Support Activity (IASA).