idnits 2.17.1 draft-ietf-netlmm-lma-discovery-05.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 (September 13, 2010) is 4967 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network-based Localized Mobility J. Korhonen 3 Management (NetLMM) Nokia Siemens Networks 4 Internet-Draft V. Devarapalli 5 Intended status: Informational Vasona Networks 6 Expires: March 17, 2011 September 13, 2010 8 LMA Discovery for Proxy Mobile IPv6 9 draft-ietf-netlmm-lma-discovery-05.txt 11 Abstract 13 Large Proxy Mobile IPv6 deployments would benefit from a 14 functionality, where a Mobile Access Gateway could dynamically 15 discover a Local Mobility Anchor for a Mobile Node attaching to a 16 Proxy Mobile IPv6 domain. The purpose of the dynamic discovery 17 functionality is to reduce the amount of static configuration in the 18 Mobile Access Gateway. This document describes several possible 19 dynamic Local Mobility Anchor discovery solutions. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 17, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. AAA-based Discovery Solutions . . . . . . . . . . . . . . . . . 3 57 2.1. Receiving LMA Address during the Network Access 58 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Receiving LMA FQDN during the Network Access 60 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Discovery Solutions based on Data from Lower Layers . . . . . . 5 62 3.1. Constructing the LMA FQDN from a Mobile Node Identity . . . 5 63 3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 5 64 3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6 65 4. Handover Considerations . . . . . . . . . . . . . . . . . . . . 6 66 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from 76 a functionality, where a Mobile Access Gateway (MAG) can dynamically 77 discover a Local Mobility Anchor (LMA) for a Mobile Node (MN) 78 attaching to a PMIPv6 domain. The purpose of the dynamic discovery 79 functionality is to reduce the amount of static configuration in the 80 MAG. Other drivers for the dynamic discovery of a LMA include LMA 81 load balancing solutions and selecting a LMA based on desired 82 services (i.e. allowing service-specific routing of traffic) 83 [RFC5149]. This document describes several possible dynamic LMA 84 discovery approaches and makes a recommendation of the preferred one. 86 The following list briefly introduces solution approaches that will 87 be discussed in this document: 89 o LMA Address from AAA during the network access authentication 90 procedure when the MN attaches to the MAG. 92 o LMA FQDN from AAA during the network access authentication, 93 followed by a Domain Name System (DNS) lookup. 95 o LMA FQDN derived from the MN identity received from the lower 96 layers during the network attachment, followed by a DNS lookup. 98 o LMA FQDN or IP address received from the lower layers during the 99 network attachment. The reception of an FQDN from the lower 100 layers is followed by a DNS lookup. 102 o LMA FQDN derived from the service selection indication received 103 from lower layers during the network attachment, followed by a DNS 104 lookup. 106 When a MN performs a handover from one MAG to another, the new MAG 107 must use the same LMA that the old MAG was using. This is required 108 for session continuity. The LMA discovery mechanism in the new MAG 109 should be able to return the information of the same LMA that was 110 being used by the old MAG. This document also discusses solutions 111 for LMA discovery during a handover. 113 2. AAA-based Discovery Solutions 115 This section presents a LMA discovery solution that requires a MAG to 116 be connected to an AAA infrastructure for instance as described in 117 [RFC5779]. The AAA infrastructure is also assumed to be aware of 118 PMIPv6. A MN attaching to a PMIPv6 domain is typically required to 119 provide authentication for network access and to be authorized for 120 mobility services before the MN is allowed to send or receive any IP 121 packets or even complete its IP level configuration. 123 The AAA-based LMA discovery solution hooks into the network access 124 authentication and authorization process. The MAG has also the role 125 of a Network Access Server (NAS) at this step. While the MN is 126 attaching to the network, the PMIPv6 related parameters are 127 bootstrapped in parallel with authentication for the network access 128 and authorization for the mobility services. The PMIPv6 parameters 129 bootstrapping involves the Policy Profile download over the AAA 130 infrastructure to the MAG (see Appendix A of [RFC5213]). 132 2.1. Receiving LMA Address during the Network Access Authentication 134 After the MN has successfully authenticated for the network access 135 and authorized for the mobility service, the MAG receives the LMA IP 136 address(es) from the AAA server over the AAA infrastructure. The LMA 137 IP address information would be part of the AAA message that ends the 138 successful authentication and authorization AAA exchange. 140 Once the MAG receives the LMA IP address(es), it sends Proxy Binding 141 Update (PBU) message for the newly authenticated and authorized MN. 142 The MAG expects that the LMA returned by the AAA server is able to 143 provide mobility session continuity for the MN, i.e. after a handover 144 the LMA would be the same one the MN already has a mobility session 145 set up with. 147 2.2. Receiving LMA FQDN during the Network Access Authentication 149 This solution is similar to the procedure described in Section 2.1. 150 The difference is that the MAG receives a Fully Qualified Domain Name 151 (FQDN) of the LMA instead of the IP address(es). The MAG has to 152 query the DNS infrastructure in order to resolve the FQDN to the LMA 153 IP address(es). 155 The LMA FQDN might be a generic name for a PMIPv6 domain that 156 resolves to one or more LMAs in the PMIPv6 domain. Alternatively the 157 LMA FQDN might be resolved to exactly one LMA within the PMIPv6 158 domain. The latter approach would obviously be useful if a new 159 target MAG after a handover should resolve the LMA FQDN to the LMA IP 160 address where the MN mobility session is already located. 162 The procedures described in this section and in Section 2.1 may also 163 be used together. For example, the AAA server might return a generic 164 LMA FQDN during the MN initial attach and once the LMA gets selected, 165 return the LMA IP address during the subsequent attachments to other 166 MAGs in the PMIPv6 domain. In order for this to work, the resolved 167 and selected LMA IP address must be updated to the remote Policy 168 Store. For example, the LMA could perform the update once it 169 receives the initial PBU from the MAG for the new mobility session. 171 3. Discovery Solutions based on Data from Lower Layers 173 The following section discusses solutions, where a MAG acquires 174 information from layers below the IP layer. Based on this 175 information, the MAG is able to determine which LMA to contact when 176 the MN attaches to the MAG. The lower layers discussed here are not 177 explicitly defined but include different radio access technologies 178 and tunneling solutions such as IKEv2 [RFC4306] IPsec tunnel 179 [RFC4303]. 181 3.1. Constructing the LMA FQDN from a Mobile Node Identity 183 A MAG acquires a MN identity from lower layers. The MAG can use the 184 information embedded in the identity to construct a generic LMA FQDN 185 (based on some pre-configured formatting rules) and then proceed to 186 resolve the LMA IP address(es) using the DNS. Obviously, the MN 187 identity must embed information that can be used to uniquely identify 188 the entity hosting and operating the LMA for the MN. Examples of 189 such MN identities are the International Mobile Subscriber Identity 190 (IMSI) and Globally Unique Temporary User Equipment Identity (GUTI) 191 [3GPP.23.003]. These MN identities contain information that can 192 uniquely identify the operator where the subscription belongs to. 194 3.2. Receiving LMA FQDN or IP Address from Lower Layers 196 The solution described here is similar to the solution discussed in 197 Section 3.1. A MAG receives a LMA FQDN or an IP address from lower 198 layers, for example, as a part of the normal lower layer signaling 199 when the MN attaches to the network. IKEv2 could be existing example 200 of such lower layer signaling where IPsec is the "lower layer" for 201 the MN [3GPP.24.302]. IKEv2 has an IKEv2 IDr payload, which is used 202 by the IKEv2 initiator (i.e. the MN in this case) to specify which of 203 the responder's identities (i.e. the LMA in this case) it wants to 204 talk to. And here the responder identity could be an FQDN or an IP 205 address of the LMA (as the IKEv2 identification payload can be an IP 206 address or an FQDN). Another existing example is the Access Point 207 Name Information Element (APN IE) in 3GPP radio's network access 208 signaling capable of carrying a FQDN [3GPP.24.008]. However, in 209 general this means the MN is also the originator of the LMA 210 information. The LMA information content as such can be transparent 211 to the MN, meaning the MN does not associate the information with any 212 LMA function. 214 3.3. Constructing the LMA FQDN from a Service Name 216 Some network access technologies (including tunneling solutions) 217 allow the MN to signal the service name that identifies a particular 218 service or the external network it wants to access [3GPP.24.302] 219 [RFC4306]. If the MN originated service name also embeds the 220 information of the entity hosting the service or the hosting 221 information can be derived from other information available at the 222 same time (e.g., see Section 3.1), then the MAG can construct a 223 generic LMA FQDN (e.g., based on some pre-defined formatting rules) 224 providing an access to the service or the external network. The pre- 225 defined formatting rules [3GPP.23.003] are usually agreed on among 226 operators that belong to the same inter-operator roaming consortium 227 or by network infrastructure vendors defining an open networking 228 system architecture. 230 Once the MAG has the FQDN it can proceed to resolve the LMA IP 231 address(es) using the DNS. An example of such service or external 232 network name is the Access Point Name (APN) [3GPP.23.003] that 233 contain information of the operator providing the access to the given 234 service or the external network. 236 4. Handover Considerations 238 Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all 239 the MAGs that the MN attaches to, should use the same LMA. If there 240 is only one LMA per PMIPv6 domain, then there is no issue. If there 241 is a context transfer mechanism available between the MAGs, then the 242 new MAG knows the LMA information from the old MAG. Such a mechanism 243 is described in [I-D.ietf-mipshop-pfmipv6]. If the MN related 244 context is not transferred between the MAGs, then a mechanism to 245 deliver the current LMA information to the new MAG is required. 247 Relying on DNS during handovers is not generally a working solution 248 if the PMIPv6 domain has more than one LMA, unless the DNS 249 consistently assigns a specific LMA for each given MN. In most cases 250 described in Section 3, where the MAG derives the LMA FQDN, there is 251 no prior knowledge whether the LMA FQDN resolves to one or more LMA 252 IP address(es) in the PMIPv6 domain. However, depending on the 253 deployment and deployment related regulation (such as inter-operator 254 roaming consortium agreements) the situation might not be this 255 desperate. For example, a MAG might be able to synthesize a LMA 256 specific FQDN (e.g. out of MN identity or some other service specific 257 parameters). Alternatively, the MAG could use (for example), a MN 258 identity as an input to an algorithm that deterministically assigns 259 the same LMA out of a pool of LMAs (assuming the MAG has e.g. learned 260 a group of LMA FQDNs via SRV [RFC2782] query). These approaches 261 would guarantee that DNS returns always the same LMA Address to the 262 MAG. 264 Once the MN completes its initial attachment to a PMIPv6 domain, the 265 information about the LMA that is selected to serve the MN is stored 266 in the Policy Store (or the AAA server). The LMA information is 267 conveyed to the policy store by the LMA after the initial attachment 268 is completed [RFC5779]. Typically AAA infrastructure is used for 269 exchanging information between the LMA and the Policy Store. 271 When the MN moves and attaches to another MAG in the PMIPv6 domain, 272 then the AAA servers delivers the existing LMA information to the new 273 MAG as part of the authentication and authorization procedure as 274 described in Section 2.1 276 5. Recommendations 278 This document discussed several solution approaches for a dynamic LMA 279 discovery. All discussed solution approaches actually require 280 additional functionality or infrastructure support that the base 281 PMIPv6 [RFC5213] does not require. 283 Solutions in Section 3 all depend on lower layers being able to 284 provide information that a MAG can then use to query DNS and discover 285 a suitable LMA. The capabilities of the lower layers and the 286 interactions with them are generally out of scope of IETF, and 287 specific to a certain system and architecture. 289 Solutions in Section 2 depend on the existence of an AAA 290 infrastructure, which is able to provide a MAG either a LMA IP 291 address or a LMA FQDN. While there can be system and architecture 292 specific details regarding the AAA interactions, the dynamic LMA 293 discovery can be entirely implemented using protocols and 294 technologies developed in IETF. Therefore, using AAA based LMA 295 discovery solutions are recommended by this document. 297 6. Security Considerations 299 The use of DNS for obtaining the IP address of a mobility agent 300 carries certain security risks. These are explained in detail in 301 Section 9.1 of [RFC5026]. However, the risks described in [RFC5026] 302 are mitigated to a large extent in this document, since the MAG and 303 the LMA belong to the same PMIPv6 domain. The DNS server that the 304 MAG queries is also part of the same PMIPv6 domain. Even if the MAG 305 obtains the IP address of a bogus LMA from a bogus DNS server, 306 further harm is prevented since the MAG and the LMA should 307 authenticate each other before exchanging PMIPv6 signaling messages. 308 [RFC5213] specifies the use of IKEv2 between the MAG and the LMA to 309 authenticate each other and setup IPsec security associations for 310 protecting the PMIPv6 signaling messages. 312 The AAA infrastructure may be used to transport the LMA discovery 313 related information between the MAG and the AAA server via one or 314 more AAA brokers and/or AAA proxies. In this case the MAG to the AAA 315 server communication relies on the security properties of the 316 intermediate AAA brokers and AAA proxies. 318 7. IANA Considerations 320 This document has no actions for IANA. 322 8. Acknowledgements 324 The authors would like to thank Julien Laganier, Christian Vogt, 325 Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin Wu, 326 Jari Arkko and Xiangsong Cui for their comments, extensive 327 discussions and suggestions on this document. 329 9. Informative References 331 [3GPP.23.003] 332 3GPP, "Numbering, addressing and identification", 3GPP 333 TS 23.003 8.2.0, September 2008. 335 [3GPP.24.008] 336 3GPP, "Mobile radio interface Layer 3 specification", 3GPP 337 TS 24.008 8.6.0, June 2009. 339 [3GPP.24.302] 340 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via 341 non-3GPP access networks", 3GPP TS 24.302 10.0.0, 342 June 2010. 344 [I-D.ietf-mipshop-pfmipv6] 345 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 346 Xia, "Fast Handovers for Proxy Mobile IPv6", 347 draft-ietf-mipshop-pfmipv6-14 (work in progress), 348 May 2010. 350 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 351 specifying the location of services (DNS SRV)", RFC 2782, 352 February 2000. 354 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 355 RFC 4303, December 2005. 357 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 358 RFC 4306, December 2005. 360 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 361 Bootstrapping in Split Scenario", RFC 5026, October 2007. 363 [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 364 Selection for Mobile IPv6", RFC 5149, February 2008. 366 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 367 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 369 [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 370 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 371 Gateway and Local Mobility Anchor Interaction with 372 Diameter Server", RFC 5779, February 2010. 374 Authors' Addresses 376 Jouni Korhonen 377 Nokia Siemens Networks 378 Linnoitustie 6 379 FIN-02600 Espoo 380 Finland 382 Email: jouni.nospam@gmail.com 384 Vijay Devarapalli 385 Vasona Networks 387 Email: dvijay@gmail.com