Internet Mobopts Research Group Mobile IPv6 Route Optimization Multihoming This memo explores the possible areas of extensions to MIPv6 route optimization in the considerations of multihomed nodes. The intention is to raise awareness in the research community, leading to a possible extension to RFC 4651.

RFC 4651 discussed and analyzed various techniques of optimizing the Route Optimization in Mobility Support in IPv6 (Mobile IPv6, or MIPv6) . One area in which RFC 4651 had not considered, which was in fact mentioned as a future research area, is the consideration of multihomed nodes. As different access technologies continues to emerge, the likelihood of a node being multihomed increases. Additionally, a node can enjoy various benefits, such as more resilience to link failures or network congestions, as documented in various literature (e.g. see , , ). Thus, it could be expected that in future, a substantial portion of nodes involved in Mobile IPv6 signaling will be multihomed. Narayanan et. al provided a good analysis in the interaction of between various mobility and multihoming protocols in from an architectural perspective. The present memo is not meant to duplicate the work there. Instead, it is our intention to analyze if there are opportunities for optimization when multihomed node is involved in Mobile IPv6 signaling. For this purpose, this memo first considers the case where the mobile node is multihomed in , and then the case where the correspondent node is multihomed in . Finally, the case where the anchor node (i.e. home agent, mobility anchor point, etc) is multihomed will be considered in .

The case where the mobile node is multihomed is covered in various literature, for example, see , , , , . As such, this analysis will only focus on those not covered by these literature.

There are two main possibilities of a multihomed mobile node. In the first case, the mobile node can have multiple home addresses. This is possibly a result of the home network being multihomed, or the mobile node itself is subscribed to multiple mobility service providers. In the second case, the mobile node can have multiple care-of addresses. This is likely due to the mobile node attaching multiple interfaces to different access routers, or due to an access router advertising multiple prefixes. The first case is largely similar to a multihomed IPv6 node, and is currently being studied by the IETF SHIM6 Working Group. As such, our analysis will be confined to those optimization that are possible with respect to the Mobile IPv6 signaling. Similarly, the second case of multiple care-of addresses was previously analyzed by the IETF Monami6 Working Group (currently, the WG is merged with other mobility related effort in the Mobility Extension Working Group). Thus, we will limit our analysis to optimizing the signaling used in Mobile IPv6 Route Optimization.

Including Multiple Home Addresses in Binding Update When a mobile node has multiple home addresses, it will need to send multiple binding updates to a correspondent node or home agent, one for each home address. One way to reduce the number of signaling messages is thus to allow a binding update message to contain multiple home addresses -- i.e. multiple home address options in the destination header. However, since the destination header would typically be processed before the mobility header, a cleaner way to do this might be to create new mobility option to carry the home address, and include multiple such options in the binding update message. Re-using Care-of Keygen Tokens For route optimization signaling with a correspondent node, the mobile node need not perform separate return routability procedures for each of the home addresses. Instead, one pair of HoTI/HoT message exchange for each home address is sufficient. The care-of keygen tokens can be used independently with each home keygen token. Below illustrates the use of three home addresses with one care-of address.

| |<---- HoT(HoK1) for HoA1 (tunneled via HA) -----| |------- HoTI for HoA2 (tunneled via HA) ------->| |<---- HoT(HoK2) for HoA1 (tunneled via HA) -----| |------- HoTI for HoA3 (tunneled via HA) ------->| |<---- HoT(HoK3) for HoA3 (tunneled via HA) -----| |-------------------- CoTI --------------------->| |<----------------- CoT(CoK) --------------------| |---------------- BU for HoA1 ------------------>| |---------------- BU for HoA2 ------------------>| |---------------- BU for HoA3 ------------------>| | | ]]>

Here, HoK1, HoK2, HoK3 are the home keygen tokens for the home addresses HoA1, HoA2, HoA3 of the mobile node respectively, and CoK is the care-of keygen token for the care-of address CoA of the mobile node. Binding Multiple Home Addresses in Correspondent Node If multiple home addresses is included in a single binding update message sent to the correspondent node, multiple home nonce indices must be specified as well. The main consideration next is whether multiple mobility management key (Kbm) should be generated, one for each home address; or a single unified Kbm should be used. Using multiple Kbm has the advantage of flexibility. The mobile node may later choose to update the bindings associated to a single home address without having to generate a new Kbm. Using a single Kbm would be the more natural choice if multiple home addresses are specified in a single binding update. This way, only one Authenticator value is needed. When multiple Kbm are used, multiple Authenticator values must be present in the binding update message. A binding update message would be something similar to the following:

The reader would note that this looks like a simple aggregation of three binding updates into a single message. The complexity in processing such a binding update message may not be justified for the mere saving of bandwidth compared to the sending of three separate binding updates (one for each home address). The other alternative will be to use a single Kbm. In this case, the Kbm may be generated by:

Only one Authenticator value is needed in this case, although multiple Nonce Indices Options are still needed.

Binding of multiple care-of addresses to a home agent is already being developed in , and its security consideration discussed in and . As such, they would not be duplicated here. Instead, we focus on the binding of multiple care-of addresses to a correspondent node, and some approaches to optimizing the signaling. Binding Multiple Care-of Addresses at Correspondent Node When a mobile node wishes to bind multiple care-of addresses to its home address at a correspondent node, the current approach specified in is to use a Binding Identifier (BID) to reference each care-of address binding. So, assuming a mobile node MN with three care-of addresses CoA1, CoA2, and CoA3, it will send one HoTI message and three CoTI messages (one for each care-of address) to the correspondent node CN. After collecting the keygen tokens, it will send three binding update messages, one for each care-of address, and each with a different BID value. This is illustrated below.

| | | |<------- HoT (via HA) ---------------| |------------------------ CoTI ------------------>| |<-------------------- CoT (CoK1) ----------------| | |------------------ CoTI ------------------>| | |<-------------- CoT (CoK2) ----------------| | | |------------ CoTI ------------------>| | | |<-------- CoT (CoK3) ----------------| |---------------- BU (BID=1, using Kbm1) -------->| | |---------- BU (BID=2, using Kbm2) -------->| | | |---- BU (BID=3, using Kbm3) -------->| ]]>

As we can see from above, the mobile node will need to gather three care-of keygen tokens (CoK1, CoK2, CoK3) and combine each of them with the home keygen token (HoK) to form three mobility management keys (Kbm1, Kbm2, and Kbm3). Each of these keys is then used to protect the binding update message. The next logical step for optimization is to combine all the binding update messages into one message, or what is known a Bulk BU. This means that multiple care-of addresses are included in the Bulk BU message. As in , we could continue to use multiple Authenticator values or a single Authenticator value. Using multiple Authenticator values would mean using each of the three keys Kbm1, Kbm2 and Kbm3 to generate a cryptographic checksum of the Bulk BU. Using a single Authenticator value means that the care-of keygen tokens should be combined to form a single key, Kbm*, possibly given by:

With this, only one Authenticator value is needed, although multiple Nonce Indices Options is still required in the Binding Update message to contain all the care-of nonce indices. The Authenticator value given by

could either remain the same and use the care-of address that appears as the source of the binding update in the calculation, or one could change the Authenticator value into the following to use all three care-of addresses:

Optimizing based on Usage of Care-of Addresses Another approach to optimization would be to remove redundant signaling based on the usage of care-of addresses. Return routability procedure establishes the validity of a care-of address as a source address of a packet sent from the home address, and the reachability of the home address at the care-of address (when care-of address is used as destination). If, in a scenario, it is not necessary to establish both the validity and the reachability of a care-of address, then one could reduce the amount of signaling messages needed in the return routability procedure to establish only the needed characteristics of the care-of address. It is not possible to do so with only one care-of address, since a pair of packet exchange is required to prove anything. However, with multiple care-of addresses, such optimization becomes possible. In one example, a mobile node MN with multiple care-of addresses (CoA1 and CoA2) could assign different usage for each of its care-of addresses. For instance, CoA1 could be only used for transmitting data to the correspondent node CN, whereas CoA2 is only used for receiving data from CN. In this case, it is not necessary to establish the reachability of CoA1 as a destination address. Neither is it useful to establish the validity of CoA2 as a source address. An approach for optimization is thus to send a CoTI from CoA1 to CN. In this CoTI message, it is indicated that CoA1 is a transmit-only address and CoA2 is specified as a receive-only address. CN then generates the paired care-of keygen token, PCoK, using

The last octet '3' is used to differentiate the PCoK from a normal CoK. This included in a CoT message that is sent to the receive-only care-of address CoA2. Finally, to complete the optimized return routability procedure (which could be aptly termed as "Paired Return Routability Procedure"), MN sends a binding update message to CN. The binding update message is sent from CoA1, and includes new option to indicate that the source address is a transmit-only address and specify that CoA2 is a receive-only address. The Authenticator value is given by

where the paired mobility management key, PKbm, is given by

If a binding acknowledgement is sent, it should be sent to the receive-only care-of address CoA2. The message sequence illustrates the paired return routability procedure.

| | |<--------- HoT (via HA) ---------------| |-------------- CoTI (pair=CoA2) ------------>| | |<---------- CoT (PCoK) ----------------| |--------------- BU (Pair=CoA2) ------------->| | |<------------- BAck -------------------| ]]>

The CN must in this case record in its binding cache that CoA1 is only used to receive data from MN, and CoA2 is only used to transmit data to MN. Optimizing based on Network Infrastructure The above pairing of care-of addresses can also be used within a controlled network infrastructure, such as those provided by cellular operators, or a network with Source Address Validation Architecture (SAVA) in place. Characteristics of such a network infrastructure is that it guarantees the reachability of an address as a destination address if the validity of the address as a source address is proven, and vice versa. This can be achieved, for instance in a cellular operator controlled network with aggressive ingress filtering on all network components. With such a network infrastructure in place, it is no longer necessary for a correspondent node to use both the CoTI and CoT messages to establish the reachability of a care-of address as a destination address and validity of the care-of address as a source address. Since establishing one characteristic (eg. validity as source) implies the other (eg. reachability as destination), the CoTI and CoT messages can be used to test two care-of addresses. This optimization is similar to the pairing of two care-of addresses in the above discussion of Paired Return Routability Procedure.

At first glance, it seems that the inclusion of multiple home addresses (see ) and multiple care-of addresses (see ) in a single binding update message would not expose the recipient to additional security threats other than those already existed in the original binding update mechanism of RFC 3775 (see ). Similarly, the use of the Pairing Return Routability Procedure does not seems to have additional security concerns compared with using multiple Return Routability procedures, if the assumptions behind its usage are valid (i.e. care-of addresses are used for transmitting or receiving only, or the underlying network infrastructure guarantees the reachability or validity given one is proven). This is because these optimizations utilize all components of the original return routability procedure -- they merely optimize by merging some messages into one. Of-course, it is only prudent for one to analyze the security threats more rigorously before actually adopting any of these optimizations. The author hereby invites interested researchers to do so, and discuss the security implications for inclusion in future version of this draft.

There are two main possibilities why a correspondent node can be multihomed. Firstly, the correspondent node can be on a multihomed site. Secondly, the correspondent node may be using multiple interfaces. In both cases, the correspondent node would configure multiple addresses, and may use more than one address when communicating with the mobile node. Such communications may take the form of: Single Session: with the use of multihoming-capable protocols such as Stream Control Transmission Protocol (SCTP) , or Site Multihoming by Intermediation (Shim6) , the correspondent node and mobile node may be having only a single transport session, even though multiple addresses are used. Multiple Sessions: the correspondent node may wish to perform load balancing between its multiple addresses such that, for instance, audio streams would use one address while video stream uses another address when having a video conference session with the mobile node. In both of the forms, the packet data unit (PDU) received by the IP layer of the mobile node from the upper layers will be addressed to multiple addresses belonging to the correspondent node. In the Single Session case, the SCTP or SHIM6 protocol layer will split the traffic stream into different PDUs to be sent to different addresses of the correspondent node. In the Multiple Sessions case, the applications will open different sessions addressed to different addresses of the correspondent node. Either way, the Mobile IP layer will not be aware of the fact that all these different addresses belong to the same physical node. When route optimization is attempted, the mobile node will initiate return routability procedure with each and every of the correspondent node's addresses, oblivious to the fact that only one set of return routability procedure is needed to bind its care-of address to its home address at the correspondent node.

Approaches to eliminate such redundant signaling would involve making the Mobile IP layer of the mobile node aware that the addresses all belongs to the same correspondent node. In one approach, special application programming interface (API) is provided to allow upper layers to link a set of addresses as belonging to a single entity. This will allow SCTP, Shim6 or other multihoming protocols to inform the Mobile IP layer that route optimization is enabled with all the addresses in the linked set as long as return routability procedure is successfully conducted with one of the addresses in the linked set. The disadvantage of this approach is that it relies on upper layers to utilize the newly provided API. Old, unmaintained programs would not be able to do so, resulting in redundant signaling. Another approach is for the correspondent node to inform the mobile node of all its addresses upon receiving the first signaling message from the mobile node. This may be any one of the Home Test Init, Care-of Test Init or Binding Update messages. Upon responding with the Home Test, Care-of Test or Binding Acknowledgment messages, the correspondent node may include the list of addresses it owns, so that the mobile node would know that it need not repeat the return routability procedure with these addresses.

There are security threats that needs to be analyzed for the second approach. Two aspects of the threat analysis should be covered: the threats on the mobile node This is generally the case where a malicious correspondent node sends back a list of fake addresses. This would cause the mobile node to wrongly assume that route optimization with an address is established when it is in fact not. To illustrate how this can be used as an attack, consider a mobile node MN having communications with two correspondent nodes CN1 and CN2. Suppose that CN1 is malicious such that when MN attempts to perform route optimization with CN1, it informs MN that it also owns the address of CN2. This would trick MN into thinking that it has already established route optimization with CN2. Packets sent to CN2 from MN would thus be using the care-of address of MN as source and containing the home address destination option. However, since CN2 does not actually have a binding cache entry of the care-of address and home address of MN, these packets will be discarded, thus causing a denial-of service. the threats on the correspondent node This is generally the case where a malicious node initiate return routability procedure with a correspondent node, tricking it to revealing the list of addresses it owns. This does not seems to be a serious threat at first glance, since if the correspondent node does not wish its list of addresses to be known, it can always be configured to not return the list of addresses. To eliminate the security threat to the mobile node, the mobile node would probably need to perform a test on the list of addresses it received. A simple echo and response test on the addresses using the route optimized path would suffice. For instance, consider a mobile node MN communicating with a correspondent node CN with three addresses, CN.Addr1, CN.Addr2, and CN.Addr3. Upon initiating route optimization with CN.Addr1, MN receives the list of addresses from CN that claims to own CN.Addr2 and CN.Addr3 as well. To test the validity of this claim, MN needs to send a, say, ICMP Echo Request message to each of CN.Addr2 and CN.Addr3. Each IMCP Echo Request message would assume route optimization is achieved, i.e. each message will use the care-of address of MN as the source address, and contain the home address of MN in the home address destination option. If the addresses CN.Addr2 and CN.Addr3 are valid, MN will receive ICMP Echo response message from each of these addresses. The ICMP Echo Response messages should also contain the care-of address of MN as the source address and have a type 2 routing header bearing the home address of MN. Such a test adds one more pair of message exchange per correspondent node address, but it is still better than the six messages required by return routability if the mobile node did not know that the addresses belong to the same node. It is possible to further optimize the number of signaling by adding an option in the ICMP Echo Request message sent to CN.Addr2, such that the ICMP Echo Response message will be sent via CN.Addr3. This way, we eliminate another pair of message exchange. The figure below illustrates this.

| | | |<----------- HoT (via HA) ------------| | | |---------------- CoTI --------------->| | | |<--------------- CoT -----------------| | | |----------------- BU ---------------->| | | |<--- BAck (specify: Addr2, Addr3) ----| | | |----------- ICMP Echo Req ------------------->| | |<-----------ICMP Echo Resp ---------------------------| ]]>

One could of-course use binding update and binding acknowledgement messages to replace the ICMP Echo request and response messages.

In this section, multihomed anchor points are considered. Anchor points include home agents in Mobile IPv6 and NEMO Basic Support, mobility anchor points (MAP) in Hierarchical Mobile IPv6 (HMIPv6) , and local mobility anchor (LMA) in Proxy Mobile IPv6 (PMIP) . We would largely concentrate on the Mobile IPv6 or NEMO home agents at this point, although most of the discussions should be equally applicable to mobility anchor points and local mobility anchors as well. As home agents (and anchor points in generally) are routers by definition, they would usually have multiple interfaces (and thus multihomed). In this document, we are only interested in the case when a home agent has multiple global addresses configured on its egress interface(s) such that a mobile node that is away from the home link can contact the home agent via multiple paths. This scenario usually means that the home agent is connected to multiple egress routers, and each of the home agent's address would be reachable via one egress routers. Another possible scenario is when the home agent is managing separate home links, possibly configuring a different home agent address on the each home link.

In the case where the home agent has different egress routes, one possible optimization is to let the mobile node knows the network characteristics of each egress path. This allows the mobile node to (1) select which egress path to use when tunneling packets to the home agent, and (2) request the home agent to use a particular egress route when forwarding packets to the correspondent node or mobile node. Informing mobile node egress characteristics of home agent Information on the egress characteristics of the home agent can be transmitted to the mobile node by attaching them onto the Binding Acknowledgement message as new options, or be sent using existing protocol by running it over the bi-directional tunnel between the mobile node and the home agent. Tunneling packets from mobile node to home agent With the information on the egress characteristics of the home agent, the mobile node can then select the appropriate path to reach the home agent when tunneling packets to the home agent for forwarding. This assumes that there are multiple globally routable unicast addresses of the home agent for the mobile node to choose from, and using one such home agent address implies the choosing one particular path to reach the home agent. Forwarding packets to correspondent node Once the home agent received a packet to be forwarded to a correspondent node, the home agent will need to choose which of its available egress path it can use to forward the packet out. One way is to simply forward the packet out the same way as it was received -- since the mobile node chooses to tunnel this packet via a particular egress interface of the home agent, it makes sense to assume that the mobile node would want the packet to be forwarded to the correspondent node via the same egress interface. Another alternative is to allow the mobile node to explicitly specify which egress interface to use by using new options in the Destination Header of the tunnel packet. Forwarding packets to mobile node When the home agent intercepted a packet to be forwarded to the mobile node, the home agent will need to choose which of its available egress path it can use to forward the packet out. The obvious approach to allow this is to use similar concept of the flow binding mechanism currently being developed by the MExt Working Group, and allows each flow binding filter to specify which egress interface of the home agent to use for (in addition to which care-of address of the mobile node to use) for a given flow. In the case where the home agent is managing separate home links, a possible scenario is for a mobile node to subscribe to multiple home links managed by the same home agent. The mobile node may sees different home agent addresses on different home links and think they are separate entities. A small optimization here would be for the home agent to inform the mobile node that it owns the different home agent addresses. This way, the mobile node can specify multiple home addresses in a single binding update to the home agent (see Section ).

As signaling between the home agent and the mobile node is protected by security association, there are no third party security threats. A home agent may falsely claim to be multihomed -- but obviously, if a home agent has malicious intent or is compromised, it can do much more harm to the mobile node then claiming to own addresses it does not actually own.

This memo explores the use of multihoming and mobility protocols simultaneously, and investigates specifically if there are further enhancements that can be done in such situations. We had analyzed the cases where the mobile node, the correspondent node, and the anchor point are multihomed, and discussed various possible optimizations in each case.

draft-ng-mobopts-multihoming-02: Added Section for "Multihomed Anchor Points" draft-ng-mobopts-multihoming-01: Added Section for "Multihomed MN" Re-organized "Multihomed CN" and added discussion on mitigating the security threats draft-ng-mobopts-multihoming-00: Initial version.