IRTF E. Lear Internet Draft Name Space Research Group Category: Informational May 22 2002 Expires: November 22, 2002 draft-irtf-nsrg-report-04.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 [XXX 5] 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 some of those discussions. [XXX 7] 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? While we do not conclude an answer at this point, we flush out the question a bit more, talk about existing work, and discuss additional questions, such as the structure and use of such names. 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). However, others within the NSRG hold views that differ from those presented in this document. [XXX Ran/Keith/Brian] 1 Introduction Lear draft-irtf-nsrg-report-04.txt [Page 1] 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 packet has changed considerably. For many years, addressing of end points was a somewhat trivial matter. One could name end points, the computers intended to send and receive communications, 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 overall 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] 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. That was done as early as 1978 in IEN-119[Shoch]. The argument has been sharpened and carried forth in a number of discussions, including [Saltzer92] and [Saltzer84]. However, we are now faced with some logical outcomes earlier authors may well have predicted. In short, today 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.[XXX 13] Today we ask the question: given the changing nature of end points 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? 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 Lear draft-irtf-nsrg-report-04.txt [Page 2] specific way. Multicast Unicast communications are by-and-large connection-oriented, meaning that there is an explicit beginning, middle, and end of a two way communication, involving multiple exchanges. 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. 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 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 Lear draft-irtf-nsrg-report-04.txt [Page 3] 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 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. The perils of NAT have been well documented by others. [TRANSP, INAT,NATCOMP][XXX 18,MATT] 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). 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. [XXX 10] 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 mobility? [XXX 21] 1.3 Stresses 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. Lear draft-irtf-nsrg-report-04.txt [Page 4] 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. As a result, however, the unique identification of an end point and the universal ability to reach it was lost. [XXX 22] 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. 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? [XXX 23] 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. The first mechanism is Mobile-IP. 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 end host options. An end system uses its home address to create transport connections and communicate with the other end, one or more Lear draft-irtf-nsrg-report-04.txt [Page 5] 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. _______ ________ | |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 Lear draft-irtf-nsrg-report-04.txt [Page 6] 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. 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 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, 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 two 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). 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 draft-irtf-nsrg-report-04.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 draft-irtf-nsrg-report-04.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 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 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 is that host routing decisions within the stack are very complex. The host 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 Lear draft-irtf-nsrg-report-04.txt [Page 9] 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 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 Lear draft-irtf-nsrg-report-04.txt [Page 10] 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: 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 operating assumption no longer holds, for reasons previously discussed. Today, a host may represent multiple entities. This happens when a service provider hosts many web sites on one server. 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 or the process on one side of an end-to-end communication. That participant may move, and may be represented by multiple hosts. 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. Such an addition may be useful enough, however, to identify mobile nodes, devices behind NATs, and participants of a content delivery Lear draft-irtf-nsrg-report-04.txt [Page 11] or overlay network. 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. 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 now 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, 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 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. 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 Lear draft-irtf-nsrg-report-04.txt [Page 12] 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. A difficulty worthy of further debate is whether such incremental approaches actually help us in the long run. Still, the larger the leap, the less the likelihood of deployment success. 3.1.1 Uniqueness This document would not exist were uniqueness not desirable, since we could live on in 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. 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 name. An object itself might have multiple names. 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 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 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.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 through a distributed tree-structured database by central authorities. While this guarantees uniqueness to the level of competence of those authorities, such delegation introduces overhead, artificial markets, trademark concerns, and other Lear draft-irtf-nsrg-report-04.txt [Page 13] 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. 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. 3.1.5 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 pneumonic, 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.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 Lear draft-irtf-nsrg-report-04.txt [Page 14] 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. __________________ ________________________ | | | | | _______________| |____________________ | | /_______________| |___________________ /| | | | 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 Lear draft-irtf-nsrg-report-04.txt [Page 15] 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 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 MOBILE-IP 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 Lear draft-irtf-nsrg-report-04.txt [Page 16] 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. 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? 6. If we add an additional layer would it make the address list in SCTP unnecessary? 7. What additional security benefits would a new naming scheme offer? 8. 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 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 Lear draft-irtf-nsrg-report-04.txt [Page 17] 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 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. 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. Lear draft-irtf-nsrg-report-04.txt [Page 18] [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. [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. [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-14.txt, July, 2001. Lear draft-irtf-nsrg-report-04.txt [Page 19] [ADDIP] Stewart, et. al., "SCTP Extensions for Dynamic Reconfiguration of IP Addresses", Work in Progress, draft-ietf-tsvwg-addip-sctp-03.txt, November, 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 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 Lear draft-irtf-nsrg-report-04.txt [Page 20] 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 , and expires November 21, 2002. Lear draft-irtf-nsrg-report-04.txt [Page 22]