idnits 2.17.1 draft-bernardos-mext-dmm-cmip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 7, 2011) is 4798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-chan-distributed-mobility-ps-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group CJ. Bernardos 3 Internet-Draft A. de la Oliva 4 Intended status: Informational UC3M 5 Expires: September 8, 2011 F. Giust 6 IMDEA Networks and UC3M 7 March 7, 2011 9 A IPv6 Distributed Client Mobility Management approach using existing 10 mechanisms 11 draft-bernardos-mext-dmm-cmip-00 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 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 8, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Description of the solution . . . . . . . . . . . . . . . . . . 4 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Most of the currently standardized IP mobility solutions, like Mobile 75 IPv6 [RFC3775], or Proxy Mobile IPv6 [RFC5213] rely to a certain 76 extent on a centralized mobility anchor entity. This centralized 77 network node is in charge of both the control of the network entities 78 involved in the mobility management (i.e., it is a central point for 79 the control signalling), and the user data forwarding (i.e., it is 80 also a central point for the user plane). This makes centralized 81 mobility solutions prone to several problems and limitations, as 82 identified in [I-D.chan-distributed-mobility-ps]: longer (sub- 83 optimal) routing paths, scalability problems, signaling overhead (and 84 most likely a longer associated handover latency), more complex 85 network deployment, higher vulnerability due to the existence of a 86 potential single point of failure, and lack of granularity on the 87 mobility management service (i.e., mobility is offered on a per-node 88 basis, not being possible to define finer granularity policies, as 89 for example per-application). 91 There are basically two main approaches that are being researched 92 now: one aimed at making Mobile IPv6 work in a distributed way, and 93 another one doing the same exercise for Proxy Mobile IPv6. In this 94 draft we describe a solution to achieve a DMM behavior with a CMIP 95 (MIPv6) solution. This document is based on a research paper of the 96 same authors, called "Flat Access and Mobility Architecture: an IPv6 97 Distributed Client Mobility Management solution" [GOB+11]. 99 2. Terminology 101 The following terms used in this document are defined in the Mobile 102 IPv6 specification [RFC3775]: 104 Home Agent (HA) 106 Home Link 108 Home Address (HoA) 110 Care-of Address (CoA) 112 Binding Update (BU) 114 Binding Acknowledgement (BA) 116 The following terms are defined and used in this document: 118 DAR (Distributed Anchor Router). First hop routers where the mobile 119 nodes attach to. They also play the role of mobility managers for 120 the IPv6 addresses they anchor. 122 HDAR (Home Distributed Anchor Router). DAR which plays the role of 123 Home Agent for a particular IPv6 address (i.e., DAR where that 124 IPv6 address is anchored). 126 3. Description of the solution 128 Distributed Mobility Management approaches try to overcome the 129 limitations of the traditional centralized mobility management, i.e., 130 Mobile IP, by bringing the mobility anchor closer to the MN. 131 Following this idea, in our approach -- that we call Flat Access and 132 Mobility Architecture (FAMA) -- the MIPv6 centralized home agent is 133 moved to the edge of the network, being deployed in the default 134 gateway of the mobile node. That is, the first elements that provide 135 IP connectivity to a set of MNs are also the mobility managers for 136 those MNs. In the following we will call these access routers 137 Distributed Anchor Routers (DARs). 139 Every time a mobile node attaches to a distributed anchor router, it 140 gets an IPv6 address which is topologically anchored at the DAR. 141 That means that while attached to this DAR, the mobile can send and 142 receive traffic using that address without using any tunneling nor 143 special packet handling. Every time the mobile node moves to a 144 different DAR, it gets a new IPv6 address from the new access router. 145 In case the MN wants to keep the reachability of the IPv6 address(es) 146 it obtained from the previous DAR (note that this decision is dynamic 147 and it is out of scope of this document, it can be done on an 148 application basis for example), the mobile has to involve its MIPv6 149 stack, by sending a Binding Update to the DAR where the IPv6 address 150 is anchored, using the address obtained from the current DAR as 151 care-of address. In this way, the IPv6 address that the node wants 152 to maintain plays the role of home address, and the DAR from where 153 that address was configured plays the role of Home Agent (for that 154 particular address). Note that the FAMA approach basically enables a 155 mobile node to simultaneously handle several IPv6 addresses -- each 156 of them anchored at a different DAR -- ensuring their continuous 157 reachability by using Mobile IPv6 in a distributed fashion (i.e., 158 each access router is a potential home agent for the address it 159 delegates, if required). This distributed address anchoring is 160 enabled on demand and on a per-address granularity, which means that 161 depending on the user needs, it might be the case that all, some or 162 none of the IPv6 addresses that a mobile node configures while moving 163 within a FAMA domain, are kept reachable and used by the mobile. 165 In traditional Mobile IPv6, the communication between the MN and the 166 HA is secured through IPsec [RFC4877]. Following a similar approach 167 in FAMA is difficult due to the large number of security associations 168 that would be required, since any gateway of the access network can 169 play the role of home agent for any mobile node. In order to 170 overcome this problem and provide authentication between the DAR and 171 the MNs, we propose the use of Cryptographically Generated Addresses 172 [RFC3972] (CGAs), as introduced in [I-D.laganier-mext-cga]. CGAs are 173 a powerful mechanism allowing authentication of the packets and 174 requires no public-key infrastructure, hence it is well-suited for 175 this application. 177 Following the ideas presented above, every time an MN attaches to a 178 DAR, it configures a CGA from a prefix anchored at the DAR (e.g., by 179 using stateless address auto-configuration mechanisms). This address 180 can then be used by the MN to establish a communication with a remote 181 Correspondent Node (CN) while attached to that particular DAR. If 182 the mobile then moves to a new DAR (nDAR), the following two cases 183 are possible: i) there is no need for the address that was configured 184 at the previous DAR (pDAR) to survive the movement: in this case 185 there is no further action required; ii) the mobile wants to keep the 186 reachability of the address configured at pDAR: in this case Mobile 187 IPv6 is triggered, and the MN sends a Binding Update (BU) message to 188 the pDAR, using the address configured at the previous DAR as home 189 address, and the address configured at the new DAR as care-of 190 address. This BU includes the CGA parameters and signature 191 [I-D.laganier-mext-cga], which are used by the receiving DAR to 192 identify the MN as the legitimate owner of the address. Although the 193 use of CGAs does not impose a heavy burden in terms of performance, 194 depending on the number of MNs handled at the DAR, the processing of 195 the CGAs can be problematic. To reduce the complexity of the 196 proposed protocol, we suggest an alternative mechanism to 197 authenticate any subsequent signaling packets exchanged between the 198 MN and the DAR (in case the mobile performs a new attachment to a 199 different DAR). This alternative method relies on the use of a 200 Permanent Home Keygen Token (PHKT), which will be used to generate 201 the Authorization option that the MN has to include in all next 202 Binding Update messages. This token is forwarded to the MN in the 203 Binding Acknowledgment message, sent on reply to the BU. The 204 procedure is depicted in Figure 1. Once the signaling procedure is 205 completed, a bi-directional tunnel is established between the mobile 206 node and the DAR where the IPv6 address is anchored (the "home" DAR 207 -- HDAR -- for that particular address), so the mobile can continue 208 using the IPv6 address. 210 ------ ------- 211 | MN | | DAR | 212 ------ ------- 213 | | 214 CGA | | 215 config |-- BU + CGA param + signature ------>| 216 | | MN 217 PHKT |<----------------------- BA + PHKT --| auth 218 caching | | 219 | | 220 (first handoff) 222 PHKT | | 223 refresh,| | 224 next |-- BU(PHKT auth) ------------------->| 225 handoffs,| | MN 226 de-reg |<------------------------------ BA --| auth 227 | | 228 | | 229 (subsequent signaling) 231 Figure 1: Signaling between the MN and the DAR 233 In case the MN performs any subsequent movements and it requires to 234 maintain the reachability of an address for which it has already sent 235 a BU, the following BU messages can be secured using the PHKT 236 exchanged before, reducing the computational load at the receiving 237 DAR. 239 Note that on every attachment of a node to a DAR, the terminal also 240 obtains a new IPv6 address which is topologically anchored at that 241 DAR, and that this address can be used for new communications 242 (avoiding in this way the tunneling required when using an address 243 anchored at a different DAR). A mobile can keep multiple IPv6 244 addresses active and reachable at a given time, and that requires to 245 send -- every time the MN moves -- a BU message to all the previous 246 DARs that are anchoring the IP flows that the MN wish to maintain. 248 4. IANA Considerations 250 TBD. 252 5. Security Considerations 254 Although the approach documented in this document is attractive for 255 the reduced signaling overhead caused by the mobility support, it can 256 be misused in some particular scenarios by malicious nodes that wish 257 to export an incorrect CoA in the BU message, since it does provide 258 proof of the MN's reachability at the visited network. Indeed, the 259 CGA approach assures that the BU message has been sent by the 260 legitimate HoA's owner but it does not make sure that same MN to be 261 reachable at the CoA indicated. This requires further analysis. 263 A possible approach to provide a more secure solution is the 264 following: a Return Routability procedure similar to the one defined 265 in MIPv6 Route Optimization can be used to mitigate the 266 aforementioned security issue. The Return Routability procedure 267 starts after the handoff. Instead of sending the BU message, the MN 268 sends a Care-of Test Init message (CoTI). This message is replied by 269 the DAR with a Care-Of Test message containing a CoA Keygen Token. 270 The MN can now send a BU using both Home and CoA Keygen tokens to 271 proof its reachability at both the HoA and the CoA. The message and 272 the knowledge of both tokens is a proof that the MN is the legitimate 273 node who has sent the BU and also is reachable at the CoA indicated. 274 As all security improvements, the one proposed incurs in a 275 performance penalty, in this case an increase in the handover delay. 276 Specifically this enhanced security approach requires four messages 277 to be exchanged between the MN and the DAR instead of the two 278 messages of the original solution. In terms of handover delay, it 279 increases it by a factor of two, as the new solution requires to two 280 Round Trip Times (RTTs) to conclude, instead of one. 282 6. Acknowledgments 284 The research leading to these results has received funding from the 285 European Community's Seventh Framework Programme (FP7-ICT-2009-5) 286 under grant agreement n. 258053 (MEDIEVAL project). The work of 287 Carlos J. Bernardos has also been partially supported by the Ministry 288 of Science and Innovation of Spain under the QUARTET project 289 (TIN2009-13992-C02-01). 291 7. References 293 7.1. Normative References 295 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 296 in IPv6", RFC 3775, June 2004. 298 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 299 RFC 3972, March 2005. 301 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 302 IKEv2 and the Revised IPsec Architecture", RFC 4877, 303 April 2007. 305 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 306 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 308 7.2. Informative References 310 [GOB+11] Giust, F., de la Oliva, A., and CJ. Bernardos, "Flat 311 Access and Mobility Architecture: an IPv6 Distributed 312 Client Mobility Management solution", 3rd IEEE 313 International Workshop on Mobility Management in the 314 Networks of the Future World (MobiWorld 2011), colocated 315 with IEEE INFOCOM 2011 , 2011. 317 [I-D.chan-distributed-mobility-ps] 318 Chan, A., Liu, D., Seite, P., Yokota, H., Perkins, C., 319 Melia, T., Haddad, W., Demaria, E., Deng, H., and Z. Cao, 320 "Problem statement for distributed and dynamic mobility 321 management", draft-chan-distributed-mobility-ps-00 (work 322 in progress), October 2010. 324 [I-D.laganier-mext-cga] 325 Laganier, J., "Authorizing Mobile IPv6 Binding Update with 326 Cryptographically Generated Addresses", 327 draft-laganier-mext-cga-01 (work in progress), 328 October 2010. 330 Authors' Addresses 332 Carlos J. Bernardos 333 Universidad Carlos III de Madrid 334 Av. Universidad, 30 335 Leganes, Madrid 28911 336 Spain 338 Phone: +34 91624 6236 339 Email: cjbc@it.uc3m.es 340 URI: http://www.it.uc3m.es/cjbc/ 341 Antonio de la Oliva 342 Universidad Carlos III de Madrid 343 Av. Universidad, 30 344 Leganes, Madrid 28911 345 Spain 347 Phone: +34 91624 8803 348 Email: aoliva@it.uc3m.es 349 URI: http://www.it.uc3m.es/aoliva/ 351 Fabio Giust 352 Institute IMDEA Networks and Universidad Carlos III de Madrid 353 Av. del Mar Mediterraneo, 22 354 Leganes, Madrid 28918 355 Spain 357 Email: fabio.giust@imdea.org