idnits 2.17.1 draft-ietf-netlmm-lma-discovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 24, 2010) is 5173 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-mipshop-pfmipv6-12 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 WiChorus 6 Expires: August 28, 2010 February 24, 2010 8 LMA Discovery for Proxy Mobile IPv6 9 draft-ietf-netlmm-lma-discovery-03.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 specification describes a number of 19 possible dynamic Local Mobility Anchor discovery solutions. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 28, 2010. 44 Copyright Notice 46 Copyright (c) 2010 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 BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. AAA-based Discovery Solutions . . . . . . . . . . . . . . . . 3 63 2.1. Receiving LMA Address during the Network Access 64 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Receiving LMA FQDN during the Network Access 66 Authentication . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Lower Layers based Discovery Solutions . . . . . . . . . . . . 5 68 3.1. Constructing the LMA FQDN from a mobile node Identity . . 5 69 3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 6 70 3.3. Constructing the LMA FQDN from a Service Name . . . . . . 6 71 4. Domain Name System Considerations . . . . . . . . . . . . . . 6 72 5. Handover Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 76 9. Informative References . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit 82 from a functionality, where a Mobile Access Gateway (MAG) could 83 dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node 84 (MN) attaching to a PMIPv6 domain. The purpose of the dynamic 85 discovery functionality is to reduce the amount of static 86 configuration in the MAG. Other drivers for the dynamic discovery of 87 a LMA include LMA load balancing solutions and selecting LMA based on 88 desired services (i.e. allowing service-specific routing of traffic). 89 This document describes a number of possible dynamic LMA discovery 90 solutions. 92 There are a number of different ways for dynamically discovering the 93 LMA at the MAG. The following list briefly introduces solutions that 94 will be discussed in this specification: 96 o LMA Address from AAA during the network access authentication 97 procedure when the MN attaches to the MAG. 99 o LMA FQDN from AAA during the network access authentication, 100 followed by a Domain Name System (DNS) lookup. 102 o LMA FQDN derived from the MN identity received from the lower 103 layers during the network attachment, followed by a DNS lookup. 105 o LMA FQDN or IP address received from the lower layers during the 106 network attachment followed by an optional DNS lookup. 108 o LMA FQDN derived from the service selection indication received 109 from lower layers during the network attachment, followed by a DNS 110 lookup. 112 When a MN performs a handover from one MAG to another, the new MAG 113 must use the same LMA that the old MAG was using. This is required 114 for session continuity. The LMA discovery mechanism used by the new 115 MAG should be able to return the information about the same LMA that 116 was being used by the old MAG. This document also discusses 117 solutions for LMA discovery during a handover. 119 2. AAA-based Discovery Solutions 121 This section presents a LMA discovery solution that requires a MAG to 122 be connected to an AAA infrastructure. The AAA infrastructure is 123 also assumed to be aware of and support PMIPv6 functionality. A MN 124 attaching to a PMIPv6 domain is typically required to authenticate to 125 the network access and to be authorized for the mobility services 126 before the MN is allowed to send or receive any IP packets or even 127 complete its IP level configuration. 129 The AAA-based LMA discovery solution hooks into the network access 130 authentication and authorization procedure. The MAG has also the 131 role of a Network Access Server (NAS) at this step. While the MN is 132 attaching to the network, the PMIPv6 related parameters are 133 bootstrapped at the same time the MN is authenticated for the network 134 access and authorized for the mobility services using the AAA 135 infrastructure. The PMIPv6 parameters bootstrapping involves the 136 Policy Profile download over the AAA infrastructure to the MAG. The 137 procedure for the Policy Profile download resembles largely the 138 client Mobile IPv6 Integrated Scenario bootstrapping [RFC5447]. 140 2.1. Receiving LMA Address during the Network Access Authentication 142 After the MN has successfully authenticated for the network access 143 and authorized for the mobility service, the MAG receives the LMA IP 144 address(es) from the AAA server over the AAA infrastructure. The LMA 145 IP address information would be part of the AAA message(s) that ends 146 the successful authentication and authorization AAA exchange. 148 Once the MAG receives the LMA IP address(es), it sends Proxy Binding 149 Update (PBU) message for the newly authenticated and authorized MN. 150 The MAG trusts that the LMA returned by the AAA server is able to 151 provide mobility session continuity for the MN, i.e. after a handover 152 the LMA would be the same the MN already has a mobility session set 153 up with. 155 2.2. Receiving LMA FQDN during the Network Access Authentication 157 This solution is identical to the procedure described in Section 2.1. 158 The difference is that the MAG receives a Fully Qualified Domain Name 159 (FQDN) of the LMA instead of the IP address(es). The MAG has to 160 query the DNS infrastructure in order to resolve the FQDN to the LMA 161 IP address(es). 163 The LMA FQDN might be a generic to a PMIPv6 domain resolving to one 164 or more LMAs in the said domain. Alternatively the LMA FQDN might 165 resolve to exactly one LMA within the PMIPv6 domain. The latter 166 approach would obviously be useful if a new target MAG after a 167 handover should resolve the LMA FQDN to the LMA IP address where the 168 MN mobility session is already located. 170 The procedures described in this section and in Section 2.1 may also 171 be used together. For example, the AAA server might return a generic 172 LMA FQDN during the MN initial attach and once the LMA gets selected, 173 return the LMA IP address during the subsequent attachments to other 174 MAGs in the PMIPv6 domain. In order for this to work, the resolved 175 and selected LMA IP address must be updated to the remote Policy 176 Store. For example, the LMA could perform the update once it 177 receives the initial PBU from the MAG for the new mobility session. 179 3. Lower Layers based Discovery Solutions 181 The following section discusses solutions, where the MAG receives 182 information from lower layers below the IP layer when the MN attaches 183 to the MAG. Based on this information, the MAG is then able to 184 determine which LMA to contact. These solution could essentially 185 allow large PMIPv6 deployments without the AAA infrastructure. The 186 lower layers discussed here are not explicitly defined but could 187 include different radio access technologies and tunneling solutions 188 such as IKEv2 [RFC4306] IPsec tunnel [RFC4303]. 190 3.1. Constructing the LMA FQDN from a mobile node Identity 192 Depending on the actual network access technology, the MAG may be 193 able to receive a MN identity (or actually the subscription identity 194 but from now on we assume that the MN identity equals to the 195 subscription identity, which is a rather broad simplification) as a 196 result of the network access attachment procedure. The MN may signal 197 its identity as part of the attachment signaling or alternatively the 198 MAG receives the MN identity from a remote policy store. 200 Once the MAG has acquired the MN identity, the MAG can use the 201 information embedded in the identity to construct a generic LMA FQDN 202 (based on some pre-configured formatting rules) and then proceed to 203 resolve the LMA IP address(es) using the DNS. Obviously, the MN 204 identity must embed information elements that can be extracted and at 205 minimum used to determine the entity hosting and operating the LMA 206 for the MN. Thus the MN identity in this solution cannot be a "flat" 207 identity without any structure and "clear text" parts containing the 208 hosting entity information. Examples of such identities are the 209 International Mobile Subscriber Identity (IMSI) or Globally Unique 210 Temporary User Equipment Identity (GUTI) [3GPP.23.003] that both 211 contain information of the operator owning the given subscription. 213 The solution discussed in this section has issues if MN's identity 214 does not embed enough information. In a case the MN identity does 215 not embed any LMA hosting entity information, the MAG might use a 216 local database to map MN identities to corresponding LMAs. However, 217 this solution is unlikely to scale outside a limited PMIPv6 domain. 219 3.2. Receiving LMA FQDN or IP Address from Lower Layers 221 The solution described in this section is similar to the solution 222 discussed in Section 3.1. Instead of deriving the LMA FQDN from the 223 MN identity, the MAG receives a LMA FQDN or an IP address information 224 from lower layers, for example, as a part of the normal lower layer 225 signaling when the MN attaches to the network. IKEv2 could be 226 existing example of such lower layer signaling when IPsec is the 227 "lower layer" for the MN. IKEv2 has an IKEv2 IDr payload, which is 228 used by the IKEv2 initiator (i.e. the MN in this case) to specify 229 which of the responder's identities (i.e. the LMA in this case) it 230 wants to talk to. And here the responder indentity could be an FQDN 231 or an IP address of the LMA (as the IKEv2 identification payload can 232 be an IP address or an FQDN). Another existing example is the Access 233 Point Name Information Element (APN IE) in 3GPP radio's network 234 access signaling capable of carrying a FQDN [3GPP.24.008]. However, 235 in general this means the MN is also the originator of the LMA 236 information. The LMA information content as such can be transparent 237 to the MN, meaning the MN has no knowledge it being anything LMA 238 related. 240 3.3. Constructing the LMA FQDN from a Service Name 242 Some network access technologies (including tunneling solutions) 243 allow the MN to signal the service name that identifies a particular 244 service or the external network it wants to access. If the MN 245 originated service name also embeds the information of the entity 246 hosting the service or the hosting information can be derived from 247 other information available at the same time (e.g., see Section 3.1), 248 then the MAG can construct a generic LMA FQDN (e.g., based on some 249 pre-defined formatting rules) providing an access to the service or 250 the external network. The pre-defined formatting rules are usually 251 agreed on among operators that belong to the same inter-operator 252 roaming consortium or by network infrastructure vendors defining an 253 open networking system architecture. 255 Once the MAG has the FQDN it can proceed to resolve the LMA IP 256 address(es) using the DNS. An example of such service or external 257 network name is the Access Point Name (APN) [3GPP.23.003] that 258 contain information of the operator providing the access to the given 259 service or the external network. 261 4. Domain Name System Considerations 263 A number of LMA discovery solutions described in Section 2 and 264 Section 3 eventually depend on the DNS. This section discusses 265 impacts of the DNS response caching and issues related to the Dynamic 266 DNS [RFC2136] updates. 268 The caching (positive or negative) properties of the DNS [RFC2308] 269 and the fact that updates to the DNS take time to propagate globally, 270 need to be considered when applying DNS-based solutions to the PMIPv6 271 domain. First, the caching of DNS responses effectively delay the 272 propagation of up to date FQDN to IP address mappings (after both 273 addition and deletion). Hosts in the PMIPv6 domain keep using the 274 stale cached DNS response (positive or negative) until they give up 275 or the caching times out. The delay can be in order of hours in the 276 worst case. On the other hand, DNS administrators can lower the 277 resource record caching time (the Time To Live (TTL) value). 278 Obviously, too low TTL values increase the number of DNS queries 279 considerably. Second, the secondary DNS servers do not get 280 immediately updated when the masters do. These updates are also 281 periodic, usually in order of several hours, and may cause 282 considerable delay on global propagation of the updated naming 283 information. Third, some DNS resolvers ignore low TTLs, replacing 284 them with a higher default value. This could lead to outdated LMA 285 information being around for longer than desired. 287 The above considerations are valid when, for example, the PMIPv6 288 domain LMA availability or load information is dynamically updated 289 into the DNS. There are incentives for doing so, however, the 290 concerns described above need to be understood clearly in that case. 292 5. Handover Considerations 294 Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all 295 the MAGs that the MN attaches to, should use the same LMA. If there 296 is only one LMA per PMIPv6 domain, then there is no issue. If there 297 is a context transfer mechanism available between the MAGs, then the 298 new MAG knows the LMA information from the old MAG. Such a mechanism 299 is described in [I-D.ietf-mipshop-pfmipv6]. If the MN related 300 context is not transferred between the MAGs, then a mechanism to 301 deliver the current LMA information to the new MAG is required. 303 Relying on DNS during handovers is not generally a working solution 304 if the PMIPv6 domain has more than one LMA, unless the DNS 305 consistently assigns a specific LMA for each given MN. In most cases 306 described in Section 3, where the MAG derives the LMA FQDN, there is 307 no prior knowledge whether the LMA FQDN resolves to one or more LMA 308 IP address(es) in the PMIPv6 domain. However, depending on the 309 deployment and deployment related regulation (such as inter-operator 310 roaming consortium agreements) the situation might not be this 311 desperate. For example, a MAG might be able to synthesize a LMA 312 specific FQDN (e.g. out of MN identity or some other service specific 313 parameters). Another alternative could that MAG uses, for example, a 314 MN identity as an input to an algorithm that deterministically 315 assigns the same LMA out of a pool of LMAs (assuming the MAG has e.g. 316 learned a group of LMA FQDNs via SRV [RFC2782] query). These 317 approaches would guarantee that DNS returns always the same LMA 318 Address to the MAG. 320 Once the MN completes its initial attachment to a PMIPv6 domain, the 321 information about the LMA that is selected to serve the MN is stored 322 in the Policy Store (or the AAA server). The LMA information is 323 conveyed to the policy store by the LMA after the initial attachment 324 is completed [I-D.ietf-dime-pmip6]. Typically AAA infrastructure is 325 used for exchanging information between the LMA and the Policy Store. 327 When the MN moves and attaches to another MAG in the PMIPv6 domain, 328 then the AAA servers delivers the existing LMA information to the new 329 MAG as part of the authentication and authorization procedure as 330 described in Section 2.1 332 6. Security Considerations 334 The use of DNS for obtaining the IP address of a mobility agent 335 carries certain security risks. These are explained in detail in 336 Section 9.1 of RFC 5026 [RFC5026]. However, the risks described in 337 RFC 5026 are mitigated to a large extent in this document, since the 338 MAG and the LMA belong belong to the same PMIPv6 domain. The DNS 339 server that the MAG queries is also part of the same PMIPv6 domain. 340 Even if the MAG obtains the IP address of a bogus LMA from a bogus 341 DNS server, further harm is prevented since the MAG and the LMA 342 should authenticate each other before exchanging PMIPv6 signaling 343 messages. RFC 5213 [RFC5213] specifies the use of IKEv2 [RFC4306] 344 between the MAG and the LMA to authenticate each other and setup 345 IPsec security associations for protecting the PMIPv6 signaling 346 messages. 348 The AAA infrastructure may be used to transport the LMA discovery 349 related information between the MAG and the AAA server via one or 350 more AAA brokers and/or AAA proxies. In this case the MAG to the AAA 351 server communication relies on the security properties of the 352 intermediate AAA brokers and AAA proxies. 354 7. IANA Considerations 356 This specification has no actions for IANA. 358 8. Acknowledgements 360 The authors would like to thank Julien Laganier, Christian Vogt, 361 Ryuji Wakikawa, Frank Xia, Behcet Sarikaya and Xiangsong Cui for 362 their comments, extensive discussions and suggestions on this 363 document. 365 9. Informative References 367 [3GPP.23.003] 368 3GPP, "Numbering, addressing and identification", 3GPP 369 TS 23.003 8.2.0, September 2008. 371 [3GPP.24.008] 372 3GPP, "Mobile radio interface Layer 3 specification", 3GPP 373 TS 24.008 8.6.0, June 2009. 375 [I-D.ietf-dime-pmip6] 376 Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 377 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 378 Gateway and Local Mobility Anchor Interaction with 379 Diameter Server", draft-ietf-dime-pmip6-04 (work in 380 progress), September 2009. 382 [I-D.ietf-mipshop-pfmipv6] 383 Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 384 Xia, "Fast Handovers for Proxy Mobile IPv6", 385 draft-ietf-mipshop-pfmipv6-12 (work in progress), 386 December 2009. 388 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 389 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 390 RFC 2136, April 1997. 392 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 393 NCACHE)", RFC 2308, March 1998. 395 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 396 specifying the location of services (DNS SRV)", RFC 2782, 397 February 2000. 399 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 400 RFC 4303, December 2005. 402 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 403 RFC 4306, December 2005. 405 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 406 Bootstrapping in Split Scenario", RFC 5026, October 2007. 408 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 409 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 411 [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 412 and K. Chowdhury, "Diameter Mobile IPv6: Support for 413 Network Access Server to Diameter Server Interaction", 414 RFC 5447, February 2009. 416 Authors' Addresses 418 Jouni Korhonen 419 Nokia Siemens Networks 420 Linnoitustie 6 421 FIN-02600 Espoo 422 Finland 424 Email: jouni.nospam@gmail.com 426 Vijay Devarapalli 427 WiChorus 428 3950 North First Street 429 San Jose, CA 95134 430 USA 432 Email: vijay@wichorus.com