TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2006.
Copyright © The Internet Society (2005).
The CXTP specification uses SCTP as transport for CXTP message exchanges between a mobile node's new and previous access routers. It also relies on a pre-established IPsec ESP transport mode tunnel. This document presents an alternative approach based on the NSIS GIST protocol, which offers a more flexible transport and richer security properties for context transfer between different entities within the network that support forwarding of a mobile node's IP traffic.
1.
Introduction
2.
Terminology
3.
Design Overview
4.
Context Transfer over GIST
5.
Further Discussions
5.1.
Triggers for Context Transfer
5.2.
Interworking with NSIS QoS and NAT/FW NSLP protocols
5.3.
GIST MA bootstrapping, maintenance and inter-domain
context transfer issues
6.
Security Considerations
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
TOC |
The Context Transfer Protocol (CXTP)[1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) provides a way to improve performance for mobile hosts by transferring state from the previous access router (pAR) to the new access router (nAR) across an IP based network. This document describes a solution based on the General Internet Signaling Transport protocol (GIST)[2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) for enhancing CXTP to perform more effectively. This approach allows reuse of an existing (secure) communication channel for context transfer between a pAR and any nAR, as well as seamless interworking with PANA and NSIS protocols, and minimized involvement of mobile hosts. This channel is soft state based, which allows an efficient and secure acquisition of state information for roaming devices as well as flexible selection of underlying transport mechanisms and automatic release of unused resources.
TOC |
Most of the terms are defined in the CXTP [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) and GIST [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) specifications:
o MA GIST messaging association o MRS GIST message routing state o MRI GIST message routing information o CTAR CXTP Activate Request message o CTAA CXTP Activate Acknowledge message o CTD CXTP Data message o CTReq CXTP Request message o CTDR CXTP Data Reply message o CTC CXTP Cancel message o pAR previous Access Router o nAR new Access Router o AR Access Router
TOC |
The GIST protocol being developed by the NSIS working group for general signaling transport is independent on the underlying transport protocol, such as UDP, TCP, TCP over TLS or SCTP. In this section we describe the overall approach on how to reuse GIST for general context transfer between two entities within the network that support forwarding of a mobile node's IP traffic.
The most important part of CXTP is message exchanges between the entities within the network. These entities can be either nodes supporting access control or a PEP (Policy Enforcement Point) function, or access routers. This document covers the case where these entities are access routers, but the mechanisms are also applicable for any other types of nodes. The context transferred can be anything related to mobile nodes' end-to-end communications, such as AAA, header compression, QoS, Policy, and possibly sub-IP protocols and services such as PPP, as supported by CXTP.
This document extends CXTP [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) in that the CXTP messages exchanged between the entities within the network are encapsulated as a NSIS signaling application running above GIST. This way, features like soft state refreshes and messaging state reuse, transport protocol flexibility and ensured reliable and secure transport will allow CXTP to be applicable in many operational environments.
Typically, GIST operates with a path-coupled discovery procedure to determine the signaling node. As an access router will likely be able to know its neighboring access routers' address information (either by static configuration or can learn that information by other means), GIST messaging associations (MAs) between them can be either established on demand or pre-established depending on the policies, without the need of performing GIST path-coupled discovery and maintaining GIST message routing state (MRS).
If a mobile node (MN) requests for context transfer, or an AR predicts an MN is likely to move to another AR, context transfer message exchanges can be made upon the corresponding GIST MA.
Figure 1 illustrates an example scenario for CXTP using GIST. Theoretically, an AR can maintain GIST MA(s) between itself and any number of its neighboring ARs. Assume there is an MN moving from AR1 to AR3, then to AR4 and finally AR6. As there is already an existing GIST MA3 between AR1 and AR3, AR1 can transfer context of this MN to AR3 through MA3 by exchanging CXTP data messages (as CXTP NSLP messages). As there is no MA exists between AR3 and AR4, GIST will establish an MA4 when either AR3 or AR4 learns MN's movement or intention to move from AR3 to AR4. Note, one can negotiate which transport protocol and security properties between these ARs, allowing maximal flexibility and applicability in operational scenarios. After MA4 is established, AR3 can perform CXTP over it as usual. If for some (long) period of time AR1 does not anticipate any need for transferring context to any neighboring AR, nor it receives any CXTP message from that neighbor, GIST MAs SHOULD be released, avoiding waste of network resources.
(GIST MA) +-----+GIST MA6+-----+ +----+---------------------+ AR5 +--------+ AR6 | |AR1 |\ +--+--+ /+--+--+ +----+ \ | / | GIST/ \GIST GIST| GIST |GIST MA1/ \ MA3 MA5| / MA7 |MA8 / \ | / | +--/-+ GIST MA2+\----+(GIST MA4)+--+--+GIST MA8+--+--+ |AR2 +---------+ AR3 +----------+ AR4 +--------+ AR7 | +----+ +-----+ +-----+ +-----+ Figure 1: An example scenario for CXTP using GIST
TOC |
A new NSIS signaling application type (NSLP ID TBD), "CXTP NSLP", is defined in this document for exchanging CXTP messages (CTD, CTReq, CTDR and CTC) between pAR and nAR and possibly creating GIST MAs. Each CXTP NSLP message contains a common NSLP header (as defined in [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.)), followed by one of these 4 types of CXTP messages defined in [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.)). For example, the CXTP NSLP CTD message is described in Figure 2:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP message type = CXTP NSLP | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.|Type= CTD|V| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MN's Previous IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Previous (New) AR IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: CXTP NSLP CTD message
If previous access router (pAR) and next access router (nAR) are neighbors, then no GIST discovery is needed. Thus, GIST messages defined in [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) should be changed as follows:
CXTP messages between MN and pAR and between MN and nAR are specified in CXTP [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) as ICMP messages and not modified here.
If pAR and nAR are not neighbors, then standard GIST discovery is used.
TOC |
TOC |
There are many possiblities to trigger Context Transfer using GIST, some of which are listed below:
These triggers can be categorized to either 1) triggers perceived at the nAR or 2) triggers perceived at the pAR. Upon a trigger of category 1), the nAR needs to send a CT-Req over the GIST MA to the pAR, and the latter in turn responds back with a CTD; then an optional CTDR can be sent from the pAR to the nAR. Upon a trigger of category 2), the pAR simply needs to send a CTD over the GIST MA to the nAR.
In either case, if a desired CTD message is not received within a certain period of time (or due to other reasons, e.g., the nAR senses that the MN moves out of its coverage before receiving a CTD), the nAR may issue a CTC to cancel the context transfer using the GIST MA.
TOC |
CXTP, especially its use over GIST, can reduce the overhead for the last hop communication between an MN and its AR. Using CXTP/GIST, the AR states related to MN-CN end-to-end communications are transferred seamlessly, without the need to reestablish from the MN.
Figure 3 illustrates an example where QoS NSLP signaling is desired from the MN to the CN. The case of NAT/FW NSLP is similar. Before the handover, QoS NSLP was used, involving steps 1)-4) and finally reaches CN. Then the MN moves to the nAR, which maintains a (secure) GIST MA with the pAR. Some trigger as described in previous subsection (e.g., either (1) or (1a) or another event) then starts the CXTP/GIST, which results in QoS NSLP state successfully transferred from the pAR to the nAR. Once the CXTP/GIST is accomplished, the nAR can then act on behalf on the MN and (re)establish the QoS NSLP state along the path towards the CN using QoS NSLP signaling.
+-----+ (2) +-----+ ~| pAR |~~~~~~~| R1 | (1)~ +--*--+ +-----+~ (3) ~ * ~ ~ *(CXTP/GIST) ~+----+ (4) +----+ +----+ +----~-+ * | R3 +-----+ .. +--+ CN | | MN | * (3a)/+----+ +----+ +----+ +------+\ \*/ / (1a)\+--*--+ (2a) +-----+/ | nAR +-------+ R2 | +-----+ +-----+ Figure 3: Interworking with NSIS QoS NSLP
TOC |
CXTP/GIST requires maintaining a GIST MA between neighboring ARs. In cases where ARs belonging to different administrative domains do not have a pre-established GIST MA, or an AR is newly added or rebooted, GIST MAs need to be established on demand in a secure fashion. Further versions of this document will discuss this aspect in more detail.
TOC |
The security considerations of both [2] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) and [1] (Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” July 2005.) apply. Further security analysis is needed to consider any additional security vulnerabilities, and will be included in an updated draft.
TOC |
Henning Peters provided useful comments.
TOC |
TOC |
[1] | Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, “Context Transfer Protocol (CXTP),” RFC 4067, July 2005. |
[2] | Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” draft-ietf-nsis-ntlp-08 (work in progress), September 2005. |
TOC |
[3] | Forsberg, D. and et. al, “PANA Mobility Optimizations,” draft-ietf-pana-mobopts-00 (work in progress), January 2005. |
[4] | Bournelle, J., “Use of Context Transfer Protocol (CxTP) for PANA,” draft-bournelle-pana-ctp-03 (work in progress), June 2005. |
TOC |
Xiaoming Fu | |
University of Goettingen | |
Institute for Informatics | |
Lotzestr. 16-18 | |
Goettingen 37083 | |
Germany | |
Email: | fu@cs.uni-goettingen.de |
John Loughney | |
Nokia Research Center | |
Itamerenkatu 11-13 | |
Helsinki 00180 | |
Finland | |
Email: | john.loughney@nokia.com |
TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright © The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.