Internet Engineering Task Force S. Schuetz, Ed. Internet-Draft R. Winter Intended status: Experimental NEC Expires: March 17, 2008 L. Burness P. Eardley BT B. Ahlgren SICS September 14, 2007 Node Identity Internetworking Architecture draft-schuetz-nid-arch-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 March 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a new proposal for a future Internet architecture. Similar to many other proposals it employs a locator/ identifier split to overcome the short-comings arising from the dual Schuetz, et al. Expires March 17, 2008 [Page 1] Internet-Draft Node Identity Architecture September 2007 role of IP addresses. Similar to the Host Identity Protocol, each node carries a unique, randomly self-generated identifier - the public part of a public/private key pair. It can therefore directly be used for authentication and authorisation purposes. Different from some other proposals, the Node Identity Internetworking architecture does not try to converge on a single (globally managed) address space, but instead accepts the co-existence of different networking domains - here called locator domains. Routing within the architecture is based on a two-level approach. First, routing within a locator domain is managed by the internal addressing and routing scheme of the locator domain. Second, routing between locator domains involves specialized nodes at locator domain borders. By grouping the nodes into locator domains, the effects of certain events such as mobility can often be localised, thus reducing the impact on the global network. Table of Contents 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture Description . . . . . . . . . . . . . . . . . . . 6 3.1. Assumptions and Principles . . . . . . . . . . . . . . . . 6 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Details . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Mobility and Multihoming . . . . . . . . . . . . . . . . . 10 3.4.1. Node and Network Mobility . . . . . . . . . . . . . . 10 3.4.2. Node and Network Multihoming . . . . . . . . . . . . . 11 4. Protocol Sketch . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. NID Registration Protocol . . . . . . . . . . . . . . . . 12 4.1.1. Recursive Operation . . . . . . . . . . . . . . . . . 12 4.1.2. Iterative Operation . . . . . . . . . . . . . . . . . 13 4.2. Data Packets . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Stateless Operation . . . . . . . . . . . . . . . . . 15 4.2.2. Stateful Operation . . . . . . . . . . . . . . . . . . 15 5. Open Design Issuses . . . . . . . . . . . . . . . . . . . . . 16 6. Report on Prototype Implementation . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Document Revision History . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Schuetz, et al. Expires March 17, 2008 [Page 2] Internet-Draft Node Identity Architecture September 2007 1. Introduction and Motivation The fundamental basis of today's Internet is the global deployment of the Internet Protocol (IP). IP is very flexible in the sense that it runs over many link layer technologies and can carry many different kinds of data traffic over it. However, IP also has some limitations by design as it relies on principles that do not reflect today's reality well. The dual role of an IP address serving as both a node's identifier as well as its locator in the network topology has a set of disadvantages. A change of a node's IP address implies the change of its identity as seen by its peers. Nodes, i.e. hosts and routers, are becoming increasingly mobile, in the sense that they appear in the network at different points-of-attachment over time, usually implying a change of a node's (or a node's interface's) IP address. Similarly, multi-homed nodes that attach to the network with different IP addresses through multiple interfaces appear in the network as having different identities or as being different entities altogether. It is not possible to verify that a set of IP addresses or a changed IP address actually belong to the same node using IP alone. These characteristics of IP have an impact on techniques to achieve e.g. session survivability or can lead to de-facto provider lock-in as re-numbering can become a quite complex and painful process. IP on its own does not provide support for authentication of a node (or packets) and also does not provide a means for data encryption. To bridge IP's security gap, IPsec [RFC4301] was developed to provide this functionality, but it is an "add-on" rather than an integral design part of the architecture and therefore experiences problems, e.g. when traversing middleboxes such as Network Address Translators (NATs) or firewalls. The attempts to migrate to IPv6 together with the proliferation of NAT:ed private address space have shown that a new architecture must support multiple address domains and networking technologies, rather than trying to unify on a single address space and single technology. In other words, the architecture needs to brigde over heterogeneous domains. This is to some extent the original internetworking problem that IPv4 once solved, but which over time has reappeared. We must also conclude that there is no benefit in introducing yet another global, managed address space to solve this bridging problem, since that will not provide significant advantage over the IPv6 address space. This draft introduces the Node Identity Architecture [nid-global-internet], which is designed to address the above Schuetz, et al. Expires March 17, 2008 [Page 3] Internet-Draft Node Identity Architecture September 2007 described challenges. Its key characteristics and ingredients are: o an identifier/locator split o a node's "node identity" is the public part of a randomly, self- generated public/private key pair o multiple locator domains, which may use different addressing schemes, are intrinsically supported, where at locator domain borders a process similar to twice-NAT is performed o there is a relatively stable core locator domain, via which a node can reach any other node o a global name resolution system mapping node names to the identities of the node and the router in the core though which the node can be reached o there is a default mechanism for installing routing information for a node (based on the default route to the core locator domain and the reverse path). Other routing mechanisms for more optimal routes are out of scope of this draft This draft describes the high-level approach taken by the Node Identity architecture, its principal mechanisms and outlines its general functionality by example. The Node ID architecture is in line with many of the goals of a future Internet architecture as described in [I-D.irtf-rrg-design-goals], although a detailed analysis is out of scope. Some goals are addressed explicitly such as security, others more implicitly such as the expected benefits of the general ID/LOC split approach including the possibility to aggressively aggregate prefixes in the default-free zone (DFZ) of the Internet. In addition, the Node Identity Internetworking architecture naturally supports the bridging of heterogeneous networking domains, such as ones based on IPv4 and IPv6 as described in later chapters. It further does not mandate the introduction of an additional managed namespace and it supports multiple levels of hierarchy. Further details will follow in subsequent versions of this and additional drafts. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] Terms and abbreviations special to this document are defined in Schuetz, et al. Expires March 17, 2008 [Page 4] Internet-Draft Node Identity Architecture September 2007 Table 1 and Table 2. +------------+------------------------------------------------------+ | Node | General term for end-host or router. | | | | | Locator | A network domain with a consistent internal | | Domain | addressing and routing system. | | | | | | | | Node | Identifies a node within the architecture; the | | Identity | public part of a randomly self-generated | | | public/private key pair | | | | | Node | A fixed-length hash of the node identity. Used to | | Identity | register a node and make it reachable outside its | | Forwarding | own locator domain(s). | | Tag | | | | | | Node | A border router that connects locator domains and | | Identity | makes forwarding decisions based on either the | | Router | routing hint or the Node Identity Forwarding Tag. | | | | | Core Node | A border router that has an interface attached to | | Identity | the core locator domain. | | Router | | | | | | Routing | A forwarding token mainly used to traverese the core | | hint | locator domain towards a core node identity router | | | through which a destination node is reachable. | +------------+------------------------------------------------------+ Table 1: Definitions +------+------------------------------+ | CNR | Core Node Identity Router | | ID | Identity | | LD | Locator Domain | | LS | Routing hint lookup system | | NID | Node Identity | | NIFT | Node Identity Forwarding Tag | | NR | Node Identity Router | | NS | Global naming system | +------+------------------------------+ Table 2: Abbreviations Schuetz, et al. Expires March 17, 2008 [Page 5] Internet-Draft Node Identity Architecture September 2007 3. Architecture Description 3.1. Assumptions and Principles Each node within the Node Identity Architecture carries a unique identity, the Node Identity or NID in short. The NID is the public part of a randomly self-generated public/private key pair. This allows the use of the NID for authentication purposes. The NID is a flat label and does not contain any topological semantics. In addition, a node has one or several locators. In contrast to the NID, the locators usually have topological semantics. The locator is used to route messages to the node within its network. It can be e.g. an IPv4 or IPv6 address. The locators of a node may be assigned to one or multiple interface and can be of different kind. A key assumption in the Node Identity Internetworking architecture is the co-existence of independent locator domains. A locator domain (LD) has a consistent internal addressing and routing system. Nodes within one LD can freely communicate, only relying on internal services of the LD. Different LDs may employ different networking technologies, in particular IPv4, IPv6, global and private address spaces, so an LD boundary may also be a technology boundary. The Node Identity Internetworking architecture does not aim to unify the global network into a single, globally deployed networking technology, but accepts or even encourages the existence of different networking domains. E.g. the global IPv4 network can be seen as one LD. Private, NAT:ed networks can be seen as separate LDs. A second assumption is that connectivity between locator domains is dynamic, especially in the edge topology. That is, the existence and characteristics of connectivity between two locator domains, and between nodes and locator domains, may change dynamically on relatively short timescales, due to routing changes, mobility or multi-homing events or provider change of nodes or networks. A third assumption is that there will be a "core" LD, that is rather static. It can be compared to the current IPv4 backbone. Dynamicity - such as frequent (node or network) mobility and routing changes - is rather expected to happen closer to the edge of the topology. Similar to many other new network architecture proposals, the Node Identity Internetworking architecture is based on a naming scheme separating the node's identity from its locator or address. In this respect, it is very similar to the Host Identity Protocol [RFC4423]. Routing inside an LD is performed on LD-internal locators such as IPv4 and IPv6 addresses. When routing across LD boundaries forwarding is performed on forwarding tokens generated from the node ID (by e.g. hashing the node's public key) - the Node Identity Schuetz, et al. Expires March 17, 2008 [Page 6] Internet-Draft Node Identity Architecture September 2007 Forwarding Tag (NIFT) -, similar to the host identity tag employed in HIP. This approach will be explained in much more detail in later chapters. 3.2. Overview As already mentioned, the Node Identity Internetworking Architecture groups nodes into so-called locator domains or LDs in short. To recap, an LD is defined as a network domain with a consistent internal addressing and routing system, that means nodes can communicate without relying on any service that is external to the network domain. This also implies that a single LD has only one type of locator, e.g. IPv4 or IPv6 addresses. Note that one node can belong to more than one LD if it has more than one locator. A locator within one LD has absolutely no meaning within another LD, even if the two LDs employ the same internal addressing and routing system. As a consequence, overlapping locator/address spaces are not an issue anymore and locators do not need to be globally managed. They only need to be unique within a single LD. Routing within the Node Identity Internetworking Architecture follows a two-level approach: o Routing between nodes within an LD is solely based on the internal routing scheme of the respective LD. Each LD can therefore have a different routing scheme. o When crossing LD borders, the routing is based on the NID of the node, or more precisely on a fixed-length hash of its NID - the NID Forwarding Tag (NIFT) -, or on a so-called routing hint, which can also be a NIFT in the simplest case. The nodes that are attached to more than one LD and perform routing between the LDs are called Node Identity routers, or NRs for short. More details are given in Section 3.3. Note that within an IP-based LD two NRs can be multiple IP-hops apart from each other. 3.3. Details Figure 1 presents a small example topology that will be used to describe the Node Identity Internetworking Architecture in more detail. It shows one core LD (LD1) that is supposed to be rather static. In addition, there are two more LDs (LD2 and LD3) that are attached to the core LD through NRs (NR1 and NR2). LD4 and LD5 are attached to LD3 through NR3 and NR4. In addition, three other nodes A, B and C are present and belong to LD2, LD4 and LD5 respectively. Schuetz, et al. Expires March 17, 2008 [Page 7] Internet-Draft Node Identity Architecture September 2007 /--------------\ / \ / LD1 (core) \ / \ \ ------ ------ / \ | NS | | LS | / \ ------ ------ / ----\--------------/----- ( NR1 ) ( NR2 ) /-------\----- ----/-------\ / \ / \ X LD2 X X LD3 X \ / \ / \-------/ ----\-------/----- | ( NR3 ) ( NR4 ) +---+ /-------\---- ----/-------\ | A | / \ / \ +---+ X LD4 X X LD5 X \ / \ / \-------/ \-------/ | | +---+ +---+ | B | | C | +---+ +---+ Figure 1: Example topology Nodes within one LD, as described before, can directly communicate using the LD internal addressing and routing scheme. As an example, in the above figure node A can directly talk to NR1. To be reachable from outside their own LD, nodes need to register their NIFT along a chain of NRs starting from their own, local LD to a NR connected to the core LD. The NRs connected to the core are called core NRs (NR1 and NR2 in Figure 1) and have a special role as will be described later. During the registration process, the NRs use the registration information to set up a route from the node to the core NR and vice- versa. After this process has finished, a packet that needs to be delivered to a node can be routed along that path once it reaches the destination node's core NR. To illustrate this process, node A in Figure 1 would only need to register with its local Node ID router NR1. Packets arriving at NR1 destined for A can be delivered to A, as it has registered its locator, which is only valid within LD2 together with its NIFT. To actually get to NR1 from somewhere across the core network, e.g. from NR2, the Node Identity Internetworking Architecture employs so- called routing hints. Routing hints are tags that are used by any Schuetz, et al. Expires March 17, 2008 [Page 8] Internet-Draft Node Identity Architecture September 2007 core NR to retrieve the core locator (e.g. IPv4 address) of a destination's core NR. In the simplest case, the routing hint for a specific node is the NIFT of its core NR. To explain it with the help of Figure 1, a packet that arrives at NR2, destined for node A needs to be delivered to NR1 first as it holds the mapping between node A's NIFT and its LD2-internal locator. Similar to other ID/ LOC-based approaches, either a lookup system is needed to retrieve NR1's locator or, within the core, all core NRs need to hold this state about all other core NRs. Assuming the destination node is registered and both core NRs "know" each other or their NIFT can be resolved into a locator inside the core LD, a source node still needs to retrieve the destination nodes's NIFT and routing hint before communication between the two nodes can be initiated. The Node Identity Internetworking Architecture therefore requires a global naming system that maps a fully qualified domain name (FQDN) into a node's NIFT and a node's routing hint. The source node then needs to lookup the FQDN to receive these parameters before establishing communication. DNS is a candidate for such a naming system. As a complete example, if node A in Figure 1 wants to contact node B, the following actions need to be performed: 1. A sends a request to the global naming system (NS) to resolve the FQDN for B. This query returns B's NIFT and B's routing hint, i.e. in this case NR2's NIFT. 2. As A does not know where B is located it sends the packet to its default NR (NR1). The packet contains B's NIFT and B's routing hint. 3. NR1 also does not know where B is located (as it is not B's core NR) and checks the routing hint, which is NR2's NIFT. 4. NR1 either sends a request to the routing hint lookup system (LS) to resolve B's routing hint into NR2's locator (e.g. IPv4 address) or it has state for this mapping itself and can readily forward the packet to NR2. 5. NR1 forwards the packet to NR2. 6. NR2 knows from the registration information that B registered through NR3 and forwards the packet to NR3. 7. NR3 knows from the registration information that B is in its local LD and directly delivers the packet to B. Schuetz, et al. Expires March 17, 2008 [Page 9] Internet-Draft Node Identity Architecture September 2007 3.4. Mobility and Multihoming The Node Identity Internetworking Architecture can support a number of different protocol implementations and options for both routing and registration protocols. For example, registration can be recursive or iterative and there are protocol options that require more state than others (see Section 4). To a certain degree, the impact on mobility and multihoming depends on the chosen options. This section describes some of these implications. 3.4.1. Node and Network Mobility A node can move within its locator domain without impacting the Node ID architecture outside the LD itself. If locator changes occur within the LD, they have to be handled LD-internally, for example by refreshing the registration state inside the local NR or employing some mobility scheme locally. The sizing and layout of an LD therefore has some impact on the mobility handling. This fact could be used e.g. by a radio access network operator, giving the operator full control over the mobility mechanism employed without affecting the rest of the network not belonging to the operator when mobility events occur. When a node changes its attachment to a new locator domain, it needs to register with the new network. Depending on the topology overlap, the registration might reach a router which already knows the node re-registering. At this point, the registration process can stop - thus the effect of movement can be localized. Stale registration state will eventually time out, or explicit de-registration messages could be sent. Taking Figure 1 as an example and assuming node B attaches to LD5, then B's registration would eventually reach NR2 making B globally reachable again without having to propagate any information about the mobility event beyond NR2. If mobility causes a node to change the core NR it is attached to, and assuming the node is using the core NR's forwarding token as a routing hint, then the node would need to update the naming system (e.g. DNS) that maintains its reachability record. When a network moves, its NRs will obviously need to make itself "known" to the locator domain it attaches to. In addition, and more importantly, any registration state associated with nodes within the moving network needs to be correctly propagated towards, if possible, the old core NR to keep the overall registration overhead to a minimum. In that respect, the consequences are similar to the node mobility case depicted before. The nodes will not need to (re-)register in the local locator domain though. Schuetz, et al. Expires March 17, 2008 [Page 10] Internet-Draft Node Identity Architecture September 2007 3.4.2. Node and Network Multihoming A node with multiple interfaces could register in multiple locator domains simultaneously. In case the registration has disjoint registration paths ending up at two separate core NRs, the node's reachability record, e.g. its DNS entry, should hold both possible routing hints. A source node could then decide on a routing hint based on available criteria, such as possibly taken from the reachability record. In case registration paths overlap, routers receiving registrations for the same forwarding tag from different sources could perform traffic engineering based on policies. A key requirement in today's Internet is network multi-homing. Network multi-homing can be done in a number of different ways as shown in Figure 2. A network may be multi-homed to its provider network for example having multiple NRs connecting the two networks (NR5 and NR6 in Figure 2). A network may also be multi-homed in a way that it connects to two different provider networks (LD2 and LD3 in Figure 2). These provider networks in turn may or may not share a common core NR. /---------------------------\ / \ / LD1 (core) \ / \ \ / \ / \ / \---------------------------/ (NR1) (NR2) (NR3) /------\ /-------\--- ---/-------\ / \ / \ / \ X LD2 X X LD3 X X LD4 X \ / \ / \ / \------/ \-------/ \-------/ (NR4) (NR5) (NR6) (NR7) /---------------------------\ / \ / LD5 \ \ / \ / \---------------------------/ | +---+ | B | +---+ Schuetz, et al. Expires March 17, 2008 [Page 11] Internet-Draft Node Identity Architecture September 2007 Figure 2: Multi-homing topologies The registration process is the key in multi-homing and the description of the detailed operation is deferred to later draft versions. This section merely depicts the way it is done conceptually. Depending on the implementation details either the node has the responsibility to carry out the necessary registrations or NRs take care of this process. E.g. a service such as DHCP could advertise NR4 and NR5 to the node, which then registers at both. Alternatively, the NRs within an LD interact and exchange registration state to multi-home node B. Similarly, registration state can be propagated further up towards the core. For example, when being multi-homed using NR5 and NR6 in Figure 2, in LD3 multi- homing can be done in different ways, depending on implementation details, policy and security considerations. In addition, whenever a router receives registration state for the same forwarding tag relating to different routes, it can use it to perform traffic engineering on it or it can be used in case one of those multihoming options fails. 4. Protocol Sketch This section sketches how protocols implementing the Node Identity Architecture can be designed. It does not define the protocols in detail, but gives an overview of possible approaches and their implications. Section 4.1 sketches the protocol for registering a node's NID in the network while Section 4.2 sketches the protocol for sending actual data packets. 4.1. NID Registration Protocol A node that wants to be globally reachable needs to register its NID along a set of NRs from its own LD up to the core LD. This registration follows a default route up to the core, and builds the route from the core NR to the node in its local LD. The way NID registration is performed can be designed in a number of ways: recursive, iterative or in a mixed version. The details are discussed in the following sub-sections. 4.1.1. Recursive Operation In recursive operation, a node sends a registration request to its local (first hop) NR and waits for a response. The local NR is then in charge of further registering the NID towards the core LD on behalf of the node. The NRs should wait with sending a response Schuetz, et al. Expires March 17, 2008 [Page 12] Internet-Draft Node Identity Architecture September 2007 until they have received responses to the upstream requests, to inform the registering node about success or failure of the registration. This is illustrated in Figure 3 for Node B registering at NR 3 and NR 2. +--------+ +-------+ +-------+ | Node B | | NR 3 | | NR 2 | +--------+ +-------+ +-------+ | | | | Request(B) | | |----------------->| Request(B) | | |----------------->| | | | | | Response(OK) | | Response(OK) |<-----------------| |<-----------------| | | | | Figure 3: Recursive Registration The advantage of recursive operation is that the node only needs to know or find a local NR. Additionally, the scheme minimizes message round-trips. In recursive mode however, the NRs need to perform registrations on behalf of other nodes. That implies that, the nodes cannot influence where they get registered on the path towards the core. Second, the NR must be authorized through some mechanism that it can register another node. 4.1.2. Iterative Operation In iterative operation, a node that wants to be globally reachable registers its NID along a path towards the core LD one step at a time, as illustrated in Figure 4 for the same setup as in Figure 3. It needs to send one request after the other to each involved NR and receives an appropriate response. Optionally, if there is no other lookup system available to find the right NRs, the response can include the (or a set of potential) next hop NR that needs to be contacted . Schuetz, et al. Expires March 17, 2008 [Page 13] Internet-Draft Node Identity Architecture September 2007 +--------+ +-------+ +-------+ | Node B | | NR 3 | | NR 2 | +--------+ +-------+ +-------+ | | | | Request(B) | | |----------------->| | |<-----------------| | | Response(OK,NR 2)| | | | | | Request(B) | | |------------------------------------>| |<------------------------------------| | Response(OK) | | | | | Figure 4: Iterative Registration While the round-trip time for a full registration increases compared to the recursive operation, the iterative operation has different security properties and gives much more control of the path creation process to the end nodes - a node knows exactly at which NRs it gets registered or might even choose from several options. As the node itself registers it can use its own key material to register at NRs. If the security credentials of the registering nodes are to be used for the registration process in general (e.g. within organizations), then the iterative operation does not need an authorization mechanism to enable the NRs to carry out subsequent registrations. 4.2. Data Packets Data packets are routed on two levels. Within an LD, they are routed with the common routing system applied within that LD. At LD borders, routing is based on NIFTs. This section discusses different options for routing the data packets across LD borders. The following sub-sections differentiate the options based on the state that a NR needs to hold. In all proposals, NRs need to hold at least the forwarding state installed during NID registration, i.e. the default path from/to the core LD. This state is present in the NRs, no matter whether there is actual data traffic present or not. In this context, a routing approach is called "stateless" if no additional state/forwarding information needs to be created or held by a NR when a pair of nodes starts communication. On the other hand, a routing approach is called "stateful" if it requires to set up additional state/forwarding information in the NRs per communication pair or maybe even per communication session. For Schuetz, et al. Expires March 17, 2008 [Page 14] Internet-Draft Node Identity Architecture September 2007 example, a NAT box needs to install port mapping information per communication session, i.e. it is stateful. 4.2.1. Stateless Operation The first option is to include a new "NID header" in the data packets. This header includes (among others) the NIFT of the destination node and the same for the source node (see Figure 5) in addition to source and destination routing hint, all acquired from the FQDN resolution operation mentioned earlier. A NR - when receiving such a packet - checks the destination NIFT in the packet, to look up the next-hop NR or to send it directly to the destination node if it is in a local LD. ++-----+-----+---++-------+------+-------+------+---++-------+ ||dstIP|srcIP|...||dstNIFT|dstHnt|srcNIFT|srcHnt|...||payload| ++-----+-----+---++-------+------+-------+------+---++-------+ |--- IP header --||----------- NID header ----------| Figure 5: Example data packet within an IP-based LD The advantage of stateless operation for data packets is that a NR only needs to cache one entry per currently communicating destination NID, even if multiple sources communicate with it or run multiple sessions. The disadvantage is the overhead in message size and processing by including a NID header in every packet. Note: The result of a lookup of a next-hop NR as described above may be cached for a short period for efficiency reasons, i.e. to prevent a time-consuming lookup for every data packet, which makes the approach more stateful again. Still, this state can be dropped any time and re-created on demand. 4.2.2. Stateful Operation With stateful operation, communicating endpoints first need to signal to each other in order to install forwarding state at every NR on the communication path. NRs need to capture or read these signalling messages and install a mapping state for later data packets that do not include a NID header. An example for such an approach is HIP SPINAT [hip-spinat], which uses the SPI values in ESP packets [RFC4303] that are exchanged between peer nodes during the HIP base exchange [I-D.ietf-hip-base] to forward the HIP data packets, which are ESP encapsulated. Schuetz, et al. Expires March 17, 2008 [Page 15] Internet-Draft Node Identity Architecture September 2007 Using stateful operation reduces the header overhead compared to stateless operation, but also has some disadvantages. It requires an explicit signalling before the data packets can be sent, which prolongs communication establishment. It also makes the established communication more vulnerable to dynamics within the network, because every routing change - due to mobility or other reason - requires either to update installed state or install state at new NRs along the path. 5. Open Design Issuses This document presents an initial version of the Node Identity Internetworking Architecture. However, there is still a number of open design issues that need more detail and further discussion. This section gives an overview on the main open issues. Different options for the various issues should be discussed in later versions of this draft or as separate follow-up drafts. Routing Hint: The routing hint is a tag to find the locator of a core NR that is able to route towards the destination node. This document uses a simple approach and proposes to use the core NRs NIFTs as the routing hint. The architecture, however, can also support other types of routing hints. Currently under investigation is the introduction of an LD identifier - or LD ID - such that nodes register only within their local LD, and a local NR needs to register the LD (instead of the individual NIDs) towards the core. In that case, the routing hint would be the LD ID. Routing Hint Resolution System: Core NRs need to be able to map a routing hint into a routable (core) locator. In case of core NR NIFTs being the routing hint, it might be feasible to keep the mapping in every core NR. However, depending on the number of core NRs or different types of routing hints, a specialized resolution system may need to be installed. Such a system has not been designed yet, but could e.g. be based on DHT systems. Global Naming System: The Node Identity Internetworking Architecture requires a global naming system that needs to be able to map FQDNs into a node's NID and a node's routing hint. It is an open question whether this could also be implemented in two separate systems or should be integrated into a single one. DNS would be a natural candidate for such a system, which would require the definition of additional resource records. Schuetz, et al. Expires March 17, 2008 [Page 16] Internet-Draft Node Identity Architecture September 2007 NID Registration Protocol: The protocol design for a NID registration protocol is not decided yet. As discussed in section Section 4.1, different messaging schemes could be used to design such a protocol. Data Packet Protocol: Like the NID registration protocol, the protocol for sending data packets has not been defined yet. As discussed in section Section 4.2, various options are available to for its design. 6. Report on Prototype Implementation The concepts and design of the Node Identity Internetworking Architecture have been developed within the context of the EU/IST project Ambient Networks. The project is also required to provide a first proof-of-concept implementation. In order to speedup the development process, the project decided to base the first prototype on an existing implementation for the Host Identity Protocol (HIP) [I-D.ietf-hip-base]. The reason for using HIP as a code base is that the Host Identity Protocol employs a similar identifier/locator split as the Node Identity Internetworking Architecture. Basically, the Host Identity is used as a NID and the Host Identity Tag as the NIFT. The NID registration protocol is implemented as an extension to the HIP protocol. It was extended with a new HIP control packet type and a few new HIP parameters. The NID registration protocol was implemented in a recursive version as discussed in Section 4.1. The routing functionality is implemented as an extension to the previously existing HIP SPINAT implemenation [hip-spinat]. HIP SPINAT is a NAT implementation that multiplexes ESP data traffic based on the SPI values. HIP SPINAT basically reads all passing HIP control packets to extract the SPI values exchanged between end-hosts during a HIP base exchange or HIP UPDATE procedure. This functionality is modified to meet the needs of a NR. Consequently, the data packet protocol is implemented in a stateful version as discussed in Section 4.2. When two nodes start communication, they first execute an end-to-end HIP base exchange. The NRs along the path read the exchanged SPI values, which are later on used to forward the ESP-encapsulated data traffic. HIP control packets are forwarded by the NRs using an additional NID routing table which holds the forwarding information gathered by NID registrations. On IP-level, all packets (control and data) are always addressed to the next-hop NID node (either a NR or the destination node). A NR Schuetz, et al. Expires March 17, 2008 [Page 17] Internet-Draft Node Identity Architecture September 2007 receiving the packet replaces or rewrites the IP header to address the packet to the next-hop NID node. Prototype implementation is still work in progress, but the current implementation is already able to handle tree-based LD structures. LDs can be IPv4 or IPv6 networking domains, having local or global addresses. Within the testing environment, multi-hop communication across multiple NRs/LDs with different networking domain types has been succesfully tested. 7. IANA Considerations This document includes no request to IANA. 8. Security Considerations The Node Identity Internetworking architecture is based on cryptographic node identifiers similar to the Host Identity Protocol [RFC4423]. Therefore, the end-to-end security properties are - assuming proper protocol design - similar to those already expressed for the Host Identity Protocol [RFC4423] as it also employs a locator/identifier split with cryptographic identifiers. In addition, the NID registration process needs to be secured in various ways. First, the NRs must be protected against spoofed registrations, which can be done by authenticating the registration using the cryptographic nature of the NID. Second, NRs need to be DoS protected against registration floods. Third, a node performing a NID registration needs a secure means to lookup the right NRs to register with. Furthermore, depending on the design of the registration protocol, a recursive registration scheme needs a mechanism for authorizing NRs to perform registrations on behalf of other nodes. 9. Acknowledgments The authors are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. The authors would like to thank Jarno Rajahalme and Hannu Flinck for their valuable comments that greatly helped to improve this document. Schuetz, et al. Expires March 17, 2008 [Page 18] Internet-Draft Node Identity Architecture September 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08 (work in progress), June 2007. [I-D.irtf-rrg-design-goals] Li, T., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01 (work in progress), July 2007. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [hip-spinat] Ylitalo, J., Salmela, P., and H. Tschofenig, "SPINAT: Integrating IPsec into Overlay Routing", In Proc. of Security and Privacy for Emerging Areas in Communications Networks (SecureComm '05)., Sept. 2005. [nid-global-internet] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A Node Identity Internetworking Architecture", In Proc. of 9th IEEE Global Internet Symposium, Barcelona, Spain, April 2006. Appendix A. Document Revision History +----------+-------------------------------------------------------+ | Revision | Comments | +----------+-------------------------------------------------------+ | 00 | Initial version. | +----------+-------------------------------------------------------+ Schuetz, et al. Expires March 17, 2008 [Page 19] Internet-Draft Node Identity Architecture September 2007 Authors' Addresses Simon Schuetz (editor) NEC Laboratories Europe Kurfuersten-Anlage 36 Heidelberg, 69115 Germany Email: simon.schuetz@nw.neclab.eu Rolf Winter NEC Laboratories Europe Kurfuersten-Anlage 36 Heidelberg, 69115 Germany Email: rolf.winter@nw.neclab.eu Louise Burness BT Group Networks Research Centre B54/77 BT Labs Martlesham Heath, Ipswich IP5 3RE United Kingdom Email: louise.burness@bt.com Philip Eardley BT B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk, IP5 3RE United Kingdom Phone: Fax: Email: philip.eardley@bt.com Bengt Ahlgren Swedish Institute of Computer Science Box 1263 Kista, SE-164 29 Sweden Email: bengta@sics.se Schuetz, et al. Expires March 17, 2008 [Page 20] Internet-Draft Node Identity Architecture September 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). Schuetz, et al. Expires March 17, 2008 [Page 21]