IETF Mobile IP Working Group Charles E. Perkins INTERNET DRAFT Nokia Research Center 15 April 2002 Francis Dupont ENST Bretagne Nonfinal Mobility Header for Mobile IPv6 draft-ietf-mobileip-piggyback-00.txt Status of This Memo This document is a submission by the IETF Mobile IP Working Group Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@sunroof.eng.sun.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document specifies operations to allow inclusion of data along with a mobility header (from Mobile IPv6) containing a Binding Update or Binding Acknowledgement message. In this way, smoother handovers and reduced jitter and bandwidth utilization can be achieved. Interactions with IPsec-based verification of mobility messages are described; basically, establishment of such IPsec-based methods preclude the use of the mobility header specified in this document, unless simple modifications to IPsec (outside the scope of this document) can be utilized. Perkins, Dupont Expires 15 November 2002 [Page i] Internet Draft Nonfinal Mobility Header 15 April 2002 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 3. Nonfinal Mobility Message Header Format 3 4. Operation and Use of the Nonfinal Mobility Header 3 4.1. Rules for the Sender . . . . . . . . . . . . . . . . . . 3 4.2. Rules for the Correspondent Node . . . . . . . . . . . . 3 5. ICMP Payload Inclusion Control Message 4 6. IANA Considerations 4 7. Security Considerations 5 8. Acknowledgement 5 References 5 A. Requesting Isolation of Payload and Mobility Headers 6 B. Table of Nonfinal and Final Mobility Header vs IPsec-based Security 7 C. Mobility Signals Which May be Included with Payload 8 Addresses 9 1. Introduction When a mobile node moves to a new point of attachment, it can use a Mobile IPv6 Binding Update message [3] to supply a new care-of address to a correspondent node. This information can conveniently be located in the same packet as data which the mobile node may be already transmitting towards the correspondent node. In this way, smoother handovers and reduced jitter and bandwidth utiliziation can be achieved. Perkins, Dupont Expires 15 November 2002 [Page 1] Internet Draft Nonfinal Mobility Header 15 April 2002 Such operation has been described in Mobile IPv6 specifications until recently, when concerns about IPsec policy ambiguity led to a more restrictive approach towards verifying the authentication data in the Mobility Header. Basically, establishment of such IPsec-based security associations for verifying authentication data precludes the use of the mobility header specified in this document, unless simple modifications to IPsec (outside the scope of this document) can be utilized. Some suggestions for possible improvements to IPsec are included in an appendix, along with descriptions of other interactions with IPsec-based verification of mobility messages. The requirement is to use of two new header types: one extension header that can be placed before a transport header, and one final header type to enable use of IPsec for verifying authentication data. Since an extension header cannot be protected according to the strictest interpretation of RFC 2401 [4], and the final header type is considered as transport, there is no requirement for changing IPsec at all in any node, peer or intermediate. Since these two headers have an identical format, the effect on mobility implementation is minimal. A node (HA, MN, or CN) MAY request that a sender always send mobility control information without data, by indicating "No Piggybacking" whenever the underlying security association is established (see section 5). For the return-routability messages specified in in the base Mobile IPv6 draft [3], this information can be supplied as a option to the Home Address Test message sent back to the mobile node. An implementation can have a policy which by default allows piggybacking, by means of static configuration. If there is any non-IPsec reason why the node cannot use the Nonfinal Mobility Header, the default policy can be disabled by a management interface to the policy. If IPsec is used, this default behavior must be disabled. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. This section defines other terminology used that is not already defined in [3]. Piggybacking The insertion of two packets from separate message flows or sessions is often called "piggybacking". In this document, Perkins, Dupont Expires 15 November 2002 [Page 2] Internet Draft Nonfinal Mobility Header 15 April 2002 piggybacking refers to the insertion of a nonfinal Mobility Header into an IPv6 packet that also contains payload. 3. Nonfinal Mobility Message Header Format The format of the Nonfinal Mobility Header is identical to the format of the final Mobility Header specified in Mobile IPv6 [3]. In this document, only message types for Binding Update, Binding Acknowledgement, and Binding Request are specified as allowable types for the Nonfinal Mobility Header. 4. Operation and Use of the Nonfinal Mobility Header The basic rule is simple: - If there is an IPsec security association which is established to create verification data for binding cache messages, no payload may be sent along with any binding cache message. Use the "final" Mobility Header. - Otherwise, payload MAY be sent. To do so, use the Nonfinal Mobility Header specified in section 3, along with the Binding Authentication Data option from [3], to validate the message. The following subsections detail any necessary elaboration to the above rule. 4.1. Rules for the Sender The basic rule applies, except that: If the correspondent node has requested that no payload be included in packets containing a Mobility Header, then the mobile node MUST NOT do so. However, the mobile node MAY still Use the Nonfinal Mobility Header along with the Binding Authentication Data option, with empty payload. 4.2. Rules for the Correspondent Node For the most part, the correspondent node just follows the basic rule for any IPv6 extension header [2]. If there exists an IPsec-based security association that is to be used when validating binding cache messages, the Nonfinal Mobility Header MUST be ignored, and any payload processed just as if the Mobility Header were not present. Perkins, Dupont Expires 15 November 2002 [Page 3] Internet Draft Nonfinal Mobility Header 15 April 2002 If a correspondent node receives a Nonfinal Mobility Header with payload, and if for any reason it would prefer to have the payload received in separate packets, the correspondent node SHOULD send an ICMP "Piggybacking Control" message back to the mobile node (see section 5). However, in this case, the correspondent node MUST NOT drop the packet. Processing for the contents of the Nonfinal Mobility Header is governed by the basic rule, not the existence or absence of payload. 5. ICMP Payload Inclusion Control Message This specification introduces a new ICMP message type, for use when a correspondent node would prefer to control the inclusion of payload with the Nonfinal Mobility Header. The ICMP "Payload Inclusion Control" has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type field is TBD. The Reserved field is sent as zero, and ignored on reception. The Code field can have two valued: 0 Payload MAY be sent following the Nonfinal Mobility Header 1 Payload MUST NOT be sent following the Nonfinal Mobility Header See appendix A for discussion about conditions under which a correspondent node might utilize such a feature. 6. IANA Considerations This specification reserves one extension header number for the Nonfinal Mobility Header (see section 3). This specification also reserves one ICMP number for the "Payload Inclusion Control" ICMP message (see section 5). Perkins, Dupont Expires 15 November 2002 [Page 4] Internet Draft Nonfinal Mobility Header 15 April 2002 7. Security Considerations This document describes a protocol extension header which allows for interoperation with IPsec such that the IPsec selector granularity requirement for protecting mobility signaling by IPsec headers can be expressed in a policy. A protocol number reserved as the end header allows for this with IPsec while the other protocol number allows for use of the Nonfinal Mobility Header for those times when there is no IPsec security association governing the validation of binding cache messages. The cache signaling is then protected by the non-IPsec method used with route optimization. Hence, the proposal solves the ambiguity problem that is result of having only a single IPsec header available to protect both the payload and the mobility cache management signaling. Furthermore, this proposal enables a very strict interpretation of the clause [4] which requires that IPsec policy selection be made only on the basis of the final IP header type -- which is often the transport header. When IPsec is to be used to validate binding cache messages, even the strict interpretation allows IPsec to be used, as long as the relevant message data resides in a final header as is specified in [3]. However, some implementations would no longer allow payload with the IPsec-protected mobility cache signaling. This proposal solves that problem. 8. Acknowledgement Appendices B and C were written by Vijay Devarapalli and Jari Malinen, who also provided valuable comments on the other parts of this draft. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [3] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, March 2001. Perkins, Dupont Expires 15 November 2002 [Page 5] Internet Draft Nonfinal Mobility Header 15 April 2002 [4] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. Request for Comments (Proposed Standard) 2401, Internet Engineering Task Force, November 1998. A. Requesting Isolation of Payload and Mobility Headers In this discussion, a few fundamental principles should be kept in mind: - IP has a MTU which is far larger than the typical capacity of a radio bearer channel. Thus, in order to be IPv6 compliant, the device driver for the bearer channel MUST be able to transmit larger packets, presumably by a link-layer adaptation that fragments and reassembles bearer frames. Consequently, requirements related to packet sizing should logically be considered as part of a "IP-over-foo" specification, and neither part of the base Mobile IPv6 specification, nor this specification. The "piggybacking" ICMP message are provided merely for convenience. - IP typically does not distinguish between the delivery of data and control information. Expectations that binding cache control information will be delivered out of band, represent assumptions which can only be satisfied for particular systems. Again, the logical place to specify protocol details that can enable such expectations to be met, would be in a separate "IP-over-foo" specification. - If there is a "flow" which needs a certain reserved capacity in order to achieve acceptable performance, then the natural solution for meeting that need should involve a Quality of Service negotiation for that flow, along with admission control, and then the subsequent traffic shaping, conditioning, and charging. Any expectation that a specific kind of data will be the only allowable data that can flow over a radio bearer channel, represents an unwarranted restriction that should not persist in any generic IPv6 protocol specification. Considerations which are unique for particular platforms or media belong in separate "IP-over-foo" specifications. It is expected that Mobile IPv6 will be deployed in systems that carry voice data over such constrained radio bearer channels. In this situation, it could be that the bearer channel is engineered to fit the size of the voice data, and any extra data might cause unintended effects. For convenience, the receiver (i.e., the correspondent node) might then send an ICMP "Piggybacking Control" to the transmitter (i.e., the mobile node), in order to forestall Perkins, Dupont Expires 15 November 2002 [Page 6] Internet Draft Nonfinal Mobility Header 15 April 2002 this possibility. The binding cache management information would then presumably be delivered to the mobile node either during a time when no voice data was available, or over an alternate channel. This introduces nontrivial timing dependencies. In partcular, the mobile node SHOULD NOT blindly send out Binding Update messages to all correspondent nodes on its Binding List unless there is a reasonable expectation that the correspondent node will be sending data to the mobile node before the mobile node moves to yeat another point of attachment to the Internet. Furthermore, a method is needed by which the mobile node can determine whether the mobility signaling, or the application payload data, has priority for transmission to the correspondent node, in cases where the mobile node does have some data to send. Another possibility would be to allow the correspondent node to instruct the mobile node about its needs for future binding cache message handling by way of conditioning applied to the establishment of the security association by which the binding messages are to be validated. This method suffers from the disadvantage that the isolation of binding cache messages and payload is no longer able to be dynamically controlled. B. Table of Nonfinal and Final Mobility Header vs IPsec-based Security In order to include cache management signaling along with payload when IPsec is in use, we have cases 1-4 in Table 1. We assume the current IPsec selectors [4] and two mobility header types for mobility signals: a final header (as defined in [3]), and a nonfinal extension header (as defined in section 3). The node having IPsec policies (controlling the insertion of an AH or ESP header) can use the nonfinal extension header in cases 1 and 2, that is, when mobility signaling does not have an IPsec policy. Table 1: Nonfinal Mobility Header Inclusion with IPsec IPsec policy for IPsec policy Mobility Message for Payload Can piggyback? 1. no no | yes 2. no yes | yes 3. yes no | no 4. yes yes | no In order for the mobility signaling to enforce this, the mobility code of a sender needs to know the nature of the security policy which controls mobility signaling. The easiest way to do this is to record the information for use within the mobility processing, Perkins, Dupont Expires 15 November 2002 [Page 7] Internet Draft Nonfinal Mobility Header 15 April 2002 at the time the security association is set up for this purpose. That is very natural, since the security association is itself established for mobility management. In unforeseen cases where no such records-keeping is possible, an implementation can make the determination even after the security association is set up, as follows. First, construct a mobility signaling packet, making the header type final and causing a kernel IPsec policy lookup, in the same way as a non-mobility kernel would do. IPsec already does this for any packet. If no policy exists, the final header type MAY be changed to an extension one to indicate that this signal can be piggybacked. If a policy was found, the final header type MUST be used. A receiver needs no knowledge of mobility in its IPsec processing. The header type determines whether a policy even can exist. If the header is final and no policy exists, or a wrong policy exists, the packet will be transparently rejected by IPsec. If the header is an extension header, the header type determines that this signal cannot have an IPsec policy. Whether it accepts the extension header depends on policy of the non-IPsec protection. Piggybacking is not possible on case 3, due to processing difficulties at both the sender and the receiver. The scan for transport protocol field as described in [4] does not allow for such a mode. For case 4, conflicting IPsec policies make it impossible to piggyback. Putting the above together, the sender MAY piggyback for the cases 1 and 2 in Table 1 and MUST NOT piggyback for cases 3 and 4. This leads directly to the basic rule formulated in section 4. C. Mobility Signals Which May be Included with Payload An implementation sends mobility signaling piggybacked when its negotiation result with the peer allows and if it makes sense for the mobility signal in question. Mobility message types include binding cache management messages (BU/BAck/BR) and the return routability test messages (HoTI/HoT/CoTI/CoT). Piggybacking of BU/BAck messages between the mobile node and its home agent is very rare, since the mobile node rarely has any payload for the home agent other than the Binding Update itself. However, the home agent MAY wish to include a Binding Request message along with a Router Advertisement in order to facilitate renumbering. Table 2 describes when a mobility signal can be included with the payload to be sent between a mobile node (MN) and a correspondent node (CN). Perkins, Dupont Expires 15 November 2002 [Page 8] Internet Draft Nonfinal Mobility Header 15 April 2002 "Maybe" indicates that piggybacking would be sometimes possible (details in the design team writeup). Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Megisto Corp. 6000 Connection Dr. Suite 120 20251 Century Blvd Irving, TX. 75039 Germantown MD 20874 USA USA Phone: +1 972-894-6709 Phone: +1 847-202-9314 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com Questions about this memo can also be directed to the authors: Charles E. Perkins Francis Dupont Communications Systems Lab ENST Bretagne Nokia Research Center Campus de Rennes 313 Fairchild Drive 2, rue de la Chataigneraie BP 78 Mountain View, California 94043 35512 Cesson-Sevigne Cedex USA FRANCE Phone: +1-650 625-2986 Fax: +1 650 625-2502 Fax: +33 2 99 12 70 30 EMail: charliep@iprg.nokia.com Francis.Dupont@enst-bretagne.fr Perkins, Dupont Expires 15 November 2002 [Page 9] Internet Draft Nonfinal Mobility Header 15 April 2002 Table 2: Mobility Signals and Piggybacking, Assuming No IPsec Policy Controlling Verification of Mobility Messages Mobility Message Type Sndr Rcvr Piggyback? --------------------- ---- ---- ---------- BU (Binding Update) MN CN Yes BAck (Binding Acknowledgment) CN MN Yes BR (Binding Request) CN MN Yes Home Address Test Initiate MN CN Maybe Home Address Test CN MN No Care-of Address Test Initiate MN CN Maybe Care-of Address Test CN MN No Perkins, Dupont Expires 15 November 2002 [Page 10]