[Search] [txt|pdf|bibtex] [Tracker] [Email] [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-00.txt                 Glen Zorn
Date: May 1998                                     Microsoft Corporation
                                                                Ping Pan
                                        IBM T. J. Watson Research Center



                      DIAMETER Framework Document
               <draft-calhoun-diameter-framework-00.txt>


Status of this Memo


   This document is an Internet-Draft. Internet-Drafts are working docu-
   ments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a ``work-
   ing draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Abstract


   As the number of new internet services has increased in the past cou-
   ple of years, routers and network access servers (NAS) have had to
   undergo re-engineering to support them.

   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. This allows a single server
   to handle policies for many services.





Calhoun et al.           expires November 1998                  [Page 1]


INTERNET DRAFT                                                  May 1998


Table of Contents

      1.0   Introduction
      1.1   Terminology
      1.2   Specification Language
      2.0   DIAMETER Architecture
      2.1   DIAMETER Base Protocol
      2.1.1 DIAMETER Security
      2.2   Resource Management Extension
      2.3   Accounting Extension
      2.5   QOS Extension
      2.6   Mobile IP Extension
      3.0   Why not LDAP?
      4.0   References
      5.0   Acknowledgements
      6.0   Author's Address
      Appendix A. "Drinks" Policy Extension


1.0  Introduction


   As the number of new internet services has increased in the past cou-
   ple of years, routers and network access servers (NAS) have had to
   undergo re-engineering to support them.

   These new services could often benefit from an Authentication,
   Authorization and Accounting (AAA) protocol to facilitate off-loading
   policy information to an external server.

   An example of such a service is dial-up PPP Internet access. Large
   ISPs cannot bear the administrative burden to configure all of their
   users on each NAS everytime a new device is deployed. In this case
   RADIUS [1] has been used successfully by many such ISPs.

   New services such as Voice over IP, Fax over IP [6], Mobile IP [7]
   and RAP [5] also require similar services in order to be able to
   authenticate, retrieve authorization information, and generate
   accounting records for billing purposes.

   The current trend is for each working groups to define its own policy
   protocol for a specific service, each with their own nuances. This
   requires requires customers to deploy several policy servers, which
   increases the cost of administration and complicates deployment.

   DIAMETER offers a common solution by defining a base protocol that
   defines the header formats, security extensions and requirements as
   well as a small number of mandatory commands and AVPs. A new service



Calhoun et al.           expires November 1998                  [Page 2]


INTERNET DRAFT                                                  May 1998


   can extend DIAMETER by extending the base protocol to support new
   functionality.


1.1  Terminology

   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 DIAME-
      TER 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.


1.2  Specification Language

   In this document, several words are used to signify the requirements
   of the specification [8].  These words are often capitalized.

      MUST       This word, or the adjective "required", means that
                 the definition is an absolute requirement of the
                 specification.

      MUST NOT   This phrase means that the definition is an absolute
                 prohibition of the specification.

      SHOULD     This word, or the adjective "recommended", means
                 that, in some circumstances, valid reasons may exist to
                 ignore this item, but the full implications must be
                 understood and carefully weighed before choosing a
                 different course.  Unexpected results may result
                 otherwise.





Calhoun et al.           expires November 1998                  [Page 3]


INTERNET DRAFT                                                  May 1998


      MAY        This word, or the adjective "optional", means that this
                 item is one of an allowed set of alternatives.  An
                 implementation which does not include this option MUST
                 be prepared to interoperate with another implementation
                 which does include the option.














































Calhoun et al.           expires November 1998                  [Page 4]


INTERNET DRAFT                                                  May 1998


2.0  DIAMETER Architecture

   The Base DIAMETER Architecture consists of three modules, which
   defines a small set of primitives that MUST be implemented by all
   DIAMETER entities.

   Many applications require that the policy server maintain session
   state information. The Resource Management extension provides this
   capability between client and a server as well as between two
   servers.

   Most services using DIAMETER require accounting. The current IETF's
   standard protocol for accounting is SNMP, but experience indicates
   that SNMP often is not the correct protocol for service accounting.
   Many applications and services use RADIUS Accounting [4] as their
   accounting protocol, however RADIUS accounting is not a standard pro-
   tocol and is informational only. A standard accounting protocol is
   required.

   The following diagram provides a representation of the DIAMETER
   Architecture.  As an example, a fictional Policy Extension has been
   added to the architecture. This fictional service is described here
   in order to to illustrate how a service could make use of DIAMETER.

                              +------------+
                              |   Policy   |
                              |            |
                              | Extension  |
                              +------------+
           +------------+          / \           +------------+
           |  Resource  |           |            | Accounting |
           |            |           |            |            |
           | Management |           |            | Extension  |
           +------------+           |            +------------+
                 / \                |                 / \
                  |                 |                  |
                 \ /               \ /                \ /
           +--------------------------------------------------+
           |                                                  |
           |              DIAMETER Base Protocol              |
           |                                                  |
           +--------------------------------------------------+
                 Figure 1: DIAMETER Protocol Architecture

   Design direction for more extensions will be taken from the user (ISP
   and network operations) community.





Calhoun et al.           expires November 1998                  [Page 5]


INTERNET DRAFT                                                  May 1998


2.1  DIAMETER Base Protocol

   The Base Protocol defines a set of primitives and the security model
   used between DIAMETER peers. The following goals motivate the defini-
   tion of the base protocol:

      - Base protocol MUST be lightweight and simple to implement.

      - Allow unsolicited messages from the Policy Server to the client.

      - Feature discovery.

      - Version negotiation.

      - unsupported extension notification instead of silent discard.

      - Efficient encoding of Attributes.

      - The AVP address space MUST be large (i.e. 32 bits)

      - The protocol MUST ensure that 32 bit alignment is observed.

      - Support for vendor specific AVPs and Commands.

      - The protocol MUST support both TCP and UDP.

      - client to server as well as server to server communication (as
      in figure 2) is needed.

      - Authentication and privacy for policy messages.

      - Communication with a DIAMETER entity through an intermediate
      DIAMETER entity.

   Feature Discovery is intended to dramatically reduce the administra-
   tive overhead associated with Policy Server configuration. A DIAMETER
   client can use the a DIAMETER service-type request over SLP [2] to
   locate Policy Servers within the network, and then a set of DIAMETER
   messages to retrieve the supported extensions.

   DIAMETER version negotiation will also reduce the administrative
   overhead in policy server configuration. DIAMETER entities SHOULD
   agree to use the higher DIAMETER protocol version number that they
   commonly support.

   UDP is preferable for policy applications that require "fine tuned"
   retransmission strategies. For applications that require support for
   larger messages and are not as concerned with the retransmission



Calhoun et al.           expires November 1998                  [Page 6]


INTERNET DRAFT                                                  May 1998


   policy, TCP can be used. Each individual extension may specify the
   underlying transport requirements.

   As mentioned above, DIAMETER supports server to server communication
   (see figure 2). Servers can either belong to the same administrative
   domain, or they may belong to different domains. This is commonly
   called "proxying" DIAMETER requests, where a proxy server is used in
   order to reach the end policy server. This functionality is described
   in [3] and has many different applications besides Internet dial-up
   access.

                        +--------+                 +--------+
                        | proxy  |                 | policy |
                        | policy |<--------------->|        |
                        | server |  server-server  | server |
                        +--------+  communication  +--------+
                         /    /|\
                        /      | client-server
                       /       | communication
                     |/_      \|/
             +--------+       +--------+
             | router |       | router |
             +--------+       +--------+
                  Figure 2: Client through a Proxy Server


2.1.1  DIAMETER Security

   The protocol presents three different security methods. The first and
   most obvious method requires no security and can be used with IPSEC.

   The second method is to make use of shared secrets between two enti-
   ties. In this case the protocol could include an HMAC-MD5-96 [8]
   Integrity Check Vector (ICV) within an AVP to provide integrity of
   the message.

   Figure 3 depicts an example of Hop-by-Hop security where Policy
   Server 1 (PS1) and Proxy Server 2 (PS2) share a secret as well as PS2
   and Policy Server 3 (PS3). In this example PS1 sends a message to PS3
   through PS2 with an ICV that is computed using the secret it shares
   with PS2. Upon receipt of the message, PS2 validates the ICV, removes
   it and adds an ICV that is computed using the secret it shares with
   PS3. This is commonly called Hop-by-Hop security since it does not
   provide message integrity between PS1 and PS3.

   The third method, called End-to-End security, allows a DIAMETER
   entity to communicate with a Server through a set of intermediate
   Proxies (see figure 3). In this case the initiator MUST sign the



Calhoun et al.           expires November 1998                  [Page 7]


INTERNET DRAFT                                                  May 1998


   message using public key cryptography since it is the only way for
   the end server to ensure that a proxy has not modified the original
   message.

                +----------+                 +----------+
                |  policy  |<--------------->|  proxy   |
                | server 1 |  server-server  | server 2 |
                +----------+  communication  +----------+
                                                /|\
                                                 | server-server
                                                 | communication
                                                \|/
                                             +----------+
                                             |  policy  |
                                             | server 3 |
                                             +----------+
                   Figure 3: Proxy Server Communication

   If certificates are not statically configured or retrieved through
   some other means (i.e. Certificate Authority), it requires that both
   the client and the server exchange certificates as part of the DIAME-
   TER bootstrap protocol.

   For both the second and the third method the base protocol MUST pro-
   vide replay protection.


2.2  Resource Management Extension

   The Resource Management Extension enables Servers to maintain session
   state information. Many applications require the policy server to
   make decisions not only based on a static policy, but also based on
   network events.

   The Resource Management Extension allows a client and server to
   exchange state information as well as two Servers. Some servers may
   also use a distributed back-end database to share state information.

   The Resource Management extension does not provide a message to
   create a session. This is handled through an extension's authoriza-
   tion response message.

   An example would be when the server authorizes the allocation of
   bandwidth through a successful response message. A response message
   would then create state information within the client and the server
   that can be handled through the resource management extensions at a
   later time, using the session identifier assigned to the session.




Calhoun et al.           expires November 1998                  [Page 8]


INTERNET DRAFT                                                  May 1998


   The following abilities supported by the Resource Management exten-
   sion:

      - Associating resources with clients.

      - Identifying when a session is terminated.

      - Session termination by servers.

      - State update/refresh from the client or other servers.

   In order for the server to maintain accurate state information, it
   MUST be notified when a session is terminated.

   State update and refresh is very important in the case where the
   server has lost state information (i.e. reboot). The server MUST be
   able to request information about a specific session as well as a
   generic request to retrieve all state information. For services that
   require fault tolerance, servers SHOULD share state information.

   The server must be able to request that a client terminate a session.
   This is required in services where policy can pre-empt a low priority
   session.

   Because multiple servers need to share state information, the server
   MUST generate resource tokens. These resource tokens are returned by
   the server at authorization time by the appropriate extension. The
   resource token is sent by the client to the server when it receives a
   request for a state update, and must contain enough information for
   the server to rebuild session state information.

   Furthermore since state information is shared amongst servers it is
   required that each session have a universally unique session identif-
   ier associated with it that is assigned by the client.


2.3  Accounting Extension

   The Accounting Extension defines the messages used for service
   accounting. The accounting extension MUST provide the following func-
   tionality (a separate effort is in place to define the exact require-
   ments of the accounting extension):

      - Negotiable transfer mechanism.

      - Provide general purpose AVPs.

      - Flexible to allows new extensions to use the accounting



Calhoun et al.           expires November 1998                  [Page 9]


INTERNET DRAFT                                                  May 1998


      extension.

      - Scalable to allows millions to users and thousands of sites.

      - Secure accounting data transfer.

   The accounting extension must be able to transfer accounting records
   in an event-driven or batch manner. The selected transfer mechanism
   must be negotiable, and it must be possible to initiate batch
   transfer from either peer.

   The extension MUST Support accounting finite and infinite sessions as
   well indivisible events. Other detailed requirements call for sup-
   porting service name/id, amount and length of attributes.

   It must also be flexible to work in many applications areas. This
   requires extensibility, application defined level of security,
   minimal storage and code size requirements, and the ability to work
   in both real-time and non-real time situations.

   The accounting protocol must be scalable to the size of global
   shared-use networks with millions of users and thousands of sites and
   accounting systems.Transmission, header, and security overhead MUST
   be amortized over several accounting records. Only a per-entity state
   needs to be held by the accounting systems (as opposed to a per-
   session state).

   The accounting protocol must be secure. End-to-end and hop-by-hop
   integrity and confidentiality, data-based access control are all
   needed. Standard Internet security protocols are to be used where
   possible.


3.0  Why not LDAP?

   Many people have asked 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 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 direc-
   tory so outside routers have writeable access. Moreover, having
   1000's of routers constantly write to the directory would cause some



Calhoun et al.           expires November 1998                 [Page 10]


INTERNET DRAFT                                                  May 1998


   additional problems to the Directory Service.

   Finally, LDAP does not provide server initiated messages which is a
   requirement for an AAA protocol.


4.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, Zorn, "Roaming Requirements", draft-ietf-roamops-
       roamreq-08.txt, March 1998.

   [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997.

   [5] Yavatkar, Pendarakis, Guerin, "A Framework for Policy-based
       Admission Control", draft-ietf-rap-framework-00.txt,
       November 1997.

   [6] Masinter, "Terminology and Goals for Internet Fax",
       draft-ietf-fax-goals-02.txt, March 1998.

   [7] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.

   [8] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
       Message Authentication", RFC 2104, January 1997.

   [9] Bradner, "Key words for use in RFCs to Indicate Requirements
       Levels", BCP 14, RFC 2119, March 1997.


5.0  Acknowledgements

   The Authors would like to thanks Bernard Aboba and Jari Arkko for
   their Accounting Requirements contribution.












Calhoun et al.           expires November 1998                 [Page 11]


INTERNET DRAFT                                                  May 1998


6.0  Author's Address

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      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
      IBM T. J. Watson Research Center
      30 Saw Mill River Road,
      Hawthorne, NY 10532

       Phone:  1-914-784-6579
         Fax:  1-914-784-6205
      E-mail:  pan@watson.ibm.com
















Calhoun et al.           expires November 1998                 [Page 12]


INTERNET DRAFT                                                  May 1998


Appendix A.  "Drinks" Policy Extension

   This section is provided as an example only and is intended to pro-
   vide the reader with a better understanding of how DIAMETER could be
   used by services.

   This protocol will provide authentication, authorization and account-
   ing services for bar customers. Each user will be provided with a
   smart card that contains the user's identity and private key.

   When a user enters a bar he may use the automated facility by insert-
   ing his card into a card slot and wait for the appropriate retina
   scan to be performed. The user also selects a drink, and may simply
   hit the "favorite drink" button on the machine.

   The DIAMETER Client then issues the authentication request to the
   Server which authenticates the user. The message MUST contain a
   unique session identifier that will be used while the user is present
   in the bar. The authentication phase consists of a check that the key
   and retina scan matches the user's identity and that the user is of
   age (this is a local decision since each state has different minimum
   age requirements).

   If the user is successfully authenticated the server adds authoriza-
   tion information. Authorization information MAY include the user's
   favorite drinks, whether the user's martini should be shaken or
   stirred, any known allergic reactions to peanuts or other assorted
   snacks, etc.

   Upon receipt of the response, the DIAMETER client dispenses the drink
   to the customer and generates and accounting request to the DIAMETER
   accounting server (which MAY be different from the authentication and
   authorization server).

   Since the Policy server adapts itself according to the user's drink-
   ing habits, it knows how often to send a message to the DIAMETER
   Client to offer another drink to the customer. Since the policy
   server also knows about the user's favorite drinks, it may even "sug-
   gest" a list of drinks to the user periodically. This is achieved
   using the Resource Management extensions defined earlier.

   When the user wishes to order a new drink, the same mechanism occurs
   as defined above, but the Session Identifier is constant. When the
   user leaves the bar, the DIAMETER Client sends a message to the
   server stating that it is terminating a session (based on the Session
   ioni





Calhoun et al.           expires November 1998                 [Page 13]