Network Working Group M. Bagnulo Internet-Draft Huawei Lab at UC3M Intended status: Standards Track March 4, 2007 Expires: September 5, 2007 Proxy Shim6 (P-Shim6) draft-bagnulo-pshim6-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This draft discusses extensions to the shim6 architecture to support shim6 proxies that would allow the provision of the following capabilities: o Provide Upper Layer Identifier portability. o Provide Traffic Engineering policy enforcement. o Off-load of the shim6 context management from the actual peers of the communication. Bagnulo Expires September 5, 2007 [Page 1] Internet-Draft P-Shim6 March 2007 o Enable legacy IPv6 nodes located in the multihomed site to obtain full multihoming support (no modification of the end nodes). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Centrally Managed Unique Local Addresses . . . . . . . . . 8 4.2. DNS component . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Reverse DNS . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. DNS Application Level Gateway . . . . . . . . . . . . 8 4.3. DHCP server component. . . . . . . . . . . . . . . . . . . 9 4.4. Proxy-shim component . . . . . . . . . . . . . . . . . . . 9 4.5. Firewall component . . . . . . . . . . . . . . . . . . . . 10 5. Application scenario . . . . . . . . . . . . . . . . . . . . . 10 6. Protocol walkthrough . . . . . . . . . . . . . . . . . . . . . 11 6.1. Fault Tolerance. . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. Path Failures. . . . . . . . . . . . . . . . . . . . . 14 6.1.2. Multiple P-Shim6 support. . . . . . . . . . . . . . . 14 6.1.3. P-Shim6 fault tolerance. . . . . . . . . . . . . . . . 15 7. Support for legacy sites and hosts. . . . . . . . . . . . . . 16 8. Compatibility with host based shim6 . . . . . . . . . . . . . 17 9. Alternative Design Choices . . . . . . . . . . . . . . . . . . 17 10. Other security mechanisms . . . . . . . . . . . . . . . . . . 21 11. Incompatibilities. . . . . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations. . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 22 14. Change History . . . . . . . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Bagnulo Expires September 5, 2007 [Page 2] Internet-Draft P-Shim6 March 2007 1. Introduction The shim6 architecture [11] provides scalable support for IPv6 end site multihoming. As opposed to the BGP-style multihoming, where the multihomed site injects its own prefix through the different providers, in the shim6 approach, a multihomed site obtains a Provier Aggregatable (PA) prefix from each of its providers' address blocks. This enables aggressive prefix aggregation in the global routing table, since the multihomed site prefixes do not need to be announced independently in the global routing table and only ISP PA prefixes are visible in the Default Free Zone. From the multihomed site perspective, this configuration results in the presence of multiple prefixes in the site (one per provider) and multiple global addresses configured in the hosts (again, one per provider). The goal of the shim6 protocols [6] [8] is to preserve established communications through outages in the paths to the multihomed site. The shim6 protocol [6] is an end-to-end protocol that is used to create shim6 contexts between the peers of a communication that contain the different addresses available for the communication. The shim6 architecture inserts a shim6 sublayer between the IP endpoint sublayer and the IP forwarding sublayer. The shim6 sublayer uses the shim6 context state to map between the address used by the upper layers (know as the Upper Layer Identifier ULID) and the actual addresses used for forwarding packets (called locators). The shim6 peers use the shim6 protocol to securely exchange the multiple addresses available for each end of the communication so that in case a failure is detected in the communication path, an alternative address can be used as locator, while still presenting an unchanged ULID. Summarizing, the main characteristics of the shim6 architecture are: o One prefix per ISP (PA addressing), resulting in multiple addresses per host. o All the addresses can be used as ULID and/or locators for any communication. o The involved protocols (shim6 protocol and REAP protocol) are end- to-end protocols used to securely create and manage the ULID- locator binding information. The result is a clean architecture where the peers are aware of the multiple addresses and can securely exchange context information that binds all the different addresses of a given host. In addition, the failure detection and recovery is also performed end to end providing optimal fault tolerance within the fate-sharing region. However, it has been pointed out [10] that the shim6 protocol does fail to provide some key features provided by current BGP-based approach to multihoming. In particular, the shim6 approach fails to Bagnulo Expires September 5, 2007 [Page 3] Internet-Draft P-Shim6 March 2007 provide the so-called portability of the address block used by the multihomed site. This basically means that when a multihomed end site changes one of its providers, the addresses associated to this ISP need to be renumbered. Renumbering may be a costly and painful process, so imposing address renumbering when changing providers does increase provider lock-in. Another capability that is missing in the shim6 architecture is traffic engineering policy enforcement capabilities. The shim6 approach supports some forms of traffic engineering, but because of its end-to-end nature, the traffic engineering capabilities are available at the end-nodes, making it hard to actually enforce the traffic engineering policies at a site level. Finally, it has also been mentioned that for deployment and performance issues, it may be important to be able to off-load the shim6 context management from the end nodes to specialized middle boxes. This draft proposes some ideas to extend the shim6 architecture to support shim6 proxies that would allow the provision all the aforementioned capabilities and discusses difficult issues with it.. 2. Goals The goals of the design of shim6 proxies are the following: o Provide Upper Layer Identifier portability. o Provide Traffic Engineering policy enforcement. o Off-load of the shim6 context management from the actual peers of the communication. o Enable legacy IPv6 nodes located in the multihomed site to obtain full multihoming support (no modification of the end nodes). o Do not require any modification to the routers of the "core". o Allow shim6 peers to communicate with nodes served by a P-shim6 box while benefiting of the multihoming features. o Do not introduce additional vulnerabilities to the Internet. The goal of this draft is to provide an in depth discussion of the difficult issues that need to be taken into account when designing a proxy type of solution. Since we think that the difficulties are more clearly identified when the details are fleshed out, we have decided to use existent tools for the provision of the needed services. In particular, we have decided to use Centrally Managed Unique Local Addresses which have been discussed previously, as provider independent ULIDs. In addition, we have decided to use the reverse DNS to retrieve locator information for those ULIDs. It should be noted that it would be possible to use alternative ULIDs and alternative mechanisms to retrieve the locator information, but we consider that using existent tools would help to have a clearer picture of the issues involved. See Section "Alternative Design Bagnulo Expires September 5, 2007 [Page 4] Internet-Draft P-Shim6 March 2007 choices" for additional information. 3. Overview In this approach, a multihomed site obtains a PA prefix from each of its providers and a non-routable Provider Independent prefix from a central registry (e.g. a Centrally Managed Unique Local Address (CMULA) prefix [12]). Hosts within the multihomed site are IPv6 hosts without any shim6 support and they are configured only with a single address containing the CMULA prefix. This means that the addresses configured to the hosts in the multihomed site do not depend of the ISPs and that a change in the ISP would not imply a renumbering of the hosts of the multihomed site. In this approach, all the addresses information is published in the DNS. PA addresses are published in AAAA RR while CMULAs are published in a new ULID RR. The multihomed site is served by one or more Proxy-Shim6 (P-shim6) boxes. The P-Shim6 box will execute the shim6 protocol on behalf of the hosts of the multihomed site. The peer of a external communication can be a host located in another multihomed site or in a single-homed site. In any case, in order to enable the shim6 support for the communication, either the peer needs to be shim6-capable or it is behind another P-shim6 box that is executing the shim6 protocol on its behalf. In the latter case, the result is that the shim6 protocol is executed between the P- shim6 boxes that are serving each of the peers of the communication. The proposed approach would work as follows. When a (non-shim6 capable) host H1 located within the multihomed site (see figure 1 below) initiates a communication with a peer host H2, H1 normally performs a DNS query searching for H2.foo.com. The query processed by a DNS ALG located in the P-Shim6 box of the multihomed site and both AAAA and ULID records are queried for. The reply is processed by the DNS ALG of the multihomed site and only the CMULA is returned to H1 in a AAAA RR. From the perspective of the legacy host H1 within the multihomed site, it is a regular DNS query that has returned a single AAAA record. In addition to that, the P-Shim6 box stores the PA address information returned in the original DNS reply in the AAAA RR associated to the CMULA identifier obtained. When H1 sends the first packet addressed to the CMULA of H2, the packet is intercepted and processed by the P- Shim6 box of the multihomed site. The P-Shim6 box retains the data packet and Bagnulo Expires September 5, 2007 [Page 5] Internet-Draft P-Shim6 March 2007 initiates the 4-way exchange to create a shim6 context with the P-shim6 box of the peer network. This exchange uses the PA addresses as locators and the CMULAs as ULIDs. Once that the shim6 context is established between the local P-shim6 box and the remote P- Shim6 box, the local P-Shim6 box can forward the data packet with a shim6 payload header, referring to the established shim6 context. This communication is now protected by the shim6 protocol, in the sense that the reachability detection mechanisms of the REAP protocol will monitor the path availability of the communication. In case a failure is detected, alternative locator pairs will be explored and the communication will be diverted to the alternative locator pair that is available. Once that the communication stops, the P-shim6 boxes discard the associated shim6 state. The result is that the legacy nodes within the multihomed site benefit from the multihoming fault tolerance capabilities. Besides, the hosts only have provider independent (non routable) addresses configured, reducing the renumbering costs in case of a change of providers. Finally, the P-shim6 box is the one managing the locator set, so it is capable of enforcing traffic engineering policies for the site and it can also off-load the shim6 processing from hosts within the multihomed site. Bagnulo Expires September 5, 2007 [Page 6] Internet-Draft P-Shim6 March 2007 +---------------------------------------------+ | Multihomed site | | Prefixes : PA1, PA2, PU | | +---------+ | | |non-shim6| | | | host H1 | +---------+ | | +---------+ | DNS ALG | | | | PU:H | P-shim6 | | | -------------------- +---------+ | | | | | | ------------------------------- | | | | | | +--------+ +---------+ | | |Router 1| | Router 2| | | +--------+ +---------+ | +---------------|------------------|----------+ | | +-------+ +-------+ | ISP 1 | | ISP 2 | +-------+ +-------+ | | +------------------------------------+ | Internet | +------------------------------------+ | +-------+ | ISP 3 | +-------+ | +------------------------------------|-------+ | +--------+ +--------+ +--------+| | |Host H2 | |P-shim6'| |Router 3|| | +--------+ +--------+ +--------+| | H2.foo.com | | | | | PU':H | | | | | ---------------------------------------- | | Site foo.com Prefixes: PA3, PU' | +--------------------------------------------+ Figure 1 4. Components The proposed P-shim6 approach has the following components: Bagnulo Expires September 5, 2007 [Page 7] Internet-Draft P-Shim6 March 2007 4.1. Centrally Managed Unique Local Addresses In the P-shim6 approach, the hosts within the multihomed site are configured with a single address, the ULID. It is proposed that in order to provide address portability, the ULID used are a form of Centrally Managed ULAs (CMULAs) [12]. CMULAs have been proposed before and while the exact form of the addresses does not need to be the one proposed in the past, the following characteristics are required by the P-shim6 approach: o They must be globally unique. o They must not be dependent of the location of the network to which they are assigned. o They are permanently allocated to the end site. So, in the P-shim6 approach, an end site can obtain a CMULA block that is independent of its ISP and it will be used as ULIDs for shim6 contexts. 4.2. DNS component As we mentioned above, the hosts within the multihomed site are configured with a single CMULA, which are by definition non globally routable. In order to allow external peers to initiate communications using the CMULAs as ULIDs, it is necessary to publish these CMULAs in the DNS. However, these CMULAs are not globally routable, so, in order to prevent an external non-shim6 aware node to try to use the CMULAs as a regular routable address, it is necessary to store the CMULAs in a different DNS resource record. It is then proposed the definition of a new ULID RR for storing ULIDs. So, the DNS of the multihomed site is configured to publish routable addresses in AAAA records and CMULAs in the new ULID records. 4.2.1. Reverse DNS The reverse tree of the DNS is used to retrieve the locator set associated to the CMULAs in case that there is no cached locator information available. This basically requires that the reverse DNS tree of the CMULAs is properly populated. So when a reverse DNS lookup is performed for a CMULA, the FQDN is returned and the locator information can be included in the additional information field of the DNS reply. 4.2.2. DNS Application Level Gateway In the proposed shim6 approach, the goal is that communicating peers located in different sites communicate using the ULAs as ULIDs. In order to achieve that, when a (legacy) host located behind the P-shim6 within the multihomed site performs a DNS query to initiate a Bagnulo Expires September 5, 2007 [Page 8] Internet-Draft P-Shim6 March 2007 communication with the remote host that is located behind another P-shim6 box, the CMULA should be returned in the AAAA record correspondent to the FQDN queried. However, in the DNS configuration described in the previous paragraph, the CMULAs are stored in the ULID RR and the routable addresses are stored in the AAAA records, so if no additional processing is performed, the hosts behind the P-shim6 box would use the PA addresses as ULIDs. The P-shim6 needs a DNS ALG component that transform the DNS reply so that the CMULA is included in the AAAA RR and the routable addresses are removed from the reply. In addition, the DNS ALG component should store the routable addresses associated to the CMULA, so that they can be used to establish the shim6 context for that (future) communication. For intra-site communications, hosts will use CMULAs. So, in this case, the DNS should also return the CMULAs of the internal hosts in AAAA records for internal queries. So again, the DNS ALG should process the DNS reply so that the CMULAs are returned in AAAA records. 4.3. DHCP server component. The shim6 security relies on the usage of CGA or HBA [5], [7] addresses to protect the binding between the ULID and the locator set. In order to extend the shim6 approach to shim6 proxies, it is necessary that the addresses configured in the hosts within the multihomed site are CGAs or HBAs. However, as the hosts themselves are not involved in the shim6 protocol, the end hosts do not need to be aware that the address assigned is a CGA or HBA neither they need to know the associated parameters. So, in the P-shim6 approach, the CGA and HBA addresses are generated by the proxy (which stores the correspondent parameters) and then, they are assigned to the end hosts using the DHCP protocol [2]. This is performed by the DHCP component of the P-shim6. 4.4. Proxy-shim component Once that a host behind the P-Shim6 initiates a communication sending a packet containing an external CMULA as destination address and a CMULA as source address, the packet is intercepted by the P-shim. At this moment the P-Shim6 establishes a shim6 context with the shim6 peer or the shim6 proxy of the peer. Once that the context has been established the packets are translated and locators associated to the established context are included in the address fields of the packet. These functions are performed by the Proxy-shim component. Bagnulo Expires September 5, 2007 [Page 9] Internet-Draft P-Shim6 March 2007 4.5. Firewall component In order to provide address portability, it is desired that the CMULAs are used instead of the routable addresses in the configuration data on any process that needs to hardcode addresses. In particular, it is expected that CMULAs are used in filters and ACL in firewalls. However, in order to do that, the firewall must be placed behind the P-shim, so that packets carry CMULAs and not locators. It is possible then to include a firewall component in the P-shim6 so that packets can be filtered as soon as the locators are translated into CMULAs. 5. Application scenario The P-Shim6 approach is used in the following scenario (see figure 1). Consider a multihomed site served by ISP1 and ISP2. Each of the ISPs delegates a Provider Aggregatable address block to the multihomed, prefixes PA1 and PA2 respectively. Since addresses are PA, the address block delegated by ISPA can only be reached through ISPA and the address block delegated by ISPB can only be reached through ISPB. Besides, we assume that ISPs are performing ingress filtering, meaning that packets containing source address belonging to the address block delegated by ISPA(B) can only exit through ISPA(B). In addition, an CMULA block (prefix PU) is delegated to the site so that they can be used as ULIDs for shim6 communications. So, each host within the multihomed site has conceptually 3 addresses i.e. a CMULA from prefix PU and one address per PA prefix available in the site, prefixes PA1 and PA2. If HBAs are used, then the HBA set must be generated using the 3 prefixes available for the site. The HBA technology is less demanding in terms of CPU processing, since it doesn't requires performing public/private key cryptographic operations. However, the usage of HBA technology would defeat the goal of portability, since a change in the prefix set available in the site would result in a change in the addresses, in particular in the CMULAs assigned to the hosts. So in order to provide ULID portability, CGA technology needs to be used. If CGAs are used, it is necessary to generate the CMULAs assigned to the hosts within the multihomed site as CGAs. However, because the shim6 processing will be performed by the P-shim, the CGA Parameter Data Structure and the associated private key must be known by the P-shim6 box and not by the end host itself. The proposed approach is Bagnulo Expires September 5, 2007 [Page 10] Internet-Draft P-Shim6 March 2007 that the DHCP component of the P-Shim6 generates CMULA CGAs on behalf of the hosts that are located behind the proxy and it stores the associated parameters (CGA parameter Data structure and private key). Once that the CGA CMULA is generated, it is assigned to the host using the DHCP protocol as a regular address i.e. the host does not need to be aware that the assigned address is a CGA. Observations: a. It is possible for the P-Shim6 to generate all the CMULA CGA using the same key pair, and only changing the Modifier field of the CGA Parameter Data Structure. This allows the P-shim6 box to only have a single key pair for all its shim6 contexts. b. It is possible to use Multi-key CGA [14] in two cases: 1. When the hosts within the multihomed site need to use CGA for other protocols, such as SeND [4]. In this case, the CGA will have two keys, the key of the host to do SeND and the key of the P- Shim6 to do shim6. Additional mechanisms to allow the DHCP server to learn the public key of the host and to allow the DHCP server to convey the CGA Parameter Data Structure are needed. 2. When there are multiple P-Shim6 and each of them has a different key pair. In this case, in order to provide fault tolerance when one of the proxies fails, the CMULA CGAs need to be generated containing both public addresses. In addition to the CMULA CGA, the P-shim6 will (virtually) assign one address from each PA prefix available in the multihomed site to each host. Such address is not configured in the host itself, since they only play the role of locator, so they are only used by the P-shim. Besides, the hosts served by the P-Shim6 need to be configured with the P-Shim6 as a DNS server (in order to use the DNS ALG) and packets generated by the hosts served by the P-Shim6 containing a destination address with a CMULA prefix need to be routed through the P-shim. Similarly, incoming packets addressed to the PA prefixes used by the P-Shim6 box are routed to the P-Shim6 box to be processed before delivery to the end nodes.In general, the P-Shim6 is implemented as a stand- alone box, and it must inject a route to the CMULA prefix and a route to the PA prefixes it is using, so that all packets addressed to CMULAs and to its PA prefixes are sink to the P-shim6 box. 6. Protocol walkthrough In summary, the P-Shim6 application scenario is the following (depicted in figure 1): Bagnulo Expires September 5, 2007 [Page 11] Internet-Draft P-Shim6 March 2007 o The site has 3 prefixes: PA1, a PA prefix delegated by ISP1 from its own PA block, PA2, a PA prefix delegated by ISP2 from its own PA block and PU, a CMULA block, obtained by the site, independently of its providers. o The hosts within the site have obtained addresses containing PU from the DHCP server of the P-shim. The delegated addresses are CGAs, and the P-Shim6 stores the associated information, including the key pair and the CGA Parameter Data Structure corresponding to each delegated address. o The hosts within the site have configured the P-Shim6 as their DNS server, so they will forward all DNS queries to it. o The P-Shim6 box is announcing routes in the IGP towards the generic prefix of the CMULAs and to the PA prefixes used by the P-Shim6 approach to generate locators. The first route sinks outgoing packets containing a CMULA destiantion address and the second route will sink incoming packets containing locators as destiantion addresses (instead of ULIDs). We are assuming that the intra site is announcing more specific routes to the interanlly used CMULA prefixes, so that internal communications that use the CMULA assigned prefix will not be sink to the P-Shim6 box. With this setup, the behaviour of the P-Shim6 solution is the following: 1. A host H1 behind the P-Shim6 wants to initiate a communication with a host H2 located outside the multihomed site with FQDN H2.foo.com. For that, it performs a DNS query to its DNS server (the P-Shim6 box) for H2.foo.com. 2. The P-Shim6 box performs a DNS query for H2.foo.com. If the query returns a ULID RR and one or more AAAA/A records, then the P-Shim6 stores the information about the ULID and the associated locators and returns a single AAAA RR in the reply containing the CMULA (PU':H2) to H1. At this point, the P-Shim6 can assume that H1 will start sending data packets to that destination and it can initiate the 4-way handshake defined in the shim6 protocol to establish a shim6 context. The other option is to wait until the reception of the first data packet addressed to the CMULA. 3. When the host H1 receives the DNS reply containing a CMULA PU':H2 in the AAAA record, it will start sending packet to the received address. Because of the longest prefix match of the address selection algorithm defined in RFC3484 [3], host H will choose the CMULA as source address. 4. The intra site routing will forward packets containing an external CMULA as destination address to the P-Shim6 box. When a packet containing a CMULA as a destination address arrives, the P-Shim6 box performs the following processing: Bagnulo Expires September 5, 2007 [Page 12] Internet-Draft P-Shim6 March 2007 A. If a shim6 context exists with the addresses contained in the packet as ULID pair, then it uses the existing shim6 context to process the packet (the context may be already in use, or may be just created when the DNS reply was received). B. If no shim6 context exists, but there is locator information associated to the CMULA contained in the destination address (cached from the DNS reply), it will use that locator information to initiate the 4-way handshake to create a shim6 context for that ULID pair. Once that the shim6 context is established, it is used to process the packet. C. If no shim6 context exits and there is no locator information associated to the destination CMULA cached, the P-Shim6 box performs a DNS reverse lookup on the CMULA contained in the destination address field, and it obtains the locator set associated to the CMULA. Once that the locator information is obtained, the 4-way handshake used to establish the shim6 context is performed. Once that the shim6 context is established, it is used to process the packet. 5. From the H2 (the receiver) perspective, incoming packets are forwarded to the P-Shim6 box: A. If the packet is an I1 or an I2 packet of the shim6 protocol, it will continue with the 4-way handshake for the establishment of the shim6 context. B. If the packet is a payload packet and the P-Shim6 box has an existent context associated with it, it will process the data packet and replace the locators by the associated identifiers and the forward the packet to the final destination. C. If the packet is a payload packet and the P-Shim6 box does not have an associated shim6 context, it will initiate the context recovery procedure, sending a R1bis packet back, so that context can be restored. 6. Once that the shim6 context is established, the communication continues and both P-Shim6 boxes perform the translation between ULIDs and locator pairs as needed. In addition the REAP protocol for failure detection and alternative path exploration is used when needed, as defined in the shim6 protocol. 7. When the communication is finished, the P-Shim6 boxes will use some heuristics to discard the shim6 context. The P-Shim6 box is a stand alone box and we have presented mechanisms to divert the traffic towards those P-Shim6 boxes. Because of ingress filters, it may be necessary to route packets containing a given prefix in the source address through the ISP that has delegated this prefix. This can be achieved using tunnels from the P-Shim6 box to the exit routers, and allowing the P-Shim6 box to route packets containing a given prefix in the source address through the correspondent ISP. Bagnulo Expires September 5, 2007 [Page 13] Internet-Draft P-Shim6 March 2007 6.1. Fault Tolerance. 6.1.1. Path Failures. The shim6 protocol executed between the P-Shim6 boxes will use the REAP protocol to detect failure along the communication path and explore alternative paths. Once a failure is detected and an alternative path is discovered, the P-Shim6 will divert the existent context affected by the failure through the new path, using the associated locator pair. It should be noted that it is also possible to feed the P-Shim6 box with additional information that can be used for failure detection. In particular, the P-Shim6 box can be feed with BGP information from the different ISPs. In this case, the P-Shim6 box would have access to routing information and could divert the communication through alternative ISP in case of a failure. In this case, it is also possible for the P-Shim6 box to inform the P-Shim6 peer that a given locator is no longer reachable using the BROKEN flag of the Locator Preference Option defined in the shim6 protocol 6.1.2. Multiple P-Shim6 support. Since the main goal of multihoming is fault tolerance, it is critical to support multiple P-Shim6 boxes in a multihomed site and that established communications can be preserved in case of a failure in the P-shim6 box that is being used for that communication. This can be done using the shim6 context recovery features. We will next consider the setup required to support multiple P-Shim6 in a single site. The described configuration uses one P-shim6 box as the primary proxy for the multihomed site and the other P-shim6 box as a backup in case the primary box fails. The interaction between the P-Shim6 box and the host being served by it involves the following interactions: 1. Delegation of CGA/HBA CMULA and storing the associated parameters. 2. The host uses the P-Shim6 as DNS server and the P-Shim6 box performs as a DNS ALG. 3. All packets generated by the host that are addresses to an external destination pass through the P-Shim6 box, which establishes the correspondent shim6 context and then performs the appropriate ULID-locator translation. 4. All incoming packet for that hosts are processed by the P-Shim6 host, which restores the ULIDs. It should be noted that all these operations result in state in the Bagnulo Expires September 5, 2007 [Page 14] Internet-Draft P-Shim6 March 2007 P-Shim6 box. With respect to the CGA related information, all the P-Shim6 boxes within a site must have access to the CGA Parameter Data structure of each CMULA address assigned to a host within the site. With respect to the private key information, there are two options: one is that the same private key is distributed to all the P-Shim6 boxes within a site. The difficulty with this approach is that private key distribution always implies security risks. The other option would be to use multi-key CGAs. In this approach, each P-Shim6 box would have a key pair, and the CGAs assigned to the hosts within the site would contain the public key information of all the P-Shim6 boxes, allowing all of them to establish shim6 contexts on behalf of any of the nodes. With respect to the other interaction, the configuration required is the following: o With respect to the DNS server component. It is possible to configure a primary DNS server and a secondary DS server in the hosts. The primary DNS server would be the primary P-Shim6 box and the secondary DNS server would be the backup P-Shim6 box. The hosts will always try with the primary DNS server first, and in case there is a timeout, they will retry with the secondary one. o With respect to outgoing data packets, they must be forwarded through the primary P-Shim6 box as long it is working. This is achieved by configuring the primary P-Shim6 box to announce a route towards the generic CMULA prefix with a high priority and the backup P-Shim6 box to announce a route to the generic CMULA prefix with a low priority. In case of a failure of the primary P-Shim6 box, the associated route would disappear and the alternative routes associated to the backup P-Shim6 box would be used. o With respect to incoming packets, the primary P- Shim6 box will announce a route to the globally routable prefixes used to generate locators for the hosts within the multihomed site with a high preference, so that all packets coming from the Internet are sink to the primary P-Shim6 box. The backup P-Shim6 box also announce a route to these prefixes, but with a lower preference. 6.1.3. P-Shim6 fault tolerance. In case the primary P-Shim6 box fails, the ongoing communications that have been established by the P-Shim6 box need to be preserved. This can be done by diverting the communications towards the secondary P-Shim6 box and allowing it to recover the shim6 context associated with the ongoing communication. We assume that when a P-Shim6 box fails, the associated routes are no Bagnulo Expires September 5, 2007 [Page 15] Internet-Draft P-Shim6 March 2007 longer announced. This implies that the routes to the secondary P- Shim6 box will become the preferred ones. So, after the primary P-Shim6 box has failed, the following packets that belong to an ongoing communication can reach the secondary P-Shim6 box: o An incoming packet with a destination address containing the global prefix of the primary P-Shim6 box and a Payload header with a context tag (this can be a data packet or a probe packet from the REAP protocol). The secondary P-Shim6 box will receive the packet and it will find that there is no existent context for that packet. The secondary P-Shim6 box will reply with a R1bis packet and the context recovery mechanism of the shim6 protocol will be executed. This consists in a 3 way handshake with the other end which results in the recovery of the lost context. o An outgoing packet coming from one of the internal hosts is received. The secondary P-Shim6 box will unsuccessfully look for an existent shim6 context of for cached locator information retrieved from the DNS query. Since there is no locator information associated with the destination identifier, it will perform a reverse DNS query and it will obtain the locator information. At this point it will perform the 4 way handshake and the shim6 context will be re-established. 7. Support for legacy sites and hosts. In order to allow communication between hosts within the multihomed site and external non-shim6 hosts that are not served by any P-Shim6 we will need additional tools. In this section we will consider two approaches to communicate with legacy IPv6 hosts. A first option would be to configure globally routable addresses from the prefixes delegated by the ISPs to the nodes within the multihomed sites. According to the longest prefix match defined in RFC3484, CMULA source addresses are preferred over PA addresses when the destination address is also a CMULA and that PA addresses are preferred as source addresses when the destination address is a globally routable address. This implies that hosts would select globally routable addresses when communicating with other globally routable addresses and the P-Shim6 would not intervene in such communications. However, it should be noted that allowing the hosts to have access to global routable addresses enable the host to bypass the P-Shim6 diminishing the capability of the P-Shim6 to enforce traffic engineering policies. The configuration of PA addresses in the hosts also imposes additional renumbering cost when changing ISP, limiting the benefit of portability. The trade-offs involved in this scenario are: portability and TE enforcement versus backward Bagnulo Expires September 5, 2007 [Page 16] Internet-Draft P-Shim6 March 2007 compatibility and reduced latency. The other option to support communications with legacy hosts is to enable the P-Shim6 boxes to behave as a NATv6. In this case, the P- Shim6 box would simply translate the CMULA to one of the globally routable addresses. Of course this present some of the limitations of NAT in IPv4, including that the address is not restored end to end, and so if addresses are included as application layer information, they will not match with the address actually contained in the header. However, since it is possible to perform a stateless one to many mapping between the CMULA and the global addresses, some of the limitations of NATs in IPv4 are lifted. In particular, it would be possible to receive externally initiated communications with a node behind the NAT without need for NAT traversal mechanisms and there is no need to use additional tools to keep the NAT state alive. It is important to note that this is just a mechanism to support legacy hosts and it is expected to be merely a transition tool. This approach preserves all the features of the P-Shim6 approach, including portability and TE enforcement. 8. Compatibility with host based shim6 The proposed approach is compatible with host based shim6. this means that is possible for a shim6 host to establish a shim6 context with a proxy shim6 box and use that context to provide multihoming benefits for the communications established between the shim6 host and the hosts served by the proxy shim6. However, for this, it is necesary that the shim6 host has pupulated the DNS reverse tree corresponding to the ULID that it is using for the shim6 context. This is so, because the P-Shim6 approach relies on the DNS reverse tree in order to obtain the locator information associated with the target ULID in case that one of the P-shim6 boxes fail and the backup P-shim6 needs to restore the shim6 contexts. In addition, the shim6 hosts should support the new ULID RR in order to establish the shim6 context with the unroutable ULIDs used by the hosts served by the P-shim6. 9. Alternative Design Choices The presented approach provides a set of features and relies on a set of components. However, it should be noted that it is possible to provide a subset of the features using a subset of the components and that some of the components can be sustituted by alternative ones. In this section we describe which components are needed for which features and we also describe which other options could be used to replace some of the selected componenets. Bagnulo Expires September 5, 2007 [Page 17] Internet-Draft P-Shim6 March 2007 We will start by identifying which components are required for which feature. Centrally Managed Unique Local Addresses Centrally Managed Unique Local Addresses are used to provide provider independence i.e. avoid provider lock-in. Using CMULAs allows the multihomed site to have provider independent identifiers and in the presented approach, the hosts within the multihomed site are only configured with CMULAs, greatly reducing the cost of a renumbering event. PA addresses are only configured in the P-Shim6 boxes, so in case of a change in one of the ISPs, only the P-Shim6 boxes need to be reconfigured. It should be noted that it is perfectly possible to use the P-Shim6 approach presented in this document with regular PA addresses as identifiers. In this case, the hosts would be configured with PA addresses and the cost of a renumbering event would increase increasing also the provider lock-in. In addition it should be noted that alternative provider independent identifiers could be used, such a regular PI address space. DNS Reverse tree The DNS reverse tree is used in this approach to restore ULID to locator mapping information in backup P-Shim6 boxes for ongoing communications in case that the primary shim6 fails. In case that a single P-Shim6 box is used in a site, there is no need to populate the reverse DNS tree. In case that alternative fault tolerance measures are in place (like mirrored P-Shim boxes) there reverse DNS population is not required. In addition, alternative mechanisms to distribute ULID to locator mapping information among P-Shim6 boxes can be used instead of the reverse DNS (more in this below) ULID RR ULID RR is used to store information about addresses that are not globally routable and that are only meant to be used as ULID for shim6 context and not as locators. Again, this is only needed to support non routable ULIDs, which are required to provide provider independence. In the case that routable addresses (PA addresses for isntance) are used as ULIDs, this new ULID RR would be no longer needed. DNS Aplication level Gateway DNS Application Gateway is used to translate information ontained in the newly defined ULID RR and presented to legacy hosts in a AAAA record. This is needed to support unmodified legacy hosts and provider independence through PI identifiers. In the case that no Bagnulo Expires September 5, 2007 [Page 18] Internet-Draft P-Shim6 March 2007 provider independence is needed, and routable addresses are used as ULIDs, the DNS ALG would be no longer needed. Similarly, if it can be asumed that the hosts in the multihomed site can understand the new ULID RR the DNS ALG would be no longer needed. Dual faced DNS The current proposal asumes that the DNS server in the multihomed site will return ULIDs in AAAA RR to internal queries and ULIDs in ULID RRs to external queries. Again this is needed when non routable provider independent ULIDs are used. If routable addresses are used as ULIDs (and no provider independence is required, there would be no need to dual faced DNS. Direct DNS population Direct DNS is used in the same way that it is currently used in non shim6 setups. It is used in order to allow eternal hosts to initiate communications with a FQDN. So DNS population is only required for hosts behaving as servers (i.e. they receive externally initiated communications). Clients do no need DNS entries. NATv6 NATv6 is required as a mechanism to comunicate with legacy hosts outside the multihomed site in the case that non routable ULIDs are being used i.e. in case provider independence is required. If provider independence is not required, then is is posible to use the alternative choice described in the document, which relies in configurating multiple PA addresses per host, increasing provider lock in. Firewall component Having a firewall component in the P-Shim6 boxes is also required to provide provider independence. This is so, because in order to facilitate renumbering we require that firewall rules will be configured using PI ULIDs rather than PA addresses. If provider independence is no required and routable addresses can be used as ULIDs, the regular firewalls can be used unmodified. CGAs and HBAs ULIDs must be either CGAs or part of an HBA set. In casethat provider independence is required, CGA are the only option, since a modification in one of the acialble prefixes in the site would result in a change in the ULIDs. So, again, the usage of only CGAs is required by the provider independence requirement. Bagnulo Expires September 5, 2007 [Page 19] Internet-Draft P-Shim6 March 2007 Summarizing Tools imposed by the Provider Independence requirement CMULAs or similar DNS ALG New ULID RR NATv6 Firewall component CGAs and not HBAs It would be perfectly possible to use the proposed approach wihtout the aforementioned components if provider independence is not required Alternative design choices In this document, we have made a certain choices in order to present the details of how a proxy based solution would be.In particular, we decided to use as much available tools as possible, in order to allow the reader to grasp in more detail the issues involved. However, it would perfectly possible to use alternative tools and even create new tools for providing the required features. In particular, the usage of the DNS reverse tree to retrieve alternative locator information could be replaced by alternative mechanism as we discuss below. The DNS reverse tree is used to retireve locator information associated with an unroutable ULID. In concrete, it is used in the following situation: A shim6 context has been established between a P-shim and a remote shim6 peer (either P-shim6 or a shim6 host). The P-shim6 that has the shim6 context information fails and the backup shim6 is used to continue with the communication. In order to do that, the context information must be restored. In this case, the backup P-shim6 needs to retrieve the locator information associated to the ULID of the remote peer. It does so, by performing a DNS reverse lookup for the CMULA used a ULID. However, it should be noted that the locator information was already available in the site, in particular, it was available in the primary P-shim6. So it would be perfectly possible to create an inter-P- shim6 protocol to exchange locator-ULID binding information between the primary and the backup P-shim6 as soon as the the context is created. This would distribute the locator to ULID binding Bagnulo Expires September 5, 2007 [Page 20] Internet-Draft P-Shim6 March 2007 information and there would be no need to retrieve it from the DNS reverse tree (and there would be no need to require the population of the reverse DNS tree if such inter-P-shim6 protocol was available. It must be noted that the reverse tree is never used to retrieve ULID locator binding information for initial contact, but is only used to restore information that was once available locally. this is why, it is perfectly possible to design local mechanisms to substitute the usage of the reverse DNS in the P-shim6 approach. 10. Other security mechanisms So far, we have used the security mechanisms currently defined in the shim6 protocols for P-shim. However, the shim6 protocol can be extended to support other security mechanisms to protect the binding between the ULID and the locator set. One possibility would be to use the DNS. This basically means that the DNS would serve as a trusted third party that would provide authoritative information about the binding between a CMULA and its locators. In terms of the protocol, this means that when the P-Shim6 resolves the FQDN, it will obtain a ULID RR and several AAAA records. Since this information comes from the DNS, it is assumed to be trustworthy and can be safely stored in the shim6 context for that communication. However, the same procedure needs to be used on the peer side. This basically means that after performing the 4-way handshake to establish the shim6 context, the P- Shim6 needs to verify that the presented locator set is bound to the ULID of the peer. In order to do that, it will need to perform a reverse DNS lookup and only the locators contained in the returned AAAA records will be validated for that context. This approach has a different set of tradeoffs than the one presented before. In particular, it doesn't require the usage of CGA/HBA, so there is no need for the DHCP component of the solution. However, it does require both peers to perform a DNS lookup for verifying the binding between the ULID and the locator set. In the case of the initiator, it can be argued that the DNS lookup is needed in any case, so no additional cost is imposed by this approach. However, from the receiver point of view, the additional DNS lookup imposes additional latency before accepting the establishment of the shim6 context. In any case, both CGA/HBA and DNS security can be used with the P-Shim6 approach. In addition, such approach presents additional security issues that arise when two different sites claim ownership in their DNS of the same ULID. A possible solution for this is to verify the reverse DNS tree to check who has the delegation of the reverse tree, but such a solution imposes additional DNS queries. Bagnulo Expires September 5, 2007 [Page 21] Internet-Draft P-Shim6 March 2007 11. Incompatibilities. The presented approach is incompatible with stateless address autoconfiguration as described in RFC2462 [1], since the addresses of the hosts within the multihomed site need to be configured using DHCP. It could be argued that it would be possible to support stateless address autoconfiguration if DNS based security is used. However, this is not so trivial, since it is necessary to configure the AAAA records of the autoconfigured addresses in the DNS, in order to enable DNS based security. For that, dynamic DNS configured by the end nodes is needed, which would impose additional security mechanisms to protect it. 12. Security Considerations. The P-Shim6 approach benefits from all the security features of the shim6 protocol as described in the Security Consideration Section of [6], including cryptographic protection for the binding between the ULIDs and the locator set and flooding protection using a probe before sending packets towards a new locator. In addition, the 4-way handshake used for establishing the shim6 context provides protection to the P-Shim6 boxes against DoS attacks. The main difference in terms of security with respect to the end to end shim6 protocol is that a trust relationship is assumed between the hosts within the multihomed site and the P-Shim6 boxes. The P-Shim6 approach is compatible with IPSec, both end to end IPSec used by the end nodes and IPSec tunnels used by any two devices along the path. 13. Acknowledgements. Most of the ideas presented in the document have been previously discussed in the shim6 working group. In particular, this document contains the result from several conversations with Erik Nordmark and Alberto Garcia Martinez. Some form of shim6 proxy as well as the usage of the shim6 protocol with ULAs has been proposed in [9]. The idea of using the DNS as a security mechanism for a multihoming protocol has been proposed in [13]. Thanks to Erik Nordmark, Brian Carpenter, Alberto Garcia Martinez Sam Xia, Iljitsch van Beijnum and John Ronan for reviewing and providing valuable feedback Conversations with Pekka Nikander helped to understand which Bagnulo Expires September 5, 2007 [Page 22] Internet-Draft P-Shim6 March 2007 components are needed for which features. Marcelo Bagnulo would like to acknowledge the European Commission support in the co-funding of the IST-RiNG project, where his work is being developed. 14. Change History draft-bagnulo-pshim6-00: Extended Alternative design choices to describe which component corresponds to which feature supported 15. References 15.1. Normative References [1] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [3] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [5] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [6] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-06 (work in progress), October 2006. [7] Bagnulo, M., "Hash Based Addresses (HBA)", draft-ietf-shim6-hba-02 (work in progress), October 2006. [8] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", draft-ietf-shim6-failure-detection-06 (work in progress), September 2006. Bagnulo Expires September 5, 2007 [Page 23] Internet-Draft P-Shim6 March 2007 15.2. Informative References [9] Nordmark, E., "Extended Shim6 Design for ID/loc split and Traffic Engineering", draft-nordmark-shim6-esd-00 (work in progress), February 2006. [10] Baker, F. and M. Azinger, "Multihomed IPv6 prefix delegation, aggregation, and distribution", draft-baker-v6ops-l3-multihoming-analysis-00 (work in progress), October 2006. [11] Huston, G., "Architectural Commentary on Site Multi-homing using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in progress), July 2005. [12] Hinden, R. and B. Haberman, "Centrally Assigned Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-01 (work in progress), February 2005. [13] Nordmark, E., "Multihoming without IP Identifiers", draft-nordmark-multi6-noid-02 (work in progress), July 2004. [14] Kempf, J., Wood, J., Ramzan, Z., and C. Gentry, "IP Address Authorization for Secure Address Proxying using Multi-key CGAs and Ring Signatures", IWSEC06, August 2006. Author's Address Marcelo Bagnulo Huawei Lab at UC3M Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo Expires September 5, 2007 [Page 24] Internet-Draft P-Shim6 March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bagnulo Expires September 5, 2007 [Page 25]