[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Microsystems, Inc.
Title: draft-calhoun-diameter-17.txt                     Allan C. Rubens
Date: September 2000                                   Tut Systems, Inc.
                                                           Haseeb Akhtar
                                                         Nortel Networks
                                                            Erik Guttman
                                                  Sun Microsystems, Inc.

                         DIAMETER Base Protocol

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@diameter.org mailing list.

   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 1999.  All Rights Reserved.

Calhoun et al.             expires March 2001                   [Page 1]

INTERNET DRAFT                                            September 2000


   The DIAMETER base protocol is intended to provide a AAA framework for
   Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message
   format, transport, error reporting and security services to be used
   by all DIAMETER extensions and MUST be supported by all DIAMETER

Table of Contents

      1.0  Introduction
            1.1  Requirements language
            1.2  Terminology
      2.0  Protocol Overview
            2.1  Header Format
            2.2  AVP Format
                  2.2.1  AVP Header
                  2.2.2  Optional Header Elements
                  2.2.3  AVP Value Formats
                  2.2.4  DIAMETER Base Protocol AVPs
            2.3  Mandatory AVPs
                  2.3.1  Host-Name AVP
            2.4  Grouping of AVPs
            2.5  State Machine
            2.6  Device-Reboot-Ind (DRI) Command
                  2.6.1  Vendor-Name AVP
                  2.6.2  Firmware-Revision AVP
                  2.6.3  Extension-Id AVP
                  2.6.4  Host-IP-Address AVP
      3.0  "User" Sessions
            3.1  Session-Id AVP
            3.2  Session-Timeout AVP
            3.3  User-Name AVP
            3.4  Session Termination
                  3.4.1  Session-Termination-Ind
                  3.4.2  Session-Termination-Request
                  3.4.3  Session-Termination-Answer
      4.0  Reliable Transport
      5.0  Error Reporting
            5.1  Message-Reject-Ind (MRI) Command
                  5.1.1  Failed-AVP AVP
                  5.1.2  Unrecognized-Command-Code
            5.2  Result-Code AVP
      6.0  DIAMETER Message Routing
            6.1  NAI-Based Message Routing
            6.2  Message Proxying
                  6.2.1  Proxy-State AVP

Calhoun et al.             expires March 2001                   [Page 2]

INTERNET DRAFT                                            September 2000

                  6.2.2  Destination-NAI AVP
            6.3  Message Redirection
                  6.3.1  Redirected-Host AVP
                  6.3.2  Redirect-Host-Port AVP
      7.0  DIAMETER Message Security
            7.1  Hop-by-Hop Security
                  7.1.1  Integrity-Check-Value AVP
                  7.1.2  Encrypted-Payload AVP
             MD5 Payload Hiding
            7.2  Nonce AVP
            7.3  Timestamp AVP
      8.0  IANA Considerations
            8.1  AVP Attributes
            8.2  Command Code AVP Values
            8.3  Extension Identifier Values
            8.4  Result-Code AVP Values
            8.5  Integrity-Check-Value AVP Transform Values
            8.6  AVP Header Bits
      9.0 Open Issues
      10.0 DIAMETER protocol related configurable parameters
      11.0 Security Considerations
      12.0 References
      13.0 Acknowledgements
      14.0 Authors' Addresses
      15.0 Full Copyright Statement

Calhoun et al.             expires March 2001                   [Page 3]

INTERNET DRAFT                                            September 2000

1.0  Introduction

   The DIAMETER protocol allows peers to exchange a variety of messages.
   The base protocol provides the following facilities:

      - Delivery of AVPs (attribute value pairs)
      - Capabilities negotiation, as required in [20]
      - Error notification
      - Extensibility, through addition of new commands and AVPs, as
        required in [21]

   All data delivered by the protocol is in the form of an AVP.  Some of
   these AVP values are used by the DIAMETER protocol itself, while
   others deliver data associated with particular applications which
   employ DIAMETER.  AVPs may be added arbitrarily to DIAMETER messages,
   so long as the required AVPs are included and AVPs which are
   explicitly excluded are not included.  AVPs are used by base DIAMETER
   protocol to support the following required features:

      - If application-level security is required, all messages MUST
        include an Integrity Check Vector (ICV).  If the ICV is present,
        the message MUST also carry a timestamp and a nonce to aid in
        providing replay protection.
      - To carry user authentication information, for the purposes of
        enabling the DIAMETER server to authenticate the user.
      - To allow authorization information to be exchanged for a
        particular user's session between a DIAMETER client and server.
      - To exchange resource usage information, which MAY be used for
        accounting purposes, capacity planning, etc.

   The DIAMETER base protocol provides the minimum requirements needed
   for an AAA transport protocol, as required by NASREQ [21], Mobile IP
   [22, 23], and ROAMOPS [20]. The base protocol is not intended to be
   used by itself, and must be used with an application-specific
   extension, such as Mobile IP [10]. The DIAMETER protocol was heavily
   inspired and builds upon the tradition of the RADIUS [1] protocol.

   Any node can initiate a request. In that sense, DIAMETER is a peer to
   peer protocol. In this document, a DIAMETER client is the device that
   normally initiates a request for authentication and/or authorization
   of a user. A DIAMETER server is the device that either forwards the
   request to another DIAMETER server (known as a proxy), or one that
   performs the actual authentication and/or authorization of the user
   based on some profile. Given that the server MAY send unsocilited
   messages to clients, it is possible for the server to also issue
   authentication requests. However, these are typically in the form of
   an indication that the user must be re-authenticated and/or re-
   authorized. Another example of an unsolicited message would be for a

Calhoun et al.             expires March 2001                   [Page 4]

INTERNET DRAFT                                            September 2000

   request that the client issue an accounting update.

   DIAMETER services require sequenced in-order reliable delivery of
   data, with congestion control (receiver windowing).  Timely detection
   of failed or unresponsive peers is also required, allowing for robust
   operation.  TCP is insufficient for this second requirement.
   DIAMETER SHOULD be transported over SCTP [26].

1.1  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 [13].

1.2  Terminology

   Refer to [9] for terminology used in this document.

2.0  Protocol Overview

   The base DIAMETER protocol is never used on its own.  It is always
   extended for a particular application.  Four extensions to DIAMETER
   are defined by companion documents:  NASREQ [7], Mobile IP [10],
   Accounting Extension [15], Strong Security [11].  These options are
   introduced in this document but specified elsewhere.  Additional
   extensions to DIAMETER may be defined in the future (see Section

   The base DIAMETER protocol concerns itself with capabilities
   negotiation, and how messages are sent and how peers may eventually
   be abandoned.  The base protocol also defines certain rules which
   apply to all exchanges of messages between DIAMETER peers.  It is
   important to note that the base protocol provides optional
   application-level security AVPs (Integrity-Check-Value) which MAY be
   used in absence of an underlying security protocol (e.g. IP

   Communication between DIAMETER peers begins with one peer sending a
   message to another DIAMETER peer. The set of AVPs included in the
   message is determined by a particular application of or extension to
   DIAMETER. We will refer to this as the DIAMETER extension. One AVP
   that is included to reference a user's session is the Session-Id.

   The initial request for authentication and/or authorization of a user
   would include the Session-Id. The Session-Id is then used in all

Calhoun et al.             expires March 2001                   [Page 5]

INTERNET DRAFT                                            September 2000

   subsequent messages to identify the user's session (see section 3.0
   for more information). The communicating party may accept the
   request, or reject it by returning a response with Result-Code AVP
   set to indicate an error occured. The specific behavior of the
   diameter server or client receiving a request depends on the DIAMETER
   extension employed.

   Session state (associated with a Session-Id) MUST be freed upon
   receipt of the Session-Termination-Request, Session-Termination-
   Answer and according to rules established in a particular
   extension/application of DIAMETER.

   Exchanges of messages are either request/reply oriented, or in some
   special cases, do not require replies.  All such messages that do not
   require replies have names ending with '-Ind' (short for Indication).

   The DIAMETER base protocol provides the Session-Timeout AVP, which
   MAY be used by extensions to specify the duration of a specific
   authorized session.

2.1  Header Format

   The base DIAMETER protocol is run over SCTP [26] port 1812.
   Implementations MAY send packets from any source port, but MUST be
   prepared to receive packets on port 1812. When a request is received,
   in order to send a reply, the source and destination ports in the
   reply are reversed. Note that the source and destination addresses
   used in request and replies MAY be any of the peer's valid IP

   A given DIAMETER process SHOULD use the same port number to send all
   messages to aid in identifying which process sent a given message.
   More than one DIAMETER process MAY exist within a single host, so the
   sender's port number is needed to discriminate them.

   A summary of the DIAMETER data format is shown below. The fields are
   transmitted in network byte order.

Calhoun et al.             expires March 2001                   [Page 6]

INTERNET DRAFT                                            September 2000

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |RADIUS PCC=254 |  Flags  | Ver |         Message Length        |
      |                          Identifier                           |
      |                         Command-Code                          |
      |                           Vendor-ID                           |
      |  AVPs ...

      The RADIUS Packet Compatibility Code (PCC) field is a one octet
      field which is used for backward compatibility with RADIUS and
      MUST be set to 254. In order to easily distinguish DIAMETER
      messages from RADIUS, the value of 254 has been reserved and
      allows implementations to support both protocols by using the
      first octet in the header.

      The Message Flags field is five bits, and is currently unused.
      This field MUST be initialized to zero.

      This Version field MUST be set to 1 to indicate DIAMETER Version

   Message Length
      The Message Length field is two octets and indicates the length of
      the DIAMETER message including the header fields.

      The Identifier field is four octets, and aids in matching requests
      and replies. The sender MUST ensure that the identifier in a
      message is locally unique (to the sender) at any given time, and
      MAY attempt to ensure that the number is unique across reboots.
      The identifier is normally a monotonically increasing number,
      whose start value was randomly generated. DIAMETER servers should
      consider a message to be unique by examining the source address,
      source port and Identifier field of the message.

      The Command-Code field is four octets, and is used in order to
      communicate the command associated with the message. The 32-bit
      address space is managed by IANA (see section 8.2). The following

Calhoun et al.             expires March 2001                   [Page 7]

INTERNET DRAFT                                            September 2000

      Command Codes are currently defined in the DIAMETER base protocol
      and extensions:

         Command-Name             Abbrev.    Code       Reference
         Device-Reboot-Ind         DRI       257           2.6
         Message-Reject-Ind        MRI       259           5.1
         Session-Termination-Ind   STI       274           3.4.1
         Session-Termination-      STR       275           3.4.2
         Session-Termination-      STA       276           3.4.3
         AA-Mobile-Node-Request    AMR       260           [10]
         AA-Mobile-Node-Answer     AMA       261           [10]
         Home-Agent-MIP-Request    HAR       262           [10]
         Home-Agent-MIP-Answer     HAA       263           [10]
         AA-Request                AAR       265           [7]
         AA-Answer                 AAA       266           [7]
         AA-Challenge-Ind          ACI       267           [7]
         DIAMETER-EAP-Request      DER       268           [7]
         DIAMETER-EAP-Answer       DEA       269           [7]
         DIAMETER-EAP-Ind          DEI       270           [7]
         Accounting-Request        ACR       271           [15]
         Accounting-Answer         ACA       272           [15]
         Accounting-Poll-Ind       ACP       273           [15]
         Accounting-Status-Ind     ASI       279           [15]
         Session-Resource-Query    SRQ       277           [29]
         Session-Resource-Reply    SRR       278           [29]
         Home-Agent-Allocated-Ind  HAI       279           [10]

      In the event that the Command-Code field contains a vendor
      specific command, the four octet Vendor-ID field contains the IANA
      assigned "SMI Network Management Private Enterprise Codes" [2]
      value. If the Command-Code field contains an IETF standard
      Command, the Vendor-ID field MUST be set to zero (0).

      AVPs is a method of encapsulating information relevant to the
      DIAMETER message. See section 2.2 for more information on AVPs.

2.2  AVP Format

   DIAMETER AVPs carry specific authentication, accounting and
   authorization information, security information as well as
   configuration details for the request and reply.

Calhoun et al.             expires March 2001                   [Page 8]

INTERNET DRAFT                                            September 2000

   Some AVPs MAY be listed more than once. The effect of this AVP is
   specific, and is specified in each case by the AVP description.

   Each AVP of type 'string' and 'data' MUST be padded to align on a 32
   bit boundary, while other AVP types align naturally. NULL bytes are
   added to the end of the AVP value till a word boundary is reached.
   The length of the padding is not reflected in the AVP Length field.

2.2.1  AVP Header

   The AVP format is shown below and MUST be sent in network byte order.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |                           AVP Code                            |
      |          AVP Length           |     Reserved        |P|R|V|R|M|
      |                        Vendor-ID (opt)                        |
      |    Data ...

   AVP Code
      The AVP Code identifies the attribute uniquely. The first 256 AVP
      numbers are reserved for backward compatibility with RADIUS and
      are to be interpreted as per NASREQ [7]. AVP numbers 256 and above
      are used for DIAMETER, which are allocated by IANA (see section

   AVP Length
      The AVP Length field is two octets, and indicates the length of
      this Attribute including the AVP Code, AVP Length, AVP Flags,
      Reserved, the Vendor-ID field if present and the AVP data. If a
      message is received with an Invalid attribute length, the message
      SHOULD be rejected.

   AVP Flags
      The AVP Flags field informs the DIAMETER host how each attribute
      must be handled. Note that subsequent DIAMETER extensions MAY
      define bits to be used within the AVP Header, and an unrecognized
      bit should be considered an error. The 'R' and the reserved bits
      are unused and should be set to 0 and ignored on receipt, while
      the 'P' bit is defined in [11].

      The 'M' Bit, known as the Mandatory bit, indicates whether support

Calhoun et al.             expires March 2001                   [Page 9]

INTERNET DRAFT                                            September 2000

      of the AVP is required. If an AVP is received with the 'M' bit
      enabled and the receiver does not support the AVP, the message
      MUST be rejected.  AVPs without the 'M' bit enabled are
      informational only and a receiver that receives a message with
      such an AVP that is not supported MAY simply ignore the AVP.

      The 'V' bit, known as the Vendor-Specific bit, indicates whether
      the optional Vendor-ID field is present in the AVP header. When
      set the AVP Code belongs to the specific vendor code address

      Unless otherwise noted, AVPs will have the following default AVP
      Flags field settings:
         The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

2.2.2  Optional Header Elements

   The AVP Header consists of several optional fields. These fields are
   only present if their respective bit-flags are enabled.

      The Vendor-ID field is present in the 'V' bit is set in the AVP
      Flags field. The optional four octet Vendor-ID field contains the
      IANA assigned "SMI Network Management Private Enterprise Codes"
      [2] value, encoded in network byte order. Any vendor wishing to
      implement a DIAMETER extensions MUST use their own Vendor-ID along
      with their privately managed AVP address space, guaranteeing that
      they will not collide with any other vendor's extensions, nor with
      future IETF extensions.

      A vendor ID value of zero (0) corresponds to the IETF adopted AVP
      values, as managed by the IANA. Since the absence of the vendor ID
      field implies that the AVP in question is not vendor specific,
      implementations SHOULD not use the zero (0) vendor ID.

2.2.3  AVP Value Formats

   The Data field is zero or more octets and contains information
   specific to the Attribute. The format and length of the Data field is
   determined by the AVP Code and AVP Length fields. The format of the
   value field MAY be one of seven data types.

         The data contains a variable length of arbitrary data. Unless
         otherwise noted, the AVP Length field MUST be set to at least

Calhoun et al.             expires March 2001                  [Page 10]

INTERNET DRAFT                                            September 2000

         The data contains a non-NULL terminated variable length string
         using the UTF-8 [24] character set.  Unless otherwise noted,
         the AVP Length field MUST be set to at least 9.

         32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most
         significant octet first. The format of the address (IPv4 or
         IPv6) is determined by the length. If the attribute value is an
         IPv4 address, the AVP Length field MUST be 12, otherwise the
         AVP Length field MUST be set to 24 for IPv6 addresses.

         32 bit value, in network byte order. The AVP Length field MUST
         be set to 12.

         64 bit value, in network byte order. The AVP Length field MUST
         be set to 16.

         32 bit unsigned value contains the four most significant octets
         returned from NTP [18], in network byte order. The AVP Length
         field MUST be set to 12.

         The complex data type is reserved for AVPs that includes
         multiple information fields, and therefore do not fit within
         any of the AVP types defined above. Complex AVPs MUST provide
         the data format, and the expected length of the AVP.

2.2.4  DIAMETER Base Protocol AVPs

   The following table describes the DIAMETER AVPs defined in the base
   protocol, their AVP Code values, types, possible flag values and
   whether the AVP MAY be encrypted.

Calhoun et al.             expires March 2001                  [Page 11]

INTERNET DRAFT                                            September 2000

                                            |    AVP Flag rules   |
                   AVP    Section  Value    |    |     |SHLD| MUST|MAY |
   Attribute Name  Code   Defined  Type     |MUST| MAY | NOT|  NOT|Encr|
   User-Name          1     3.3    String   |    |     |    |     | Y  |
   Session-Timeout   27     3.2    Integer32|    |     |    |     | Y  |
   Proxy-State       33     6.2.1  Complex  | M  |     |    |  V  | N  |
   Host-IP-Address  257     2.6.4  Address  | M  |     |    |  V  | N  |
   Extension-Id     258     2.6.3  Integer32|    |     |    |     | Y  |
   Integrity-Check  259     7.1.1  Complex  |    |     |    |     | N  |
     -Value                                 |    |     |    |     |    |
   Encrypted-       260     7.1.2  Complex  |    |     |    |     | N  |
     Payload                                |    |     |    |     |    |
   Nonce            261     7.2    Data     |    |     |    |     | N  |
   Timestamp        262     7.3    Time     |    |     |    |     | N  |
   Session-Id       263     3.3    Data     |    |     |    |     | Y  |
   Host-Name        264     2.3.2  String   | M  |     |    |  V  | N  |
   Vendor-Name      266     2.6.1  String   |    |     |    | V,M | Y  |
   Firmware         267     2.6.2  Integer32|    |     |    | V,M | Y  |
     -Revision                              |    |     |    |     |    |
   Result-Code      268     5.2    Complex  |    |     |    |     | N  |
   Destination-NAI  269     6.2.2  String   |    |     |    |     | Y  |
   Unknown-Command- 270     5.1.2  Integer32|    |     |    |     | Y  |
     Code                                   |    |     |    |     |    |
   Failed-AVP       279     5.1.1  Data     |    |     |    |     | Y  |
   Redirect-Host    278     6.3.1  Address  |    |     |    |     | Y  |
   Redirect-Host-   277     6.3.2  Integer32|    |     |    |     | Y  |
     Port                                   |    |     |    |     |    |
   Grouped-AVP      280     2.4.1  Data     | M  |     |    |  V  | Y  |

2.2.5 Standard DIAMETER Extension AVPs

   The following AVPs are defined in standard DIAMETER extensions.

Calhoun et al.             expires March 2001                  [Page 12]

INTERNET DRAFT                                            September 2000

   AVP Name      Code Ref AVP Name      Code Ref  AVP Name      Code Ref
   ------------- ---- --- ------------  ---- ---  ------------  ---- ----
   User-Password    2 [7] Framed-         38 [7]  MN-FA-         322 [10]
   CHAP-Password    3 [7]   Appletalk-              Challenge-
   NAS-IP-Address   4 [7]   Network                 Length
   NAS-Port         5 [7] Framed-         39 [7]  MN-FA-Response 323 [10]
   Service-Type     6 [7]     Appletalk-          Mobile-Node-   333 [10]
   Framed-Protocol  7 [7]     Zone                  Address
   Framed-IP-       8 [7] CHAP-Challenge  60 [7]  Home-Agent-    334 [10]
     Address              NAS-Port-Type   61 [7]    Address
   Framed-IP-       9 [7] Port-Limit      62 [7]  Previous-FA-   335 [10]
     Netmask              Login-LAT-Port  63 [7]    NAI
   Framed-Routing  10 [7] Tunnel-Type     64 [7]  MN-AAA-SPI     336 [10]
   Filter-Id       11 [7] Tunnel-Medium-  65 [7]  Foreign-Home-  337 [10]
   Framed-MTU      12 [7]   Type                    Agent-
   Framed-         13 [7] Tunnel-Client-  66 [7]    Available
     Compression            Endpoint              Filter-Rule    400 [7]
   Login-IP-Host   14 [7] Tunnel-Server-  67 [7]  Request-Type   401 [7]
   Login-Service   15 [7]   Endpoint              EAP-Payload    402 [7]
   Login-TCP-Port  16 [7] Tunnel-Password 69 [7]  Accounting-    480 [15]
   Reply-Message   18 [7] Tunnel-Private- 81 [7]    Record-Type
   Callback-Number 19 [7]   Group-ID              ADIF-Record    481 [15]
   Callback-Id     20 [7] Tunnel-         82 [7]  Accounting-    482 [15]
   Framed-IP-Route 22 [7]   Assignment-ID           Interim-
   Framed-IPX-     23 [7] Tunnel-         83 [7]    Interval
     Route                  Preference            Accounting-    483 [15]
   Idle-Timeout    28 [7] Tunnel-Client-  90 [7]    Delivery-
   Called-Station- 30 [7]   Auth-ID                 Interval
     Id                   Tunnel-Server-  91 [7]  Accounting-    484 [15]
   Calling-        31 [7]   Auth-ID                 Delivery-
     Station-Id           CMS-Data       310 [11]   Max-Delay
   NAS-Identifier  32 [7] MIP-           320 [10] Accounting-    485 [15]
   Login-LAT-      34 [7]   Registration-           Record-
     Service                Request                 Number
   Login-LAT-Node  35 [7] MIP-           321 [10] Accounting-
   Login-LAT-Group 36 [7]   Registration-           State        486 [15]
   Framed-         37 [7]   Reply                 Query-Index    500 [29]
     Appletalk-                                   Resource-Token 501 [29]

2.3  Mandatory AVPs

   This section defines the DIAMETER AVPs that MUST be present in all
   DIAMETER messages.

2.3.1 Host-Name AVP

Calhoun et al.             expires March 2001                  [Page 13]

INTERNET DRAFT                                            September 2000

   The Host-Name AVP (AVP Code 264) [1] is of type String, and is used
   to inform a DIAMETER peer of the sender's identity. All DIAMETER
   messages MUST include the Host-Name AVP, which contains the host name
   of the originator of the DIAMETER message that MUST follow the NAI
   [8] naming conventions.

   Note that the Host-Name AVP may resolve to more than one address as
   the DIAMETER peer may support more than one address.

2.4  Grouping of AVPs

   The DIAMETER protocol allows AVPs to be "grouped" into a set,
   allowing for complex data representation. The Grouped-AVP AVP
   encapsulates more than one AVP to form an AVP set. Multiple layers of
   encapsulation MAY be used by including a child Grouped-AVP AVP inside
   a parent Grouped-AVP AVP.

   An example of the use of the Grouped-AVP AVP is the Redirect-Host AVP
   (see section 6.3.1), which is used by brokers to request that a
   DIAMETER message be redirected to another DIAMETER node. Since it is
   possible for a DIAMETER node to listen for incoming messages other
   than on the default (standard) port, the Redirect-Host-Port AVP
   (section 6.3.2) allows the port number to be communicated as well.
   The Grouped-AVP MAY be used to create a logical set of the Host and
   the port number, thereby allowing the broker to return more than one
   set of hosts which the message could be redirected to. The following
   is the BNF representation of the above example:

      <Foobar-Ind> ::= <DIAMETER Header, Command-Code = foobar>
                       <Grouped-AVP {
                              <Redirect-Host AVP>
                              <Redirect-Host-Port AVP>
                       <Grouped-AVP {
                              <Redirect-Host AVP>
                              <Redirect-Host-Port AVP>

2.4.1  Grouped-AVP AVP

   The Grouped-AVP AVP (AVP Code 280) is of type complex and is used to
   encapsulate multiple AVPs creating an AVP set.

Calhoun et al.             expires March 2001                  [Page 14]

INTERNET DRAFT                                            September 2000

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                         AVP Header (AVP Code = 280)
      |                             AVPs...

         The AVPs field contains the encapsulated AVPs.

2.5  State Machine

   This section contains a finite state machine, that MUST be observed
   by all DIAMETER implementations. Each DIAMETER node MUST follow the
   state machine described below when communicating with each peer.

      State     Event                          Action    New State
      -----     -----                          ------    ---------
      Initial   Local request to establish     SCTP      Idle
                communication with a DIAMETER  Connect
                peer with which there is no
                existing transport level
                connection established.

      Initial   Receive transport level        Send DRI  Open
                connection request from a
                DIAMETER peer.

      Idle      Connection Established         Send DRI  Wait-DRI

      Idle      Receive DRI                    Send DRI  Open

      Wait-DRI  Receive DRI                    None      Open

      Open      Receive other messages         Process   Open

      Open      Receive DRI                    Cleanup   Closed

      Open      Transport level failure        Cleanup   Closed

      Closed    DIAMETER Entity shutdown       Close     Initial
                or close connection with peer  connection

   The Initial and Idle states MAY be merged if the local SCTP
   implementation is able to implement the piggyback of data during the

Calhoun et al.             expires March 2001                  [Page 15]

INTERNET DRAFT                                            September 2000

   connection phase.

   When the Cleanup action is invoked, the DIAMETER node SHOULD attempt
   to forward all pending requests and replies, which haven't been
   acknowledged, to an alternate server (when possible). If the final
   destination for a specific message is the host that is no longer
   accessible, the message in question SHOULD be responded with the

2.6  Device-Reboot-Ind (DRI) Command

   A DIAMETER device sends the Device-Reboot-Ind message, by setting the
   Command-Code field with a value of 257, to inform a peer that a
   reboot has just occured. Since SCTP [26] allows for connections to
   span multiple interfaces, hence multiple IP addresses, the Device-
   Reboot-Ind message MUST contain one Host-IP-Address AVP for each
   potential IP address that MAY be locally used when transmitting
   DIAMETER messages.

   The DRI message is also used for capabilities negotiation, such as
   the supported protocol version number, and the locally supported
   extensions. The receiver uses the extensions advertised in order to
   determine whether it SHOULD send certain application-specific
   DIAMETER commands. A DIAMETER node MUST retain the supported
   extensions in order to ensure that unrecognized commands and/or AVPs
   are not sent to a peer. Note that in a proxy environment, it is still
   possible that a downstream proxy has no available peer that have
   advertised the extension that corresponds to the Command-Code, and
   therefore the request cannot be forwarded any further. The DIAMETER
   base protocol provides this error reporting, via the Result-Code AVP.

   Once the transport layer connection has been established, a DIAMETER
   entity MUST issue a DRI message, regardless of whether the peer was
   statically configured, or dynamically discovered.  Dynamic discovery
   of DIAMETER peers MAY be done by using Service Location Protocol
   (SLP) [28], or through some other discovery mechanism.

   If a peer is no longer reachable, a DIAMETER device SHOULD
   periodically attempt to establish a transport level connection with
   the peer and send a DRI message. This message does not require a
   reply. If a DIAMETER node receives a DRI message that results in an
   error, a Message-Reject-Ind message MUST be returned.

   Message Format

Calhoun et al.             expires March 2001                  [Page 16]

INTERNET DRAFT                                            September 2000

      <Device-Reboot-Ind> ::= <DIAMETER Header, Command-Code = 257>
                              <Host-Name AVP>
                              <Host-IP-Address AVP>
                              <Vendor-Name AVP>
                              <Extension-Id AVPs>
                              [<Firmware-Revision AVP>]
                              [<Timestamp AVP>
                               <Nonce AVP>
                               <Integrity-Check-Value AVP>]

2.6.1  Vendor-Name AVP

   The Vendor-Name AVP (AVP Code 266) is of type String and is used to
   inform a DIAMETER peer of the Vendor Name of the DIAMETER device.
   This MAY be used in order to know which vendor specific attributes
   may be sent to the peer. It is also envisioned that the combination
   of the Vendor-Name and the Firmware-Revision (section 2.6.2) AVPs MAY
   provide very useful debugging information.

2.6.2  Firmware-Revision AVP

   The Firmware-Revision AVP (AVP Code 267) is of type Integer32 and is
   used to inform a DIAMETER peer of the firmware revision of the
   issuing device.

   For devices that do not have a firmware revision (general purpose
   computers running DIAMETER software modules, for instance), the
   revision of the DIAMETER software module may be reported instead.

2.6.3  Extension-Id AVP

   The Extension-Id AVP (AVP Code 258) is of type Integer32 and is used
   in order to identify a specific DIAMETER extension. This AVP is used
   in the Device-Reboot-Ind message in order to inform the peer what
   extensions are locally supported.

   Each DIAMETER extension draft MUST have an IANA assigned extension
   Idenfier (see section 8.3). The base protocol does not require an
   Extension-Id since its support is mandatory.

   There MAY be more than one Extension-Id AVP within a DIAMETER
   Device-Reboot-Ind message. The following values are recognized:

      NASREQ              1 [7]
      Strong Security     2 [11]

Calhoun et al.             expires March 2001                  [Page 17]

INTERNET DRAFT                                            September 2000

      Resource Management 3 [29]
      Mobile-IP           4 [10]
      Accounting          5 [15]

2.6.4  Host-IP-Address AVP

   The Host-IP-Address AVP (AVP Code 4) [1] is of type Address and is
   used to inform a DIAMETER peer of the sender's IP addresses.  All
   source addresses that a DIAMETER node expects to use with SCTP [26]
   MUST be advertised in the Device-Reboot-Ind message by including a
   Host-IP-Address AVP for each address. This AVP MUST ONLY be used in
   the Device-Reboot-Ind message.

3.0  "User" Sessions

   When a user requests access to the network, a DIAMETER client issues
   an authentication and authorization request to its local server. The
   request contains a Session-Id AVP, which is used in subsequent
   messages (e.g. subsequent authorization, accounting, etc) relating to
   the user's session. The Session-Id AVP is a means for the client and
   servers to correlate a DIAMETER message with a user session.

   When a DIAMETER server authorizes a user to use network resources, it
   SHOULD add the Session-Timeout AVP to the response. The Session-
   Timeout AVP defines the maximum amount of time a user MAY make use of
   the resources before another authorization request is to be
   transmitted to the server. If the server does not receive another
   authorization request before the timeout occurs, it SHOULD release
   any state information related to the user's session. Note that the
   Session-Timeout AVP implies how long the DIAMETER server is willing
   to pay for the services rendered, therefore a DIAMETER client SHOULD
   NOT expect payment for services rendered past the session expiration

   The base protocol does not include any authorization request
   messages, since these are largely application-specific and are
   defined in a DIAMETER protocol extension document. However, the base
   protocol does define a set of messages that are used to terminate
   user sessions. These are used to allow servers that maintain state
   information to free resources.

3.1  Session-Id AVP

   The Session-Id AVP (AVP Code 263) is of type Data and is used to
   identify a specific session (see section 3.0). All messages

Calhoun et al.             expires March 2001                  [Page 18]

INTERNET DRAFT                                            September 2000

   pertaining to a specific session MUST include only one Session-Id AVP
   and the same value MUST be used throughout the life of a session.
   When present, the Session-Id SHOULD appear immediately following the
   DIAMETER Header (see section 2.1).

   For messages that do not pertain to a specific session, multiple
   Session-Id AVPs MAY be present as long as they are encapsulated
   within different Grouped-AVP AVPs.

   The Session-Id MUST be globally unique at any given time since it is
   used by the server to identify the session (or flow). The format of
   the session identifier SHOULD be as follows:

   <Sender's Host-Name><sender's port number> <monotonically increasing
   32 bit value><optional value>

   The monotonically increasing 32 bit value SHOULD NOT start at zero
   upon reboot, but rather start at a random value. This will minimize
   the possibility of overlapping Session-Ids after a reboot.
   Alternatively, an implementation MAY keep track of the increasing
   value in non-volatile memory. The optional value is implementation
   specific but may include a modem's device Id, a layer 2 address,
   timestamp, etc.

   The session Id is created by the DIAMETER device initiating the
   session, which in most cases is done by the client. Note that a
   Session-Id MAY be used by more than one extension (e.g.
   authentication for a specific service and accounting, both of which
   have separate extensions).

3.2  Session-Timeout AVP

   The Session-Timeout AVP (AVP Code 27) [1] is of type Integer32 and
   contains the maximum number of seconds of service to be provided to
   the user before termination of the session. A value of zero means
   that this session has an unlimited number of seconds before

   This AVP MAY be provided by the client as a hint of the maximum
   duration that it is willing to accept. However, the server DOES NOT
   have to observe the hint, and MAY return a value that is smaller than
   the hint. A value of zero provided by a client DOES NOT imply that
   service is being terminated.

3.3  User-Name AVP

Calhoun et al.             expires March 2001                  [Page 19]

INTERNET DRAFT                                            September 2000

   The User-Name AVP (AVP Code 1) [1] is of type String and contains the
   User-Name in a format consistent with the NAI specification [8]. All
   DIAMETER systems SHOULD support usernames of at least 72 octets in

3.4  Session Termination

   The DIAMETER Base Protocol provides a set of messages that MAY be
   used by any peer to explicitely request that a previously
   authenticated and/or authorized session be terminated. Since the
   Session-Id is typically tied to a particular service (i.e. Mobile IP,
   NASREQ, etc), the session termination messages are used to request
   that the service tied to the Session Id be terminated.

3.4.1  Session-Termination-Ind

   The Session-Termination-Ind (STI), indicated by the Command-Code set
   to 274, MAY be sent by any DIAMETER entity to the access device to
   request that a particular session be terminated. This message MAY be
   used when a server detects that a session MUST be terminated, which
   is typically done as a policy decision (e.g. local resources have
   been expended, etc). The Destination-NAI AVP MUST be present, and
   contain the NAI of the access device that initiated the session (see
   section 3.0).

   Upon receipt of the STI message, the access device SHOULD issue a
   Session-Terminate-Request message.

   Message Format

      <Session-Termination-Ind>  ::= <DIAMETER  Header,  Command-Code  =
                                     <Session-Id AVP>
                                     <Host-Name AVP>
                                     <User-Name AVP>
                                     <Destination-NAI AVP>
                                     [<Proxy-State AVP>]
                                     [<Timestamp AVP>
                                      <Nonce AVP>
                                      <Integrity-Check-Value AVP>]

3.4.2  Session-Termination-Request

   The Session-Termination-Request (STR), indicated by the Command-Code
   set to 275, is sent by the access device to inform the Home AAA that
   an authenticated and/or authorized session is being terminated. The

Calhoun et al.             expires March 2001                  [Page 20]

INTERNET DRAFT                                            September 2000

   Destination-NAI AVP MUST be present, and set to the value that was
   found in the Host-Name AVP of the authentication and/or authorization
   response that corresponds with the session in question (e.g. AAA,
   HAR, AMA in section 2.1).

   Upon receipt of the STR, the Home DIAMETER Server SHOULD release all
   resources for the session indicated by the Session-Id AVP. Any
   intermediate server in the Proxy-Chain MAY also release any
   resources, if necessary.

   Message Format

      <Session-Termination-Request>  ::= <DIAMETER Header,  Command-Code
      = 275>
                                         <Session-Id AVP>
                                         <Host-Name AVP>
                                         <User-Name AVP>
                                         <Destination-NAI AVP>
                                         [<Proxy-State AVP>]
                                         [<Timestamp AVP>
                                          <Nonce AVP>
                                          <Integrity-Check-Value AVP>]

3.4.3  Session-Termination-Answer

   The Session-Termination-Answer (STA), indicated by the Command-Code
   set to 276, is sent by the Home DIAMETER Server to acknowledge that
   the session has been terminated. The Result-Code AVP MUST be present,
   and MAY contain an indication that an error occured while servicing
   the STR.

   Message Format

      <Session-Termination-Answer>  ::= <DIAMETER Header, Command-Code =
                                        <Result-Code AVP>
                                        <Session-Id AVP>
                                        <Host-Name AVP>
                                        <User-Name AVP>
                                        <Destination-NAI AVP>
                                        [<Proxy-State AVP>]
                                        [<Timestamp AVP>
                                         <Nonce AVP>
                                         <Integrity-Check-Value AVP>]

4.0  Reliable Transport

Calhoun et al.             expires March 2001                  [Page 21]

INTERNET DRAFT                                            September 2000

   In order to provide rapid discovery of the failure of a communicating
   peer, aggressive retransmission and rapid transactions, DIAMETER
   peers MUST be able to send and receive messages over SCTP [26].  A
   DIAMETER peer MAY use TCP [27], as TCP does provide reliable
   transport, though it does not have the properties listed above.

5.0  Error Reporting

   There are five different types of errors within DIAMETER. The first
   being where a DIAMETER message is poorly formatted and
   unrecognizable, indicated below by "Bad Message". This error
   condition applies if a received message creates a fatal error (e.g.
   fails transport level authentication, cannot be parsed, etc).

   The second case involves receiving a Command-Code that is not
   supported, which is shown below by "Unknown Command". The third case
   is where an AVP is received, marked mandatory and is unknown by the
   receiver, which is labeled below as "Unknown AVP".

   This fourth case involves receiving a message with a known AVP, yet
   the value is either unknown or illegal, which is shown below as "Bad
   Value".  The last case occurs when an error occurs while processing a
   specific extension command, which is not related to the message
   format and is labeled "Extension Error" below.

   Error Type           Ignore Message          Send         Extension
                                         Message-Reject-Ind  Response +
   Bad Message                 X
   Unknown Command                               X
   Unknown AVP                                   X
   Bad Value                                     X
   Extension Error                                               X

   "Ignore Message" indicates that the message is simply dropped. The
   "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST
   be sent to the peer as described in the appropriate section. The
   "Extension Response + Result-Code" indicates that the appropriate
   Response to the message MUST be sent with the Result-Code AVP set to
   a value that enables the peer to understand the nature of the

5.1  Message-Reject-Ind (MRI) Command

   The Message-Reject-Ind (MRI), indicated by the Command-Code set to
   259, provides a generic means of completing transactions by

Calhoun et al.             expires March 2001                  [Page 22]

INTERNET DRAFT                                            September 2000

   indicating errors in the messages that initiated them. The Message-
   Reject-Ind command is sent in response:

      1. An error is found in a Device-Reboot-Ind message.
      2. An error is found in a message for which there is no
         appropriate response.
      3. A message was received that cannot pass the base protocol error
      4. A message was received whose extension is not locally

   In the event that a request is received that causes an error defined
   in a DIAMETER extension, the appropriate response with the Result-
   Code AVP SHOULD be sent.

   The Message-Reject-Ind message MUST contain the same identification
   in the header and include the Session-Id if it was present in the
   original message that it is responding to, even if the identification
   is erroneous.

   Message Format

      The structure of the Message-Reject-Ind message is defined as

      <Message-Reject-Ind message> ::= <DIAMETER Header, Command-Code  =
                                       <Host-Name AVP>
                                       [<Session-Id AVP>]
                                       <Result-Code AVP>
                                       <Failed-AVP AVP>
                                       [<Timestamp AVP>
                                        <Nonce AVP>
                                        <Integrity-Check-Value AVP>]

      where the Identifier value in the message header and optionally
      the Session-Id AVP are copied from the message being rejected. The
      Result-Code AVP indicate the nature of the error causing
      rejection, and the Failed-AVP AVP provides some minimal debugging
      data by indicating a specific AVP type which caused the problem.
      See the description of the Result-Code AVP for indication of when
      the Failed-AVP AVP MUST be present in the message.  See [25] for
      more information.

5.1.1  Failed-AVP AVP

   The Failed-AVP AVP (AVP Code 279) is of type Data and provides

Calhoun et al.             expires March 2001                  [Page 23]

INTERNET DRAFT                                            September 2000

   debugging information in cases where a request is rejected or not
   fully processed due to erroneous information in a specific AVP. The
   value of the Result-Code AVP will provide information on the reason
   for the Failed-AVP AVP.

   A DIAMETER message MAY contain one or more Failed-AVP, each
   containing a complete AVP that could not be processed successfully.
   The possible reasons for this AVP are the presence of an improperly
   constructed AVP, an unsupported or unrecognized AVP or an invalid AVP

5.1.2  Unrecognized-Command-Code

   The Unrecognized-Command-Code AVP (AVP Code 270) is of type Integer32
   and contains the offending Command-Code that resulted in sending the
   Message-Reject-Ind message.

5.2  Result-Code AVP

   The Result-Code AVP (AVP Code 268) is of type Complex and indicates
   whether a particular request was completed successfully or whether an
   error occurred. All DIAMETER messages of type *-Response or *-Answer
   MUST include one Result-Code AVP.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                         AVP Header (AVP Code = 268)
      |                          Result Code                          |
      |    String ...

   The Result Code field contains an IANA-managed 32-bit address space
   representing errors (see section 8.4). The String field contains an
   OPTIONAL string field containing a human readable error message. The
   base protocol defines the following error codes, and others MAY be
   defined in separate DIAMETER extensions:

      DIAMETER_SUCCESS                   0
         The Request was successfully completed.

      DIAMETER_FAILURE                   1
         The Request was not successfully completed for an unspecified

Calhoun et al.             expires March 2001                  [Page 24]

INTERNET DRAFT                                            September 2000

         reason.  A DIAMETER Message-Reject-Ind message returning this
         result SHOULD whenever possible also contain one or more
         Failed-AVP AVPs indicating the AVPs that caused the failure.

      DIAMETER_POOR_REQUEST              2
         The Request was poorly constructed.

      DIAMETER_INVALID_AUTH              3
         The Request did not contain a valid Integrity-Check-Value or
         CMS-Data [11] AVP.

         The request or response contained an unknown Session-Id.

         A request was received for a user that is unknown, therefore
         authentication failed.  This error is sent only due to
         conditions that arise due to command messages in DIAMETER
         extensions, the base protocol does not include command codes
         that require the User-Name AVP.

         The Request contained a Command-Code that the receiver did not
         recognize or support. The Message-Reject-Ind message MUST also
         contain a Unknown-Command-Code AVP containing the unrecognized

      DIAMETER_TIMEOUT                   7
         This error MAY be returned if a request has been received that
         has a Timestamp AVP that is older than the maximum age that the
         communicating peer is willing to accept.

         The peer received a message that contained an AVP that is not
         recognized or supported and was marked with the Mandatory bit.
         A DIAMETER message with this error MUST contain one or more
         Failed-AVP AVP containing the AVPs that caused the failure.

         A proxy or broker has determined that the request could not be
         satisfied locally and the initiator of the request should
         direct the request directly to the server, whose contact
         information has been added to the response. This error code
         MUST NOT be sent in a Message-Reject-Ind message.

         A proxy or broker has determined that it is unable to forward
         the request or provide redirect information since the realm

Calhoun et al.             expires March 2001                  [Page 25]

INTERNET DRAFT                                            September 2000

         portion of the NAI requested is unknown.

         A message was received that included an Integrity-Check-Value
         or CMS-Data AVP [11] that made use of an unsupported transform.

         The authentication process for the user failed, most likely due
         to an invalid password used by the user.

         A request was received for which the user could not be
         authorized.  This error could occur when the user has already
         expended allowed resources, or if the service requested is not
         permitted to the user.

         The request contained an AVP with an invalid value in its data
         portion. A DIAMETER message with this result code MUST include
         the offending AVPs within a Failed-AVP AVP.

      DIAMETER_MISSING_AVP              15
         The request did not contain an AVP that is considered mandatory
         by the Command Code definition. If this value is sent in the
         Result-Code AVP, a Failed-AVP AVP SHOULD be included in the
         message. The data portion of the Failed-AVP MUST have its AVP
         Code set to the value of the missing AVP.

         The request could not be delivered to the host specified in the
         Destination-NAI AVP, or no host is available for that
         particular realm to handle the request.

5.2.1 Additional Error Codes

   The following additional result codes are defined by standard
   extensions to the DIAMETER protocol.

      DIAMETER_ERROR_BAD_KEY             16 [10]
      DIAMETER_ERROR_TOO_BUSY            18 [10]
      DIAMETER_INVALID_CMS_DATA          20 [11]

6.0  DIAMETER Message Routing

Calhoun et al.             expires March 2001                  [Page 26]

INTERNET DRAFT                                            September 2000

   The DIAMETER base protocol supports two basic message routing
   methods; proxying and brokering. A DIAMETER proxy is a server that
   simply forwards the request based on the user's identity, or through
   some other means. A DIAMETER broker is a server that provides
   redirect services, allowing all servers in a roaming consortium to
   interact directly. This section describes how DIAMETER message
   routing is performed.

6.1  NAI-Based Message Routing

   DIAMETER Message routing is done through the use of the Network
   Access Identifier (NAI), and an associated realm routing table (see
   section 10.0). The NAI has a format of user@realm, and DIAMETER
   servers have a list of locally supported realms, and MAY have a list
   of externally supported realms. When a message is received that
   includes a realm that is not locally supported, the message is
   proxied to the DIAMETER entity configured in the "route" table.

   Figure 1 depicts an example where DIA1 receives a request to
   authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local
   realm route table and determines that the message must be proxied to
   DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3
   checks its realm route table, and determines that the realm is
   locally supported, and processes the authentication request, and
   returns the response. How the response actually makes it back to the
   sender of the original request is described in the next section.

                   (Request)                  (Request)
            (User-Name=joe@abc.com)    (User-Name=joe@abc.com)
      +------+      ------>      +------+      ------>      +------+
      |      |                   |      |                   |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
                   (Response)                 (Response)
            (User-Name=joe@abc.com)    (User-Name=joe@abc.com)

      mno.net                    xyz.com                    abc.com
                        Figure 1: NAI Based Routing

6.2  Message Proxying

   A DIAMETER proxy is a server that provides message forwarding
   functions to other DIAMETER Servers. Proxies are typically used when
   a hierarchical DIAMETER network is deployed, where some DIAMETER
   servers can authenticate and authorize a set of users.  Such an

Calhoun et al.             expires March 2001                  [Page 27]

INTERNET DRAFT                                            September 2000

   example is a roaming consortium, where each ISP has a user base,
   which they can authenticate and authorize. It is important to note
   that proxy servers MUST NOT attempt to re-order AVPs in a DIAMETER

   There are two different methods of routing DIAMETER messages through
   proxies; Proxy-State and Destination-NAI. The Proxy-State AVP is used
   to encode local state information in a request. The corresponding
   response is guaranteed to include the same Proxy-State AVP, allowing
   the node to recover the state information. The use of the Proxy-State
   AVP requires that the corresponding response traverse through the
   same set of proxies (in reverse order), which introduces some
   reliability problems. If a single DIAMETER node in the proxy chain
   fails, all responses that must traverse through it would be lost. The
   Proxy-State AVP is used by proxy servers that MUST maintain state
   information, such as protocol translation gateways [25].

   The Destination-NAI is a more flexible scheme, and is used by
   DIAMETER proxies that do not need to maintain any state information
   when acting as a simple message routing agent. This allows the
   DIAMETER network to be much more reliable, since responses can be
   sent through an alternate path should a proxy server fail.

6.2.1  Proxy-State AVP

   The Proxy-State AVP (AVP Code 33) [1] is used by proxy servers when
   forwarding requests and contains opaque data that is used by the
   proxy to further process the response. Such data may include AVPs
   that are to be added to the response, information about the
   downstream peer, etc.

   It is important to note that the use of the Proxy-State AVP requires
   that the corresponding response traverse through the DIAMETER node
   that added the AVP. The requirement that responses return on the
   reverse path of a request is only adequate in certain networks.  It
   does not allow for resilient operation, since alternative servers
   MUST NOT be used. Therefore a DIAMETER node SHOULD only use the
   Proxy-State AVP when performing protocol bridging [25].

   A DIAMETER node that adds a Proxy-State AVP to a request expects the
   SAME AVP to be present in the corresponding response. Furthermore,
   more than one Proxy-State AVP MUST NOT be present in a single
   DIAMETER message.  See [25] for more information on AVP handling.

Calhoun et al.             expires March 2001                  [Page 28]

INTERNET DRAFT                                            September 2000

                   (Request)                  (Request)
            (User-Name=joe@abc.com)    (User-Name=joe@abc.com)
             (Proxy-State=DIA1,x)       (Proxy-State=DIA2,y)
      +------+      ------>      +------+      ------>      +------+
      |      |                   |      |                   |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
                   (Response)                 (Response)
            (User-Name=joe@abc.com)    (User-Name=joe@abc.com)
             (Proxy-State=DIA1,x)       (Proxy-State=DIA2,y)

      mno.net                    xyz.com                    abc.com
                   Figure 2: Use of the Proxy-State AVP

   When a DIAMETER node receives a message that includes the Proxy-State
   AVP, and the address within the AVP is a peer that it is able to
   exchange DIAMETER messages with, the message MUST be forwarded to the
   peer in question. When the Proxy-State AVP's address indicates that
   the AVP was locally added, the Proxy-State AVP MUST be removed, and
   the original Proxy-State AVP must be restored (if one was present in
   the corresponding request). When DIA2 receives the response from DIA3
   (in figure 2), it examines the Proxy-State and finds that it was
   created by DIA1. Since DIA2 is able to communicate with DIA1, it
   forwards the message to DIA1.

   The Proxy-State AVP's Address field is 128-bits in length contains
   one of the IP addresses of the system that created the AVP, and used
   to assist hosts in determining whether a Proxy-State AVP is intended
   for the local host. If the host creating the AVP has an IPv4 address,
   and is IPv6 capable, the leading 96 bits MUST be set to zero (0). If
   the AVP has an IPv4 address, and the host is not IPv6 capable, the
   leading 64 bites MUST be set to zero (0), and the following 32 bits
   MUST be set to all ones [16].

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                        AVP Header (AVP Code = 33)
      |                       128-bit Address...
      |    Data ...

6.2.2  Destination-NAI AVP

Calhoun et al.             expires March 2001                  [Page 29]

INTERNET DRAFT                                            September 2000

   The Destination-NAI AVP (AVP Code 269) is of type String, MAY be
   included in a request, and SHOULD be included in a response message.
   The Destination-NAI MUST be in a format consistent with the NAI
   specification. When found in a response, the AVP SHOULD contain the
   value of the Host-Name AVP that was found in the request.

   Since the Destination-NAI AVP allows for a more resilient DIAMETER
   network, by allowing a DIAMETER node to send to one of many peers
   that can handle a particular realm, implementations SHOULD use it as
   opposed to the Proxy-State AVP.

   Request messages in transactions that span multiple round trips (e.g.
   EAP [7]), the Destination-NAI AVP SHOULD be copied from the previous
   response that caused the new request. This will ensure that all
   requests forming the transaction will be forwarded to the same target
   DIAMETER server.

                   (Request)                  (Request)
            (User-Name=joe@abc.com)    (User-Name=joe@abc.com)
            (Host-Name=DIA1@nmo.net)   (Host-Name=DIA1@nmo.net)
      +------+                   +------+                   +------+
      |      |                   |      |                   |      |
      | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 |
      |      |                   |      |                   |      |
      +------+                   +------+                   +------+
         ^                                                      |
         |                       +------+                       |
         |                       |      |                       |
         +-----------------------| DIA4 |<----------------------+
                                 |      |
                   (Response)                 (Response)
            (User-Name=joe@abc.com)    (User-Name=joe@abc.com)
            (Dest-NAI=DIA1@mno.net)    (Dest-NAI=DIA1@mno.net)

      mno.net                     mno.com                    abc.com
                     Figure 3: Use of Destination-NAI

   When DIA3 (in figure 3) creates the response, it adds the
   Destination-NAI AVP with the value that was found in the request's
   Host-Name AVP. DIA3 is not able to communicate directly with DIA1,
   but it is able to communicate with peers within the mno.com network.
   Therefore, it issues the response to any peer in the mno.com network.
   When DIA4 receives the response, it examines the Destination-NAI AVP,
   and determines that it is able to communicate directly with DIA1, and
   forwards the response to it.

Calhoun et al.             expires March 2001                  [Page 30]

INTERNET DRAFT                                            September 2000

6.3  Message Redirection

   There are cases where a DIAMETER proxy, known as a broker, may wish
   to request that a server contact another directly instead of
   forwarding the message (figure 2). This is typically done when the
   broker provides simple NAI to Home DIAMETER Server address resolution

   In the example provided in figure 4, abc.net's DIAMETER server issues
   a request to its broker, which in turn returns a response that
   includes the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION (see
   section 5.2).  When a response is received with the Result-Code set
   to this value, the message MUST also include one or more Redirect-
   Host AVPs, and optionally the Redirect-Host-Port AVP. The Redirect-
   Host AVP contains the IP address to which the request SHOULD be
   forwarded to directly. When more than one un-grouped Redirect-Host-
   Port AVPs are found, they contain more than one server that could
   service the request. When more than one Redirect-Host AVP is present
   in a Grouped-AVP, they contain the various IP addresses of the SAME
   host, any of which MAY be used to directly contact the peer.

   The above requires that the broker be contacted for all messages in
   order to identify the Home DIAMETER server to use for a particular
   realm. Since contacting the broker does introduce additional latency,
   an implementation MAY cache the information received by the broker,
   eliminating the need to contact the broker for multiple messages to
   the same realm. The broker MAY include the the Session-Timeout AVP in
   the redirect response as a hint to its peer as to how long the cache
   entry SHOULD be valid. The peer is not obligated to respect the hint
   from the broker.

   In the event that the Redirect-Host AVP is grouped, the broker MAY
   also include the Session-Timeout AVP to the same Grouped-AVP in order
   to specify the cache timeout for the particular host.

                             +------------------+ +---------+
                             |     DIAMETER     | | CRL DB/ |
                             |      Broker      | |  OCSP   |
                             +------------------+ +---------+
                      Request |  Response +
                              |  Result Code =
                              |  Redirect
                     +----------+              +----------+
                     | abc.net  |              | xyz.net  |
                     | DIAMETER |<------------>| DIAMETER |
                     |  Server  |              |  Server  |

Calhoun et al.             expires March 2001                  [Page 31]

INTERNET DRAFT                                            September 2000

                     +----------+    Direct    +----------+
          Figure 4: DIAMETER Broker Returning Redirect Indication

   When returning the response with the Result-Code set to
   DIAMETER_REDIRECT_INDICATION, the broker MAY also include the
   certificates of both the requesting server, and the target server.
   These certificates are encapsulated in a CMS-Data AVP [11]. The
   requesting server SHOULD forward the certificate that belongs to it
   in the subsequent request to the home DIAMETER server.

   Figure 5 below provides a more complex network, where the request
   must be forwarded to a second broker (Inter-Broker Communication),
   and there are a number of proxies between the NAS and the "edge"
   DIAMETER Server that communicates with the broker. When Broker A
   receives the response that includes the redirect information from
   Broker B, it is passed down to abc's DIAMETER server, which in turn
   communicates directly with xyz's server.

                         +------------+  Request  +------------+
                         |  DIAMETER  |           |  DIAMETER  |
                         |  Broker A  |<--------->|  Broker B  |
                         +------------+  Redirect +------------+
                              ^          Response
                      Request |Redirect
                          +----------+              +----------+
            +-----+     +-| abc.net  |              | xyz.net  |
            |     |   +-| | DIAMETER |<------------>| DIAMETER |
            | NAS |<->| | | Server(s)|              |  Server  |
            |     |   | | +----------+    Direct    +----------+
            +-----+   | +----------+   Communication
           Figure 5: Inter-Broker redirect in a proxied network

6.3.1  Redirect-Host AVP

   The Redirect-Host AVP (AVP Code 278) is of type Address and is
   returned in a response that has the Result-Code AVP set to
   DIAMETER_REDIRECT_REQUEST. This AVP includes the IP address of the
   DIAMETER host to which the request MUST be redirected. The presence
   of multiple Redirect-Host AVPs within the same Grouped-AVP, implies
   that all of the addresses MAY be used to contact the same host. When
   multiple AVPs are found that are un-grouped, or grouped with
   different Grouped-AVPs, they represent separate hosts. Upon receipt

Calhoun et al.             expires March 2001                  [Page 32]

INTERNET DRAFT                                            September 2000

   of such a Result-Code, and this AVP, a DIAMETER host SHOULD send the
   request directly to one of the hosts.

   The broker MAY wish to return the certificate associated with a given
   Redirect-Host AVP. This can be returned in a CMS-Data AVP, as defined
   in [11].

6.3.2  Redirect-Host-Port AVP

   The Redirect-Host-Port AVP (AVP Code 277) is of type Integer32 and
   MAY be present when the Redirect-Host AVP is present. The absence of
   this AVP implies that the reserved port MUST be used.

7.0  DIAMETER Message Security

   The DIAMETER Base protocol MAY be secured in one of three ways. The
   first method does not involve any security mechanisms in the DIAMETER
   protocol, but relies on an underlying security mechanism, such as IP
   Security. The second method is hop-by-hop security, which SHOULD be
   supported by all DIAMETER implementations. The third method is
   optional and requires a Public Key Infrastructure [14], and is
   documented in [11].

7.1  Hop-by-Hop Security

   DIAMETER Hop-by-Hop security provides message integrity and per AVP
   encryption, and requires that the communicating entities have a pre-
   configured shared secret, similar to the method employed by the
   RADIUS protocol. Hop-by-Hop security is very difficult to deploy and
   administer in large scale networks and involves symmetric trust,
   unlike security based on a public key infrastructure (PKI). PKI is
   used for DIAMETER End-to-End security, and is defined in [11]. Hop-
   by-Hop security may be desirable in environments where symmetric
   cryptography is sufficient or when a PKI is not available.

   Figure 6 below provides an example of hop-by-hop security in a proxy
   chain. Assuming that the packet was received by DIA2 from DIA1, and
   was to be proxied to DIA3, the following steps would be taken:

     1. Validating the message's integrity using the shared secret with
        DIA1, and removing the authenticated security AVPs.

     2. Decrypting any encrypted AVPs using the secret shared with DIA1.

     3. Re-encrypting AVPs using the secret shared with DIA3.

Calhoun et al.             expires March 2001                  [Page 33]

INTERNET DRAFT                                            September 2000

     4. Computing the message hash using the secret shared with DIA3,
        and adding it to the ICV AVP in the DIAMETER message.

               (Shared-Secret-1)          (Shared-Secret-2)
      +------+       ----->      +------+      ------>      +------+
      |      |                   |1    3|                   |      |
      | DIA1 +------------------>+ DIA2 +------------------>+ DIA3 |
      |      |                   |2    4|                   |      |
      +------+                   +------+                   +------+
            Figure 6: Hop-by-Hop Security in Proxy Environments

   The above steps that each proxy MUST perform in a proxy chain clearly
   describes the security issues associated with hop-by-hop security in
   a proxy environment. Since the message integrity is re-computed at
   each node in the chain, it is not possible to detect if a proxy
   modified information in the message (e.g. session time). Furthermore,
   any sensitive information would be known to all proxies in the chain,
   since each node must decrypt AVPs. Therefore, Any AVPs that contain
   data that MUST NOT be seen by intermediate DIAMETER nodes MUST be
   protected via the mechanism described in the strong security
   extension [11].

   It is highly recommended that the size of the shared secrets used be
   sufficiently long (e.g. 128 bits), and that different shared secrets
   be used for both authentication and encryption.

7.1.1  Integrity-Check-Value AVP

   The Integrity-Check-Value AVP (AVP Code 259) is of type complex and
   is used for hop-by-hop message authentication and integrity.

   The DIAMETER header as well as all AVPs (including padding) up to
   this AVP is protected by the Integrity-Check-Value. Note that the
   Message Length field in the DIAMETER header MUST be set to zero (0)
   prior to the ICV calculation. The Timestamp and Nonce AVPs MUST be
   present in the message PRIOR to the Integrity-Check-Value AVP. The
   Timestamp AVP provides replay protection and the Nonce AVP provides
   randomness. Any AVPs in a message that is not succeeded by the
   Integrity-Check-Value AVP MUST be ignored.

   The following is an example of a message that include hop-by-hop

Calhoun et al.             expires March 2001                  [Page 34]

INTERNET DRAFT                                            September 2000

   <DIAMETER Message> ::= <DIAMETER Header, Command-Code = foobar>
                          <Nonce AVP>
                          [<Additional AVPs>]
                          <Timestamp AVP>
                          <Integrity-Check-Value AVP>

   All DIAMETER implementations SHOULD support this AVP.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                         AVP Header (AVP Code = 259)
      |                          Transform ID                         |
      |                             Key ID                            |
      |    Data ...

      AVP Length
         The length of this attribute MUST be at least 13.

      Transform ID
         The Transform ID field contains a value that identifies the
         transform that was used to compute the ICV. The following
         values are defined in this document:

         HMAC-MD5-96[6]          1
            The ICV is computed using the HMAC-MD5 algorithm, and the
            first 12 bytes of the hash output is included in the data
            portion of the ICV AVP. All DIAMETER implementations
            supporting this AVP MUST support this transform. Using the
            example code provided in [6], the following call would be
            used to generate the Integrity-Check-Value:

            hmac_md5(DiameterMessage, MessageLength, Secret,
                     Secretlength, Output)

      Key ID
         The Key ID field contains a key identifier, which is used to
         identify the keying information used to generate the AVP's data

         The data field contains the output from the hashing algorithm.

Calhoun et al.             expires March 2001                  [Page 35]

INTERNET DRAFT                                            September 2000

7.1.2  Encrypted-Payload AVP

   The Encrypted-Payload AVP (AVP Code 260) is of type complex and is
   used to encapsulate encrypted AVPs for privacy during transmission.

   Hop-by-Hop confidentiality is achieved by encapsulating all AVPs
   which are to be encrypted into an Encrypted-Payload AVP.  This
   feature SHOULD be supported by DIAMETER implementations.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                         AVP Header (AVP Code = 260)
      |                          Transform ID                         |
      |                             Key ID                            |
      |     Decrypted Data Length     |           Data ...

      AVP Length
         The length of this attribute MUST be at least 13.

      Transform ID
         The Transform ID field contains a value that identifies the
         transform that was used to compute the ICV. The following
         values are defined in this document:

         MD5                     1
            See section for more information.

      Key ID
         The Key ID field contains a key identifier, which is used to
         identify the keying information used to generate the AVP's data

      Decrypted Data Length
         The encrypted data length field contains the actual length of
         the decrypted data. This field is necessary in order to not
         treat the padded data as part of the plaintext.

         The data field contains the encrypted payload.  MD5 Payload Hiding

Calhoun et al.             expires March 2001                  [Page 36]

INTERNET DRAFT                                            September 2000

   MD5 Payload Hiding is supported by DIAMETER for backward
   compatibility with existing RADIUS infrastructure.

   The plain text (which is a buffer containing one or more AVPs) is
   first padded to a sixteen (16) byte boundary with 0 bytes.  Since the
   encapsulated AVPs have length fields, it is possible to detect their
   boundaries, whether or not padding has been done.

   One or more Nonce AVPs MUST precede an Encrypted-Payload AVP.  An MD5
   hash is performed on the:

      - last Nonce AVP which precedes the Encrypted-Payload AVP
      - the shared authentication secret

   This MD5 hash value is then XORed with the first 16 octet segment of
   the buffer to encrypt.  The resulting 16 octet result is saved as the
   first 16 octets of the encrypted buffer.  The result is also used to
   calculate a new value using MD5:

       - the shared authentication secret
       - the 16 byte result of the previous XOR

   This value is then XORed with the next 16 bytes.  This is done for
   each 16 bytes successively in the buffer to encrypt, producing an
   equal sized encrypted buffer.

   The receiver of a DIAMETER message with an Encrypted-Payload AVP MUST
   first check the integrity of the message, either through the ICV, or
   the CMS-Data AVP [11] if it protects the Encrypted-Payload AVP.  Then
   the Encrypted-Payload AVP is decrypted, by reversing the above
   procedure, which applied to the buffer will reproduce the plain text
   version.  The decapsulated AVPs are then used to process the DIAMETER
   message in the normal manner.

7.2  Nonce AVP

   The Nonce AVP (AVP Code 261) is of type Data and MUST be present
   prior to the Integrity-Check-Value AVPs within a message and is used
   to ensure randomness within a message. The content of this AVP MUST
   be a random value of at least 128 bits. Some crypto algorithms are
   known to have weaknesses if a random value is not found early within
   the plaintext, therefore it is recommended that the Nonce AVP be
   added early in a message if possible.

7.3  Timestamp AVP

Calhoun et al.             expires March 2001                  [Page 37]

INTERNET DRAFT                                            September 2000

   The Timestamp AVP (AVP Code 262) is of type Time and is used to add
   replay protection to the DIAMETER protocol. This AVP MUST appear
   prior to the Integrity-Check-Value AVP or any other message integrity
   AVP defined in separate extensions. The value of this AVP is the most
   significant four octets returned from an NTP [18] server that
   indicates the number of seconds expired since Jan. 1, 1900.

   Messages that are older than a configurable maximum age SHOULD be
   rejected (see section 10.0) and a response SHOULD be returned with
   the Result-Code AVP value set to DIAMETER_TIMEOUT. Note that the
   larger the configurable value, the more susceptible one is to a
   replay attack. However, one does have to take into account the
   possibility for clock drift, and the latency involved in the
   transmission of the message over the network. The timestamp AVP
   SHOULD be updated prior to retransmission.

   A DIAMETER node that receives a message with the Result-Code AVP set
   to DIAMETER-TIMEOUT MAY use the time found in the Timestamp AVP
   within the reply in order to synchronize its clock with its peer.
   When time synchronization is done, the sender MUST NOT change its
   local time, but SHOULD adjust the time delta for all outgoing
   messages to the peer, and require that its local time be used in
   received messages.

   Implementations must be prepared to wrap at the epochal 2038 where
   Time values are used, and 0,1,... MUST be considered greater than
   2^32-1 at that time.

8.0  IANA Considerations

   This document defines a number of assigned numbers to be maintained
   by the IANA.  This section explains the criteria to be used by the
   IANA to assign additional numbers in each of these lists. The
   following subsections describe the assignment policy for the
   namespaces defined elsewhere in this document.

8.1  AVP Attributes

   As defined in section 2.2, AVPs contain vendor ID, attribute and
   value fields. For vendor ID value of 0, IANA will maintain a registry
   of assigned AVP codes and in some case also values. Attribute 0-254
   are assigned from the RADIUS protocol [1], whose attributes are also
   maintained through IANA. AVP Codes 256-280 are assigned within this
   document. The remaining values are available for assignment through
   Designated Expert [12].

Calhoun et al.             expires March 2001                  [Page 38]

INTERNET DRAFT                                            September 2000

8.2  Command Code Values

   As defined in section 2.1, the Command Code field has an associated
   value maintained by IANA. Values 0-255 are reserved for backward
   RADIUS compatibility, and values 256-258 are defined in this
   specification. The remaining values are available for assignment via
   Designated Expert [12].

8.3  Extension Identifier Values

   As defined in section 2.6.5, the Extension Identifier is used to
   identify a specific DIAMETER Extension. All values, other than zero
   (0) are available for assignment via Standards Action [12].

   Note that the DIAMETER protocol is not inteded to be extended for any
   purpose. Any extensions added to the protocol MUST ensure that they
   fit within the existing framework, and that no changes to the base
   protocol are required.

8.4  Result-Code AVP Values

   As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines
   the values 0-8. All remaining values are available for assignment via
   IETF Consensus [12].

8.5  Integrity-Check-Value AVP Transform Values

   Section 7.1.1 defines the Integrity-Check-Value AVP (AVP Code 259)
   which contains a field called the Transform. This document reserves
   the value 1. All remaining values are available for assignment via
   Designated Expert [12].

8.6  AVP Header Bits

   There are six remaining reserved bits in the AVP header. Additional
   bits should only be assigned via a Standards Action [12].

9.0  Open Issues

   The following are the open issues that SHOULD be addressed in future
   versions of the DIAMETER protocol:

      - AVPs of type 'Time" are 32 bits in size and contain the a

Calhoun et al.             expires March 2001                  [Page 39]

INTERNET DRAFT                                            September 2000

        timestamp consistent with NTP [18]. This field is expected to
        expire sometime in 2038. Future investigation SHOULD be done to
        determine if a 64 bit time format could be used.

      - The fact that the Sender's IP Address is used in the
        construction of the Session-Id means that the introduction of
        Network Address Translation MAY cause two hosts to represent the
        same Session Identifier.  This area needs to be investigated
        further to be able to support DIAMETER hosts on a private

      - When additional hashing transforms are supporting by the
        DIAMETER base protocol, there SHOULD be a method to negotiate
        the transform to be used.  This negotiation MUST NOT be prone to
        a bidding down attack to the lowest secure transform.

      - This specification defines the use of SCTP port 1812. This port
        has not been assigned to the DIAMETER protocol, and cannot be
        requested until SCTP becomes an RFC.

10.0  DIAMETER protocol related configurable parameters

   This section contains the configurable parameters that are found
   throughout this document:

      DIAMETER Peer
         A DIAMETER entity MAY communicate with peers that are
         statically configured. A statically configured DIAMETER peer
         would require that either the IP address or the fully qualified
         domain name (FQDN) be supplied, which would then be used to
         resolve through DNS.

      Realm Routing Table
         A DIAMETER Proxy server routes messages based on the realm
         portion of a Network Access Identifier (NAI). The server MUST
         have a table of Realms Names, and the address of the peer to
         which the message must be forwarded to. The routing table MAY
         also include a "default route", which is typically used for all
         messages that cannot be locally processed.

      Maximum Age of an outstanding message
         Messages older than the maximum age SHOULD be rejected, as
         described in section 7.3.  The recommended value is 4 seconds.

      Shared Secret
         The shared secret is a value that is known by two communicating
         peers, and is used to generate the Integrity-Check-Value AVP.

Calhoun et al.             expires March 2001                  [Page 40]

INTERNET DRAFT                                            September 2000

         There is no default.

11.0  Security Considerations

   The DIAMETER base protocol requires that two communicating peers
   exchange messages in a secure fashion. This document describes two
   security methods that can be used. The first requires no security at
   the application layer, but rather relies on an underlying security
   mechanism, such as IP Security.

   When IP Security is not available, or desirable, the DIAMETER
   protocol MAY use hop-by-hop security, which requires communicating
   peers to share a long-lived secret. Hop-by-Hop security provides
   replay protection by requiring that the communicating peers share a
   time source, such as an NTP server. Information of a sensitive
   nature, which MUST NOT be seen by any intermediate DIAMETER node MUST
   NOT be encrypted using hop-by-hop encryption.

   When the DIAMETER protocol is used in an inter-domain network, strong
   application level security MAY be required, such as non-repudiation.
   When the communicating peers do require this level of security either
   for legal or business purposes, the extension defined in [11] MAY be
   used. This security model provides AVP-level authentication, and the
   encryption mechanism is designed such that only the target host has
   the keying information required to decrypt the information.

12.0  References

   [1]  Rigney, et alia, "RADIUS", RFC-2138, April 1997

   [2]  Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994.

   [3]  Postel, "User Datagram Protocol", RFC 768, August 1980.

   [4]  Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April

   [5]  Kaufman, Perlman, Speciner, "Network Security: Private Communi-
        cations in a Public World", Prentice Hall, March 1995, ISBN 0-

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

   [7]  P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ

Calhoun et al.             expires March 2001                  [Page 41]

INTERNET DRAFT                                            September 2000

        Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
        progress, September 2000.

   [8]  Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu-
        ary 1999.

   [9]  Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-
        calhoun-diameter-framework-08.txt, IETF work in progress, June

   [10] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft-
        calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep-
        tember 2000.

   [11] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
        Extension", draft-calhoun-diameter-strong-crypto-05.txt (work in
        progress), September 2000.

   [12] Narten, Alvestrand,"Guidelines for Writing an IANA Considera-
        tions Section in RFCs", BCP 26, RFC 2434, October 1998

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

   [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public
        Key Infrastructure Online Certificate Status Protocol (OCSP)",
        RFC 2560, June 1999.

   [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension",
        draft-calhoun-diameter-accounting-08.txt, IETF work in progress,
        September 2000.

   [16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC
        2373, July 1998.

   [17] ISI, "Internet Protocol", RFC 791, September 1981.

   [18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4,
        IPv6 and OSI, RFC 2030, October 1996.

   [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras-
        tructure Certificate and CRL Profile", RFC 2459, January 1999.

   [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols",
        RFC 2477, January 1999.

   [21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
        Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work

Calhoun et al.             expires March 2001                  [Page 42]

INTERNET DRAFT                                            September 2000

        in progress, June 2000.

   [22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA",
        draft-hiller-cdma2000-aaa-02.txt, IETF work in progress, Sep-
        tember 2000.

   [23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
        Authorization, and Accounting Requirements", draft-ietf-
        mobileip-aaa-reqs-04.txt, IETF work in progress, June 2000.

   [24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [25] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J.
        Haag, "DIAMETER Implementation Guidelines", draft-calhoun-
        diameter-impl-guide-03.txt, IETF work in progress, June 2000.

   [26] R. Stewart et al., "Simple Control Transmission Protocol",
        draft-ietf-sigtran-sctp-13.txt, IETF Work in Progress, July

   [27] Postel, J. "Transmission Control Protocol", RFC 793, January

   [28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location
        Protocol, Version 2", RFC 2165, June 1999.

   [29] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft-
        calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, Sep-
        tember 2000.

13.0  Acknowledgements

   The authors would like to thank Nenad Trifunovic, Tony Johansson and
   Pankaj Patel for their participation in the Document Reading Party.

   The authors would also like to acknowledge the following people for
   their contribution in the development of the DIAMETER protocol:

   Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant,
   Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal
   Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Stephen Farrell,
   Sumit Vakil, John R. Vollbrecht, Jeff Weisberg, Jon Wood and Glen

14.0  Authors' Addresses

Calhoun et al.             expires March 2001                  [Page 43]

INTERNET DRAFT                                            September 2000

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Laboratories
      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

      Allan C. Rubens
      Tut Systems, Inc.
      220 E. Huron, Suite 260
      Ann Arbor, MI 48104

       Phone:  +1 734-995-1697
      E-Mail:  arubens@tutsys.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

      Erik Guttman
      Network and Security Research Center, Sun Laboratories
      Sun Microsystems, Inc.
      Eichhoelzelstr. 7
      74915 Waibstadt

       Phone:  +49-7263-911-701
      E-mail:  erik.guttman@germany.sun.com

15.0  Full Copyright Statement

Calhoun et al.             expires March 2001                  [Page 44]

INTERNET DRAFT                                            September 2000

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this docu-
   ment itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English. The lim-
   ited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis

Calhoun et al.             expires March 2001                  [Page 45]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/