idnits 2.17.1 draft-ietf-seamoby-ctp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1464. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1431), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 32 longer pages, the longest (page 33) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2004) is 7193 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FMIPV6' is mentioned on line 190, but not defined == Missing Reference: 'RFC 791' is mentioned on line 690, but not defined == Missing Reference: 'RFC 2373' is mentioned on line 692, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) == Missing Reference: 'PerkCal04' is mentioned on line 1084, but not defined == Unused Reference: 'RFC2026' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: 'CARD' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: 'CTHC' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 1196, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 14 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Seamoby WG J. Loughney (editor) 2 Internet Draft M. Nakhjiri 3 Category: Experimental C. Perkins 4 R. Koodli 5 Expires: Feburary 2005 August 2004 7 Context Transfer Protocol 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) The Internet Society 2004. All Rights Reserved. 38 Abstract 40 This document presents a context transfer protocol that enables 41 authorized context transfers. Context transfers allow better support 42 for node based mobility so that the applications running on mobile 43 nodes can operate with minimal disruption. Key objectives are to 44 reduce latency, packet losses and avoiding re-initiation of signaling 45 to and from the mobile node. 47 Table of Contents 49 1. Introduction 50 1.1 The Problem 51 1.2 Conventions Used in This Document 52 1.3 Abbreviations Used in the Document 53 2. Protocol Overview 54 2.1 Context Transfer Scenarios 55 2.2 Context Transfer Message Format 56 2.3 Context Types 57 2.4 Context Data Block (CTB) 58 2.5 Messages 59 3. Transport 60 3.1 Inter-Router Transport 61 3.2 MN-AR Transport 62 4. Error Codes and Constants 63 5. Examples and Signaling Flows 64 5.1 Network controlled, Initiated by pAR, Predictive 65 5.2 Network controlled, Initiated by nAR, Reactive 66 5.3 Mobile controlled, Predictive New L2 up/old L2 down 67 6. Security Considerations 68 6.1 Threats 69 6.2 Access Router Considerations 70 6.3 Mobile Node Considerations 71 7. IANA Considerations 72 8. Acknowledgements & Contributors 73 9. References 74 9.1 Normative References 75 9.2 Non-Normative References 76 Appendix A. Timing and Trigger Considerations 77 Appendix B. Multicast Listener Context Transfer 78 Authors' Addresses 79 Full Copyright Statement 80 Intellectual Property 81 Acknowledgement 83 1. Introduction 85 This document describes the Context Transfer Protocol overview, which 86 provides: 88 * Representation for feature contexts. 89 * Messages to initiate and authorize context transfer, and notify 90 a mobile node of the status of the transfer. 91 * Messages for transferring contexts prior to, during and after 92 handovers. 94 The proposed protocol is designed to work in conjunction with other 95 protocols in order to provide seamless mobility. The protocol 96 supports both IPv4 and IPv6, though support for IPv4 private 97 addresses is for future study. 99 1.1 The Problem 101 "Problem Description: Reasons For Performing Context Transfers 102 between Nodes in an IP Access Network" [RFC3374] defines the 103 following main reasons why Context Transfer procedures may be useful 104 in IP networks. 106 1) The primary motivation, as mentioned in the introduction, is the 107 need to quickly re-establish context transfer-candidate services 108 without requiring the mobile host to explicitly perform all 109 protocol flows for those services from scratch. An example of a 110 service is included in Appendix B. 112 2) An additional motivation is to provide an interoperable solution 113 that supports various Layer 2 radio access technologies. 115 1.2 Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 1.3 Abbreviations Used in the Document 123 Mobility Related Terminology [TERM] defines basic mobility 124 terminology. In addition to the material in that document, we use 125 the following terms and abbreviation in this document. 127 CTP Context Transfer Protocol 129 DoS Denial-of-Service 130 FPT Feature Profile Types 132 PCTD Predictive Context Transfer Data 134 2. Protocol Overview 136 This section provides a protocol overview. A context transfer can be 137 either started by a request from the mobile node ("mobile 138 controlled") or at the initiative of either the new or the previous 139 access router ("network controlled"). 141 * The mobile node (MN) sends the CT Activate Request (CTAR) to its 142 current access router (AR) immediately prior to handover whenever 143 possible to initiate predictive context transfer. In any case, the 144 MN always sends the CTAR message to the new AR (nAR). If the 145 contexts are already present, nAR verifies the authorization token 146 present in CTAR with its own computation using the parameters 147 supplied by the previous access router (pAR), and subsequently 148 activates those contexts. If the contexts are not present, nAR 149 requests pAR to supply them using the Context Transfer Request 150 message, in which it supplies the authorization token present in 151 CTAR. 153 * Either nAR or pAR may request or start (respectively) context 154 transfer based on internal or network triggers (see Appendix A). 156 The Context Transfer protocol typically operates between a source 157 node and a target node. In the future, there may be multiple target 158 nodes involved; the protocol described here would work with multiple 159 target nodes. For simplicity, we describe the protocol assuming a 160 single receiver or target node. 162 Typically, the source node is a MN's pAR and the target node is MN's 163 nAR. Context Transfer takes place when an event, such as a handover, 164 takes place. We call such an event a Context Transfer Trigger. In 165 response to such a trigger, the pAR may transfer the contexts; the 166 nAR may request contexts; and the MN may send a message to the 167 routers to transfer contexts. Such a trigger must be capable of 168 providing the necessary information (such as the MN's IP address) by 169 which the contexts are identified, the IP addresses of the access 170 routers, and authorization to transfer context. 172 Context transfer protocol messages use Feature Profile Types (FPTs) 173 that identify the way that data is organized for the particular 174 feature contexts. The FPTs are registered in a number space (with 175 IANA Type Numbers) that allows a node to unambiguously determine the 176 type of context and the context parameters present in the protocol 177 messages. Contexts are transferred by laying out the appropriate 178 feature data within Context Data Blocks according to the format in 179 Section 2.3, as well as any IP addresses necessary to associate the 180 contexts to a particular MN. The context transfer initiation messages 181 contain parameters that identify the source and target nodes, the 182 desired list of feature contexts and IP addresses to identify the 183 contexts. The messages that request transfer of context data also 184 contain an appropriate token to authorize the context transfer. 186 Performing context transfer in advance of the MN attaching to nAR can 187 increase handover performance. For this to take place, certain 188 conditions must be met. For example, pAR must have sufficient time 189 and knowledge about the impending handover. This is feasible, for 190 instance, in Mobile IP fast handovers [LLMIP][FMIPV6]. Additionally, 191 many cellular networks have mechanisms to detect handovers in 192 advance. However, when the advance knowledge of impending handover is 193 not available, or if a mechanism such as fast handover fails, 194 retrieving feature contexts after the MN attaches to nAR is the only 195 available means for context transfer. Performing context transfer 196 after handover might still be better than having to re-establish all 197 the contexts from scratch. Finally, some contexts may simply need to 198 be transferred during handover signaling. For instance, any context 199 that gets updated on a per-packet basis must clearly be transferred 200 only after packet forwarding to the MN on its previous link is 201 terminated. 203 2.1 Context Transfer Scenarios 205 The Previous Access Router transfers feature contexts under two 206 general scenarios. 208 2.1.1 Scenario 1 210 The pAR receives a Context Transfer Activate Request (CTAR) message 211 from the MN whose feature contexts are to be transferred, or it 212 receives an internally generated trigger (e.g., a link-layer trigger 213 on the interface to which the MN is connected). The CTAR message, 214 described in Section 2.5, provides the IP address of nAR, the IP 215 address of MN on pAR, the list of feature contexts to be transferred 216 (by default requesting all contexts to be transferred), and a token 217 authorizing the transfer. In response to a CT-Activate Request 218 message or to the CT trigger, pAR predictively transmits a Context 219 Transfer Data (CTD) message that contains feature contexts. This 220 message, described in Section 2.5, contains the MN's previous IP 221 address. It also contains parameters for nAR to compute an 222 authorization token to verify the MN's token present in CTAR message. 223 Recall that the MN always sends CTAR message to nAR regardless of 224 whether it sent the CTAR message to pAR. The reason for this is that 225 there is no means for the MN to ascertain that context transfer 226 reliably took place. By always sending the CTAR message to nAR, the 227 Context Transfer Request (see below) can be sent to pAR if necessary. 229 When context transfer takes place without the nAR requesting it, nAR 230 requires MN to present its authorization token. Doing this locally at 231 nAR when the MN attaches to it improves performance and increases 232 security, since the contexts are highly likely to be present already. 233 Token verification takes place at the router possessing the contexts. 235 2.1.2 Scenario 2 237 In the second scenario, pAR receives a Context Transfer Request (CT- 238 Req), described in Section 2.5, message from nAR. The nAR itself 239 generates the CT-Req message as a result of receiving the CTAR 240 message, or, alternatively, from receiving a context transfer 241 trigger. In the CT-Req message, nAR supplies the MN's previous IP 242 address, the FPTs for the feature contexts to be transferred, the 243 sequence number from the CTAR, and the authorization token from the 244 CTAR. In response to CT-Req message, pAR transmits a Context Transfer 245 Data (CTD) message that includes the MN's previous IP address and 246 feature contexts. When it receives a corresponding CTD message, nAR 247 may generate a CTD Reply (CTDR) message to report the status of 248 processing the received contexts. The nAR installs the contexts once 249 it has received them from the pAR. 251 2.2 Context Transfer Message Format 253 A CTP message consists of a message-specific header and one or more 254 data blocks. Data blocks may be bundled together in order to ensure 255 a more efficient transfer. On the inter-AR interface, SCTP is used 256 so fragmentation should not be a problem. On the MN-AR interface, the 257 total packet size, including transport protocol and IP protocol 258 headers SHOULD be less than the path MTU, in order to avoid packet 259 fragmentation. Each message contains a three bit version number field 260 in the low order octet, along with the 5 bit message type code. This 261 specification only applies to Version 1 of the protocol, and the 262 therefore version number field MUST be set to 0x1. If future 263 revisions of the protocol make binary incompatible changes, the 264 version number number MUST be incremented. 266 2.3 Context Types 268 Contexts are identified by FPT code, which is a 16-bit unsigned 269 integer. The meaning of each context type is determined by a 270 specification document and the context type numbers are to be 271 tabulated in a registry maintained by IANA [IANA], and handled 272 according to the message specifications in this document. The 273 instantiation of each context by nAR is determined by the messages in 274 this document along with the specification associated with the 275 particular context type. The following diagram illustrates the 276 general format for CTP messages: 278 +----------------------+ 279 | Message Header | 280 +----------------------+ 281 | CTP Data 1 | 282 +----------------------+ 283 | CTP Data 2 | 284 +----------------------+ 285 | ... | 287 Each context type specification contains the following details: 288 - Number, size (in bits), and ordering of data fields in the 289 state variable vector which embodies the context. 290 - Default values (if any) for each individual datum of the 291 context state vector. 292 - Procedures and requirements for creating a context at a new 293 access router, given the data transferred from a previous 294 access router, and formatted according to the ordering rules 295 and date field sizes presented in the specification. 296 - If possible, status codes for success or failure related to the 297 context transfer. For instance, a QoS context transfer might 298 have different status codes depending on which elements of the 299 context data failed to be instantiated at nAR. 301 2.4 Context Data Block (CTB) 303 The Context Data Block (CTB) is used both for request and response 304 operation. When a request is constructed, only the first 4 octets are 305 typically necessary (See CTAR below). When used for transferring the 306 actual feature context itself, the context data is present, and 307 sometimes the presence vector is present. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Feature Profile Type (FTP) | Length |P| Reserved | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Presence Vector (if P = 1) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ Data ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Feature Profile Type 320 16 bit integer, assigned by IANA, 321 indicating the type of data 322 included in the Data field 324 Length Message length in units of 8 octet words. 326 'P' bit 0 = No presence vector 327 1 = Presence vector present. 329 Reserved Reserved for future use. Set to 330 zero by the sender. 332 Data Context type-dependent data, whose 333 length is defined by the Length 334 Field. If the data is not 64-bit 335 aligned, the data field is 336 padded with zeros. 338 The Feature Profile Type (FPT) code indicates the type of data in the 339 data field. Typically, this will be context data but it might be an 340 error indication. The 'P' bit specifies whether or not the "presence 341 vector" is used. When the presence vector is in use, the Presence 342 Vector is interpreted to indicate whether particular data fields are 343 present (and containing non-default values). The ordering of the 344 bits in the presence vector is the same as the ordering of the data 345 fields according to the context type specification, one bit per data 346 field regardless of the size of the data field. The Length field 347 indicates the size of the CTB in 8 octet words including the first 4 348 octets starting from FPT. 350 Notice that the length of the context data block is defined by the 351 sum of lengths of each data field specified by the context type 352 specification, plus 4 octets if the 'P' bit is set, minus the 353 accumulated size of all the context data that is implicitly given as 354 a default value. 356 2.5 Messages 358 In this section, the CTP messages are defined. The MN for which 359 context transfer protocol operations are undertaken is always 360 identified by its previous IP access address. At any time, only one 361 context transfer operation per MN may be in progress so that the CTDR 362 message unambiguously identifies which CTD message is acknowledged 363 simply by including the MN's identifying previous IP address. The 'V' 364 flag indicates whether the IP addresses are IPv4 or IPv6. 366 2.5.1 Context Transfer Activate Request (CTAR) Message 368 This message is always sent by MN to nAR to request context transfer. 369 Even when the MN does not know if contexts need to be transferred, 370 the MN sends the CTAR message. If an acknowledgement for this message 371 is needed, the MN sets the 'A' flag to 1; otherwise the MN does not 372 expect an acknowledgement. This message may include a list of FPTs 373 that require transfer. 375 The MN may also send this message to pAR while still connected to 376 pAR. In such a case, the MN includes the nAR's IP address; otherwise, 377 if the message is sent to nAR, the pAR address is sent. The MN MUST 378 set the sequence number to the same value for the message sent on 379 both pAR and nAR so pAR can determine whether to use a cached 380 message. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |Vers.| Type |V|A| Reserved | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 ~ MN's Previous IP Address ~ 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 ~ Previous (New) AR IP Address ~ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Sequence Number | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | MN Authorization Token | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Requested Context Data Block (if present) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Next Requested Context Data Block (if present) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | ........ | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Vers. Version number of CTP protocol = 0x1 404 Type CTAR = 0x1 406 'V' flag When set to '0', IPv6 addresses. 407 When set to '1', IPv4 addresses. 409 'A' bit If set, the MN requests an acknowledgement. 411 Reserved Set to zero by the sender, ignored by the 412 receiver. 414 Length Message length in units of octets. 416 MN's Previous IP Address Field contains either: 418 IPv4 Address as defined in [RFC 791], 419 4 octets. 420 IPv6 Address as defined in [RFC 2373], 421 16 octets. 423 nAR / pAR IP Address Field contains either: 424 IPv4 Address as defined in [RFC 791], 425 4 octets. 426 IPv6 Address as defined in [RFC 2373], 427 16 octets. 429 Sequence Number A value used to identify requests and 430 acknowledgements (see Section 3.2). 432 Authorization Token 433 An unforgeable value calculated as 434 discussed below. This authorizes the 435 receiver of CTAR to perform context 436 transfer. 438 Context Block Variable length field defined in 439 Section 2.4. 441 If no context types are specified, all contexts for the MN are 442 requested. 444 The Authorization Token is calculated as: 446 First (32, HMAC_SHA1 447 (Key, (Previous IP address | Sequence Number | CTBs))) 449 where Key is a shared secret between the MN and pAR, and CTBs is a 450 concatenation of all the Context Data Blocks specifying the contexts 451 to be transfered which are included in the CTAR message. 453 2.5.2 Context Transfer Activate Acknowledge (CTAA) Message 455 This is an informative message sent by the receiver of CTAR to the MN 456 to acknowledge a CTAR message. Acknowledgement is optional, depending 457 on whether the MN requested it. This message may include a list of 458 FPTs that were not transferred successfully. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 |Vers.| Type |V| Reserved | Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 ~ Mobile Node's Previous IP address ~ 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | FPT (if present) | Status code | Reserved | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | ........ | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Vers. Version number of CTP protocol = 0x1 474 Type CTAA = 0x2 476 'V' flag When set to '0', IPv6 addresses. 477 When set to '1', IPv4 addresses. 479 Reserved Set to zero by the sender and ignored by 480 the receiver. 482 Length Message length in units of octets. 484 MN's Previous IP Address Field contains either: 485 IPv4 Address as defined in [RFC 791], 486 4 octets. 487 IPv6 Address as defined in [RFC 2373], 488 16 octets. 490 FPT 16 bit unsigned integer, listing the FTP 491 that was not successfully transferred. 493 Status Code An octet, containing failure reason. 495 2.5.3 Context Transfer Data (CTD) Message 497 Sent by pAR to nAR, and includes feature data (CTP data). This 498 message handles predictive as well as normal CT. An acknowledgement 499 flag, 'A', included in this message indicates whether a reply is 500 required by pAR. 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 |Vers.| Type |V|A| Reserved | Length | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Elapsed Time (in milliseconds) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 ~ Mobile Node's Previous Care-of Address ~ 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 511 | Algorithm | Key Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD 513 | Key | only 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V 515 ~ First Context Data Block ~ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 ~ Next Context Data Block ~ 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 ~ ........ ~ 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Vers. Version number of CTP protocol = 0x1 524 Type CTD = 0x3 (Context Transfer Data) 525 PCTD = 0x4 (Predictive Context Transfer 526 Data) 528 'V' flag When set to '0', IPv6 addresses. 529 When set to '1', IPv4 addresses. 531 'A' bit When set, the pAR requests an 532 acknowledgement. 534 Length Message length in units of octets. 536 Elapsed Time The number of milliseconds since the 537 transmission of the first CTD message for 538 this MN. 540 MN's Previous IP Address Field contains either: 541 IPv4 Address as defined in [RFC 791], 542 4 octets. 543 IPv6 Address as defined in [RFC 2373], 544 16 octets. 546 Algorithm Algorithm for carrying out the computation 547 of the MN Authorization Token. Currently 548 only 1 algorithm is defined, HMAC_SHA1 = 1. 550 Key Length Length of key, in octets. 552 Key Shared key between MN and AR for CTP. 554 Context Data Block The Context Data Block (see Section 2.4). 556 When CTD is sent predictively, the supplied parameters including the 557 algorithm, key length and the key itself, allowing nAR to compute a 558 token locally and verify against the token present in the CTAR 559 message. This material is also sent if the pAR receives a CTD 560 message with a null Authorization Token, indicating that the CT-Req 561 message has been sent before the nAR received the CTAR message. CTD 562 MUST be protected by IPsec, see Section 6. 564 As described previously, the algorithm for carrying out the 565 computation of the MN Authorization Token is HMAC_SHA1. The token 566 authentication calculation algorithm is described in Section 2.5.1. 568 For predictive handover, the pAR SHOULD keep track of the CTAR 569 sequence number and cache the CTD message until receiving either a 570 CTDR message for the MN's previous IP address from the pAR, 571 indicating that the context transfer was successful, or until 572 CT_MAX_HANDOVER_TIME expires. The nAR MAY send a CT-Req message 573 containing the same sequence number if the predictive CTD message 574 failed to arrive or the context was corrupted, In that case, the nAR 575 sends a CT-Req message with a matching sequence number and pAR can 576 resend the context. 578 2.5.4 Context Transfer Data Reply (CTDR) Message 580 This message is sent by nAR to pAR depending on the value of the 'A' 581 flag in CTD. Indicates success or failure. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |Vers.| Type |V|S| Reserved | Length | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 ~ Mobile Node's Previous IP Address ~ 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | FPT (if present) | Status code | Reserved | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 ~ ....... ~ 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Vers. Version number of CTP protocol = 0x1 597 Type CTDR = 0x5 (Context Transfer Data) 598 'V' flag When set to '0', IPv6 addresses. 599 When set to '1', IPv4 addresses. 601 'S' bit When set to one, this bit indicates 602 that all feature contexts sent in CTD 603 or PCTD were received successfully. 605 Reserved Set to zero by the sender and ignored by 606 the receiver. 608 Length Message length in units of octets. 610 MN's Previous IP Address Field contains either: 611 IPv4 Address as defined in [RFC 791], 612 4 octets. 613 IPv6 Address as defined in [RFC 2373], 614 16 octets. 616 Status Code A context-specific return value, 617 zero for success, nonzero when 'S' is 618 not set to one. 620 FPT 16 bit unsigned integer, listing the FTP 621 that is being acknowledged. 623 2.5.5 Context Transfer Cancel (CTC) Message 625 If transferring a context cannot be completed in a timely fashion, 626 then nAR may send CTC to pAR to cancel an ongoing CT process. 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 |Vers.| Type |V| Reserved | Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 ~ Mobile Node's Previous IP Address ~ 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Vers. Version number of CTP protocol = 0x1 638 Type CTC = 0x6 (Context Transfer Cancel) 640 Length Message length in units of octets. 642 'V' flag When set to '0', IPv6 addresses. 643 When set to '1', IPv4 addresses. 645 Reserved Set to zero by the sender and ignored by 646 the receiver. 648 MN's Previous IP Address Field contains either: 649 IPv4 Address as defined in [RFC 791], 650 4 octets. 651 IPv6 Address as defined in [RFC 2373], 652 16 octets. 654 2.5.6 Context Transfer Request (CT-Req) Message 656 Sent by nAR to pAR to request start of context transfer. This message 657 is sent as a response to CTAR message from the MN. The fields 658 following the Previous IP address of the MN are included verbatim 659 from the CTAR message. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 |Vers.| Type |V| Reserved | Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 ~ Mobile Node's Previous IP Address ~ 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Sequence Number | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | MN Authorization Token | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 ~ Next Requested Context Data Block (if present) ~ 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 ~ ........ ~ 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Vers. Version number of CTP protocol = 0x1 679 Type CTREQ = 0x7 (Context Transfer Request) 681 'V' flag When set to '0', IPv6 addresses. 682 When set to '1', IPv4 addresses. 684 Reserved Set to zero by the sender and ignored 685 by the receiver. 687 Length Message length in units of octets. 689 MN's Previous IP Address Field contains either: 690 IPv4 Address as defined in [RFC 791], 691 4 octets. 692 IPv6 Address as defined in [RFC 2373], 693 16 octets. 695 Sequence Number Copied from the CTAR message, allows the 696 pAR to distinguish requests for previously 697 sent context. 699 MN's Authorization Token 700 An unforgeable value calculated as 701 discussed in Section 2.5.1. This 702 authorizes the receiver of CTAR to 703 perform context transfer. Copied from 704 CTAR. 706 Context Data Request Block 707 A request block for context data, see 708 Section 2.4. 710 The sequence number is used by pAR to correlate a request for 711 previously transmitted context. In predictive transfer, if the MN 712 sends CTAR prior to handover, pAR pushes context to nAR using CTD. If 713 the CTD fails, the nAR will send CT-Req with the same sequence 714 number, allowing the pAR to distinguish which context to resend. pAR 715 drops the context after CTP_MAX_TRANSFER_TIME. The sequence number is 716 not used in reactive transfer. 718 For predictive transfer the pAR sends the keying material and other 719 information necessary to calculate the Authorization Token, with no 720 CT-Req message necessary. For reactive transfer, if the nAR receives 721 a context transfer trigger but has not yet received the CTAR message 722 with the authorization token, the Authorization Token field in CT-Req 723 is set to zero. The pAR interprets this as an indication to include 724 the keying material and other information necessary to calculate the 725 Authorization Token, and includes this material into the CTD message 726 as if the message were being sent due to predictive transfer. This 727 provides nAR with the information it needs to calculate the 728 authorization token when the MN sends CTAR. 730 3. Transport 732 3.1 Inter-Router Transport 734 Since the types of access networks in which CTP might be useful are 735 not today deployed or, if they have been deployed, have not been 736 extensively measured, it is difficult to know whether congestion will 737 be a problem for CTP. Part of the research task in preparing CTP for 738 consideration as a candidate for possible standardization is to 739 quantify this issue. However, in order to avoid potential 740 interference with production applications should a prototype CTP 741 deployment involve running over the public Internet, it seems prudent 742 to recommend a default transport protocol that accommodates 743 congestion. In addition, since the feature context information has a 744 definite lifetime, the transport protocol must accommodate flexible 745 retransmission, so stale contexts that are held up by congestion are 746 dropped. Finally, because the amount of context data can be 747 arbitrarily large, the transport protocol should not be limited to a 748 single packet, or require implementing a custom fragmentation 749 protocol. 751 These considerations argue that implementations of CTP MUST support 752 and prototype deployments of CTP SHOULD use Stream Control Transport 753 Protocol (SCTP) [SCTP] for the transport protocol on the inter-router 754 interface, especially if deployment over the public Internet is 755 contemplated. SCTP supports congestion control, fragmentation, and 756 partial retransmission based on a programmable retransmission timer. 757 SCTP also supports many advanced and complex features, such as 758 multiple streams and multiple IP addresses for failover, that are not 759 necessary for experimental implementation and prototype deployment of 760 CTP. In this specification, the use of such SCTP features is not 761 recommended at this time. 763 The SCTP Payload Data Chunk carries the context transfer protocol 764 messages. The User Data part of each SCTP message contains an 765 appropriate context transfer protocol message defined in this 766 document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR 767 (Section 2.5.4), CTC (Section 2.5.5) and CT-Req (Section 2.5.6). In 768 general, each SCTP message can carry feature contexts belonging to 769 any MN. If the SCTP checksum calculation fails, the nAR returns the 770 BAD_CHECKSUM�error code in a CTDR message. 772 A single stream is used for context transfer without in-sequence 773 delivery of SCTP messages. Each message corresponds to a single MN's 774 feature context collection. A single stream provides simplicity. Use 775 of multiple streams to prevent head-of-line blocking is for future 776 study. Having unordered delivery allows the receiver to not block for 777 in-sequence delivery of messages that belong to different MNs. The 778 Payload Protocol Identifier in the SCTP header is 'CTP'. Inter-router 779 CTP uses the Seamoby SCTP port [IANA]. 781 Timeliness of the context transfer information SHOULD be accommodated 782 by setting the SCTP maximum retransmission value to 783 CT_MAX_TRANSFER_TIME in order to accommodate the maximum acceptable 784 handover delay time, and the AR SHOULD be configured with 785 CT_MAX_TRANSFER_TIME to accommodate the particular wireless link 786 technology and local wireless propagation conditions. SCTP message 787 bundling SHOULD be turned off in order to reduce any extra delay in 788 sending messages. Within CTP, the nAR SHOULD estimate the retransmit 789 timer from the receipt of the first fragment of a CTP message and 790 avoid processing any IP traffic from the MN until either context 791 transfer is complete or the estimated retransmit timer expires. If 792 both routers support PR-SCTP [PR-SCTP], then PR-SCTP SHOULD be used. 793 PR-SCTP modifies the lifetime parameter of the Send() operation 794 defined in Section 10.1 E in [SCTP] so that it applies to retransmits 795 as well as transmits; that is, in PR-SCTP if the lifetime expires and 796 the data chunk has not been acknowledged, the transmitter stops 797 retransmitting, whereas in the base protocol the data would be 798 retransmitted until acknowledged or the connection timed out. 800 The format of Payload Data Chunk taken from [SCTP] is shown in the 801 following diagram. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Type = 0 | Reserved|U|B|E| Length | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | TSN | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Stream Identifier S | Stream Sequence Number n | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Payload Protocol Identifier | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 ~ User Data (seq n of Stream S) ~ 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 'U' bit The Unordered bit. MUST be set to 1 (one). 818 'B' bit The Beginning fragment bit. See [SCTP]. 820 'E' bit The Ending fragment bit. See [SCTP]. 822 TSN Transmission Sequence Number. See [SCTP]. 824 Stream Identifier S 825 Identifies the context transfer protocol stream. 827 Stream Sequence Number n 828 Since the 'U' bit is set to one, the 829 receiver ignores this number. See [SCTP]. 831 Payload Protocol Identifier 832 Set to 'CTP' (see [IANA]). 834 User Data Contains the context transfer protocol messages. 836 If a CTP deployment will never run over the public Internet, and it 837 is known that congestion is not a problem in the access network, 838 alternative transport protocols MAY be appropriate vehicles for 839 experimentation. An example is piggybacking CTP messages on top of 840 handover signaling for routing, such as provided by FMIPv6 in ICMP 841 [FMIPv6]. Implementations of CTP MAY support ICMP for such purposes. 842 If such piggybacking is used, an experimental message extension for 843 the protocol on which CTP is piggybacking MUST be designed. Direct 844 deployment on top of a transport protocol for experimental purposes 845 is also possible, in that case, the researcher MUST be careful to 846 accommodate good Internet transport protocol engineering practices, 847 including using retransmits with exponential backoff. 849 3.2 MN-AR Transport 851 The MN-AR interface MUST implement and SHOULD use ICMP for transport 852 of the CTAR and CTAA messages. Because ICMP contains no provisions 853 for retransmitting packets if signaling is lost, the CTP protocol 854 incorporates provisions for improving transport performance on the 855 MN-AR interface. The MN and AR SHOULD limit the number of context 856 data block identifiers included in the CTAR and CTAA messages so that 857 the message will fit into a single packet, since ICMP has no 858 provision for fragmentation above the IP level. CTP uses the 859 Experimental Mobility ICMP type [IANA]. The ICMP message format for 860 CTP messages is as follows: 862 0 1 2 3 863 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 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Type | Code | Checksum | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Subtype | Reserved | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Message... 870 +-+-+-+-+-+-+-+-+-+-+-+- - - - 872 IP Fields: 874 Source Address An IP address assigned to the sending 875 interface. 877 Destination Address 878 An IP address assigned to the receiving 879 interface. 881 Hop Limit 255 883 ICMP Fields: 885 Type Experimental Mobility Type (To be assigned by IANA, 886 for IPv4 and IPv6, see [IANA]) 888 Code 0 890 Checksum The ICMP checksum. 892 Sub-type The Experimental Mobility ICMP subtype for CTP, see 893 [IANA]. 895 Reserved Set to zero by the sender and ignored by 896 the receiver. 898 Message The body of the CTAR or CTAA message. 900 CTAR messages for which a response is requested but which fail to 901 elicit a response are retransmitted. The initial retransmission 902 occurs after a CTP_REQUEST_RETRY wait period. Retransmissions MUST 903 be made with exponentially increasing wait intervals (doubling the 904 wait each time). CTAR messages should be retransmitted until 905 either a response (which might be an error) has been obtained, or 906 until CTP_RETRY_MAX seconds after the initial transmission. 908 MNs SHOULD generate the sequence number in the CTAR message 909 randomly, and, for predictive transfer, MUST use the same sequence 910 number in a CTAR to the nAR as for the pAR. An AR MUST ignore the 911 CTAR if it has already received one with the same sequence number 912 and MN IP address. 914 Implementations MAY, for research purposes, try other transport 915 protocols. Examples are the definition of a Mobile IPv6 Mobility 916 Header [MIPv6] for use with the FMIPv6 Fast Binding Update 917 [FMIPv6] to allow bundling of both routing change and context 918 transfer signaling from the MN to AR, or definition of a UDP 919 protocol instead of ICMP. If such implementations are done, they 920 should abide carefully by good Internet transport engineering 921 practices and be used for prototype and demonstration purposes 922 only. Deployment on large scale networks should be avoided until 923 the transport characteristics are well understood. 925 4. Error Codes and Constants 927 Error Code Section Value Meaning 928 ------------------------------------------------------------ 929 BAD_CHECKSUM 3.1 0x01 Error code if the 930 SCTP checksum fails. 932 Constant Section Default Value Meaning 933 -------------------------------------------------------------------- 935 CT_REQUEST_RATE 6.3 10 requests/ Maximum number of 936 sec. CTAR messages before 937 AR institutes rate 938 limiting. 940 CT_MAX_TRANSFER_TIME 3.1 200 ms Maximum amount of time 941 pAR should wait before 942 aborting the transfer. 944 CT_REQUEST_RETRY 3.2 2 seconds Wait interval before 945 initial retransmit 946 on MN-AR interface. 948 CT_RETRY_MAX 3.2 15 seconds Give up retrying 949 on MN-AR interface. 951 5. Examples and Signaling Flows 953 5.1 Network controlled, Initiated by pAR, Predictive 955 MN nAR pAR 956 | | | 957 T | | CT trigger 958 I | | | 959 M | |<------- CTD ----------| 960 E |--------CTAR--------->| | 961 : | | | 962 | | |-------- CTDR -------->| 963 V | | | 964 | | | 966 5.2 Network controlled, initiated by nAR, Reactive 968 MN nAR pAR 969 | | | 970 T | CT trigger | 971 I | | | 972 M | |--------- CT-Req ----->| 973 E | | | 974 : | |<------- CTD ----------| 975 | | | | 976 V |--------CTAR--------->| | 977 | |----- CTDR (opt) ----->| 978 | | | 980 5.3 Mobile controlled, Predictive New L2 up/old L2 down 982 CTAR request to nAR 984 MN nAR pAR 985 | | | 986 new L2 link up | | 987 | | | 988 CT trigger | | 989 | | | 990 T |--------CTAR ------->| | 991 I | |-------- CT-Req ------>| 992 M | | | 993 E | |<-------- CTD ---------| 994 : | | | 995 | | | | 996 V | | | 997 | | | 999 It is for future study whether the nAR sends the MN a CTAR reject if 1000 CT is not supported. 1002 6. Security Considerations 1004 At this time, the threats to IP handover in general and context 1005 transfer in particular are incompletely understood, particularly on 1006 the MN to AR link, and mechanisms for countering them are not well 1007 defined. Part of the experimental task in preparing CTP for eventual 1008 standards track will be to better characterize threats to context 1009 transfer and design specific mechanisms to counter them. This section 1010 provides some general guidelines about security based on discussions 1011 among the Design Team and Working Group members. 1013 6.1. Threats. 1015 The Context Transfer Protocol transfers state between access routers. 1016 If the MNs are not authenticated and authorized before moving on the 1017 network, there is a potential for masqurading attacks to shift state 1018 between ARs, causing network disruptions. 1020 Additionally, DoS attacks can be launched from MNs towards the access 1021 routers by requesting multiple context transfers and then 1022 disappearing. Finally, a rogue access router could flood mobile 1023 nodes with packets, attempting DoS attacks, and issue bogus context 1024 transfer requests to surrounding routers. 1026 Consistency and correctness in context transfer depend on 1027 interoperable feature context definitions and how CTP is utilized for 1028 a particular application. For some considerations regarding 1029 consistency and correctness that have general applicability but are 1030 articulated in the context of AAA context transfer, please see [EAP]. 1032 6.2. Access Router Considerations 1034 The CTP inter-router interface relies on IETF standardized security 1035 mechanisms for protecting traffic between access routers, as opposed 1036 to creating application security mechanisms. IPsec MUST be supported 1037 between access routers. 1039 In order to avoid the introduction of additional latency due to the 1040 need for establishment of a secure channel between the context 1041 transfer peers (ARs), the two ARs SHOULD establish such a secure 1042 channel in advance. The two access routers need to engage in a key 1043 exchange mechanisms such as IKE [RFC2409], establish IPSec SAs, 1044 defining the keys, algorithms and IPSec protocols (such as ESP) in 1045 anticipation for any upcoming context transfer. This will save time 1046 during handovers that require secure transfer. Such SAs can be 1047 maintained and used for all upcoming context transfers between the 1048 two ARs. Security should be negotiated prior to the sending of 1049 context. 1051 Access Routers MUST implement IPsec ESP [ESP] in transport mode with 1052 non-null encryption and authentication algorithms to provide per- 1053 packet authentication, integrity protection and confidentiality, and 1054 MUST implement the replay protection mechanisms of IPsec. In those 1055 scenarios where IP layer protection is needed, ESP in tunnel mode 1056 SHOULD be used. Non-null encryption should be used when using IPSec 1057 ESP. Strong security on the inter-router interface is required to 1058 protect against attacks by rogue routers, and to ensure 1059 confidentiality on the context transfer authorization key in 1060 predicative transfer. 1062 The details of IKE key exchange and other details of the IPsec 1063 security associations between routers are to be determined as part of 1064 the research phase associated with finalizing the protocol for 1065 standardization. Prior to standardization, these details must be 1066 determined. Other working groups are currently working on general 1067 security for routing protocols. Ideally, a solution for CTP will be 1068 based on this work, if possible, in order to minimize operational 1069 configuration of routers for different protocols. Requirements for 1070 CTP will be brought to the appropriate IETF routing protocol security 1071 working groups for consideration. 1073 6.3 Mobile Node Considerations 1075 The CTAR message requires the MN and AR to possess a shared secret 1076 key in order to calculate the authorization token. Validation of this 1077 token MUST precede context transfer or installation of context for 1078 the MN, removing the risk that an attacker could cause an 1079 unauthorized transfer. How the shared key is established is out of 1080 scope of the current specification. If both the MN and AR know 1081 certified public keys of the other party, Diffie-Helman can be used 1082 to generate a shared secret [RFC2631]. If an AAA protocol of some 1083 sort is run for network entry, the shared key can be established 1084 using that protocol [PerkCal04]. 1086 If predictive context transfer is used, the shared key for 1087 calculating the authorization token is transferred between ARs. A 1088 transfer of confidential material of this sort poses certain security 1089 risks, even if the actual transfer itself is confidential and 1090 authenticated, as is the case for inter-router CTP. The more entities 1091 know the key, the more likely a compromise may occur. In order to 1092 mitigate this risk, nAR MUST discard the key immediately after using 1093 it to validate the authorization token. The MN MUST establish a new 1094 key with the AR for future CTP transactions. The MN and AR SHOULD 1095 exercise care in using a key established for other purposes for also 1096 authorizing context transfer. It is RECOMMENDED that a separate key 1097 be established for context transfer authorization. 1099 Replay protection on the MN-AR protocol is provided by limiting the 1100 time period in which context is maintained. For predictive transfer, 1101 the pAR receives a CTAR message with a sequence number, transfers the 1102 context along with the authorization token key, then drops the 1103 context and the authorization token key immediately upon completion 1104 of the transfer. For reactive transfer, the nAR receives the CTAR, 1105 requests the context, including the sequence number and authorization 1106 token from the CTAR which allows the pAR to check whether the 1107 transfer is authorized. The pAR drops the context and authorization 1108 token key after the transfer has been completed. The pAR and nAR 1109 ignore any requests containing the same MN IP address if an 1110 outstanding CTAR or CTD message is unacknowledged and has not timed 1111 out. After the key has been dropped, any attempt at replay will fail 1112 because the authorization token fails to validate. The AR MUST NOT 1113 reuse the key for any MN, including the same MN as originally 1114 possessed the key. 1116 DoS attacks on the MN-AR interface can be limited by having the AR 1117 rate limit the number of CTAR messages it processes. The AR SHOULD 1118 limit the number of CTAR messages to CT_REQUEST_RATE. If the request 1119 exceeds this rate, the AR SHOULD randomly drop messages until the 1120 rate is established. The actual rate SHOULD be configured on the AR 1121 to match the maximum number of handovers that the access network is 1122 expected to support. 1124 7. IANA Considerations 1126 Instructions for IANA allocations are included in [IANA]. 1128 8. Acknowledgements & Contributors 1130 This document is the result of a design team formed by the Working 1131 Group chairs of the SeaMoby working group. The team included John 1132 Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. 1134 Contributors to the Context Transfer Protocol review are Basavaraj 1135 Patil, Pekka Savola, and Antti Tuominen. 1137 The working group chairs are Pat Calhoun and James Kempf, whose 1138 comments have been very helpful during the creation of this 1139 specification. 1141 The authors would also like to thank Julien Bournelle, Vijay 1142 Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf 1143 Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their 1144 help and suggestions with this document. 1146 9. References 1148 9.1 Normative References 1150 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 1151 BCP 9, RFC 2026, October 1996. 1153 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- 1154 ment Levels", BCP 14, RFC 2119, March 1997. 1156 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1157 Considerations Section in RFCs", BCP 26, RFC 2434, October 1158 1998. 1160 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 1161 RFC 2409, November 1998. 1163 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- 1164 load (ESP)", RFC 2406, November 1998. 1166 [SCTP] Stewert, R., et. al., "Stream Control Transmission Proto- 1167 col", RFC 2960, October, 2000. 1169 [PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension", 1170 Internet Engineering Task Force. Work in Progress. 1172 [CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate 1173 Access Router Discovery", Internet Engineering Task Force. 1174 Work in Progress. 1176 [IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol 1177 IANA Allocations", Internet Engineering Task Force. Work in 1178 Progress. 1180 9.2 Non-Normative References 1182 [CTHC] R. Koodli et al., "Context Relocation for Seamless Header 1183 Compression in IP Networks", Internet Draft, Internet 1184 Engineering Task Force, Work in Progress. 1186 [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet 1187 Engineering Task Force. Work in Progress. 1189 [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", 1190 Internet Engineering Task Force. Work in Progress. 1192 [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing 1193 Context Transfers Between Nodes in an IP Access Network", RFC 1194 3374, May 2001. 1196 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet 1197 Protocol", RFC 2401, November 1998. 1199 [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet 1200 Engineering Task Force, Work in Progress. 1202 [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631, 1203 June, 1999. 1205 [PerkCal04]C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile 1206 IPv4", Internet Engineering Task Force, Work in Progress. 1208 [MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in 1209 IPv6", Internet Engineering Task Force, Work in Progress. 1211 [RFC2710] S. Deering, W. Fenner, and B. Haberman, " Multicast Listener 1212 Discovery (MLD) for IPv6," RFC 2710, October, 1999. 1214 [RFC2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 1215 for IP Version 6 (IPv6)," RFC 2461, December, 1998. 1217 [RFC2462] S. Thompson, and T. Narten, "IPv6 Address Autoconfiguration," 1218 RFC 2462, December, 1998. 1220 [RFC3095] C. Borman, ed., "RObust Header Compression (ROHC)", RFC 3095, 1221 July, 2001. 1223 [BT] IEEE, "IEEE Standard for information technology - Telecommuni- 1224 cation and information exchange between systems - LAN/MAN - 1225 Part 15.1: Wireless Medium Access Control (MAC) and Physical 1226 Layer (PHY) specifications for Wireless Personal Area Networks 1227 (WPANs)", IEEE Standard 802.15.1, 2002. 1229 [EAP] B. Aboba, D. Simon, J. Arkko, P. Eron, and H. Levokowetz, 1230 "Extensible Authentication Protocol (EAP) Key Management 1231 Framework", Internet Draft, work in progress. 1233 Appendix A. Timing and Trigger Considerations 1235 Basic Mobile IP handover signaling can introduce disruptions to the 1236 services running on top of Mobile IP, which may introduce unwanted 1237 latencies that practically prohibit its use for certain types of 1238 services. Mobile IP latency and packet loss is being optimized 1239 through several alternative procedures, such as Fast Mobile IP 1240 [FMIPv6] and Low Latency Mobile IP [LLMIP]. 1242 Feature re-establishment through context transfer should contribute 1243 zero (optimally) or minimal extra disruption of services in conjunc- 1244 tion to handovers. This means that the timing of context transfer 1245 SHOULD be carefully aligned with basic Mobile IP handover events, and 1246 with optimized Mobile IP handover signaling mechanisms, as those pro- 1247 tocols become available. 1249 Furthermore, some of those optimized mobile IP handover mechanisms 1250 may provide more flexibility in choosing the timing and order for 1251 transfer of various context information. 1253 Appendix B. Multicast Listener Context Transfer 1255 In the past, credible proposals have been made in the Seamoby Working 1256 Group and elsewhere for using context transfer to speed handover of 1257 authentication, authorization, and accounting context, distributed 1258 firewall context, PPP context, and header compression context. 1259 Because the Working Group was not chartered to develop context pro- 1260 file definitions for specific applications, none of the drafts sub- 1261 mitted to Seamoby were accepted as Working Group items. At this time, 1262 work continues to develop a context profile definition for RFC 3095 1263 header compression context [RFC3095] and to characterize the perfor- 1264 mance gains obtainable by using header compression, but the work is 1265 not yet complete. In addition, there are several commercial wireless 1266 products that reportedly use non-standard, non-interoperable context 1267 transfer protocols, though none is as yet widely deployed. 1269 As a consequence, it is difficult at this time to point to a solid 1270 example of how context transfer could result in a commercially 1271 viable, widely deployable, interoperable benefit for wireless net- 1272 works. This is one reason why CTP is being proposed as an Experimen- 1273 tal protocol, rather than Standards Track. However, it nevertheless 1274 seems valuable to have a simple example that shows how handover could 1275 benefit from using CTP. The example we consider here is transferring 1276 IPv6 MLD state [RFC2710]. MLD state is a particularly good example 1277 because every IPv6 node must perform at least one MLD messaging 1278 sequence on the wireless link to establish itself as an MLD listener 1279 prior to performing router discovery [RFC2461] or duplicate address 1280 detection [RFC2462] or before sending/receiving any application- 1281 specific traffic (including Mobile IP handover signaling, if any). 1282 The node must subscribe to the Solicited Node Multicast Address as 1283 soon as it comes up on the link. Any application-specific multicast 1284 addresses must be re-established as well. Context transfer can signi- 1285 ficantly speed up re-establishing multicast state by allowing the nAR 1286 to initialize MLD for a node that just completed handover without any 1287 MLD signaling on the new wireless link. The same approach could be 1288 used for transferring multicast context in IPv4. 1290 An approximate quantitative estimate for the amount of savings in 1291 handover time can be obtained as follows. MLD messages are 24 octets, 1292 to which the headers must be added, because there is no header 1293 compression on the new link, with IPv6 header being 40 octets, and a 1294 required Router Alert Hop-by-Hop option being 8 octets including pad- 1295 ding. The total MLD message size is 72 octets per subscribed multi- 1296 cast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report 1297 messages per address subscription, since the Report message is unack- 1298 nowledged. Assuming 2 MLD messages sent for a subscribed address, the 1299 MN would need to send 144 octets per address subscription. If MLD 1300 messages are sent for both the All Nodes Multicast address and the 1301 Solicited Node Multicast address for the node's link local address, a 1302 total of 288 octets are required when the node hands over to the new 1303 link. Note that some implementations of IPv6 optimize by not sending 1304 an MLD message for the All Nodes Multicast Address, since the router 1305 can infer that at least one node is on the link (itself) when it 1306 comes up and always will be, but for purposes of this calculation, we 1307 assume that the IPv6 implementation is conformant and that the mes- 1308 sage is sent. The amount of time required for MLD signaling will, of 1309 course, depend on the per node available wireless link bandwidth, but 1310 some representative numbers can be obtained by assuming bandwidths of 1311 20 kbps or 100 kbps. With these two bit rates, the savings from not 1312 having to perform the pre-router discovery messages are 115 msec. and 1313 23 msec., respectively. If any application-specific multicast 1314 addresses are subscribed, the amount of time saved could be substan- 1315 tially more. 1317 This example might seem a bit contrived because MLD isn't used in the 1318 3G cellular protocols and wireless local area network protocols typi- 1319 cally have enough bandwidth, if radio propagation conditions are 1320 optimal, so sending a single MLD message might not be viewed as such 1321 a performance burden. An example of a wireless protocol where MLD 1322 context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT]. 1323 IEEE 802.15.1 has two IP "profiles": one with and one without PPP. 1324 The profile without PPP would use MLD. The 802.15.1 protocol has a 1325 maximum bandwidth of about 800 kbps, shared between all nodes on the 1326 link, so a host on a moderately loaded 802.15.1 access point could 1327 experience the kind of bandwidth described in the previous paragraph. 1328 In addition 802.15.1 handover times typically run upwards of a second 1329 or more because the host must resynchronize its frequency hopping 1330 pattern with the access point, so anything the IP layer could do to 1331 alleviate further delay would be beneficial. 1333 The context-specific data field for MLD context transfer included in 1334 the CTP Context Data Block message for a single IPv6 multicast 1335 address has the following format: 1337 0 1 2 3 1338 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 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | | 1341 + Subnet Prefix on nAR Wireless Interface + 1342 | | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | | 1345 + + 1346 | | 1347 + Subscribed IPv6 Multicast Address + 1348 | | 1349 + + 1350 | | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 The Subnet Prefix on nAR Wireless Interface field contains a subnet 1354 prefix that identifies the interface on which multicast routing 1355 should be established. The Subscribed IPv6 Multicast Address field 1356 contains the multicast address for which multicast routing should be 1357 established. 1359 The pAR sends one MLD context block per subscribed IPv6 multicast 1360 address. 1362 No changes are required in the MLD state machine. 1364 Upon receipt of a CTP Context Data Block for MLD, the state machine 1365 takes the following actions: 1367 - If the router is in the No Listeners present state on the wireless 1368 interface on which the Subnet Prefix field in the Context Data 1369 Block is advertised, it transitions into the Listeners Present 1370 state for the Subscribed IPv6 Multicast Address field in the Con- 1371 text Data Block. This transition is exactly the same as if the 1372 router had received a Report message. 1374 - If the router is in the Listeners present state on that interface, 1375 it remains in that state but restarts the timer, as if it had 1376 received a Report message. 1378 If more than one MLD router is on the link, a router receiving an MLD 1379 Context Data Block SHOULD send the block to the other routers on the 1380 link. If wireless bandwidth is not an issue, the router MAY instead 1381 send a proxy MLD Report message on the wireless interface that 1382 advertises the Subnet Prefix field from the Context Data Block. Since 1383 MLD routers do not keep track of which nodes are listening to munti- 1384 cast addresses, only whether a particular multicast address is being 1385 listened to, proxying the subscription should cause no difficulty. 1387 Authors' Addresses 1389 Rajeev Koodli 1390 Nokia Research Center 1391 313 Fairchild Drive 1392 Mountain View, California 94043 1393 USA 1394 Rajeev.koodli@nokia.com 1396 John Loughney 1397 Nokia 1398 Itdmerenkatu 11-13 1399 00180 Espoo 1400 Finland 1401 john.loughney@nokia.com 1403 Madjid F. Nakhjiri 1404 Motorola Labs 1405 1031 East Algonquin Rd., Room 2240 1406 Schaumburg, IL, 60196 1407 USA 1408 madjid.nakhjiri@motorola.com 1410 Charles E. Perkins 1411 Nokia Research Center 1412 313 Fairchild Drive 1413 Mountain View, California 94043 1414 USA 1415 charliep@iprg.nokia.com 1417 Disclaimer of Validity 1419 This document and the information contained herein are provided on an 1420 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1421 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1422 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1423 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 1424 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 1425 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1427 Full Copyright Statement 1429 Copyright (C) The Internet Society (2004). This document is subject 1430 to the rights, licenses and restrictions contained in BCP 78, and 1431 except as set forth therein, the authors retain all their rights. 1433 This document and the information contained herein are provided on an 1434 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1435 OR IS SPONSORED BY \(IF ANY\), THE INTERNET SOCIETY AND THE INTERNET 1436 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1437 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1438 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1439 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1440 PURPOSE. 1442 Intellectual Property 1444 The IETF takes no position regarding the validity or scope of any 1445 Intellectual Property Rights or other rights that might be claimed to 1446 pertain to the implementation or use of the technology described in 1447 this document or the extent to which any license under such rights 1448 might or might not be available; nor does it represent that it has 1449 made any independent effort to identify any such rights. Information 1450 on the procedures with respect to rights in RFC documents can be 1451 found in BCP 78 and BCP 79. 1453 Copies of IPR disclosures made to the IETF Secretariat and any 1454 assurances of licenses to be made available, or the result of an 1455 attempt made to obtain a general license or permission for the use of 1456 such proprietary rights by implementers or users of this specifica- 1457 tion can be obtained from the IETF on-line IPR repository at 1458 http://www.ietf.org/ipr. 1460 The IETF invites any interested party to bring to its attention any 1461 copyrights, patents or patent applications, or other proprietary 1462 rights that may cover technology that may be required to implement 1463 this standard. Please address the information to the IETF at ietf- 1464 ipr@ietf.org. 1466 Acknowledgement 1468 Funding for the RFC Editor function is currently provided by the 1469 Internet Society.