INTERNET-DRAFT P. Nikander J. Lundberg Expires September 2001 Ericsson NomadicLab C. Candolin T. Aura Helsinki Univ. of Tech. February 2001 Homeless Mobile IPv6 Status of this Memo 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 a variant of the Mobility Support in IPv6 protocol [MIP6], mainly intended for mobile hosts that do not need to or want to use any explicit home agent. However, portions of the protocol may be beneficial for other hosts as well, including non-mobile hosts, since it reduces the average header sizes for packets flowing between two mobile hosts or between a mobile and a non-mobile host. It may also be beneficial to multi-homed hosts or sites, since it allows migration of connections from one IP address to another. The variant can interwork with hosts implementing standard Mobility Support in IPv6 [MIP6], and with hosts implementing the minimal conformance requirements of Section 7.1 of [MIP6]. Four fundamental design principles of the protocol are the following. (1) Do not require, nor assume, any explicit home addresses or agents. (2) Try to minimize the average header overhead caused by mobility. (2a) Try to assure that the headers are easily compressable. (3) Try to minimize the changes to Mobile IPv6. (4) Be backward compatible with Mobile IPv6. However, it has not been a goal to be fully backward compatible with all applications. That is, while almost all applications should function without any changes, some applications may require application level modifications. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 1.2. New and Renamed Architectural Entities . . . . . . . . . 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 1.4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 2. Homeless Mobile IPv6 Functions . . . . . . . . . . . . . . . . 2.1. Maintaining Host Cache . . . . . . . . . . . . . . . . . 2.1.1. Creating Host Cache Entries . . . . . . . . . . . 2.1.2. Sending Binding Updates 2.1.3. Adding Addresses to Host Cache Entries . . . . . . 2.1.4. Removing Address from Host Cache Entries . . . 2.1.5. Removing Host Cache Entries . . . . . . . . . . . 2.2. Sending Packets . . . . . . . . . . . . . . . . . . . . . 2.2.1. Sending Packets to a Homeless (supporting) Hosts . 2.2.2. Sending Packets to Standard Mobile Hosts . . . . . 2.2.3. Sending Packets to Standard Hosts . . . . . . . . 2.2.4. Sending Packets to hosts with unknown capabilities 2.3. Receiving Packets . . . . . . . . . . . . . . . . . . . . 2.3.1. Receiving packets from other Homeless Hosts . . . 2.3.2. Receiving packets from Standard Mobile Hosts . . . 2.3.3. Receiving packets from Standard Hosts. . . . . . . 2.3.4. Receiving packets from hosts that do not have any corresponding Foreign Host Cache Entry . . . . . . 2.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1. Using Security Associations and Accepting New Addresses . . . . . . . . . . . . . . . . . . . . 2.4.2. Using Less Secure AH SAs . . . . . . . . . . . . . 2.4.3. Anonymous Authentication . . . . . . . . . . . . . 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 3.1. New Destination Option Sub-Options . . . . . . . . . . . 3.1.1. Homeless Support Sub-Option . . . . . . . . . . . 3.1.2. Alternate Prefixes Sub-Option . . . . . . . . . . 3.1.3. Security Challenge/Response Sub-Option . . . . . . 3.2. Packet Formats . . . . . . . . . . . . . . . . . . . . . 3.2.1. Initial Binding Update . . . . . . . . . . . . . . 3.2.2. Consecutive Binding Updates sent to Homeless Hosts 3.2.3. Consecutive Binding Updates sent to Standard Hosts 3.3. Protocol Parameters . . . . . . . . . . . . . . . . . . . 3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Classification of AH Security Associations . . . . 3.4.2. Verifying reachability . . . . . . . . . . . . . . 4. Security and Privacy Considerations . . . . . . . . . . . . . . 5. General Comments and Open Issues . . . . . . . . . . . . . . . 5.1. Application Backwards Compatibility . . . . . . . . . . . 5.2. Cache Entry Creation Policy . . . . . . . . . . . . . . . 5.3. Address Confusion . . . . . . . . . . . . . . . . . . . . 6. Intellectual Property Right Notice . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . A. Example Packet Flows . . . . . . . . . . . . . . . . . . . . . B. Binding Update Optimization . . . . . . . . . . . . . . . . . . C. An attack against "address ownership" . . . . . . . . . . . . . D. State machine for backward compatibility . . . . . . . . . . . 1. Introduction This memo specifies Homeless Mobile IPv6, a variant of the Mobility Support in IPv6 [MIP6] (aka Mobile IPv6) protocol. This variant provides mobility and handoff support for hosts that do not have any permanent home address, or that just want to take advantage of the smaller average header size of Homeless Mobile IPv6 vs. standard Mobile IPv6. Homeless Mobile IPv6 is backward compatible and can interwork with hosts that support only standard Mobile IPv6 [MIP6], or just the minimal interoperability requirements of Section 7.1 of [MIP6]. From a strictly technical point of view, Homeless Mobile IPv6 is basically a different way to implement Mobile IPv6, with just minimal protocol changes. In fact, almost all of this specification could stand without any protocol changes, but in that case some of the benefits of this specification would be lost. On the other hand, this specification has profound implications to the semantics of upper layer protocols, including TCP and UDP, and to a lesser extent, to AH and ESP. Basically, as in standard Mobile IPv6, Homeless Mobile IPv6 allows the applications to maintain transport and higher-layer connections (as well as Security Associations) when a host changes its location, and therefore its IP address. However, the connections are not maintained by providing the upper layer protocols an illusion of a permanent (home) IP address (as in the case of standard Mobile IPv6), but by defining a way to securely maintaining the connections even when the underlying addresses do (visibly) change. Even though this specification changes the semantics of TCP, UDP, AH, and ESP, it does NOT mandate any (or almost any) changes to the actual TCP or UDP implementations, and the applications (with some exceptions) will work unchanged. The need for changes in the IPSEC protocols, AH and ESP, depend on their implementation. In our estimate, most current IPSEC implementations could be used with this specification without any changes, but they would benefit from changes (see Section 2.4). Homeless Mobile IPv6 proposes three new Sub-Options. However, only one of these is crusial (the Security Sub-Option), and we think that it should be added even to the Standard Mobile IPv6. Homeless Mobile IPv6 it does not require any changes to IPv6 routers (other than support for standard Mobile IPv6 at the access routers, as defined in MIPv6 Sec. 7.1 and 7.2 of; see also MIPv6 Sec. 10.9). Homeless Mobile IPv6 relaxes some of the requirements of Mobile IPv6 specification by relying on more state and intelligence on the IP layer of the communicating end hosts. The basic assumption behind Homeless Mobile IPv6 is that there will be a large number of mobile IPv6 hosts that do not conceptually have any home network or home addresses. Some of these hosts may be client-only hosts, without any home agent kind of functionality, while others may rely on some other means of providing accessibility information, e.g., Dynamic DNS [RFC2136] or SIP [SIP]. Thus, instead of using a Binding Cache to bind a care-of-address to some (arbitrary) home address, Homeless Mobile IPv6 uses a Host Cache (see Sec. 2.1) that keeps up information about IP addresses that belong to a single host. The Host Cache allows the hosts to maintain transport and higher layer connections even if the IP addresses change. This document should be considered as an appendix to or variant of the Mobility Support in IPv6 [MIP6] specification, and read together with it. In the following, references to [MIP6] are expressed as "MIPv6, Sec N.N" 1.1. Applicability In principle, the implementation techniques suggested in this specification MAY be applied to any IPv6 protocol stack. This specification is NOT applicable to IPv4. Currently, this specification is purely EXPERIMENTAL in nature. 1.2. New and Renamed Architectural Entities Homeless Mobile host A mobile host that implements the Homeless Mobile IPv6 variant of the Mobile IPv6 protocol as specified in this document Homeless (supporting) Host (or just Homeless Host) A mobile or non-mobile host that implements the Homeless Mobile IPv6 variant of the Mobile IPv6 protocol. Standard Mobile Host A mobile host that does not implement the Homeless Mobile IPv6 variant of the Mobile IPv6 protocol but that is conformant with all of the Mobile IPv6 specification. Standard Host A mobile or non-mobile host that does not implement the Homeless Mobile IPv6 variant of the Mobile IPv6 protocol but that is conformant with the Mobile IPv6 specification, either all of MIPv6 or just the minimal host requirements as given in MIPv6 Sec 7.1. 1.3. Terminology Host Cache A cache maintained by all Homeless (supporting) Hosts. A Host Cache Entry contains a list of IP addresses that are known (or assumed) to belong to a single host or Host Personality. Host Cache Entry An entry in the Host Cache. A Host Cache Entry contains a number of IP addresses. There is a one-to-one mapping between known Host Cache Entries and Host Personalities (see below). Local Host Cache Entry A Host Cache Entry that contains IP addresses that are local to the host. A host MAY have several Local Host Cache Entries, e.g., to provide several Host Personalities or to differentiate between scoped domains. Foreign Host Cache Entry A Host Cache Entry that contains IP addresses that are not local to the host. For each remote host, or Host Personality, there MUST be only one Foreign Host Cache Entry. [Currently, a Foreign Host Cache Entry SHOULD contain only addresses that belong to a single scope and a single scoped domain, as the effects of mixing scoped addresses are unclear. TBD.] Host Personality A logical host identity. A single physical host may have several Host Personalities. In some cases, a cluster of physical hosts may be represented as a single Host Personality. However, this document does not specify any means or methods for how the members of such a cluster may need to co-ordinate their internal states in order to be able to provide such an appearance to the upper layer protocols. Host Personalities are NOT real entities, but purely imaginary objects, brought into life by creating Host Cache Entries and destroyed by Host Cache Entry timeouts. Usually (but not necessarily) there is a one-to-one mapping between Host Personalities and reapl physical hosts. Active Address An IP address (in a Host Cache Entry) which can be freely used. Active addresses may be used both for sending new packets and matching received packets. Tentative Address An IP address (in a Host Cache Entry) whose "ownership" status has not been cleared. See Sections 2.4.1. and 3.4.2. Deprecated Address An IP address (in a Host Cache Entry) which has expired. Activity-Related Lifetime IP address lifetime that depends on the last use of the address. An Activity-Related Lifetime specified that the address expires when it has been idle for a certain period of time. In this context, an address is idle if no packets are received with it as a source address. Absolute Expiration Time IP address lifetime that depends on wall clock. An Absolute Expieration Time specifies that the address expires at a specific point of time unless renewed. The address expires even if it is not idle. Anonymous Authentication Protocol (AAP) A lightweight and weak (or at least weaker than IKE) authentication protocol that can be used even in an environment where there is no infrastructure. See Section 2.4.3. Anonymous Security Association (Anonymous SA) An IPsec Security Association created as a result of running the Anonymous Authentication Protocol. 1.4. Protocol Overview In what follows, we present an overview of functions of the Host Cache in Homeless Hosts, followed by a figure illustrating the data structures that are typically needed to implement Homeless Mobile IPv6. Thereafter, we give an overview of how Mobile IPv6 Binding Updates are used to update the Host Cache, and outline the methods for sending and receiving arbitrary IP packets. Example packet flows are given in Appendix A. All Homeless (supporting) Hosts maintain a Host Cache. Basically, the Host Cache replaces and enhances the functionality provided by MIPv6 Binding Cache and Binding Update List. Packets transmitted by remote Mobile Hosts, either standard or homeless, may update entries in each Homeless Host's Host Cache. An entry in the Host Cache contains a list of IP addresses that are known (or assumed) to belong to a single host or Host Personality. An initial Host Cache Entry MAY be based on a DNS reply containing multiple A6 [RFC2874] or AAAA records [RFC1886]. As a host receives Binding Updates from its peer, it SHOULD add, update, and delete IP addresses in the Host Cache as specified in Sections 2.1 and 2.3. Individual IP addresses in the Host Cache expire as defined in Section 2.1.4. To prevent expiration of its IP addresses, stored in a host cache entry at its peers, a mobile host SHOULD periodically send to its peers packets containing Binding Updates. At the protocol level, there are two major differences from MIPv6: (1) Since the Homeless Host is considered not to have a home, it is always Away from Home (MIPv6 Sec 10.1, Sec 10.3). However, when communicating with another Homeless Host, neither Routing Headers nor Home Address Destination Options are needed. (2) There are three new Destination Option Sub-Options, Homeless Support Sub-Option, which MAY be sent in a Binding Request or a Binding Update, Alternate Prefixes Sub-Option, which MAY be sent in a Binding Update, and Security Challenge/Response Sub-Option, which MAY be sent in a Binding Acknowledgement or Binding Update. The main difference to the standard Mobile IPv6 implementation lies in the conceptual data structures needed for the implementation. That is, in a Homeless Host, TCP and UDP protocol control blocks (and possibly AH and ESP Security Associations) are not bound to single IP addresses but to Host Cache Entries. The difference is illustrated in Figure 1, below. It allows two communicating Homeless Hosts to independently select the source and destination IP addresses on packet bases, thereby allowing seamless handover and easy adaptation to local network conditions. +---------+ a local address, e.g., 3ffe:200:3000:0:a00:46ff:fe08:8b42 | TCP/UDP |/ | PCB / | local/| | foreign--- a foreign address, e.g., 3ffe:200:3000:0:a00:46ff:fe08:8b44 +---------+ Standard Host Protocol Control Block Bindings +--------------+- an addr, 3ffe:200:3000:0:a00:46ff:fe08:8b42 +---------+ | Local Host |- an addr, fe80::a00:46ff:fe08:8b42 | TCP/UDP |/| Cache Entry |- an addr, fe80::1 | PCB / +--------------+ | local/| | foreign---+--------------+ +---------+ | Foreign Host |- an addr, 3ffe:200:2070:0:a00:46ff:fe08:8b44 | Cache Entry |- an addr, 3ffe:200:3000:0:a00:46ff:fe08:8b44 +--------------+ Homeless Host Protocol Control Block Bindings Figure 1. Differences between Standard and Homeless Host Conceptual Kernel Data Structures Initially, a Local Host Cache Entry consists of (a subset of) the known local IP addresses. Correspondingly, a newly created Foreign Host Cache Entry consists either of the single address by which the host is known, or, OPTIONALLY, it MAY consist of several addresses as received by some other means, e.g., in a DNS reply. A Homeless (supporting) Host MAY, at any time, send Binding Updates to any other Homeless (supporting) Host, thereby attempting to modify the contents of the other host's Host Cache. The Binding Updates MUST be authenticated as specified in MIPv6, Sec 4.4. As a difference to the standard Mobile IPv6, the Binding Updates do not simply replace a single current Care-Of-Address (CoA), but may add, delete, or change entries in the corresponding Host Cache Entry. As in standard Mobile IPv6, the host sending Binding Updates MAY request the receiver to reply with Binding Acknowledgements, see MIPv6 Sec. 4.2. As an additional requirement, before accepting a new CoA as an Active Address, the receiving host MUST check that the peer host is actually reachable at it; see Sec 2.4.1. and 3.4.2. When sending packets to a Homeless (supporting) Host, the destination address for the packet MAY be freely selected among the Active Addresses in the Foreign Host Cache Entry. The selection MAY be performed separately for each packet. It is RECOMMENDED that the source address of the packet last received from the peer is used as the destination address of packets sent to the peer. Similarily, the source address for each packet MAY be individually selected among those in the Local Host Cache Entry as long as the rules specified in [ADDRSEL] are followed. Especially, the source address MUST be of the same scope as the destination address is. If the scope of the source address is smaller than the global scope, the sending host MUST know that the source and the destination addresses really belong to the same scoped domain. This specification does not offer any means to gain that kind of knowledge. It is necessary to be more strict when sending ICMP, ND, and other control packets. When sending packets, the Host Cache SHOULD NOT be used for ICMP or ND at all. When receiving packets from a Homeless (supporting) Host, each packet's destination address MUST be one of the addresses in a Local Host Cache Entry. In other words, when receiving a packet, a Homeless (supporting) Host makes sure that the unicast destination address belongs to at least one of its Local Host Cache Entries. [It is currently unspecified which Local Host Cache Entry the host should select if the destination address matches an address that is present in several Local Host Cache Entries. It looks like this selection should depend on both the interface through which the packet was received, and possibly also the matching Foreign Host Cache Entry. The real problem here is that we would like to eventually have all Host Cache Entries to carry addresses from several distinct scopes, and that always makes the global addresses to be included in several Local Host Cache Entries. TBD.] Similarily, in order to be accepted as a packet from a specific host, and thereby being part of a specific connection, the source address of the packet MAY be any of the Active or Deprecated Addresses in the corresponding Foreign Host Cache Entry. That is, the receiving host takes the source address of the received packet, looks for a Foreign Host Cache Entry in its host cache, and if a match is found, uses the Foreign Host Cache Entry to locate the specific protocol control block (pcb) representing the upper layer protocol connection (socket) the packet should be delivered to. A Tentative Address may be used to positively match a Host Cache Entry if and only if it contains a reachability Response as specified in Sec 3.4.2. If the source address does not match any Foreign Host Cache Entries in the Host Cache, the receiving host SHOULD NOT create a Foreign Host Cache Entry for the host until it has made sure that the host is actually reachable, and responds to packets sent to it (see Sec 4 to discuss the ramifications of the Host Cache and potential resource exhausting Denial-of-Service attacks). In such a case, a statically allocated Host Cache Entry MAY be used in order to match the packet against partially bound protocol control blocks. It is RECOMMENDED that the receiving host markes the last used source address of received packets in the corresponding Foreign Host Cache Entry, and uses it as the destination address of the next packet sent to the host. To maintain full backward compatibility, whenever a Homeless Host communicates with a host that does NOT support Homeless Mobile IPv6, standard Mobile IPv6 facilities must be used. This is specified in more detail in Sections 2.2. and 2.3. 2. Homeless Mobile IPv6 Functions 2.1. Maintaining Host Cache 2.1.1. Creating Host Cache Entries Local Host Cache Entries are only created through administrative actions. It is RECOMMENDED that each host, by default, creates a single default Local Host Cache Entry. It is also RECOMMENDED that this default Local Host Cache Entry contains all local IP addresses of the host, including the loopback address (::1) and Link Local loopback address (fe80::1). All addresses in the Local Host Cache Entry are permanent, i.e., they do not expire (unless, of course, the underlying IP addresses expire, e.g., since the prefix expires). Whenever a Homeless (supporting) Host decides to send a packet to a host that has no Host Cache Entry, it MAY create a new Foreign Host Cache Entry for the host. It is RECOMMENDED that if the upper layer protocol is a user data oriented protocol (e.g. TCP or UDP), and the sending host is initiating the connection, the corresponding Host Cache Entry is created; however, if the sending host is only responding to a connection request, or if the upper layer protocol is control oriented protocol (e.g. ICMP, ND), no Host Cache Entry is created. The case of IPSEC protocols, ESP and AH, are discussed later in Section 2.4. When a host decides to create a new Foreign Host Cache Entry, the new entry MUST, at minimum, contain one address. If the host has several addresses that are known to belong to a single Host Personality, the newly created Foreign Host Cache Entry MAY contain more than one address. All the addresses initially added to the Foreign Host Cache Entry MUST be temporary and have Activity-Related Lifetime, and SHOULD expire after they have been inactive for DEFAULT-LIFETIME seconds, unless there is some better information available, e.g., DNS caching time. [For the time being, it is RECOMMENDED that each Foreign Host Cache Entry contains addresses that belong only to a single scope, and within that scope to a single known scoped domain. TBD.] 2.1.2. Sending Binding Updates When a host creates a new Foreign Host Cache Entry as a result of receiving a packet and replying to it, it is RECOMMENDED that the host includes an Initial Binding Update (see Sec 3.2.1) in the first packet sent to the host. (This requires, naturally, that there is an AH SA between the hosts. See also Section 2.4). On the other hand, if a host creates a new Foreign Host Cache Entry as a result of sending a packet to a previously unknown host, it is RECOMMENDED that an Initial Binding Update is sent only after getting a reply from the host. In this case, if the remote host follows the recommendations of this specification, the reply from the remote host will contain an Initial Binding Update, which, in turn, may be used to trigger sending an Initial Binding Update back. The Initial Binding Update SHOULD include all those addresses of the sending host that have the same scope and belong to the same scoped domain than the packet destination address, including the address used as the source address of the packet. The Initial Binding Update SHOULD also include a request for a Binding Acknowledgement. The Initial Binding Update MUST be sent in a way that is compatible with standard Mobile IPv6. The exact packet format is specified in Sec. 3.2.1. Whenever a host learns a new local IP address, e.g., due to physical discovery of a new network, or through neighbor discovery, it SHOULD include a Consequtive Binding Update (see Sec. 3.2.2) in the next packets sent to such hosts in the Host Cache that belong to the same scope and scoped domain as the newly discovered address. [If the host has several Local Host Cache Entries, the situation is apparently not that simple. TBD.] Additionally, the host MAY have a timer so that it will send a Binding Update anyway, after a configurable timeout, in the case there is currently no active traffic between the hosts. Whenever a host learns that it has lost a local IP address, e.g., due to having lost radio connectivity, it MUST send a deleting Binding Update to its peers, i.e., a Binding Update with zero lifetime, thereby removing the address from their Host Cache Entries. Additionally, it MAY establish forwarding from the lost address, as defined in MIPv6 Sec. 10.9. Naturally, if the lost address was the last address, the host cannot send Binding Updates or establish forwarding. However, even in such a case the host SHOULD follow its Foreign Host Cache Entries, deleting addresses as their expire, and assume that its peers will delete addresses from their Foreign Host Cache Entries as they expire. 2.1.3. Adding Addresses to Host Cache Entries Whenever a host learns a new local IP address, e.g., due to physical discovery of a new network, or through neighbor discovery, it MUST add it to (at least one of) the Local Host Cache Entry. If the local address has natural lifetime, the lifetime in the Host Cache SHOULD reflect this lifetime. Whenever a host receives a packet with a Binding Update, and it has a Foreign Host Cache Entry that matches with either the source address of the packet, or the home address in the packet if the Home Address Destination Option is present, the receiving host SHOULD update its Host Cache, as specified in Sec. 2.3. 2.1.4. Removing Addresses from Host Cache Entries All addresses in a Foreign Host Cache Entry have a defined lifetime. Basically, the host sending a Binding Update SHOULD determine the lifetime for the addresses as defined in MIPv6 Sec 10.8. That is, the lifetime of those kinds of addresses is given as Absolute Expiration Time, i.e., the addresses expire independent of whether they are in active use or not, unless the are explicitly renewed through a Binding Update. As specified in MIPv6 Sec 5.1 and 8.2, a host MAY remove entries from its peers' Host Cache by sending a Binding Update that has a zero lifetime. Addresses that are entered to a Foreign Host Cache Entry through other means than as a result of processing a received Binding Update SHOULD have a Activity-Related Lifetime of DEFAULT-LIFETIME seconds, unless there is better information about the lifetime through some other means, e.g., DNS. That is, in the default case, the addresses expire when they have not been used for DEFAULT-LIFETIME seconds. If, after entering an address to the Host Cache through some other means than through a Binding Update, and a Binding Update is later received for that address, the lifetime of the address MUST be changed to have an Absolute Expiration Time with the lifetime given in the Binding Update. Whenever an address expires, it MAY be removed from the Host Cache Entry. However, it is RECOMMENDED that the address is kept (as an deprecated address) for some time, to make it easier to react if the address is still used. An deprecated address MUST NOT be kept in the Host Cache for longer than MAXIMUM-EXPIRED-LIFETIME seconds. 2.1.5. Removing Host Cache Entries When the last address in a Host Cache Entry expires, as specified in Sec. 2.1.4., the host MAY remove the Host Cache Entry. However, it is RECOMMENDED that the Host Cache Entry is only removed when the last deprecated address is removed and all open connections referring to the Host Cache Entry are closed. 2.2. Sending Packets When a Homeless (supporting) Host sends a packet, the amount of information about the destination host may differ. Basically, there are four alternatives: - the destination host is known to be a Homeless (supporting) Host; there is no difference whether it is a Homeless Mobile Host or a non-mobile Homeless (supporting) Host. - the destination host is known to be a Standard Mobile Host - the destination host is known to be a Standard non-mobile Host - the status of the destination host is not known (See Appendix D) In some cases, it is possible that the host wants to send a packet using a Foreign Host Cache Entry where all the addresses are deprecated. Currently, it is RECOMMENDED that in such a case the IP layer behaves as if there was an ICMP Destination Unreachable received. 2.2.1. Sending Packets to a Homeless (supporting) Hosts When a Homeless (supporting) Host sends a packet to another Homeless (supporting) Host, it may freely select the destination address from the Active Addresses included in the Foreign Host Cache Entry. Additionally, it may freely select the source address from the addresses in the associated Local Host Cache Entry, as long as the selected source address matches the scope and the scoped domain of the selected destination address as defined in [ADDRSEL]. If the sending host has learned any new local IP addresses since it has last sent a packet to the destination host, it SHOULD include a Binding Update adding the address to the Foreign Host Cache Entry in the destination host (as specified in Section 2.1.2.), or use the technique described in Appendix B. In both cases the packet MUST be protected with AH. If the sending host wants to use, as the source address of the packet, a new local IP address that has not yet been sent in a Binding Update to the remote host, it can do it in either one of the following ways. - It MUST include both a Home Address Destination Option containing one of the previously registered addresses, and a Binding Update registering the new source address. The Binding Update SHOULD contain a lifetime that is greater than zero, and it SHOULD have the A-bit (request for Binding Acknowledgement) set. The packet MUST be protected with AH. - It can use the Binding Update optimization technique described in Appendix B. If the sending host has lost any local IP addresses since it has last sent a packet to the destination host, it MUST include a Binding Update removing the IP address from the destination host's Host Cache, and the Binding Update SHOULD have the A-bit (request for Binding Acknowledgement) set. The packet MUST be protected with AH. Additionally, it MAY establish forwarding from the lost address, as defined in MIPv6 Sec. 10.9. If the newly lost address is the address which was used as the source address when the previous packet was sent to the correspondent host, the Binding Update SHOULD be sent immediately to remove the lost address. It is important to note here that no Routing Extensions or Home Address Destination Options are needed in the communication between two Homeless (supporting) Hosts. This means that the average IPv6 header size is just 40 bytes of IP header instead of 40+28+24 bytes of IP header + Routing header + Destination Option header. 2.2.2. Sending Packets to Standard Mobile Hosts When a Homeless (supporting) Host sends a packet to a Standard Mobile Host, there are basically two cases. If the Standard Mobile Host is at its home network, the case is identical to the Sending Packets to a Standard Host case, and specified in the next Section. When a Homeless (supporting) Host sends packets to a Standard Mobile Host which is Away from Home (MIPv6 Sec 10.1, Sec 10.3), the sending host MUST include a Routing header as specified in MIPv6 Sec 8.9. Furthermore, the Homeless (supporting) Host must provide an illusion of having a Home Address to the Standard Mobile Host. That is, if the Homeless (supporting) Host decides to use another source IP address than the one the Standard Mobile Host assumes to be the Homeless (supporting) Host's Home Address, the sending host MUST include a Home Address Destination Option to the outgoing packet, and additionally MUST keep sending Binding Updates until a Binding Acknowledgement is received. If a Binding Update is included, the packet MUST be protected with AH. It is RECOMMENDED that the illusion of being a Standard Mobile Host is provided on a connection-by-connection basis, since a connection-by-connection based solution provides potentially smaller average header size. That is, it is RECOMMENDED that whenever opening a new connection with an already known Standard Mobile Host, the Homeless Mobile Host selects the source address used in the connection independent on the source address used in other connections with the same host. In this way, there is high probability that the new connection will not need Home Address Destination Options even if some of the existing connections do need. A suggested way to implement the Mobile IPv6 compatible functionality for destination addresses is to mark one of the addresses in the Foreign Host Cache Entry of a Standard Mobile Host as a Home Address, and another address as the current Care-of-Address. The existense of an address marked as a Care-of-Address forces the destination address selection to select the CoA as the destination address. The existense of an address marked as a Home Address signals the packet output routine to include a Routing header containing the Home Address. A suggested way to implement the Mobile IPv6 compatible functionality for source addresses is to record in the protocol control blocks a pointer to a data structure that contains the following information: - the initially selected source address, i.e., emulated Home Address - the currently used source address, i.e., emulated Care-of-Address This data structure may be shared between all protocol control blocks that have the same initially selected source address. When sending a packet, the sending host compares the selected source address to the initially selected source address. If they are equal, no further processing is needed. If they differ, a Home Address Destination Option needs to be included in the packet. In addition to including the Home Address Destination Option, the sending host compares the selected source address to the emulated Care-of-Address. If they do not match, a Binding Update Destination Option must be included in addition to the Home Address Destination Option. 2.2.3. Sending Packets to Standard Hosts When sending packets to a Standard non-mobile Host (or to a Standard Mobile Host currently At Home), the Foreign Host Cache Entry contains only one non-expired address. This address is THE address of the Standard host, or the home address of the Standard Mobile Host. In this case, the Homeless (supporting) Host MUST emulate a Standard Mobile Host in order to support application portability. That is, whenever the Homeless (supporting) host wants to use a local address different from the initial source address, it MUST include a Home Address Destination Option, and include Binding Update Destination Options until a Binding Acknowledgement is received, as defined above in the previous Section. 2.2.4. Sending Packets to hosts with unknown capabilities When sending packets to a new host whose capabilities are not known, the sending host MAY send an Initial Binding Update whose purpose is twofold: - to inform the receiving host that the sending host is a Homeless (supporting) Host, and - to trigger a similar Binding Update from the receiving host in the case it is a Homeless (supporting) host. This must be made in a way that is compatible with standard Mobile IPv6. The format of the Initial Binding Update is defined in Section 3.2.1. 2.3. Receiving Packets When a Homeless (supporting) Host receives a packet, the amount of information about the source host may differ. Basically, there are four alternatives: - the source host is known to be a Homeless (supporting) Host since there is an existing Foreign Host Cache Entry that contains the source address in the packet and the host has indicated its support for Homeless Mobile IPv6; there is no difference whether it is a Homeless Mobile Host or a non-mobile Homeless (supporting) Host. - the source host is known to be a Standard Mobile Host since there is an existing Foreign Host Cache Entry that contains the source address in the packet, the host has not indicated to support Homeless Mobile IPv6, but it has sent either Home Address Destination Options or Binding Updates. - the source host is either a Standard Host or a Standard Mobile Host; there is an existing Foreign Host Cache Entry that contains the source address in the packet, the host is known not to support Homeless Mobile IPv6, and the host has not (yet) sent Home Address Destination Options or Binding Updates. - there is no Foreign Host Cache Entries that would match the source address of the packet. 2.3.1. Receiving packets from other Homeless Hosts When a Homeless (supporting) Host receives a packet from another, already known Homeless (supporting) Host, the source address (or the address in the Home Address Destination Option) matches to a Foreign Host Cache Entry that denotes that the sending host is a Homeless (supporting) Host. If the packet contains a Home Address Destination Option, it MUST also contain a Binding Update, the packet MUST be protected with AH, and the Binding Update SHOULD contain a lifetime that is greater than zero. In such a case, the receiving host SHOULD add the addresses specified in the Binding Update to the Foreign Host Cache Entry. That is, since the packet contains a Home Address Destination Option, the source address of the packet is usually the one added to the Foreign Host Cache Entry. All the addresses MUST be added as Tentative Addresses, and verified as specified in Sec 3.4.2. Any received packet MAY contain a Binding Update. If the packet contains a Binding Update, it MUST be protected with AH. When processing the Binding Update, the receiving host SHOULD add address(es) to or delete address(es) from the Foreign Host Cache Entry, as specified by the Binding Update. When adding addresses, they MUST be added as Tentative Addresses and verified, as specified in Sec 3.4.2, before their status can be changed to Active. 2.3.2. Receiving packets from Standard Mobile Hosts Packets that are received from a Standard Mobile Host can be divided into two categories: - The correspondent node is away from home. - The correspondent node is at its home network. When a packet is received from a Standard Mobile Host that is away from home, the packet includes a Home Address Option. The packet SHOULD be matched to a Foreign Host Cache Entry using the address received in the Home Address Option. Packets received from a Standard Mobile Host that do not include the Home Address Destination Option are handled as if they were received from a Standard Host (Sec 2.3.3). When a packet containing a Binding Update is received from a Standard Mobile Host, the address received in the Binding Update SHOULD be marked as the current Care-of-Address of the correspondent host as specified in Sec 2.2.2. The Binding Update must be protected with AH. 2.3.3. Receiving packets from Standard Hosts When receiving packets from a host that is supposed to be a non-mobile Standard Host, the packet is typically a standard IP packet without any Home Address Destination Options or Binding Update Destination Options. In this case, the packet is handled normally, and the associated protocol control block is found through the associated Foreign Host Cache Entry as specified above. However, since Standard Mobile Hosts do not need to announce their ability to be transferred away from Home, it is possible that a packet contains a Home Address Destination Option or a Binding Update. In such a case, the status of the foreign host SHOULD be changed into a Standard Mobile Host, and the packet SHOULD be handled as specified in Sec 2.3.2. 2.3.4. Receiving packets from hosts that do not have any corresponding Foreign Host Cache Entry When receiving packets from a host that does not have any corresponding Foreign Host Cache Entry, the receiving host SHOULD NOT create any new Foreign Host Cache Entry upon packet arrival. Instead, the algorithms MAY either use the address directly to determine a possibly existing wildcard protocol control block, or use a statically allocated Foreign Host Cache Entry which is used only for such received packets. (See also Sec. 4.1 where we discuss potential Denial-of-Service attacks.) 2.4. Security As discussed above in Sections 2.2.1 and 2.3.1., two Homeless (supporting) Hosts MAY use several different IP addresses as the source and destination address in the packets flowing between them (as long as the addresses have the same scope and belong to the same scoped domain). As already mentioned, this behaviour changes the semantics of a number of upper layer protocols, including TCP and UDP on one hand (as discussed above), and possibly also IPSEC AH and ESP on the other hand. Specifically, the method for finding the correct protocol control block for each received packet MUST be changed, and the method for finding the correct Security Association for each received packet MAY be changed, too. The latter issue is discussed in Section 2.4.1, below. As a related security measure, all Binding Updates and Binding Acknowledgements used in Homeless Mobile IPv6 MUST carry valid AH headers. The purpose of this requirement is to prevent malicious mobile or non-mobile hosts from changing addressing information related to other Homeless Hosts or Standard Mobile Hosts. Unfortunately, as we point out in Section 2.4.1, just relying on AH is not enough. The new approach highlights and worsens a potential security problem already present in the current Mobile IPv6 specification. To protect from address stealing [OWNERSHIP], all addresses added to a Host Cache Entry must be verified as specified in Sec 2.4.1 and 3.4.2. As a related measure, using IKE to negotiate IPsec SAs may be too heavy for the purposes of just protecting Binding Updates. The situation is discussed in Section 2.4.2, and an alternative solution is outlined in Section 2.4.3. 2.4.1. Using Security Associations and Accepting New Addresses As specified in IP Security Architecture [RFC2401] Section 5.2.1, the standard method for determining the correct IPSEC SA for a received packet is to use the packet destination address, IPSEC Protocol type, and the Security Parameter Index (SPI) fields to look up the SA. Because Homeless hosts may use several addresses, it is natural allow any of the local addresses to be used to look up the SA. That is, in the Homeless Mobile IPv6 the SA is not bound to a single address, or to a predefined set of addresses, but to a changing set of addresses. In practice, all the addresses in a Local Host Cache Entry are equally acceptable. It must be noted that such a usage may be considered as a slight deviation from the IP Security Architecture [RFC2401]. The SAs are still associated with the destination addresses, but the set of destination addresses an SA is valid for may dynamically change. That is, when a host learns a new address, it starts to accept a new SPI/destination address combination as a lookup key for the existing SA. Similarily, at the sending end, when the recipient tells that it has learned a new address, the sender adds the address as one that the SA may be used with. According to RFC2401, such a change can be only accomplished through administrative actions, and possibly requires an IKE negotiation. In the case of Homeless Mobile IPv6, the case may be a side effect of adding a new address into a Host Cache Entry, depending on implementation. However, we do not consider this behavior as a problem per se. We don't see any security implications at the receiver end. Instead, there is a problem at the sender. If the sender blindly accepts a new address to a Foreign Host Cache Entry, a malicious node can easily divert traffic meant to some other party to itself. (For a specific attack skenario, see Appendix C.) To prevent this, new addresses sent by a Homeless Mobile Host MUST first be considered as Tentative. Only when the actual reachability of the address has been checked as defined in Sec 3.4.2, it may be changed into an Active Address. [At this writing we do not define a policy when such a checking should be made. It may be made immediately when the new address is learned, when the first packet using the new address is received, or at other point of time.] To make the behaviour explicit, we specify as follows. For incoming packets, a host SHOULD accept any IP address in a Local Host Cache Entry together with a valid SPI. That is, instead of having possibly different SPIs for each local IP address, a host does not care which of its local unicast IP addresses an incoming IPSEC protected packet carries as long as the SPI is a valid one, and the packet can be validated. For outgoing packets, a host SHOULD create a dynamic IPSEC policy entry that maps outgoing IP addresses to SAs based on the Active Addresses in the Host Cache. That is, when selecting which SA to use for protecting an outgoing packet, as defined in [RFC2401] in Section 5.1.1. item 2., the host SHOULD compare the destination address against the Active Addresses in the Foreign Host Cache Entries, and use this information for selecting the right SA. However, the host MUST NOT use any of the Tentative Addresses for this purpose, and it SHOULD NOT use any of the Deprecated Addresses either. 2.4.2. Using Less Secure AH SAs It is REQUIRED that all Binding Updates and Binding Acknowledgements are protected with AH. This means that a remote Homeless Mobile Host cannot update the corresponding Foreign Host Cache Entry at its peers until there is a valid AH Security Association between the hosts. Consequently, typically one of the first application protocols exchanged between two hosts is IKE, which is used to create the IPSEC AH SA. Unfortunately IKE is quite heavy a protocol, and requires external knowledge which may not be available. However, depending on the situation, it may be sufficient to create the AH SA in some less secure means, e.g., through a so called Anonymous Authentication Protocol specified in Section 2.4.3, below. Furthermore, in order to simplify the management of the specific AH SA that is used for protecting Binding Updates, it is RECOMMENDED that the specific AH SA is directly associated with the Host Cache Entry, and whenever sending Binding Updates, the associated Foreign Host Cache Entry is directly used to select the SA. This method assures that future Binding Updates sent to the denoted host will automatically get protected with the right SA. It should be noted, however that it MAY be necessary to have some other AH SA to protect traffic for other purposes than authenticating Binding Updates. 2.4.3. Anonymous Authentication Sometimes there is no other need for IPSEC (or AH) between a specific pair of hosts other than protecting future Binding Updates. That is, two hosts may learn about each other through some insecure means, e.g., as a result of a mobile host browsing a web site, and continue to talk to each other as either one or both of the hosts move. In such case it may well be that all the information the hosts know about each other is their ability to communicate using specific IP addresses. Thus, there are no external credentials for creating AH SA, e.g., through performing an IKE authentication. For these kinds of situations, there is clearly a need for a protocol with the following properties. 1) The protocol is lightweight, requiring no heavy cryptographic operations. 2) As a result of running the protocols, the hosts know with _reasonably_ high confidence that they have a common secret that no other host knows. In other words, host A knows that there is some host B, which is currently able to use a specific IP address, and that B knows the same secret value which A knows, and no-one else knows that particular secret (unless, of course A or B themselves have leaked it). That is, we mainly seek for protection against passive attackers, since an active attacker would easily play at B's address. We denote such an protocol as an "Anonymous Authentication Protocol" (AAP), and any SA created through the protocol as an Anonymous SA. Some more specific requirements for the protocol are given at [Nikander2001]. The exact protocol is beyond the scop of this specification, and currently still to be defined. If an AAP is used to create an IPSEC AH SA to protect Binding Updates, the resulting Anonymous AH SA MUST NOT be used for any purposes that require strong (identity based) authentication. That is, the Anonymous AH SA does not authenticate anything else but that such connections which were initiated after the authentication was performed will keep connected to the same host even if one or both of the connected hosts move and change their IP addresses. 3. Protocol Details This section defines the protocol details, including new Destination Option Sub-Options, giving the details of the Binding Update packet formats, and discussing the details of security and the use of AH. 3.1. New Destination Option Sub-Options Three new Binding Update Destination Option Sub-Options are defined. The Homeless Support Sub-Option SHOULD be included in the first Binding Update sent to a host whose capabilities are unknown, or that is believed not to know that the sending host does support Homeless Mobile IPv6. That is, it SHOULD be included in the Binding Updates sent to a host until the first Binding Acknowledgement is received from the host. The Alternate Prefixes Sub-Option MAY be included in any Binding Update, but it MUST NOT be expected that the receiving host understands it unless it is known that the receiving host does support Homeless Mobile IPv6. The Security Challenge/Response Sub-Option is used to check that a remote host is really reachable through a new address it is giving. The purpose of this Sub-Option is to prohibit address stealing attacks. The general format of suboptions is defined in MIPv6 Sec 5.5. 3.1.1. Homeless Support Sub-Option Homeless Support Sub-Option (alignment requirement: none) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Homeless Support Sub-Option is used in a Binding Update or Binding Request to indicate that the sending host supports Homeless Mobile IPv6. 3.1.2. Alternate Prefixes Sub-Option Alternate Prefixes Sub-Option (alignment requirement: 4n+1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Sub-Option Len|PL |PrefixCount| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alternate Prefix #1 | . . . . . . | Alternate Prefix #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Alternate Prefixes MAY be used in a Binding Update to indicate that there are several alternative addresses that differ only in their prefix. A prefix may have a length of 4, 8, 12, or 16 bytes. Prefix length of 16 bytes can be used to signal alternate addresses that are completely different, i.e., that do not have any common suffix. More typically, however, would be to use 8 byte prefixes, i.e., having different routing prefixes but identical host IDs. The suffix shared by all prefixes is defined as follows. If there is an Alternatate Care-Of-Address Sub-Option in the Binding Update Destination Option that preceeds this Alternate Prefixes Sub-Option, the suffix is copied from the Alternate Care-Of-Address Sub-Option. If there are several preceeding Alt CoA Sub-Options, the suffix is copied from the one that is closed to this Alt Prefix Sub-Option. Otherwise, the suffix is copied from the packet source address. A single Binding Update MAY carry several Alternate Prefix Sub-Options. Sub-Option Length As defined in MIPv6, Sec. 5.5. For the Alternate Prefix Sub-Option, the following equation MUST hold. Sub-Option Length == 1 + ((1 << (2 * (PL + 1))) * Prefix Count) PL 2-bit prefix length. 00 - the precixes are 4 bytes long 01 - the prefixes are 8 bytes long 10 - the prefixes are 12 bytes long 11 - the prefixes are 16 bytes long i.e., the prefix length is (1 << (2 * (PL + 1))) Prefix Count 6-bit unsigned integer, giving the number of prefixes in this Sub-Option. The Maximum number of Alternate Prefixes is limited by the Maximum length of the Sub-Option, i.e., 255 bytes, yielding 63, 31, 21 or 15 prefixes, for the corresponding lengths of 4, 8, 12, and 16 bytes. Alternate Prefix #k An alternate prefix, either 4, 8, 12, or 16 bytes long. There MUST be exactly Prefix Count Alternate Prefixes in the Sub-Option. 3.1.3. Security Challenge/Response Sub-Option Security Challenge/Response Sub-Option (alignment requirement: 4n+2) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Sub-Option Len| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Challenge / | | Response | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As specified in Section 3.4.2, the Security Challenge/Response Sub-Option is used to verify the reachability of hosts so that Tentative Addresses can be securely upgraded to Active Addresses. Sub-Option Length As defined in MIPv6, Sec. 5.5. For the Security Challenge/REsponse Sub-Option, the length is always 16. Challenge/Response 128 bits of a hash code as defined in Section 3.4.2. 3.2. Packet formats This section details the formats for Binding Updates sent by a Homeless (supporting) Host. 3.2.1. Initial Binding Update An Initial Binding Update is sent to a host whose capabilities are unknown. Thus, it must be fully compatible with MIPv6, but, at the same time inform the receiving host about the sending host's capabilities. MIPv6 states the following (MIPv6, Sec 5.1.): Any packet that includes a Binding Update option MUST also include a Home Address option. The home address of the mobile node in the binding given in the Binding Update option is indicated by the Home Address field in the Home Address option in the packet. .... If the care-of-address for the binding (specified either in an Alternate Care-of-Address Sub-Option in the Binding Update option, if present, or in the Source Address field in the packet's IPv6 header) is equal to the home address of the mobile node, the Binding Update option indicates that any existing binding for the mobile node MUST be deleted. and (MIPv6, Sec. 5.5) ... any of the Mobile IPv6 destination options defined in this document MAY include one or more sub-options. .... Sub-Option Type 8-bit identifier of the type of sub-option. In processing a Mobile IPv6 destination option containing a sub-option for which the Sub-Option Type value is not recognized by the receiver, the receiver SHOULD quietly ignore and skip over the sub-option, correctly handling any remaining sub-options in the option. Given these provisions, it seems safe to send an initial packet that - includes a Home Address Destination Option with the Home Address equaling to the source address in the packet, - includes a Binding Update Destination Option that MUST first carry a Homeless Support Sub-Option, and after that MAY carry one or more Alternate Prefix Sub-Options that enumerate the other IP addresses the host wants to indicate. According to the MIPv6 specification, a Standard Mobile Host SHOULD treat this as a request to delete a non-existing binding in the Binding Cache, i.e., as a non-op. A Homeless (supporting) Host, instead, would recognize the packet as indicating support for Homeless Mobile IPv6, and will also directly learn the the other addresses that the peer wants to publish. 3.2.2. Consecutive Binding Updates sent to Homeless Hosts When sending Binding Updates to a host that is known to support Homeless Mobile IPv6, the following relaxations MAY be applied in comparison to the MIPv6 specification: Any packet that includes a Binding Update NEED NOT to include a Home Address option, if the source address of the packet is already known to the receiver. (cf. MIPv6 Sec 5.1, Sec 8.2) A packet MAY include several Binding Updates. This may be useful, for example, for including different IP addresses with different lifetimes. If there are several Binding Updates within a single packet, they MUST all have increasing Sequence Numbers. [MIPv6 does not seem to prohibit this, but this kind of usage is not necessarily useful for MIPv6 hosts.] A packet MAY include several Binding Acknowledgements. This may be used to acknowledge several Binding Updates, received either in one packet or along several packets. [Again, MIPv6 does not seem to prohibit this.] As a shorthand, all Binding Updates within a single packet MAY be positively acknowledged with a single Binding Acknowledgement whose Sequence Number is equal to the highest Sequence Number in the packet that contained the Binding Updates. Any Binding Update MAY carry more than one Alternate Care-Of-Address and Alternate Prefix Sub-Options. 3.2.3. Consecutive Binding Updates sent to Standard Hosts When sending Binding Updates to a host that is known not to support Homeless Mobile IPv6, the options must be strictly formatted according to MIPv6 specification. 3.3. Protocol Parameters The following parameters shall be set by network management. The values listed here are for information only. DEFAULT-LIFETIME 600 seconds MAXIMUM-EXPIRED-LIFETIME 1800 seconds 3.4. Security For the purposes of Homeless Mobile IPv6, there is basically only one security goal: to make sure that connections remain to be connected to the original hosts even if one or both of the hosts move. As was already mentioned in Section 2.4.3, it MAY NOT be necessary to know whom a connection was originally created with. In other words, the goal is make sure that Host Personalities remain integral. Homeless Mobile IPv6 does not have any specific confidentiality goals. The worst skenario that we have been able to find so far is an address stealing skenario (see Appendix C), where a malicious node claims to be at someone else's address, and move from there to its real address. In that skenario, all the traffic destined to the other host would be sent to the malicious node. Fortunately, a single challenge-response protocol will fix that problem. The details are defined in Section 3.4.2. Additionally, it MUST be realized that the integrity goals of Homeless Mobile IPv6 are typically much weaker than other typical integrity goals are. Homeless Mobile IPv6 is only interested in making sure that the communicating parties remain the same throughout the communication, and that a malicious communicating party cannot claim to use addresses that it actually cannot use. The realization of the relative weakness of the requirements leads to classification of AH Security Associations, as discussed in Section 3.4.1., below. 3.4.1. Classification of AH Security Associations Basically, from the point of view of Homeless Mobile IPv6, there are two types of AH Security Associations: - Generic (or application specific) host-to-host AH Security Associations, which MAY be used for other purposes than authenticating Binding Updates and Binding Acknowledgements, too. - Anonymous host-to-host AH Security Associations, which SHOULD NOT be used for any other purpose but authenticating Binding Updates and Binding Acknowledegements. Typically, generic host-to-host AH SAs are created either through manual configuration or through some high level protocol, such as IKE. On the other hand, Anonymous host-to-host AH SAs are typically created through an Anonymous Authentication protocol (see Section 2.4.3). In order to be secure, a Homeless Mobile IPv6 implementation MUST be able to make a distinction between these two types of associations. In particular, it MUST make sure that Anonymous SAs are used only for securing BUs and BAs, and not for application security. The reachability verification mechanism (described in Section 3.4.2, next), takes care of preventing address stealing. 3.4.2. Verifying reachability When a Homeless Host receives a Binding Update requesting that a new IP address is added to a Foreign Host Cache Entry, it MUST first add that address as a Tentative Address only. In particular, it MUST NOT assume that the address necessarily belongs to the peer host claiming to own it. If some other host requests to have the same address, the host SHOULD use local security policy to decide what to do. It is RECOMMENDED that the host runs the reachability verification protocol against both of the claimants, and believes the one that checks OK. If both of them check ok, it is RECOMMENDED that the node completely flushes the Host Cache Entries for both claimants. In order to raise the status of a Tentative Address into an Active Address, a Homeless Host SHOULD run the following reachability verification protocol. 1. Using the SA that protected the received BU, the verifying node creates a challenge and sents it to the address being checked. It is important that the challenge is actually sent to the Tentative Address and not to any other of the addresses in the Foreign Host Cache Entry. 2. When the peer node receives the Challenge, it constructs a corresponding Response and sents it back to the verifying node. The destination address of the Response SHOULD be the source address in the Challenge, but it MAY be any of the other addresses in the Foreign Host Cache Entry that represents the verifying node at the peer host. The source address of the Response may be freely selected as long at it follows the rules specified elsewhere in this specification. 3. When the verifying node receives and positively verifies the Response, it SHOULD raise the status of the address to an Active Address. It is important to realize that the protocol only checks that there is a node that is able to receive packets sent to the address being checked and that knows the keying material associated with the SA. Thus, since the peer nodes are assumed not to reveal their keying material, the node is assumed to be the same node that sent the original BU. The Challenge is created as follows. K_MAT = the authentication keying material associated with the SA HMAC = the keyed hashing algorithm used in the SA ADDR = the IPv6 address whose reachability is being checked TIME = the current time or a nonce in a host specific format Challenge = HMAC(K_MAT, ADDR | TIME) The Response is created as follows. Reply = HMAC(K_MAT, Challenge | ADDR) The Challenge is sent in the Challenge/Response field of a Security Challenge/Response Sub-Option, included in a Binding Acknowledgement. The Response is sent in the Challenge/Response field of a Security Challenge/Response Sub-Option, included in a simple Binding Update that MUST NOT contain anything else but a simple binding repeating the address being checked. That is, if the source address contained the address to be checked, the Binding Update would consists of the the actual BU and a Security Challenge/Response Sub-Option. On the other hand, if the source address was different, the BU would contain both Alternate CoA and Security Challenge/Response Sub-Options. It should be noted that the above defined protocol is actually slight overkill. Since the BA and BU must be protected with the SA anyway, the protocol protects the Challenge and Response twice. Thus, this part of the specification is likely to be revised in a future version. 4. Security and Privacy Considerations [This section is still not ready, and needs some work. However, it is much better than it was in the -00.txt version.] In a way, Homeless Mobile IPv6 loosens up security assumptions about IP addresses. However, to us it seems like this is an intrinsic property of host mobility. We believe that the same security problems, including the address ownership problem, are present already in the current Mobile IPv6 solution. However, since the presented solution "enhances" mobility by allowing a host to be "present" simultaneous at several topological locations, the security problems look worse. In this section, we summarize the security and privacy concerns. First, in Section 4.1., we discuss potential Denial-of-Service attacks. Section 4.2. briefly covers the address ownership problem in the context of Binding Updates. Finally, Section 4.3. briefly mentions some privacy problems. The proposed solutions are presented throughout this document, but especially in sections 2.4 and 3.4, above. 4.1. Potential Denial-of-Service Attacks The Host Cache introduces an entirely new data structure into the kernel. As state must be created into the Host Cache based on information provided by other hosts, a potential Denial-of- Service vulnerability is created. Ways of reducing the vulnerability of implementations may include creating Host Cache Entries only when absolutely necessary, that is, when the first AH protected Binding Update is received from the correspondent host. Here, the presens of AH protection can be considered as a relative security agains DoS, since creating SAs is expensive compared to just sending packets. Another potential DoS vulnerability is present in IPsec itself. It is likely that sometime in the future it will be possible to automatically create SAs with any host. It is unrealistic to assume that all of these hosts would be trustworthy. Thus, it will be possible to make other hosts to burne large amounts of CPU by making them to decrypt and check garbage. Fortunately, such attack requires some effort from the side of the attacker, since it needs first to establish the SA. Even further, such attacks are not caused or directly affected by Homeless Mobile IPv6; we just mention this attack here in order to put the other potential DoS attacks into a proper context. 4.2. Address ownership and Binding Updates A Binding Update allows a remote host to effectively change the routing table of the local host. Such a mechanism is an effective impersonation, man-in-the-middle, and denial-of-service attack tool. For this reason, MIPv6 requires that all BUs must be protected with AH. In addition to being simply protected with AH, there must be some mechanism that makes sure that the sender of the BU is indeed authorized to change the routing information for the address given in the BU. In the case of standard MIPv6, routing information is only changed for the home address, and therefore it is sufficient to be authorized to change routing information for it. However, in the case of Homeless Mobile IPv6, all the addresses in a Host Cache Entry are equal. Therefore, it is equally important to check that the remote host is authorized for all of the addresses. Currently, there are no existing PKI or other infrastructure that would provide the needed information, and it is doubtful whether there will ever be. Therefore, we have selected a simplistic approach. The recipient of the BU checks that the sender is indeed reachable through the address to be added to the Host Cache Entry. If the sender is reachable, i.e., if it can read packets sent to that address, it is assumed to be authorized to modify routing information for that address. The reasoning goes as follows. If a host is able to act as if it is at address A, then it is either actually at address A, or it is able to eavesdrop all traffic that is sent from the current address to address A. If there is no other host at address A, we can't do much since we cannot effectively make a distinction between a host genuinely at that location and a malicious host eavesdropping all traffic sent to that location. On the other hand, if there is another host at address A, there two more possibilies. First, it is possible that the eavesdropper is also able to block traffic. In that case, again, there isn't much we can do. However, if the eavesdropper cannot block traffic, then also the "real" host at A receives packets sent to A. In that case, the "real" host at A can send error messages indicating that it is getting unsolicited challenges. However, no such mechanism has been specified (yet), and we are still trying to figure out the value of such messages. [TBD] One further condition must still be considered. Let us consider a situation where initially the host at address A is absent, and then comes back at some later point of time. This case is more tricky, since by the time the "real" host comes back, there is already an authenticated binding directing all traffic sent to it to somewhere else. Fortunately, even this kind of attack, like the ones above, require that the attacker can eavesdrop the traffic at least when the attack is initiated. This limits the number of potential attackers considerably. The other aspects of this skenario are being studied. [TBD] Thus, by the argument above, a host that is able to reply to packets sent to a specific address is also able to otherwise divert traffic sent to the address, at least in the case that we receive no notifications about unsolicited challenges. Thus, it seems to be safe to use the simple reachability check in order to accept routing information. 4.3. Privacy [Ability to change addresses at will. Ability to send Binding Updates inside ESP. TBD.] [Local Host Cache Entries corresponding to several distinct Host Personalities to enhance privacy. TBD.] 5. General Comments and Open Issues 5.1. Application Backwards Compatibility According to our current understanding, most applications SHOULD work without any changes on the top of Homeless Mobile IPv6. In general, applications that just open a connected socket, and use it in an "address-agnostic" way do work just fine. However, there are a small collection of TCP applications, FTP being the prime example, that use IP addresses at the application level, and a slightly larger collection of UDP applications that do the same. Of these, those applications that store the address for a long time and use it later, will definitely break. But, in our opinion, those applications should be rewritten in any case. On the other hand, if the IP address is used at the application level just for a short time, the application has a good chance of working anyway. 5.2. Cache Entry Creation Policy We need to clarify the policy for creating Foreign Host Cache Entries when acting as a server (answering party). Basically, the method must be such that there are no easy IP address-spoofing Denial-of-Services attacks. - The upper layer PDU might contain information, such as application-level authentication data, that proves the foreign host to be honest. In that case, a cache entry could be created without any worries. - In the case of protocols like TCP, the cache entry is still created too early (= when sending SYN|ACK). - For stateless upper-level protocols, the cache entry should exist only between receiving a packet and sending a reply. After that, the entry is wasting cache space. We do not know how to solve the problem. However, the following ideas have come to our mind. - Classify cache entries into "trusted" and "untrusted". For untrusted entries, use the DEFAULT-LIFETIME instead of the one specified in the last Binding Update. When the cache is filling up, erase random untrusted entries. - Provide and API that lets the upper-layer (or application) protocols say that a certain cache entry is trusted. The TCP protocol could mark the cache entry as trusted after receiving the ACK (3rd packet). - Provide an API that lets upper-layer (or application) protocols erase cache entries or prevent their creation. The stateless upper-layer protocol could erase the cache entry after sending a reply. (It might be better not to create any cache entries and to pass the source IP addresses to the upper layer protocol.) - Create Host Cache Entries only after the first AH protected Binding Update is received from the correspondent host. The problem is that only the upper-layer protocol can determine whether a cache entry should be trusted to not. (For example, only the TCP layer knows that the ACK proves that the foreign host has received the SYN|ACK. This cannot be reasoned by the network layer without making some strong assumptions about all upper-layer protocols.) But if we let the upper-layer protocols manage the cache, as we suggest above, it will become confusing when cache entries are shared by several upper-layer protocols and even by several users. 5.3. Address Confusion Consider the following scenario: 1. Stateless Mobile Host M1 has care-of-address ADDR1. 2. M1 opens a connection to a Standard Mobile Host C. 3. M1 obtains a new address ADDR2, loses its old address ADDR1, and sends the corresponding Binding Updates to C. From now on, M1 creates the illusion to C that ADDR1 is his home address. 4. Stateless Mobile Host M2 gets the old care-of-address ADDR1. 5. M2 opens a connection to a Standard Mobile Host C. C becomes confused because M2 appears to have the same home address as M1. This problem will not occur if the care-of-addresses are not reused by different mobile hosts. For example, composing the care-of-address of a unique hardware address solves it. 6. Intellectual Property Right Notice For Ericsson policy on IPR issues, see the Ericsson General IPR statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General References [MIP6] David B. Johnson, Charles Perkins, ``Mobility Support in IPv6'', work in progress, Internet-Draft draft-ietf-mobileip-ipv6-13.txt, Internet Engineering Task Force, November 2000. [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore & Cisco & DEC, April 1997. [SIP] Handley, Schulzrinne, Schooler, Rosenberg, ``SIP: Session Initiation Protocol'', work in progress, Internet Draft draft-ietf-sip-rfc2543bis-01.txt, Internet Engineering Task Force, August 2000. [RFC2874] M. Crawford and C. Huitema, ``DNS Extensions to Support IPv6 Address Aggregation and Renumbering'', RFC 2874, July 2000. [RFC1886] S. Thomson and C. Huitema, ``DNS Extensions to support IP version 6'', RFC 1886, December 1995. [ADDRSEL] R. Draves, ``Default Address Selection for IPv6'', work in progress, Internet Draft draft-ietf-ipngwg-default-addr-select-02.txt, November 2000. [OWNERSHIP] P. Nikander, ``An Address Ownership Problem in IPv6'', work in progress, Internet Draft draft-nikander-ipng-address-ownership-00.txt, Internet Engineering Task Force, February 2001. [RFC2401] S. Kent and R. Atkinson, ``Security Architecture for the Internet Protocol'', RFC2401, November 1998. [Nikander2001] P. Nikander, ``Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World'', unpublished manuscript submitted for publication, available from the author upon request. Authors' Addresses Pekka Nikander Ericsson Research NomadicLab, Espoo, Finland phone: +358-40-721 4424 email: Pekka.Nikander@nomadiclab.com Janne Lundberg Ericsson Research NomadicLab, Espoo, Finland phone: +358-9-2991 email: Janne.Lundberg@nomadiclab.com Catharina Candolin Telecommunications Software and Multimedia Lab Helsinki University of Technology, Finland email: Catharina.Candolin@hut.fi Tuomas Aura Microsoft Research, Cambridge, UK email: tuomaura@microsoft.com Appendix A. Example Packet Flows A.1. Alice contacts Bob, initiates IKE negotiation creating an AH SA, and Alice and Bob exchange Binding Updates. Alice Bob ===== === IKE connects an UDP socket to Bob Kernel creates a Foreign Host Cache Entry for Bob --------- First IKE Message --------> The IKE daemon receives the message through an unconnected UDP socket, creates a cookie and sends a stateless response <-------- Second IKE Message ------- --------- Third IKE Message --------> The IKE daemon receives the message through an unconnected UDP socket, checks the cookie, and connects a UDP socket to Alice Kernel creates a Foreign Host Cache Entry for Alice <---- Rest of IKE negotiation ------> AH SA Established AH SA Established and associated and associated with Bob's with Alice's Foreign Host Foreign Host Cache Entry Cache Entry ----- Initial Binding Update-------> <---- Initial Binding Update ------- A.2. Alice contacts Bob, performs Anonymous Authentication, and Alice and Bob exchange Binding Updates Alice Bob ===== === IKE connects an UDP socket to Bob Kernel creates a Foreign Host Cache Entry for Bob ----- First Anon Auth Message ------> Bob creates a response that contains all his state, including the AH SA, and does not create any state yet <----- Second Anon Auth Message ----- + AH + Initial Binding Update Alice creates an AH SA and associates it with the Foreign Host Cache Entry ------ Third Anon Auth Message -----> + AH + Initial Binding Update Bob checks that the the state can be correctly recovered, creates a Foreign Host Cache Entry and an AH SA, and associates the AH SA with the Foreign Host Cache Entry Appendix B. Binding Update Optimization This appendix presents an alternative way of performing Binding Updates between two Homeless Hosts. This alternative further reduces overhead caused by Binding Updates. A Homeless Host can inform a correspondent host of a new address that can be used to reach it by sending a packet with the new address as the source address in a packet. No Binding Update Option is needed. In the receiving host, the new address is added to the Host Cache Entry which is identified by the SPI in the AH header in the packet. The packet MUST be protected with AH, and a Binding Acknowledgement MUST be sent as a result of receiving an address through this optimization. The lifetime of the address is set to DEFAULT-LIFETIME. This technique MUST NOT be used as the Initial Binding Update, and the destination node MUST be known to be a Homeless Host. Appendix C. An attack against "address ownership" A usual misconception in security is that cryptography means security. That is, most people think that "if I have an IPSEC security association with Bob, then Bob must be honest and trustworthy". Unfortunately, this assumtion is not necessarily true. Now, as long as IPsec is used for VPN only, the problem doesn't really surface. Once we start to use IPsec for multiple purposes, or simply for signalling with several hosts, the problem becomes more visible. In this example, we show how this problem surfaces with standard Mobile IPv6. C.1. An attack skenario Let us consider a server serving a number of future mobile terminals. The actual nature of the server is not important. The terminals and the server communicate with Mobile IPv6. The server is meant to be open, i.e., to serve any hosts using Mobile or non-mobile IPv6. Following the cryptographic tradition, let us call the server Alice. To simplify the situation, let us have only two clients: Bob, who is honest, and Mallory, who is malicious and whose aim is to "steal" or at least disturb communication with Alice and Bob. It is important to notice that Mallory has selected Bob as his target, and he attempts to perform his attack in such a way that neither Alice or Bob are aware of the attack; the result of a succesfull attack is that Mallory controls, at least to a degree, all communication between Alice and Bob. Now, if we assume that the MIP6 implementation that Alice uses fully conforms to the standards but is simple minded, the following attack would work. 1. Mallory contacts Alice and creates a pair of AH SAs with her. 2. Using the SAs created in Step 1, Mallory sends a MIP6 Binding Update to Alice, claiming that his Home Address is that of Bob's and that Bob (the Home Address) is currently visiting at Mallory's (care-of-address). 3. Since the Binding Update is protected with AH (see MIPv6 Sec 4.4 and 8.2), Alice accepts the Binding Update. (Note that this is a mistake at Alice's part. However, giving Alice the required knowledge to make the right decision is hard. For more discussion, see [address-ownership-problem]. 4. As part of the Binding Update processings (sec 8.3), Alice creates a new Binding Cache Entry telling that all future communications to Bob's Home Address should be sent to the address Mallory gave (the CoA). Now, let us assume that Bob now wants to create a TCP connection with Alice. Thus, he sends a TCP SYN packet, using his home address, to Alice. Alice receives this packet normally, and passes it to TCP. Alice's TCP creates a new TCB and sends a SYN ACK packet, using Bob's home address as the destination address. 5. Now, as a part of output processing (MIP6 sec 8.9), Alice checks its Binding Cache, find a Binding matching the destination address, and adds a Routing Header to route the packet through Mallory to Bob. 6. Mallory receives the SYN ACK packet from Alice. 7. Mallory has now a number of options to further fool Bob. a) Mallory may choose to claim Bob that Alice is a mobile node herself, and currently at the location where Mallory is. To do this, he creates a pair of IPsec SAs with Bob (or uses existing ones), and sends a Binding Update claiming that Alice is currently at his address. (This assumes, of course, that Bob makes the same mistake Alice made above at step 3.) b) Mallory may choose to claim Bob that Alice is currently (better) reachable through him. To do this, he replaces the routing header that Alice inserted with his own, and uses an existing AH SA (or creates a new) between himself and Bob to protect the routing header to get replies back, as specified in RFC2460 section 8.4. The real difference between this and the a) alternative is that Bob does not insert a Home Address destination option or a Binding Update, but relies on Bob reversing the Routing Header since it is protected with AH. 8. Independent on whether Mallory decides use Binding Updates or Routing Headers, he further has two options on how to handle the data stream in the future a) Mallory may decide to act as a man-in-the-middle, passing data between Alice and Bob, and modifying it at need. Furthermore, if the IPsec implementation Alice and Bob are using is simple minded enough, he _may_ be able to fool Alice that she is securely (i.e. with IPSec) talking with Bob, and fool Bob that he is securely talking with Alice. b) Mallory may decide to play Alice to Bob, and completely terminate Bob's session with Alice. This ends the attack description; the only purpose of it is to be illustrate the problem. C.2. Attack analysis Even an superficial analysis on the attack description reveals the basic problem: Alice is using an "untrustworthy" SA to accept Binding Updates concerning Bob, and Bob is using equally "untrustworthy" SA to verify Binding Updates or Routing Headers. If we look at a little bit closer to steps 3. and 7. above, we can describe the problem as an authorization problem. First, in step 3., the SA that Mallory has created with Alice should NOT be authorized to create a Binding Cache Entry for Bob's home address. Similarily, in step 7a., the SA that Mallory has created with Bob should NOT be authorized to create a Binding Cache Entry for Alice. Still, in step 7b., the SA that Mallory has created with Bob should NOT be authorized to accept the Routing Header as a reversible Routing Header (RFC2460 sec 8.4.). Appendix D. State machine for backward compatibility This appendix defines a state machine implementation for keeping track of the status of the peer hosts. (See Sections 2.2. and 2.3.) TBD. Expires September 2001