One document matched: draft-calhoun-diameter-framework-03.txt
Differences from draft-calhoun-diameter-framework-02.txt
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-framework-03.txt Glen Zorn
Date: October 1999 Microsoft Corporation
Ping Pan
Bell Labs
Haseeb Akhtar
Nortel Networks
DIAMETER Framework Document
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.
This document is an individual contribution for consideration by the
AAA Working Group of the Internet Engineering Task Force. Comments
should be submitted to the diameter@ipass.com mailing list.
Distribution of this memo is unlimited.
Abstract
As the number of new internet services has increased in the past
couple of years, routers and network access servers (NAS) have had to
undergo re-engineering to support them.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 1]
INTERNET DRAFT October 1999
These new services could often benefit from an Authentication,
Authorization and Accounting (AAA) protocol to facilitate off-loading
policy information to an external server.
The DIAMETER protocol defines a policy protocol used by clients to
perform Policy, AAA and Resource Control for Internet Access
technologies such as PPP and Mobile-IP
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 2]
INTERNET DRAFT October 1999
Table of Contents
1.0 Introduction
1.1 Copyright Statement
1.2 Requirements language
1.3 Terminology
2.0 Problems to be addressed
3.0 DIAMETER Architecture
3.1 DIAMETER Base Protocol
3.1.1 Proxy Support
3.1.2 Broker Support
3.2 End-to-End Security Extension
3.3 Mobile-IP Extension
3.4 PPP (ROAMOPS) Extension
3.5 Accounting Extension
3.6 DIAMETER Command Naming Conventions
3.6.1 Request/Response
3.6.2 Query/Response
3.6.3 Indication
4.0 Why not LDAP?
5.0 References
6.0 Acknowledgements
7.0 Author's Address
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 3]
INTERNET DRAFT October 1999
1.0 Introduction
Historically, the RADIUS protocol has been used to provide AAA
services for dial-up PPP [17] and terminal server access. Over time,
routers and network access servers (NAS) have increased in complexity
and density, making the RADIUS protocol increasingly unsuitable for
use in such networks.
The Roaming Operations Working Group (ROAMOPS) has published a set of
specifications [19, 20, 21] that define how a PPP user can gain
access to the Internet without having to dial into his/her home
service provider's dial equipment. This is achieved by allowing
service providers to cross-authenticate their users. Effectively, a
user can dial into any service provider's point of presence (POP)
that has a roaming agreement with his/her home Internet service
provider (ISP), the benefit being that the user does not have to
incur a long distance charge while traveling, which can sometimes be
quite expensive.
Given the number of ISPs today, ROAMOPS realized that requiring each
ISP to set up roaming agreements with all other ISPs did not scale.
Therefore, the working group defined a "broker", which acts as an
intermediate server, whose sole purpose is to set up these roaming
agreements. A collection of ISPs and a broker is called a "roaming
consortium". There are many such brokers in existence today; many
also provide settlement services for member ISPs.
The Mobile-IP Working Group has recently changed its focus to cross-
domain mobility, which is a requirement for cellular carriers wishing
to deploy IETF-based mobility protocols. The current cellular
carriers requirements [22, 23] are very similar to the ROAMOPS model,
with the exception that the access protocol is Mobile-IP [2] instead
of PPP.
The DIAMETER protocol was not designed from the ground up. Instead,
the basic RADIUS model was retained while fixing the flaws in the
RADIUS protocol itself. DIAMETER does not share a common protocol
data unit (PDU) with RADIUS, but does borrow sufficiently from the
protocol to ease migration.
The basic concept behind DIAMETER is to provide a base protocol that
can be extended in order to provide AAA services to new access
technologies. Currently, the protocol only concerns itself with PPP
access, both in the traditional sense as well as taking into account
the ROAMOPS model, and Mobile-IP.
Although DIAMETER could be used to solve a wider set of AAA problems,
we are currently limiting the scope of the protocol in order to
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 4]
INTERNET DRAFT October 1999
ensure that we do not lose focus. Note that a truly generic AAA
protocol used by many applications might provide functionality not
provided by DIAMETER. Therefore, it is imperative that the designers
of new applications understand their requirements before using
DIAMETER.
1.1 Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
1.2 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [9].
1.3 Terminology
[editor's note: lots of new terminology is needed here]
AAA
Authentication, Authorization and Accounting.
AVP
The DIAMETER protocol consists of a header followed by objects.
Each object is encapsulated in a header known as an Attribute-
Value-Pair.
Commands
The DIAMETER Protocol is a request/response protocol. Each
DIAMETER message includes a Command AVP that is used to identify
the type of request or response.
Integrity Check Vector (ICV)
An Integrity Check Vector is an unforgeable or secure hash of the
packet with a shared secret.
2.0 Problems to be addressed
The RADIUS protocol was designed in the early 1990's as an attempt to
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 5]
INTERNET DRAFT October 1999
solve a scaling problem associated with dial-in and telnet servers.
Over time the networks became more complex (e.g. roaming networks)
and the Network Access Servers (NAS) increased in complexity and
density. These changes combined with a massive deployment of the
protocol uncovered some fundamental issues with the protocol that
needed to be fixed. The DIAMETER protocol was designed as a next
generation RADIUS protocol, designed with roaming and high density
NASes in mind.
This section will describe the documented, and undocumented, RADIUS
problems known today. Further sections will describe how the DIAMETER
protocol addresses each one of these problems. The problems are:
- strict limitation of attribute data.
- inefficient retransmission algorithm.
- Inability to control flow to servers.
- end-to-end message acknowledgement.
- no retransmission procedure.
- Silent discarding of packets.
- No fail-over server support.
- client/server protocol.
- Authentication Replay Attacks.
- Hop-by-Hop security.
- No support for user-specific commands.
- Heavy processing cost.
One of problems that RADIUS suffers from is its inherent limitation
on the length of attribute data. This limitation is imposed by the
fact that the protocol's attribute header only reserves one byte for
the length field. The RADIUS protocol does specify that larger data
can be spanned across multiple attributes, however doing so
introduces a new set of problems. The RADIUS protocol also allows
multiple attributes of the same type to be included within a message.
Therefore, it is difficult for a RADIUS server, or client, to
determine whether multiple identical attributes are in fact multiple
independent attributes, or a single fragmented attribute.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 6]
INTERNET DRAFT October 1999
The RADIUS protocol states that the identifier field, found within
the header, is used to identify retransmissions. This one byte field
imposes a strict limitation on the number of requests that can be
pending at any given time to 255. In the early 1990's, this number
was sufficient, but the increased density of most NASes today make
the protocol nearly nearly unusable. Most NASes today have fixed this
problem by including information in other attributes to bypass this
limitation. However, the RADIUS servers have also had to support this
change in protocol since they must be able to properly identify
retransmissions. The RADIUS protocol also states that the identifier
MUST be changed if any data is changed in a request.
For this reason, most RADIUS servers keep a cache of received RADIUS
request (e.g. all packets received in the last 60 seconds). The
RADIUS servers then attempt to match some attributes within the
received requests with all attributes in all packets in the cache.
This places a very heavy burden on the RADIUS servers, but
unfortunately is the only method of identifying retransmissions given
the fact that the RADIUS protocol does not have any good scheme. This
hack has proved necessary since some NASes have had to change some
information within requests in the retransmission queue (such as
session length).
Given the rather bursty nature of the RADIUS protocol, current
servers have no way of properly managing their receive buffers. This
is in part due to the fact that RADIUS operates over UDP, and does
not include any windowing support. This has been known to cause
large bursts of requests to be directed to a server, which can burden
a server's ability to respond in a timely manner. This problem is
most prevalent in cases where a server becomes unavailable and all
requests must be sent to an alternate server, or when an ingress port
on the NAS becomes available (e.g. T3 port on NAS).
The RADIUS protocol requires that a NAS retransmit a request until a
successful or failed response is received, and does not permit a
RADIUS server to retransmit a response. This is problematic since
there are many times when a server does receive a request, but cannot
respond before the NAS determines that the request must be
retransmitted. This can occur for many reasons, including the fact
that processing a RADIUS request, which includes authentication and
authorization of the user, a database lookup and logging events, can
be lengthy.
Another reason why NASes typically retransmit is when a SERVER
receives a large number of requests, and cannot process all of them
in a timely manner. The side effect here is that if the NAS
retransmits requests to the server, it simply causes further damage
to the busy server. Since the RADIUS server cannot retransmit, some
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 7]
INTERNET DRAFT October 1999
RADIUS servers keep a cache of responses sent in the past 60 seconds
in order to minimize processing should a retransmission be received.
As previously discussed, identifying a retransmission is a very CPU
intensive tasks, but perhaps not quite as intensive as a database
lookup.
The introduction of proxy RADIUS network have made this
acknowledgement scheme even worse, since the end server must respond
in a timely manner. Each intermediate RADIUS server adds additional
latency to proxied requests due to the application processing cost.
This has been known to cause unnecessary retransmission of requests
by NASes, which impose heavy burden on the proxies, and the network.
When a NAS retransmits a request a maximum number of times, it
assumes that the server is no longer available and transmits the
packet to an alternate server. If there are many packets in the
retransmission queue, all other requests are also transmitted to the
new server. Since a burst of requests were sent to the server, the
chances that it can satisfy all requests before the retransmission
period are very small, which causes unnecessary retransmissions.
The RADIUS protocol states that packets that do not contain the
expected information, or packets that have errors are silently
discarded. Silently discarding packets can create a serious problem
since no response is sent to the NAS, which then has to assume that
the server is no longer reachable. Since proxy networks are
transparent to a NAS, should a server in a proxy chain silently
discard a request, it will cause the NAS to assume that the local
(first hop) server is no longer available.
Most NASes today support a large number of RADIUS servers in an
attempt to provide resilience. However, the RADIUS protocol itself
makes this very difficult due to the problems described above. Since
a NAS does not know a priori whether a specific server is available,
when it switches to an alternate server, it must retransmit a packet
a maximum number of times before determining that the server in
question is down, and that the next server in the configuration chain
must be tried. Taking an example of a NAS with 8 servers configured,
if the next 3 servers in the configuration chain were down, it would
take the NAS x number of seconds to reach an available server (where
x is equal to the retransmission interval * the maximum number of
retransmissions * 3), which is most often longer than the clients are
willing to wait.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 8]
INTERNET DRAFT October 1999
Serving ISP Home ISP
+--------+ +--------+
| Primary| | Primary|
+-------+ | Proxy |----------->| Home |
| |----------->| Server | | Server |
|Network| +--------+ +--------+
|Access |
|Server | +--------+ +--------+
| |----------->| 2 nd | | 2 nd |
+-------+ | Proxy |----------->| Home |
| Server | | Server |
+--------+ +--------+
Figure 1: RADIUS Proxy Network
Given that a RADIUS server cannot know a priori whether a downstream
RADIUS server is reachable, and the fact that the NAS must retransmit
any packets, the RADIUS protocol is not well suited to proxy
environments. Since servers are not aware of a peer's reachability,
most RADIUS networks are designed by creating parallel links between
primary and alternate servers (see figure 1). In this example the
serving ISP's primary server communicates with the home ISP's primary
server, while the 2nd servers communicate directly. When the NAS
issues a request to the primary server, the first hop server attempts
to proxy the request to the primary server at the home network. The
NAS will attempt to retransmit the request n number of times, and the
primary server will simply forward the request to the primary server
at the home network.
Should no response be received, the primary server could attempt to
forward the request to the 2nd server at the home network, but since
the NAS is controlling the retransmissions, it may not have the
opportunity to do so. Therefore, the NAS will redirect all requests
to the serving ISP's 2nd server. Given the protocol's limitations,
it requires a large number of RADIUS servers in order to provide
resilient service.
The above problem is further aggravated should the serving ISP
attempt to proxy to two different administrative network's servers.
Take an example where the serving ISP issues two authentication
requests, one for abc.net and another for xyz.com. Let's also assume
that abc.net's primary server is down, while xyz's 2nd server is
down. Should such a problem occur, all requests for abc.net would
cause the NAS to switch to the serving ISP's 2nd server, while all
requests to xyz.net would cause the NAS to switch back to the serving
ISP's primary server. This clearly illustrates that the RADIUS
protocol cannot be reliably used in proxy networks.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 9]
INTERNET DRAFT October 1999
The RADIUS protocol does not allow a server to send unsolicited
messages to the NAS. As network services became more complex, this
limitation has forced manufacturers to break the RADIUS protocol in
this area in order to allow servers to communicate with the client.
This is widely used for accounting purposes, and to allow a server to
inform a NAS that a session should be terminated. Unfortunately, the
lack of a standard method of doing this has caused many non-
interoperable implementations to be deployed.
In today's PPP world, the NAS provides a challenge to the user, which
is then computed by the PPP user to create the challenge response.
This is commonly known as CHAP [26], and is a popular PPP
authentication scheme. Before roaming networks existed, service
providers would own both the NAS and the RADIUS server and this
wasn't considered a problem. However, now that the NAS and the RADIUS
server are owned by two separate administrative domains, the fact
that the non-trusted NAS generates a challenge provides the ability
for authentication replay attacks. A NAS, or any RADIUS server in a
proxy chain, can have access to a valid challenge/response pair,
which can be replayed at a later time.
The EAP protocol [10], which will be supported as part of RADIUS
extensions can solve this problem, but the fact that EAP is not
widely deployed on clients, and that many EAP authentication
transforms cannot be used within RADIUS (due to the limitation on
attribute data size) makes it difficult to use. Furthermore, given
the RADIUS protocol's requirement for end-to-end retransmissions,
since some EAP authentication types involve a higher number of round
trips than what RADIUS currently supports, RADIUS and EAP cannot be
used on networks that exhibit data loss. This is primarily due to the
fact that most EAP (PPP) clients timeout before the authentication
can be completed.
The RADIUS protocol uses hop-by-hop security, which means that every
hop in a RADIUS proxy network adds authentication data that is used
by the next peer in the chain. There does not exist the concept of
end-to-end security, where security is maintained from the requestor
and the responder, even though a request is handled by intermediate
nodes. This has caused opportunities for fraud in RADIUS networks,
since intermediate nodes can easily modify information (e.g.
accounting information), and such events are untraceable.
Although the RADIUS protocol does support vendor-specific attributes,
it does not allow for vendor-specific commands. This has caused
serious inter-operability problems since vendors simply choose
command identifiers at random, which can collide with other
manufacturer's implementation.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 10]
INTERNET DRAFT October 1999
Unlike most newer IETF protocols, the RADIUS protocol does not impose
any alignment requirements, which adds an unnecessary burden on most
processors. All fields within the header and attributes must be
treated as byte aligned characters.
3.0 DIAMETER Architecture
The DIAMETER architecture consists of a base protocol and a set of
protocol extensions (such as end-to-end security, PPP, Mobile-IP and
accounting). Functionality common to all supported services is
implemented in the base protocol, while application-specific
functionality may be provided through the extension mechanism.
The base protocol [18] must be supported for all DIAMETER
applications, and defines the basic PDU format, a few primitives and
the basic security services offered by the protocol. Like RADIUS, the
DIAMETER protocol operates over UDP but it does define a good
retransmission and fail-over strategy that was lacking in RADIUS. The
base protocol also defines a windowing scheme, which allows the AAA
servers to limit the flow of incoming requests. This can then be used
by the AAA clients to distribute the traffic load across multiple
servers. The fail-over strategy and the windowing capabilities allow
clients and servers to detect the reachability state of peers within
the network, allowing for quick transition to back-up servers.
As previously discussed, the ROAMOPS model introduces the AAA broker,
which acts as an intermediate server redirecting requests to user's
home ISPs. ROAMOPS also described a set of attacks that one could
mount if such a network was built using the RADIUS protocol [21]. In
order to provide secure broker services, end-to-end security is
required at the application layer, since messages traverse
application gateways (brokers).
The DIAMETER End-to-End Security Extension defines a set of
extensions to the base protocol that provide end-to-end integrity,
confidentiality and non-repudiation at the Attribute-Value-Pair (AVP)
level. With these extensions, it is possible to secure portions of a
DIAMETER message, while other parts of the message are not secured.
Secured objects are called protected AVPs; non-secured objects are
called unprotected AVPs. Using DIAMETER, brokers can add, delete or
modify unprotected AVPs in a message.
The RADIUS protocol provides dial-up PPP AAA services by providing
three commands and many Attributes. Attributes in RADIUS are
analogous to AVPs in DIAMETER. In order to ease migration from RADIUS
to DIAMETER, the first 256 entries in the DIAMETER AVP space are
reserved for RADIUS compatibility. This allows both protocols to
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 11]
INTERNET DRAFT October 1999
share a common dictionary and policy rules for PPP user profiles.
Recently, the RADIUS protocol adopted support for the Extensible
Authentication Protocol (EAP) [10], but RADIUS' lack of support for
large attributes and its inherent unreliability has made the
integration of the protocols very difficult.
The DIAMETER PPP Extension defines a set of
authentication/authorization commands, which can be used for CHAP,
PAP and EAP. DIAMETER's support for larger AVPs and its
retransmission strategy has made the use of EAP much more palatable,
allowing for end-to-end user authentication, which reduces many of
authentication replay attacks currently documented.
Unlike PPP, Mobile-IP hosts do not have a long-lived "nailed-up"
connection to a PPP server, but rather get service from routers that
provide service in a particular cell. In the Mobile-IP world, the
router is known as a Foreign Agent, while the moving hosts are known
as Mobile Nodes. The mobile node's home network has a host that
forwards all packets destined to the mobile node through the Foreign
Agent. This host is commonly referred to as the Home Agent.
Mobile-IP [7] allows the mobile nodes to move from one cell (subnet)
to another while retaining the same IP address, minimizing the impact
to applications. Although the Mobile-IP protocol could be deployed in
a small network with any AAA services, a larger network suffers from
many scaling issues such as:
- Static mobile node home address
- Static mobile node home agent
- Requirement to pre-configure mobile node profile on home agents
- No inter-domain mobility
Both PPP and Mobile-IP require that usage data be collected for uses
such as capacity planning and for accounting purposes. The current
standard protocol for accounting is SNMP [12], but experience
indicates that SNMP often is not the correct protocol for service
accounting. Today many applications and services use RADIUS
accounting [4] as their accounting protocol, however the RADIUS
accounting protocol is not an IETF standard; in addition, it suffers
from similar scaling and security problems. The DIAMETER accounting
extension [11] is designed to allow accounting information to be sent
across administrative domains (optionally through brokers), and has
been derived from an accounting requirements document [6, 8].
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 12]
INTERNET DRAFT October 1999
+-----------+
| Mobile-IP |
| |
| Extension |
+-----------+
+-----------+ /|\ +------------+
| ROAMOPS | | | Accounting |
| (PPP) | | | |
| Extension | | | Extension |
+-----------+ | +------------+
/|\ | /|\
| | |
\|/ \|/ \|/
+----------------------------------+---------------------+
| | |
| DIAMETER Base Protocol | End-to-End Security |
| | |
+----------------------------------+---------------------+
Figure 2: DIAMETER Protocol Architecture
3.1 DIAMETER Base Protocol
The Base Protocol defines the DIAMETER message format, a set of
primitives and how the messages are transmitted in a secure fashion.
The Base Protocol assumes a peer-to-peer communication model, as
opposed to a client-server model. The following goals motivated the
design of the base protocol:
- lightweight and simple to implement.
- Large AVP space
- Efficient encoding of attributes, similar to RADIUS
- Support for vendor specific AVPs and Commands
- Support for large number of simultaneous pending requests
- Reliable, UDP-based transport
- Well-defined retransmission and fail-over scheme
- Ability to quickly detect unreachable peers
- No silent message discards
- Support of unsolicited messages to "clients"
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 13]
INTERNET DRAFT October 1999
- integrity and confidentiality at the AVP level
- Hop-by-Hop and End-to-End security
- Session-Oriented protocol
- Allow direct communication, bypassing the broker
The DIAMETER base protocol is intended to simply provide a secure
transport for the messages defined in the various application-
specific extensions. It is therefore imperative that the base be
lightweight and simple to implement.
In the DIAMETER protocol, data objects are encapsulated within the
Attribute Value Pair (AVP). An AVP consists of three parts: the
Identifier, Length and Data. A unique AVP Identifier is assigned to
all data objects in order to be able to distinguish the data
contained. The AVP Identifier namespace must be sufficiently large to
ensure that future protocol extensibility is not limited by the size
of the namespace, as in the RADIUS protocol. Furthermore, vendors
wishing to add "proprietary" extensions must be allowed to do so by
using a vendor-specific namespace, managed by IANA.
For many years the question as to whether RADIUS should operate over
UDP or TCP has been under heated discussion. It must be determined
whether the benefits that UDP provides are worth the implementation
complexities. Over time, it has become clear that these benefits are
well worth the cost. The issue with TCP is that an AAA protocol
requires a quick retransmission and fail-over scheme, which TCP
cannot provide. The DIAMETER protocol must be able to control
retransmission strategy, and more importantly when to switch to an
alternate DIAMETER server.
Contrary to RADIUS, the DIAMETER protocol requires that each node in
a proxy chain acknowledge a request, or response, at the "transport"
layer. Since DIAMETER defines a reliable layer over UDP, this is
done through the use of sequence and acknowledgement numbers. This
allows each node in a chain to retransmit unacknowledged packets.
The DIAMETER protocol provides message sequencing within the header,
which can be used to detect retransmissions. This simple
retransmission detection can greatly simplify server implementations,
and allow a given server to support a much larger number of
transactions per second.
The DIAMETER protocol provides windowing, which requires that each
peer advertise it's receive window. This makes it much simpler for a
NAS to send only the number of requests that the next hop DIAMETER
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 14]
INTERNET DRAFT October 1999
server can handle. Clever implementations can then decide to send
requests to an alternate server when a primary server is busy.
When a DIAMETER peer has not acknowledged a specific message, and the
message has been retransmitted some maximum number of times, the peer
is assumed to be no longer reachable, and all pending requests can
then be issued to an alternate server (providing that they fit within
the peer's receive window). The Base Protocol also defines a watchdog
message, which is sent to a peer to detect reachability when no
traffic has been sent for some time.
With the exception of a few security related errors, the DIAMETER
protocol requires that all messages be acknowledged, either with a
successful response or one that contains an error code.
Where the RADIUS protocol is client-server, the DIAMETER protocol is
peer to peer, allowing unsolicited messages to be sent to NASes.
There are many benefits to peer-to-peer AAA protocols. One example is
the on-demand retrieval of accounting data; another, server-initiated
session termination.
The Base DIAMETER protocol provides for hop-by-hop security, similar
to the scheme employed by RADIUS today. However, the DIAMETER
protocol also provides for replay protection through a timestamp
mechanism. This security scheme requires a long lived security
association to be established by peers, or can make use of keying
material negotiated out of band. The Base Protocol also allows the
built-in security measure to be turned off, (i.e., in cases where
IPSec is in use).
The DIAMETER protocol is a session-oriented protocol, meaning that
each authentication/authorization request must belong to a session,
which is identified through a Session Identifier. All subsequent
DIAMETER transactions done on behalf of the session MUST include the
Session Identifier; a termination message exists to end sessions.
Since today's processors work more efficiently when objects are
aligned on a 32-bit boundary, the DIAMETER protocol requires 32-bit
alignment of all headers and the data. This has recently become a
common requirement for many new protocols at the IETF.
3.1.1 Proxy Support
The DIAMETER protocol was designed from the beginning to support
roaming networks. This means that every node in the network is
responsible for it's own retransmissions, and the protocol does allow
each node to know a priori the reachability state of each peer. This
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 15]
INTERNET DRAFT October 1999
allows for a resilient network, and efficient retransmission scheme.
Figure 3 depicts a network where each DIAMETER server can communicate
with all other servers.
Serving ISP Home ISP
+--------+ +--------+
| Primary| | Primary|
+-------+ | Proxy |----------->| Home |
| |----------->| Server |\ / | Server |
|Network| +--------+ \ / +--------+
|Access | X
|Server | +--------+ / \ +--------+
| |----------->| 2 nd |/ \ | 2 nd |
+-------+ | Proxy |----------->| Home |
| Server | | Server |
+--------+ +--------+
Figure 3: DIAMETER Proxy Network
In the network shown in figure 3, should a request, or response be
lost in the network, the last node that handled the lost packet is
responsible for retransmitting it to it's peer. Furthermore, should
connectivity to a peer be lost, it allowed the node to transmit the
packet to an alternate peer. This reduces the number of systems
required, processing overhead of intermediate nodes, decreases the
latency involved in the switch-over and increases reliability.
3.1.2 Broker Support
A broker is a proxy server that provides simple DIAMETER message
"routing" functions. Brokers are generally deployed in order to
reduce the configuration information that would otherwise be
necessary on all servers owned by ISPs within a roaming consortium.
Brokers can provide two separate functions depending upon the
business model.
The first where the broker forwards messages to the proper
destination based on the NAI information (figure 4). In such a
network, when the broker receives a request from a DIAMETER server,
it determines the packet's destination and can optionally perform
some authorization decisions based on local policy.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 16]
INTERNET DRAFT October 1999
+------------------+
| DIAMETER |
| Broker |
+------------------+
/|\ /|\
| |
\|/ \|/
+----------+ +----------+
| abc.net | | xyz.net |
| DIAMETER | | DIAMETER |
| Server | | Server |
+----------+ +----------+
Figure 4: DIAMETER Roaming Consortium
The DIAMETER broker's organization can also provide Certificate
Authority services, by issuing certificates to all DIAMETER servers
within the consortium. This allows the broker and the DIAMETER
servers to communicate in a secure fashion, without the need for
long-lived secrets. Protocols such as IP Security can allow for
short-lived session keys to be generated and periodically refreshed.
The second broker model allows the end DIAMETER servers to directly
communicate (figure 5). In this model the broker simply provides
redirect services, which is aimed at reducing the amount of
configuration that would otherwise be necessary on all end DIAMETER
servers. When a DIAMETER servers sends a request the broker, the
broker returns contact information that is then used by the
requesting server to issue the request directly to the home DIAMETER
server. In order for the end DIAMETER servers to be able to
communicate in a secure fashion, a pre-established security
association is required. This can be in the form of a long-lived
shared secret, which has scaling problems, or via certificates when
the broker's organization provides CA services.
When the broker provides the message forwarding functions, it can
validate that the source and destination DIAMETER servers are in
"good standing", which reduces the processing on the end servers.
This can be done by having the broker check the server's certificates
against a CRL, via an Online Certificate Status Protocols [25], or
through local configuration. The broker can optionally attach the
source server's certificate if it isn't already present in the
message. When a broker receives a request from or destined to a
server that is not in "good standing", an error would be returned to
the requesting server.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 17]
INTERNET DRAFT October 1999
+------------------+ +---------+
| DIAMETER | | CRL DB/ |
| Broker | | OCSP |
+------------------+ +---------+
/|\
Request | Response with
| Result Code =
| Redirect
\|/
+----------+ +----------+
| abc.net |/ \| xyz.net |
| DIAMETER |--------------| DIAMETER |
| Server |\ /| Server |
+----------+ Direct +----------+
Communication
Figure 5: DIAMETER Broker Returning Redirect Indication
The very fact that the DIAMETER servers in the roaming network do not
have to burden themselves with validating certificates against a CRL,
or some other certificate validation infrastructure, is a huge
advantage. In cases of inter-consortium roaming, the brokers involved
can be responsible for validating any certificates involved. Note
that it is also possible for the broker to periodically issue new
certificates to the roaming consortium members out-of-band in order
to eliminate the need to add certificates to each message, decreasing
the message size and the per-packet processing penalty.
When the broker provides redirect services, the broker can return
both the source and the destination server's certificates. The
certificates are encapsulated within a DIAMETER attribute, and
include a timestamp, an expiration time all signed by the broker.
Should the end server's policy be setup such that they will trust the
certificate returned by the broker, they do not have to make any
additional certificate validation checks. However, local policy may
require that the end DIAMETER servers validate periodically.
Note that even though some broker's do allow direct communication,
some will require that all accounting messages be forwarded by the
broker. This is typically required when the broker also provides
settlement services. In such a network, the broker normally requires
some reassurances that the user was in fact authenticated and
authorized by the home DIAMETER server prior to accepting accounting
records. The document [5] defines a method by which the broker can
get such reassurances.
3.2 End-to-End Security Extension
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 18]
INTERNET DRAFT October 1999
The DIAMETER base protocol allows ISP's DIAMETER servers to
communicate securely, using hop-by-hop authentication. Hop-by-hop
authentication means that the requesting server has secure
communication with the broker, and the broker has secure communicate
with the destination server. However, the base protocol does not
provide the ability for the requesting and destination server to
communicate securely through the broker.
The End-to-End Security extension provides for end-to-end integrity,
confidentiality and non-repudiation at the AVP level. This means that
DIAMETER servers can add a Digital Signature over a select set of
AVPs, which provides message integrity. Intermediate nodes, such as
brokers can also add their own digital signature, should there be a
requirement to do so. confidentiality is provided by encrypting AVPs
using the target's private key, while non-repudiation is provided via
the digital signature previously mentioned.
The end-to-end security extension can only be used in networks where
the broker issues roaming certificates to all DIAMETER servers that
form the roaming consortium. In certain cases, the broker can also
act as a settlement agent, similar to the EDI clearing houses [14].
3.3 Mobile-IP Extension
The Mobile-IP protocol is used to manage mobility of an IP host
across IP subnets [7]. Recent activity within the Mobile-IP Working
Group has defined the interaction between Mobile-IP and AAA in order
to provide:
- Better scaling of security associations
- Mobility across administrative domain boundaries
- Dynamic home agent assignment
The Mobile IP protocol [7] works well when all mobile nodes belong to
the same administrative domain. Some of the current work within the
Mobile IP Working Group is to allow Mobile IP to scale across
administrative domains. This work requires modifications to the
existing Mobile IP trust model.
Figure 6 depicts the DIAMETER trust model for Mobile-IP. In this
model each network contains mobile nodes (MN) and a DIAMETER server.
Each mobility device shares a security association (SA) with the
DIAMETER server within its own home network. This means that none of
the mobility devices initially share a security association. The
DIAMETER servers in both administrative domains can either share a
direct security association, or can have a security association with
an intermediate broker.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 19]
INTERNET DRAFT October 1999
Broker AAA
+--------+
| |
|DIAMETER|
/=====| |=====\
// +--------+ \\
Foreign // SA SA \\ Home
AAA // \\ AAA
+--------+ +--------+
| | SA4 | |
|DIAMETER|======================|DIAMETER|
| |(in lieu of broker or)| |
+--------+(in direct comm model)+--------+
|| || ||
|| || ||
SA1|| SA2 || || SA3
|| || ||
|| || ||
+---------+ +---------+ +---------+
| | | | | |
| FA | | MN | | HA |
| | | | | |
+---------+ +---------+ +---------+
Figure 6 - Mobile-IP AAA Trust Model
Figure 7 provides an example of a Mobile-IP network that includes
DIAMETER. In the integrated Mobile-IP/DIAMETER Network, it is assumed
that each mobility agent shares a security association between itself
and its home DIAMETER server. Further, the Home and Foreign DIAMETER
servers both share a security association with the broker's DIAMETER
server. Lastly, it is assumed that each mobile node shares a trust
relationship with its home DIAMETER Server.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 20]
INTERNET DRAFT October 1999
Visited Access Broker Home IP
Provider Network Network Network
+--------+ +--------+ +--------+
| | | | | |
|DIAMETER|------|DIAMETER|------|DIAMETER|
| | | | | |
+--------+ +--------+ +--------+
| |
| |
AAA | | AAA
| |
| |
+---------+ +---------+
| | | |
| FA | | HA |
| | | |
+---------+ +---------+
|
| Visited Access Home Network
| Provider Network -Private Network
Mobile | -Home Provider
IP | -Home ISP
|
+--------+
| Mobile |
| Node |
+--------+
Figure 7 - General Wireless IP Architecture for Mobile-IP AAA
In this example, a Mobile Node appears within a foreign network and
issues a registration to the Foreign Agent. Since the Foreign Agent
does not share any security association with the Home Agent, it sends
a DIAMETER request to its local DIAMETER server, which includes the
authentication information and the Mobile-IP registration request.
The Mobile Node cannot communicate directly with the home DIAMETER
Server for two reasons:
- It does not have access to the network. The registration request
is sent by the Mobile Node to request access to the network.
- The Mobile Node may not have an IP address, and may be requesting
that one be assigned to it by its home provider.
The Foreign DIAMETER Server will determine whether the request can be
satisfied locally through the use of the Network Access Identifier
[3] provided by the Mobile Node. The NAI has the form of user@realm
and the DIAMETER Server uses the realm portion of the NAI to identify
the Mobile Node's home DIAMETER Server. If the Foreign DIAMETER
Server does not share any security association with the Mobile Node's
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 21]
INTERNET DRAFT October 1999
home DIAMETER Server, it may forward the request to its broker. If
the broker has a relationship with the home network, it can forward
the request, otherwise a failure indication is sent back to the
Foreign DIAMETER Server.
When the home DIAMETER Server receives the DIAMETER Request, it
authenticates the user and begins the authorization phase. The
authorization phase includes the generation of:
- Dynamic session keys to be distributed among all mobility agents
- Optional dynamic assignment of a home agent
- Optional dynamic assignment of a home address (note this could be
done by the home agent).
- Optional assignment of QOS parameters for the mobile node [22]
Once authorization is complete, the home DIAMETER Server issues an
unsolicited DIAMETER request to the Home Agent, which includes the
information in the original DIAMETER request as well as the
authorization information generated by the home DIAMETER server. The
Home Agent retrieves the Registration Request from the DIAMETER
request and processes it, then generates a Registration Reply that is
sent back to the home DIAMETER server in a DIAMETER response. The
message is forwarded through the broker back to the Foreign DIAMETER
server, and finally to the Foreign Agent.
The DIAMETER servers maintain session state information based on the
authorization information. If a Mobile Node moves to another Foreign
Agent within the foreign domain, a request to the foreign DIAMETER
server can be done in order to immediately return the keys that were
issued to the previous Foreign Agent. This eliminates an additional
round trip through the internet when micro mobility is involved, and
enables smooth hand-off. In order for the DIAMETER server to be able
to provide the keying information to the new Foreign Agent, they must
have a pre-existing security association.
Note that smooth hand-off is really a mobility function, and it is
not clear that DIAMETER should be involved. However, this example is
provided for completeness.
If the Mobile Node enters a service area owned by a new service
provider, the authentication and authorization request will have to
be sent back to the home DIAMETER server, which will create new
keying information.
3.3.1. Minimized Internet Traversal
Although it would have been possible for the DIAMETER interactions to
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 22]
INTERNET DRAFT October 1999
be performed for basic authentication and authorization, and the
Registration flow to be sent directly to the Home Agent from the
Foreign Agent, one of the key Mobile-IP DIAMETER requirements is to
minimize Internet traversals. Including the Registration Request and
Replies in the DIAMETER messages allows for a single traversal to
authenticate the user, perform authorization and process the
Registration Request. This streamlined approach is required in order
to minimize the latency involved in getting wireless (cellular)
devices access to the network. New registrations should not increase
the connect time more than what the current cellular networks
provide.
3.3.2. Key Distribution
In order to allow the scaling of wireless data access across
administrative domains, it is necessary to minimize the security
associations required. This means that each Foreign Agent does not
share a security association with each Home Agent on the Internet.
The Mobility Agents share a security association with their local
DIAMETER server, which in turn shares a security association with
other DIAMETER servers. Again, the use of brokers (as defined by
ROAMOPS) allows such services to scale by allowing the number of
relationships established by the providers to be reduced.
After a Mobile Node is authenticated, the authorization phase
includes the generation of Sessions Keys. Specifically, three keys
are generated:
- k1 - Key to be shared between the Mobile Node and the Home Agent
- k2 - Key to be shared between the Mobile Node and the Foreign
Agent
- k3 - Key to be shared between the Foreign Agent and the Home
Agent
Each key is encrypted in two separate methods. K1 is encrypted using
SA2 (for the Home Agent), and using SA3 (for the Mobile Node). K2 is
encrypted using SA4 (for the Foreign Agent) and using SA3 (for the
Mobile Node). Lastly, K3 is encrypted using SA1 (for the Foreign
Agent), and using SA2 (for the Home Agent). All of the Security
Associations (SAx) are shown in figure 6. The keys destined for the
foreign and home agent are propagated to the mobility nodes via the
DIAMETER protocol, while the keys destined for the Mobile Node are
sent via the Mobile-IP protocol.
Figure 8 depicts the new security associations used for Mobile-IP
message integrity using the keys derived by the DIAMETER server.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 23]
INTERNET DRAFT October 1999
+--------+ +--------+
| | k3 | |
| FA |======================| HA |
| | | |
+--------+ +--------+
\\ //
\\ k2 k1 //
\\ +--------+ //
\\ | | //
\=====| MN |=====/
| |
+--------+
Figure 8 - Security Association after Key Distribution
Once the session keys have been established and propagated, the
mobility devices can exchange registration information directly
without the need of the DIAMETER infrastructure. However the session
keys have a lifetime, after which the DIAMETER infrastructure must be
used in order to acquire new session keys.
3.4 PPP (ROAMOPS) Extension
The ROAMOPS extension provides authentication and authorization for
PPP users in both intra- and inter-domain networks. The extension
makes use of the attributes defined in the RADIUS protocol to carry
the data objects. This was intended to ease migration of existing
RADIUS servers to DIAMETER since they could share a single dictionary
and user profile. Furthermore, this would reduce the amount of
processing required for an inter-working system that acts as a
RADIUS/DIAMETER bridge.
DIAMETER has native EAP support that works very well, due to the fact
that the known RADIUS problems have been fixed in the base protocol.
Furthermore, DIAMETER takes end-to-end authentication one step
further by providing for end-to-end authentication via PPP's CHAP.
This allows for a more secure authentication infrastructure without
having to replace or modify the installed base of clients.
If end-to-end CHAP is used in bridged DIAMETER/RADIUS environments,
the bridge host is responsible for generating the challenge to the
user.
The remaining authentication and authorization logic found in RADIUS
implementations can then be re-used. The basic changes are the packet
formats and the transmission mechanism as defined in the DIAMETER
base protocol. This section will not detail how RADIUS
authentication and authorization functions given that it is a well
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 24]
INTERNET DRAFT October 1999
known problem space and has been in use for years.
3.5 Accounting Extension
The Accounting extension provides usage collection to both the
Mobile-IP and the PPP (ROAMOPS) extensions. The accounting
requirements specifications [6, 8] define that an accounting protocol
must provide the following functionality:
- Negotiable transfer mechanism.
- Provide general purpose AVPs.
- Flexible to allows new extensions to use the accounting
extension.
- Scalable to allows millions to users and thousands of sites.
- Secure accounting data transfer.
The DIAMETER protocol encodes the actual accounting information using
the Accounting Data Interchange Format (ADIF) [24]. ADIF was intended
to allow a uniform encoding of accounting data to be transferred over
virtually any transport (e.g. DIAMETER, SMTP, HTTP, etc).
The DIAMETER Accounting Extension makes extensive use of tokens.
Tokens are created by the server during the authorization phase. The
token includes information about the session, which is then used by
the accounting server to ensure that the accounting record received
corresponds to a previously authenticated and authorized session. The
replay protection and digital signature embedded within the token is
used to minimize accounting fraud. See [5] for more information.
The DIAMETER Accounting Extension allows accounting information to be
sent in two modes; real-time and batched. Real-time accounting
transfers are useful in environments where timely arrival of the
information is required, such as when debit cards are used. Batched
accounting transfers are useful in environments that do not need up
to the minute accounting records. However, it is possible that in
inter-domain networks, real-time accounting data delivery will be
more popular since the ISPs involved will want to receive some
guarantees of payment prior to providing service.
The DIAMETER protocol is session oriented, and each session typically
has a finite lifetime. Prior to the timeout of a session, a user
typically needs to be re-authentication and/or re-authorized in order
to extend the life of the session. In the Mobile-IP world, this
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 25]
INTERNET DRAFT October 1999
equates to the mobility registration lifetime, while in PPP this
means that the PPP authentication must be re-opened [5]. When a re-
authentication and/or re-authorization occurs, a new token is
generated, which is used in the corresponding accounting message.
The DIAMETER Accounting Extension supports non-repudiation of both
the request, and the corresponding response. In the RADIUS world,
even if non-repudiation was added to the protocol, an accounting
acknowledgement does not include the information being acknowledged,
making it very difficult to prove that the peer really accepted the
request. The DIAMETER protocol requires that a hash of the accounting
record be included in the response, which can optionally be signed
for non-repudiation.
3.6 DIAMETER Command Naming Conventions
The following conventions are proposed for the naming of Diameter
messages. Diameter commands typically start with an object name, and
end with one of the following verbs:
3.6.1 Request/Response
Request is used when the command is asking the peer to do something
for it, for example, set up a session, or reconfigure some
parameters. The Response usually contains either a positive or
negative result code, telling the requester whether or not the
request successfully occurred. Other information can also be returned
in the Response.
For example, AA-Request asks the peer device to authorize and/or
authenticate a user in order to set up a session. The request may
fail, thus the response may be positive or negative.
3.6.2 Query/Response
Query is used when the command is asking for information that it
expects the peer to have. An example would be querying for current
configuration information, or querying for information on resources
or sessions in use. The Response usually contains a positive result
code and the information, or a negative result code with the reason
for not answering the query.
For example, Resource-Query requests the peer device to return
specific information about one or more resources. The answer is
returned in a Resource-Response.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 26]
INTERNET DRAFT October 1999
3.6.3 Indication
Indication is used when the command is giving information on
something that is about to or has already occurred. The peer
receiving the message does not respond to the message, but a
transport level acknowledgement must be done in order to ensure that
the message was reliably delivered.
For example the base draft defines a message that is used to ensure
that a peer is still active. This is achieve with the Device-
Watchdog-Ind message, which is acknowledgement as defined in [18].
4.0 Why not LDAP?
One common question is whether LDAP would provide the functionality
required.
A Server MAY wish to access policies using LDAP, but the use of LDAP
between the client and the server is not possible. The use of LDAP in
this case would require that all routers have read/write access to
the directory. Most customers would not accept this requirements and
it is not efficient.
In the case of roaming, customers would have to open up their
directory so outside routers have writeable access. The security
implications set aside, having 1000's of routers constantly
read/write to the directory would cause some additional problems to
the Directory Service.
Finally, LDAP does not provide server initiated messages which is a
requirement for an AAA protocol.
5.0 References
[1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997
[2] Veizades, Guttman, Perkins, Kaplan, "Service Location
Protocol", RFC-2165, June 1997.
[3] Aboba, Beadles, "The Network Access Identifier", RFC 2486,
January 1999.
[4] Rigney, "RADIUS Accounting", RFC-2139, April 1997.
[5] G. Zorn, P. Calhoun, "Limiting Fraud in Roaming",
draft-ietf-roamops-fraud-limit-00.txt, IETF Work in Progress,
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 27]
INTERNET DRAFT October 1999
May 1999.
[6] B. Aboba, J. Arkko, "Introduction to Accounting
Management", draft-aboba-acct-01.txt, IETF Work in Progress
June 1999.
[7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[8] J. Arkko, "Requirements for Internet-Scale Accounting
Management", draft-arkko-acctreq-00.txt, IETF Work
in Progress, August 1998.
[9] Bradner, "Key words for use in RFCs to Indicate Requirements
Levels", BCP 14, RFC 2119, March 1997.
[10] L. Blunk, J. Vollbrecht, "Extensible Authentication Protocol
(EAP)", RFC 2284, March 1998.
[11] P. Calhoun, P. Patel, G. Zorn, J. Arkko, "DIAMETER
Accounting Extension", draft-calhoun-diameter-accounting-
00.txt, IETF Work in Progress, October 1999.
[12] J. Case, D. Harrington, R. Presuhn, B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol:", RFC 2572, April 1999.
[13] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions",
draft-calhoun-diameter-mobileip-02.txt, IETF Work in
Progress, August 1999.
[14] M. Baum, H. Perritt, "Electronic Contracting, Publishing and
EDI Law", Prentice-Hall, ISBN 0-471-53135-9.
[15] P. Calhoun, C. Perkins "Mobile IP Foreign Agent
Challenge/Response Extension",
draft-ietf-mobileip-challenge-02.txt, IETF Work in progress,
May 1999.
[16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)"
RFC 1409, November 1998.
[17] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
STD 51, July 1994.
[18] P. Calhoun, A. Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-08.txt, IETF Work in Progress,
August 1999.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 28]
INTERNET DRAFT October 1999
[19] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477, January 1999.
[20] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.
[21] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[22] T. Hiller and al, "3G Wireless Data Provider Architecture
Using Mobile IP and AAA", draft-hiller-3gwireless-00.txt,
IETF Work in Progress, March 1999.
[23] E. Gustafsson, A. Jonsson, E. Hubbard, J. Halmkvist,
A. Roos, "Requirements on Mobile IP from a Cellular
Perspective", draft-ietf-mobileip-cellular-requirements-
02.txt, IETF Work in Progress, June 1999.
[24] B. Aboba, D. Lidyard, "The Accounting Data Interchange
Format (ADIF)", draft-roamops-acctng-06.txt, IETF Work
in Progress, August 1999.
[25] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet
Public Key Infrastructure Online Certificate Status
Protocol (OCSP)", RFC 2560, June 1999.
[26] W. Simpson, "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
6.0 Acknowledgements
The Authors would like to thanks Bernard Aboba and Jari Arkko for
their Accounting Requirements contribution. Thanks also goes to Erik
Guttman for some very useful comments in helping make this draft more
readable. The Mobile-IP Extension section was text originally
written by Pat Calhoun for another Internet-Draft, which was
subsequently cleaned up by Dave Spence.
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 29]
INTERNET DRAFT October 1999
7.0 Author's Address
Questions about this memo can be directed to:
Pat R. Calhoun
Sun Laboratories, Network and Security
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: 1-425-703-1559
E-Mail: glennz@microsoft.com
Ping Pan
Bell Laboratories
Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
USA
Phone: 1-732-332-6744
E-mail: pingpan@dnrc.bell-labs.com
Haseeb Akhtar
Wireless Technology Labs
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082-4399
USA
Phone: 1-972-684-8850
E-Mail: haseeb@nortelnetworks.com
Calhoun, Zorn, Pan, Akhtar expires April 2000 [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-22 13:58:08 |