idnits 2.17.1 draft-bernardos-dmm-cmip-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2598 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group CJ. Bernardos 3 Internet-Draft A. de la Oliva 4 Intended status: Informational UC3M 5 Expires: September 14, 2017 F. Giust 6 NEC 7 March 13, 2017 9 An IPv6 Distributed Client Mobility Management approach using existing 10 mechanisms 11 draft-bernardos-dmm-cmip-07 13 Abstract 15 The use of centralized mobility management approaches -- such as 16 Mobile IPv6 -- poses some difficulties to operators of current and 17 future networks, due to the expected large number of mobile users and 18 their exigent demands. All this has triggered the need for 19 distributed mobility management alternatives, that alleviate 20 operators' concerns allowing for cheaper and more efficient network 21 deployments. 23 This draft describes a possible way of achieving a distributed 24 mobility behavior with Client Mobile IP, based on Mobile IPv6 and the 25 use of Cryptographic Generated Addresses. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 14, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Description of the solution . . . . . . . . . . . . . . . . . 4 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 6.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Appendix A. Comparison with Requirement document . . . . . . . . 11 76 A.1. Distributed mobility management . . . . . . . . . . . . . 11 77 A.2. Bypassable network-layer mobility support for each 78 application session . . . . . . . . . . . . . . 12 79 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 12 80 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 12 81 A.5. Coexistence with deployed networks/hosts and operability 82 across different networks . . . . . . . . . . . . . . . . 13 83 A.6. Operation and management considerations . . . . . . . . . 13 84 A.7. Security considerations . . . . . . . . . . . . . . . . . 13 85 A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13 86 Appendix B. Open DMM platform . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 Most of the currently standardized IP mobility solutions, like Mobile 92 IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213] rely to a certain 93 extent on a centralized mobility anchor entity. This centralized 94 network node is in charge of both the control of the network entities 95 involved in the mobility management (i.e., it is a central point for 96 the control signalling), and the user data forwarding (i.e., it is 97 also a central point for the user plane). This makes centralized 98 mobility solutions prone to several problems and limitations, as 99 identified in [RFC7333]: longer (sub-optimal) routing paths, 100 scalability problems, signaling overhead (and most likely a longer 101 associated handover latency), more complex network deployment, higher 102 vulnerability due to the existence of a potential single point of 103 failure, and lack of granularity on the mobility management service 104 (i.e., mobility is offered on a per-node basis, not being possible to 105 define finer granularity policies, as for example per-application). 107 There are basically two main approaches that are being researched 108 now: one aimed at making Mobile IPv6 work in a distributed way, and 109 another one doing the same exercise for Proxy Mobile IPv6 (see the 110 document [RFC7429]). In this draft we describe a solution to achieve 111 a DMM behavior with a CMIP (MIPv6) solution. This document is based 112 on a research paper of the same authors, called "Flat Access and 113 Mobility Architecture: an IPv6 Distributed Client Mobility Management 114 solution" [GOB11]. 116 2. Terminology 118 The following terms used in this document are defined in the Mobile 119 IPv6 specification [RFC6275]: 121 Home Agent (HA) 123 Home Link 125 Home Address (HoA) 127 Care-of Address (CoA) 129 Binding Update (BU) 131 Binding Acknowledgement (BA) 133 The following terms are defined and used in this document: 135 DAR (Distributed Anchor Router). First hop routers where the mobile 136 nodes attach to. They also play the role of mobility managers for 137 the IPv6 addresses they anchor. 139 HDAR (Home Distributed Anchor Router). DAR which plays the role of 140 Home Agent for a particular IPv6 address (i.e., DAR where that 141 IPv6 address is anchored). 143 3. Description of the solution 145 Distributed Mobility Management approaches try to overcome the 146 limitations of the traditional centralized mobility management, i.e., 147 Mobile IP, by bringing the mobility anchor closer to the MN. 148 Following this idea, in our approach -- that we call Flat Access and 149 Mobility Architecture (FAMA) -- the MIPv6 centralized home agent is 150 moved to the edge of the network, being deployed in the default 151 gateway of the mobile node. That is, the first elements that provide 152 IP connectivity to a set of MNs are also the mobility managers for 153 those MNs. In the following we will call these access routers 154 Distributed Anchor Routers (DARs). 156 The diagram in Figure 1 depicts the operations of the proposed 157 solution. When a mobile node attaches to a distributed anchor 158 router, it gets an IPv6 address which is topologically anchored at 159 the DAR (Pref1::addr1 - HoA1). In the scheme we assume the address 160 configuration takes place through a Router Solicitation/Router 161 Advertisement handshake. While attached to this DAR, the mobile can 162 send and receive traffic using HoA1 without traversing any tunneling 163 nor special packet handling. 165 If the the mobile node moves to a different DAR, it gets a new IPv6 166 address from the new access router (Pref2::addr2 - HoA2). In case 167 the MN wants to keep the reachability of the IPv6 address(es) it 168 obtained from the previous DAR (note that this decision is dynamic 169 and it is out of scope of this document, it can be done on an 170 application basis for example), the host has to involve its MIPv6 171 stack, by sending a Binding Update to the DAR where the IPv6 address 172 is anchored, using the address obtained from the current DAR as care- 173 of address (in our example the MN binds HoA2 as CoA to DAR1). 175 +-----+ +-----+ +-----+ +-----+ +-----+ 176 | MN | |DAR1 | |DAR2 | | CN1 | | CN2 | 177 +-----+ +-----+ +-----+ +-----+ +-----+ 178 | | | | | 179 |-Rtr. Sol.->| | | | 180 |<-Rtr. Adv.-| | | | 181 | | | | | 182 Pref1::addr1 | | | | 183 conf. (HoA1) | | | | 184 | | | | | 185 |<-----------+--IP flow 1------------->| | 186 | | | | | 187 - o - o - o - o - o Handover to DAR2 o - o - o - o - o - o - 188 | | | | | 189 |--------Rtr. Sol.------->| | | 190 |<-------Rtr. Adv.--------| | | 191 Pref2::addr2 | | | | 192 conf. (HoA2) | | | | 193 |----BU----->| | | | 194 | (CoA=HoA2) | | | | 195 |<---BA------| | | | 196 |(-tnl est.-)| | | | 197 | | | | | 198 |(<---------)+--IP flow 1------------->| | 199 | | | | | 200 |<--------------IP flow 2-+------------------------>| 201 | | | | | 203 Figure 1: Signalling after the first handover 205 In this way, the IPv6 address that the node wants to maintain in use 206 (Pref1::addr1) plays the role of home address (HoA1), and the DAR 207 from where that address was configured plays the role of Home Agent 208 (for that particular address). In this scenario, old flows are 209 anchored to the previous DAR (DAR1), which is in charge to 210 encaspulate the packets and deliver them to the MN's CoA. The IP 211 tunnel is bi-directional, so the MN does the same when sending 212 packets with the old address (HoA1). Conversely, new IP flows are 213 started using the address configured at the new DAR (HoA2). These 214 flows are handled by the new DAR as a plain IPv6 router. 216 Note that the FAMA approach basically enables a mobile node to 217 simultaneously handle several IPv6 addresses -- each of them anchored 218 at a different DAR -- ensuring their continuous reachability by using 219 Mobile IPv6 in a distributed fashion (i.e., each access router is a 220 potential home agent for the address it delegates, if required). 221 Figure 2 illustrates the above case in which the MN is connected to 222 DAR2, but flow1 is anchored at DAR1, because it was started by the MN 223 using the IPv6 address Pref1::addr1, configured when the MN was 224 connected to DAR1. In the same example, the MN starts flow2 using 225 Pref2::addr2, assigned by DAR2. 227 +---+ +---+ 228 |CN1| |CN2| 229 +*--+ +*--+ 230 * * 231 * * 232 ***** * 233 flow1 * * flow2 234 * * 235 * * 236 * * 237 +---*-+ +----*+ +-----+ 238 | * | ___ | *| | | 239 |DAR1**(__*\-+DAR2*+-----+DAR3 | 240 | | \*\| *| | | 241 +-----+ \*\----*+ +-----+ 242 \*\ * 243 \*\ * 244 flow1 using \*--*+ flow2 using 245 Pref1::addr1 |* *| Pref2::addr2 246 |*MN*| 247 +----+ 249 Operations sequence Packets flow 251 Figure 2: MN's flows forwarding in FAMA 253 The same operations take place if the MN moves to another DAR. The 254 MN obtains a new address (Pref3::addr3 - HoA3), which is indicated as 255 CoA in the BU messages sent by the MN to the previous DARs. This 256 distributed address anchoring is enabled on demand and on a per- 257 address granularity, which means that depending on the user needs, it 258 might be the case that all, some or none of the IPv6 addresses that a 259 mobile node configures while moving within a FAMA domain, are kept 260 reachable and used by the mobile. The scheme in Figure 3 depicts the 261 example where the MN updates all the previous DARs, mapping the 262 corresponding HoA with the new CoA 263 +-----+ +-----+ +-----+ +-----+ +-----+ 264 | MN | |DAR1 | |DAR2 | |DAR3 | | CNs | 265 +-----+ +-----+ +-----+ +-----+ +-----+ 266 | | | | | 267 (<-----------)--IP flow 1-------------------------->| 268 | | | | | 269 |<--------------IP flow 2-+------------------------>| 270 | | | | | 271 - o - o - o - o - o Handover to DAR2 o - o - o - o - o - o - 272 | | | | | 273 |--------------Rtr. Sol.-------------->| | 274 |<-------------Rtr. Adv.---------------| | 275 Pref3::addr3 | | | | 276 conf. (HoA3) | | | | 277 |----BU----->| | | | 278 | (CoA=HoA) | | | | 279 |<---BA------| | | | 280 |(-tnl est.-)| | | | 281 |------------BU---------->| | | 282 | (CoA=HoA3) | | | 283 |<-----------BA-----------| | | 284 |(---------tnl est.------)| | | 285 | | | | | 286 |(<---------)+-IP flow 1--------------------------->| 287 | | | | | 288 |(<------------IP flow 2-)+------------------------>| 289 | | | | | 290 |<-------------IP flow 3---------------+----------->| 291 | | | | | 293 Figure 3: Signalling after a second handover 295 In traditional Mobile IPv6, the communication between the MN and the 296 HA is secured through IPsec [RFC4877]. Following a similar approach 297 in FAMA is difficult due to the large number of security associations 298 that would be required, since any gateway of the access network can 299 play the role of home agent for any mobile node. In order to 300 overcome this problem and provide authentication between the DAR and 301 the MNs, we propose the use of Cryptographically Generated Addresses 302 [RFC3972] (CGAs), as introduced in [I-D.laganier-mext-cga]. CGAs are 303 a powerful mechanism allowing authentication of the packets and 304 requires no public-key infrastructure, hence it is well-suited for 305 this application. 307 Following the ideas presented above, every time an MN attaches to a 308 DAR, it configures a CGA from a prefix anchored at the DAR (e.g., by 309 using stateless address auto-configuration mechanisms). This address 310 can then be used by the MN to establish a communication with a remote 311 Correspondent Node (CN) while attached to that particular DAR. If 312 the mobile then moves to a new DAR (nDAR), the following two cases 313 are possible: i) there is no need for the address that was configured 314 at the previous DAR (pDAR) to survive the movement: in this case 315 there is no further action required; ii) the mobile wants to keep the 316 reachability of the address configured at pDAR: in this case Mobile 317 IPv6 is triggered, and the MN sends a Binding Update (BU) message to 318 the pDAR, using the address configured at the previous DAR as home 319 address, and the address configured at the new DAR as care-of 320 address. This BU includes the CGA parameters and signature 321 [I-D.laganier-mext-cga], which are used by the receiving DAR to 322 identify the MN as the legitimate owner of the address. Although the 323 use of CGAs does not impose a heavy burden in terms of performance, 324 depending on the number of MNs handled at the DAR, the processing of 325 the CGAs can be problematic. To reduce the complexity of the 326 proposed protocol, we suggest an alternative mechanism to 327 authenticate any subsequent signaling packets exchanged between the 328 MN and the DAR (in case the mobile performs a new attachment to a 329 different DAR). This alternative method relies on the use of a 330 Permanent Home Keygen Token (PHKT), which will be used to generate 331 the Authorization option that the MN has to include in all next 332 Binding Update messages. This token is forwarded to the MN in the 333 Binding Acknowledgment message, sent on reply to the BU. The 334 procedure is depicted in Figure 4. Once the signaling procedure is 335 completed, a bi-directional tunnel is established between the mobile 336 node and the DAR where the IPv6 address is anchored (the "home" DAR 337 -- HDAR -- for that particular address), so the mobile can continue 338 using the IPv6 address. 340 ------ ------- 341 | MN | | DAR | 342 ------ ------- 343 | | 344 CGA | | 345 config |-- BU + CGA param + signature ------>| 346 | | MN 347 PHKT |<----------------------- BA + PHKT --| auth 348 caching | | 349 | | 350 (first handoff) 352 PHKT | | 353 refresh,| | 354 next |-- BU(PHKT auth) ------------------->| 355 handoffs,| | MN 356 de-reg |<------------------------------ BA --| auth 357 | | 358 | | 359 (subsequent signaling) 361 Figure 4: Signaling between the MN and the DAR 363 In case the MN performs any subsequent movements and it requires to 364 maintain the reachability of an address for which it has already sent 365 a BU, the following BU messages can be secured using the PHKT 366 exchanged before, reducing the computational load at the receiving 367 DAR. 369 Note that on every attachment of a node to a DAR, the terminal also 370 obtains a new IPv6 address which is topologically anchored at that 371 DAR, and that this address can be used for new communications 372 (avoiding in this way the tunneling required when using an address 373 anchored at a different DAR). A mobile can keep multiple IPv6 374 addresses active and reachable at a given time, and that requires to 375 send -- every time the MN moves -- a BU message to all the previous 376 DARs that are anchoring the IP flows that the MN wish to maintain. 378 4. IANA Considerations 380 TBD. 382 5. Security Considerations 384 Although the approach documented in this document is attractive for 385 the reduced signaling overhead caused by the mobility support, it can 386 be misused in some particular scenarios by malicious nodes that wish 387 to export an incorrect CoA in the BU message, since it does provide 388 proof of the MN's reachability at the visited network. Indeed, the 389 CGA approach assures that the BU message has been sent by the 390 legitimate HoA's owner but it does not make sure that same MN to be 391 reachable at the CoA indicated. This requires further analysis. 393 A possible approach to provide a more secure solution is the 394 following: a Return Routability procedure similar to the one defined 395 in MIPv6 Route Optimization can be used to mitigate the 396 aforementioned security issue. The Return Routability procedure 397 starts after the handoff. Instead of sending the BU message, the MN 398 sends a Care-of Test Init message (CoTI). This message is replied by 399 the DAR with a Care-Of Test message containing a CoA Keygen Token. 400 The MN can now send a BU using both Home and CoA Keygen tokens to 401 proof its reachability at both the HoA and the CoA. The message and 402 the knowledge of both tokens is a proof that the MN is the legitimate 403 node who has sent the BU and also is reachable at the CoA indicated. 404 As all security improvements, the one proposed incurs in a 405 performance penalty, in this case an increase in the handover delay. 406 Specifically this enhanced security approach requires four messages 407 to be exchanged between the MN and the DAR instead of the two 408 messages of the original solution. In terms of handover delay, it 409 increases it by a factor of two, as the new solution requires to two 410 Round Trip Times (RTTs) to conclude, instead of one. 412 6. References 414 6.1. Normative References 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, 418 DOI 10.17487/RFC2119, March 1997, 419 . 421 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 422 RFC 3972, DOI 10.17487/RFC3972, March 2005, 423 . 425 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 426 IKEv2 and the Revised IPsec Architecture", RFC 4877, 427 DOI 10.17487/RFC4877, April 2007, 428 . 430 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 431 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 432 RFC 5213, DOI 10.17487/RFC5213, August 2008, 433 . 435 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 436 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 437 2011, . 439 6.2. Informative References 441 [GOB11] Giust, F., de la Oliva, A., and CJ. Bernardos, "Flat 442 Access and Mobility Architecture: an IPv6 Distributed 443 Client Mobility Management solution", 3rd IEEE 444 International Workshop on Mobility Management in the 445 Networks of the Future World (MobiWorld 2011), colocated 446 with IEEE INFOCOM 2011 , 2011. 448 [I-D.laganier-mext-cga] 449 Laganier, J., "Authorizing Mobile IPv6 Binding Update with 450 Cryptographically Generated Addresses", draft-laganier- 451 mext-cga-01 (work in progress), October 2010. 453 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 454 Korhonen, "Requirements for Distributed Mobility 455 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 456 . 458 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 459 CJ. Bernardos, "Distributed Mobility Management: Current 460 Practices and Gap Analysis", RFC 7429, 461 DOI 10.17487/RFC7429, January 2015, 462 . 464 Appendix A. Comparison with Requirement document 466 In this section we descrbe how our solution addresses the DMM 467 requirements listed in [RFC7333]. 469 A.1. Distributed mobility management 471 "IP mobility, network access solutions, and forwarding solutions 472 provided by DMM MUST enable traffic to avoid traversing a single 473 mobility anchor far from the optimal route." 475 In our solution, a DAR is responsible to handle the mobility for 476 those IP flows started when the MN is attached to it. As long as the 477 MN remains connected to the DAR's access links, the IP packets of 478 such flows can benefit from the optimal path. When the MN moves to 479 another DAR, the path becomes non-optimal for ongoing flows, as they 480 are anchored to the previous DAR, but newly started IP sessions are 481 forwarded by the new DAR through the optimal path. 483 A.2. Bypassable network-layer mobility support for each application 484 session 486 "DMM solutions MUST enable network-layer mobility, but it MUST be 487 possible for any individual active application session (flow) to not 488 use it. Mobility support is needed, for example, when a mobile host 489 moves and an application cannot cope with a change in the IP address. 490 Mobility support is also needed when a mobile router changes its IP 491 address as it moves together with a host and, in the presence of 492 ingress filtering, an application in the host is interrupted. 493 However, mobility support at the network layer is not always needed; 494 a mobile node can often be stationary, and mobility support can also 495 be provided at other layers. It is then not always necessary to 496 maintain a stable IP address or prefix for an active application 497 session." 499 Our DMM solution operates at the IP layer, hence upper layers are 500 totally transparent to the mobility operations. In particular, 501 ongoing IP sessions are not disrupted after a change of access 502 network. The routability of the old address is ensured by the IP 503 tunnel with the old DAR. New IP sessions are started with the new 504 address. From the application's perspective, those processes which 505 sockets are bound to a unique IP address do not suffer any impact. 506 For the other applications, the sockets bound to the old address are 507 preserved, whereas next sockets use the new address. 509 A.3. IPv6 deployment 511 "DMM solutions SHOULD target IPv6 as the primary deployment 512 environment and SHOULD NOT be tailored specifically to support IPv4, 513 particularly in situations where private IPv4 addresses and/or NATs 514 are used." 516 The DMM solution we propose targets IPv6 only. 518 A.4. Existing mobility protocols 520 "A DMM solution MUST first consider reusing and extending IETF 521 standard protocols before specifying new protocols." 523 This DMM solution is derived from the operations and messages 524 specified in [RFC6275], [RFC3972], and [I-D.laganier-mext-cga]. 526 A.5. Coexistence with deployed networks/hosts and operability across 527 different networks 529 "A DMM solution may require loose, tight, or no integration into 530 existing mobility protocols and host IP stacks. Regardless of the 531 integration level, DMM implementations MUST be able to coexist with 532 existing network deployments, end hosts, and routers that may or may 533 not implement existing mobility protocols. Furthermore, a DMM 534 solution SHOULD work across different networks, possibly operated as 535 separate administrative domains, when the needed mobility management 536 signaling, forwarding, and network access are allowed by the trust 537 relationship between them" 539 The proposed solution can provide a fallback mechanism employing 540 legacy Mobile IPv6, for instance forcing the MN to use only one DAR. 541 Moreover, this solution applies when the MN is connected to an 542 administrative domain not supporting trust relationships. Indeed, 543 all the IP sessions can remain anchored to the DARs of the "home" 544 domain. Our solution can be deployed across different domains with 545 trust agreements. 547 A.6. Operation and management considerations 549 "A DMM solution needs to consider configuring a device, monitoring 550 the current operational state of a device, and responding to events 551 that impact the device, possibly by modifying the configuration and 552 storing the data in a format that can be analyzed later. 554 The proposed solution can re-use existing mechanisms defined for the 555 operation and management of Mobile IPv6. 557 A.7. Security considerations 559 "A DMM solution MUST support any security protocols and mechanisms 560 needed to secure the network and to make continuous security 561 improvements. In addition, with security taken into consideration 562 early in the design, a DMM solution MUST NOT introduce new security 563 risks or amplify existing security risks that cannot be mitigated by 564 existing security protocols and mechanisms." 566 The proposed solution uses a CGA-based security system to enable 567 authentication and authorization of mobile hosts. 569 A.8. Multicast 571 "DMM SHOULD enable multicast solutions to be developed to avoid 572 network inefficiency in multicast traffic delivery." 573 This solution does not include multicast traffic in its scope. 574 Nevertheless, it allows combining multicast support solutions, such 575 as local subscription at each DAR, which would result in a flexible 576 distribution scenario. 578 Appendix B. Open DMM platform 580 The client-based DMM solution described in this document is available 581 at the Open Distributed Mobility Management (ODMM) project 582 (http://www.odmm.net). The ODMM platform is intended to foster DMM 583 development and deployment, by serving as a framework to host open 584 source implementations. 586 Authors' Addresses 588 Carlos J. Bernardos 589 Universidad Carlos III de Madrid 590 Av. Universidad, 30 591 Leganes, Madrid 28911 592 Spain 594 Phone: +34 91624 6236 595 Email: cjbc@it.uc3m.es 596 URI: http://www.it.uc3m.es/cjbc/ 598 Antonio de la Oliva 599 Universidad Carlos III de Madrid 600 Av. Universidad, 30 601 Leganes, Madrid 28911 602 Spain 604 Phone: +34 91624 8803 605 Email: aoliva@it.uc3m.es 606 URI: http://www.it.uc3m.es/aoliva/ 608 Fabio Giust 609 NEC Laboratories Europe 610 NEC Europe Ltd. 611 Kurfuersten-Anlage 36 612 Heidelberg D-69115 613 Germany 615 Phone: +49 6221 4342216 616 Email: fabio.giust@neclab.eu