Network Working Group P. Nikander Internet-Draft K. Slavov Intended status: Informational Ericsson Research Nomadic Lab Expires: August 30, 2007 February 26, 2007 Proxying Approach to SHIM6 and HIP (PASH) draft-nikander-ram-pash-00 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 August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an incremental, network-based method for deploying SHIM6 or HIP based identifier / locator separation, called Proxying Approach to SHIM6 and HIP (PASH). This mechanism requires no changes to host stacks and, when deployed with routable Endpoint IDentifiers (EID), no changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers, and deployed independently by ISPs. At the same time, it allows the network to gradually evolve towards full, host-based SHIM6 Nikander & Slavov Expires August 30, 2007 [Page 1] Internet-Draft PASH February 2007 and/or HIP support, thereby making possible the larger architectural benefits that the network-based "jack-up" approaches provide. This proposal has been on the mental roadmaps within the HIP community for a number of years, but is properly documented only now as a result of the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic idea . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Transition roadmap . . . . . . . . . . . . . . . . . . . . . 5 4. Packet flow sequences . . . . . . . . . . . . . . . . . . . 6 4.1. SHIM6-based proxied packet flow . . . . . . . . . . . . . . 6 4.2. HIP-based proxied packet flow . . . . . . . . . . . . . . . 7 5. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 9 6. Handling legacy sites . . . . . . . . . . . . . . . . . . . 9 6.1. Legacy sites with PASH 1 . . . . . . . . . . . . . . . . . . 9 6.2. Legacy sites with PASH 1.5 . . . . . . . . . . . . . . . . . 9 6.3. Legacy sites with PASH 2 and 3 . . . . . . . . . . . . . . . 10 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security considerations . . . . . . . . . . . . . . . . . . 10 10. IANA considerations . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 12. Informative references . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 13 Nikander & Slavov Expires August 30, 2007 [Page 2] Internet-Draft PASH February 2007 1. Introduction As outlined in [4], it is possible to implement almost any host-stack based identifier / locator split mechanism in the network side by deploying suitable proxies. Such an approach does not require any changes to the hosts, and depending on the exact nature of the identifiers used, may be deployed at different points in the network, including Tier 1 ISPs. In this document, our attempt is to illustrate how host-based mechanisms, such as SHIM6 and HIP, can be implemented in the network side, bringing forth deployment benefits similar to the proposed Locator/ID Separation Protocol (LISP) [5]. Consequently, we do not repeat the argumentation therein but, when discussing the properties of the present proposal, merely point to the similarities and differences between the present proposal and the LISP one. In particular, in this document we aim towards the same design goals as LISP, as outlined in Section 2 thereof. At the same time, we strongly emphasis that, in our opinion, host- based identifier / locator separation approaches potentially provide benefits far beyond what network-based ones can provide. From that point of view, we are tempted to claim that the LISP proposal, at least in its current state, does not actually implement the identifier / locator separation in the sense the term has traditionally been used [9]. However, that discussion we defer to a separate document [8]. In addition to the design goals, we also adopt the topological dependencies from LISP, i.e., the notion of deployment genres: PASH 1, PASH 1.5, PASH 2, and PASH 3. 2. Basic idea The basic idea of this proposal is support network structures where some hosts have been upgraded to support SHIM6 or HIP while others work the same way as today. As in LISP, the routers continue to work as today. To support legacy hosts, we introduce SHIM6 or HIP proxies to the network. Depending on the deployment genre, the proxies may either be located relatively freely within the network, including individual ISPs (PASH 1 or 1.5), or need to be deployed at each edge or site accomodating legacy hosts (PASH 2 or 3). With these arrangements, we archieve the following properties: o SHIM6 ULIDs or HIP HITs are the only globally routable "IP addresses" assigned to legacy hosts. Nikander & Slavov Expires August 30, 2007 [Page 3] Internet-Draft PASH February 2007 o In theory, routers need no information about SHIM6 ULIDs or HIP HITs. However, since in PASH 1 and 1.5 the identifier and locator spaces overlap, under those deployment genres the routers do know about the ULIDs or HITs. However, they do not necessarily place any new burden to the routing or forwarding tables, depending on the ULID or HIT name space design. o ULIDs or HITs can be used for end-to-end communication within individual all-legacy networks. Note that in PASH 1 the whole Internet can initially be considered as one huge legacy network. However, end-to-end communication between separated legacy network, or between legacy networks and completely upgraded hosts (that are no longer able to communicate in the legacy manner), requires proxies. Structurally, this is similar to the LISP use of Tunneling Routers. o For PASH 1 and 1.5, it is preferable to have organizationally structured end-point identifiers. For SHIM6 ULIDs, this might require allocation of a new fraction of the IPv6 address space. For HIP, this would require changes to the ORCHID format [3], perhaps along the way J. Rajahalme argued during the ORCHID draft's IETF last call. o Depending on the usage scenarios, the actual data packets either need no extra headers or carry the SHIM6 context tag header, or a header similar to it. o The network is free to rewrite the source and destination addresses of packets, as long as the packet will eventually reach its final destination. As proxies handle only packets that either contain EID in their destination address field, carry a control message (SHIM6 extension or HIP control message), or are identified as proxied traffic by the means of a context tag or ESP SPI, having multiple proxies on the packet path is not a problem. This also means that proxies may act in a way transparent to the upgraded hosts. Nikander & Slavov Expires August 30, 2007 [Page 4] Internet-Draft PASH February 2007 An illustration of an example network 2001:001a:5131::2/28 HIP | | -------- | ---------- v | Host A |+---[2001:10::/28]---+| Proxy PA |+========[Internet... -------- ---------- | | 2001:0014:aaaa::1/28 2001:0020::8/28 | | ---------- -------- ...Internet]=======+| Proxy PB |+---[2001:20::/28]---+| Host B | ---------- | -------- | 2001:002f::9/28 The figure depicts a PASH 1 like situation where both hosts A and B are legacy (i.e. not SHIM6/HIP aware). Both proxies PA and PB store the host identities of A and B, enabling them to perform the SHIM6 handshake or HIP base exchange on behalf of the legacy hosts. 3. Transition roadmap In this section, we briefly outline how the described mechansism could be deployed in an incremental fashion. Similar to LISP 1, individual ISPs or ISP coalitions are able to start using PASH 1 immediately, without their customers or peers concent. In such a case, the only differences with LISP 1 are the mechanisms used between the proxies (respectively LISP tunnel routers) to establish the necessary identifier-to-locator mapping state, reflecting the underlying differences between trust and security models. Moving forward, once large fractions of the Internet are using this mechanism, it will pay off to connect such islands. That would bring forth routing benefits, provided that the providers also move to the PASH 1.5 deployment genre, reducing the need to continue supporting legacy identifier-based routing. Once the Internet core (all Tier 1 ISPs) have done the transition, deployment can gradually move towards the PASH 2 and/or 3 genres, where the identifiers are no longer routable through the core Internet. This will provide an incentive for sites to upgrade the Nikander & Slavov Expires August 30, 2007 [Page 5] Internet-Draft PASH February 2007 hosts or implement the proxying themselves, instead of relying on their ISPs doing it. 4. Packet flow sequences In this section, we describe packet flow sequences for both SHIM6 and HIP based fully proxied scenarios, using notation similar to Section 4.1. of [5]. 4.1. SHIM6-based proxied packet flow o Source host "host1.abc.com" is sending an initial packet to destination host "host2.xyz.com", or to the EID of the destination host, known a priori. o Both sites are multi-homed and use SHIM6 proxies at the site- borders. The proxies are directly deployed at the sites. 1. host1.abc.com wants to open a TCP connection or send an UDP packet to host2.xyz.com, or the corresponding EID. If host1 doesn't have the EID yet, it performs a DNS lookup and received the EID as a AAAA record. It builds an IP packet with src=EID1 and dst=EID2. 2. The packet arrives at the site-exit SHIM6 proxy, since all (non- local) EIDs are locally routed to it. [If there are multiple proxies, there can be multiple parallel local routes.] 3. The site-exit SHIM6 proxy attempts to determine the locator corresponding to EID2. If it does not find such a locator in its cache, the next step depends on the deployment genre: A. In PASH 1, the packet is sent as such. In this scenario it will reach the site-entry SHIM6 proxy of host2, but it the case there is no such proxy, it could also reach host2 directly, as such. B. In PASH 1.5, the packet is routed on a different routing infrastructure (perhaps an overlay), but it may exit untouched to a "legacy Internet" and reach host2 as such. C. In PASH 2 or 3, the destination of the packet is resolved or routed over an overlay, but the ability to support legacy hosts without proxying is lost. Here we consider only the cases where the packet reaches the site-entry SHIM6 proxy. In the PASH 1 and 1.5 cases the SHIM6 I1 Nikander & Slavov Expires August 30, 2007 [Page 6] Internet-Draft PASH February 2007 extension message MAY be added to the packet. Alternatively, either of the SHIM6 proxies may decide to initiate the SHIM6 protocol at any later stage. For PASH 2 and 3, it appears necessary to initiate the SHIM6 exchange immediately. 4. When the packet reaches the site-entry SHIM6 proxy for host2, the proxy checks the packet for any SHIM6 extensions. If the packet carries the SHIM6 I1 extension, it initiates full SHIM6 exchange. It can either piggyback it on further messages between host1 and host2 (which may be hard to implement) or use plain IP packets that carry only the SHIM6 extension and no upper layer payload. 5. Once the SHIM6 protocol has been completed, both proxies cache the SHIM6 state that allows them to rewrite the IP address fields in the packets; when they do so, they also add/remove the SHIM6 context tag extension. 4.2. HIP-based proxied packet flow Since both HIP and SHIM6 protocols share the same ideology for the most parts, the HIP-based proxied packet flow does not provide notable changes compared to the SHIM6 packet flow. For lazy readers the major changes are: o Under current HIP design, the proxies have to establish the rewriting state immediately, even under PASH 1 and 1.5. Delayed setup a ala SHIM6 is not possible. o Under PASH 1 and 1.5, HIP will need routable HITs. o Temporary host identities of legacy peers would be stored in the proxies, enabling them to run HIP base exchange on behalf of the legacy host. o Source host "host1.abc.com" is sending an initial packet to destination host "host2.xyz.com", or to the HIT of the destination host, known a priori. o Both sites may be multi-homed and use HIP proxies at the site- borders. The proxies are directly deployed at the sites. 1. In PASH 1 and 1.5, host1.abc.com wants to open a TCP connection or send an UDP packet to host2.xyz.com, or to the corresponding HIT. If host1 doesn't have the HIT yet, it performs a DNS lookup and receives the HIT as an AAAA record, passing the HIT to the application. If there is a HIP RR, it is ignored by the legacy host. It builds an IP packet with src=HIT1 and dst=HIT2. In contrast to what HIP base specification defines, the HITs in PASH Nikander & Slavov Expires August 30, 2007 [Page 7] Internet-Draft PASH February 2007 1 and 1.5 would be routable. For example, they could be CGAs in PASH 1. 2. In PASH 2 and 3 the resolver lookup would yield the destination HIT in the HIP RR and a set of locators in AAAA or A RRs. There, either the IP packet would be built with src=locator1 dst=locator2 resulting in legacy operation, or the proxy would need to handle also the DNS queries. 3. The packet arrives at the site-exit HIP proxy, since all (non- local) HITs are locally routed to it. [If there are multiple proxies, there can be multiple parallel local routes.] 4. The site-exit HIP proxy attempts to determine the locator corresponding to HIT2. If it does not find such a locator in its cache, the next step depends on the deployment genre: A. In PASH 1, the packet is sent as such. In parallel, the proxy initiates HIP base exchange with the destination, using HIT2 as the destination locator. In this scenario, both packets will reach the site-entry HIP proxy of host2, but in the case there is no such proxy, they could also reach host2 directly; in that case the HIP I1 packet would get ignored. B. In PASH 1.5, the packet and HIP I1 are both routed on a different routing infrastructure, but they may exit untouched to a "legacy Internet" and reach host2 as such, just as above. C. In PASH 2 or 3, the destination of the packet needs to be resolved or overlay routed. In these cases it may make sense to delay or drop the initial packet and wait for the HIP base exchange to complete before continuing. Here we only consider the cases where the packet reaches the site-entry HIP proxy. As stated, in the PASH 1 and 1.5 cases, the HIP base exchange takes place in parallel. This may be implemented either as a separate I1 message, as described above, or the HIP I1 message may be added to the packet, e.g. as TCP option as defined in [7]. For PASH 2 and 3, it appears necessary to initiate the HIP exchange immediately. 5. When the packet reaches the site-entry HIP proxy for host2, the proxy checks if the packet is or contains any HIP control messages. If the packet carries the HIP I1 message, the HIP proxy replies with the HIP R1, continuing the HIP base exchange. It seems sensible to use plain IP packets that carry only the HIP control messages and no upper layer payload. Nikander & Slavov Expires August 30, 2007 [Page 8] Internet-Draft PASH February 2007 6. Once the HIP base exchange is completed, both proxies cache the HIP state that allows them to rewrite the IP address fields in the packets. 7. For cases where the packet reaches the end host instead of any site-entry HIP proxies, the data flow does not change notably. For PASH 1 and 1.5: A. If both hosts are HIP-enabled, accoring to the HIP specification, the HIP base exchange will be executed before any payload traffic will be sent. To detect this the hosts may use the same techniques as described above. B. If only one of the hosts is HIP-enabled, the data connection will fallback to an ordinary IP connection. This case is valid also if neither of the hosts understand HIP. For PASH 2 and 3, legacy hosts cannot directly connect beyond their local legacy network, and proxies are always required. 5. Packet formats There is no need to make any changes to the SHIM6 or HIP packet formats. 6. Handling legacy sites Handling of legacy sites (with no or few upgraded hosts) depends on the deployment genre. 6.1. Legacy sites with PASH 1 Under PASH 1, legacy sites can decide whether they want to do a site- wide upgrade or not. A site upgrades by adding proxies at their site-border routers. Once they have done that, they assign one of their existing prefixes as SHIM6 ULIDs. For the HIP case, some more design is needed. One option is to allow CGAs to be used with HIP; in that case, existing prefixes can used, just like with SHIM6. 6.2. Legacy sites with PASH 1.5 Under PASH 1, legacy sites can decide whether they want to upgrade, provided that they ISP provides a route for EIDs. More details are to be written once we understand better how LISP 1.5 is meant to work. Nikander & Slavov Expires August 30, 2007 [Page 9] Internet-Draft PASH February 2007 6.3. Legacy sites with PASH 2 and 3 Under PASH 2 and 3, the site entry/exit proxies will provide temporary identifiers for the legacy hosts. The proxies will also act as a termination point for the identifier-bound connections. The actual payload will be forwarded to the legacy host using the available legacy mechanisms. 7. Open issues o Co-ordination between multiple site-border routers. o TE co-ordination between sites and ISPs and between ISPs. o Using routable identifiers (e.g. CGAs) with HIP. 8. Discussion In this document, we have outlined how two host-based identity / locator split mechansims, SHIM6 and HIP, can be implemented in separate boxes in the network. The approach is meant to act as a transition tool. The main message of this document is to show that it is indeed possible to adopt host-based mechanisms to be implemented at the network side; a discussion which we started in [4]. Consequently, we strongly feel that there is no need to rush adopting a network-based, "jack up" solution to the current routing scalability problem. Instead, we urge the community to keep the various options open, remembering that host-based solutions not only bring forth a number of advantages compared to network-based solutions but can, as a transition mechanism, be implemented within the network in order to provide support and most benefits even for legacy hosts. 9. Security considerations At this stage, we haven't worked out the security details related to proxying. However, we don't expect there to be any major problems and expert to rely on existing SHIM6 and HIP security work. 10. IANA considerations This document has no actions for IANA. Nikander & Slavov Expires August 30, 2007 [Page 10] Internet-Draft PASH February 2007 11. Acknowledgments 12. Informative references [1] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [2] Lear, E. and R. Droms, "What's In A Name:Thoughts from the NSRG", draft-irtf-nsrg-report-10 (work in progress), September 2003. [3] Nikander, P., "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", draft-laganier-ipv6-khi-05 (work in progress), September 2006. [4] Nikander, P., "Generic Proxying as a Deployment Tool (GEPROD)", draft-nikander-ram-generix-proxying-00 (work in progress), January 2007. [5] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-00 (work in progress), January 2007. [6] Lindqvist, J., "Establishing Host Identity Protocol Opportunistic Mode with TCP Option", draft-lindqvist-hip-opportunistic-01 (work in progress), March 2006. [7] Lindqvist, J., "Piggybacking TCP to Host Identity Protocol", draft-lindqvist-hip-tcp-piggybacking-00 (work in progress), July 2006. [8] Nikander, P., "Identifier / Locator Separation: Exploration of the Design Space", draft-nikander-ram-ilse-00 (work in progress), February 2007. [9] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. Nikander & Slavov Expires August 30, 2007 [Page 11] Internet-Draft PASH February 2007 Authors' Addresses Pekka Nikander Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: pekka.nikander@nomadiclab.com Kristian Slavov Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: kristian.slavov@nomadiclab.com Nikander & Slavov Expires August 30, 2007 [Page 12] Internet-Draft PASH February 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). Nikander & Slavov Expires August 30, 2007 [Page 13]