Seamoby WG J. Loughney (editor) Internet Draft M. Nakhjiri Category: Experimental C. Perkins
<draft-ietf-seamoby-ctp-08.txt><draft-ietf-seamoby-ctp-09.txt> R. Koodli Expires: July 21,October 13, 2004 January 21,April 14, 2004 Context Transfer Protocol Status of this Memo This document is an Internet-DraftBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and isany of which I become aware will be disclosed, in full conformanceaccordance with all provisions of Section 10 of RFC2026 [RFC2026].RFC 3668. 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.txthttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society 2004. All Rights Reserved. Abstract This document presents a context transfer protocol that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency, packet losses and avoiding re-initiation of signaling to and from the mobile node. Table of Contents 1. Introduction 1.1 The Problem 1.2 Conventions Used in This Document 1.3 Abbreviations Used in the Document 2. Protocol Overview 2.1 Context Transfer Scenarios 2.2 Context Transfer Packet FormatsMessage Format 2.3 Context Types 2.4 Context Data Block (CTB) 2.5 Messages 3. Transport, Reliability and Retransmission of Feature DataTransport 3.1 Inter-Router Transport 3.2 MN-AR Transport 4. Open Issues 4.1 Failure HandlingError Codes and Constants 5. Examples and Signaling Flows 5.1 Network controlled, Initiated by pARpAR, Predictive 5.2 Network controlled, Initiated by nARnAR, Reactive 5.3 Mobile controlled, Predictive New L2 up/old L2 down 6. Security Considerations 6.1 Threats 6.2 Access Router Considerations 6.3 Mobile Node Considerations 7. IANA Considerations 8. Acknowledgements & Contributors 9. References 9.1 Normative References 9.2 Non-Normative References Appendix A. Timing and Trigger Considerations Appendix B. Multicast Listener Context Transfer Author'sAuthors' Addresses Full Copyright Statement Intellectual Property Acknowledgement 1. Introduction This document describes the Context Transfer Protocol overview, which provides: * Representation for feature contexts. * Messages to initiate and authorize context transfer, and notify a mobile node of the status of the transfer. * Messages for transferring contexts prior to, during and after handovers. The proposed protocol is designed to work in conjunction with other protocols in order to provide seamless mobility. The protocol supports both IPv4 and IPv6, though support for IPv4 private addresses is for future study. 1.1 The Problem "Problem Description: Reasons For Performing Context Transfers between Nodes in an IP Access Network" [RFC3374] defines the following main reasons why Context Transfer procedures may be useful in IP networks. 1) The primary motivation, as mentioned in the introduction, is the need to quickly re-establish context transfer-candidate services without requiring the mobile host to explicitly perform all protocol flows for those services from scratch. An example of a service is included in Appendix C.B. 2) An additional motivation is to provide an interoperable solution that supports various Layer 2 radio access technologies. 1.11.2 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.21.3 Abbreviations Used in the Document Mobility Related Terminology [TERM] defines basic mobility terminology. In addition to the material in that document, we use the following terms and abbreviation in this document. CTP Context Transfer Protocol DoS Denial-of-Service FPT Feature Profile Types PCTD Predictive Context Transfer Data 2. Protocol Overview This section provides a protocol overview. A context transfer can be either started by a request from the mobile node ("mobile controlled") or at the initiative of either the new or the previous access router ("network controlled"). * The mobile node (MN) sends the CT Activate Request to old ARits current access router (AR) immediately prior to handover whenever possible to initiate predictive context transfer. In any case, the MN always sends the CTAR message to new AR.AR (nAR). If the contexts are already present, nAR would verifyverifies the authorization token present in CTAR with its own computation (usingusing the parameters supplied by pAR),the previous access router (pAR), and subsequently activateactivates those contexts. If the contexts are not present, nAR requests pAR to supply them using the Context Transfer Request message, in which it supplies the authorization token present in CTAR. * Either nAR or pAR may request or start (respectively) context *transfer based on internal or network triggers (see Appendix B).A). The Context Transfer protocol typically operates between a source node and a target node. In the future, there may be multiple target nodes involved; the protocol described here would work with multiple target nodes. For simplicity, we describe the protocol assuming a single receiver or target node. Typically, the source node is a MN's Previous Access Router (pAR)pAR and the target node is MN's New Access Router (nAR).nAR. Context Transfer takes place when an event, such as a handover, takes place. We call such an event a Context Transfer Trigger. In response to such a trigger, the pAR may transfer the contexts; the nAR may request contexts; and the MN may send a message to the routers to transfer contexts. Such a trigger must be capable of providing the necessary information, suchinformation (such as the MN's IP address withaddress) by which the contexts are associated,identified, the IP addresses of the access routers, and authorization to transfer context. Context transfer protocol messages use Feature Profile Types (FPTs) that identify the way that data is organized for the particular feature contexts. The Feature Profile Types (FPTs)FPTs are registered in a number space (with IANA Type Numbers) that allows a node to unambiguously determine the type of context and the context parameters present in the protocol messages. Contexts are transferred by laying out the appropriate feature data within Context Data Blocks according to the format in sectionSection 2.3, as well as any IP addresses necessary to associate the contexts to a particular MN. The context transfer initiation messages contain parameters that identify the source and target nodes, the desired list of feature contexts and IP addresses to identify the contexts. The messages that request transfer of context data also contain an appropriate token to authorize the context transfer. Performing context transfer in advance of the MN attaching to nAR can increase handover performance. For this to take place, certain conditions must be met. For example, pAR must have sufficient time and knowledge about the impending handover. This is feasible, for instance, in Mobile IP fast handovers.handovers [LLMIP][FMIPV6]. Additionally, many cellular networks have mechanisms to detect handovers in advance. However, when the advance knowledge of impending handover is not available, or if a mechanism such as fast handover fails, retrieving feature contexts after the MN attaches to nAR is the only available means for context transfer. Performing context transfer after handover might still be better than having to re-establish all the contexts from scratch. Finally, some contexts may simply need to be transferred during handover signaling. For instance, any context that gets updated on a per-packet basis must clearly be transferred only after packet forwarding to the MN on its previous link is terminated. The messages (CTD and CTDR) that perform the context transfer between the access routers need to be authenticated, so that the access routers can be certain that the data has not been tampered with during delivery.2.1 Context Transfer Scenarios The Previous Access Router transfers feature contexts under two general scenarios. 2.1.1 Scenario 1 The pAR may receivereceives a Context Transfer Activate Request (CTAR) message from the MN whose feature contexts are to be transferred, or it receives an internally generated trigger (e.g., a link-layer trigger on the interface to which the MN is connected). The CTAR message, described in Section 2.5, provides the IP address of nAR, the IP address of MN on pAR, the list of feature contexts to be transferred (by default requesting all contexts to be transferred), and a token authorizing the transfer. It also includes the MN's new IP address (valid on nAR) whenever it is known.In response to a CT- ActivateCT-Activate Request message or to the CT trigger, pAR predictively transmits a Context Transfer Data (CTD) message that contains feature contexts. This message, described in Section 2.5, contains the MN's previous IP address and its new IP address (if known).address. It also contains parameters for nAR to compute an authorization token to verify the MN's token present in CTAR message. Recall that the MN always sends CTAR message to nAR regardless of whether it sent the CTAR message to pAR. The reason for this is that there is no means for the MN to ascertain that context transfer reliably took place. By always sending the CTAR message to nAR, the Context Transfer Request (see below) can be sent to pAR wheneverif necessary. When context transfer takes place without the nAR requesting it, nAR requires MN to present its authorization token. Doing this locally at nAR when the MN attaches to it improves performance and increases security, since the contexts are highly likely to be present already. Token verification takes place at the router possessing the contexts. 2.1.2 Scenario 2 In the second scenario, pAR receives a Context Transfer Request (CT Request),(CT- Req), described in Section 2.5, message from nAR. The nAR itself generates the CT RequestCT-Req message eitheras a result of receiving the CTAR message or asmessage, or, alternatively, from receiving a response to an internal trigger (that indicates the MN's attachment).context transfer trigger. In the CT- ReqCT-Req message, nAR supplies the MN's previous IP address, the FPTs for the feature contexts to be transferred, the sequence number from the CTAR, and athe authorization token (generated byfrom the MN) authorizing context transfer.CTAR. In response to CT RequestCT-Req message, pAR transmits a Context Transfer Data (CTD) message that includes the MN's previous IP address and feature contexts. When it receives a corresponding CTD message, nAR may generate a CTD Reply (CTDR) message to report the status of processing the received contexts. When contexts are transferred reactively, the pAR verifies authorization token before transmitting the contexts, and hence the keyThe nAR installs the key is not needed incontexts once it has received them from the CTD message.pAR. 2.2 Context Transfer PacketMessage Format The packetA CTP message consists of a message specificmessage-specific header and one or more data packets.blocks. Data packetsblocks may be bundled together in order to ensure a more efficient transfer. The total packetOn the inter-AR interface, SCTP is used so fragmentation should not be a problem. On the MN-AR interface, the total packet size, including transport protocol and IP protocol headers SHOULD be less than the path MTU, in order to avoid packet fragmentation. Each message contains a three bit version number field in the low order octet, along with the 5 bit message type code. This specification only applies to Version 1 of the protocol, and the therefore version number field MUST be set to 0x1. If future revisions of the protocol make binary incompatible changes, the version number number MUST be incremented. 2.3 Context Types Contexts are identified by context type of Feature Profile Type (FPT),FPT code, which is a 15-bit number.16-bit unsigned integer. The meaning of each context type is determined by a specification document and the context type numbers are to be tabulated in a registry maintained by IANA,IANA [IANA], and handled according to the message specifications in this document. The instantiation of each context by nAR is determined by the messages in this document along with the specification associated with the particular context type. Each such context type specification contains theThe following details:diagram illustrates the general format for CTP messages: +----------------------+ | Message Header | +----------------------+ | CTP Data 1 | +----------------------+ | CTP Data 2 | +----------------------+ | ... | Each context type specification contains the following details: - Number, size (in bits), and ordering of data fields in the state variable vector which embodies the context. - Default values (if any) for each individual datum of the context state vector. - Procedures and requirements for creating a context at a new access router, given the data transferred from a previous access router, and formatted according to the ordering rules and date field sizes presented in the specification. - If possible, status codes for success or failure related to the context transfer. For instance, a QoS context transfer might have different status codes depending on which elements of the context data failed to be instantiated at nAR. 2.4 Context Data Block (CTB) The Context Data Block (CTB) is used both for request and response operation. When a particular featurerequest is constructed, only the first 4 bytes are typically necessary (See CTAR below). When used for transferring the actual feature context itself, the context data is present, and sometimes the presence vector is present. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cxt-Type | Length |P|Feature Profile Type (FTP) | Length |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Presence Vector (if P = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + data + | |~ Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cxt-Type Single octet, definedFeature Profile Type 16 bit integer, assigned by IANAIANA, indicating the type of data included in the Data field Length messageMessage length in units of 8 octet wordswords. 'P' bit 0 = No presence vector 1 = Presence vector present. FPT 16 bit integer, listing the feature profile type contained inReserved Reserved for future use. Set to zero by the data field. datasender. Data Context type-dependent data, whose length is defined by the Length Field. If the data is not 64-bit aligned, the data field is padded with zeros. The Cxt-Type indicates the type of the feature context message itself (such as QoS Context Request, QoS Context Transfer etc.), andFeature Profile Type (FPT) identifiescode indicates the waytype of data in the particular featuredata field. Typically, this will be context is organized.data but it might be an error indication. The 'P' bit, which is the high order bit in the Length field, specifies whether or not the "presence vector" is used. When the presence vector is in use, the Presence Vector is interpreted to indicate whether particular data fields are present (and containing non-default values). The ordering of the bits in the presence vector is the same as the ordering of the data fields according to the context type specification, one bit per data field regardless of the size of the data field. The Length field indicates the size of the CDBCTB in 8 octetsoctet words including the first 4 bytes starting from Cxt-Type. Cxt-Type = 0 is reserved for a general error message. The data field contains error codes information, and is defined by in specific context types.FPT. Notice that the length of the context data block is defined by the sum of lengths of each data field specified by the context type specification, plus 4 bytes if the 'P' bit is set, minus the accumulated size of all the context data that is implicitly given as a default value. 2.5 Messages In this section, a list ofthe availableCTP messages are defined. The MN for which context transfer message types is given, along with a brief description of their functions. In addition, the CTAR message also contains either the Previous Router's IP address or the New Router's IP address. The Mobile Node, for which context transfer protocol operations are undertaken,protocol operations are undertaken is always identified by its previous IP access address. At any onetime, only one context transfer operation per MN may be in progress so that the CTDR message unambiguously identifies which CTD message is acknowledged simply by including the mobile node'sMN's identifying previous IP address. The 'V' flag indicates whether the MN's previous address is IPv4 only, IPv6 only or bothIP addresses are present. See below.IPv4 or IPv6. 2.5.1 Context Transfer Activate Request (CTAR) Message This message is always sent by MN to nAR to request context transfer activation.transfer. Even when the MN does not know whether or notif contexts are present,need to be transferred, the MN sends the CTAR message to gain access with nAR.message. If an acknowledgement for this message is needed, the MN sets the A'A' flag to 1,1; otherwise the MN does not expect an acknowledgement. This message may include a list of FPT (feature profile types)FPTs that require transfer. It may include flags to request reliable transfer.The MN may also send this message to pAR while still connected to pAR. In such a case, the MN includes the nAR's IP address and its new IP address (if known) rather than previous IP address and pAR's IP address. Ifaddress; otherwise, if the new IP addressmessage is not known, then its previous IPsent to nAR, the pAR address is used.sent. The MN MUST set the sequence number to the same value for the message sent on both pAR and nAR so pAR can determine whether to use a cached message. 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=CTAR|Vers.| Type |V|A| Reserved | Length | V |A| Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's~ MN's Previous (New)IP Address |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Previous (New) RouterAR IP Address |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ReplaySequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CTP protocol = 0x1 Type CTAR = 10x1 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. 'A' bit If set, the MN requests an acknowledgement. Reserved Set to zero by the sender, ignored by the receiver. Length messageMessage length in units of 8 octet wordsbytes. MN's Previous IP Address Field contains either: IPv4 Address as defined in [RFC 791].791], 4 octets. IPv6 Address as defined in [RFC 2373].2373], 16 octets. nAR / pAR IP Address Field contains either: IPv4 Address as defined in [RFC 791].791], 4 octets. IPv6 Address as defined in [RFC 2373]. Reserved Reserved for future use. Must be set to zero by the MN. 'V' flag When set to '00', indicate presence of IPv6 Previous (New) address only. When set to '01' indicate presence of IPv4 Previous (New) Address only. When set to '10' indicate presence of both IPv6 and IPv4 Previous (New) addresses. 'A' bit The MN requests an acknowledgement. Replay2373], 16 octets. Sequence Number A value used to make sure that each use of the CTAR message is uniquely identifiable.identify requests and acknowledgements (see Section 3.2). Authorization Token An unforgeable value calculated as discussed below. This authorizes the receiver of CTAR to perform context transfer. Context Block Variable length field defined in sectionSection 2.4. If no context types are specified, thenall contexts for the mobile nodeMN are requested. When 'V' is 10, the IPv4 address MUST precede the IPv6 address both for the MN and the access router. Since Context Types clearly define the context including the IP version, context enumeration need not be in any strict order, although it might be natural to outline all the IPv4 contexts followed by IPv6 contexts.The Authorization Token is calculated as: First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context Types))),Sequence Number| CTBs))) where Key is thea shared secret between the MN and pAR, and Context Types includesCTBs is a concatenation of all the desiredContext Data Blocks specifying the contexts forto be transfered which are included in the transfer is desired. In the default scenario, the MN implicitly (i.e., even without the knowledge of contexts being present) or explicitly requests transfer of all contexts.CTAR message. 2.5.2 Context Transfer Activate Acknowledge (CTAA) Message This is an informative message sent by the receiver of CTAR to the MN to acknowledge a CTAR message. Acknowledgement is optional, depending on whether the MN requested it. This message may include a list of FPT (feature profile types)FPTs that were not transferred successfully. 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=CTAA|Vers.| Type |V| Reserved | Length | V | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Mobile Node's Previous IP address |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT (if present) | Status code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type CTAR = 2 Length message length in units of 8 octet words Reserved Reserved for future use. Must be set to zero by the senderVers. Version number of CTP protocol = 0x1 Type CTAA Message, i.e. pAR or nAR.= 0x2 'V' flag When set to '00', indicate presence of'0', IPv6 Previous (New) address only.addresses. When set to '01' indicate presence of'1', IPv4 Previous (New) Address only. When setaddresses. Reserved Set to '10' indicate presence of both IPv6zero by the sender and IPv4 Previous (New) addresses.ignored by the receiver. Length Message length in units of bytes. MN's PrevPrevious IP Address Field contains either: IPv4 Address as defined in [RFC 791].791], 4 octets. IPv6 Address as defined in [RFC 2373].2373], 16 octets. FPT 16 bit unsigned integer, listing the FTP that was not Successfullysuccessfully transferred. Status Code An octet, containing failure reason. 2.5.3 Context Transfer Data (CTD) Message Sent by pAR to nAR, and includes feature data (CTP data). This message should handlehandles predictive as well as normal CT. An acknowledgement flag, A,'A', included in this message indicates whether a reply is required by pAR. 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=(P)CTD|Vers.| Type |V|A| Reserved | Length | V |A| Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's New Care-of Address, when Type=PCTD |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | Algorithm | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD | Key | only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V |~ First Context Data Block |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Next Context Data Block |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ ........ |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CTP protocol = 0x1 Type CTD = 30x3 (Context Transfer Data) PCTD = 40x4 (Predictive Context Transfer Data) 'V' flag When set to '00', indicate presence of'0', IPv6 Previous (New) address only.addresses. When set to '01' indicate presence of'1', IPv4 Previous (New) Address only.addresses. 'A' bit When set to '10' indicate presence of both IPv6 and IPv4 Previous (New) addresses. 'A' bit The MNset, the pAR requests an acknowledgement. Length messageMessage length in units of 8 octet words Reserved Reserved for future use. Must be set to zero by the pAR.bytes. Elapsed Time The number of milliseconds since the transmission of the first CTD message. MN's Prev CoA Address Field contains either: IPv4 Address as defined in [RFC 791], IPv6 Address as defined in [RFC 2373].message for this MN. MN's New CoAPrevious IP Address Field contains either: IPv4 Address as defined in [RFC 791], 4 octets. IPv6 Address as defined in [RFC 2373]. This is only applicable for the PCTD message.2373], 16 octets. Algorithm Algorithm for carrying out the computation of the MN Authorization Token. Currently only 1 algorithm is defined, HMAC_SHA1 = 1. Key Length Length of key, in octets. Key Shared key between MN and AR for CTP. Context Data Block The Context Data Block (see Section 2.4). When CTD is sent predictively, the supplied parameters including the algorithm, key length and the key itself, allowallowing nAR to compute a token locally and verify against the token present in the CTAR message. This material is also sent if the pAR receives a CTD message with a null Authorization Token, indicating that the CT-Req message has been sent before the nAR received the CTAR message. CTD MUST be protected by IPsec.IPsec, see Section 6. As described previously, the algorithm for carrying out the computation of the MN Authorization Token is HMAC_SHA1. The input data for computing thetoken are:authentication calculation algorithm is described in Section 2.5.1. For predictive handover, the MN's Previous IP address,pAR SHOULD keep track of the FPT objectsCTAR sequence number and cache the Replay field. When support for transferring all contexts is requested,CTD message until receiving either a default FPT is used.CTDR message for the MN's previous IP address from the pAR, indicating that the context transfer was successful, or until CT_MAX_HANDOVER_TIME expires. The Authorization Token is obtained by truncatingnAR MAY send a CT-Req message containing the results ofsame sequence number if the HMAC_SHA1 computationpredictive CTD message failed to retain onlyarrive or the context was corrupted, In that case, the leading 32 bits.nAR sends a CT-Req message with a matching sequence number and pAR can resend the context. 2.5.4 Context Transfer Data Reply (CTDR) Message This message is sent by nAR to pAR depending on the value of the reliability'A' flag in CTD. Indicates success or failure. 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=CTDR|Vers.| Type |V|S| Reserved | Length | V |S| Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Mobile Node's Previous IP Address |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT (if present) | Status code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ ....... |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CTP protocol = 0x1 Type CTDR = 50x5 (Context Transfer Data) Length Message length in units of 8 octet words'V' flag When set to '00', indicate presence of'0', IPv6 Previous address only.addresses. When set to '01' indicate presence of IPv4 Previous Address only. When set to '10' indicate presence of both IPv6 and'1', IPv4 Previousaddresses. 'S' bit When set to one, this bit indicates that all thefeature contexts sent in CTD or PCTD were received successfully. Reserved Reserved for future use. Must be setSet to zero by the nAR.sender and ignored by the receiver. Length Message length in units of bytes. MN's PrevPrevious IP Address Field contains either: IPv4 Address as defined in [RFC 791].791], 4 octets. IPv6 Address as defined in [RFC 2373].2373], 16 octets. Status Code A context-specific return value, presentzero for success, nonzero when 'S' is not set to one. FPT 16 bit unsigned integer, listing the FTP that is being acknowledged. Status Code 0 = not successfully transfered 1 = successfully transfered2.5.5 Context Transfer Cancel (CTC) Message If transferring a context cannot be completed in a timely fashion, then nAR may send CTC to pAR to cancel an ongoing CT process. 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=CTC|Vers.| Type |V| Reserved | Length | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Mobile Node's Previous Care-ofIP Address |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CTP protocol = 0x1 Type CTC = 60x6 (Context Transfer Data)Cancel) Length Message length in units of 8 octet words Reserved Reserved for future use. Must bebytes. 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. Reserved Set to zero by the nAR.sender and ignored by the receiver. MN's Previous IP Address Field contains either: IPv4 Address as defined in [RFC 791], 4 octets. IPv6 Address as defined in [RFC 2373], 16 octets. 2.5.6 Context Transfer Request (CT Request)(CT-Req) Message Sent by nAR to pAR to request start of context transfer. This message is sent as a response to CTAR message byfrom the MN. The fields following the Previous IP address of the MN are included verbatim from the CTAR message. 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=CTREQ|Vers.| Type |V| Reserved | Length | V | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Mobile Node's Previous IP Address |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ReplaySequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ Next Requested Context Data Block (if present) |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |~ ........ |~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CTP protocol = 0x1 Type CTREQ = 7 Length Message length in units of 8 octet words0x7 (Context Transfer Request) 'V' bitsflag When set to '00', indicate presence of'0', IPv6 Previous (New) address only. When set to '01' indicate presence of IPv4 Previous (New) Address only.addresses. When set to '10' indicate presence of both IPv6 and'1', IPv4 Previous (New)addresses. Reserved Reserved for future use. Must be setSet to zero by the nAR. Replay A value used to make sure that each use ofsender and ignored by the CTAR message is uniquely identifiable.receiver. Length Message length in units of bytes. MN's Previous IP Address Field contains either: IPv4 Address as defined in [RFC 791], 4 octets. IPv6 Address as defined in [RFC 2373], 16 octets. Sequence Number Copied from CTAR. Authorization Token An unforgeable value calculated as discussed above.the CTAR message, allows the pAR to distinguish requests for previously sent context. MN's Authorization Token An unforgeable value calculated as discussed in Section 2.5.1. This authorizes the receiver of CTAR to perform context transfer. Copied from CTAR. 3. Transport, Reliability and Retransmission of FeatureContext Data CTP runs over UDP using portRequest Block A request block for context data, see Section 2.4. The sequence number <TBD>. Some feature contexts may specify a reliability factor, MAX_RETRY_INTERVAL, whichis the length of time that theused by pAR is allowedto perform retransmissions before giving up on the context transfercorrelate a request for that featurepreviously transmitted context. The longer the allowed retry interval,In predictive transfer, if the more retransmissions will be possible for that feature context. For feature contexts that specify MAX_RETRY_INTERVAL,MN sends CTAR prior to handover, pAR SHOULD retransmit an unacknowledgedpushes context to nAR using CTD. If the CTD message after waiting for RETRANSMISSION_DELAY milliseconds. This time value is configurable based onfails, the type of network interface; slower network media naturallynAR will be configuredsend CT-Req with longer values forthe RETRANSMISSION_DELAY. Except for the value ofsame sequence number, allowing the elapsed time field,pAR to distinguish which context to resend. pAR drops the payload of each retransmitted CTD packetcontext after CTP_MAX_TRANSFER_TIME. The sequence number is identical tonot used in reactive transfer. For predictive transfer the payload ofpAR sends the initially transmitted CTD packet, in orderkeying material and other information necessary to maintaincalculate the ability ofAuthorization Token, with no CT-Req message necessary. For reactive transfer, if the mobile device to presentnAR receives a correctly calculated authentication token. The number of retransmissions, each delayed by RETRANSMISSION_DELAY, depends oncontext transfer trigger but has not yet received the maximum value for MAX_RETRY_INTERVAL as specified by any ofCTAR message with the contexts. The value ofauthorization token, the Elapsed TimeAuthorization Token field in CT-Req is set to zero. The pAR interprets this as an indication to include the number of milliseconds sincekeying material and other information necessary to calculate the transmission ofAuthorization Token, and includes this material into the firstCTD message UDP provides an optional checksum, which SHOULD be checked. Ifas if the checksum is incorrect,message were being sent due to predictive transfer. This provides nAR SHOULD returnwith the information it needs to calculate the authorization token when the MN sends CTAR. 3. Transport 3.1 Inter-Router Transport Since the types of access networks in which CTP might be useful are not today deployed or, if they have been deployed, have not been extensively measured, it is difficult to know whether congestion will be a CTDR packetproblem for CTP. Part of the research task in preparing CTP for consideration as a candidate for possible standardization is to pARquantify this issue. However, in order to avoid potential interference with production applications should a prototype CTP deployment involve running over the status value BAD_UDP_CHECKSUM, evenpublic Internet, it seems prudent to recommend a default transport protocol that accommodates congestion. In addition, since the feature context information has a definite lifetime, the transport protocol must accommodate flexible retransmission, so stale contexts that are held up by congestion are dropped. Finally, because the amount of context data can be arbitrarily large, the transport protocol should not be limited to a single packet, or require implementing a custom fragmentation protocol. These considerations argue that implementations of CTP MUST support and prototype deployments of CTP SHOULD use Stream Control Transport Protocol (SCTP) [SCTP] for the transport protocol on the inter-router interface, especially if deployment over the 'A' bitpublic Internet is contemplated. SCTP supports congestion control, fragmentation, and partial retransmission based on a programmable retransmission timer. SCTP also supports many advanced and complex features, such as multiple streams and multiple IP addresses for failover, that are not setnecessary for experimental implementation and prototype deployment of CTP. In this specification, the use of such SCTP features is not recommended at this time. The SCTP Payload Data Chunk carries the context transfer protocol messages. The User Data part of each SCTP message contains an appropriate context transfer protocol message defined in this document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR (Section 2.5.4), CTC (Section 2.5.5) and CT-Req (Section 2.5.6). In general, each SCTP message can carry feature contexts belonging to any MN. If the CTD. 4. Error Codes This section listsSCTP checksum calculation fails, the nAR returns the BAD_CHECKSUM error codes used by UDP BAD_UDP_CHECKSUM 0x01 5. Examples and Signaling Flows 5.1 Network controlled, Initiatedcode in a CTDR message. A single stream is used for context transfer without in-sequence delivery of SCTP messages. Each message, unless fragmented, corresponds to a single MN's feature context collection. A single stream provides simplicity. Use of multiple streams to prevent head- of-line blocking is for future study. Having unordered delivery allows the receiver to not block for in-sequence delivery of messages that belong to different MNs. The Payload Protocol Identifier in the SCTP header is 'CTP'. Inter-router CTP uses the Seamoby SCTP port [IANA]. Timeliness of the context transfer information SHOULD be accommodated by pAR MNsetting the SCTP maximum retransmission value to CT_MAX_TRANSFER_TIME in order to accommodate the maximum acceptable handover delay time, and the AR SHOULD be configured with CT_MAX_TRANSFER_TIME to accommodate the particular wireless link technology and local wireless propagation conditions. SCTP message bundling SHOULD be turned off in order to reduce any extra delay in sending messages. Within CTP, the nAR pARSHOULD estimate the retransmit timer from the receipt of the first fragment of a CTP message and avoid processing any IP traffic from the MN until either context transfer is complete or the estimated retransmit timer expires. If both routers support PR-SCTP [PR-SCTP], then PR-SCTP SHOULD be used. PR-SCTP modifies the lifetime parameter of the Send() operation defined in Section 10.1 E in [SCTP] so that it applies to retransmits as well as transmits; that is, in PR-SCTP if the lifetime expires and the data chunk has not been acknowledged, the transmitter stops retransmitting, whereas in the base protocol the data would be retransmitted until acknowledged or the connection timed out. The format of Payload Data Chunk taken from [SCTP] is shown in the following diagram. 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 = 0 | Reserved|U|B|E| Length | T+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | CT trigger I+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | M+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |<------- CTD ----------| EPayload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ User Data (seq n of Stream S) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'U' bit The Unordered bit. MUST be set to 1 (one). 'B' bit The Beginning fragment bit. See [SCTP]. 'E' bit The Ending fragment bit. See [SCTP]. TSN Transmission Sequence Number. See [SCTP]. Stream Identifier S Identifies the context transfer protocol stream. Stream Sequence Number n Since the 'U' bit is set to one, the receiver ignores this number. See [SCTP]. Payload Protocol Identifier Set to 'CTP' (see [IANA]). User Data Contains the context transfer protocol messages. If a CTP 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. An example is piggybacking CTP messages on top of handover signaling for routing, such as provided by FMIPv6 in ICMP [FMIPv6]. Implementations of CTP MAY support ICMP for such purposes. If such piggybacking is used, an experimental message extension for the protocol on which CTP is piggybacking MUST be designed. Direct deployment on top of a transport protocol for experimental purposes is also possible, in that 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 for transport of the CTAR and CTAA messages. Because ICMP contains no provisions for retransmitting packets if signaling is lost, the CTP 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, since ICMP has no provision for fragmentation above the IP level. The ICMP message format for CTP 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Seamoby Type (To be assigned by IANA, for IPv4 and IPv6, see [IANA]) Code 1 Checksum The ICMP checksum. 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 which fail to elicit a response are retransmitted. The initial retransmission occurs after a CTP_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 CTP_RETRY_MAX seconds after the initial transmission. MNs SHOULD generate the sequence number in the CTAR message randomly, and, for predictive transfer, MUST use the same sequence number in a CTAR to the nAR as for the pAR. An AR MUST ignore the CTAR 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 | | | | | | in 0 5.2 Network controlled, initiated by nAR in 6nAR, Reactive MN nAR pAR | | | T | CT trigger | I | | | M | |----- CT Request|--------- 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 Request|-------- CT-Req ------>| M | | | E | |<-------- CTD ---------| : | | | | | | | V | | | | | | In caseIt is for future study whether the nAR sends the MN a CTAR reject if CT cannotis not supported. 6. Security Considerations At this time, the threats to IP handover in general and context transfer in particular are incompletely understood, particularly on the MN to AR link, and mechanisms for countering them are not well defined. Part of the experimental task in preparing CTP 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 DoS attacks to shift state between ARs, causing network disruptions. Additionally, DoS attacks can be supported,launched from MNs towards the access routers by requesting multiple context transfers and then disappearing. Finally, a CTAR reject (TBD) mayrogue access router could flood mobile nodes with packets, attempting DoS attacks, and issue bogus context transfer requests to surrounding routers. 6.2. Access Router Considerations The CTP interrouter interface relies on IETF standardized security mechanisms for protecting traffic between access routers, as opposed to creating application security mechanisms. IPsec MUST be sentsupported between access routers. In order to avoid the MN by nAR. 6.introduction of additional latency due to the need for establishment of 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 mechanisms such as IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and IPSec protocols (such as ESP) in anticipation for 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 Considerations At this time,should be negotiated prior to the threatssending 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 handoverlayer protection is needed, ESP in generaltunnel 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 particular are incompletely understood, particularly onpredicative transfer. 6.3 Mobile Node Considerations The CTAR message requires the MN to AR link,and mechanisms for countering them are not well defined. Part of the experimental task in preparing CTP for eventual standards track will beAR to better characterize threatspossess a shared secret key in order to calculate the authorization token. Validation of this token MUST precede context transfer and design specific mechanisms to counter them. This section provides some general guidelines about security based on discussions amongor installation of context for the Design Team and Working Group members. 6.1. Threats. The Context Transfer Protocol transfers state between access routers.MN, removing the risk that an attacker could cause an unauthorized transfer. How the shared key is established is out of scope of the current specification. If both the mobile nodes are not authenticatedMN and authorized before moving onAR know certified public keys of the network, there isother party, Diffie-Helman can be used to generate a potentialshared secret [RFC2631]. If an AAA protocol of some sort is run for DoS attacks to shift state between ARs, causingnetwork disruptions. Additionally, DoS attacksentry, the shared key can be launched from mobile nodes towards the access routers by requesting multipleestablished using that protocol [PerkCal04]. If predictive context transfers and then disappearing. Additionally, a rogue access router could flood mobile nodes with packets, attempting DoS attacks. 6.2. Security Details CTP relies on IETF standardized security mechanismstransfer is used, the shared key for protecting traffic between access routers, as opposed to creating application security mechanisms. IPsec MUST be supported between access routers. In order to avoidcalculating the introduction of additional latency to contextauthorization token is transferred between ARs. A transfer due to the need for establishmentof secure channel betweenconfidential material of this sort poses certain security risks, even if the contextactual transfer peers (ARs), the two ARs SHOULD establish such secure channel in advance. If IPSecitself is used,confidential and authenticated, as is the case for example,inter-router CTP. The more entities know the two access routers need to engage inkey, the more likely a compromise may occur. In order to mitigate this risk, nAR MUST discard the key exchange mechanisms such as IKE [RFC2409],immediately after using it to validate the authorization token. The MN MUST establish IPSec SAs, defininga new key with the keys, algorithmsAR for future CTP transactions. The MN and IPSec protocols (such as ESP)AR SHOULD exercise care in anticipationusing a key established for any upcomingother purposes for also authorizing context transfer. This will save time during handoversIt is RECOMMENDED that require secure transfer of mobile node's context(s). Such SAs cana separate key be maintained and usedestablished for all upcomingcontext transfers betweentransfer authorization. Replay protection on the two ARs. Security should be negotiated prior toMN-AR protocol is provided by limiting the sending of context. Furthermore, either one or both oftime period in which context is maintained. For predictive transfer, the pAR and nAR need to be able to authenticatereceives a CTAR message with a sequence number, transfers the mobile and authorize mobile's credential before authorizingcontext, then drops the context transfer and releaseimmediately upon completion of context to the mobile. In casethe context transfer is request bytransfer, along with the MN, a mechanism MUST be provided so that requests are authenticated (regardless ofauthorization token key. For reactive transfer, the security of context transfer itself) to preventnAR receives the possibility of rogue MNs launching DoS attacks by sending large number of CTCTAR, requests as well as cause large number of context transfers between ARs. Another important consideration is thatthe mobile node should claim it's own context,context along with the sequence number and not some other masquerader. One methodauthorization token, allowing the pAR to achieve thischeck whether the transfer is to provide an authentication cookie to be included withauthorized. The pAR drops the context transfer message sent fromand authorization token key after the transfer has been completed. The pAR to the nARand confirmed bynAR ignore any requests containing the mobile nodesame MN IP address during the transfer process. After the key has been dropped, any attempt at replay will fail because the nAR. 6.3. IPsec Considerations Access Routers MUST implement IPsec ESP [ESP] in transport mode with non-null encryption and authentication algorithmsauthorization token fails to provide per- packet authentication, integrity protection and confidentiality, andvalidate. The AR MUST implementNOT reuse the replay protection mechanismskey for other MNs. DoS attacks on the MN-AR interface can be limited by having the AR rate limit the number of IPsec. In those scenarios where IP layer protection is needed, ESP in tunnel modeCTAR messages it processes. The AR SHOULD be used. Non-null encryption should be used when using IPSec ESP. 7. IANA Considerations This section provides guidance tolimit the Internet Assigned Numbers Authority (IANA) regarding registrationnumber of values relatedCTAR messages to CT_REQUEST_RATE. If the context transfer protocol, in accordance with BCP 26 [RFC2434]. 7.1 Context Profile Types Registry This document authorized IANA to create a registry for Context Profile Types, introduced inrequest exceeds this document. For future Context Profile Types, itrate, the AR SHOULD randomly drop messages until the rate is recommended that allocationsestablished. The actual rate SHOULD be doneconfigured on the basis of Designated Expert. The Context Profile Type introduced in this document requires IANA Type Numbers for each setAR to match the maximum number of feature contextshandovers that make use of Profile Types. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appointthe Designated Expert. 7.2 UDP Port CTP requires a UDP port assignment.access network is expected to support. 7. IANA Considerations Instructions for IANA allocations are included in [IANA]. 8. Acknowledgements & Contributors This document is the result of a design team formed by the Working Group chairs of the SeaMoby working group. The team included John Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. Contributors to the Context Transfer Protocol review are Basavaraj Patil, Pekka Savola, and Antti Tuominen. The working group chairs are Pat Calhoun and James Kempf, whose comments have been very helpful during 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. 9. References 9.1 Normative References [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- mentRequirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- loadPayload (ESP)", RFC 2406, November 1998. [SCTP] Stewert, R., et. al., "Stream Control Transmission Protocol", RFC 2960, October, 2000. [PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension", Internet Engineering Task Force. Work in Progress. [CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate Access Router Discovery", Internet Engineering Task Force. Work in Progress. [IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol IANA Allocations", Internet Engineering Task Force. Work in Progress. 9.2 Non-Normative References [CTHC] R. Koodli et al., "Context Relocation for Seamless Header Compression in IP Networks", Internet Draft, Internet Engineering Task Force, Work in Progress. [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet Engineering Task Force. Work in Progress. [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", Internet Engineering Task Force. Work in Progress. [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, Internet Engineering Task Force, RFC 3374,May 2001. [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet Engineering Task Force, Work in Progress. [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631, June, 1999. [PerkCal04]C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile IPv4", Internet Engineering Task Force, Work in Progress. [MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force, Work in Progress. [RFC2710] S. Deering, S.,W. Fenner, W.,and B. Haberman, B.," Multicast Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. [RFC2461] T. Narten, T.,E. Nordmark, E.,and Simpson. W.,W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December, 1998. [RFC2462] S. Thompson, S.,and T. Narten, T.,"IPv6 Address Autoconfiguration," RFC 2462, December, 1998. [RFC3095] C. Borman, ed., "RObust Header Compression (ROHC)", RFC 3095, July, 2001. [BT] IEEE, "IEEE Standard for information technology - Telecommuni- cation and information exchange between systems - LAN/MAN - Part 15.1: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.1, 2002. Appendix A. Timing and Trigger Considerations Basic Mobile IP handover signaling can introduce disruptions to the services running on top of Mobile IP, which may introduce unwanted latencies that practically prohibit its use for certain types of ser- vices.services. Mobile IP latency and packet loss is being optimized through several alternative procedures, such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP]. Feature re-establishment through context transfer should contribute zero (optimally) or minimal extra disruption of services in conjunc- tionconjunction to handovers. This means that the timing of context transfer SHOULD be carefully aligned with basic Mobile IP handover events, and with optimized Mobile IP handover signaling mechanisms, as those pro- tocolsprotocols become available. Furthermore, some of those optimized mobile IP handover mechanisms may provide more flexibility isin choosing the timing and order for transfer of various context information. Appendix B. Multicast Listener Context Transfer In the past, credible proposals have been made in the Seamoby Working Group and elsewhere for using context transfer to speed handover of authentication, authorization, and accounting context, distributed firewall context, PPP context, and header compression context. Because the Working Group was not chartered to develop context profile definitions for specific applications, none of the drafts submitted to Seamoby were accepted as Working Group items. At this time, work continues to develop a context profile definition for RFC 3095 header compression context [RFC3095] and to characterize the performance gains obtainable by using header compression, but the work is not yet complete. In addition, there are several commercial wireless products that reportedly use non-standard, non-interoperable context transfer protocols, though none is as yet widely deployed. As ana consequence, it is difficult at this time to point to a solid example of how context transfer can improve the performance of IP layer handover,could result in a commercially viable, widely deployable, interoperable benefit for wireless networks. This is one reason why CTP is being proposed as an Experimental protocol, rather than Standards Track. However, it nevertheless seems valuable to have a simple example that shows how handover could benefit from using CTP. The example we consider here is transferring IPv6 MLD state [RFC2710]. MLD state is a particularly good example because every IPv6 node must perform twoat least one MLD messaging sequencessequence on the wireless link to establish itself as an MLD listener prior to performing router discovery [RFC2461] or duplicate address detection [RFC2462] or before sending/receiving any application-specific traffic (including Mobile IP handover signaling, if any). The node must subscribe to the Soli- citedSolicited Node Multicast Address as soon as it comes up on the link. Any application-specific multicast addresses must be re-established as well. Context transfer can significantly speed up re-establishing multicast state by allowing the nAR to initialize MLD for a node that just completed handover;handover without any MLD signaling on the new wire- lesswireless link. The same approach could be used for transferring multicast context in IPv4. An approximate qualitativequantitative estimate for the amount of savings in handover time can be obtained as follows. MLD messages are 24 bytes, to which the headers must be added, because there is no header compression on the new link, with IPv6 header being 40 bytes, and a required Router Alert Hop-by-Hop option being 8 bytes including pad- ding. The total MLD message size is 72 bytes per subscribed multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report mes- sagesmessages per address subscription, since the Report message is unack- nowledged.unacknowledged. Assuming 2 MLD messages sent for a subscribed address, the mobile nodeMN would need to send 144 bytes per address subscription. If MLD messages are sent for both the All Nodes Multicast Addressaddress and the Solicited Node Multicast address for the node's link local address, a total of 288 bytes are required when the node hands over to the new link. Note that some implementations of IPv6 optimize by not sending an MLD message for the All Nodes Multicast Address, since the router can infer that at least one node is on the link (itself) when it comes up and always will be, but for purposes of this calcu- lation,calculation, we assume that the IPv6 implementation is conformant and that the message is sent. The amount of time required for MLD signaling will, of course, depend on the per node available wireless link bandwidth, but some representative numbers can be obtained by assuming bandwidths of 20 kbps or 100 kbps. The former is approximate for a narrowband 3G cel- lular links and the latter for a heavily utilized 802.11b WLAN link, both running Voice over IP (VoIP).With these two bit rates, the sav- ingssavings from not having to perform the pre-router discovery messages are 115 msec. and 23 msec., respectively. If any application-specific multicast addresses are subscribed, the amount of time saved could be substantially more. Considering most ATM-basedThis example might seem a bit contrived because MLD isn't used in the 3G voicecellular pro- tocols try to keep total voice handover delay less than 40- 80 msec., MLD signaling couldprotocols and wireless local area network protocols typically have enough bandwidth, if radio propagation conditions are optimal, so sending a large impactsingle MLD message might not be viewed as such a performance burden. An example of a wireless protocol where MLD context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT]. IEEE 802.15.1 has two IP "profiles": one with and one without PPP. The profile without PPP would use MLD. The 802.15.1 protocol has a maximum bandwidth of about 800 kbps, shared between all nodes on the performancelink, so a host on a moderately loaded 802.15.1 access point could experience the kind of inter- subnet VoIP handover.bandwidth described in the previous paragraph. In addition 802.15.1 handover times typically run upwards of a second or more because the host must resynchronize its frequency hopping pattern with the access point, so anything the IP layer could do to alleviate further delay would be beneficial. The context-specific data field for MLD context transfer included in the CTP Context Data Block message for a single IPv6 multicast address has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix on nAR Wireless Interface + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Subscribed IPv6 Multicast Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Subnet Prefix on nAR Wireless Interface field contains a subnet prefix that identifies the interface on which multicast routing should be established. The Subscribed IPv6 Multicast Address field contains the multicast address for which multicast routing should be established. The pAR sends one MLD context block per subscribed IPv6 multicast address. No changes are required in the MLD state machine. Upon receipt of a CTP Context Data Block for MLD, the state machine takes the following actions: - If the router is in the No Listeners present state on the wireless interface on which the Subnet Prefix field fromin the Context Data Block is advertised, it transitions into the Listeners Present state for the Subscribed IPv6 Multicast Address field in the Con- textContext Data Block. This transition is exactly the same as if the router had received a Report message. - If the router is in the Listeners present state on that interface, it remains in that state but restarts the timer, as if it had received a Report message. If more than one MLD router is on the link, a router receiving an MLD Context Data Block SHOULD send the block to the other routers on the link. TheIf wireless bandwidth is not an issue, the router MAY instead send a proxy MLD Report message on the wireless interface that advertises the Subnet Prefix field from the Context Data Block if wireless bandwidth is not an issue.Block. Since MLD routers do not keep track of which nodes are listening to munticast addresses, only whether a particular multicast address is being listened to, proxying the subscription should cause no difficulty. Authors' Addresses Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Rajeev.email@example.com John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland firstname.lastname@example.org Madjid F. Nakhjiri Motorola Labs 1031 East Algonquin Rd., Room 2240 Schaumburg, IL, 60196 USA email@example.com Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA firstname.lastname@example.org Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 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 INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property ConsiderationsThe IETF takes no position regarding the validity or scope of any intellectual propertyIntellectual Property Rights or other rights that might be claimed to per- tainpertain 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; neithernor does it represent that it has made any independent effort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards- related documentationRFC documents can be found in BCP-11.BCP 78 and BCP 79. Copies of claims of rightsIPR disclosures made available for publicationto 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 specificationspecifica- tion can be obtained from the IETF Secretariat.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 whichthat may cover technology that may be required to practiceimplement this standard. Please address the information to the IETF Executive Director.at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.