idnits 2.17.1 draft-ietf-mobileip-piggyback-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 112: '... (HA, MN, or CN) MAY request that a se...' RFC 2119 keyword, line 158: '...herwise, payload MAY be sent. To do s...' RFC 2119 keyword, line 171: '... the mobile node MUST NOT do so. Howe...' RFC 2119 keyword, line 172: '... MAY still Use the Nonfinal Mobil...' RFC 2119 keyword, line 180: '... Mobility Header MUST be ignored, and ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 359 has weird spacing: '...Message for...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 15 April 2002 Francis Dupont 4 ENST Bretagne 6 Nonfinal Mobility Header for Mobile IPv6 7 draft-ietf-mobileip-piggyback-00.txt 9 Status of This Memo 11 This document is a submission by the IETF Mobile IP Working Group 12 Working Group of the Internet Engineering Task Force (IETF). 13 Comments should be submitted to the mobile-ip@sunroof.eng.sun.com 14 mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document specifies operations to allow inclusion of data along 37 with a mobility header (from Mobile IPv6) containing a Binding Update 38 or Binding Acknowledgement message. In this way, smoother handovers 39 and reduced jitter and bandwidth utilization can be achieved. 40 Interactions with IPsec-based verification of mobility messages are 41 described; basically, establishment of such IPsec-based methods 42 preclude the use of the mobility header specified in this document, 43 unless simple modifications to IPsec (outside the scope of this 44 document) can be utilized. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 54 2. Terminology 2 56 3. Nonfinal Mobility Message Header Format 3 58 4. Operation and Use of the Nonfinal Mobility Header 3 59 4.1. Rules for the Sender . . . . . . . . . . . . . . . . . . 3 60 4.2. Rules for the Correspondent Node . . . . . . . . . . . . 3 62 5. ICMP Payload Inclusion Control Message 4 64 6. IANA Considerations 4 66 7. Security Considerations 5 68 8. Acknowledgement 5 70 References 5 72 A. Requesting Isolation of Payload and Mobility Headers 6 74 B. Table of Nonfinal and Final Mobility Header vs IPsec-based 75 Security 7 77 C. Mobility Signals Which May be Included with Payload 8 79 Addresses 9 81 1. Introduction 83 When a mobile node moves to a new point of attachment, it can use 84 a Mobile IPv6 Binding Update message [3] to supply a new care-of 85 address to a correspondent node. This information can conveniently 86 be located in the same packet as data which the mobile node may be 87 already transmitting towards the correspondent node. In this way, 88 smoother handovers and reduced jitter and bandwidth utiliziation can 89 be achieved. 91 Such operation has been described in Mobile IPv6 specifications until 92 recently, when concerns about IPsec policy ambiguity led to a more 93 restrictive approach towards verifying the authentication data in 94 the Mobility Header. Basically, establishment of such IPsec-based 95 security associations for verifying authentication data precludes 96 the use of the mobility header specified in this document, unless 97 simple modifications to IPsec (outside the scope of this document) 98 can be utilized. Some suggestions for possible improvements to 99 IPsec are included in an appendix, along with descriptions of other 100 interactions with IPsec-based verification of mobility messages. 102 The requirement is to use of two new header types: one extension 103 header that can be placed before a transport header, and one final 104 header type to enable use of IPsec for verifying authentication 105 data. Since an extension header cannot be protected according 106 to the strictest interpretation of RFC 2401 [4], and the final 107 header type is considered as transport, there is no requirement for 108 changing IPsec at all in any node, peer or intermediate. Since 109 these two headers have an identical format, the effect on mobility 110 implementation is minimal. 112 A node (HA, MN, or CN) MAY request that a sender always send mobility 113 control information without data, by indicating "No Piggybacking" 114 whenever the underlying security association is established (see 115 section 5). For the return-routability messages specified in in the 116 base Mobile IPv6 draft [3], this information can be supplied as a 117 option to the Home Address Test message sent back to the mobile node. 119 An implementation can have a policy which by default allows 120 piggybacking, by means of static configuration. If there is any 121 non-IPsec reason why the node cannot use the Nonfinal Mobility 122 Header, the default policy can be disabled by a management interface 123 to the policy. If IPsec is used, this default behavior must be 124 disabled. 126 2. Terminology 128 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [1]. This 131 section defines other terminology used that is not already defined 132 in [3]. 134 Piggybacking 136 The insertion of two packets from separate message flows or 137 sessions is often called "piggybacking". In this document, 138 piggybacking refers to the insertion of a nonfinal Mobility 139 Header into an IPv6 packet that also contains payload. 141 3. Nonfinal Mobility Message Header Format 143 The format of the Nonfinal Mobility Header is identical to the 144 format of the final Mobility Header specified in Mobile IPv6 [3]. 145 In this document, only message types for Binding Update, Binding 146 Acknowledgement, and Binding Request are specified as allowable types 147 for the Nonfinal Mobility Header. 149 4. Operation and Use of the Nonfinal Mobility Header 151 The basic rule is simple: 153 - If there is an IPsec security association which is established to 154 create verification data for binding cache messages, no payload 155 may be sent along with any binding cache message. Use the 156 "final" Mobility Header. 158 - Otherwise, payload MAY be sent. To do so, use the Nonfinal 159 Mobility Header specified in section 3, along with the Binding 160 Authentication Data option from [3], to validate the message. 162 The following subsections detail any necessary elaboration to the 163 above rule. 165 4.1. Rules for the Sender 167 The basic rule applies, except that: 169 If the correspondent node has requested that no payload 170 be included in packets containing a Mobility Header, then 171 the mobile node MUST NOT do so. However, the mobile node 172 MAY still Use the Nonfinal Mobility Header along with the 173 Binding Authentication Data option, with empty payload. 175 4.2. Rules for the Correspondent Node 177 For the most part, the correspondent node just follows the basic rule 178 for any IPv6 extension header [2]. If there exists an IPsec-based 179 security association that is to be used when validating binding cache 180 messages, the Nonfinal Mobility Header MUST be ignored, and any 181 payload processed just as if the Mobility Header were not present. 183 If a correspondent node receives a Nonfinal Mobility Header with 184 payload, and if for any reason it would prefer to have the payload 185 received in separate packets, the correspondent node SHOULD send an 186 ICMP "Piggybacking Control" message back to the mobile node (see 187 section 5). However, in this case, the correspondent node MUST 188 NOT drop the packet. Processing for the contents of the Nonfinal 189 Mobility Header is governed by the basic rule, not the existence or 190 absence of payload. 192 5. ICMP Payload Inclusion Control Message 194 This specification introduces a new ICMP message type, for use when a 195 correspondent node would prefer to control the inclusion of payload 196 with the Nonfinal Mobility Header. 198 The ICMP "Payload Inclusion Control" has the following format: 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type | Code | Checksum | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 The Type field is TBD. The Reserved field is sent as zero, and 209 ignored on reception. The Code field can have two valued: 211 0 Payload MAY be sent following the Nonfinal Mobility 212 Header 214 1 Payload MUST NOT be sent following the Nonfinal Mobility 215 Header 217 See appendix A for discussion about conditions under which a 218 correspondent node might utilize such a feature. 220 6. IANA Considerations 222 This specification reserves one extension header number for the 223 Nonfinal Mobility Header (see section 3). 225 This specification also reserves one ICMP number for the "Payload 226 Inclusion Control" ICMP message (see section 5). 228 7. Security Considerations 230 This document describes a protocol extension header which allows for 231 interoperation with IPsec such that the IPsec selector granularity 232 requirement for protecting mobility signaling by IPsec headers can be 233 expressed in a policy. 235 A protocol number reserved as the end header allows for this with 236 IPsec while the other protocol number allows for use of the Nonfinal 237 Mobility Header for those times when there is no IPsec security 238 association governing the validation of binding cache messages. The 239 cache signaling is then protected by the non-IPsec method used with 240 route optimization. 242 Hence, the proposal solves the ambiguity problem that is result of 243 having only a single IPsec header available to protect both the 244 payload and the mobility cache management signaling. Furthermore, 245 this proposal enables a very strict interpretation of the clause [4] 246 which requires that IPsec policy selection be made only on the basis 247 of the final IP header type -- which is often the transport header. 248 When IPsec is to be used to validate binding cache messages, even 249 the strict interpretation allows IPsec to be used, as long as the 250 relevant message data resides in a final header as is specified 251 in [3]. However, some implementations would no longer allow payload 252 with the IPsec-protected mobility cache signaling. This proposal 253 solves that problem. 255 8. Acknowledgement 257 Appendices B and C were written by Vijay Devarapalli and Jari 258 Malinen, who also provided valuable comments on the other parts of 259 this draft. 261 References 263 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 264 Levels. Request for Comments (Best Current Practice) 2119, 265 Internet Engineering Task Force, March 1997. 267 [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 268 Specification. Request for Comments (Draft Standard) 2460, 269 Internet Engineering Task Force, December 1998. 271 [3] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in 272 progress). Internet Draft, Internet Engineering Task Force, 273 March 2001. 275 [4] S. Kent and R. Atkinson. Security Architecture for the Internet 276 Protocol. Request for Comments (Proposed Standard) 2401, 277 Internet Engineering Task Force, November 1998. 279 A. Requesting Isolation of Payload and Mobility Headers 281 In this discussion, a few fundamental principles should be kept in 282 mind: 284 - IP has a MTU which is far larger than the typical capacity of a 285 radio bearer channel. Thus, in order to be IPv6 compliant, the 286 device driver for the bearer channel MUST be able to transmit 287 larger packets, presumably by a link-layer adaptation that 288 fragments and reassembles bearer frames. 290 Consequently, requirements related to packet sizing should 291 logically be considered as part of a "IP-over-foo" specification, 292 and neither part of the base Mobile IPv6 specification, nor this 293 specification. The "piggybacking" ICMP message are provided 294 merely for convenience. 296 - IP typically does not distinguish between the delivery of data 297 and control information. Expectations that binding cache control 298 information will be delivered out of band, represent assumptions 299 which can only be satisfied for particular systems. Again, the 300 logical place to specify protocol details that can enable such 301 expectations to be met, would be in a separate "IP-over-foo" 302 specification. 304 - If there is a "flow" which needs a certain reserved capacity 305 in order to achieve acceptable performance, then the natural 306 solution for meeting that need should involve a Quality 307 of Service negotiation for that flow, along with admission 308 control, and then the subsequent traffic shaping, conditioning, 309 and charging. Any expectation that a specific kind of data 310 will be the only allowable data that can flow over a radio 311 bearer channel, represents an unwarranted restriction that 312 should not persist in any generic IPv6 protocol specification. 313 Considerations which are unique for particular platforms or media 314 belong in separate "IP-over-foo" specifications. 316 It is expected that Mobile IPv6 will be deployed in systems that 317 carry voice data over such constrained radio bearer channels. In 318 this situation, it could be that the bearer channel is engineered 319 to fit the size of the voice data, and any extra data might cause 320 unintended effects. For convenience, the receiver (i.e., the 321 correspondent node) might then send an ICMP "Piggybacking Control" 322 to the transmitter (i.e., the mobile node), in order to forestall 323 this possibility. The binding cache management information would 324 then presumably be delivered to the mobile node either during a time 325 when no voice data was available, or over an alternate channel. This 326 introduces nontrivial timing dependencies. In partcular, the mobile 327 node SHOULD NOT blindly send out Binding Update messages to all 328 correspondent nodes on its Binding List unless there is a reasonable 329 expectation that the correspondent node will be sending data to the 330 mobile node before the mobile node moves to yeat another point of 331 attachment to the Internet. Furthermore, a method is needed by which 332 the mobile node can determine whether the mobility signaling, or 333 the application payload data, has priority for transmission to the 334 correspondent node, in cases where the mobile node does have some 335 data to send. 337 Another possibility would be to allow the correspondent node to 338 instruct the mobile node about its needs for future binding cache 339 message handling by way of conditioning applied to the establishment 340 of the security association by which the binding messages are to 341 be validated. This method suffers from the disadvantage that the 342 isolation of binding cache messages and payload is no longer able to 343 be dynamically controlled. 345 B. Table of Nonfinal and Final Mobility Header vs IPsec-based Security 347 In order to include cache management signaling along with payload 348 when IPsec is in use, we have cases 1-4 in Table 1. We assume 349 the current IPsec selectors [4] and two mobility header types for 350 mobility signals: a final header (as defined in [3]), and a nonfinal 351 extension header (as defined in section 3). The node having IPsec 352 policies (controlling the insertion of an AH or ESP header) can 353 use the nonfinal extension header in cases 1 and 2, that is, when 354 mobility signaling does not have an IPsec policy. 356 Table 1: Nonfinal Mobility Header Inclusion with IPsec 358 IPsec policy for IPsec policy 359 Mobility Message for Payload Can piggyback? 360 1. no no | yes 361 2. no yes | yes 362 3. yes no | no 363 4. yes yes | no 365 In order for the mobility signaling to enforce this, the mobility 366 code of a sender needs to know the nature of the security policy 367 which controls mobility signaling. The easiest way to do this is 368 to record the information for use within the mobility processing, 369 at the time the security association is set up for this purpose. 370 That is very natural, since the security association is itself 371 established for mobility management. In unforeseen cases where no 372 such records-keeping is possible, an implementation can make the 373 determination even after the security association is set up, as 374 follows. First, construct a mobility signaling packet, making the 375 header type final and causing a kernel IPsec policy lookup, in the 376 same way as a non-mobility kernel would do. IPsec already does this 377 for any packet. If no policy exists, the final header type MAY be 378 changed to an extension one to indicate that this signal can be 379 piggybacked. If a policy was found, the final header type MUST be 380 used. 382 A receiver needs no knowledge of mobility in its IPsec processing. 383 The header type determines whether a policy even can exist. If the 384 header is final and no policy exists, or a wrong policy exists, the 385 packet will be transparently rejected by IPsec. If the header is 386 an extension header, the header type determines that this signal 387 cannot have an IPsec policy. Whether it accepts the extension header 388 depends on policy of the non-IPsec protection. 390 Piggybacking is not possible on case 3, due to processing 391 difficulties at both the sender and the receiver. The scan for 392 transport protocol field as described in [4] does not allow for such 393 a mode. For case 4, conflicting IPsec policies make it impossible to 394 piggyback. 396 Putting the above together, the sender MAY piggyback for the cases 397 1 and 2 in Table 1 and MUST NOT piggyback for cases 3 and 4. This 398 leads directly to the basic rule formulated in section 4. 400 C. Mobility Signals Which May be Included with Payload 402 An implementation sends mobility signaling piggybacked when its 403 negotiation result with the peer allows and if it makes sense for the 404 mobility signal in question. 406 Mobility message types include binding cache management 407 messages (BU/BAck/BR) and the return routability test messages 408 (HoTI/HoT/CoTI/CoT). Piggybacking of BU/BAck messages between the 409 mobile node and its home agent is very rare, since the mobile node 410 rarely has any payload for the home agent other than the Binding 411 Update itself. However, the home agent MAY wish to include a 412 Binding Request message along with a Router Advertisement in order to 413 facilitate renumbering. Table 2 describes when a mobility signal can 414 be included with the payload to be sent between a mobile node (MN) 415 and a correspondent node (CN). 417 "Maybe" indicates that piggybacking would be sometimes possible 418 (details in the design team writeup). 420 Addresses 422 The working group can be contacted via the current chairs: 424 Basavaraj Patil Phil Roberts 425 Nokia Megisto Corp. 426 6000 Connection Dr. Suite 120 427 20251 Century Blvd 428 Irving, TX. 75039 Germantown MD 20874 429 USA USA 430 Phone: +1 972-894-6709 Phone: +1 847-202-9314 431 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 433 Questions about this memo can also be directed to the authors: 435 Charles E. Perkins Francis Dupont 436 Communications Systems Lab ENST Bretagne 437 Nokia Research Center Campus de Rennes 438 313 Fairchild Drive 2, rue de la Chataigneraie 439 BP 78 440 Mountain View, California 94043 35512 Cesson-Sevigne Cedex 441 USA FRANCE 442 Phone: +1-650 625-2986 443 Fax: +1 650 625-2502 Fax: +33 2 99 12 70 30 444 EMail: charliep@iprg.nokia.com Francis.Dupont@enst-bretagne.fr 446 Table 2: Mobility Signals and Piggybacking, Assuming No IPsec Policy 447 Controlling Verification of Mobility Messages 448 Mobility Message Type Sndr Rcvr Piggyback? 449 --------------------- ---- ---- ---------- 450 BU (Binding Update) MN CN Yes 451 BAck (Binding Acknowledgment) CN MN Yes 452 BR (Binding Request) CN MN Yes 453 Home Address Test Initiate MN CN Maybe 454 Home Address Test CN MN No 455 Care-of Address Test Initiate MN CN Maybe 456 Care-of Address Test CN MN No