Stream Sequence Number n
Since the ’U’ bit is set to one, the
receiver ignores this number. See [SCTP].
Payload Protocol Identifier
Set to ’CXTP’ (see [IANA]).
User Data Contains the context transfer protocol
messages.
If a CXTP deployment will never run over the public Internet, and it
is known that congestion is not a problem in the access network,
alternative transport protocols MAY be appropriate vehicles for
experimentation. For example, piggybacking CXTP messages on top of
handover signaling for routing, such as provided by FMIPv6 in ICMP
[FMIPv6]. Implementations of CXTP MAY support ICMP for such
purposes. If such piggybacking is used, an experimental message
extension for the protocol on which CXTP is piggybacking MUST be
designed. Direct deployment on top of a transport protocol for
experimental purposes is also possible. In this case, the researcher
MUST be careful to accommodate good Internet transport protocol
engineering practices, including using retransmits with exponential
backoff.
3.2. MN-AR Transport
The MN-AR interface MUST implement and SHOULD use ICMP to transport
the CTAR and CTAA messages. Because ICMP contains no provisions for
retransmitting packets if signaling is lost, the CXTP protocol
incorporates provisions for improving transport performance on the
MN-AR interface. The MN and AR SHOULD limit the number of context
data block identifiers included in the CTAR and CTAA messages so that
the message will fit into a single packet, because ICMP has no
provision for fragmentation above the IP level. CXTP uses the
Experimental Mobility ICMP type [IANA]. The ICMP message format for
CXTP messages is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
Source Address An IP address assigned to the sending
interface.
Destination Address
An IP address assigned to the receiving
interface.
Hop Limit 255
ICMP Fields:
Type Experimental Mobility Type (To be assigned by IANA,
for IPv4 and IPv6, see [IANA])
Code 0
Checksum The ICMP checksum.
Sub-type The Experimental Mobility ICMP subtype for CXTP,
see [IANA].
Reserved Set to zero by the sender and ignored by
the receiver.
Message The body of the CTAR or CTAA message.
CTAR messages for which a response is requested but fail to elicit
a response are retransmitted. The initial retransmission occurs
after a CXTP_REQUEST_RETRY wait period. Retransmissions MUST be
made with exponentially increasing wait intervals (doubling the
wait each time). CTAR messages should be retransmitted until
either a response (which might be an error) has been obtained, or
until CXTP_RETRY_MAX seconds after the initial transmission.
MNs SHOULD generate the sequence number in the CTAR message
randomly (also ensuring that the same sequence number has not been
used in the last 7 seconds), and, for predictive transfer, MUST
use the same sequence number in a CTAR message to the nAR as for
the pAR. An AR MUST ignore the CTAR message if it has already
received one with the same sequence number and MN IP address.
Implementations MAY, for research purposes, try other transport
protocols. Examples are the definition of a Mobile IPv6 Mobility
Header [MIPv6] for use with the FMIPv6 Fast Binding Update
[FMIPv6] to allow bundling of both routing change and context
transfer signaling from the MN to AR, or definition of a UDP
protocol instead of ICMP. If such implementations are done, they
should abide carefully by good Internet transport engineering
practices and be used for prototype and demonstration purposes
only. Deployment on large scale networks should be avoided until
the transport characteristics are well understood.
4. Error Codes and Constants
Error Code Section Value Meaning
------------------------------------------------------------
BAD_CHECKSUM 3.1 0x01 Error code if the
SCTP checksum fails.
Constant Section Default Value Meaning
--------------------------------------------------------------------
CT_REQUEST_RATE 6.3 10 requests/ Maximum number of
sec. CTAR messages before
AR institutes rate
limiting.
CT_MAX_TRANSFER_TIME 3.1 200 ms Maximum amount of time
pAR should wait before
aborting the transfer.
CT_REQUEST_RETRY 3.2 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
CT_RETRY_MAX 3.2 15 seconds Give up retrying
on MN-AR interface.
5. Examples and Signaling Flows
5.1. Network Controlled, Initiated by pAR, Predictive
MN nAR pAR
| | |
T | | CT trigger
I | | |
M | |<------- CTD ----------|
E |------- CTAR -------->| |
: | | |
| | |-------- CTDR -------->|
V | | |
| | |
5.2. Network Controlled, Initiated by nAR, Reactive
MN nAR pAR
| | |
T | CT trigger |
I | | |
M | |--------- CT-Req ----->|
E | | |
: | |<------- CTD ----------|
| | | |
V |------- CTAR -------->| |
| |----- CTDR (opt) ----->|
| | |
5.3. Mobile Controlled, Predictive New L2 up/Old L2 down
CTAR request to nAR
MN nAR pAR
| | |
new L2 link up | |
| | |
CT trigger | |
| | |
T |------- CTAR -------->| |
I | |-------- CT-Req ------>|
M | | |
E | |<-------- CTD ---------|
: | | |
| | | |
V | | |
| | |
Whether the nAR sends the MN a CTAR reject message if CT is not
supported is for future study.
6. Security Considerations
At this time, the threats to IP handover in general and context
transfer in particular are not widely understood, particularly on the
MN to AR link, and mechanisms for countering them are not well
defined. Part of the experimental task in preparing CXTP for
eventual standards track will be to better characterize threats to
context transfer and design specific mechanisms to counter them.
This section provides some general guidelines about security based on
discussions among the Design Team and Working Group members.
6.1. Threats
The Context Transfer Protocol transfers state between access routers.
If the MNs are not authenticated and authorized before moving on the
network, there is a potential for masquerading attacks to shift state
between ARs, causing network disruptions.
Additionally, DoS attacks can be launched from MNs towards the access
routers by requesting multiple context transfers and then by
disappearing. Finally, a rogue access router could flood mobile
nodes with packets, attempt DoS attacks, and issue bogus context
transfer requests to surrounding routers.
Consistency and correctness in context transfer depend on
interoperable feature context definitions and how CXTP is utilized
for a particular application. For some considerations regarding
consistency and correctness that have general applicability but are
articulated in the context of AAA context transfer, please see [EAP].
6.2. Access Router Considerations
The CXTP inter-router interface relies on IETF standardized security
mechanisms for protecting traffic between access routers, as opposed
to creating application security mechanisms. IPsec [RFC2401] MUST be
supported between access routers.
To avoid the introduction of additional latency due to the need for
establishing a secure channel between the context transfer peers
(ARs), the two ARs SHOULD establish such a secure channel in advance.
The two access routers need to engage in a key exchange mechanism
such as IKE [RFC2409], establish IPSec SAs, and define the keys,
algorithms, and IPSec protocols (such as ESP) in anticipation of any
upcoming context transfer. This will save time during handovers that
require secure transfer. Such SAs can be maintained and used for all
upcoming context transfers between the two ARs. Security should be
negotiated prior to the sending of context.
Access Routers MUST implement IPsec ESP [ESP] in transport mode with
non-null encryption and authentication algorithms to provide per-
packet authentication, integrity protection and confidentiality, and
MUST implement the replay protection mechanisms of IPsec. In those
scenarios where IP layer protection is needed, ESP in tunnel mode
SHOULD be used. Non-null encryption should be used when using IPSec
ESP. Strong security on the inter-router interface is required to
protect against attacks by rogue routers, and to ensure
confidentiality on the context transfer authorization key in
predicative transfer.
The details of IKE key exchange and other details of the IPsec
security associations between routers are to be determined as part of
the research phase associated with finalizing the protocol for
standardization. These details must be determined prior to
standardization. Other working groups are currently working on
general security for routing protocols. Ideally, a possible solution
for CXTP will be based on this work to minimize the operational
configuration of routers for different protocols. Requirements for
CXTP will be brought to the appropriate IETF routing protocol
security working groups for consideration.
6.3. Mobile Node Considerations
The CTAR message requires the MN and AR to possess a shared secret
key to calculate the authorization token. Validation of this token
MUST precede context transfer or installation of context for the MN,
removing the risk that an attacker could cause an unauthorized
transfer. How the shared key is established is out of scope of this
specification. If both the MN and AR know certified public keys of
the other party, Diffie-Hellman can be used to generate a shared
secret key [RFC2631]. If an AAA protocol of some sort is run for
network entry, the shared key can be established using that protocol
[PerkCal04].
If predictive context transfer is used, the shared key for
calculating the authorization token is transferred between ARs. A
transfer of confidential material of this sort poses certain security
risks, even if the actual transfer itself is confidential and
authenticated, as is the case for inter-router CXTP. The more
entities know the key, the more likely a compromise may occur. To
mitigate this risk, nAR MUST discard the key immediately after using
it to validate the authorization token. The MN MUST establish a new
key with the AR for future CXTP transactions. The MN and AR SHOULD
exercise care in using a key established for other purposes for also
authorizing context transfer. The establishment of a separate key
for context transfer authorization is RECOMMENDED.
Replay protection on the MN-AR protocol is provided by limiting the
time period in which context is maintained. For predictive transfer,
the pAR receives a CTAR message with a sequence number, transfers the
context along with the authorization token key, and then drops the
context and the authorization token key immediately upon completion
of the transfer. For reactive transfer, the nAR receives the CTAR,
requests the context that includes the sequence number and
authorization token from the CTAR message that allows the pAR to
check whether the transfer is authorized. The pAR drops the context
and authorization token key after the transfer has been completed.
The pAR and nAR ignore any requests containing the same MN IP address
if an outstanding CTAR or CTD message is unacknowledged and has not
timed out. After the key has been dropped, any attempt at replay
will fail because the authorization token will fail to validate. The
AR MUST NOT reuse the key for any MN, including the MN that
originally possessed the key.
DoS attacks on the MN-AR interface can be limited by having the AR
rate limit the number of CTAR messages it processes. The AR SHOULD
limit the number of CTAR messages to the CT_REQUEST_RATE. If the
request exceeds this rate, the AR SHOULD randomly drop messages until
the rate is established. The actual rate SHOULD be configured on the
AR to match the maximum number of handovers that the access network
is expected to support.
7. Acknowledgements & Contributors
This document is the result of a design team formed by the chairs of
the SeaMoby working group. The team included John Loughney, Madjid
Nakhjiri, Rajeev Koodli and Charles Perkins.
Basavaraj Patil, Pekka Savola, and Antti Tuominen contributed to the
Context Transfer Protocol review.
The working group chairs are Pat Calhoun and James Kempf, whose
comments have been very helpful in the creation of this
specification.
The authors would also like to thank Julien Bournelle, Vijay
Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf
Motiwala, Phil Neumiller, Hesham Soliman, and Lucian Suciu for their
help and suggestions with this document.
8. References
8.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[SCTP] 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.
[PR-SCTP] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[IANA] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005.
8.2. Informative References
[FHCT] R. Koodli and C. E. Perkins, "Fast Handovers and Context
Transfers", ACM Computing Communication Review, volume
31, number 5, October 2001.
[TEXT] M. Nakhjiri, "A time efficient context transfer method
with Selective reliability for seamless IP mobility",
IEEE VTC-2003-Fall, VTC 2003 Proceedings, Vol.3, Oct.
2003.
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
4068, July 2005.
[LLMIP] K. El Malki et al., "Low Latency Handoffs in Mobile
IPv4", Work in Progress.
[RFC3374] Kempf, J., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network",
RFC 3374, September 2002.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[TERM] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[PerkCal04] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys for
Mobile IPv4", RFC 3957, March 2005.
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October