[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Review of ILNP -- plus a new idea
[Sorry for a long email. I know I am over-stretching my "talk time"
quota on this mailing list for a month or so...]
Hi Ran,
I read your ILNP proposal [1] and thought it has great ideas in it. I
very much like the new API you are proposing, the interface between
applications and transport protocols that hides IP addresses from the
former. Nevertheless, if I have understood the ILNP specification
correctly, there may be an issue with the identifier/locator split
that ILNP introduces between transport protocols and the IP layer. I
would like to discuss this issue with you below. In addition, let me
sketch an alternative protocol, which is based on a variant of your
proposed API, and does without any identifier/locator split.
I identified two basic components in ILNP:
(1) a new API between applications and transport protocols, which
hides IP addresses from the applications, and
(2) an identifier/locator split between transport protocols and the IP
layer, according to which transport protocols identify sessions
only based on the lower 64 bit in each of a pair of IP addresses.
So ILNP has three naming layers -- host names, identifiers, and
locators -- and two indirections.
I think component (1) is great because...
- it reduces renumbering complexity: A potentially very expensive
part of renumbering is updating hardcoded addresses in
applications. This is mitigated in ILNP because applications are
by design limited to host names (at the cost of having to
configure a host name for every host in DNS).
- it makes application programming easier: Host name resolution and
address selection are transparently handled by the IP layer and do
not have to be replicated in every application.
- it increases manageability and user friendliness because only
human-readable host names are visible in applications.
But what I think won't work well with component (2) is that the
operation of ILNP requires identifiers to be globally unique, although
the protocol does not (and cannot) guarantee such uniqueness.
Let me be more specific: According to the definition in section 1 of
[1], identifiers (the lower 64 bit in IP addresses) don't have to be
globally unique. They have to be unique only locally within the
context of a given locator. This local uniqueness is advantageous for
two reasons:
- Local uniqueness enables autonomous generation of identifiers, e.g.,
using Stateless Address Autoconfiguration.
- Global uniqueness would be hard to realize, independent of whether
the uniqueness was to be guaranteed or statistical:
--> If global uniqueness was to be guaranteed, central allocation
would be required. But since identifiers don't have topological
meaning, it would be facile to forgo the allocation procedure.
This is exactly what happens today with MAC addresses.
--> If statistical uniqueness was sufficient, the allocation problem
would be mitigated. But this would come at the cost of a
non-negligible risk of breaking upper-layer connections due to
identifier collisions. An identifier collision could happen in
two cases: (a) whenever a host communicates with two
correspondent hosts that happen to use the same identifier in
the context of their respective locators; and (b) whenever a
host's identifier is already in use by a neighbor on ANY of the
links to which the host attaches. Note that (b) is problematic
in particular for hosts that are mobile.
So there are good reasons why ILNP limits the uniqueness of
identifiers to local scope. But on the other hand, ILNP's operation
does require identifiers to be globally unique: Transport connections
are bound to an identifier that is valid for multiple locators (both
simultaneously or sequentially), which requires that the identifier is
unique within the contexts of ALL locators. The only practical way to
ensure this, in the presence of mobility and multi-homing, is for the
identifier to be globally unique.
So in short: My understanding is that, whereas ILNP requires
identifiers to be globally unique, it does not and can not provide
global identifier uniqueness. (Perhaps I am missing something. Let
me know if that is the case.)
Now, I have a suggestion for a related, but different protocol that
does not have this "uniqueness problem". This is based on ILNP's API
between applications and transport protocols -- which, again, exposes
only host names, but no IP addresses to applications. But instead of
using IP addresses in transport protocols, we move the boundary
between host names and IP addresses to between transport protocols and
the IP layer. Consequently, both applications and transport protocols
by default operate exclusively on host names, and only the IP layer
uses IP addresses. IP addresses have only locator semantics, but no
identification semantics. The IP layer is then responsible for host
name resolution, address selection, and multi-address management
(mobility, multi-homing, privacy addressing, etc.). Applications and
transport protocols may, optionally, interact with address selection
and multi-address management through a well-defined interface towards
the IP layer. This would enable applications or transport protocols to
select a specific path, or to distribute traffic over multiple paths.
As a result, this protocol does without any identifier/locator split
other than the existing split between host names and IP addresses.
Some more specific aspects of the protocol:
MULTI-ADDRESS MANAGEMENT. To enable a host to change its IP address
without losing active communiation sessions or reachability for new
communication sessions, the host must have means to inform current
correspondent hosts about the new IP address, and to quickly update
DNS. Correspondent hosts can be updated with a direct message
exchange. To realize fast DNS updates, one option would be to
introduce rendez-vous servers (like in the Host Identify Protocol).
The rendez-vous servers would be anchored in DNS as well, but since
they do not use caching, they could be updated more efficiently. A
second alternative might be to reduce caching in DNS for mobile or
multi-homed hosts. Recent research [2] indicates that this might be
feasible without making DNS unscalable, since there is evidence that
DNS may actually be less dependend on caching than commonly believed.
(I personally prefer the rendez-vous server approach, but this is
irrelevant at this point.)
SECURITY. To prevent misuse of multi-address management for
illegitimate traffic redirection, hosts must verify the IP address
updates of correspondent host. Various methods are possible for this
purpose. One is the nonce-based message exchange that ILNP uses. This
is fast and lightweight, but weak because nonces can be snooped and
replayed. Snooping is especially an issue on the wireless links to
which mobile hosts typically attach. An alternative approach is for
hosts to check with DNS (or with the rendez-vous server of the
correspondent host) whether the new IP address of the correspondent
host is legitimate. This builds on the security model of DNS: DNS
uses a trusted root and delegation along administrative relationships
to ensure that queries are handled by only those entities, which by
nature have an interest in serving the queries in a faithful manner.
And securing DNS updates (or rendez-vous server updates) should be
straightforward. The beauty of DNS-based IP address verification is
that it provides a reasonable level of security without complex
cryptography. Today's Internet uses this trust model at application
layer.
BACKWARDS COMPATIBILITY. This needs to be considered for legacy
applications, legacy transport protocols, and legacy correspondent
hosts:
- Legacy applications may try to connect to an IP address rather than
to a host name. The API could permit this, just as it permits
upgraded applications to optionally select a specific IP address.
- Legacy transport protocols cannot operate on host names. They could
instead be represented with 128-bit representations of host names.
The 128-bit representation must be (a) globally unique, at least
statistically, and (b) provably bound to the host name. We can
borrow a method from the Host Identity Protocol for this:
Generating a 128-bit representation of an arbitrary-length "name"
by hashing it. Note that, conceptually, we are not creating a new
namespace here. The 128 bit hash output are only another form of
representing, with fixed length, an identifier of arbitrary
length.
- Legacy correspondent hosts can communicate with upgraded hosts since
they can use the IP address of an upgraded host in transport
protocols and appliations. The new stack architecture of the
upgraded host remains transparent to them. However, multi-address
management is then restricted because the legacy correspondent
host does not support IP address updates.
ANALYSIS. The protocol I am describing has the following advantages:
- Like ILNP, it reduces renumbering complexity.
- Like with ILNP, application programming becomes easier.
- Like with ILNP, manageability and user friendliness increase because
only human-readable host names are visible in applications. Even
more: Also transport protocols operate on human-readable host
names now.
- Unlike with ILNP, there is no "uniqueness problem": The host names,
which the protocol uses exclusively for identification purposes,
are guaranteed to be globally unique, and their allocation process
cannot be circumvented due to the allocation hierarchy. The IP
addresses, which the protocol uses exclusively for localization
purposes, are also globally unique. And since they are
topology-dependent, they cannot be arbitrarily spoofed either.
A disadvantage of the protocol I am describing is that it requires all
hosts to be represented in DNS or in rendez-vous servers. Whether
each host must be assigned an individual host name is for further
study. It may be possible to enable hosts to autonomously generate a
host name given the host name components that identify their domain.
Since the host name allocation process is a combination of centralized
and autonomous allocation, such an approach may be feasible.
That's it. Ran, what do you, and what do other folks think about this
protocol?
- Christian
[1] http://tools.ietf.org/html/draft-rja-ilnp-intro
[2] Jaeyeon Jung, Emil Sit, Hari Balakrishnan, Robert Morris. "DNS
Performance and the Effectiveness of Caching," IEEE/ACM Transactions
on Networking, vol. 10, no. 5, October 2002.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg