INTERNET-DRAFT P. Nikander Ericsson NomadicLab Expires April 2001 J. Lundberg C. Candolin T. Aura Helsinki Univ. of Tech. November 2000 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 [1], 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 [1], and with hosts implementing the minimal conformance requirements of Section 7.1 of [1]. 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 Mobility Support in IPv6 [1]. (4) Be backward compatible with Mobility Support in IPv6 [1]. 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. Adding Addresses to Host Cache Entries . . . . . . 2.1.3. Removing Address from the Host Cache Entries . . . 2.1.4. 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. The Usage of Security Associations . . . . . . . . 2.4.2. Interconnections between Host Cache and IPSEC AH . 2.4.3. Anonymous Authentication . . . . . . . . . . . . . 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 3.1. New Destination Option Sub-Options . . . . . . . . . . . . 3.2. Protocol Parameters . . . . . . . . . . . . . . . . . . . 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 1. Introduction This memo specifies Homeless Mobile IPv6, a variant of the Mobility Support in IPv6 [1] (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 Mobility Support IPv6 [1], or just the minimal interoperability requirements of Section 7.1 of [1]. 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 lesses 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.2). Homeless Mobile IPv6 does NOT require any new packet formats or on-the-wire support; however, it does suggest some new sub-Options for more efficient operations. Still further, it does not require any changes to IPv6 routers (other than support for standard Mobile IPv6, as defined in Sec. 7.1 and 7.2 of [1]; see also 10.9 of [1]). Instead, it relaxes some of the requirements of Mobility Support in IPv6 [1] 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 [2] or SIP [3]. Thus, instead of using a Binding Cache to bind a care-of-address to some (arbitratry) 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 [1] specification, and read together with it. In the following, references to [1] are expressed as "MIPv6, Sec X.X" 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 [1] protocol. Homeless (supporting) Host A mobile or non-mobile host that implements the Homeless Mobile IPv6 variant of the Mobile IPv6 [1] protocol. Standard Mobile Host A mobile host that does not implement the Homeless Mobile IPv6 variant of the Mobile IPv6 [1] 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 [1] 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 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 hosts. 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. 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 believed) to belong to a single host or Host Personality. An initial Host Cache entry MAY be based on a DNS reply containing multiple A6 [4] or AAAA records [5]. 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.3. To prevent its Host Cache IP addresses from expiring at active peers, a mobile host SHOULD periodically transmit 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 two new Destination Option Sub-Options, Homeless Support Sub-Option, which MAY be sent in a Binding Request or a Binding Update, and Alternate Prefixes Sub-Option, which MAY be sent in a 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 indipendently 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 Acknowledments, see MIPv6 Sec. 4.2. When sending packets to a Homeless (supporting) Host, the destination address for the packet MAY be freely selected among of the 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. However, 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. [Apparently, we need to be more strict when sending ICMP, ND and other control packets. It seems like the Host Cache should not be used for ICMP or ND at all. Until further experimentation brings more light to this, it is RECOMMENDED that the Host Cache is completely bypassed when sending ICMP, ND and other control packets. TBD.] When receiving packets from a Homeless (supporting) Host, each packet's destination address MAY be any 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 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 representing the upper layer protocol connection (socket) the packet should be delivered to. 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.X 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 records the 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 addres (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 somehow). 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.2. 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 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. Adding Addresses to Host Cache Entries 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 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 hosts 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 neighbourhood discovery, it SHOULD include a Binding Update 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. 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 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.3. Removing Address from the 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 not activity-related, 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 a host leans 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. Whenever an address expires, it MAY be removed from the Host Cache Entry. However, it is RECOMMENDED that the address is kept (as an expired address) for some time, to make it easier to react if the address is still used. An expired address MUST NOT be kept in the Host Cache for longer than MAXIMUM-EXPIRED-LIFETIME seconds. 2.1.4. Removing Host Cache Entries When the last address in an Host Cache Entry expires, as specified in Sec. 2.1.3., the host MAY remove the Host Cache Entry. However, it is RECOMMENDED that the Host Cache Entry is only removed when the last expired 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 only - the status of the destiation host is not known 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 expired. Currently, it is RECOMMENDED that in such a case the IP layer behaves as if there was an ICMP Destination Unreachable received. [This needs more work. TBD.] 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 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 scope and scoped domain of the selected destination address. 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. If a Binding Update is included, 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 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. 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. 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 bases, 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 probablity 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 Destiation 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. 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. 2.3.2. Receiving packets from Standard Mobile Hosts [This section has to be written. TBD.] 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.X 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. As a related security measure, all Binding Updates used in Homeless Mobile IPv6 MUST carry valid AH headers. This prevents malicious mobile or non-mobile hosts from changing addressing information related to other Homeless Hosts or Standard Mobile Hosts using a spoofed source address. The implications of this are discussed later in this section. 2.4.1. The Usage of Security Associations As specified in IP Security Architecture [RFC2401] Section 5.1.2, 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. Let us consider the Security Associations needed in order to allow communication from one Homeless (supporting) Hosts, called Alice, to another, called Bob. Basically, there must be either a separate SA for each possible Bob's addresses, a single SA must be shared between all possible Bob's addresses, or a number of SAs that together cover all possible Bob's addresses. Now, the standard way of adding new SAs or changing the applicability of an SA to cover new IP addresses is to run an ISAKMP Phase 2 negotiation. However, since that is quite a heavy operation, and it would be needed whenever an Host Cache Entry is updated, we suggest a different means next, in Section 2.4.2. 2.4.2. Interconnections between Host Cache and IPSEC AH [This section needs to be clarified. TBD.] It is REQUIRED that all Binding Updates are protected 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 ISAKMP, which is used to create the IPSEC AH SA. However, depending on the situation, it may be sufficient to create the AH SA in some less secure means, e.g., through so called Anonymous Authentication Protocol specified in Section 2.4.3, below. Now, once there is an AH SA between two Homeless (supporting) Hosts, and both of them have a Foreign Host Cache Entry denoting the peer, it is clearly beneficial if there is one-to-one coverage between the usage of the SA and the IP addresses represented in the Host Cache Entries. Since the updates to the Host Cache Entries must be protected with the AH SA, it seems safe to update the AH SA coverage together with the Host Cache Entries. This observation leads to the following suggestion. For incoming packets, a host MAY 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 MAY create a dynamic IPSEC policy entry that maps outgoing IP addresses to SAs based on the information 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 MAY compare the destination address against the addresses in the Foreign Host Cache Entries, and use this information for selecting the right SA. 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 ISAKMP 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 common secret that no other host know. In other words, host A knows that there is some host B, which is currently able to use a specific IP address addrress, and that B knows the same secret value than A knows, and no-one else knows that particular secret. That is, we mainly seek for protection against passive attackers. In this specification, we denote such an protocol as "Anonymous Authentication Protocol" (AAP). [A protocol, or a reference to a protocol to be defined. Seems like that we have to use Elliptic Curve Diffie-Hellman. TBD.] If an Anonymous Authententication Protocol is used to create an IPSEC AH SA to protect Binding Updates, the AH Security Association 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 connections that 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 Two 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 general format of suboptions is defined in MIPv6 Sec 5.5. 3.1.1. Homeless Support Sub-Option Homeless Support Sub-Option (alignment requirement: 2) 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 a 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 Prefixes are 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.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 an 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, the 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 Bindin Updates to a host that is known not to support Homeless Mobile IPv6, the options must be strictly formatted according to MIPv6 specification. 3.2. 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.3. 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. It MUST be realized that the integrity goals of Homeless Mobile IPv6 are typically much weaker than other the integrity goals typically are. This realization leads to classification of AH Security Associations, as discussed in Section 3.3.1., below. 3.3.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 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 Bindin Acknowledegements. Typically, Generic host-to-host AH SAs are created either through manual configuration or through some high level protocol, such as ISAKMP. On the other hand, Anonymous host-to-host AH SAs are typically created through an Anonymous Authentication protocol (see Section 2.4.3). 4. Security and Privacy Considerations [This section needs to be written. TBD.] Local Host Cache Entries corresponding to several distinct Host Personalities to enhance privacy. Possibilities for resource exhausting Denial-of-Service attacks. 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 good changes to work any 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 came 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.) 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 This is to affirm that Telefonaktiebolaget LM Ericsson and its subsidiaries, in accordance with corporate policy, will offer patent licensing for submissions rightfully made by its employees which are adopted or recommended as a standard by your organization as follows: If part(s) of a submission by Ericsson employees is (are) included in a standard and Ericsson has patents and/or patent application(s) that are essential to implementation of such included part(s) in said standard, Ericsson is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non- discriminatory terms and conditions. According to the knowledge of the authors, Ericsson or Helsinki University of Technology have NOT filed patent applications that might possibly become essential to the implementation of this contribution. References [1] David B. Johnson, Charles Perkins, ``Mobility Support in IPv6'', work in progress, Internet-Draft draft-ietf-mobileip-ipv6-12.txt, Internet Engineering Task Force, April 2000. [2] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore & Cisco & DEC, April 1997. [3] 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. [4] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6 Address Aggregation and Renumbering'', RFC 2874, July 2000. [5] Thomson, S. and C. Huitema, ``DNS Extensions to support IP version 6'', RFC 1886, December 1995. Authors' Addresses Pekka Nikander Ericsson Research NomadicLab phone: +358-40-721 4424 email: Pekka.Nikander@nomadiclab.com Janne Lundberg Telecommunications Software and Multimedia Lab Helsinki University of Technology Catharina Candolin Telecommunications Software and Multimedia Lab Helsinki University of Technology Tuomas Aura Laboratory of Theoretical Computer Science Helsinki University of Technology Appendix A. Example Packet Flows A.1. Alice contacts Bob, issues 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 an 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