Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs, MAGs) tied by the MN and the CN may be distributed between different provider domains (i.e., domain A, B, C) and the MN and/or CN moves from one provider domain to another one. In order to support localized routing when roaming occurs, it is required that MAGs to which the MN and CN connect be within the same provider domain, and each MAG has a security relationship with the
corresponding LMA, which maintains the registration of the MN or the CN, respectively.
According to the roaming model as depicted in Figure 2, the MN’s PMIPv6 domain is characterized by its MAG (MAG1/MAG1’) and its LMA (LMA1), whereas the CN’s PMIPv6 domain is characterized by the CN’s MAG (MAG2/MAG2’) and its LMA (LMA2/LMA2’). A solution for localized routing cannot take any assumption about whether or not the MN and CN share the same PMIPv6 domain; hence, MAG1/MAG1’ may not share a
security association with LMA2/LMA2’, and MAG2/MAG2’ may not share a security association with LMA1, respectively.
It is not required that LMAs, which hold the registration for the MN and the CN, respectively, be part of the same provider domain as the MAGs where the MN and CN attach. When the MN’s MAG and LMA belong to different provider domains (A and C), localized routing is subject to policy governing the service level agreements between these domains.
The same applies to the provider domains that provide the CN’s MAG and LMA. Based on the above requirements, four PMIPv6 roaming and non-roaming cases can be taken into account.
o Case 1: The MN’s MAG (MAG1), the CN’s MAG (MAG2), the MN’s LMA (LMA1), and the CN’s LMA (LMA2) are located in the same provider domain A.
o Case 2: The MN’s MAG (MAG1), the CN’s MAG (MAG2), and the MN’s LMA (LMA1) are located in the same domain A, while the CN’s LMA
(LMA2’) is located in provider domain B.
o Case 3: The MN’s MAG (MAG1’) and the CN’s MAG (MAG2’) are located in domain C, while the MN’s LMA (LMA1) and the CN’s LMA (LMA2) are located in provider domain A.
o Case 4: The MN’s MAG (MAG1’) and the CN’s MAG (MAG2’) are located in provider domain C, while the MN’s LMA (LMA1) is located in provider domain A and the CN’s LMA (LMA2’) is located in provider domain B.
In these roaming cases, the MN can be allowed to roam within its domain (e.g., the MN’s home domain in which the MN’s LMA is located) or over different domains (e.g., the MN moves from its home domain to a visited domain). During mobility, the CN and MN should remain attached to MAGs of the same provider domain to maintain efficient routing of traffic between their MAGs.
|
+---+ +---+ | +---+
|LMA1 | |LMA2 | | |LMA2’|
+---+ +---+ | +---+
| | | | +---+ +---+ | |MAG1 | |MAG2 | | +---+ +---+ | | |
Provider Domain A | Provider Domain B
Provider Domain C
+---+ +---+
|MAG1’| |MAG2’|
+---+ +---+
Figure 2: PMIPv6 Roaming Cases Considered for Localized Routing 6. Security Considerations
A protocol solution for localized routing in a PMIPv6 network must counter unauthorized change of a routing path. In particular, the control plane for localized routing must preclude the blocking or hijacking of mobile nodes’ traffic by malicious or compromised network components. A security solution must support suitable mechanisms for authentication of control plane components of the localized routing functional architecture for both roaming and
non-roaming scenarios. Any possibility for Internet hosts to
interfere with the localized routing procedure in a malicious manner must be precluded.
Since network entities other than MNs and CNs perform signaling to set up localized routing, the MIPv6 return routability test [RFC3775]
is not suitable to authenticate associated signaling messages in PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate, or to provide sufficient defense against, possible security threats.
When PMIPv6 participants are administered within the same domain, infrastructure-based authorization mechanisms, such as IPsec, may be usable to protect signaling for localized routing.
Existing security associations according to [RFC5213] can be re-used to protect signaling for localized routing on the interface between a MAG and an LMA. In the case where a protocol solution for localized routing in PMIPv6 relies on protocol operation between MAGs, means for protection of signaling between these MAGs must be provided. The same applies for signaling on a possible protocol interface between two LMAs of the same domain.
7. Acknowledgments
Many aspects of the problem space for route optimization in PMIPv6 have been discussed in the context of a PMIPv6 Route Optimization Design Goals document, which was submitted to the NetLMM WG in November 2007. This group of contributors includes Sangjin Jeong, Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Behcet Sarikaya, Shinta Sugimoto, Long Le, Alice Qinxia, and Jaehwoon Lee. Many thanks to Rajeev Koodli for his comments about the structure and scope of this problem statement for the NetExt WG.
This problem statement reflects the results of the discussion in the NetExt group. Many thanks to Hidetoshi Yokota, Carlos Bernardos, Ashutosh Dutta, Sri Gundavelli, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, Dirk von Hugo, Frank Xia, Xiangsong Cui, and Basavaraj Patil for their comments and support to improve the quality of the problem statement.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
8.2. Informative References
[PMIP6-LR] Zorn, G., Wu, Q., Liebsch, M., and J. Korhonen, "Diameter Support for Proxy Mobile IPv6 Localized Routing", Work in Progress, May 2011.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC5779] Korhonen, J., Ed., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010.
Authors’ Addresses
Marco Liebsch (editor) NEC Laboratories Europe NEC Europe Ltd.
Kurfuersten-Anlage 36 69115 Heidelberg Germany
Phone: +49 6221 4342146 EMail: liebsch@neclab.eu
Sangjin Jeong ETRI
218 Gajeongno, Yuseong Daejeon 305-700
Korea
Phone: +82 42 860 1877 EMail: sjjeong@etri.re.kr
Qin Wu
Huawei Technologies Co., Ltd
101 Software Avenue, Yuhua District Nanjing 210012
China
Phone: +86 25 56623633 EMail: sunseawq@huawei.com