IRTF E. Lear
Internet Draft R. Droms
Category: Informational Name Space Research Group
December 2002
Expires: June 11, 2003
draft-irtf-nsrg-report-08.txt
What's In A Name:
Thoughts from the NSRG
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
Over the last few years, the character of Internet connectivity has
changed dramatically. A research group in the IRTF has been
chartered to review these changes, and make recommendations on
whether or not remediation within the protocol stack is necessary.
This document reports the outcome of some of the discussions within
the research group.
The key question we will consider is this: does the TCP/IP protocol
suite need an additional level of naming above layer 3 but below
the application layer? In this document, we review the motivation
for an additional naming mechanism, review related work, propose a
strawman "stack name" and discuss additional questions, such as the
structure and use of such names.
Although this document has two authors, the ideas described are
those of many people both within and outside of the IRTF (see the
References and Acknowledgements sections for more details).
However, others within the NSRG hold views that differ from those
presented in this document.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 1]
1 Introduction
The Internet has gone through several metamorphoses, and the use of
IP addresses in the Internet has changed over time. While routing
of IP packets has remained largely unchanged, the use and
assignment of IP addresses has changed considerably.
For many years, end points, the computers intended to send and
receive communications, could be named either by IP address or by a
mnemonic domain name that could be resolved to that address. The
static binding between name and address allowed the interchangeable
use of either to name a host.
However, several new developments have changed the nature of
addressing in the Internet:
* dynamic addressing as provided, for example, through PPP [PPP]
and DHCP [DHCP]
* private network address space and network address translators
(NAT)
* virtual hosts, where one host is assigned multiple IP addresses
* load sharing or load balancing, where one IP address is shared by
multiple hosts, so the services at that address can be provided
by multiple hosts
The overall addressing model on the Internet has shifted to one of
dynamic binding between a host and its address. A host is assigned
an address from place to place, or from time to time, when the host
needs to assert a location in the network topology [BCP5, NAT]. In
addition, a single IP address can now be shared by multiple servers
to represent a single logical end point. The converse is also true
- a single server can represent multiple logical end points, and
not even have to use multiple addresses [HTTP11].
We are not the first to point out the differences between names,
addresses, and routes. Shoch delineated those differences as early
as 1978 in IEN-119 [Shoch]. Saltzer, et al., have also written
about the nature of naming and addressing [Saltzer92, Saltzer84].
Research into the nature of names, addresses and routes can help
provide insight into the current situation, in which the function
of IP addresses is overloaded to serve the function of a location
in the network, an interface, a host name, and a portion of that
which identifies a TCP connection.
Today we ask the question: given the changing nature of the use of
IP addresses for end point identification on the network, is
something more than IP addresses and DNS needed to resolve end
points? What functionality would that something bring to the
table?
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 2]
1.1.1 Security Considerations
In this document we address the notion of identity, which is a key
component of security, and key to privacy.
Communications today are secured through one of several means. For
strongest protocol security, the communication is encrypted and the
ends are identified with verifiable public keys. Several systems
are available today to do this, including SSH[SSH], the IPSEC
mechanisms of ESP[ESP] and IKE[IKE], TLS[TLS], and PGP[PGP].
The absence of a name space that uniquely named a host created
problems in the design of ESP/AH (so-called "IPsec"). ESP/AH
really want to bind security associations to a hostname distinct
from either DNS or IP address, because both the DNS entry and the
IP address can change when in fact the security association could
remain valid. This could occur in the case where a PC moves from
one point in a topology to another. In the absence of a persistent
name in the Internet Architecture, IP addresses are used for the
binding of Security Associations. This is an architectural
shortcoming, not a feature. Among other advantages, a real unique
name space would mean that ESP/AH did not care about the
presence/absence of NAT devices.
At a different level, there is an expectation that the routing
system guides a packet toward the destination end point, as
indicated in the IP destination address. Until a few years ago,
this would not have been an unreasonable assumption. Today
there are exceptions, particularly transparent web proxies and
firewalls.
With some of the currently contemplated changes, the risk of a
transport connection being hijacked changes. Instead of having to
intercept every packet, an attacker may only need to forge a
rebinding message to one end or the other of a connection.
1.2 How Things Have Changed
As mentioned earlier, the nature of addressing in the Internet has
changed. One important change in the Internet addressing model
comes from the use of NAT [TRANSP, INAT, NATCOMP]. When a host
contacts a server to request a web page, it is quite likely that
the remote address and TCP port, as it appears to the web server,
will not be the same as the source address and port used by the web
client. Furthermore, it is likely to be difficult for the web
client to determine the address received by server as the client's
address. And, a host that has a NAT device between it and the
Internet cannot become a server because other clients have no way
to address it.
Another change to the addressing model in the Internet is that
computers are far more mobile than they were just a few years ago.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 3]
When a host moves from one location to another, one's address
changes to reflect the change in its point of attachment to the
Internet. Because TCP bases its transport connection state on IP
addresses, any connections to the old address are lost (but see
below).
One of the largest changes in the character of Internet usage
involves the resources we access and how we access them. Whereas
in the past we intended to access a particular host with a
particular IP address, today we are likely more interested in
accessing a service, such as a news service, or a banking service,
and we are less interested in the host upon which the service sits.
An industry has built up around the notion these so-called content
delivery or overlay networks. The IP address of the web server
matters only in as much as it will serve the necessary web pages.
In particular with secure services, what matters most to the user
is that a particular trusted company has verifiably provided the
service.
This brings us to our question: would a new name space enable new
functionality or return to us old capabilities in the face of NAT,
DHCP, PPP, and other forms of borrowed IP addresses without unduly
compromising the Internet architecture in areas such as transport
protocols and security?
1.3 Why have things changed?
The most important change the Internet has undergone is spectacular
growth. The result of the growth has been shortages in address
space and routing resources.
As the growth of the Internet exploded so did address space
utilization. A combination of measures, including the introduction
of private address space, NATs, and a tightening of policy by
addressing registries reduced the risk of the Internet running out
of allocatable addresses until the 2010 time frame (or later). As
a result, however, the unique identification of an end point and
the universal ability to reach it was lost.
At the same time, Internet routing tables exploded in size. To
reduce routing tables routes, classless routing [BGP4] was
developed and deployed to aggregate routes on bit boundaries,
rather than on old classful boundaries. Next, the IANA
discontinued its policy of allocating addresses directly to end
users and instead allocated them hierarchically to providers,
requiring providers to show sufficient allocation and utilization
to justify further assignments. This retarded for a time the
explosion in routing, but did not eliminate growth. While work
continues in this area, it is important to understand that as of
this writing the aggregation of routes through CIDR is the most
efficient way to route Internet traffic, given its current design
goals.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 4]
There is a natural conflict between the above two policies. If one
allocates addresses in small chunks, more routing entries will
result. Periodically providers will renumber to get larger blocks,
at the inconvenience of all of their customers.
In summary, the Internet has exploded in size, NATs are now widely
present, and the use of mechanisms such as PPP and DHCP are widely
deployed. In addition, services are now as much or more of
interest than are individual hosts. Given all of these changes, is
it possible to add a new name space that will make connectivity
more stable and allow us to establish some new operating
assumptions, such as the ones that these complications broke?
2 Related Work
There exists a large body of work on name spaces and their
bindings. The work we discuss below primarily relates to the
binding of stacks to IP addresses, with an eye toward mobility or
transience.
2.1 Mobile-IP
Mobile-IP addresses the problem of having a stable end point
identifier on mobile hosts. As hosts move through the topology
they update a home agent which acts as an ever-present anchor.
Mobile-IP provides a different solution depending on whether one is
using IPv4 or IPv6 [MobileIP, MobileIPv6]. In IPv4, Mobile-IP is a
tunneling mechanism. In IPv6, mobile hosts make use of destination
options. An end system uses its home address to create transport
connections and communicate with the other end, one or more
correspondent nodes. IPV4 mobile hosts are tunneled through a home
agent and optionally a foreign agent, so that the end system's
address space is found in the routing system without additional
global routing overhead. In IPv4 the home agent is separate from
the other end of a transport connection, and packets take a
triangular route. In IPv6, support of mobility is required, and
the likely non-mobile host, the correspondent node, is aware that
the other end is mobile. Therefore, once the mobile host and
remote host establish communications they can "short circuit" to
remove the home agent. This is key because while the foreign agent
is likely to be near the mobile host, the home agent is unlikely to
be near anybody.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 5]
_______ ________
| |Care-of Address | | foreign agent optionally
|Mobile |--------------------| Remote | forwards packets to mobile
| Host | | Agent | host
|_______| |________|
::Home Address |
:: | home agent encapsulates and passes
:: | packets to the remote agent or
:: ___|____ directly to the mobile node
:: | |
:: | Home |
:: | Agent |\ remote host sends packets
:: |________| \ to home agent
:: \
\\ \
\\ \
\\ \_____________
\\ tunneled transport connection | |
=====================================|Correspondent|
| Node |
|_____________|
Figure 1: Mobile-IPv4
In effect, Mobile-IP turns the mobile node's IP address into a host
identifier, where the "care of" address is the host's current
location. The way Mobile-IP succeeds is that it uses tunneling
within the topology to represent an address at one location when it
is in fact at another. However, a route to the mobile node's
address itself must be available within the topology at all times.
In an IPv4 world this would be untenable because of constraints on
both the addressing system. With IPv6, the addressing pressures
are off, and so each host can have a unique end address. However,
problems remain with the routing system. In addition, there is a
class of devices for which there may be no "home", such as devices
in airplanes, mobile homes, or constant travelers. Additionally,
there is a desire within some of the mobility community to have
"micromobility" mechanisms that enable faster movement than
envisioned by Mobile-IP. The Routing Research Group (rrg) is
currently investigating this area.
Most importantly, mobile devices can't withstand the loss of the
home agent, even if they are still online somewhere. With the home
agent offline, no incoming connections can get to them, and
long-lived communications cannot be re-established. If the
rendezvous point location/identity wasn't overloaded on the home
address (which is, of necessity, a place in the network, and might
go offline, not a distributed database), it might be possible to
work around that for those entities that cared about that failure
mode.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 6]
2.2 Stream Control Transport Protocol (SCTP)
Many of the problems raised have to do with the use of layer 3
information at higher layers, such as the use of a layer 3 address
as the end point identifier for a TCP connection and the use of
layer 3 addresses in the pseudo-header in TCP. SCTP, an
alternative to TCP, uses IP addresses in a more dynamic way as the
identifiers for connection endpoints. TCP transport connection end
points are named by IP addresses, and there are precisely two end
point addresses, one for each end. SCTP allows for multiple
transport addresses per end, nominally for redundancy of
applications that require high availability. However, it is
possible to move a transport connection as a host moves from one
location to another, or as its address changes due to renumbering
(for whatever purpose). Work has progressed within the IETF to
introduce a new capability to SCTP, that allows connection end
points to change the set of IP addresses used for a transport
connection.[ADDIP]
There are three limitations to this idea. For one, it only affects
those hosts that use SCTP, and so long as there exist other
transports that are considered more appropriate for specific tasks,
solving an Internet naming problem within SCTP will be susceptible
to the charge that the solution is not sufficiently general.
The second problem is that as contemplated in the draft the risk of
an attacker hijacking a connection is elevated. This same
problem exists within MobileIP, and may similarly be mitigated by
purpose built keys (see below).
Finally, because SCTP does not have a home agent, SCTP does not
handle what some would argue is a corner case, when two nodes
change their location at the same time.
2.3 Host Identity Payload
Host Identity Payload (HIP) is a new approach to the problem of
naming end points. It inserts an additional "name" between layer 3
and layer 4, thus becoming layer 3.5.[HIP-ARCH] The goal is to
decouple the transport layer from the Internet layer, so that
changes in the Internet layer do not impact the transport, and the
benefit is shared by all mechanisms atop transports that use HIP.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 7]
______________________________________
| |
| Application |
|______________________________________|
| |
| Transport |
|______________________________________| The Host Stack
| |
| HIP or ESP w/ HI as SPI |
|______________________________________|
| |
| IP Header |
|______________________________________|
Figure 2: Host Identity
HIP itself relies on a cryptographic host identity (HI) that is
represented in a Host Identity Tag (HIT) of various forms. One is
a hash of the public key host identity, another is an
administratively assigned value coupled with a smaller hash of the
public key host identity. Host identities can be public or
anonymous, the difference being whether or not they are published
in a directory.
Whereas today one binds the transport to an IP address, HIP
proposes that the transport binds to a host identity tag (HIT).
DNS is used to determine the HI and HIT, or to validate via reverse
lookup an HIT. Further, DNS continues to be used to get an
Internet address.
Whether one should want to decouple the transport layer from the
Internet layer is a controversial question. After all, that
coupling has for many years provided the barest bones of the
security of knowing that the packets that make up the transport
connection are being guided through the network by routing
tables in Internet routers that are owned by people and
organizations whose intent is to get one's packets from source to
destination. If we divorce the transport from the Internet layer,
we introduce another way for an attacker to potentially hijack
connections. HIP attempts to address this through the use of
public key verification.
Additionally, HIP raises an issue regarding other uses for
aggregation of IP addresses. Today, they are not only aggregated
for purposes of reduced routing, but also for reduced
administration. A typical access list used on the Internet will
have some sort of a mask, indicating that a group of hosts from the
same subnet may access some resource. Because the value of a HIT
is a hash in part, only the administratively assigned value can be
aggregated, introducing an allocation limitation and authorization
concerns.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 8]
On the other hand, there is the old computer science saying, any
problem can be fixed by an additional layer of indirection
(arguably what we're talking about). It should be possible to
administratively aggregate on groupings that are made at higher
layers.
An alternative approach would be to aggregate based on DNS names,
rather than HI values. See [HIP-ARCH] for more details.
A key concern with HIP is whether or not it will work in a mobile
world. If the DNS is involved, or if any directory is involved,
will caching semantics eventually limit scalability, or are there
mobility mechanisms that can be employed make use of directories
feasible?
2.4 Purpose Built Keys
Purpose built keys (PBKs) are temporary end point identifiers that
are used to validate a given endpoint during a communication. PBKs
are similar to HIP [PBK]. Rather than attempting to build an
infrastructure to validate the end points, however, PBK's sole
purpose is to ensure that two hosts that originate a communication
may continue that communication with the knowledge that when
finished each end point will be the same end point it was at the
start. Thus, even if one's address changes for whatever reason it
is still possible to validate oneself to the other side of the
communication.
PBKs make no claim as to who the parties actually are. They make
no use of public key infrastructures. PBKs are themselves
ephemeral for the duration of a communication.
PBKs take the form of ad hoc public/private key pairs. When a
node wishes to validate itself to another node it signs a piece of
data with its private key that is validated by the other end with
the public key. The public key itself becomes an end point
identifier.
PBKs might be instantiated in several different places in the
stack; for example, carried in an IPv6 header extension or used by
an application protocol.
2.5 RSIP and MIDCOM
Two related efforts have been made to stitch together name spaces
that conflict. One is RSIP, which allows for the temporary
allocation of address space in one "realm" by a host in another
realm, not unlike the way an address is gotten via DHCP. The
benefit of RSIP is that it allows the end point to know what
address it is assigned, so that it may pass such information along
in the data path, if necessary. The problem with RSIP is that host
routing decisions within the stack are very complex. The host
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 9]
makes decisions based on destination address (a process that a fair
amount of configuration, and lacked certainty as it was based on
potentially non-unique IP addresses). Because RSIP borrows public
addresses it must relinquish them as quickly as possible, or the
point of NAT is negated. In order to make better use of the scarce
public resource, RSIP implementations would need to route not just
on destination address, but on application information as well.
For example, internal hosts would probably not need external
addresses merely to browse the web.
MIDCOM is a similar approach. However, rather than tunneling
traffic, an agreement between an end point and its agent and a
"middle box" such as a NAT or a firewall is made so that the end
point understands what transformation will be made by the middle
box. Where a NAT or a web cache translates from one name
space to another, MIDCOM enables end points to identify that
translation.
MIDCOM is contemplated for use by specific applications, and thus
avoids the stack problems associated with RSIP. However, neither
MIDCOM nor RSIP resolve how to discover such middle boxes. Nor do
they provide a unique way for a host behind a NAT to identify
itself in an enduring way. Finally, they both run into problems
when multiple NATs are introduced in a path.
2.6 GSE or "8+8"
One proposal attempts to ease the conflict between the desire of
end systems to have a fixed name for themselves, and the needs of
the routing systems for address assignments which minimize the
overhead of routing calculations. The clash between these two
desires produces either the inconvenience (for the end systems) of
renumbering, or routing inefficiency and potentially poor address
space utilization as well; the latter caused by the difficulty of
renumbering to allows effective use of address space.
Known as 8+8 or GSE, it would have split the IPv6 address into two
parts: a routing system portion that would be assigned and managed
by service providers that would change based on routing system
requirements, and a locally managed portion that would be assigned
and managed by terminal autonomous systems [GSE]. While each portion
is globally unique, there are in effect two addresses, one to get a
packet to an autonomous system and another to get to the host.
Further, end hosts might not be aware, at least initially, of their
routing portions. It was envisioned that the renumbering of
the routing portion could be done as a matter of signaling, with
little administrative involvement from the end point. Another goal
of GSE was to eliminate additional routing overhead caused by
multihomed end systems, whose information must today be carried
throughout the routing system. By allowing end enterprises to have
multiple global parts for purposes of multihoming, the terminal
ASes would become what are today's last-hop ISPs. There are a
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 10]
number of challenges that GSE would have to overcome. For one, how
does one glue together the provider portion of an address with the
more local part, and how would one accomplish the task securely?
Would doing so eliminate the need or interest in adding other
additional name spaces?
2.7 Universal Resource Names
Universal resource names (URNs) do not provide us a mechanism to
resolve our naming concerns [URN]. Rather, they may provide us the
form of the name to use, and perhaps a framework for resolution.
For instance, an HI may conceivably be represented as a URN. URNs
further the notion of defining a binding and boundaries between the
name of an object and its location.
3. Discussion: Users, Hosts, Entities and Stacks
The original addressing architecture of IP and TCP assumed that
there is a one-to-one relationship between an IP address and a
communicating "entity." By "entity," we mean an identifiable
participant in an Internet communication. Examples of an entity
include a host, a user, a client program or a service. This
one-to-one relationship between IP address and entity was assumed
to exist throughout the duration of a "session" (usually a TCP
connection); that is, all of the IP datagrams exchanged during a
session would share the same endpoint identifiers, and the endpoint
identifiers in those datagrams would not be altered as the
datagrams traversed the Internet.
There is also an assumption that the binding between an entity and
an IP address would vary only infrequently over time. DNS allows
for the binding between a domain name for a host and its IP address
to vary over time, but changes in those bindings may propagate
slowly and do not accommodate frequent changes.
As explained in section 1, the underlying addressing architecture
of the Internet has changed, leading to the need for new naming
mechanisms that function with host mobility, the instantiation of
multiple entities on a single host and the instantiation of a
single entity across multiple hosts, and that can provide security
independent of IP addressing.
When a host moves from one location to another, or when a
host receives a new address for some other reason, the computer
itself has largely remained the same, as has the person using it.
The identity of that computer has not changed. That entity may
well be in communication with other computers and have access
rights to network resources. Indeed, multiple entities may be
represented by a single computer.
Today, a host may represent multiple entities. This happens when a
service provider hosts many web sites on one server. Similarly, a
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 11]
single entity may be represented by multiple hosts. Replicated web
servers are just such an example. We refer to these entities as
"stacks", instantiations of the TCP/IP model, be they across one or
many hosts. We define a stack as one participant or the process on
one side of an end-to-end communication. That participant may move
and may be represented by multiple hosts.
Each instance of a stack has a name, a "stack name". At an
architectural level the Name Space Research Group debated the value
of such names, and their associated costs. We see forms of this
name used in numerous places today. As previously mentioned, SSH
uses public/private key pairs to identify end points. An HTTP
cookie anonymously identifies one end of a communication, in such a
manner that both the transport connection and the IP address of the
other end point may change many times. Stack names are intended to
identify mobile nodes, devices behind NATs, and participants of a
content delivery or overlay network.
When two devices represent a single end point they must share state
in order to keep the other end from becoming confused (to say the
very least). When doing so, such stacks may indeed consist of
multiple processes on each end. One view is that such processes
can theoretically be named independently of the Internet layer,
allowing for sessions to migrate at the behest of applications.
However, it is not possible to standardize migration independent of
applications, who retain state in all manner of places, from
configuration files to memory. Additional names of such processes
serve only to identify those who are authorized somehow to
represent the end point, and do not themselves alleviate effort
required to ensure application consistency.
We use the word "sessions" above, a mechanism that the current IP
stack does not formally provide. If we were to have a session
layer in the classic sense it might sit above the transport layer,
and a session could consist of more than a single transport
connection. If we view the session at below the transport layer,
then transport connections can be bound to an identifier of some
form other than that of the IP address, and transport connections
could persist across IP address changes. It is unlikely, however,
that anything that the transport layer binds to would entirely
obviate the need for sessions above the transport layer.
3.1 Requirements, desirable features and design decisions
Stack names are defined to be a new naming structure integrated
into Internet addressing, which provide a solution to several
problems in the current addressing architecture. We have
identified several requirements for this naming structure. Stack
names will allow continuation of sessions independent of host
mobility or other host renumbering. A stack that spans several
host is identified by a single stack name, and multiple stacks on a
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 12]
single host are unambiguously identified by separate stack names.
Stack names allow authentication of stack identity, authentication
of the origin and contents of messages and privacy for message
contents. Finally, the stack name architecture will interoperate
with existing Internet infrastructure, including existing host
implementations and core routing, for backward compatibility.
Stack names are intended to address as many of the problems in the
current Internet addressesing as possible, including: NAT,
mobility, renumbering, multiple entities on one host and entities
that span multiple hosts. Stack names should be globally unique,
so that state about stack names, such as mapping information, need
not be kept in the network. Stack names should also provide
anonymity, so that users or other entities cannot be easily
identified through a stack name.
These requirements and features lead to several design decisions:
* Internal structure: opaque/structured,
fixed-length/variable-length, universally-unique/random-unique
* Position in stack
* Mapping to mnemonic name (are stack names ever visible to
humans?)
* Relationship between stack names and routing system
3.2. What do stack names look like?
Names may be structured or unstructured. If they are structured,
what encoding do they use, and what is their scope? Is the length
of such a name fixed or variable? Are stack names unique across
the Internet? If so, are they guaranteed unique through some sort
of a registry or are they statistically unique? If it is a
registry, is it centralized or distributed, such as DNS? The
remainder of this section summarizes the discussion within the NSRG
on these questions.
As we have seen, one possibility is that stack names could be
represented as MOBILE-IP home addresses. The benefit of this idea
is that one might well derive a large benefit without having to
incur any additional protocol engineering, at least initially. By
representing stack names in this way the architectural distinction
between stack name and location is somewhat muddled. If the goal
is to separate location and entities, where an IP address
represents location, a Mobile-Ipv6 answer doesn't get us to the
goal.
3.2.1 Uniqueness
This document would not exist were uniqueness not desirable, since
we could live on with the current state of affairs (and we may
yet). Uniqueness offers certainty that a name represents exactly
one object. DNS A records never were intended to have uniqueness.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 13]
and as we've discussed, IP addresses, particularly in a V4
environment, no longer have uniqueness. Uniqueness allows for
people and programs to build operating assumptions the other end of
a communication. TCP was designed with such an assumption.
Being uniquely identified also raises security concerns. What if
you don't want to be uniquely identified by generators of SPAM or
by powerful entities such as governments? Note that we refer to
the uniqueness of the object referenced by the identifier. An
object itself might have multiple names.
3.2.4 Statistical Uniqueness versus Universal Uniqueness
The classic way we have ensured uniqueness of names and addresses
on the Internet has been to have those names and addresses assigned
by central authorities through a distributed tree-structured
database. The overhead for name assignment may be distributed
through delegation of authority. While this mechanism for name
assignment guarantees uniqueness to the level of competence of
those authorities, such delegation introduces overhead, artificial
markets, trademark concerns, and other problems.
Some members of the NSRG are concerned that any new registry for
stack names would bring unwelcome and burdensome administrative
costs to connecting to the Internet, either as a service or a user.
One could envision a very large reverse lookup domain that contains
all HIs, leaving little room for decentralization.
In particular we have seen two problems [el1]crop up with centralized
name spaces. The first problem is that of domain squatting, where
people buy a name simply for its usefulness to others. The second
problem lies with IP addresses, which are allocated and sold by
providers. Those providers may choose to make a "service" out of
making addresses available to customers. When designing a new name
space, one should introduce no artificial scarcity.
One way to avoid a new administrative overhead would be for
individuals to be able to generate statistically unique names.
Statistically unique names can easily be mapped TO, but they are
less easily mapped FROM. This is because it is difficult to
establish trust relationships necessary to make changes to the
mapping. For instance, if a central authority controls the name
space, there must be some sort of authentication and authorization
model in place for the change to be allowed. If such a mechanism
is in place, one has to wonder (a) why the names used for that
infrastructure are not used and therefore (b) why statistically
unique names would be of any advantage.
There was a consensus that if we were to introduce a new name space
it should not be mnemonic in nature. DNS exists for that purpose
today, and while others have recently identified a need to revisit
DNS, that was not the purpose of this effort.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 14]
3.2.2 Mapping
This brings into question several related concerns with naming:
what, if any, mapping mechanisms exist? Should stack names map to
IP addresses, to domain names, or for that matter, to anything?
Do domain names, X.509 distinguished names, or other names map to
stack names? Each is a separate question. A name on its own is of
very limited value. The mappings go to how the name will be used.
Is a stack name just something that sits in a transport control
block on a device? In effect purpose built keys could accomplish
that task.
3.2.3 Anonymity
Related to uniqueness and mapping is anonymity. Is it possible or
even desirable to have anonymous names? That is, should my
computer be able to establish a communication to your computer,
such that you can be assured that you are communicating with the
same entity who used a particular name, without actually knowing
the underlying binding between the name and the object?
3.2.4 Fixed versus variable length names
When the nature of the name is decided one must decide whether the
name should be of fixed length or whether it is variable length.
Traditionally those fields which are found in every packet tend to
be fixed length for performance reasons, as other fields beyond
them are easily indexed. The form the name takes will have some
relevance on this decision. If the name appears along the lines of
an X.509 distinguished name, it must be variable. If the name is
otherwise fixed length and supposed to be universally unique, the
field must allow for large enough numbers to not require a protocol
change anytime soon. Similarly, if the name is statistically
unique, the field must be large enough so that the odds of a
collision are acceptably low so that the protocol needn't change
anytime soon. We leave it to engineers to determine what "anytime
soon" and "acceptably low" are.
A convenient feature of a variable-length name is that it allows
for ease of organizational delegation. If one provides a
hierarchical model such as DNS, one can decentralize authority to
get a new name or to change a name. By the same token, such
structure requires a root authority from which distribution
occurs. So long as the name itself is not a mnemonic, perhaps it
is possible to limit problems such as domain squatting.
Ultimately, if the name is to be other than statistically unique,
there will be some sort of central root service.
3.3 At what layer are stack names represented?
Where are stack names represented? Are they represented in every
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 15]
packet, or are they represented in only those packets that the
underlying use requires? The benefit of not requiring stack names
to appear in every packet is some amount of efficiency. However,
the benefit of having them in every packet is that they can be used
by upper layers such as ESP. In addition, end points would be able
to distinguish flows of packets coming from the same host even if
the IP address changes, or if the remote stack migrates to another
piece of hardware. The PBK approach would alert an end point when
one side knows of such a change, but as we have seen, the IP
address one side sees, the other side may not, without a mechanism
such as MIDCOM or RSIP. HIP and ESP solve this problem by putting
an identifier (either the HIT or SPI) in every packet.
______________________________
| ______ ______ |
| /_____ /| /_____ /| |
| | APP |f| | APP |b| |
| |------|o| |------|a| |
| |TRANS |o| |TRANS |r| |
| | PORT |.| | PORT |.| |
| |------|c| |------|c| |
| | IP |o| | IP |o| |
| |______ m| |______ m| |
| | MAC |/ | MAC |/ |
| |______/ |______/ |
| |
| |
|______________________________|
Figure 3: One application: multiple stacks on a single device
If we had a stable Internet layer it might be possible to
represent stack names as IP addresses. Even if a host moved, a
stack name could be represented as a Mobile-IP "home" address. The
PBK proposal suggests that stack names be passed as necessary as
end to end options in IPv6 or simply as options in IPv4.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 16]
__________________ ________________________
| | | |
| _______________| |____________________ |
| /_______________| |___________________ /| |
| | A P P L I| |C A T I O N |f| |
| |----------------| |-------------------|o| |
| | T R A N | | P O R T |o| |
| |----------------| |-------------------|.| |
| | I N T E| |R N E T |c| |
| |----------------| |-------------------|o| |
| | F R A M| | I N G |m| |
| |----------------| |-------------------| / |
| |________________| |___________________|/ |
| | | |
|__________________| |________________________|
Figure 4: Another application: single stack represented by
multiple hosts
If we do not assume a stable Internet layer, then stack names must
appear above it. If we insert a new mechanism between the Internet
and transport layers, all end points that wish to use the mechanism
would need to change.
3.3.1 A few words about transport mechanisms
We may not wish to completely divorce the transport layer from the
Internet layer, as currently implemented. The transport mechanisms
today are largely responsible for congestion control. If one end
point moves it is quite possible that the congestion
characteristics of the links involve will change as well, and it
thus might be desirable for mechanisms such as TCP Slow Start to be
invoked. It is also possible that codecs may no longer be
appropriate for the new path, based on its new characteristics. In
as much as mobile hosts change their locations and bindings with
MOBILE-IP today, this is already an issue.
3.4 Stack names and the routing system
It would seem a certainty that the routing system would want very
little to do with stack names. However, as previously mentioned,
when we break the binding between Internet and transport layers, we
now must take some care to not introduce new security problems,
such that a transport connection cannot be hijacked by another host
that pretends to be authorized on behalf of an end point.
One misguided way to do this would be to enforce that binding in
the routing system by monitoring binding changes. In order for the
routing system to monitor the binding, it realistically must be
done out in the open (i.e., not an encrypted exchange) and the
binding must appear at some standard point, such as an option or at
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 17]
a predictable point in the packet (e.g., something akin to layer
3.5).
In other words, one would have gone all the way around from
attempting to break the binding between transport and Internet
layers to re-establishing the binding through the use of some sort
of authorization mechanism to bind stack names and Internet
addresses.
3.5 Is an architectural change needed?
The question of what level in the stack to solve the problem
eventually raises whether or not we contemplate architectural
changes or engineering enhancements. There can be little dispute
that the topic is architectural in nature. For one, there are now
numerous attempts to solve end point identification problems within
the engineering space. We've already mentioned but a few. The
real question is whether the existing architecture can cover the
space. Here there are two lines of thought. The first is that the
use of mobility mechanisms and MOBILE-IP will cover any perceived
need to provide stack names. Assuming that it can be widely and
securely deployed, MOBILE-IP certainly resolves many host mobility
concerns. However, it remains to be seen if it can address other
problems, such as those introduced by content delivery networks.
The other line of thought is that we should make the architectural
distinction between names, addresses, and routes more explicit
since there is otherwise an overloading of operators. Regardless
of whatever tactical benefit one might gain, the sheer
architectural separation should provide value in and of itself over
time. The risk of this argument is that we will have introduced
complexity without having actually solved any specific problem,
initially.
To resolve the differences between the two schools of thought
requires development of the latter idea to the point where it can
be properly defended, or for that matter, attacked.
4 Conclusions or Questions
The NSRG was not able to come to unanimity as to whether an
architectural change is needed. In order to answer that question,
as just noted in the previous section, the notion of a stack name
should be further developed.
Specific questions that should be answered are the following:
1. How would a stack name improve the overall functionality of the
Internet?
2. What does a stack name look like?
3. What is its lifetime?
4. Where does it live in the stack?
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 18]
5. How is it used on the end points?
6. What administrative infrastructure is needed to support it?
7. If we add an additional layer would it make the address list in
SCTP unnecessary?
8. What additional security benefits would a new naming scheme
offer?
9. What would the resolution mechanisms be, or what
characteristics of a resolution mechanisms would be required?
Of the many existing efforts in this area, what efforts could such
a name help? For instance, would a stack name provide for a more
natural MIDCOM design?
This document raises more questions than answers. Further studies
will hopefully propose valid answers.
5 Further Studies
Various efforts continue independently. One outgrowth is the
possibility of a HIP working group within the IETF. Although this
work might occur within the IETF, it should be noted that there is
a risk to attempting to standardize something about which we yet
have the full benefit of having explored in research.
Work on relieving stress between routing and addressing also
continues within the IETF in the MULTI6 and PTOMAIN working groups.
A separate effort proceeds elsewhere in the research community to
address what the Internet should look like ten years from now.
There-in we suspect that stack names will play a considerably
larger role.
It is possible that work will continue within the IRTF. However,
that work should be conducted by smaller teams until mature
proposals can be debated. Questions of "whether additional name
spaces should be introduced" can only be answered in such a manner.
6 Acknowledgments
This document is a description of a review done by the Name Space
Research Group of the Internet Research Task Force. The members of
that group include: J. Noel Chiappa, Scott Bradner, Henning
Schulzrinne, Brian Carpenter, Rob Austien, Karen Sollins, John
Wroclawski, Steve Bellovin, Steve Crocker, Keith Moore, Steve
Deering, Matt Holdrege, Randy Stewart, Leslie Daigle, John
Ioannidis, John Day, Thomas Narten, Bob Moskowitz, Ran Atkinson,
Gabriel Montenegro, and Lixia Xiang.
Particular thanks go to Noel Chiappa whose notions and continuing
efforts on end points kicked off the stack name discussion. The
definition of an endpoint is largely taken from Noel's unpublished
draft. Thanks also to Ran Atkinson and Bob Moskowitz whose
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 19]
comments can be found (in some cases verbatim) in this document.
The idea of GSE or 8+8 was originally developed by Mike O'Dell.
The documents in which GSE is described are not published as RFCs.
7. Authors' Address
Eliot Lear
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
Phone: +1 408 527 4020
EMail: lear@cisco.com
Ralph Droms
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 497 4733
EMail: rdroms@cisco.com
8. References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March, 1997.
[BCP5] Rekhter, Y. et al, "Address Allocation for Private
Internets", BCP-5 (RFC 1918), February, 1996.
[NAT] Srisuresh, P., Holdrege, M., "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[Shoch] Shoch, J., "Inter-Network Naming, Addressing and Routing",
Proceedings of IEEE Compcon, pp 72-97, Fall, 1978.
[GSE] O'Dell, M., "GSE - an alternate addressing architecture for
IPv6", draft-ietf-ipngwg-gseaddr-00.txt, 1997.
[Saltzer92] Saltzer, J., "On The Naming and Binding of Network
Destinations", RFC 1498, September, 1992 (as republished).
[Saltzer84] Saltzer, J, Reed, D., Clark, D., "End-To-End Arguments
in System Design", ACM Transactions on Computer Systems, Vol. 2,
No. 4, November, 1984.
[TCP] Postel, J., "Transmission Control Protocol", RFC 792,
September, 1981.
[MCAST] Deering, S.E., "Host Extensions for IP multicasting",
RFC 1112, August, 1989.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 20]
[SSH] Ylonen, T., et. al, "SSH Protocol Architecture", Work in
Progress, draft-ietf-secsh-architecture-12.txt, January, 2001.
[ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
(ESP)", RFC 2406, November, 1998.
[IKE] Harkins, D., Carrel, D., "Internet Key Exchange", RFC 2409,
November 1998.
[TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0",
RFC 2246, January, 1999.
[TRANSP] Carpenter, B., "Internet Transparency", RFC 2775,
February, 2000.
[INAT] Hain, T., "Architectural Implications of NAT", RFC 2993,
November, 2000.
[NATCOMP] Holdrege, M., Srisuresh, P., "Protocol Complications
with the IP Network Address Translator", RFC 3027, January, 2001.
[BGP4] Rekhter, Y., Li, T., "Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March, 1995.
[MobileIP] Perkins, C., "IP Mobility Support", RFC 2002,
October, 1996.
[MobileIPv6] Johnson, P., Perkins, C., "Mobility Support in IPv6",
Work in Progress, draft-ietf-mobileip-ipv6-18.txt, June, 2002.
[ADDIP] Stewart, et. al., "SCTP Extensions for Dynamic
Reconfiguration of IP Addresses", Work in Progress,
draft-ietf-tsvwg-addip-sctp-05.txt, May, 2002.
[HIP-ARCH] Moskowitz, B., "Host Identity Payload Architecture",
Work in Progress, draft-moskowitz-hip-arch-02.txt, February, 2001.
[PBK] Bradner, S., Mankin, A., Schiller, J., "A framework for
Purpose Build Keys (PBK)", Work in Progress,
draft-bradner-pbk-frame-01.txt, July, 2002.
[URN] Sollins, K., "Architectural Principles of Universal Resource
Name Resolution", RFC 2276, January, 1998.
[ESMTP] Klensin, J. (Ed), "Simple Mail Transfer Protocol",
RFC 2821, April, 2001.
9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 21]
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF
Executive Director.
10. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."
11. Expiration Date
This memo is filed as <draft-irtf-nsrg-report-08.txt>, and expires
June 11, 2003.
Lear, Droms draft-irtf-nsrg-report-08.txt [Page 22]
