Network Working Group M. Bagnulo Internet-Draft A. Garcia-Martinez Expires: September 30, 2003 I. Soto UC3M April 2003 Extending BCE lifetime to enable the application of MIPv6 to multi-homing draft-bagnulo-multi6-extendBCElt-00 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. This Internet-Draft will expire on September 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This note proposes modifications to the nodes behavior defined in MIPv6 [1] specification in order to overcome detected limitations when attempting to provide a multi-homing solution using the MIPv6 protocol. An analysis of the security implications of such changes is included as part of the modification design rationale. Bagnulo, et al. Expires September 30, 2003 [Page 1] Internet-Draft Extended BCE lifetime for multi-homing April 2003 1. Introduction The goal of the multi-homing and mobility solutions is to provide a communicating end-point with uninterrupted connectivity throughout changes in the point that it is using for attaching to the public IP network. In the mobility scenario, the communicating end-point changes its attachment point because of its movement. In the multi-homing scenario, the attachment point used by the end-point for communication varies because of topological changes caused by outages in the communication elements. While the causes are different, there seems to be enough similarities between the two scenarios to consider common solutions for both problems. Basic specification for IPv6 mobility support [1](hereafter MIPv6) is almost complete, while the appropriate approach for IPv6 multi-homing support is still being discussed. It is then a natural approach to analyze the application of the available mobility solution to the multi-homing problem. Such analysis is presented in detail in [2] and a brief summary is included in this document. The result of this analysis is that the MIPv6 protocol is suitable to be used for the provision of IPv6 multi-homing support without modifications in the packet formats defined in the specification. However, some changes in nodes behavior defined in MIPv6 are needed. Bagnulo, et al. Expires September 30, 2003 [Page 2] Internet-Draft Extended BCE lifetime for multi-homing April 2003 2. The Multi-Homing Scenario +-----+ |Host1| | CN | +-----+ | ... | _______|_______________________________________ | | | | | | |______________________________________________| | | | | | link2 link1 | | | +---------------+ +---------------+ | ISPA | | ISPB | | PA::/nA | | PB::/nB | +---------------+ +---------------+ | | | | | | link3 link4 __|____________________________|___ | RA RB | | +-----+ | |Multi-homed end-site |Host2| | |PA:Site::/48 | MHH | | |PB:Site::/48 +-----+ | |___________________________________| The application scenario consists of a multi-homed end-site that obtains global connectivity through two (or more) ISPs i.e. ISPA and ISPB. Since the end-site is multi-homed and provider aggregatable addresses are being used, the site has obtained two address ranges: one delegated from ISPA address range i.e. PA:Site::/48 and the other one from ISPB address space i.e. PB:Site::/48. Furthermore, in order to benefit from multi-homing, hosts within the site have to be Bagnulo, et al. Expires September 30, 2003 [Page 3] Internet-Draft Extended BCE lifetime for multi-homing April 2003 reachable through both ISPs. This implies that hosts have to configure one address from each ISP address range that the site has obtained. For instance, in the case of Host2, two addresses are configured i.e. PA:Site:Host2 and PB:Site:Host2. So, this configuration provides some Fault Tolerance capabilities since Host1 can reach Host2 through ISPA, using as destination address PA:Site:Host2 and it can also reach it through ISPB using as destination address PB:Site:Host2. This means that if there is an outage in one of the ISPs, ISPA for instance, Host1 can still reach Host2 using the alternative address i.e. PB:Site:Host2. However, this configuration does not allow the preservation of established connections through an outage event. This is the result of following constraints: - Most connections established at the transport level and above identify the endpoints involved in the communication by their IP addresses, imposing that they must remain unchanged during the lifetime of the connection. - In order to preserve aggregation benefits, Provider Aggregatable addresses delegated to the end-site by an ISP are to be routed toward the site through this ISP, so that it routes them toward the final destination. In the application scenario considered, addresses containing the prefix PA::/nA are routed to ISPA, who then routes them to the end-site considered. These constraints imply that if a connection between Host1 and Host2 is established using PA:Site:Host2 as address for Host2, packets flowing to Host2 will be routed through ISPA and only through ISPA. Then, if during the lifetime of this connection an outage occurs in ISPA, the connection will be dropped, even if a path between Host1 and Host2 is available. This is so because packets whose final destination address contains the PA::/nA prefix have no available route to Host2, since they can not be routed through ISPB and packets addressed to the alternative destination of Host2 (PB:Site:Host2) are not recognized by transport and uppers layers as belonging to the connection established using PA:Site:Host2. This note presents a mechanism for preserving established communications during an outage based in the MIPv6 protocol. Bagnulo, et al. Expires September 30, 2003 [Page 4] Internet-Draft Extended BCE lifetime for multi-homing April 2003 3. Application of the MIPv6 protocol In this section we will present an overview of the usage of the MIPv6 protocol to preserve established communication in multi-homed environments. For a detailed description the reader is referred to [2]. The idea is to use mobility messages, in particular Binding Updates (BU) messages, to convey alternative address information from the host within the multi-homed site to the other end of the established communication once that an outage affecting the currently used path occurs. This causes that forthcoming packets are addressed to the alternative address, implying that the communication is re-routed through an alternative available path. Therefore, during a communication between a host within the multi-homed site (i.e. Host2 in the figure above) and another host in the Internet (i.e. Host1 in the figure above), the first will assume the role of the MIPv6 Mobile Node and the second will act as the MIPv6 Correspondent Node. It should be noted that no party assumes the role of MIPv6 Home Agent. Then, when the communication is established, address selection rules will determine which one of the available addresses configured in Host2 is to be used for that particular communication, for example PA:Site:Host2 in the figure above. Such address will be considered as the MIPv6 Home Address (HoA). If no outage occurs along the path through which the packets are flowing, the communication continues using this address. However, if an outage does occur along the path, for example link1 if the figure above fails, the established communication is preserved using the MIPv6 protocol. In this case, Host2 sends a BU message to Host1 that contains an alternative address (i.e. PB:Site:Host2) as a Care-of Address (CoA), so that the following packets of the communication are addressed to the new CoA, which is still reachable. The communication then is preserved by using this new address. 3.1 About the Return Routability procedure In order to obtain the authorization data required by the MIPv6 binding procedure, the Return Routability (RR) procedure must be performed prior sending the BU message. Moreover, since the RR procedure requires connectivity through both addresses i.e. the HoA and the CoA, it must be performed before the outage occurs. On the other hand, authorization data obtained through the RR procedure has a limited lifetime, bounded by MAX_NONCE_LIFE i.e. 240 seconds. This imposes the periodic performance of the RR procedure in order to insure that valid authorization data is available in Host2 in case that an outage occurs. Since the RR procedure essentially consists in the exchange of HoTI/HoT messages through the HoA and the exchange of CoTI/CoT messages through the CoA, the periodical performance of the Bagnulo, et al. Expires September 30, 2003 [Page 5] Internet-Draft Extended BCE lifetime for multi-homing April 2003 procedure implies the periodical exchange of such messages. When applied to the multi-homed scenario, this message exchange can be used as an end-to-end path failure detection mechanism. Such usage imposes a higher message exchange frequency than the one required for providing valid authorization data, but it provides a valuable mechanism in the multi-homing scenario. For more details about the usage of the RR procedure as a failure detection mechanism the reader is referred to [2]. 3.2 Detected Limitation: Limited lifetime of Binding Cache Entries The main detected limitation for the application of the MIPv6 protocol to multi-homed environments refers to the limited lifetime of Binding Cache Entries (BCEs). It is stated in MIPv6 specification that Binding Cache Entries that have been authorized using the RR procedure have a maximum lifetime of MAX_RR_BINDING_LIFE (420 seconds). This means that binding between HoA and CoA at the CN will only remain valid for 7 minutes after the BU reception. If this CoA is to be used to reach the HoA after this period, a new BU message binding the HoA and the CoA has to be sent. However, as it has been presented earlier, BU authorization data has to be acquired using the RR procedure, which implies communication through both the CoA and the HoA. In the multi-homing scenario, the RR procedure can not be performed once that an outage occurred along the initial path, since the HoA is unreachable. This constraint means that if the MIPv6 protocol is used for preserving established communication in multi-homed environments, such communication can only be preserved during 7 minutes after an outage occurs. This seems to be a severe limitation for this application, since outages can last longer than 7 minutes and many communications last longer that 7 minutes. It is then deemed necessary to overcome this limitation if the MIPv6 is to be applied to solve the multi-homing problem. However, this limitation exists in the MIPv6 specification due to relevant security considerations, which will be presented in the next section. It is the goal of this note to present a modification to the MIPv6 specification that overcomes this limitation but preserves the current security level of MIPv6. 3.3 Security Concerns that lead to reduced BCE lifetime. BCE lifetime has been limited to a few minutes in order to limit the possibility of time shifting attacks,as it is presented in [3]. The goal of MIPv6 security is to avoid the introduction of new security hazards which are not present in non-MIPv6 enabled environments. In particular, the goal of the RR procedure is the reduction of the set of potential attackers to those who can Bagnulo, et al. Expires September 30, 2003 [Page 6] Internet-Draft Extended BCE lifetime for multi-homing April 2003 intercept packets flowing between the Mobile Node and the CN. This procedure forces the attacker to be present somewhere along the path between the mobile node and the correspondent node in order to acquire valid authorization data needed to generate forged BU messages. However, this mechanism by itself only imposes that the attacker has to be present on the path the time needed to intercept the messages that carry authorization information. Once that the attacker has intercepted valid authorization information, he can leave his position along the path and still perform attacks using such information. These are called time shifting attacks since an attacker that once was on-path intercepting packets can perform attacks in the future when he is no longer on the communication path. A possible time shifting attack can be performed by using previously acquired authorization information to forge BU messages. In this case, once the attacker has obtained the valid authorization information, he can generate as many valid BU messages as he wishes from any location, as long the authorization information is still valid. In order to reduce this type of attacks, MIPv6 specification limits the lifetime of authorization data to 240 seconds through the MAX_NONCE_LIFE constant. This means that the attacker will only be able to forge BU messages for maximum period of 4 minutes after obtaining the information. As we have presented earlier, while this timer imposes additional difficulties for the application of MIPv6 to the multi-homing problem, these difficulties can be surmounted without requiring any modification to the MIPv6 specification and what is more, the imposed message exchange can be used as a failure detection mechanism. While the reduced lifetime of the authorization information limits the time frame during which the attacker can generate forged BU messages, it does not prevent the usage of forged BU messages generated during the validity time frame. This means that another time shifting attack can be achieved by in the following way: the attacker placed along the communication path intercepts authorization information and generates a forged BU message. The attacker leaves the position but the attack continues since the traffic is still diverted to the CoA contained in the fake BU message. The effect of this attack is limited by reducing BCE lifetime in the CN to 7 minutes, imposing the generation of a new BU message in order to restore the BCE. Since the attacker is no longer along the communication path, he will not be able to generate new BU messages. This limited BCE lifetime drastically reduces the benefits of a multi-homing solution based in the MIPv6 protocol, as it has been presented earlier. This is because established sessions can only be preserved during the BCE lifetime, which is deemed to be Bagnulo, et al. Expires September 30, 2003 [Page 7] Internet-Draft Extended BCE lifetime for multi-homing April 2003 insufficient. The goal of this document is to suggest modifications in the node behavior defined in MIPv6 in order to surmount these limitations. Bagnulo, et al. Expires September 30, 2003 [Page 8] Internet-Draft Extended BCE lifetime for multi-homing April 2003 4. Proposed modifications to the MIPv6 specification A proper multi-homing solution must preserve established communications for at least a period of 2 hours (This is a tentative value that needs further consideration). So, in order to enable a MIPv6 based multi-homing solution it is required to increase the value of the MAX_RR_BINDING_LIFE constant to 7200 seconds. This modification alone would unacceptably increase the potential time shifting attacks, so additional modifications are needed to restore the security of the solution. The first modification proposed to restore the security refers to the mobile node behavior. Since it is in the mobile mode best interest to protect itself against forged BU messages causing the diversion of traffic addressed to it toward the attacker, it is proposed that part of the defense against time shifting attacks, that currently reside in the CN timers, to be transferred to the mobile node. This is achieved by requiring the mobile node to defend its address through periodic BU messages. So, the mobile node periodically sends BU messages every 420 seconds to the CN in order to refresh the BCE in the CN. This action limits to 420 seconds the time that the mobile node is exposed to a time shifting attack where an attacker has sent a forged BU message and the traffic is being diverted to an alternative address. From the mobile node perspective, this solution is as secure as the previous one. However, not only mobile nodes are exposed to time shifting attacks, but fixed nodes are susceptible to this type of attacks. For instance, an attacker can generate a forged BU message, binding a fixed node address to an alternative address, in order to divert traffic to that node to an alternative location. Since the fixed node is not required to have MIPv6 capabilities, it will not be able to defend its address through BU messages as the mobile node does. In this case, it is proposed that, the CN must send a Binding Refresh Request (BRR) to the HoA included in the BCE if the BCE has not been refreshed by the mobile node for 420 seconds. In the case that this is a legitimate BCE, the mobile node will send a BU to refresh it. In case that this is fake BCE, the fixed node will reply to the BRR message with an ICMP Parameter Problem [4]. Then, upon the reception of an ICMP Parameter Problem message, the CN has to delete the correspondent fake BCE from the cache, terminating the attack. This restores the security for fixed nodes. Finally, a time shifting attack can be performed even when the attacked address has not been assigned to a node. In this case, no node will reply to the BRR message with a ICMP Parameter Problem message. However, if this address has been assigned to a particular subnet, the last hop router will return an ICMP Destination Bagnulo, et al. Expires September 30, 2003 [Page 9] Internet-Draft Extended BCE lifetime for multi-homing April 2003 Unreachable message containing a Address Unreachable Code. Note that this message differs from the one generated when no route to destination is available, in which case an ICMP Destination Unreachable message containing a No Route to Destination Code is to be sent (this message is the one to be sent in the multi-homing application). So when the CN receives an ICMP Destination Unreachable message containing a Address Unreachable Code, it must delete the correspondent BCE from the cache. This restores the security for address that have been assigned to a given subnet but that have not been assigned to a particular host. In the case of addresses that have not been assigned to any subnet, there is no last hop router, since these addresses do not belong to any existent subnet. So, the reply to the BRR message will be an will be replied by an ICMP Destination Unreachable message containing a No Route to Destination Code. In this case, the CN must not delete the correspondent BCE, since this is the same behavior that in the multi-homing application. Both cases are indistinguishable from each other, since in both cases there is no route to destination in one case because the destination prefix remains unassigned while in the other case because the route is unavailable because of an outage. Summarizing, the proposed changes are the following: - Set MAX_RR_BINDING_LIFE to 7200 seconds (tentative) - The Mobile Node must refresh the BCE of the CN through BU messages every 420 seconds. - The CN must send BRR for the BCE that have not been refreshed for 420 seconds. - The CN node must set to expired those BCE whose correspondent BRR message has been replied with an ICMP Parameter Problem message. - The CN node must set to expired those BCE whose correspondent BRR message has been replied with an ICMP Destination Unreachable message containing a Address Unreachable Code. The proposed changes enable a multi-homing solution that preserves established communications for 2 hours. Bagnulo, et al. Expires September 30, 2003 [Page 10] Internet-Draft Extended BCE lifetime for multi-homing April 2003 5. Security Considerations This note proposes changes to MIPv6 security. The reader is referred to section xx for the risks that the modified security features prevent and to section xx for an analysis of how the proposed changes deal with these risks. Additional security consideration refer to the resulting MIPv6 based multi-homing solution. Hosts within the multi-homed site are also susceptible to time shifting attacks. If such attacks are performed while the communication is established using the address selected as HoA, the periodical performance of the RR procedure would limit its effect. However, if the attack is performed when the HoA is no longer available, it is possible that the attacker is capable of diverting the traffic without being detected. However, in order to perform such attack, the attack must be launched while the outage is occurring, which imposes that the attacker have to have knowledge about the network status. Bagnulo, et al. Expires September 30, 2003 [Page 11] Internet-Draft Extended BCE lifetime for multi-homing April 2003 6. Acknowledgments The authors would like to thank Pekka Nikander for suggesting the creation of this document. Bagnulo, et al. Expires September 30, 2003 [Page 12] Internet-Draft Extended BCE lifetime for multi-homing April 2003 References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Internet Draft, Work in progress draft-ietf-mobileip-ipv6-21.txt, May 2002. [2] Bagnulo, M., Garcia-Martinez, A. and I. Soto, "Application of the MIPv6 protocol to the multi-homing problem", Internet Draft, Work in progress draft-bagnulo-multi6-mnm-00, February 2003. [3] Nikander, P., Aura, T., Arkko, J. and G. Montenegro, "Mobile IP version 6 (MIPv6) Route Optimization Security Design Background", Internet Draft, Work in progress draft-nikander-mobileip-v6-ro-sec-00, March 2003. [4] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)Specification", RFC 2463, December 1998. Authors' Addresses Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es/marcelo Alberto Garcia-Martinez Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: alberto@it.uc3m.es URI: http://www.it.uc3m.es/alberto Bagnulo, et al. Expires September 30, 2003 [Page 13] Internet-Draft Extended BCE lifetime for multi-homing April 2003 Ignacio Soto Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: isoto@it.uc3m.es URI: http://www.it.uc3m.es/isoto Bagnulo, et al. Expires September 30, 2003 [Page 14] Internet-Draft Extended BCE lifetime for multi-homing April 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Bagnulo, et al. Expires September 30, 2003 [Page 15] Internet-Draft Extended BCE lifetime for multi-homing April 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bagnulo, et al. Expires September 30, 2003 [Page 16]