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.
