| TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
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, 2004.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document presents a framework for interoperation between the Context Transfer Protocol (CTP) and the Next Steps in Signaling (NSIS) protocols. The main goals we are trying to achieve are: to provide a seamless handover, to establish QoS and other states required by NSIS, to have this process appropriately secured, and to tradeoff between security, complexity and performance.
| TOC |
| TOC |
The IETF Next Steps in Signaling (NSIS) working group is currently developing a two-layer framework [I-D.ietf-nsis-fw] and protocols for generic signaling transport and service-specific signaling such as QoS signaling [I-D.ietf-nsis-qos-nslp]. However, how NSIS can support seamless handover is still an open issue. Firstly, while a mobile node (MN) changes from one access router (AR) to another (i.e., a handover takes place), QoS state (and other states) in the network nodes for ongoing sessions needs to be released (in the previous path) or re-established (in the new path). Secondly, the latency for QoS state re-establishment should be as low as possible. Thirdly, it is necessary to secure the state manipulations and possibly provide data integrity and confidentiality.
On the other hand, the Context Transfer Protocol (CTP) [I-D.ietf-seamoby-ctp] is being developed by the IETF SEAMOBY working group to improve the handover performance by transferring context from the previous access router (pAR) to the new access router (nAR). In addition, CTP provides a mechanism to authenticate the MN to the ARs. Some previous study (for example, [I-D.westphal-seamoby-qos-relocate][I-D.westphal-nsis-qos-mobileip]) addressed the relationship between CTP and QoS signaling, but they either considered new protocol design instead of reusing available mechanisms, or security issues have not been sufficiently addressed.
The purpose of this document is to provide a framework how CTP can be used for secured NSIS state (including QoS state) establishment for the new access router after a handover. It illustrates how CTP can interoperate with NSIS entities and save signaling overhead on the low bandwidth wireless link.
| TOC |
This document uses the following terms or abbreviations:
Mobile Node (MN), Correspondent Node (CN)
Home Agent (HA)
Care of Address (CoA), previous CoA (pCoA), and new CoA (nCoA)
Access Router (AR), previous AR (pAR), and new AR (nAR)
Context Transfer (CT), Context Transfer Protocol (CTP)
Context Transfer Request (CTR)
Context Transfer Data (CTD)
Context Transfer Activate Request (CTAR)
Context Transfer Activate Acknowledge (CTAA)
Feature Profile Type (FPT)
Security Association (SA)
Denial of Service (DoS)
Authentication Token
Internet Key Exchange Protocol (IKE)
Handover (HO)
Next Steps in Signaling (NSIS)
Quality of Service (QoS)
NSIS Transport-Layer Protocol (NTLP), NSIS Signaling-Layer Protocol (NSLP)
| TOC |
The reference scenario that will be used in this document is illustrated in Figure 1. A mobile node (MN) in movement can attach to the new Access Router (nAR) and possibly loose the connectivity to the previous Access Router (pAR). Here two potential problems need to be resolved. Firstly, an AR should authenticate the MN and authorize the MN's credential to prove that it has the right to use certain services. A new Security Association (SA), which is related to the MN's new Care of Address (nCoA), needs to be established with the nAR, typically being a shared secret. Secondly, in order for the MN to obtain some services (e.g., QoS and header compression) on the new subnet, the MN must explicitly re-establish the service by performing the necessary signaling from scratch and thus, install some service-related information (state) in the new path via the nAR. This can be done by applying the NSIS mechanisms, which consist of two layers, namely the NSIS Transport Layer protocol (NTLP) and the NSIS Signaling Layer Protocols (NSLPs), in the new path. Directly applying NSIS can be considerable expensive due to two main reasons:
An alternative is to transfer existing NSIS state ("context"), to the new subnet, by the Context Transfer Protocol (CTP).
+------------+
+--+ | previous | <
|MN| ---------- | Access | ------ > ----\
+--+ | Router(pAR)| < \
| +------------+ +-------------+
| moving ^ IP |Correspondent|
| |NSIS-CTP Core |Node (CN) |
V | Network +-------------+
v /
+------------+ /
+--+ | new | NSIS < /
|MN| ---------- | Access | ------ > ----/
+--+ | Router(nAR)| <
+------------+
Figure 1 - Reference Scenario
| TOC |
Before an overview of NSIS-CTP interoperation is given, some necessary extensions to NSIS and CTP are suggested.
According to [I-D.ietf-seamoby-ctp], a CTP message contains one or several context blocks of different Feature Profile Types (FPTs). Here, we suggest seven new FPTs, namely "NSIS transfer request", "NSIS transfer response", "NSIS generic/NTLP context (downlink)", "NSIS generic/NTLP context (uplink)", "QoS NSLP context (downlink)" and "QoS NSLP context (uplink)", for the interoperation between NSIS and CTP. The detailed data fields for each message type are to be defined in a later version of this document.
NSIS should be extended to be aware of NSIS-CTP, by introducing a set of new operation states in the MN and ARs ("Predictive HO Waiting", "Non-Predictive CTD Waiting", "waiting for release", "NSIS active", in addition to normal NSIS state - here so-called "NSIS idle", see discussions in Section 5.1), an NSIS-CTP session key (NCSK) (see discussions in Section 5.2), and new interfaces in the MN and the ARs (see discussions in Section 5.3).
QoS profile introduced in [I-D.westphal-seamoby-qos-relocate] can be the content of QoS-NSLP context.
CT can work in two different modes. When CT is performed prior to handover it is called predictive mode. Otherwise it is called non-predictive mode. Subsequently, this document distinguishes the NSIS-CTP operation modes into two modes (predictive and non-predictive modes) by different orders of performing the following two actions:
The modes describe in which order the two main steps are performed. Each mode of NSIS-CTP consist of several steps. Some steps slightly differ between predictive and non-predictive modes, which will be explained in Section 5.1.
Some steps act as a trigger for the NSIS protocol, i.e., to process the QoS profile types or to install new states. Some other steps are for security reasons, e.g., to authenticate the CT transaction and NSIS state changes. The basic steps for a typical NSIS-CTP operation can be as follows:
| TOC |
This section discusses some of the related issues in more detail. The difference between predictive and non-predictive modes and how this framework deals with them is discussed in this section. It will be explained why the NSIS-CTP Session Key (NCSK) is introduced for this interoperation and what are the advantages. Afterwards it is explained how the nAR can initiate refreshments in charge of the mobile node.
The CTP provides two different modes, namely the predictive and non-predictive modes. Predictive means to transfer context prior to a handover where the normal (non-predictive) mode performs context transfer after the handover.
The CTP always sends a CTAR message to both the pAR and the nAR. That is because it is not clear weather the MN looses connectivity to the pAR or not. In the following the two scenarios (predictive and non-predicitive) are discussed in detail. Figure 2 illustrates the message flow.
The CTAR message arrives at the pAR. CT to the nAR is initiated. In this predictive mode all keying information, including the shared secret and the algorithm is also transferred to the nAR. Once the MN attaches to the nAR it will send a CTAR message to activate the transferred context.
The NSIS context includes a "predictive" flag. This flag must be set by the pAR-NSIS entity in order to indicate the predictive context transfer. The nAR-NSIS entity sends a "waiting" state according to the predictive flag. In predictive case NTLP and NSLP-QoS states will be installed, then NSIS activities such as next-peer discovery can be performed along the new path. However, the nAR-NSIS entity is aware that the mode is still inactive since the MN will arrive.
In the case that the mobile node never reaches the nAR the states should be released. Therefore a timer is recommended that releases the states after timeout.
When the mobile node attaches to the nAR and thus sends a CTAR, the CTP should trigger NSIS to change the operational state from "Predictive HO waiting" to "NSIS active".
In the non-predictive scenario the mobile node sends a CTAR just to the nAR. The nAR forwards the message to the pAR in order to initiate the context transfer, and changes its state to "Non-predictive CTD waiting". Accordingly the pAR sends the context to the nAR.
In this case the mobile node is assumed to be already connected to the nAR. Therefore the pAR-NSIS entity should release the state right after creating the profile type for CTP.
The predictive flag is not set, thus the nAR-NSIS entity should install the state as "NSIS active".
Predictive Mode MN nAR NSIS pAR NSIS | | | | |[QoS] |---CTAR---------------------------------->| | | | | |------>| | | | |<------| | |<------- CTD --------------| | | |------>|[QoS predictive] | | | | | | | |---CTAR------>| | | | | |------>|[QoS] | | | | | | | | | | | | Non-Predictive Mode MN nAR NSIS pAR NSIS | | | | |[QoS] | | | | | |---CTAR------>| |[waiting] | | | |---- CT Request ---------->| | | | | |------>| | | | |<------|[QoS relea.] | |<-------- CTD -------------| | | |------>|[QoS] | | | | | | |
Figure 2 - Predictive Mode v.s. Non-Predictive Mode
The state machine of the access routers are illustrated in Figure 3.
START
|
............................|......................................
nAR |
V
+-----------------+ <-----------------------+
| NSIS | <--------------------+ |
+---------| idle |----------+ | |
CTAR | | | CTD | | |
from | +-----------------+ from | | |
MN | pAR | | |
V V | |
+-----------------+ +-----------------+ | |
| non-predictive | | predicitve | | |
| CTD waiting | | HO waiting | | |
| | | | | |
+-----------------+ +-----------------+ | |
| | | |
CTP | CTAR | | |
from | from | | |
pAR | MN | | |
.........|......................................|...........|..|...
pAR | | | |
| +-----------------+ | CT | |
| | NSIS | | (non-per.)| |
+-------> | active | <--------+ | |
| |----------------------+ |
+-----------------+ CT req. from nAR |
^ | (non-predicitve mode |
| | only) |
| | |
timer OR | | CT Req. from nAR |
CT error | | (predic. mode only) |
| V CT |
+-----------------+ (perdic.) |
| waiting | |
| for |-------------------------+
| release |
+-----------------+
Figure 3 - State Machine for Access Routers
This section discusses the usage of the NSIS-CTP Session Key (NCSK).
The CTP assumes a secure channel between the pAR and nAR. This channel is usually an IPSec tunnel. The shared secret can be exchanged by the Internet Key Exchange protocol (IKE). To provide a sufficient secure channel, the encryption should be as least as strong as normally required by the suggested NSIS security [I-D.ietf-nsis-threats].
The CTP provides an authentication token. Usually the algorithm for the token computation is HMAC-SHA1. The input data consists of the MN, previous IP address, the FPT, and the "Replay" field. The authorisation token is obtained by truncating the result of the HMAC-SHA1 computation to retain only the leading 32 bits. The replay field prevents from relay attacks so that the message can be used only once. The authorisation token is based on the shared key between the pAR and the MN.
When CTP is performed, either the pAR or the nAR proves the token. In the non-predictive mode the pAR computes the token and compares the results. In case of predictive mode the pAR forwards all keying material to the nAR. Once the MN connects to the nAR the token comparison will be performed locally at the nAR.
Each NSIS context must contain an NSIS-CTP Session Key (NCSK). It is recommended to uses at least a 128-bit key. This key can be either an NSIS session that is known along the path or a shared secret just between the pAR and the nAR. In the latter case it might be even a pseudo-random number + timestamp.
In case the key is shared along the NSIS path it is known by the CN or even the MN.
The NCSK may be used by the nAR to release the NSIS state at the pAR. Authentication can be achieved even when the message is sent over an insecure channel by using NCSK for authentication or encryption.
This document does not directly rely on the CTP authentication token for security reason. The NCSK should never be sent over the wireless link and should only be transferred over secured channels.
The NCSK can be used to authenticate the pAR-NSIS entity, where the pAR should distribute the NCSK along the path. In this case the NCSK may be used to establish the NSIS state in the path from the nAR to the CN without requesting some authentication token or key from the MN. That makes the process potentially faster since no authentication information, token or key has to be sent from the MN to the nAR for NSIS peer discovery.
This framework improves security because of the usage of two keys. The 32-bit CTP authentication token initiates the NSIS state installation, while the recommended NCSK is used for NSIS security.
In case of the predictive mode, additional advantage can be gained. The nAR can establish the NSIS states and is authorized to perform NSIS states installation along the path. In this case the NSIS state may be established prior to the MN arrival at the nAR. Thus it is unnecessary to perform NSIS signaling (including QoS reservation) from scratch after the MN attaches to the nAR. Especially for voice or multimedia application this advantage can be extremely important.
There are several triggers and operational states necessary for the framework, which are closely related to each other. NSIS needs 3 more states in addition to its normal operational states. The CTP entity should trigger the NSIS entity and thus switches the state from one to another.
- States in the AR:
- There should be a state which we call "NSIS Idle", where the NTLP and NSLP-QoS states are not yet established but NSIS is running. In addition to this state, the following other states are necessary in the ARs (also see state machine shown in Figure 3). We do not distinguish between pAR and nAR, since the current nAR can be the pAR of a future handover.
- NSIS Active:
- The state in which the AR is usually working. That means the MN is attached and NTLP and NSLP-QoS states are established.
- Predictive HO Waiting:
- In the predictive mode, context is transferred to nAR before the MN attaches. The arrival of the CTD message at the nAR triggers the state to change to "Predictive HO Waiting". Once the MN attaches to the nAR and sends a CTAR to the nAR it triggers a state change to "NSIS Active".
- Non-predictive CTD Waiting:
- In the non-predictive mode, the MN attaches before the context is available. The MN sends a CTAR message. This message triggers the nAR to change its state to "Non-Predictive CTP Waiting" In this case the AR changes to this state and is waiting for the context. Once the context arrives the state will be changed to "NSIS Active".
- Waiting for release:
- Whenever the pAR receives a CT request, it changes its state from "NSIS Active" to "Waiting for release". When it experiences the timer expiration or receives a CT error message, it changes its state from "Waiting for release" to "NSIS Active". If the pAR receives a CT acknoweldgement message, it changes its state from "Waiting for release" to "NSIS Idle", and release its NSIS state.
- States in the MN:
- In the MN there should be an operational state indicates that a CTAR has been send out and the MN is now waiting for the CTP to send a relay. If the NSIS-CTP fails, the MN should be able to initialize NSIS signaling from scratch and switch its state accordingly (see discussions in Section 5.5).
With the soft state principle, NSIS state will be valid for a limited period of time. After this period they need to be refreshed. Usually for a data path between the MN and the CN the refresh is initiated by the Mobile Node and forwarded along the path. In case that no refresh will occur in a node, NSIS will release all states for this specific path. A timer is triggering these events and it is set back to its maximum whenever a refresh occurs.
This document suggests to let the nAR initiate the state establishments and the state refreshes. Thus the nAR should send a refresh the states along the path from the nAR to the CN. These refreshes can occur more frequently than the signaling to the MN. This reduces the signaling overhead over the wireless link.
This section describes how the mechanism deals with errors. NSIS-CTP expedites the NSIS state installation, however, the fallback to normal NSIS signaling for state installation is always possible.
When the MN attaches to the nAR, it can happen there will be no NSLP QoS states made available by NSIS-CTP.
| TOC |
The following open issues should be considered in future:
| TOC |
This section shows how security can be archieved. This needs to be handled with care since NSIS and CTP are interoperating and NSIS partly needs to rely on CTP. On one hand the CTP authentication token triggers the NSIS state installation. On the other hand the NSIS key is transferred over the secure channel of the CTP.
It is important not to introduce new security holes. That is why this interoperation framework tries to make a minimum of assumptions and rely on NSIS and CTP's own mechanisms. This is a trade-off between security, complexity, and performance.
To actually improve the performance the following assumptions about security are made. In case these assumptions are invalid the whole environment is considered to be insecure.
The conditions changed when NSIS uses CTP for QoS state and Session Key forwarding. Therefore possible attacks are considered.
- Eavesdropping:
- The NCSK will never be sent over the wireless link. The NCSK will be transmitted only in between the pAR and nAR. Here an IPSec tunnel secures the messages. Therefore this method prevents from eavesdropping the NCSK;
- DoS:
- Denial of Service (DoS) attacks can be caused by forged or more-than-necessary CTP requests sent by malicious or uncautious MNs. Therefore the nAR-NSIS entity should restrict the maximum of NSIS CT requests per node. It can be assumed that one mobile node has knowledge of only one CTP authentication token.
| TOC |
We would like to acknowledge Michael Ebner for his comments.
| TOC |
| [I-D.ietf-mobileip-fast-mipv6] | Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-08 (work in progress), October 2003. |
| [I-D.ietf-nsis-fw] | Hancock, R. and et al., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-04 (work in progress), September 2003. |
| [I-D.ietf-nsis-qos-nslp] | Van den Bosch, S. and et al., "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-00 (work in progress), September 2003. |
| [I-D.ietf-nsis-threats] | Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", draft-ietf-nsis-threats-02 (work in progress), July 2003. |
| [I-D.ietf-seamoby-ctp] | Loughney, J. and et al., "Context Transfer Protocol", draft-ietf-seamoby-ctp-04 (work in progress), October 2003. |
| [I-D.westphal-nsis-qos-mobileip] | Westphal, C. and H. Chaskar, "QoS Signaling Framework for Mobile IP", draft-westphal-nsis-qos-mobileip-00 (work in progress), June 2002. |
| [I-D.westphal-seamoby-qos-relocate] | Westphal, C. and H. Chaskar, "Context Relocation of QoS Parameters in IP Networks", draft-westphal-seamoby-qos-relocate-00 (work in progress), July 2001. |
| [RFC3374] | Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002. |
| [RFC3583] | Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003. |
| TOC |
| Rene Soltwisch | |
| University of Goettingen | |
| Telematics Group | |
| Lotzestr. 16-18 | |
| Goettingen 37083 | |
| Germany | |
| EMail: | soltwisch@cs.uni-goettingen.de |
| Xiaoming Fu | |
| University of Goettingen | |
| Telematics Group | |
| Lotzestr. 16-18 | |
| Goettingen 37083 | |
| Germany | |
| EMail: | fu@cs.uni-goettingen.de |
| Dieter Hogrefe | |
| University of Goettingen | |
| Telematics Group | |
| Lotzestr. 16-18 | |
| Goettingen 37083 | |
| Germany | |
| EMail: | hogrefe@cs.uni-goettingen.de |
| Sathya Narayanan | |
| Panasonic Information and Networking Technology Lab | |
| Two Research Way | |
| Princeton, NJ 8540 | |
| USA | |
| EMail: | sathya@research.panasonic.com |
| TOC |
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Funding for the RFC Editor function is currently provided by the Internet Society.