Network Working Group R. Soltwisch
Internet-Draft X. Fu
Expires: April 17, 2004 D. Hogrefe
Univ. Goettingen
S. Narayanan
Panasonic USA
October 18, 2003
A Framework for Interoperation between NSIS and CTP
draft-soltwisch-nsis-ctp-interop-00.txt
Status of this Memo
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
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.
Soltwisch, et al. Expires April 17, 2004 [Page 1]
Internet-Draft NSIS CTP Interop October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Reference Scenario . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Extensions to NSIS and CTP . . . . . . . . . . . . . . . . . 6
4.2 Operational Overview . . . . . . . . . . . . . . . . . . . . 6
5. Detailed Discussions . . . . . . . . . . . . . . . . . . . . 8
5.1 Predictive vs. Non-Predictive Mode . . . . . . . . . . . . . 8
5.1.1 Predictive Scenario . . . . . . . . . . . . . . . . . . . . 8
5.1.2 Non-Predictive Scenario . . . . . . . . . . . . . . . . . . 9
5.2 NSIS-CTP Session Key . . . . . . . . . . . . . . . . . . . . 11
5.2.1 Secure Channel between pAR and nAR . . . . . . . . . . . . . 11
5.2.2 Security Provided by CTP . . . . . . . . . . . . . . . . . . 11
5.2.3 NSIS-CTP Session Key . . . . . . . . . . . . . . . . . . . . 11
5.3 Triggers and Operational States . . . . . . . . . . . . . . 12
5.4 NSIS State Refreshment . . . . . . . . . . . . . . . . . . . 13
5.5 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . 16
7.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
Soltwisch, et al. Expires April 17, 2004 [Page 2]
Internet-Draft NSIS CTP Interop October 2003
1. Introduction
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.
Soltwisch, et al. Expires April 17, 2004 [Page 3]
Internet-Draft NSIS CTP Interop October 2003
2. Terminology
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)
Soltwisch, et al. Expires April 17, 2004 [Page 4]
Internet-Draft NSIS CTP Interop October 2003
3. Reference Scenario
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:
1. The bandwidth in typical wireless environments can be low, and
2. the SA between MN and nAR is difficult to obtain because of
lacking of trust relationship.
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
Figure 1
Soltwisch, et al. Expires April 17, 2004 [Page 5]
Internet-Draft NSIS CTP Interop October 2003
4. Overview
Before an overview of NSIS-CTP interoperation is given, some
necessary extensions to NSIS and CTP are suggested.
4.1 Extensions to NSIS and CTP
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.
4.2 Operational Overview
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:
o Handover, i.e., the MN changes its connectivity from the pAR to
the nAR.
o (QoS/NSIS) Context transfer, i.e., transfer NSIS context from the
pAR to the nAR.
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
Soltwisch, et al. Expires April 17, 2004 [Page 6]
Internet-Draft NSIS CTP Interop October 2003
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:
1. The MN sends a Context Transfer Activity Request (CTAR) message
including the authentication token and NSIS-related FPTs to the
nAR;
2. The nAR forwards the CTAR to the pAR. If possible the MN sends
the CTAR directly to the pAR, in order to perform a predictive
CT;
3. The pAR-CTP entity (the CTP entity at the pAR) computes the
authentication token and checks if they are equal;
4. The pAR-CTP entity requests a QoS profile and NTLP context from
NSIS entity;
5. The pAR-NSIS entity generates the NSIS-CTP Session Key (NCSK),
then creates the QoS profile;
6. The pAR sends the CTD message to the nAR;
7. The CTD arrival triggers the local NSIS state establishment at
nAR according to the transferred context;
8. The nAR's NSLP-QoS entity performs QoS installation along the
path.
Soltwisch, et al. Expires April 17, 2004 [Page 7]
Internet-Draft NSIS CTP Interop October 2003
5. Detailed Discussions
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.
5.1 Predictive vs. Non-Predictive Mode
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.
5.1.1 Predictive Scenario
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".
Soltwisch, et al. Expires April 17, 2004 [Page 8]
Internet-Draft NSIS CTP Interop October 2003
5.1.2 Non-Predictive Scenario
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
Figure 2
The state machine of the access routers are illustrated in Figure 3.
Soltwisch, et al. Expires April 17, 2004 [Page 9]
Internet-Draft NSIS CTP Interop October 2003
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
Figure 3
Soltwisch, et al. Expires April 17, 2004 [Page 10]
Internet-Draft NSIS CTP Interop October 2003
5.2 NSIS-CTP Session Key
This section discusses the usage of the NSIS-CTP Session Key (NCSK).
5.2.1 Secure Channel between pAR and nAR
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].
5.2.2 Security Provided by CTP
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.
5.2.3 NSIS-CTP Session Key
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.
Soltwisch, et al. Expires April 17, 2004 [Page 11]
Internet-Draft NSIS CTP Interop October 2003
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.
5.3 Triggers and Operational States
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".
Soltwisch, et al. Expires April 17, 2004 [Page 12]
Internet-Draft NSIS CTP Interop October 2003
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).
5.4 NSIS State Refreshment
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.
5.5 Error Handling
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.
o It is possible that the first possibility is that the nAR is not
Soltwisch, et al. Expires April 17, 2004 [Page 13]
Internet-Draft NSIS CTP Interop October 2003
NSIS aware or does not provide NSLP-QoS. In the first case the MN
may be notified and should perform the NSIS state installation
along the path on its own. In the second case the nAR provides at
least NTLP but no NSLP-QoS. In this case the MN may get a
notification that the next hop is NSIS-aware but does not provide
NSLP-QoS, then the NTLP context can be used.
o The timer expired and the state have been released before the MN
attaches. In this case the MN acts as if no CTP would be
available. The MN would perform usual NSIS state installation.
Soltwisch, et al. Expires April 17, 2004 [Page 14]
Internet-Draft NSIS CTP Interop October 2003
6. Open Issues
The following open issues should be considered in future:
o Support for fast handovers. The mechanism should even work in
cases that fast handover [I-D.ietf-mobileip-fast-mipv6] is used.
In this case the nAR-NTLP/NSLP should be inserted in the chain.
o Inter-domain interoperability. CTP has not yet resolved the
problem of interoperating between domains, because it assumes to
have an SA between pAR and nAR. Therefore, the interoperation of
CTP and NSIS heavily depends on the CTP solution in inter-domain
cases.
o How to integrate other key exchange mechanisms that authenticate
users rather than hosts. This means that AAA mechanisms such as
Radius or Diameter have to be used.
o Multiple usage of one channel for several mobile nodes. This
assumption considers a SA for each Mobile node or at least the
channel used by CTP. Since multiple MNs can be attached and they
all move to the same nAR the channel can be reused. That would
reduce the amount of traffic which brings a gain.
Soltwisch, et al. Expires April 17, 2004 [Page 15]
Internet-Draft NSIS CTP Interop October 2003
7. Security Considerations
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.
7.1 Assumptions
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.
o nAR and pAR share a strong trust relationship. Usually pAR and nAR
are located in the same administrative domain and thus should have
a strong trust relationship.
o nAR and pAR share a secret. Usually exchanged by the IKE
o A secure channel exists between nAR and pAR. IPSec must be
provided. ESP or AH header support with non-null encryption must
be used. The chosen mechanism must be appropriate according to the
requirement to transport the NCSK.
7.2 Attacks
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.
Soltwisch, et al. Expires April 17, 2004 [Page 16]
Internet-Draft NSIS CTP Interop October 2003
8. Acknowledgment
We would like to acknowledge Michael Ebner for his comments.
Soltwisch, et al. Expires April 17, 2004 [Page 17]
Internet-Draft NSIS CTP Interop October 2003
References
[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.
Soltwisch, et al. Expires April 17, 2004 [Page 18]
Internet-Draft NSIS CTP Interop October 2003
Authors' Addresses
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
Soltwisch, et al. Expires April 17, 2004 [Page 19]
Internet-Draft NSIS CTP Interop October 2003
Intellectual Property Statement
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.
Full Copyright Statement
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
Soltwisch, et al. Expires April 17, 2004 [Page 20]
Internet-Draft NSIS CTP Interop October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Soltwisch, et al. Expires April 17, 2004 [Page 21]