[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09                                 
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:


   The list of Internet-Draft Shadow Directories can be accessed at:


   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.


   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

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]


      Authentication, Authorization and Accounting.


      The DIAMETER protocol consists of a header followed by objects.
      Each object is encapsulated in a header known as an Attribute-


      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

   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    +----------+
          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
                            |        |
                      /=====|        |=====\
                     //     +--------+     \\
           Foreign  // SA                SA \\   Home
             AAA   //                        \\  AAA
           +--------+                      +--------+
           |        |          SA4         |        |
           |        |(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
            +--------+      +--------+      +--------+
            |        |      |        |      |        |
            |        |      |        |      |        |
            +--------+      +--------+      +--------+
                 |                              |
                 |                              |
             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

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
      - k3 - Key to be shared between the Foreign Agent and the Home

   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

   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

   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

      - 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

   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

   [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

       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

       Phone:  1-425-703-1559
      E-Mail:  glennz@microsoft.com

      Ping Pan
      Bell Laboratories
      Lucent Technologies
      101 Crawfords Corner Road
      Holmdel, NJ 07733

       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

       Phone: 1-972-684-8850
      E-Mail: haseeb@nortelnetworks.com

Calhoun, Zorn, Pan, Akhtar expires April 2000                  [Page 30]