IRTF                                                        E. Lear
Internet Draft                            Name Space Research Group
Category: Informational
January 2001
Expires: July 15, 2002


                    draft-irtf-nsrg-report-01.txt
                          What's In A Name:
              Report from the Name Space Research Group

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 end to end 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 discusses the outcome of those discussions.  The key
   question we will consider is this: does the stack need an
   additional level of naming above layer 3 but below the application
** layer?

++ Although this document has a single author, the ideas
++ described are those of many people both within and outside of the
++ IRTF (see the References and Acknowledgements sections for more
++ details).

1  Introduction

   The Internet has gone through several metamorphoses, and how one
   gets around on the Internet has changed over time.  Even though the
   IP packet has remained largely unchanged, the routing of that

Lear                  draft-irtf-nsrg-report-01.txt            [Page 1]


   packet has changed considerably.  For many years, addressing of end
   points was a somewhat trivial matter.  One could name end points
   either by IP address or by the mnemonic pointing to that address- a
   domain name.  The difference between name and address seemed
   unimportant.  However, with the advent of PPP[PPP] and DHCP[DHCP],
   private network address space and network address translators

   (NAT),  the addressing  model on  the  Internet has  become one  of
   transients.  One borrows  an address from place to  place, or from
   time to  time, when one needs  to assert a location  in the network
   topology.[BCP5,NAT]

   We are not the first to point out the differences between names,
   addresses, and routes.  That was done as early as 1978 in
   IEN-119[Shoch].  The argument has been carried forth in a
   discussion of routing and addressing in numerous academic
   discussions, including [Saltzer92] and [Saltzer84].  However, we
   are now faced with some logical outcomes earlier authors may well
   have predicted.

   Today we ask the question: given the ephemeral nature of IP
   addresses, is something more than IP addresses and DNS needed to
   resolve end points?  What functionality would that something bring
   to the table?

1.1  How Endpoints Communicate Today

   While attempting not to burden the reader with a long review of how
   IP works, we must consider the process of communication between end
   points on the Internet in order to address the question we pose.

   We consider three forms of communication:

   Unicast Connection Oriented

   A good example is classic TCP.  In order for two ends to establish
   a connection, one end resolves the address of the other, usually by
   DNS lookup, and then the two exchange SYNs and ACKs, thereby
   exchanging state.[TCP] A TCP connection may last for a brief
   fraction of a second, or it may last for days.

   We also consider connection oriented UDP services, such as SIP or
   H.323.  Again, state is exchanged, this time in an application
   specific way.

   Multicast

   Because multicast is a one-to-many method of communication it is
   for the most part connectionless, albeit not necessarily stateless.
   When a host is to receive a multicast it declares its interest in
   the communication via IGMP [MCAST] and the routing system then
   arranges for that host to receive messages to a particular address.

Lear                  draft-irtf-nsrg-report-01.txt            [Page 2]


   Although most of our discussions will focus on unicast, we are
   mindful of the impact any changes made may have on multicast.

   Anycast

   Finally, a form of communication that has of late become useful:
   anycast.  An anycast request is served the "nearest" computer
   participating in that anycast service, for some value of "near".
   Examples of anycast mechanisms include use of multiple DNS servers
   answering on a single IP address.  Modern anycast service requires
   that either the requests consist of a single packet exchange or
   that those endpoints sharing the name or address closely coordinate
   so as not to break routing or other semantics.

1.1.1  Security Considerations

   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], and TLS[TLS].

   The absence of a namespace 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 would 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
   namespace would mean that ESP/AH did not care about the
   presence/absence of NAT/PAT 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
   hijacking a connection changes from that of a continuous intercept
   to the potential of a redirection through some form of spoofed
   rebinding.

1.2  How Things Have Changed

   As mentioned earlier, the nature of communications has changed.
   When one transfers a web page to one's system it is quite likely
   that the remote address and TCP port, as it appears to the web

Lear                  draft-irtf-nsrg-report-01.txt            [Page 3]


   server, will not bear much relation to what the client browsing
   host stated.  Furthermore, without great difficulty the client
   cannot determine the address it is in fact using when speaking to a
   server.  And indeed it itself cannot become a server because
   another end has no way to address it.  This is the essence of NAT.
   All the perils of NAT have been well documented by
   others.[TRANSP,INAT]

   In addition, computers are far more mobile than they were just a
   few years ago.  When one moves from one location to another, one's
   address changes to reflect one's change in topology.  Because TCP
   bases its transport connection state on IP addresses, any
   connections to the old address are lost (but see below).

   This brings us to our question: what if we interpose an additional
   layer with an additional name?  Would it be possible to do that
   which cannot be done with NAT?  What impact would this have on
   mobility?  To answer these questions, we ask an additional
   question: does wide adoption of IP version 6 restore the same
   functionality without requiring an additional layer of indirection?

1.3  Strains

   There are two resource strains we must now mention.  The first
   strain is on the addressing system.  As the growth of the Internet
   exploded so did address 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.

   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.  Work continues in this area.

   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.

2  Related Work

   Although the problem has been brewing for a few years, so have
   several solutions.  None of these solutions is perfect or complete,
   but each addresses some subset of the problem.  The first is
   MOBILE-IP.

Lear                  draft-irtf-nsrg-report-01.txt            [Page 4]


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 each packet is
   encapsulated in a mobility packet.  An end system uses its home
   address to create transport connections.  In addition it is routed
   via a home agent and a remote agent, so that the end system's
   address space is found in the routing system.  In IPv4 the home
   agent is separate from the other end of a transport connection, and
   packets take a triangular route.  In IPv6, Mobile-IP is required.
   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 remote agent is likely to be near the
   mobile host, the home agent is unlikely to be near anybody.

     _______                      ________
    |       |Care-of Address     |        | remote 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

   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 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
   and routing systems.  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".

Lear                  draft-irtf-nsrg-report-01.txt            [Page 5]


2.2  Session 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 pseudo-header in TCP.
   A protocol that is considered an alternative to TCP has certain
   potential benefits in the area of names and addresses. 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, there may be a limited ability 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).

   There are some limitations to this idea.  For one, it only affects
   those hosts that use SCTP.  For another, there is no mechanism to
   add transport end points to an SCTP connection dynamically today.
   Finally, even if one could, one would need to communicate that
   change of binding somehow to the other end, a problem not
   contemplated by the SCTP authors.

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.  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.

             ______________________________________
            |                                      |
            |            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) which 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

Lear                  draft-irtf-nsrg-report-01.txt            [Page 6]


   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 following natural routing, as guided 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.

   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 problem similar to those of
   addresses.

   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 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

Lear                  draft-irtf-nsrg-report-01.txt            [Page 7]


   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 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.

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 contemplated
   implementations required tunneling of some form, making host
   routing decisions highly complex.  For instance, if an HTTP
   connection was to be made, should RSIP be used or not?

   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.  Thus, 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.

2.6  GSE or "8+8"

   One proposal attempts to ease the conflict between end system
   inconvenience of renumbering and address space and routing space
   efficiency.  Known as 8+8 or GSE, it would have split the IPv6
   address into two parts: a globally managed portion that would be
   assigned and managed by service service providers, and a locally
   managed portion that would be assigned and managed by terminal
   autonomous systems.  Further, end hosts would not be aware, at
   least initially, of their global portions.  It was thus envisioned
   that the renumbering of the global portion could be done as a
   matter of signaling, with little administrative involvement from
   the enterprise.  Another goal of GSE was to eliminate additional
   routing overhead caused by multihomed enterprises, 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

Lear                  draft-irtf-nsrg-report-01.txt            [Page 8]


   today's last-hop ISPs.

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: Hosts and Stacks

++ When one's computer moves from one location to another, or when a
++ host receives a new address for whatever 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 other computers and have access rights to
++ network resources.  Indeed multiple entities may be represented by
++ a single computer.

   Until recently it was generally assumed that a host identified
   itself by an IP address or a group of IP addresses.  With the
   exception of such mechanisms as MX records [ESMTP], one connected
   to an IP address, assuming there to be an 1:1 relationship between
   IP address and host.  This assumption is no longer valid for
   reasons previously discussed.

   Today, a host may represent multiple entities.  This happens when a
   service provider hosts a web site.  Similarly, a 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 or end point as one participant 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.

   We thus are left with several questions as to the nature of stack
   names.

3.1.  What do stack names look like?

   Names may be structured or unstructured.  If they are structured,

Lear                  draft-irtf-nsrg-report-01.txt            [Page 9]


   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?

   There is no universal view on many of these questions.  For one
   thing, many are concerned that any new registry 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 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
++ problems lies with IP addresses, which are allocated buy providers.
++ Those providers may choose to make a "service" out of making
++ addresses available to customers.  Where at all possible, when
++ designing a new name space, one should introduce no artificial
++ scarcity.

   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.  On the other
   hand, by representing stack names thusly the architectural
   distinction between stack name and location is somewhat muddled.
   On the one hand, a mobile IP address bears no relation to its
   actual place in the network topology.  Further, any stack name
   proposal could be implemented incrementally by those who wish to
   take advantage of it.  On the other hand, the use of a mobile IP
   address defines the size and structure of stack names, limiting
   their potential.

++ 3.1.1 Uniqueness
++
++ Uniqueness offers certainty that a name represents exactly one
++ object.  DNS A records never were intended to have such uniqueness,
++ and as we've discussed, IP addresses, particularly in a V4
++ environment, no longer have uniqueness.  By providing uniqueness
++ people and programs may build operating assumptions.  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?
++
++ 3.1.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

Lear                  draft-irtf-nsrg-report-01.txt            [Page 10]


++ 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.1.3  Anonymity
++
++ Related to uniqueness 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?  A good example of
++ anonymity exists in the Uniform Commercial Code of U.S. law in the
++ form of agency law.  Do we need such an analog for networking?
++
++ 3.1.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.  While this guarantees uniqueness to the
++ level of competence of those authorities, as we have discussed,
++ such delegation introduces overhead and other problems.  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.  [more needed here].

   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.

3.2  At what layer are stack names represented?

   Where are stack names represented?  Are they represented in every
   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.

Lear                  draft-irtf-nsrg-report-01.txt            [Page 11]


           ______________________________
          |   ______          ______     |
          |  /_____ /|       /_____ /|   |
          | | 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.

            __________________   ________________________
           |                  | |                        |
           |   _______________| |____________________    |
           |  /_______________| |___________________ /|  |
           | |       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.2.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

Lear                  draft-irtf-nsrg-report-01.txt            [Page 12]


++ today are 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 MobileIPv4 today,
++ this is already an issue.

3.3  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
   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.4  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

Lear                  draft-irtf-nsrg-report-01.txt            [Page 13]


   architectural separation should provide value in and of itself over
   time.  The risk of this argument is that we will having 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

   The NSRG was not able to come to consensus 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.  Where does it live in the stack?
   4.  How is it used on the end points?
   5.  What administrative infrastructure is needed to support it?

   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 HIP
   working group within the IETF.  Although this work occurs in 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 to 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.

Lear                  draft-irtf-nsrg-report-01.txt            [Page 14]


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 Holdredge, 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
** comments can be found (in some cases verbatim) in this document.

7. Author's Address

   Eliot Lear
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA 95134
   Phone: +1 408 527 4020
   EMail: lear@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, 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.

   [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                  draft-irtf-nsrg-report-01.txt            [Page 15]


   [SSH] Ylonen, T., et. al, "SSH Protocol Architecture", Work in
   Progress, draft-ietf-secsh-architecture-09.txt, July, 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.

   [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-14.txt, July, 2001.

   [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-00.txt, February, 2001.

   [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
   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

Lear                  draft-irtf-nsrg-report-01.txt            [Page 16]


   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 (2000).  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-01.txt>, and expires
   July 15, 2002.




Lear                  draft-irtf-nsrg-report-01.txt            [Page 17]