IRTF E. Lear Internet Draft Name Space Research Group Category: Informational December 2001 Expires: June 18, 2002 draft-irtf-nsrg-report-00.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? 1 Introduction The Internet has gone through several metaporphoses, 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 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 Lear draft-irtf-nsrg-report-00.txt [Page 1] (NAT), the addressing model on the Internet has become one of transcients. 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. 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 Lear draft-irtf-nsrg-report-00.txt [Page 2] 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 persistant 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 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. Lear draft-irtf-nsrg-report-00.txt [Page 3] All the perils of NAT have been well documented by others[TRANSP]. 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 addressses 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. 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. Lear draft-irtf-nsrg-report-00.txt [Page 4] 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". 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 Lear draft-irtf-nsrg-report-00.txt [Page 5] 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 adminsitratively 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). Lear draft-irtf-nsrg-report-00.txt [Page 6] 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 data with its private key that is validated by the other end with the public key. The the public key itself becomes an end point identifier. Lear draft-irtf-nsrg-report-00.txt [Page 7] 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. 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 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 Lear draft-irtf-nsrg-report-00.txt [Page 8] 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 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. 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, 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. 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 Lear draft-irtf-nsrg-report-00.txt [Page 9] 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. 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. ______________________________ | ______ ______ | | /_____ /| /_____ /| | | | 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 Lear draft-irtf-nsrg-report-00.txt [Page 10] 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. Lear draft-irtf-nsrg-report-00.txt [Page 10] 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 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. Lear draft-irtf-nsrg-report-00.txt [Page 11] 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. 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 Lear draft-irtf-nsrg-report-00.txt [Page 12] 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, and 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., "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [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. [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. Lear draft-irtf-nsrg-report-00.txt [Page 13] [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January, 1999. [TRANSP] Carpenter, B., "Internet Transparency", RFC 2775, February, 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.