idnits 2.17.1 draft-liebsch-dime-pmip6-lmaresolve-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** 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 IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 26, 2009) is 5296 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) == Missing Reference: 'Authorization' is mentioned on line 232, but not defined ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-06) exists of draft-ietf-netext-pmip6-lr-ps-00 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and M. Liebsch 3 Extensions (DIME) P. Loureiro 4 Internet-Draft NEC 5 Intended status: Standards Track J. Korhonen 6 Expires: April 29, 2010 Nokia Siemens Network 7 October 26, 2009 9 Local Mobility Anchor Resolution for PMIPv6 10 draft-liebsch-dime-pmip6-lmaresolve-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The IETF is specifying Diameter extensions to support mobility 49 service authorization and home network prefix allocation for Proxy 50 Mobile IPv6. The protocol operates between a Local Mobility Anchor 51 and a AAA server. Furthermore, the associated specification extends 52 the existing protocol for network access service to support dynamic 53 assignment and discovery of a Local Mobility Anchor during the 54 authentication procedure. The AAA server maintains mobile nodes' 55 profile in a policy store, which includes information about the 56 assigned Local Mobility Anchor as well as the home network prefix. 57 This document proposes a further extension to allow Local Mobility 58 Anchors benefit from the AAA server's policy store and resolve an 59 unknown mobile node's IP address into a routable address of its 60 assigned Local Mobility Anchor. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 66 3. Problem Statement and Reference Architecture . . . . . . . . . 5 67 4. Information Query extension to Diameter for LMA Resolution . . 9 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 The IETF specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as solution 78 for network-based localized mobility management. While in host 79 mobility solutions, such as Mobile IPv6 [RFC3775], the mobile node 80 (MN) takes care about updating its routing state on a mobility 81 anchor, in PMIPv6 a Mobility Access Gateway (MAG) recognizes an 82 attachment of an MN and takes over the role of registering the MN at 83 a selected Local Mobility Anchor (LMA). 85 The base PMIPv6 protocol as per [RFC5213] specifies protocol 86 operation between a MAG and an LMA for registration, de-registration 87 and handover. The LMA is under control of assigning a unique IP 88 address prefix (Home Network Prefix, HNP) to a registering MN and 89 performs prefix-based forwarding of downlink data packets according 90 to the MN's binding cache entry (BCE). The MAG, which performed the 91 registration of the MN by means of sending a Proxy Binding Update 92 (PBU) to the responsible LMA, is referred to as proxy care-of-address 93 for the MN and the LMA forwards downlink data packets to the MN's MAG 94 through an IP tunnel. The MAG forwards the packets to the MN by 95 means of link mechanisms. 97 [RFC5213] considers selection of a responsible LMA as well as sources 98 for the assignment of an HNP to a registering MN at the LMA out of 99 scope. [I-D.ietf-dime-pmip6] specifies extensions to the Network 100 Access Server (NAS), which is collocated with a MAG in the access 101 network, to retrieve an MN's policy profile and LMA information from 102 a AAA server during access authentication. Furthermore, generic 103 extensions to the Diameter protocol are specified for mobility 104 service authorization and prefix delegation, which apply to the 105 interface between an LMA and the AAA server. 107 As MNs get assigned a unique prefix during the PMIPv6 registration 108 and associated IP addresses may be from a virtual address space and 109 remain anchored at the LMA, there is no efficient means to resolve an 110 MN's virtual IP address into the routable address of the MN's LMA. 111 This may be needed to support different use cases in a PMIPv6 domain, 112 which utilizes multiple LMAs for load sharing or other purposes. Two 113 exemplary use cases are referred to in Section 3. 115 This document proposes a mechanism which further extends the generic 116 Diameter protocol extension as per [I-D.ietf-dime-pmip6] to support 117 the resolution of an MN's virtual IP address into the associated 118 LMA's routable IP address. 120 2. Conventions and Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Problem Statement and Reference Architecture 128 Addressing of MNs in PMIPv6 [RFC5213] is based on the assignment of 129 individual Home Network Prefixes to an MN during its registration 130 with an LMA. An LMA may use a local prefix pool, DHCP or other means 131 to retrieve a valid and unique HNP for an MN. In large PMIPv6 132 domains, multiple LMAs will serve MNs to ensure load distribution. 133 In case of local communication within the PMIPv6 domain or even 134 beyond a single PMIPv6 domain, a particular LMA has only forwarding 135 information for destination MNs, which are registered with this 136 particular LMA. For unknown destination prefixes, the LMA may 137 forward data to a default gateway. 139 In some scenarios it may be useful or even necessary for one LMA to 140 discover the LMA of the destination MN. Hence, an LMA needs to 141 resolve the destination MN's virtual IP address into the routable IP 142 address of the destination MN's LMA. Figure 1 depicts this problem 143 for the communication between MN1 and MN2, which are registered with 144 LMA1 and LMA2 respectively. The reference architecture of this 145 document assumes a NAS being collocated with the MAG on an access 146 router, which performs Diameter protocol operation with a AAA server 147 for access authentication and LMA discovery according to 148 [I-D.ietf-dime-pmip6] (B1,B2 interface of Figure 1). Furthermore, 149 the architecture assumes a Diameter client on each LMA for mobility 150 service authorization and HNP delegation according to 151 [I-D.ietf-dime-pmip6] (A1,A2 interface of Figure 1). 153 +---------+ 154 +-------------->| AAA & |<--------------+ 155 | +---->| Policy |<----+ | 156 | | | Profile | | | 157 | Diameter +---------+ Diameter | 158 | A1 A2 | 159 | | | | 160 Diameter v v Diameter 161 B1 +----+ LMA2? +----+ B2 162 | |LMA1| ------> |LMA2| | 163 | +----+ +----+ | 164 | | | | 165 | // \\ | 166 | // \\ | 167 | // \\ | 168 | | | | 169 | +----+ +----+ | 170 +---->|MAG1| |MAG2|<----+ 171 +----+ +----+ 172 : : 173 +---+ +---+ 174 |MN1| |MN2| 175 +---+ +---+ 177 Figure 1: Reference architecture 179 Exemplary use cases for the resolution of an MN's (virtual) IP 180 address into the anchor's node are as follows: 182 o Local Routing: Two MNs, MN1 and MN2, which are attached to the 183 same PMIPv6 domain but are registered with different LMAs, LMA1 184 and LMA2, communicate with each other. MN1 sends data to MN2 185 through its LMA1. Dependent on the nature of MN2's IP address 186 prefix, LMA1 needs to resolve MN2's virtual IP address into a 187 routable IP address, such as LMA2's address. LMA1 can use LMA2's 188 IP address as forwarding information. 190 o Route Optimization Signaling: The IETF's NetExt WG is specifying 191 extensions to PMIPv6 for Route Optimization (Localized Routing) 192 [I-D.ietf-netext-pmip6-lr-ps]. Associated scenarios include the 193 communication between two MNs, MN1 and MN2, which are attached to 194 the same PMIPv6 domain but are registered with different LMAs, 195 LMA1 and LMA2. Protocol solutions for route optimization may 196 require signaling between the two LMAs within the same PMIPv6 197 domain to set up a direct forwarding path between the two MNs' 198 MAGs. As a result, data packets between the two MNs can be 199 forwarded locally without traversing any LMA. In such case, LMA1 200 may need to resolve MN2's virtual IP address into LMA2's routable 201 IP address. LMA1 can now send signaling messages to LMA2. 203 [RFC5213] assumes that the LMA is responsible for assigning an HNP to 204 the MN during the PMIPv6 registration, but means to determine a 205 unique HNP are out of scope of the specification. 206 [I-D.ietf-dime-pmip6] specifies extensions to network access service 207 to retrieve information about a responsible LMA for an MN during the 208 MN's authentication procedure. Furthermore, generic protocol 209 extensions to the Diameter protocol are specified to operate between 210 an LMA, which implements a Diameter client, and the AAA server. 211 These extensions are used to authorize mobility service for an MN 212 after an LMA received a Proxy Binding Update (PBU) from the MN's MAG 213 and to retrieve a valid and unique HNP for the MN from the AAA 214 server. 216 Figure 2 depicts the registration procedure of MN1 with LMA1 and of 217 MN2 with LMA2 according to [I-D.ietf-dime-pmip6]. MN1 attaches to 218 MAG1, whereas MN2 attaches to MAG2. As a result of mobility service 219 authorization, MN1 gets assigned HNP1, whereas MN2 gets assigned 220 HNP2. 222 +---+ +---+ +----+ +----+ +----+ +---+ +----+ 223 |MN1| |MN2| |MAG1| |MAG2| |LMA1| |AAA| |LMA2| 224 +---+ +---+ +----+ +----+ +----+ +---+ +----+ 225 | | | | | | | 226 | | | | | | | 227 |- attach- -| | | | | 228 | | |-----AA-Request[MN1]---------------->| | 229 | | |<----AA-Answer[LMA1]-----------------| | 230 | | |----PBU[MN1]--->| | | 231 | | | | |----AA-Req[MN1]---->| | 232 | | | | | [Authorization] | 233 | | | | |<--AA-Answer[HNP1]--| | 234 | | |<---PBA[HNP1]---| | | 235 | | | | | | | 236 | |- -attach - | | | | 237 | | | |----------AA-Request[MN2]--->| | 238 | | | |<---------AA-Answer[LMA2]----| | 239 | | | |-------------PBU[MN2]----------------------->| 240 | | | | | |<-AA-Req[MN2]--| 241 | | | | | | [Authoriz.] 242 | | | | | |-AA-Ans[HNP2]->| 243 | | | |<------------PBA[HNP2]-----------------------| 244 | | | | | | | 245 | | | | | | | 246 | | | | | | | 248 Figure 2: MN Authentication, LMA discovery, service authorization and 249 Prefix delegation in a multi-LMA scenario 251 4. Information Query extension to Diameter for LMA Resolution 253 According to [I-D.ietf-dime-pmip6], the AAA server is a suitable 254 entity to maintain MNs' profile information and to store further 255 dynamically assigned information during an MN's mobility session. 256 Such information includes the assigned LMA and the HNP, which has 257 been assigned to the MN during access authorization. This makes the 258 AAA server a suitable information database for trusted Diameter 259 clients to request some information from the policy store. 261 This document proposes an extension to the Diameter protocol 262 interface as per [I-D.ietf-dime-pmip6] to support resolving an MN's 263 HNP into its LMA's IP address by means of a new message type 264 INFO_QUERY. Any Diameter client, which is associated with the AAA 265 server, may send an INFO_QUERY to the AAA server, having the unknown 266 MN's HNP or complete IP address included. The AAA server performs a 267 lookup in its policy store and a longest prefix match to resolve the 268 HNP into the associated LMA's IP address. Subsequently, the AAA 269 server replies to the requesting Diameter client with an 270 INFO_RESPONSE (INFO_RESP), including the requested binding between 271 the unknown MN's HNP and its assigned LMA's IP address. Now, the 272 requesting LMA can contact the unknown LMA directly for signaling 273 reasons or take the resolved IP address as forwarding information for 274 data packets. 276 Figure 3 illustrates exemplarily the resolution of the IP address/HNP 277 of MN2, which is registered with LMA2, into the IP address of LMA2 278 with the help of the proposed LMA Resolution extension to Diameter. 279 MN1 sends a data packet to MN2, which traverses MN1's LMA1. In case 280 LMA1 needs to know a routable IP address of MN2's mobility anchor, 281 LMA1 performs LMA Resolution with the AAA server to resolve MN2's IP 282 address/HNP (IP MN2) into LMA2's IP address (IP LMA2). 284 +---+ +----+ +----+ +---+ +----+ 285 |MN1| |MAG1| |LMA1| |AAA| |LMA2| 286 +---+ +----+ +----+ +---+ +----+ 287 | data | data | | | 288 |- - - - ->|-==========->| | | 289 | | |--INFO_QUERY[IP MN2]->| | 290 | | | | | 291 | | |<--INFO_RESP[IP LMA2]-| | 292 | | | | | 293 | | |-----data/signaling----------------->| 294 | | | | | 295 | | | | | 297 Figure 3: LMA resolution at a AAA server 299 In large domains, multiple AAA servers may distribute load. To 300 assign a unique HNP to registering MNs, AAA servers may use 301 administratively assigned prefix pools. In such case, it may happen 302 that an LMA tries to resolve an unknown MN's IP/HNP into the 303 associated LMA's IP address, but the requested AAA server does not 304 have an entry for the unknown MN as well. Here, the concept of the 305 Diameter redirect agent [RFC3588] may help to support LMA resolution 306 beyond the scope of a single AAA server. Such an architecture is 307 illustrated in Figure 4. 309 +------------------------------------+ 310 ( AAA ) 311 ( +--------+ Backend ) 312 ( |Redirect| ) 313 ( | Agent | ) 314 ( +--------+ ) 315 ( ^ ) 316 ( | ) 317 ( | ) 318 ( v ) 319 ( +---------+ +---------+ ) 320 +---->| AAA1 & | | AAA2 & |<---+ 321 | ( | Policy |<-------->| Policy | ) | 322 | ( | Profile | | Profile | ) | 323 | ( +---------+ +---------+ ) | 324 | ( ^ ^ ) | 325 | +----- | ------------------- |-------+ | 326 | A1 A2 | 327 | | | | 328 | | | | 329 Diameter v v Diameter 330 B1 +----+ LMA2 ? +----+ B2 331 | |LMA1| ------> |LMA2| | 332 | +----+ +----+ | 333 | | | | 334 | // \\ | 335 | // \\ | 336 | // \\ | 337 | | | | 338 | +----+ +----+ | 339 +---->|MAG1| |MAG2|<----+ 340 +----+ +----+ 341 : : 342 +---+ +---+ 343 |MN1| |MN2| 344 +---+ +---+ 346 Figure 4: Use of a Diameter redirect agent to support LMA resolution 347 in networks with multiple AAA servers 349 Referring to an architecture with multiple AAA servers according to 350 Figure 4, AAA1 may not be able to resolve the HNP of MN2 into the IP 351 address of LMA2, as AAA2 holds this information in its policy store. 352 In such case, AAA1 contacts a Diameter redirect agent [RFC3588] to 353 request the AAA server being responsible for the assignment from the 354 address space where MN2's HNP belongs to. The redirect agent informs 355 AAA1 about AAA2's address in a Redirection Notification message, 356 which allows AAA1 to forward the INFO_QUERY to AAA2. AAA2 resolves 357 MN2's HNP into the IP address of LMA2 and sends the results back in 358 an INFO_RESPONSE message to LMA2 via AAA1. Details about the use of 359 redirection agents in this context are for further study. 361 5. Security Considerations 363 As LMA resolution according to this draft is performed between a 364 Diameter client on an LMA and the AAA server using the Diameter 365 protocol, an existing security association between the LMA and the 366 AAA server can be assumed to protect the new signaling messages. One 367 important difference to the existing protocol operation between a 368 Diameter client and the Diameter server according to 369 [I-D.ietf-dime-pmip6] is that the requesting LMA cannot include a 370 Diameter Session-ID or the MNID of the MN, whose HNP should be 371 resolved into an anchor address (MN2), in the INFO_QUERY message. 372 The AAA server must rather use the HNP or the IP address of MN2 as 373 key to perform a lookup in its policy store. Since the requesting 374 Diameter client on the LMA and the AAA server share a trust 375 relationship and associated signaling can be protected, there should 376 be no security threat with such operation. 378 6. Acknowledgments 380 Many thanks to Rafael Richter for his valuable input on AAA-based 381 anchor resolution. 383 May thanks to Glen Zorn, Dan Romascanu, Hannes Tschofenig and Qin Wu 384 for their valuable comments on the initial version of this draft. 386 7. References 388 7.1. Normative References 390 [I-D.ietf-dime-pmip6] 391 Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 392 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 393 Gateway and Local Mobility Anchor Interaction with 394 Diameter Server", draft-ietf-dime-pmip6-04 (work in 395 progress), September 2009. 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 401 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 403 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 404 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 406 7.2. Informative References 408 [I-D.ietf-netext-pmip6-lr-ps] 409 Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized 410 Routing Problem Statement", 411 draft-ietf-netext-pmip6-lr-ps-00 (work in progress), 412 September 2009. 414 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 415 in IPv6", RFC 3775, June 2004. 417 Authors' Addresses 419 Marco Liebsch 420 NEC Laboratories Europe 421 NEC Europe Ltd. 422 Kurfuersten-Anlage 36 423 69115 Heidelberg, 424 Germany 426 Phone: +49 6221 4342146 427 Email: liebsch@nw.neclab.eu 429 Paulo Loureiro 430 NEC Laboratories Europe 431 NEC Europe Ltd. 432 Kurfuersten-Anlage 36 433 69115 Heidelberg, 434 Germany 436 Phone: +49 6221 4342177 437 Email: loureiro@nw.neclab.eu 439 Jouni Korhonen 440 Nokia Siemens Network 441 Linnoitustie 6 442 Espoo FI-02600 443 Finland 445 Email: jouni.nospam@gmail.com