Network Working Group X. Fu Internet-Draft Univ. Goettingen Expires: April 17, 2006 J. Loughney Nokia October 14, 2005 Context Transfer Using GIST draft-fu-cxtp-gist-00.txt Status of this Memo 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 Notice Copyright (C) The Internet Society (2005). Abstract 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. Fu & Loughney Expires April 17, 2006 [Page 1] Internet-Draft CXTP over GIST October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4. Context Transfer over GIST . . . . . . . . . . . . . . . . . . 5 5. Further Discussions . . . . . . . . . . . . . . . . . . . . . 6 5.1. Triggers for Context Transfer . . . . . . . . . . . . . . 6 5.2. Interworking with NSIS QoS and NAT/FW NSLP protocols . . . 7 5.3. GIST MA bootstrapping, maintenance and inter-domain context transfer issues . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Fu & Loughney Expires April 17, 2006 [Page 2] Internet-Draft CXTP over GIST October 2005 1. Introduction The Context Transfer Protocol (CXTP)[1] 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] 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. 2. Terminology Most of the terms are defined in the CXTP [1] and GIST [2] 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 3. Design Overview 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 Fu & Loughney Expires April 17, 2006 [Page 3] Internet-Draft CXTP over GIST October 2005 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] 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. Fu & Loughney Expires April 17, 2006 [Page 4] Internet-Draft CXTP over GIST October 2005 (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 4. Context Transfer over GIST 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]), followed by one of these 4 types of CXTP messages defined in [1]). 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 Fu & Loughney Expires April 17, 2006 [Page 5] Internet-Draft CXTP over GIST October 2005 If previous access router (pAR) and next access router (nAR) are neighbors, then no GIST discovery is needed. Thus, GIST messages defined in [2] should be changed as follows: o Normally, GIST query messages are used to create MAs between known ARs, thus there is no need to include a router alert option; o there is no need to create or maintain MRSs upon receipt of a GIST response or confirm message; o MA-Hello messages are used to keep existing MAs alive, its timer value may be smaller than standard GIST MA lifetime; o GIST-Error messages are used to report an unknown CT NSLP message type (i.e., a new Error code needs to be introduced). CXTP messages between MN and pAR and between MN and nAR are specified in CXTP [1] as ICMP messages and not modified here. If pAR and nAR are not neighbors, then standard GIST discovery is used. 5. Further Discussions 5.1. Triggers for Context Transfer There are many possiblities to trigger Context Transfer using GIST, some of which are listed below: o Using the triggers defined in CXTP[1], such as MN-controlled or network-controlled; o Using some kind of (light-weight) NSIS signaling between the MN and the correspondent node as trigger; o If the mobile node is using NSIS signaling for other purposed (NAT/FW traversal, QoS signaling), the ARs could re-use the router alert processing to detect movement and trigger the CXTP; o Upon the completion of authentication, e.g., PANA discovery and handshake in PANA mobility optimization [3]; o Upon a successful transfer of PANA context[4]. 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. Fu & Loughney Expires April 17, 2006 [Page 6] Internet-Draft CXTP over GIST October 2005 5.2. Interworking with NSIS QoS and NAT/FW NSLP protocols 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 5.3. GIST MA bootstrapping, maintenance and inter-domain context transfer issues 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. 6. Security Considerations The security considerations of both [2] and [1] apply. Further Fu & Loughney Expires April 17, 2006 [Page 7] Internet-Draft CXTP over GIST October 2005 security analysis is needed to consider any additional security vulnerabilities, and will be included in an updated draft. 7. Acknowledgements Henning Peters provided useful comments. 8. References 8.1. Normative References [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. 8.2. Informative References [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. Fu & Loughney Expires April 17, 2006 [Page 8] Internet-Draft CXTP over GIST October 2005 Authors' Addresses 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 Fu & Loughney Expires April 17, 2006 [Page 9] Internet-Draft CXTP over GIST October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 Statement Copyright (C) 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fu & Loughney Expires April 17, 2006 [Page 10]