Network Working Group X. Fu
Internet-Draft Univ. Goettingen
Expires: September 7, 2006 J. Loughney
Nokia
H. Peters
Univ. Goettingen
March 6, 2006
Context Transfer Using GIST
draft-fu-cxtp-gist-01.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 September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The CXTP specification uses basic SCTP as transport for CXTP message
exchanges between a mobile node's previous and new access routers.
It also relies on a pre-established IPsec ESP transport mode tunnel.
This document discusses two alternative approaches based on
"persistent" associations using either SCTP streams feature or GIST
Fu, et al. Expires September 7, 2006 [Page 1]
Internet-Draft CXTP over GIST March 2006
protocol. While both approaches reduce context transfer latency
during handovers, GIST also offers more flexible transport and richer
security properties.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Use of SCTP multiple streams . . . . . . . . . . . . . . . 4
3.2. Use of GIST as alternative transport . . . . . . . . . . . 5
3.3. Applicability scenario . . . . . . . . . . . . . . . . . . 5
4. Context Transfer NSLP . . . . . . . . . . . . . . . . . . . . 6
5. Further Discussions . . . . . . . . . . . . . . . . . . . . . 7
5.1. Advantages & disadvantages of GIST transport . . . . . . . 7
5.2. Triggers for Context Transfer . . . . . . . . . . . . . . 8
5.3. Interworking with NSIS QoS and NAT/FW NSLP protocols . . . 8
5.4. GIST MA bootstrapping, maintenance and inter-domain
context transfer issues . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Fu, et al. Expires September 7, 2006 [Page 2]
Internet-Draft CXTP over GIST March 2006
1. Introduction
The Context Transfer Protocol (CXTP) [1] provides a way to improve
performance for mobile nodes moving between networks by transferring
state context from the previous access router (pAR) to the new access
router (nAR) across an IP based network. For each of these context
transfers, a new SCTP association is maintained. This document
describes alternative potentials based on "persistent" associations
between neighboring ARs to reduce the context transfer handover
latency due to individual association setup. Similar to the multi-
streaming features in the Stream Control Transmission Protocol
(SCTP), the General Internet Signaling Transport (GIST) [2] provides
the functionality of multiplexing traffic between two peers into a
single association, known as messaging association (MA). This
technique allows reuse of an existing (secure) communication channel
for context transfer between a pAR and any nAR. In addition, the
proposed approach could seamlessly interwork with PANA and NSIS
protocols, and minimize the involvement of mobile hosts. Such a
communication 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 used are defined in the CXTP [1], SCTP [3] and GIST
[2] specifications. Below is a list of acronyms used in this
document.
o AR Access Router
o pAR previous Access Router
o nAR new Access Router
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 MA GIST messaging association
o MRS GIST message routing state
o MRI GIST message routing information
3. Design Overview
CXTP message exchange can be divided into two groups: MN-AR and AR-AR
Fu, et al. Expires September 7, 2006 [Page 3]
Internet-Draft CXTP over GIST March 2006
communication. This document mainly addresses the issue of
communications between entities within the network. These entities
can be either nodes supporting access control or a PEP (Policy
Enforcement Point) function, access routers or 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 RFC 4067 [1].
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), associations between them can
be either established on demand or pre-established depending on the
policies. An association is a unidirectional context transfer
channel.
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 association.
This can be done by either of the following approaches, alternative
to the one specified in [1].
3.1. Use of SCTP multiple streams
SCTP allows to send several messages over a single association using
multiple streams. Each stream is associated with a unique stream
identifier at both endpoints. Multiple streams prevent Head of Line
Blocking (HLB); if retransmission occurs at one stream, messages of
the other streams of the same association are not delayed.
During establishment of the SCTP association, the pAR and the nAR
will negotiate in the INIT and INIT-ACK phase about the number of
streams to use, according to section 5.1.1 of [3]. After the
association is initialized, the valid outbound stream identifier
range for either endpoint shall be between 0 and min (local number of
outbound streams, remote maximum inbound streams) - 1. Once a SCTP
association is established, there is no need to perform additional
negotiation to use multiple streams.
A context identified by a feature profile type (FPT) is assigned an
incrementing outbound stream identifier, the context is encoded using
CXTP message format and finally sent over a pre-established SCTP
association. The same stream identifier MUST NOT be used for
concurrent context transfers. The stream identifier is reset when it
reaches the range limit.
Fu, et al. Expires September 7, 2006 [Page 4]
Internet-Draft CXTP over GIST March 2006
3.2. Use of GIST as alternative transport
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 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 nodes. As the target node addressing
information here is already known in advance and the peers
communicate in an end-to-end fashion, there is no need to perform
GIST path-coupled discovery and maintaining GIST message routing
state (MRS).
In GIST, a 32-bit session identifier is assigned to each context
transfer randomly. The same session identifier MUST NOT be used for
concurrent context transfers.
Note, when SCTP is used for GIST [4], multiple different sessions can
be further aggregated over a common GIST session, by using different
SCTP streams for each session. This will be useful, for instance,
when the sessions are used by different corresponding hosts.
3.3. Applicability scenario
Figure 1 illustrates an example scenario for CXTP using GIST. The
scenario also applies for persistent SCTP associations. Non-
established associations are denoted with brackets. Theoretically,
an AR can maintain (messaging) associations between itself and any
number of its neighboring ARs. Assume there is an MN moving from AR2
to AR3, then to AR5 and finally AR6. As there is already an existing
association (A3) between AR2 and AR3, AR2 can transfer context of
this MN to AR3 through A3 by exchanging CXTP data messages over a
specified transport protocol. As there exists no association between
AR3 and AR5, a new association will establish A5 on demand when
either AR3 or AR5 learns MN's movement or intention to move from AR3
to AR5. Note, GIST can negotiate transport protocol and security
properties between these ARs, allowing maximal flexibility and
applicability. After A4 is established, AR3 can perform CXTP over it
Fu, et al. Expires September 7, 2006 [Page 5]
Internet-Draft CXTP over GIST March 2006
as usual. If for some (long) period of time AR2 does not anticipate
any need for transferring context to any neighboring AR, nor it
receives any CXTP message from that neighbor, associations SHOULD be
released, avoiding waste of network resources.
+-----+ (A4) +-----+ A7 +-----+
| AR2 |---------------------+ AR4 +---------| AR6 |
+-----+ +-----+ +-----+
/ \\ | A8 ^^ |
A1 / \\ A3 A6| .=========' |(A10)
/ VV | // |
+-----+ A2 +-----+ (A5) +-----+ A9 +-----+
| AR1 +---------+ AR3 +============>| AR5 |---------| AR7 |
+-----+ +-----+ +-----+ +-----+
Figure 1: An example scenario for CXTP using GIST
4. Context Transfer NSLP
A new NSIS signaling application type (NSLP ID TBD), "CXTP NSLP", is
defined for exchanging encapsulated 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:
Fu, et al. Expires September 7, 2006 [Page 6]
Internet-Draft CXTP over GIST March 2006
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: Encapsulated CXTP CTD message
GIST discovery as defined in [2] is modified as follows:
o 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 CXTP 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.
5. Further Discussions
5.1. Advantages & disadvantages of GIST transport
Advantages:
o "Persistent" associations using a soft state approach reduces
session setup latency and requires lower state maintenance cost at
access routers. When the association is not used for a long
period of time, it will be automatically removed;
Fu, et al. Expires September 7, 2006 [Page 7]
Internet-Draft CXTP over GIST March 2006
o GIST offers more flexible and dynamic selection of underlying
transport protocol, including richer security properties. For
instance, this allows to deploy CXTP using TCP/TLS with SCTP
"multiple stream"-like feature;
o NSIS-aware networks can easily deploy CXTP NSLP. This naturally
offers interworking benefits with other NSLPs, such as QoS NSLP or
NAT/Firewall NSLP.
Disadvantages:
o Several features of GIST are not used, such as peer discovery and
message routing over a chain of GIST nodes. Thus, it seems a
simplified/light-weight version of GIST may be used instead of a
full-fledged GIST.
5.2. Triggers for Context Transfer
There are many possibilities 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 purposes
(middlebox configuration, QoS signaling), ARs could notice MN
attachment by MN's discovery messages;
o Upon the completion of authentication, e.g., PANA discovery and
handshake in PANA mobility optimization [5];
o Upon a successful transfer of PANA context [6].
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.
5.3. 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.
Fu, et al. Expires September 7, 2006 [Page 8]
Internet-Draft CXTP over GIST March 2006
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 is applied, 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 to be
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.4. 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. "Persistent"
SCTP associations are more vulnerable against blind masquerade
attacks against the SCTP Verification Tag. Further security analysis
is needed to consider additional security vulnerabilities.
Fu, et al. Expires September 7, 2006 [Page 9]
Internet-Draft CXTP over GIST March 2006
7. Acknowledgements
Kwok-Ho Chan, Hui Deng, James Kempf, Rajeev Koodli, and Hannes
Tschofenig provided valuable 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-09 (work in
progress), February 2006.
[3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
8.2. Informative References
[4] Fu, X., "General Internet Signaling Transport (GIST) over SCTP",
draft-fu-nsis-ntlp-sctp-01 (work in progress), February 2006.
[5] Forsberg, D., "PANA Mobility Optimizations",
draft-ietf-pana-mobopts-01 (work in progress), October 2005.
[6] Bournelle, J., "Use of Context Transfer Protocol (CXTP) for
PANA", draft-ietf-pana-cxtp-00 (work in progress), October 2005.
Fu, et al. Expires September 7, 2006 [Page 10]
Internet-Draft CXTP over GIST March 2006
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
Henning Peters
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: hpeters@math.uni-goettingen.de
Fu, et al. Expires September 7, 2006 [Page 11]
Internet-Draft CXTP over GIST March 2006
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 (2006). 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, et al. Expires September 7, 2006 [Page 12]