One document matched: draft-nikander-ram-ilse-00.txt
Network Working Group P. Nikander
Internet-Draft Ericsson Research Nomadic Lab
Intended status: Informational February 26, 2007
Expires: August 30, 2007
Identifier / Locator Separation: Exploration of the Design Space (ILSE)
draft-nikander-ram-ilse-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Implementing the so called identifier / locator separation may have
far-reaching consequences to the Internet architecture, depending
very much on how exactly it is implemented. That is, here as in many
other cases, the devil lies very much in the details.
In this document, we attempt to outline the various aspects of the
design space. We briefly discuss six main aspects: identifiers,
dynamic traffic management, end-to-end issues, security, economics,
Nikander Expires August 30, 2007 [Page 1]
Internet-Draft ILSE February 2007
and deployment. In this initial version of the document, we still
lack many details.
This document is a reaction to the problem statement effort at the
Amsterdam IAB Routing and Addressing Workshop (RAWS).
Nikander Expires August 30, 2007 [Page 2]
Internet-Draft ILSE February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Identifiers, resolution, and routing . . . . . . . . . . . 6
3.1. Identifier uniqueness and stability . . . . . . . . . . . 7
3.1.1. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Stability or persistence . . . . . . . . . . . . . . . . . 8
3.2. Resolution vs. identifier-based routing . . . . . . . . . 9
3.2.1. Resolving identifiers into locators . . . . . . . . . . . 9
3.2.2. Identifier-based routing . . . . . . . . . . . . . . . . . 10
3.2.3. Mapping security . . . . . . . . . . . . . . . . . . . . . 11
3.3. Backwards compatibility . . . . . . . . . . . . . . . . . 12
3.3.1. API compatibility . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Host-Router interface . . . . . . . . . . . . . . . . . . 13
3.4. Identifier syntax and structure . . . . . . . . . . . . . 13
4. Dynamics and policy: Mobility, Multi-homing, and
Traffic Engineering . . . . . . . . . . . . . . . . . . . 14
4.1. Spatial scoping of identifiers . . . . . . . . . . . . . . 14
4.2. Identifier layering and dynamic resolution . . . . . . . . 14
4.3. TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Route converge . . . . . . . . . . . . . . . . . . . . . . 14
5. Transport and other end-to-end issues . . . . . . . . . . 14
5.1. Interactions with middle boxes . . . . . . . . . . . . . . 15
5.2. Alternative paths and congestion . . . . . . . . . . . . . 15
6. Trust models, security, and privacy . . . . . . . . . . . 15
6.1. Trust models . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Threat analysis . . . . . . . . . . . . . . . . . . . . . 15
6.3. Known security mechanisms . . . . . . . . . . . . . . . . 15
6.4. Privacy aspects . . . . . . . . . . . . . . . . . . . . . 15
7. Economic aspects . . . . . . . . . . . . . . . . . . . . . 15
7.1. Peering and transit agreements . . . . . . . . . . . . . . 15
7.2. Computational mechanism design of protocols . . . . . . . 15
7.3. Cost and compensation . . . . . . . . . . . . . . . . . . 15
7.3.1. Routing and forwarding table sizes . . . . . . . . . . . . 15
8. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Incremental deployment . . . . . . . . . . . . . . . . . . 15
8.2. Incentives . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. Handling legacy sites . . . . . . . . . . . . . . . . . . 15
9. Open issues . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security considerations . . . . . . . . . . . . . . . . . 15
11. IANA considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 16
13. Informative references . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . 18
Nikander Expires August 30, 2007 [Page 3]
Internet-Draft ILSE February 2007
1. Introduction
The so called identifier / locator separation has been under heavy
debate within the IETF community for the last 10 year or so. Many
people have argued for its desirability, and a number of proposals of
implementing it, in one or another way, have been produced [3], [6].
More recently, as a result of the 2006 IAB Routing and Addressing
workshop [7], the discussion has gained more momentum but
simultaenously focused mostly on the immediate need of relieving
pressures on the routing tables.
In this document, we attempt to take to take a wider and hopefully
more balanced look at various design aspects, and their consequences.
Our goal is to make the community more aware of the opportunities the
identifier / locator separation potentially provides to the
architecture and its further development.
The rest of this document is organised as follows. First, in
Section 2 give give a brief summary of the background thinking for
the uninitiated reader. In Section 3 we discuss design issues
related to the identifier space itself, and especially to how to
resolve identifiers to locators or perform (overlay) routing directly
with the identifiers. Next, in Section 4, we discuss issues related
to the dynamic nature of the network and policies involved, including
mobility, multi-homing, and traffic engineering. In Section
Section 5 we briefly cover a few transport end end-to-end issues;
however, as the present authors include now transport-layer expert,
this discussion is necessarily scanty at the moment. Section
Section 6 is devoted to security, trust, and privacy. Section
Section 7 covers a number of non-security-related economic aspects of
networking, including peering agreements, computational mechanism
design in protocol design, and overall cost and cost distribution of
the network. Finally, Section 8 covers a number of deployment issues
not covered before, and Section 9 discusses a few open issues not
fitting elsewhere.
2. Background
TBD: This section is a skeleton, needing more work.
As early as 1982, it was recognised that the current Internet
architecture provides insufficient means to identify services and
users [1]. Since then the community has rampantly discussed [5] the
need or non-need of adding a separate name space (identifier space)
for network nodes, as opposed for network attachment points
(locators), with wildly varying opinions even about the state of
reality.
Nikander Expires August 30, 2007 [Page 4]
Internet-Draft ILSE February 2007
In late 1990s, the more academic or theoretical part of the community
had converged to the stance that some sort of an end-point name space
were needed [14]. That notion resulted, among other things, to the
development of the HIP architecture [3], which then later on had
quite a lot of influence to the development of the SHIM6 protocol
[6]. At the same time, the idea was studied extensively in the
academia (TBD: add a representative small number of references).
Most recently, triggering the current flock of activity, the IAB held
a workshop on Addressing and Routing (RAWS) in October 2006,
identifying the current semantic overloading of IP addresses as one
problem area, and briefly discussing a few proposals in the
identifier / locator separation solution space [7].
In the resulting discussion at the IAB initiated architecture-discuss
[12] and ram [13] mailing lists, has led to the following tentative
conclusions:
o There are two almost orthogonal aspects when implementing the
identifier / locator separation:
1. A more architectural aspect of where, in the layering sense,
to implement the separation. That is, when considering the
vertical stacking order of the protocol layers, where in this
stacking order the separation is placed.
2. A more implementational aspect of where, in the real-world
sense, to implement the separation. That is, when considering
the various devices needed to implement a communications path,
including the host proper, device driver, and routers and
other middle boxes, where in this implementational sense the
separation is placed.
These two aspects are considered only almost independent since the
higher in the stack the separation is located in the architectural
sense, the harder it is to implement it closer to or within the
network (middle boxes). Such within-the-network implementation is
considered beneficial and important due to deployment reasons, in
order to help supporting legacy hosts [8].
o Architecturally, the vertical locations within-the-stack where the
separation may be implemented can be roughly divided into three
different categories:
A. The separation may be implemented above the current transport
layer, mainly TCP and UDP. In practise, many applications do
implement a primitive kind of the separation already
themselves. In theory, a library could implement the
Nikander Expires August 30, 2007 [Page 5]
Internet-Draft ILSE February 2007
separation, giving legacy applications the illustration of
them being still connected to stable IP locators while in
practise using some sort of identifiers.
B. The separation may be implemented at or below the transport
(i.e. below the socket API) but above the routing part of the
IP layer. There are a plenty of proposals in this space,
including SCTP extensions [10], the Host Identity Protocol
(HIP) [3], and the SHIM6 protocol [6].
C. The separation may be implemented below the host-part of the
IP layer. Again, there are a number of proposals in this
space, of which the [9] has recently gained some attention.
What is noteworthy here is that, as argued in [8] in more detail,
there is considerable freedom in the implementational aspect
independent of the architectural choice. That is, even the
application layer approaches can be implemented within the network
with the help of proxies, if so desired. Conversely, implementations
mainly targeted to be implemented within the network, such as [9],
may be implemented within the host stack. Consequently, as we will
argue in more detail below, it is not the architectural nor the
implementation location of the separation that matters most, but
other aspects, such as the nature of identifiers, the ability to
handle network dynamics and policy, and the trust model. They will
have fundamental consequences in the future ability of the network to
evolve to support new functions and features. We hope that this, as
well as its consequences, will become clearer below.
Finally, we will passingly note that there is a parallel, longer-
reaching discussion going on the exact semantic nature of host
identifiers, i.e., whether the notion of host identifiers should be
extended to also include other types of hosts but nodes, including
all kinds of aggretable coalitions of application names, including
but not limited to virtual and distributed hosts. However, since
that discussion is only likely to confuse the average uninitiated
reader, we will pursue that not any further. Instead, throughout the
rest of this document, we take the simplifying assumption that node
names are needed just as such, as discussed in [1], unless explicitly
noted otherwise.
3. Identifiers, resolution, and routing
In this section, we discuss the perhaps most important aspect of the
proposed separation: the nature of the identifiers. Unfront, we take
the stance the it must be possible to represent the identifiers in a
backwards compatible way to legacy applications and hosts; this
Nikander Expires August 30, 2007 [Page 6]
Internet-Draft ILSE February 2007
aspect is explored more in Section 3.3 and Section 8, below.
In the following subsections, we will cover three distinct aspects
related to identifiers, as follows. However, this is by no means an
exhaustive list; it is just a choice of aspects that seem most
relevant to the current discussion.
o In Section 3.1, we consider the identifiers more from the
applications point of view, focusing on their uniqueness and
stability.
o Next, in Section 3.2, we consider by-system-provided function of
mapping the identifiers to a (set of) locator(s).
o As a third aspect, in Section 3.3, we consider backwards
compatibility of the identifiers.
o Based on the discussion in the first three subsections, in
Section 3.4, we consider the syntax and structure of identifiers
and their representations.
When reading what follows, it is important to remember that the
representation of the identifiers in a backwards compatible way need
not be the native form of the identifiers. For example, while HIP
represents the identifiers as 128-bits long Host Identity Tags or 32-
bits long Local Scope Identifiers for backwards compatibility, the
only defined native form of HIP identifiers are public cryptographic
keys.
3.1. Identifier uniqueness and stability
From an applications point of view, it is very desirable to have
genuinely unique and temporarly stable identifiers. If the
identifiers by themselves do not provide enough of means for
contacting and identifying the peers over space and time, the
applications need other means to achieve their identification goals,
partially foiling the very purpose of the identifiers. (That is, the
identifiers may still be very useful for the network and for
initiating communication.)
3.1.1. Uniqueness
The very word identifier (stemming from late Lat. identitas, in turn
stemming from early Lat. idem et idem, "same and same" or "again and
again", or "identidem", repeatedly) implies uniqueness, the ability
to uniquely identify an identity based on the identifier; a naturally
very desirable property. However, on a closer look the situation may
not be that black and white.
Nikander Expires August 30, 2007 [Page 7]
Internet-Draft ILSE February 2007
Technically, absolute uniqueness implies assurance that a given
identity will under no circumstances be used, even accidentally, by
more than on entity. Of course, in a large and decentrally
administered network such assurance is impossible to achieve.
Consequently, any realistic system must include measures to handle
the odd situation where more than one entities claim the same
identity, by accident or malice.
Based on the above observation, it has been suggested that maybe even
aiming for absolute uniqueness is undesirable due to its likely
administrative cost. As an alternative, it might be more profitable
to use long enough pseudo-random identifiers so that the statistical
probability of collisions becomes sufficiently low. Furthermore, if
the construction of the identifiers uses a suitably constructed
cryptographically strong one-way function on data that is guaranteed
to carry enough of entropy, one can virtually eliminate the potential
of collisions due to malice or human error, leaving randomness as the
only source of collisions; see e.g. [2].
As a counter-argument, it has been stated that in order to reach low
enough probability of collisions, the identifiers become too long.
Depending on the context of identifier interpretation, this may well
be true for very short identifier fields, such as entities of IPv4
address size, 32 bits or 4 octets; see Section 3.3. However, roughly
60 bits or more seems to provide enough of statistical uniqueness for
many practical purposes (see, e.g., [15] or [2]), and 256 bits (32
octets) seems large enough for even the most demanding cases.
In the case of statistical uniqueness being impossible due to the
short length of identifiers or undesirable, for example, due to human
factors, the only other proven way to ensure identifier uniqueness is
through a centrally delegated hierarchical administration, in the
manner IP addresses and DNS names are assigned today. That has the
known problem of creating an artificial monopoly point, requiring
explicit regulation.
3.1.2. Stability or persistence
Historically, most concern on identifier stability in the Internet
has been a result of increased node mobility. In the current system,
where IP addresses are used both as locators and as identifiers, node
mobility leads to cumbersome mechanisms where the same name space (IP
addresses) are used for two semantically different purposes, leading
to the aliasing problem, well known from programming language data
flow analysis. Unfortunately, to our knowledge, the effects of this
problem to distributed systems have not been formally analysed.
Generalising slightly, there are also other networking phenomena that
Nikander Expires August 30, 2007 [Page 8]
Internet-Draft ILSE February 2007
easily lead to issues with identifier stability. For example, as
discussed in Section 4.3 below, certain aspects of multi-homing and
traffic engineering may be easier to solve if the locators can be
easily changes. Conversely, the current desire to keep IP addresses
stable in order not to require administrative changes unnecessarily
complicates the existing practises, leading demonstratably to some
routing table growth.
Extending the argument, we can state that it is desirable to shield
applications from unnecessary changes of identifiers while allowing
the network to change locators as it needs.
3.2. Resolution vs. identifier-based routing
Separating the identifier and locator roles of IP addresses
necessitates a means for maintaining mappings from identifiers to
locators. There are two basic approaches to this: resolution and
identifier-based routing.
3.2.1. Resolving identifiers into locators
The better known way of maintaining name-to-address mappings is
resolution. Resolution is familiar from the Domain Name System
(DNS). In resolution, the client sends an explicit query message to
a server, the query message containing the to-be-resolved name. The
server responds with a reply containing both the name and the
corresponding address or addresses.
When considering the identifier / locator separation, it would feel
natural to resolve the identifiers into locators in the same way:
using an explicit server and a query-response system. However, while
that model is familiar, it has a couple of potential architectural
drawbacks:
o Almost by necessity, controlling access to the information must be
implemented separately from the primary entities that the
information concerns. That is, in this model it is natural that
the name servers control whom may access the information, without
involving the identified nodes at all.
o Compared to the identifier-based-routing model (below), the
resolution model includes a separate resolution step while the
identifier-based-routing model folds this step into very operation
of initiating communication.
It can be well argued if the latter is a drawback or benefit. At one
hand, it may be considered as a source of inefficiency. At the other
hand, it allows one to find the current set of locators without
Nikander Expires August 30, 2007 [Page 9]
Internet-Draft ILSE February 2007
initiating communication at all.
3.2.2. Identifier-based routing
An alternative to explicit resolution is to combine identifier-based
routing with locator determination. In this approach, the first (or
first few) packet is send over a routing infrastructure that can
route based on identifiers (as opposed to locators). Depending on
the details, such a routing infrastructure can be the same as the one
for locators (as in LISP1 [9], PASH1 [11], or SHIM6 [6]), can be
parallel to the regular routing one (as in LISP1.5 or PASH1.5), or
can be an overlay one, e.g., based on Distributed Hash Tables (DHTs).
There are plenty of examples of the last approach, including Berkeley
i3 [16].
The basic idea here goes as follows:
1. The first packet is sent essentially as such, over the
identifier-routing-capable infrastructure. Optionally, the
packet may be tagged with the sender's locators, allowing the
recipient to learn them.
2. Once the packet is received by the recipient, it processes it and
decides whether to respond. If the first message did not include
the initiator's locators, also the second packet must be passed
over the identifier-routing-capable infrastructure.
3. At some point, typically during the first few packets, the hosts
reveal their locators to their peers, allowing all further
communication to pass directly over the locator-based routing
infrastructure.
In many incarnations of this idea, the identity-routing
infrastructure is a magnitude or more less efficient than the
locator-routing infrastructure; for one data point, see [17]. In
practise, this is usually not a problem since only one or a few
initial packets will be routed over the identity-routing
infrastructure and the rest over the more efficient locator-routing
infrastructure.
There are a few potential benefits of this approach, when compared to
explicit identifier resolution:
o Both host have full control of when to reveal their locators to
their peers. Conversely, the hosts may continue to communicate
over the identity-routing infrastructure, trading routing
efficiency for increased privacy and resiliance.
Nikander Expires August 30, 2007 [Page 10]
Internet-Draft ILSE February 2007
o The identity-routing infrastructure can often provide better
resiliance properties than explicit resolution, mostly due to
different time dynamics.
o Initial communication may take place more efficiency than in the
resolution model, since the infrastructure can pass the first data
packet directly to the recipient instead of waiting for the reply
to reach the initiator, which then in turn sends the first data
packet to the recipient.
3.2.3. Mapping security
The security aspects of the identifier-to-locator mapping have been
extensively studied in the context of mobility protocols (see e.g.
[4] and [18]). The basic types of attacks can be enumerated as
follows:
1. Attacks against locator "owners", including stealing of known
future locators, attacks against secrecy and integrity of data,
and basic forms of denial-of-service (blackholing).
2. Attacks against other network nodes or links, i.e., the so called
flooding attacks. These attacks are often ignored by naive
protocol designers, as they are not as obvious as the attacks in
the first category.
3. Attacks against whatever security mechanisms are used to mitigate
the two first classes of attacks.
At the time of this writing, the common wisdom of measures effective
countering the attacks include the following ones:
a. Return routability is currently the only known effective way of
countering against flooding attacks. Basically, in return
routability the verifying node checks that the peer can receive
and reply to messages sent to the claimed locators. Return
routability also helps with many of the attacks against address
"owners." However, it must be noted that return routability is
not effective against on-path or intrastructure-spoofing
attackers.
b. Careful design of the protocol used to create and maintain
mappings helps against the third type of threats. In practise,
this means using cryptographic checks. Note, however, that
traditional key distribution is typically NOT needed. Instead,
more primitive methods, such as hash chains, can usually be
safely used.
Nikander Expires August 30, 2007 [Page 11]
Internet-Draft ILSE February 2007
c. Reverifying the mapping state often (e.g. every few minutes)
helps against time-related attacks (e.g. future location steal.)
This adds signalling load but typically avoids the need for extra
infrastructure.
d. Self-certifying identifiers, e.g., using public cryptographic
keys as primary identifiers, helps with solving many "ownership"
attacks, but seems to be by no means a necessity, at least in
many situations.
3.3. Backwards compatibility
During the last year or so, quite a lot of network-related research
has focused on the so called clean slate approaches, aiming for new
types of networking going far beyond to what the current Internet is
able to achieve. Consequently, for a relatively modest architectural
change, as compared to clean slate, such as the identifier locator
separation, it is even more important than before to be backwards
compatible.
Considering the current Internet architecture, there seems to be two
interfaces where the backwards compatibility issues condense: the
host-to-router interface over the local wire, and the stack-to-
application interface over the local API. In both cases, there
organisations and individuals responsible for the behaviour at one
side of the inferface are typically completely different from the
ones at the other side, e.g., representing different vendors from
different vendor communities.
As outlined in [8], there are two main options for implementing
different kinds of identifier locator separation: within-the-stack,
or within-the-network. In an in-the-stack approach, the host-to-
router interface continues to use locators and the stack-to-
application interface is converted to use identifiers. In an in-the-
network approach both of these interfaces are converted to use
identifiers, and locators are used only deeper in the network.
Consequently, an in-the-network approach appears to have more
stringent backwards compatibility requirements, i.e., it needs to
preserve more of the current address semantics when replacing them
with identifiers than the in-the-stack approach needs to do.
3.3.1. API compatibility
Let us consider the stack-to-application API interface first. While
there are more advanced APIs, the majority of todays applications use
some variation of the so called Berkeley sockets interface.
Furthermore, while a large fraction of the solutions have been
carefully written to be able to deal with different sorts of
Nikander Expires August 30, 2007 [Page 12]
Internet-Draft ILSE February 2007
addressings, even beyond IPv4 and IPv6 addresses, almost none of them
have actually ever been tested with anything else but IP addresses.
And, of course, there exists important legacy applications that know
of nothing else but IPv4 addresses, but their use is often confined
to organisational-internal use.
For most applications, the IP addresses are simple binary blobs.
(Diagnostic applications are a prime counterexample, but they will
need to be modified anyway for any realistic identifier locator
separation approach.) Given an IP address, a typical application
assumes that it can either create TCP connections or send UDP packets
to a corresponding application hosted at the given address, and
receive replies from the same address, no more or no less. Hence,
this appears to be the most important piece of semantics to preserve.
Unfortunately, there appears to be a number of important applications
that assume more. Basically, they assume that they can hand the
address (either as a binary blob or encoded as an ascii string) to
any other host and that host will also be able to use the address in
the same way. This is the so called referral problem. Fortunately,
for the present discussion, this property has already been largely
broken by the prevalence of NATs and firewalls, and therefore is not
that important any more than it once was.
3.3.2. Host-Router interface
TBD: This section needs to be written.
3.4. Identifier syntax and structure
The main forces affecting identifier syntax seem to be the following:
Uniqueness; see Section 3.1. Here there seems to be a tension
between the hierarchical and pseudo-random assignment approaches.
Routability; see Section 3.2. Here a big question is the scope of
routability. If the identifier locator separation is implemented
within the host stack or if the identifiers are routed through a
completely separate infrastructure, the identifier structure may
be determined without any routability considerations. If the
separation is implemented as on optional feature, as it may in the
very beginning, it may be necessary for the identifiers to be
fully routable in the traditional IP sense of the world. In some
other cases, a simple routable prefix may suffice.
Nikander Expires August 30, 2007 [Page 13]
Internet-Draft ILSE February 2007
Security; see Section 3.2.3. The desirable self-certifying property
necessarily means that at least some part of the identifier would
be cryptographic in nature, and therefore random looking.
Size, including backwards compatibility issues. Obviously, the
smaller the better, and if the identifiers, or some representation
of them, can be fitted into legacy IPv4 and IPv6 address sizes,
even better.
Additional potential requirements that we do not discuss here, on
purpose, include human friendliness, ...
Based on that, we would tentatively recommend a two-pronged strategy:
1. Leave the actual structure and syntax of the to-be-identifiers as
open as possible for as long as possible. That is, try to avoid
building syntax-dependencies in the rest of the design.
2. Plan early on for suitable backwards-compatible representations.
Here a major focus should be in determining the contexts within
which the representations will be interpreted, as that will
affect the requirements on uniqueness. Furthermore, try also to
determine if the referral problem is really an Internet-wide
phenomenon or do less stringent backwards compatibility suffice.
4. Dynamics and policy: Mobility, Multi-homing, and Traffic Engineering
In this section, we consider the design from the point of view of
dynamic events and policies controlling the network behaviour.
The rest of this document is an outline for future work.
4.1. Spatial scoping of identifiers
4.2. Identifier layering and dynamic resolution
4.3. TBD
TBD: Add here material from Elwyn Davies note on the architectural
similarities between multi-homing and traffic engineering.
4.4. Route converge
5. Transport and other end-to-end issues
Nikander Expires August 30, 2007 [Page 14]
Internet-Draft ILSE February 2007
5.1. Interactions with middle boxes
5.2. Alternative paths and congestion
6. Trust models, security, and privacy
6.1. Trust models
6.2. Threat analysis
6.3. Known security mechanisms
6.4. Privacy aspects
7. Economic aspects
7.1. Peering and transit agreements
7.2. Computational mechanism design of protocols
7.3. Cost and compensation
7.3.1. Routing and forwarding table sizes
8. Deployment
8.1. Incremental deployment
8.2. Incentives
8.3. Handling legacy sites
9. Open issues
10. Security considerations
At this stage, we haven't worked out all the security details. Some
security aspects have been discussed in Section Section 6.
Nikander Expires August 30, 2007 [Page 15]
Internet-Draft ILSE February 2007
11. IANA considerations
This document has no actions for IANA.
12. Acknowledgments
We have shamelessly borrowed text from Elwyn Davies' posting to the
RAM mailing list for the discussion about the relationship between
multi-homing and traffic engineering, in Section 4.3.
13. Informative references
[1] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993.
[2] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[3] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[4] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[5] Lear, E. and R. Droms, "What's In A Name:Thoughts from the
NSRG", draft-irtf-nsrg-report-10 (work in progress),
September 2003.
[6] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-06 (work in progress),
October 2006.
[7] Meyers, D., "Report from the IAB Workshop on Routing and
Addressing", draft-iab-raws-report-00 (work in progress),
December 2006.
[8] Nikander, P., "Generic Proxying as a Deployment Tool (GEPROD)",
draft-nikander-ram-generix-proxying-00 (work in progress),
January 2007.
[9] Farinacci, D., "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-00 (work in progress), January 2007.
[10] Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration",
Nikander Expires August 30, 2007 [Page 16]
Internet-Draft ILSE February 2007
draft-ietf-tsvwg-addip-sctp-09 (work in progress), June 2004.
[11] Nikander, P. and K. Slavov, "Proxying Approach to SHIM6 and
HIP", draft-nikander-ram-pash-00 (work in progress),
February 2007.
[12] IAB, "Architecture-discuss -- open discussion forum for long/
wide-range architectural issues".
[13] IAB, "RAM -- Routing and Addressing Mailing List".
[14] Chiappa, J., "Endpoints and Endpoint Names: A Proposed
Enhancement to the Internet Architecture",
URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999.
[15] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses",
URL http://www.isoc.org/isoc/conferences/ndss/02/proceedings/
papers/monten.pdf, 2002.
[16] Stoica, I., Atkins, D., Zhuang, S., Shenker, S., and S. Surana,
"Internet Indirection Infrastructure (i3)",
URL http://i3.cs.berkeley.edu/, 2002.
[17] Gurtov, A., Korzun, D., and P. Nikander, "Hi3: An Efficient and
Secure Networking Architecture for Mobile Hosts", URL http://
www.tml.tkk.fi/~pnr/publications/
HIIT_gurtov_hi3_report_2005.pdf, 2005.
[18] Aura, T., Nikander, P., and G. Camarillo, "Effects of Mobility
and Multihoming on Transport-Layer Security", URL http://
www.tml.tkk.fi/~pnr/publications/
aura-nikander-camarillo-ssp04.pdf, 2004.
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 August 30, 2007 [Page 17]
Internet-Draft ILSE February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nikander Expires August 30, 2007 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 06:46:59 |