idnits 2.17.1 draft-ietf-mipshop-lmm-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 612 has weird spacing: '...ovisual commu...' -- 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 19, 2004) is 7192 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: '3' is defined on line 597, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '1') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-00 == Outdated reference: A later version (-04) exists of draft-ietf-mipshop-hmipv6-02 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 mipshop C. Williams 2 Internet-Draft MCSR Labs 3 Expires: January 17, 2005 July 19, 2004 5 Localized Mobility Management Goals 6 draft-ietf-mipshop-lmm-requirements-03 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on January 17, 2005. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This document describes goals for Localized Mobility Management (LMM) 37 for IP layer mobility, such as in Mobile IP and Mobile IPv6. These 38 goals are intended to guide the design of a protocol specification 39 for LMM. Localized Mobility Management, in general, introduces 40 enhancements to IP layer mobility protocols to reduce the amount of 41 latency in IP layer mobility management messages exchanged between a 42 Mobile Node (MN) and its peer entities. In addition, LMM seeks to 43 reduce the amount of signaling over the global Internet when a mobile 44 node traverses within a defined local domain. The identified goals 45 are essential for localized mobility management functionality. They 46 are intended to be used as a guide for analysis on the observed 47 benefits over the identified goals for architecting and deploying LMM 48 schemes. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1 Intra-domain mobility . . . . . . . . . . . . . . . . . . 6 56 3.1.1 Optimized signaling within the Local Coverage Area . . . . 6 57 3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.2.1 Security services . . . . . . . . . . . . . . . . . . . . 6 59 3.2.2 Non-interference with peer entities . . . . . . . . . . . 6 60 3.2.3 No new vulnerabilities . . . . . . . . . . . . . . . . . . 7 61 3.3 Induced LMM functional requirements . . . . . . . . . . . 7 62 3.3.1 No additional functionality at peer entities . . . . . . . 7 63 3.3.2 No changes to existing components . . . . . . . . . . . . 7 64 3.3.3 No additional messages to peer entities . . . . . . . . . 7 65 3.4 Scalability, Reliability, and Performance . . . . . . . . 7 66 3.4.1 Linear complexity . . . . . . . . . . . . . . . . . . . . 7 67 3.4.2 Linear routing state growth . . . . . . . . . . . . . . . 7 68 3.4.3 No additional points of failure . . . . . . . . . . . . . 8 69 3.4.4 No worse performance . . . . . . . . . . . . . . . . . . . 8 70 3.4.5 Scalable expansion of the network . . . . . . . . . . . . 8 71 3.4.6 Resilience to topological changes . . . . . . . . . . . . 8 72 3.4.7 Header or Tunneling overhead . . . . . . . . . . . . . . . 8 73 3.5 Mobility Management Support . . . . . . . . . . . . . . . 8 74 3.5.1 No increase of latency or packet loss . . . . . . . . . . 9 75 3.5.2 No increase of service disruption . . . . . . . . . . . . 9 76 3.5.3 No new messages to peer entities . . . . . . . . . . . . . 9 77 3.6 Auto-configuration capabilities for LMM constituents . . . 9 78 3.7 LMM inter-working with IP routing infrastructure . . . . . 9 79 3.8 Sparse routing element population . . . . . . . . . . . . 10 80 3.9 Support for Mobile IPv4 or Mobile IPv6 Handover . . . . . 10 81 3.10 Simple Network design . . . . . . . . . . . . . . . . . . 10 82 3.11 Stability . . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.12 Quality of Service requirements . . . . . . . . . . . . . 10 84 3.12.1 Co-exist with end-to-end QoS . . . . . . . . . . . . . . . 10 85 3.12.2 Co-exist with link-local QoS . . . . . . . . . . . . . . . 11 86 4. Security Considerations . . . . . . . . . . . . . . . . . 12 87 4.1 Trust model . . . . . . . . . . . . . . . . . . . . . . . 12 88 4.2 Potential new vulnerabilities . . . . . . . . . . . . . . 13 89 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 15 90 Normative references . . . . . . . . . . . . . . . . . . . 16 91 Informative References . . . . . . . . . . . . . . . . . . 17 92 Author's Address . . . . . . . . . . . . . . . . . . . . . 17 93 A. LMM requirements and HMIPv6 . . . . . . . . . . . . . . . 18 94 B. Changes from last revision . . . . . . . . . . . . . . . . 19 95 Intellectual Property and Copyright Statements . . . . . . 20 97 1. Introduction 99 In order to meet the demands of real-time applications and the 100 expectations of future wireless users for service level quality 101 similar to the one of wireline users, IP layer mobility management is 102 facing a number of technical challenges in terms of performance and 103 scalability [5][6][7]. These manifest themselves as increased 104 latencies in the control signaling between a Mobile Node and its peer 105 entities, namely the Home Agent (HA) and its Corresponding Nodes 106 (CNs). 108 In the base Mobile IP protocols [1][2], movement between two subnets 109 requires that the Mobile Node obtain a new care-of address in the new 110 subnet. This allows the Mobile Node to receive traffic on the new 111 subnet. In order for the routing change to become effective, 112 however, the Mobile Node must issue a binding update (also known in 113 Mobile IPv4 as a Home Agent registration) to the Home Agent so that 114 the Home Agent can change the routing from the previous subnet to the 115 new subnet. The binding update establishes a host route on the Home 116 Agent between the Mobile Node's Home Address and its new care-of 117 address. In addition, if route optimization is in use [2], the 118 Mobile Node may also issue binding updates to Correspondent Nodes to 119 allow them to send traffic directly to the new care-of address rather 120 than tunneling their traffic through the Home Agent. 122 The same approach applies also to a number of other IP layer mobility 123 management protocols. For example, in the Host Identity Protocol 124 (HIP) mobility management scheme [8], a Mobile Node sends an 125 Readdress (REA) packet to its peer; this is very similar the Binding 126 Updates send in Mobile IPv6 Route Optimization. In general, IP layer 127 mobility protocols maintain a binding between a host identifier and 128 either one care-of address or a set of care-of addresses. In Mobile 129 IP, the home address acts as the host identifier, and only one 130 care-of address is allowed. In other IP layer mobility protocols the 131 host identifier is typically something else and more than one care-of 132 addresses may be allowed. 134 After movement, traffic destined for the Mobile Node is sent to the 135 old care-of address and is, effectively, dropped until the peer 136 entities process mobility management messages. If the Mobile Node is 137 at some geographical and topological distance away from a peer 138 entity, the amount of time involved in sending the binding updates 139 may be greater than 100 hundred milliseconds. This latency in routing 140 update may cause some packets for the Mobile Node to be lost at the 141 old Access Router. For instance, [10] is one such solution for 142 extending Mobile IP to alleviate the above performance limitations. 143 In general such proposals are identified as hierarchical/regional or 144 more generically Localized Mobility Management (LMM). 146 LMM Localized mobility management schemes allow the Mobile Node to 147 continue receiving traffic on the new subnet without any change in 148 the bindings at the peer entities. The latency involved in updating 149 the care-of-address bindings at far geographical and topological 150 distances is eliminated or reduced until such time as the Mobile Node 151 is in a position to manage the latency cost. 153 Having provided some motivation and brief summary of the underlying 154 principles of LMM, it is important to enumerate goals for LMM. 156 Goals for LMM: 158 o reduce the signaling induced by changes in the point of attachment 159 due to the movement of a host; reduction in signaling delay will 160 minimize packet loss and possible session loss; 162 o reduce the usage of air-interface and network resources for 163 mobility; 165 o reduce the processing overhead at the peer nodes, thereby 166 improving protocol scalability; 168 o avoid or minimize the changes of, or impact to the Mobile Node, 169 Home Agent or the Correspondent Node; 171 o avoid creating single points of failure; 173 o simplify the network design and provisioning for enabling LMM 174 capability in a network; 176 o allow progressive LMM deployment capabilities. 178 o LMM should introduce no new security vulnerabilities. 180 Identifying a set of desired properties that will render the protocol 181 internals, for some LMM scheme, robust enough to cater for the 182 aforementioned considerations becomes essential in designing a widely 183 accepted solution. The remainder of this document present a set of 184 goals that encompass essential considerations for the design of an 185 LMM scheme. It is with this foundation that we can seek to ensure 186 that the resulting LMM solution will best preserve the fundamental 187 philosophies and architectural principles of the Internet in practice 188 today. 190 This document is meant to capture the thinking and analysis of LMM 191 that began in Spring 2001 and is not meant to bind any futures 192 efforts that, due to gained wisdom, may wish to depart from it. 194 2. Terminology 196 See [9] for mobility terminology used in this document. 198 Peer entity A generic name used for nodes that communicate with a 199 mobile node using mobility-specific signaling. In Mobile IP and 200 IPv6, the Home Agent and Correspondent Node are peer entities. 202 3. Goals 204 This section describes the goals for a LMM solution. These desired 205 properties are relevant to both all IP layer local mobility 206 management schemes, independent of the actual IP layer macro mobility 207 protocol. 209 3.1 Intra-domain mobility 211 LMM is introduced to minimize the signaling traffic to the peer 212 entities, e.g. Home Agent and/or Correspondent Node(s), for 213 intra-domain mobility (within a Local Coverage Area). This is the 214 fundamental reason for introducing localized mobility management. In 215 the LMM infrastructure a peer entity outside the administration 216 domain must always be able to address the mobile host by the same IP 217 address, so that from the point of view of hosts outside the 218 administration domain, the IP address of the mobile host remains 219 fixed regardless of any changes in the Mobile Node's subnet. The peer 220 entities are not aware of the Mobile Node's Intra-domain movement. 222 3.1.1 Optimized signaling within the Local Coverage Area 224 By its very nature, LMM reintroduces triangle routing into the base 225 IP layer mobility protocol in that all traffic must go through the 226 LMM agent. There is no way to avoid this. The LMM framework should be 227 designed in such a way as to reduce the length of the unwanted 228 triangle leg. The LMM design should not prohibit optimal placement 229 of LMM agents to reduce or eliminate additional triangle routing 230 introduced by LMM. 231 NOTE: It is not required that a LMM scheme specify LMM agents as part 232 of its solution. 234 3.2 Security 236 3.2.1 Security services 238 LMM protocol must provide security services within the respective 239 local coverage area. 241 The security of exchanging LMM specific information and signaling 242 must be ensured. In general, an LMM scheme must cater for 243 authentication mechanisms that prevent malicious deflection of 244 traffic destined to a legitimate MN. If applicable, replay protection 245 must exist mutually between the LMM agents. 247 3.2.2 Non-interference with peer entities 249 LMM protocol must not interfere with the security provisioning that 250 exists between the peer entities and the Mobile Node. 252 3.2.3 No new vulnerabilities 254 LMM protocol must not introduce new security holes or the possibility 255 for DOS-style attacks with the base global mobility management 256 protocol that may be used for inter-domain mobility. 258 3.3 Induced LMM functional requirements 260 3.3.1 No additional functionality at peer entities 262 Any Localized Mobility Management protocol must not inject any 263 additional functionality over the base IP layer macro mobility 264 protocol employed. Thus, the LMM framework must not add any 265 modifications or extensions to the peer entities, including Mobile IP 266 or Mobile IPv6 Correspondent Node(s) and Home Agents. It is 267 essential to minimize the involvement of the Mobile Node in routing 268 beyond what is in the basic mobility protocol. Preferences, load 269 balancing, and other complex schemes requiring heavy mobile node 270 involvement in the mobility management task should BE avoided. 272 3.3.2 No changes to existing components 274 Non-LMM-aware routers, hosts, Mobile IP and IPv6 Home Agents, and 275 Mobile Nodes must be able to interoperate with LMM agents. 277 3.3.3 No additional messages to peer entities 279 By definition a localized mobility management scheme strives to 280 minimize excessive IP mobility management signaling toward its peer 281 entities, caused by frequent changes in the IP network location (i.e, 282 change in the Care-of Address (CoA)). The amount of regional 283 signaling must not surpass the amount of global signaling that would 284 have otherwise occurred if LMM were not present [4]. 286 3.4 Scalability, Reliability, and Performance 288 3.4.1 Linear complexity 290 The LMM complexity must increase at most linearly with the size of 291 the local domain and the number of Mobile Nodes. 293 3.4.2 Linear routing state growth 295 Any Localized Mobility Management protocol must assure that that LMM 296 routing state scales at most linearly with the number of Mobile Nodes 297 registered, and that the increase in routing state is confined to 298 those Access Routers/Access Network Routers (ANR) involved in 299 implementing the LMM protocol at hand. While host routes apparently 300 cannot be eliminated by any mobility management protocol including 301 base IP mobility, any LMM protocol must keep the number of host 302 routes to a minimum. 304 3.4.3 No additional points of failure 306 The LMM framework must not introduce additional points of failure in 307 the network. The current access router would be excluded from this 308 requirement. 310 3.4.4 No worse performance 312 The LMM framework should not degrade in any way the basic IP mobility 313 performance of a mobile host communications with a peer entity. 315 3.4.5 Scalable expansion of the network 317 It is imperative that the LMM function must afford larger operational 318 scales by means of incremental deployment. The LMM framework must not 319 introduce any additional restrictions in how wireless ISPs configure 320 their network, nor how they interconnect with other networks beyond 321 those introduced by standard IP routing. In addition, the amount of 322 regional signaling should not increase as the Local Domain expands in 323 size. 325 3.4.6 Resilience to topological changes 327 The LMM protocols must be topology-independent. The LMM protocols 328 must be able to adapt to topological changes within the domain. The 329 topological changes may include the addition or removal/failure of 330 LMM agents or that of changes in the routing of the local domain over 331 which the LMM scheme is applied. 333 3.4.7 Header or Tunneling overhead 335 The LMM framework must not prevent header compression from being 336 applied. It is recommended that candidate LMM designs that require 337 additional header overhead for tunnel be reviewed by the ROHC working 338 group to determine if the header compressor can be restarted from 339 transferred compressor context when handover occurs without requiring 340 any full header packet exchange on the new link. 342 3.5 Mobility Management Support 344 The following LMM requirements pertain to both inter-domain and 345 intra-domain hand-off. 347 3.5.1 No increase of latency or packet loss 349 The LMM framework must not increase the amount of latency or amount 350 of packet loss, compared to what exists with the core Mobile IP and 351 Mobile IPv6 specification [1][2]. Indeed, the LMM framework should 352 decrease the amount of latency or amount of packet loss that exists 353 with the core mobility protocols. 355 3.5.2 No increase of service disruption 357 The LMM framework must not increase the amount of service disruption, 358 compared to that already exists with the Mobile IP and Mobile IPv6 359 core mobility specifications. Again, the LMM framework should 360 decrease the amount of service disruption that already exists with 361 the IP layer mobility management protocols. 363 3.5.3 No new messages to peer entities 365 The LMM framework must not increase the number of messages between 366 the mobile host and the respective peer entities. The LMM framework 367 should decrease the number of messages between the mobile host and 368 the respective peer entities. With respect to Mobile IP and Mobile 369 IPv6, the current number of messages is defined in the Mobile IP core 370 mobility specifications [1][2]. 372 3.6 Auto-configuration capabilities for LMM constituents 374 It is essential that the configuration tasks of the LMM scheme can 375 adapt to topological changes with minimal (or no) human intervention; 376 manual configuration is usually tedious, prone to human error and for 377 large-scale deployment, impossible. Automating the configuration task 378 of the LMM function is elemental for addressing realistically 379 incremental deployment of LMM agents within an expanding network 380 domain of large numbers of MNs requiring robust IP services. 382 By introducing self-organizing LMM agents that caters for dynamic 383 discovery, configuration and management while embracing resiliency 384 with respect to state consistency or failure, an LMM scheme can 385 address successfully the previously mentioned scalability 386 requirements. 388 3.7 LMM inter-working with IP routing infrastructure 390 The LMM framework must not disrupt core IP routing outside the local 391 domain. 393 3.8 Sparse routing element population 395 Any LMM protocol must be designed to be geared towards incremental 396 deployment capabilities; the latter implies that the LMM scheme 397 itself imposes minimum requirements on the carriers' network. 398 Incremental deployment capabilities for an LMM protocol signifies 399 that an initial set of sparse LMM agents can populate the 400 administration domain of a network provider and operate sufficiently. 401 In addition, any LMM scheme must be compatible with any additional 402 deployment of LMM agents in future infrastructure expansions; that is 403 to say, allow progressive LMM deployment capabilities. 405 It is for this reason that the LMM framework must not require that 406 all routing elements be assumed to be LMM-aware in the signaling 407 interactions of an LMM protocol. The LMM framework must BE supported, 408 at the very minimum, by a sparse (proper subset) LMM agent population 409 that is co-located within the routing topology of a single 410 administration domain. 412 3.9 Support for Mobile IPv4 or Mobile IPv6 Handover 414 Since one of the primary goals of LMM is to minimize signaling during 415 handover, an LMM solution must be available for the standardized 416 Mobile IPv4 or Mobile IPv6 handover algorithms. LMM and the Mobile IP 417 or Mobile IPv6 handover algorithms must maintain compatibility in 418 their signaling interactions for fulfilling complementary roles with 419 respect to each other. 421 This requirement should not be interpreted as ruling out useful 422 optimizations of LMM and Mobile IP or Mobile IPv6 handoff schemes 423 that simplify the implementation or deployment of LMM or Mobile IP or 424 Mobile IPv6 handoff. 426 3.10 Simple Network design 428 LMM should simplify the network design and provisioning for enabling 429 LMM capability in a network and allow progressive LMM deployment 430 capabilities. 432 3.11 Stability 434 LMM must avoid any forwarding loops. 436 3.12 Quality of Service requirements 438 3.12.1 Co-exist with end-to-end QoS 440 The LMM must have the ability to coexist with QoS schemes to hide the 441 mobility of the MN to its peer by avoiding end-to-end QoS signaling. 443 3.12.2 Co-exist with link-local QoS 445 The LMM must have the ability to coexist with the QoS schemes to 446 facilitate the new provisioning of both uplink and downlink QoS after 447 a handoff. 449 4. Security Considerations 451 The usual threats against mobility mechanisms are [11] 453 unauthorized redirection of traffic, and 455 flooding. 457 An LMM scheme must cater for suitable authorization or other security 458 mechanisms that prevent malicious flooding and other deflection of 459 traffic. When LMM mechanisms are applied only within a single 460 administrative domain, solving these issues may be easier than in the 461 case of generic end-to-end mobility. It must be remembered, though, 462 that the MNs are not necessarily trusted. In the general setting, it 463 is possible that there are authenticated but malicious MNs that 464 attempt to disrupt the service. The situation is complicated by the 465 co-existence of multiple mobility mechanisms, such as Mobile IP and 466 LMM. Since security mechanisms are, in general, non-composable, each 467 protocol combination should be analyzed separately. 469 Due to administrative constraints, any LMM function should allow for 470 any security provisioning to be negotiable or at least 471 pre-configurable. In certain administrative domains, reduced 472 security requirements may be allowed, so as to minimize incurred 473 overhead. 475 Involvement with the LMM function into the security semantics of the 476 end-to-end IP mobility signaling between the MN and its peers is 477 beyond the functional scope of any LMM protocol. It is important to 478 implement the effect of mobility localization without interfering 479 with security mechanisms between visiting MNs and their peers. Any 480 possibly existing security associations between the MN and its peers 481 must be considered transparent for the LMM function. 483 4.1 Trust model 485 By necessity, the MN must trust the LMM agents to provide LMM 486 services. In most settings the MN must probably authenticate the LMM 487 agents before it can trust them. Whenever several LMM agents are 488 co-operating (as may be the case in fast mobility, for example), the 489 agents must trust each other, at least to an extent. Typically, this 490 trust is manifested in the amount of space and resources that the LMM 491 agent that is receiving packets from another LMM agent is ready do 492 reserve and use. 494 The LMM agents should not trust the MNs. Basically, they must assume 495 that the MNs may try to launch various kinds of attacks against them 496 or other MNs. On the other hand, the LMM agents are considered to be 497 obliged to provide services to the MNs. That is, even though the LMM 498 agents do not trust the MNs, they must still be willing to provide 499 the LMM services to the MNs. 501 An LMM protocol may assume that the involved nodes do not trust any 502 one else in the network but what has been defined above. On the 503 other hand, it is also possible to assume one or more trusted third 504 parties. 506 4.2 Potential new vulnerabilities 508 Beyond the possibility of failure, any LMM agents can also exhibit 509 new security vulnerabilities, including the following. 511 Denial of service. It is possible that an LMM agent may receive LMM 512 messages that incur redundant processing or resource reservation 513 at the LMM agent, and as a result, deprive other MNs from LMM 514 services. The LMM function should ensure that malicious nodes are 515 excluded from further communications with the LMM agents, in the 516 event that their mobility signals are discarded. Thus, the LMM 517 function must cater for denial of service attacks at the LMM agent 518 nodes. 520 Message replay. Signals that are sent by the MN to a LMM agent can 521 also be captured and replayed by malicious nodes towards the LMM 522 agents; the LMM agents must ensure that such signaling is either 523 authenticated or have a restricted lifetime. Hence, the LMM 524 function must ensure protection from replay attacks at the LMM 525 agents. 527 Unauthorized creation of LMM state. If an attacker is able to create 528 an unauthorized LMM state at an LMM agent, it can effectively 529 forward packets to itself, to a black hole, or to a flood victim. 530 The LMM agents should make sure that any LMM state is strongly 531 linked to a known MN. 533 Creation of LMM state before a MN arrives. If an attacker is able to 534 anticipate the care-of-address a MN is likely to use on a link, 535 and if it can attach to the link using that particular address, it 536 can use the address for a while, move away, and request LMM 537 services on that address. Such a request would be authorized 538 since the attacker was legally using the very address. When the 539 victim later comes to the link, it will not get any packets since 540 its address is forwarded away. If the care-of-address assignment 541 is completed as part of the LMM services, then the LMM system 542 should make sure that a new MN cannot acquire a care-of-address 543 that has previously been assigned to another MN. In the case 544 where by care-of-address assignment is completed in a manner 545 unrelated to the LMM services, then authentication must be 546 completed prior to beginning LMM services. 548 Unauthorized tearing down of LMM state. If an attacker is able to 549 cause an LMM agent to discard its LMM state before requested by 550 the MN, the MN may experience loss of service. Since LMM is 551 basically an optimization, this threat may not be so severe and 552 may be ignored by an LMM mechanism. 554 5. Acknowledgments 556 Thank you to all who participated in the LMM requirement discussion 557 on the Mobile IP working group alias. First, the editor wishes to 558 recognize Theo Pagtzis's work on LMM requirement analysis. Theo has 559 contributed significantly to the LMM discussion on the mailing list 560 and at IETF working group meetings and has provided text for various 561 requirements. Special thanks also to Gabriel Montenegro, John 562 Loughney, Alper Yegin, Alberto Lopez Toledo, and Madjid Nakhjiri for 563 providing input to the draft in its preliminary stage and many other 564 comments they had. Thanks to the LMM requirement analysis design 565 team: Hesham Soliman, Erik Nordmark, Theo Pagtzis, James Kempf, and 566 Jari Malinen. Thanks to Pekka Nikander for changes to make the 567 document non-Mobile IP specific and the security considerations. He 568 also produced the final xml2rfc format that was used for submitting 569 the draft to the RFC Editor. 571 Additional comments on the LMM requirements were received from: 572 Charlie Perkins, Muhammad Jaseemuddin, Tom Weckstr, Jim Bound, Gopal 573 Dommety, Glenn Morrow, Arthur Ross, Samita Chakrabarti, Karim 574 El-Malki, Phil Neumiller, Behcet Sarikaya, Karann Chew, Michael 575 Thomas, Pat Calhoun, Bill Gage, Vinod Choyi, John Loughney, Wolfgang 576 Schoenfeld, David Martin, Daichi Funato, Ichiro Okajima, Jari 577 Malinen, Kacheong Poon, Koshimi Takashi, and Cedric Westphal. 579 An LMM requirement analysis of this body of work was completed by a 580 number of members of the Mobile IP working group and published as 581 [4]. 583 In addition special thanks to the Mobile IP working group chairs, 584 Phil Roberts, Gabriel Montenegro, and Basavaraj Patil, for their 585 input as well as capturing/organizing the initial set of requirements 586 from the discussions. Thomas Narten provided important AD feedback 587 and review. 589 Normative references 591 [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 592 2002. 594 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 595 IPv6", RFC 3775, June 2004. 597 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 598 Levels", BCP 14, RFC 2119, March 1997. 600 Informative References 602 [4] Pagtzis, T., Williams, C., Kirstein, P., Perkins, C. and A. 603 Yegin, "Requirements for Localized IP Mobility Management", in 604 Proceedings of IEEE Wireless Communications and Networking 605 Conference (WCNC2003), Louisiana, New Orleans, March 2003. 607 [5] Karlsson, G., "Quality Requirements for Multimedia Network 608 Services", in Proceedings of Radiovetenskap och kommunikation, 609 pages 96-100, June 1996. 611 [6] Kurita, T., Iai, S. and N. Kitawaki, "Effects of transmission 612 delay in audiovisual communications", Electronics and 613 Communications in Japan, Vol 77, No 3, pages 63-74, 1995. 615 [7] Wang, Y., Claypool, M. and Z. Zuo, "An Empirical Study of 616 RealVideo Performance Across the Internet", in Proceedings of 617 ACM SIGCOMM Internet Measurement Workshop, Nov 2001. 619 [8] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 620 (work in progress), June 2004. 622 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 623 3753, June 2004. 625 [10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, 626 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 627 draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004. 629 [11] Nikander, P., "Mobile IP version 6 Route Optimization Security 630 Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work 631 in progress), December 2003. 633 Author's Address 635 Carl Williams 636 MCSR Labs 637 3790 El Camino Real 638 Palo Alto, CA 94306 639 USA 641 Phone: +1 650 279 5903 642 EMail: carlw@mcsr-labs.org 644 Appendix A. LMM requirements and HMIPv6 646 HMIPv6 was evaluated as a localized mobility management protocol, and 647 that it was mostly found to satisfy the requirements put forth in 648 this document. This section details one exception with some 649 explanation. 651 Exception: 653 One LMM requirement that needs further clarification with respect to 654 HMIPv6 is the requirement that states that LMM should not introduce 655 additional single points of failure. The HMIPv6 Mobility Anchor 656 Point (MAP) is a new single point of failure. Proposals for HMIPv6 657 MAP replication can be optionally incorporated in order to avoid this 658 new single point of failure. Such proposals can also be applied to 659 the base Mobile IPv6 specification to also allow for Home Agent 660 fail-over as well. 662 Appendix B. Changes from last revision 664 Changes since last revision: 666 o Updated all references 668 o Small editorial fixes throughout the document 670 o Added reference to HIP in Introduction 672 o Identified HMIPv6 as a possible solution for LMM per feedback 674 o Change requirements to goals and/or desired properties 676 o Minor change to Peer entity definition - states using 677 mobility-specific signaling 679 o Captured more fully the definition of intra-domain movement in 680 section 3.1 682 o LMM security provisioning was updated - section 3.2.1 684 o Clarification in section 3.2.3 and 3.3.3 686 o must changed to should in section 3.4.4 688 o must not changed to should not in section 3.5.1 690 o scalability and auto-configuration sections presented more as 691 goals 693 o section 3.4.8 is now a subsection of 3.1 695 o all uppercase directives changed to lowercase in an effort to 696 present more along the lines of a goals document 698 Intellectual Property Statement 700 The IETF takes no position regarding the validity or scope of any 701 intellectual property or other rights that might be claimed to 702 pertain to the implementation or use of the technology described in 703 this document or the extent to which any license under such rights 704 might or might not be available; neither does it represent that it 705 has made any effort to identify any such rights. Information on the 706 IETF's procedures with respect to rights in standards-track and 707 standards-related documentation can be found in BCP-11. Copies of 708 claims of rights made available for publication and any assurances of 709 licenses to be made available, or the result of an attempt made to 710 obtain a general license or permission for the use of such 711 proprietary rights by implementors or users of this specification can 712 be obtained from the IETF Secretariat. 714 The IETF invites any interested party to bring to its attention any 715 copyrights, patents or patent applications, or other proprietary 716 rights which may cover technology that may be required to practice 717 this standard. Please address the information to the IETF Executive 718 Director. 720 Full Copyright Statement 722 Copyright (C) The Internet Society (2004). All Rights Reserved. 724 This document and translations of it may be copied and furnished to 725 others, and derivative works that comment on or otherwise explain it 726 or assist in its implementation may be prepared, copied, published 727 and distributed, in whole or in part, without restriction of any 728 kind, provided that the above copyright notice and this paragraph are 729 included on all such copies and derivative works. However, this 730 document itself may not be modified in any way, such as by removing 731 the copyright notice or references to the Internet Society or other 732 Internet organizations, except as needed for the purpose of 733 developing Internet standards in which case the procedures for 734 copyrights defined in the Internet Standards process must be 735 followed, or as required to translate it into languages other than 736 English. 738 The limited permissions granted above are perpetual and will not be 739 revoked by the Internet Society or its successors or assignees. 741 This document and the information contained herein is provided on an 742 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 743 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 744 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 745 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 746 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Acknowledgment 750 Funding for the RFC Editor function is currently provided by the 751 Internet Society.