Network Working Group P. Nikander Internet-Draft Ericsson Research Nomadic Lab Intended status: Informational January 24, 2007 Expires: July 28, 2007 Generic Proxying as a Deployment Tool (GEPROD) draft-nikander-arch-generix-proxying-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 July 28, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document presents a generic way of using Forwarding Proxies, designed to be used as a transition mechanism in implementing various flavors of the so called Identifier / Locator separation, including both "above IP" and "below IP" approaches. This version of this draft is an very incomple version, intented to induce discussion. Nikander Expires July 28, 2007 [Page 1] Internet-Draft GEPROD January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms common to other documents . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Basic approaches . . . . . . . . . . . . . . . . . . . . . . 5 5. Architectural approaches to identifier / locator split . . . 6 5.1. Using locators at transport and IP layer . . . . . . . . . . 6 5.2. Rewriting withing the transport or 'upper' IP layers . . . . 7 5.3. Rewriting within the network . . . . . . . . . . . . . . . . 8 6. Using Proxies as an interconnected medium . . . . . . . . . 9 6.1. Forward proxying in the 'above' transport approach . . . . . 9 6.2. Forward proxying in the 'in-stack' approach . . . . . . . . 10 6.3. DNS with forward proxying . . . . . . . . . . . . . . . . . 12 6.4. Reverse proxying . . . . . . . . . . . . . . . . . . . . . . 13 6.5. Un-proxying in the 'in-the-network' approach . . . . . . . . 13 7. Stretching the wire . . . . . . . . . . . . . . . . . . . . 14 8. Security considerations . . . . . . . . . . . . . . . . . . 15 9. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. IANA considerations . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 12. Informative references . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . 17 Nikander Expires July 28, 2007 [Page 2] Internet-Draft GEPROD January 2007 1. Introduction Discussions at the IAB Routing and Addressing workshop, followed by discussions at the 67th IETF in San Diego, have revealed a potential problem in our ability to keep growing the routing and forwarding tables in the core routers in the default free zone. This, in turn, has led to a lively discussion on various architectural options towards solving the problem. A tentative consensus seems to be that implementing the so called identifier / locator separator by injecting a new naming layer either "below" or "above" the current routing layers (IPv4 and IPv6) appears to be one very potential architectural approach. However, there seems to be no consensus on the stack-wise location or semantics of the resulting new name space. In this document, we discuss an implementation approach that can be used as a transition tool to help introducing such a new name space. The approach can be used for injecting a new layer both "below" or "above", though in a slightly different manner. Both approaches are discussed. 2. Terminology 2.1. Terms common to other documents +----------------------------------------+-------------------------+ | Term | Explanation | +----------------------------------------+-------------------------+ | End-point | A communicating entity. | | | | | Locator | | | | | | Identifier | | | | | | Legacy address | | | | | | Upper Layer Protocol | | | | | | Upper Layer Protocol Identifier (ULID) | | +----------------------------------------+-------------------------+ 3. Background As discussed elsewhere (cf. RFC4423 [1]), the current IPv4 and IPv6 name spaces can be considered to be confoundings of two semantically different name spaces: interface locators and node identifiers. In other words, an IP address functions both in a locator role, Nikander Expires July 28, 2007 [Page 3] Internet-Draft GEPROD January 2007 identifying a location of an interface in the terms of the forwarding name space topology, and in an identifier role, identifying the communicating end-point (node) for transport and other upper layer protocols. The need for or non-desirability of separating these two functional roles have been discusses in the IETF for the past ten years or so. Past and present proposals for implementing the so called identifier / locator split include at least the following: HIP, where current IP addresses are demoted to mere locators and a new name space of identifiers is created. In HIP, the identifiers are essentially hashes of public cryptographic keys. SHIM6, with two variants, where in both IP addresses continue to be used both as identifiers and locators, but where the identifier addresses are formed either from a fixed set of routing prefixes and the also including a verifiable reference to public key intto the identifier address. Others to be added. Please provide text. In this document, we take the stance that in order to be architecturally sound, any layer-injecting solution must eventually be implemented by all hosts, at least in an conceptual sense. ... XXX Elaborate. When considering any such architectural solution, it becomes clear that any eventual solution must take care of a longish transition period where some part of the network has implemented the identifier / locator separation while another part of the network has not. In this document, we describe how the transition period can be eased by introducing proxies into the network. These proxies represent the 'new' part of the network to the 'old' part as if the new part still had not implemented the separation, and vice versa. 4. The Problem The identifier / locator split introduces a new name space to the networking architecture, either "below" the current IP addresses or "above" it. In any case, the result is an architecture that has two separate naming layers: a (node) identity naming layer, and an (interface) locator naming layer; see Figure XXX. Now, consier a situation where the network is partitioned into two or more parts, some of them implementing the new approach and some not. Nikander Expires July 28, 2007 [Page 4] Internet-Draft GEPROD January 2007 For brevity, we call 'old' the parts of the network that have not (yet) implemented the identifier / locator separation (whatever it is), and 'new' those parts of the network that have implemented the separation. Note that depending on the the implementation details, being 'new' may imply that the hosts implement the new functionality, that the routers implement the new functionality, that there are new boxes that implement the new functionality, or some combination thereof; this will become clearer shortly. As a result of partial deployment, those hosts that are located in the 'old' part of the network continue to send packets that in their source and destination fields have the old semantics. At the same time, thoses hosts that are in the 'new' part of the network send (either directly or due to conversion deeper in the network) packets that eventually will have mere locators in their source and destination addresses. In this world, we have the following four situations: An 'old' host sends a packet to another 'old' host. The packet contains legacy addresses in both source and destination fields. As long as there still exists routing infrastructure that connects the hosts, there are no problems. A 'new' host sends a packet to another 'new' host. The packet (will eventually) contain locators in the source and destination fields. As long as the mapping from identifiers to locators and vice versa works as it should, at both ends, there are no problems. An 'old' host attempts to send a packet to a new 'new' host. As a result of this, the outgoing packet will have the 'new' host's identity or locator in the destination field, while the source field contains the 'old' host's legacy address. There are a number of details here that differ from approach to approach. A 'new' host attempts to send a packet to an 'old' host. The source field will now be the a locator. There are a few options for what the destination field will contain; see the discussion below. In this document, we discuss the latter two situations and describe a number of particular ways of solving them, based on proxies. 4.1. Basic approaches To facilitate 'old' hosts sending packets to 'new' hosts and vice versa, we can construct the following taxonomy of approaches. Nikander Expires July 28, 2007 [Page 5] Internet-Draft GEPROD January 2007 'Old' sending packets to 'new' 'New' still directly reachable through the legacy routing system. 'New' no longer directly reachable through the legacy routing system. 'New' sending packets to 'old' 'New' still having direct access to the legacy routing system. 'New' no longer having direct access to the legacy routing system. These cluster naturally into two, depending on whether the the 'new' host has direct access to the legacy routing system or not. In this document we only look at the latter cases, where the 'new' host is only connected to the 'new' network and the 'old' system is only connected to the 'old' network, thereby needing an intermediate box to interconnect them. 5. Architectural approaches to identifier / locator split Architecturally, the identifier and locator roles of IP addresses can be separated at three different locations within the IP stack: Above the transport layer; e.g., at a library that implements the sockets API. Somewhere within the transport layer or the "upper" part of the IP layer; i.e., logically within the host stack "proper". Examples of this approach include SCTP multi-homing, HIP, and SHIM6. In the network. From a host point of view, it doesn't make a big difference if this change takes place at the device driver or in a separate box well within the network. However, in order to better match with the mind set of the 'jack up' proposals, below we introduce this model in terms of two boxes, and then "un-proxy" it by moving the functionality to the host itself. 5.1. Using locators at transport and IP layer This approach has received relatively little study. One fundamental problem is the need for TCP to resynchronise in the case of locator change. That is, if the layer above detects a need Nikander Expires July 28, 2007 [Page 6] Internet-Draft GEPROD January 2007 to change locators, it needs to open a new TCP connection that uses the new locators. If the old TCP connection was not properly shut down, the hosts cannot be sure how much of sent data the other host received, necessitating a new resynchronisation mechanism. +---------------+ | | Identifiers | Applications | | | Rewriting +----sockets----+ | | Locators | Transport | | | +---------------+ | | | Internet | | | +---------------+ | | | Device driver | | | +---------------+ Figure 1 5.2. Rewriting withing the transport or 'upper' IP layers Approaches belonging to this class have received most scrutinity to date. +---------------+ | | | Applications | | | Identifiers +----sockets----+ | | | Transport | Rewriting | | somewhere +---------------+ here | | | Internet | | | Locators +---------------+ | | | Device driver | | | +---------------+ Nikander Expires July 28, 2007 [Page 7] Internet-Draft GEPROD January 2007 Figure 2 Characteristic to these approaches is that the data items at the socket API, down to the transport, are identifiers, and the packets passed between the 'upper' and the routing and forwarding parts of the IP layer have locators. That is, somewhere between the 'top' of the transport and the routing and forwarding function the identifiers get rewritten to locators and vice versa. Proposals that more-or-less follow this approach include the following: SCTP multi-homing and add-IP HIP SHIM6 5.3. Rewriting within the network This approach has been named 'jack up' by Noel Chiappa in the late 2006 / early 2007 IAB architecture-discuss mailing list discussions. Proxy Host +--------------+ | | | Applications | | | +---sockets----+ | | | Transport | | | +--------------+ +---------------+ | | | Rewriting | | Internet | | forwarder | | | +-------+-------+ +--------------+ Locators | | | Identifiers | | | | | |Device driver | | | |<-------------->| | +---------------+ +--------------+ Figure 3 From the outset, the apparent property of these approaches is that it feels natural to perform the rewriting at the network side. In other words, a main motivator for the proposals in this category is to keep the hosts intact by providing the functionality with extra boxes at Nikander Expires July 28, 2007 [Page 8] Internet-Draft GEPROD January 2007 the network side. In this approach, there is a local subnetwork between the unmodified host and a rewriting box. The rewriting box implements the 'new' functionality for the whole subnetwork, thereby alleviating the need to change the individual hosts. However, as will become apparent momentarily, the 'network side' property of these approaches is more circumstantial than characteristic in the sense that also the other two approaches can be implemented at the network side. Hence, the main property of this category is that the rewriting is done at the 'routing' side of the IP stack, i.e., after IPsec, fragmentation, and reassembly, rather than 'above' those functions. 6. Using Proxies as an interconnected medium In this section we momentarily assume a network setting where most hosts are 'new' hosts, and we just have to take care of interconnecting a few 'old' hosts to the 'new' world via proxies. We will return to other cases, e.g., where there are just a few 'new' network segments while most of the world is still using confounded identifiers and locators, in a later section. Hence, in this section we assume that there is a local subnetwork, or even a direct wire, between the 'old' host and a proxy. Common to all proxy-based solutions is that there is a local subnetwork where the source and destination addresses in IP packets contain identifiers. In other words, the rewriting function has been moved from the host stack into a separate box in the network. Respectively, when 'un-proxying' the 'jack-up' approach, the rewriting function is moved from the separate box in the network into the lower part of the host stack. 6.1. Forward proxying in the 'above' transport approach Architecturally, these approaches are quite similar to the existing TCP 'splitters', with the difference that the identifiers get rewritten to locators and vice versa. The properties of this class of approaches have not been analysed at all; the main motivation for illustrating this to be architecturally complete and present all alternatives. Nikander Expires July 28, 2007 [Page 9] Internet-Draft GEPROD January 2007 Proxy Host +--------------+ | | +---------------+ | Applications | | Rewriter | | | +-------+-------+ +---sockets----+ | | | | | Locators | Trans|port | Identifiers | Transport | | | | | | +-------+-------+ +--------------+ | | | | | | Inter|net | | Internet | | | | | | +-------+-------+ +--------------+ | | | | | | | | |Device driver | | | |<-------------->| | +-------+-------+ +--------------+ Figure 4 6.2. Forward proxying in the 'in-stack' approach As above, the idea here is to move the rewriting function from the host stack into a distinct box in the network. Depending on where exactly within the transport/internetworking the rewriting would be done at the host side, the proxy needs to implement different amounts of functionality and state. Let us consider, as an example, the case of HIP and SHIM6. There the rewriting is performed roughly colocated with IPsec at the stack; i.e., at the point when the host is ready to send an outbound packet but before the packet gets forwarded towards a specific interface, or where the host has decided that an inbound packet is destined to itself and not to be forward. In the proxied approach, instead of rewriting the packet the host either sends an outbound packet, unmodified, to the proxy, or accepts an inbound packet from it. The proxy, in turn, maintains a rewriting table, replacing the locators with identifiers on inbound traffic and picking suitable locators for outbound packets. If the host has multiple interfaces, each interface should be logically configured with the same local IP address, since the goal is to have just one identifier for each host, and all the proxies at the various local paths must perform compatible rewriting. From a logical point of view, this approach can be illustrating by 'strething' the host stack to the new middle box. That is, we split Nikander Expires July 28, 2007 [Page 10] Internet-Draft GEPROD January 2007 the host stack at the rewriting function (whereever it happens to be), leave everything above at the host itself, and move everything below to the proxy. This is illustrated in Figure XXX. Physically, of course, the host stack remains complete and the 'stretching' is performed by the local subnetwork; see Figure XXX. Proxy Host +--------------+ | | | Applications | | | +---sockets----+ | | | Transport | | | +--------------+ Identifiers | IPsec, frag | +---------------+ +- - - - - - - + | Rewriter |<-------------->| Rewriter | +- - - - - - - -+ +--------------+ Locators | forwarding | +---------------+ | | | Device driver | | | +---------------+ Figure 5 Nikander Expires July 28, 2007 [Page 11] Internet-Draft GEPROD January 2007 Proxy Host +--------------+ | | | Applications | | | +---sockets----+ | | | Transport | +---------------+ | | | Rewriter | +--------------+ | | | IPsec, frag | +- - - -+- - - -+ |- - - - - - - | Locators | forw|arding | Identifiers | forwarding | +-------+-------+ +--------------+ | | | | | | | | |Device driver | | | |<-------------->| | +---------------+ +--------------+ Figure 6 6.3. DNS with forward proxying In the forward proxying approaches above, we have assumed that the local wire between the 'old' host and the proxy carries IP packets that have identifiers in their IP header. To work nicely with the DNS, this may require minor DNS filtering or proxying, depending on how the locators and identifiers are stored in the DNS. If the identifiers are stored in the DNS as AAAA (or A) records, and locators under some other record type, there is no need to play tricks with the DNS. The 'old' host, making a DNS query (through the proxy) will get an AAAA record containing the identifier, and everything will work as if the remote host had that identity as its IP address. Respectively, the host's identity will be stored at the public DNS as an AAAA record along with the proxy's locators. If the locators are stored in the DNS as AAAA or A records, and the identifiers under some other record type, the proxy (or some other box) must provide translation so that the 'old' host will get only the identifier as a response to its address queries. If both locators and identifiers are stored in the DNS as AAAA or A records, then it may suffice to order the records so that the identifiers come always first, or it may be necessary to filter the DNS responses. Nikander Expires July 28, 2007 [Page 12] Internet-Draft GEPROD January 2007 6.4. Reverse proxying In the approaches above we assumed that we were connecting 'old' hosts to a predominantly 'new' world, by providing the new functionality at a proxy near the 'old' host. We now consider the situation where the goal is to connect a completely 'new' host, one that no longer has direct 'old' connectivity, to a predominantly 'old' world. In this case we need a proxy, but this time a different one. This proxy will represent a huge number of 'old' hosts, out there in the Internet, towards the 'new' host. In this case, the actual proxy structure and functionality does not differ much in the architectural sense. The proxy still provides the 'new' functionality to the 'old' hosts. The difference is that the proxy has no a priori information about the identity of the 'old' hosts, and cannot be assumed to have big enough stable storage to represent them all. Secondly, it must be assumed that there may multiple of such 'reverse' proxies in parallel and it is not possible to provide coordination between them. To provide connectivity from 'new' hosts to 'old' hosts, the proxy must implement active DNS proxying. That is, when a 'new' host makes a DNS query asking for the identity and locators for an 'old' host, the proxy answers with a fabricated identity and its own locators. Correspondingly, when an 'old' host makes a DNS query asking for the IP addresses of a 'new' host, the proxy provides with its own IP addresses. Hence, while there is little difference in handling the actual IP packets, other than using fabricated rather than stable identifiers for the 'old' hosts, there are relatively large operational differences between 'forward' and 'reverse' proxying. Note that a reverse proxy can be a distributed one. 6.5. Un-proxying in the 'in-the-network' approach In the same spirit but in the reverse fashion, the 'in-the-network' or jack up approaches can be implemented within the host instead of in a separate box. In this case, we 'squeeze' the local subnetwork into the host itself, making it to physically disappear. Nikander Expires July 28, 2007 [Page 13] Internet-Draft GEPROD January 2007 +---------------+ | | | Applications | | | +----sockets----+ | | | Transport | | | +---------------+ | | Identifiers | Internet | | | Rewriting +---------------+ | | Locators | Device driver | | | +---------------+ Figure 7 In these approaches, the host stack 'proper' handles only identifiers. Even when the packets enter the routing and forwarding part of the IP layer they still contain identifiers. The identifiers get rewritten to locators, and vice versa, somewhere 'below' the host IP; for example, a "shim" layer between the IP layer and the device layer can do this, somewhat similar to the so called bump-in-the- stack (BITS) IPsec implementations. 7. Stretching the wire So far we have considered moving the rewriting functionality either out from a host to the network or vice versa, considering only a local piece of wire between the host and the proxy. We will now extend the discussion into other configurations, where there may be a larger piece of network between the old host and the proxy. When using a proxy at the local network, there are few restrictions on addressing. Basically, it suffices if the identifiers can be locally distinguished from locators. All outgoing packets containing identifiers can be processed by the proxy, as needed. The 'old', proxied hosts can use their own identifiers as their local IP addresses. However, when stretching the wire between an 'old' host and a proxy, routing becomes involved. In a word, it becomes a necessary to somehow route packets that contain identifiers in IP headers. There Nikander Expires July 28, 2007 [Page 14] Internet-Draft GEPROD January 2007 are multiple potential approaches to this, depending on the exact nature of the identifiers and on how far the packets need to be routed: The easiest case is when the identifiers are fully routable, like in SHIM6. In that case there are few limitations where and how the proxies can be located at, as long as they are on the default path between the 'old' and 'new' hosts. For example, each site exist could be equipped with a SHIM6 proxy, knowledgeable about all the other prefixes the site has, and being able to redirect the traffic on demand. Even if the identifiers are not fully routable but still contain a prefix system that allows them to be routed towards either the 'old' hosts or the proxy, forward proxying is relatively easy to arrange. Add more cases here. It is always possible to arrange 'reverse' proxying, at any location in the network, at an added operational cost. 8. Security considerations 9. Discussion The main message in this draft is that there is only little architectural diffence between implementing the identifier / locator split 'within' transport/host IP layer or 'below' the host IP layer. In other words, while at the outset it appears that a 'host' based id/loc split must be implemented in a host and a 'network' based id/ loc split must be implemented in separate boxes in the network, the 'implementation' location is actually relatively orthogonal to the 'stack' location. Even 'host' based approaches, such as SHIM6 or HIP, can be implemented within the network with the help of proxies. And 'network' based 'jack-up' approaches can be implemented in a host, by providing the host with sufficient information. The real differences are in trust, state, and operational models. Considering trust, 'host' based approaches grow from the assumption that the host is in the best position of representing itself as an integral identity. Conversely, they may be more vulnerable to possession attacks than other approaches. Respectively, 'network' based approaches grow from the assumption that the hosts cannot be trusted (as, e.g., they may be compromised) and therefore it is Nikander Expires July 28, 2007 [Page 15] Internet-Draft GEPROD January 2007 better for the network to provide the functionality. In reality, if high security is needed it seems like a good approach to combine both: start by assuming that the hosts represent themselves as integral entities having an identity but operationally forcing the hosts to delegate the representational functionality into the network. That is, in a high security environment it may be best to force the hosts to use a proxy. This divides the responsibility and therefore lowers risks. TBD: Discuss state and operational models. 10. IANA considerations This document has no actions for IANA. 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] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", URL http://users.exis.net/~jnc/tech/endpoints.txt, 1999. Author's Address Pekka Nikander Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: pekka.nikander@nomadiclab.com Nikander Expires July 28, 2007 [Page 16] Internet-Draft GEPROD January 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 Expires July 28, 2007 [Page 17]