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]