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

                         DIAMETER Base Protocol

Status of this Memo

   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 mailing list.

   Distribution of this memo is unlimited.

   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:

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


   The DIAMETER base protocol is intended to provide a AAA framework for

Calhoun et al.              expires May 2000                    [Page 1]

INTERNET DRAFT                                             December 1999

   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.1.1  ZLB Message 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  Command-Code AVP
                  2.3.2  Host-IP-Address AVP
                  2.3.3  Host-Name AVP
            2.4  The art of AVP Tagging
            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  Reboot-Type AVP
                  2.6.4  Reboot-Time AVP
                  2.6.5  Extension-Id AVP
            2.7  Device-Watchdog-Ind (DWI) Command
      3.0  "User" Sessions
            3.1  Session-Id AVP
            3.2  Session-Timeout AVP
            3.3  User-Name AVP
      4.0  Reliable Transport
            4.1  Flow Control
                  4.1.1  Receive-Window AVP
            4.2  Peer failure recovery
      5.0  Error Reporting
            5.1  Message-Reject-Ind (MRI) Command
                  5.1.1  Failed-AVP AVP
            5.2  Result-Code AVP
      6.0  DIAMETER Message Routing
            6.1  Message Proxying
                  6.1.1  Proxy-State AVP
                  6.1.2  Destination-NAI AVP

Calhoun et al.              expires May 2000                    [Page 2]

INTERNET DRAFT                                             December 1999

            6.2  Message Redirection
                  6.2.1 Redirected-Host 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
            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  Reboot-Type AVP Values
            8.7  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 Author's Addresses
      15.0 Full Copyright Statement

Calhoun et al.              expires May 2000                    [Page 3]

INTERNET DRAFT                                             December 1999

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
      - Sequenced in-order reliable delivery of UDP datagram messages
      - Support for congestion control (receiver window), as required in
      - Timely detection of failed or unresponsive peers, as required in
        [21, 22, 23]
      - 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. 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 performs the actual
   authentication and/or authorization of the user based on some
   profile. A server MAY issue an unsolicited message to a client, but

Calhoun et al.              expires May 2000                    [Page 4]

INTERNET DRAFT                                             December 1999

   this is typically not a request for authentication and/or
   authorization, but rather for something else, such as an accounting

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.  The base DIAMETER protocol
   concerns itself with capabilities negotiation, and how messages are
   sent, resent 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 an optional application-level security AVPs
   (Integrity-Check-Value) which MAY be used in absence of an underlying
   security protocol (e.g. IP Security).

   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 which is included in the initial communication is the Session-Id.

   The communicating party may accept or reject the request which
   contains a new Session-Id, or return Result-Code if the request
   cannot be processed.  The behavior of the communicating peer depends
   on the DIAMETER extension employed.

   Exchanges of messages are either request/reply oriented, or in some
   special cases, do not require replies.  All such messages which do
   not require replies (or acknowledgments) have names which end with
   '-Ind' (short for Indication).  All messages require a transport
   level acknowledgement, either through a Zero Length Body (ZLB), or by
   piggybacking an acknowledgement in a non-ZLB message.

   Communicating DIAMETER peers retain state relating to transport

Calhoun et al.              expires May 2000                    [Page 5]

INTERNET DRAFT                                             December 1999

   (sequence numbers and the like).  This state information may be
   discarded when the communicating peer is determined to be
   unreachable.  This occurs when the peer does not acknowledge receipt
   of a DIAMETER message that has been retransmitted a maximum number of
   times. The Device-Watchdog-Ind is used to pro-actively probe peers to
   ensure that communication is still possible.

   Freeing the transport state associated with a communication with a
   DIAMETER peer is entirely independent of freeing session state
   (associated with a Session-Id).  The latter MUST only be done
   according to rules established in a particular extension/application

   DIAMETER extensions SHOULD define an explicit exchange of messages
   which allow a peer to inform the other party that a session has been

2.1  Header Format

   The base DIAMETER protocol is run over UDP 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

   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.

       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|A|W| Ver |         Message Length         |
      |                          Identifier                           |
      |         Next Send (Ns)        |       Next Received (Nr)      |
      |  AVPs ...

      The RADIUS Packet Compatibility Code (PCC) field is a one octet

Calhoun et al.              expires May 2000                    [Page 6]

INTERNET DRAFT                                             December 1999

      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 used in order to
      identify any options. This field MUST be initialized to zero. The
      'W' bit (Window-Present) is set when the Next Send (Ns) and Next
      Received (Nr) fields are present in the header. The 'A' bit is set
      to indicate that the message is an acknowledgement only (ZLB) and
      does not contain a Command-Code AVP following the header. Note
      that the Security AVPs, if required, MUST still be present within
      a ZLB.

      In the event that the DIAMETER protocol is implemented over a
      reliable transport, the 'W' and 'A' bits MUST NOT be set.

      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. DIAMETER
      implementations MUST be ready to receive UDP packets of at least
      8192 octets in length.

      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.

   Next Send
      This field is present when the Window-Present bit is set in the
      header flags. The Next Send (Ns) is copied from the send sequence
      number state variable, Ss, at the time the message is transmitted.
      The variable Ss is incremented after copying into the header if
      the message is not a ZLB.

   Next Received
      This field is present when the Window-Present bit is set in the

Calhoun et al.              expires May 2000                    [Page 7]

INTERNET DRAFT                                             December 1999

      header flags. Nr is copied from the receive sequence number state
      variable, Sr, and indicates the sequence number, Ns, +1 of the
      highest (modulo 2^16) in-sequence message received. See section
      4.0 for more information.

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

2.1.1  ZLB Message Format

   Zero Length Body (ZLB) messages are used to explicitly acknowledge
   one or more DIAMETER message, and contain no additional
   Authentication, Authorization or Accounting related AVPs. ZLB
   messages must contain authentication AVPs, otherwise attacks could be
   mounted against DIAMETER nodes.

   The format of a ZLB message is as follows:

      <ZLB Message> ::= <DIAMETER Header>
                        [<Timestamp AVP>
                         <Nonce AVP>
                         <Integrity-Check-Value AVP>]

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.

   Some AVPs MAY be listed more than once. The effect of this is AVP
   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.  Zero 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.

Calhoun et al.              expires May 2000                    [Page 8]

INTERNET DRAFT                                             December 1999

       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|T|V|R|M|
      |                        Vendor ID (opt)                        |
      |                           Tag (opt)                           |
      |    Data ...

   AVP Code
      The AVP Code identifies the attribute uniquely.  If the Vendor-
      Specific bit is set, the AVP Code is allocated from the vendor's
      private address space.

      The first 256 AVP numbers are reserved for backward compatibility
      with RADIUS and are to be interpreted as per RADIUS [1].  AVP
      numbers 256 and above are used for DIAMETER, which are allocated
      by IANA (see section 8.1).

   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 Tag and Vendor ID fields 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
      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
      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

Calhoun et al.              expires May 2000                    [Page 9]

INTERNET DRAFT                                             December 1999

      set the AVP Code belongs to the specific vendor code address

      The 'T' bit, known as the Tag bit, is used to group sets of AVPs
      together. Grouping of AVPs is necessary when more than one AVP is
      needed to express a condition. If this bit is set, the optional
      Tag field will be present.

      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. The 'T'
         bit MAY 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.

   Vendor ID
      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 DIAMETER extensions MUST use their own Vendor ID along
      with private Attribute values, guaranteeing that they will not
      collide with any other vendor's extensions, nor with future IETF

      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.

      The Tag field is four octet in length and is intended to provide a
      means of grouping attributes in the same message which refer to
      the same set. If the Tag field is unused, the 'T' bit MUST NOT be

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. Note that messages
   which are larger than the path MTU will cause IP fragmentation and
   messages SHOULD be kept to that size wherever possible. In any case

Calhoun et al.              expires May 2000                   [Page 10]

INTERNET DRAFT                                             December 1999

   UDP limits messages to 2^16 bytes.

   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

         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, In network byte order, and contains the
         seconds since 00:00:00 GMT, January 1, 1900. 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 May 2000                   [Page 11]

INTERNET DRAFT                                             December 1999

                                                   Irregular AVP Flag rules
                      Attribute Section  Value    |     |     |SHOULD| MUST|Encr|
      Attribute Name     Code   Defined  Type     | MUST| MAY | NOT  |  NOT|Cand|
      User-Name      [1]    1     3.3    String   |     |     |      |     | Y  |
      Host-IP-Address[1]    4     2.3.2  Address  |  M  |     |      | T,V | N  |
      Session-Timeout[1]   27     3.2    Integer32|     |     |      |     | Y  |
      Host-Name      [1]   32     2.3.3  String   |  M  |     |      | T,V | N  |
      Proxy-State    [1]   33     6.1.1  Complex  |  M  |     |      | T,V | N  |
      Command-Code        256     2.3.1  Integer32|  M  |  V  |      |  T  | N  |
      Extension-Id        258     2.6.5  Integer32|     |     |      |     | Y  |
      Integrity-Check     259     7.1.1  Complex  |     |     |      |     | N  |
        -Value                                    |     |     |      |     |    |
      Encrypted-Payload   260     7.1.2  Data     |     |     |      |     | N  |
      Nonce               261     7.2    Data     |     |     |      |     | N  |
      Timestamp           262     7.3    Time     |     |     |      |     | N  |
      Session-Id          263     3.3    Data     |     |     |      |     | Y  |
      Vendor-Name         266     2.6.1  String   |     |     |      |T,V,M| Y  |
      Firmware            267     2.6.2  Integer32|     |     |      |T,V,M| Y  |
        -Revision                                 |     |     |      |     |    |
      Result-Code         268     5.2    Complex  |     |     |      |     | N  |
      Destination-NAI     269     6.1.2  String   |     |     |      |     | Y  |
      Reboot-Type         271     2.6.3  Integer32|     |     |      |     | N  |
      Reboot-Time         272     2.6.4  Integer32|     |     |      |     | N  |
      Failed-AVP          279     5.1.1  Data     |     |     |      |     | Y  |
      Receive-Window      277     4.1.1  Integer32|     |     |      |     | Y  |
      Redirect-Host       278     6.2.1  Address  |     |     |      |     | Y  |

2.3  Mandatory AVPs

   This section defines the DIAMETER AVPs that MUST be present in all
   DIAMETER messages, with the exception of the ZLB.

2.3.1  Command-Code AVP

   The Command-Code AVP (AVP Code 256) is of type Integer32 and MUST be
   the first AVP following the DIAMETER header (except for ZLB
   messages).  A DIAMETER message MUST have at most one Command-Code
   AVP, and it is used in order to communicate the command associated
   with the message.  The Command Code 32-bit address space is managed
   by IANA (see section 8.2).

   The following Command Codes are currently defined in the DIAMETER

Calhoun et al.              expires May 2000                   [Page 12]

INTERNET DRAFT                                             December 1999

      Command-Name             Abbrev.    Code       Reference
      Device-Reboot-Ind         DRI       257           2.6
      Device-Watchdog-Ind       DWI       258           2.7
      Message-Reject-Ind        MRI       259           5.1
      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]
      Mobile-Node-Terminate-Ind MTI       264           [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]

2.3.2  Host-IP-Address AVP

   The Host-IP-Address AVP (AVP Code 4) is of type Address and is used
   to inform a DIAMETER peer of the sender's IP address. All DIAMETER
   messages, except for ZLBs, MUST include either the Host-IP-Address or
   the Host-Name (section 2.3.3) AVPs, or both.

2.3.3  Host-Name AVP

   The Host-Name AVP (AVP Code 32) is of type String, and is used to
   inform a DIAMETER peer of the sender's identity. All DIAMETER
   messages, except for ZLBs, MUST include either the Host-IP-Address or
   the Host-Name (section 2.3.2) AVPs, or both.  This AVP contains the
   host name of the originator of the DIAMETER message that MUST follow
   the NAI [8] naming conventions.

2.4  The art of AVP Tagging

   The AVP Header provides the 'T' bit, which is used to group AVPs
   together. All AVPs with the same tag value are part of the same
   "group", and there are no guidelines or rules on which tag values are
   used.  The base protocol defines the Redirect-Host AVP (see section
   6.2.1), and [11] defines how the associated certificate MAY be
   carried within the DIAMETER protocol. This allows a single request to

Calhoun et al.              expires May 2000                   [Page 13]

INTERNET DRAFT                                             December 1999

   include information about more than one host. In the case where
   multiple AVPs are needed to indicate a specific authorization "rule"
   tagging is appropriate. In some cases, more than one such rule MAY be
   present, and the tagging mechanism allows the sets of AVPs to be
   easily grouped.

   Some Command Codes require certain AVPs to be tagged and use the '('
   and ')' characters in the BNF command definition, such as:
      <Device-Reboot-Ind> ::= <DIAMETER Header>
                              <Command Code AVP>
                              (<Tagged AVP #1>
                               <Tagged AVP #2>
                               <Tagged AVP n>)

2.5  State Machine

   A DIAMETER node initially considers all known peers to be in the
   closed state, and should not process any DIAMETER message with the
   exception of the Device-Reboot-Ind (DRI). Once the DIAMETER peer is
   set to the open state, any DIAMETER message may be accepted and
   processed. This section provides the DIAMETER base protocol state

   If at any time no transport level acknowledgement is received and the
   message was retransmitted the maximum number of times, the session
   with the peer MUST be closed, and all associated state with the peer
   MUST be freed.

      State           Event             Action               New State
      -----           -----             ------               ---------
      closed          Local Open        send DRI             wait-ack1

      closed          receive DRI       send ACK             wait-ack2
                                        send DRI

      closed          receive invalid   cleanup              closed

      wait-ack1       receive ACK       accept Incoming      wait-ack1

      wait-ack1       receive DRI       send ACK             open
                                        Accept Incoming

Calhoun et al.              expires May 2000                   [Page 14]

INTERNET DRAFT                                             December 1999

      wait-ack1       no ACK received   cleanup              closed

      wait-ack2       received ACK      Accept Incoming      open

      wait-ack2       no ACK received   cleanup              closed

      open            receive DRI       send ACK             wait-ack2
                      Rebooted          send DRI

      open            receive DRI       cleanup              closed

      open            receive DWI       send ACK             open

      open            receive other     send ACK             open

      open            inactivity period send DWI             open
                      hits watchdog

      open            no ACK received   cleanup              closed

2.6  Device-Reboot-Ind (DRI) Command

   A DIAMETER device sends the Device-Reboot-Ind message, by including
   the Command-Code AVP with a value of 257, to inform a peer either of
   an upcoming reboot, or that it has just rebooted. The Reboot-Type AVP
   MUST be present and indicates the type of reboot associated with this
   command. Note that a DIAMETER device should only send this message
   when it is able to receive network traffic.

   The receiver of a DRI message with the Reboot-Type AVP set to
   REBOOT_IMMINENT SHOULD make an attempt to send packets to an
   alternate peer, if one is available. The optional Reboot-Time AVP
   will contain an estimate of how long before the peer will be ready to
   re-establish communication. In the case of a software implementation
   (server) running on a general purpose operating system, the Reboot-
   Time AVP will probably not be present since it is possible that the
   DIAMETER server has been stopped and it is not possible to know how
   long before (and if) it will be restarted.

   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

Calhoun et al.              expires May 2000                   [Page 15]

INTERNET DRAFT                                             December 1999

   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 for this problem to occur, and the DIAMETER base protocol
   provides this error reporting message.

   Upon reboot, the host MUST issue a DRI message with the Reboot-Type
   AVP set to REBOOTED to all configured peers. If a peer is no longer
   reachable, a DIAMETER device SHOULD periodically transmit a DRI until
   an acknowledgement is received. The retransmission timer SHOULD be
   different from the retransmission timer used when communication has
   been established, and SHOULD be configurable.

   Upon receipt of this message the peer's Ss and Sr variables MUST be
   reset. It is possible for this message to be received outside the
   window (Ns and Nr set to zero) when it follows a reboot.

   The DIAMETER Reboot-Ind message does not require a reply. The message
   is acknowledged using DIAMETER's reliable transport. See [25] for
   more information.

   Message Format

      <Device-Reboot-Ind> ::= <DIAMETER Header>
                              <Command Code AVP = 257>
                              {<Host-IP-Address AVP> ||
                               <Host-Name AVP>}
                              <Vendor-Name AVP>
                              <Extension-Id AVPs>
                              <Reboot-Type AVP>
                              [<Reboot-Time AVP>]
                              [<Receive-Window AVP>]
                              [<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.

Calhoun et al.              expires May 2000                   [Page 16]

INTERNET DRAFT                                             December 1999

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  Reboot-Type AVP

   The Reboot-Type AVP (AVP Code 271) is of type Integer32 and MUST be
   present in the Device-Reboot-Indication message. This AVP contains an
   indication of the type of reboot that has or will occur. The
   following values are currently supported:

      REBOOT_IMMINENT                 1
         When the Reboot-Type AVP is set to this value it is an
         indication that the DIAMETER peer is about to reboot and should
         not be sent any additional DIAMETER messages after the
         acknowledgement for this Device-Reboot-Ind message.

      REBOOTED                        2
         When the Reboot-Type AVP is set to this value it is an
         indication that the DIAMETER peer has recently rebooted and is
         ready to accept new DIAMETER messages.

2.6.4  Reboot-Time AVP

   The Reboot-Time AVP (AVP Code 272) is of type Integer32 and MAY be
   present in the DRI. The value of this AVP indicates the number of
   seconds before the issuer expects to be ready to receive new DIAMETER
   messages. This AVP MUST only be present when the Reboot-Type AVP is
   set to REBOOT_IMMINENT. The value indicated by this AVP should be
   used as an estimate and is not a hard rule.

2.6.5  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 command in order to inform the peer what
   extensions are locally supported.

   Each DIAMETER extension draft MUST have an Extension-Id assigned to

Calhoun et al.              expires May 2000                   [Page 17]

INTERNET DRAFT                                             December 1999

   it by the IANA (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]
      Mobile-IP           4 [10]
      Accounting          5 [15]

2.7  Device-Watchdog-Ind (DWI) Command

   The Device-Watchdog-Ind (DWI), indicated by the Command-Code AVP set
   to 258, is OPTIONAL and is used as a keepalive mechanism between two
   DIAMETER peers. If implemented, it SHOULD be sent during after a
   configurable period of inactivity. Communicating peers are not
   required to have the same DWI timer values set, as each entity MAY
   have different requirements.

   A DIAMETER node MAY use this mechanism to ensure that fail-over to an
   alternate server occurs in the absence of AAA traffic. This pro-
   active approach may minimize the possible latency involved in the
   fail-over that would otherwise occur.

   The lower the timer value is set to, the quicker a host will pro-
   actively detect that a peer is no longer reachable. However, the
   timer SHOULD NOT be set to a value that is considered too low (e.g. 2
   seconds), since it will generate considerable traffic.

   The DIAMETER Device-Watchdog-Ind message does not require a reply.
   The message is acknowledged using DIAMETER's reliable transport. See
   [25 for more information.

   Message Format

      <Device-Watchdog-Ind> ::= <DIAMETER Header>
                                <Command Code AVP = 258>
                                {<Host-IP-Address AVP> ||
                                 <Host-Name AVP> }
                                [<Timestamp AVP>
                                 <Nonce AVP>
                                 <Integrity-Check-Value AVP>]

3.0  "User" Sessions

Calhoun et al.              expires May 2000                   [Page 18]

INTERNET DRAFT                                             December 1999

   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. Such extensions
   SHOULD provide a message that allows a client to inform a server that
   the user's session has been released. This would enable the server to
   free state information instead of having to wait for the timeout to

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
   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
   Command-Code AVP.

   For messages that do not pertain to a specific session, multiple
   Session-Id AVPs MAY be present as long as the 'T' bit is set.

   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 IP Address><sender's port number> <monotonically increasing
   32 bit value><optional value>

   The monotonically increasing 32 bit value SHOULD NOT start at zero

Calhoun et al.              expires May 2000                   [Page 19]

INTERNET DRAFT                                             December 1999

   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) 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 any value. A value of zero
   provided by a client DOES NOT imply that service is being terminated.

3.3  User-Name AVP

   The User-Name AVP (AVP Code 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

4.0  Reliable Transport

   This section provides a detailed overview of how DIAMETER is reliably
   transported over UDP. DIAMETER provides its own reliable transport
   due to its unique requirements, which include:

      - Rapid discovery of the failure of a communicating peer.
      - Transactions of few messages will be the norm, so the TCP slow
        start algorithm is not appropriate.
      - The retransmission scheme required is more aggressive than TCP

Calhoun et al.              expires May 2000                   [Page 20]

INTERNET DRAFT                                             December 1999

4.1  Flow Control

   The DIAMETER header contains two fields used for reliable transport:
   Nr (Next Received) and Ns (Next Send).  The sequence number state for
   each peer is represented (for clarity of discussion) as Sr (the next
   in-sequence message expected to be received) and Ss (the next in-
   sequence message to be sent).  Sr and Ss are initialized to 0.

   The sequence number is a free ranging counter modulo 65536.  For
   purposes of detecting duplication, a received sequence value is
   considered less than or equal to the last received value if its value
   lies in the range of the last value and its 32767 successor values.
   For example if the last received sequence number was 15, the packets
   received with Ns values in the range 32783..65535, or 0..15 would be
   considered duplicates.  Duplicate messages are silently discarded.

   ZLB messages are used to acknowledge DIAMETER messages to the
   communicating peer. Each subsequent non-ZLB message is sent with a
   sequence number incremented by one (modulo 2^16). The following rules

      - When a non-ZLB message is received with a Ns value which matches
        the peer's Sr value, Sr is incremented by one.  Sr is not
        modified if a message is received with a Ns value greater than
        the current Sr value.

      - In messages which are sent to a peer, Nr is set to reflect one
        higher than the Ns value of the highest (module 2^16) in-order
        message received from the peer.

      - Every time a peer sends a non-ZLB message, it sends the message
        with Ns set to the current value of Ss.  The value of Ss for
        that peer is then incremented by one (modulo 2^16).

      - Every time a peer receives an in-order non-ZLB message, the
        receiving peer must increment its Sr value.  The peer MUST
        acknowledge the message, either by sending a ZLB message with
        the updated Nr value, or by piggybacking the acknowledgement in
        any outgoing message sent to the communicating peer.  In this
        piggybacked message, the Nr field will be set to its updated
        value.  The implementation guidelines [25] defines an OPTIONAL
        algorithm for delaying acknowledgments, to wait for outgoing
        messages to piggyback acknowledgements on.

      - Messages which are sent MUST be queued and retransmitted till
        the peer sends an acknowledgement.  Messages SHOULD be
        retransmitted at least three times.  The implmentation
        guidelines specification [25] recommends a retransmission timer

Calhoun et al.              expires May 2000                   [Page 21]

INTERNET DRAFT                                             December 1999


   Retransmitted messages SHOULD include the current value of Sr in the
   Nr field.  An implementation MAY choose not to update Nr field (and
   Timestamp AVP) for retransmitted messages, in order to avoid having
   to perform another hash in the Integrity-Check- Value AVP.  The
   message identifier in the retransmitted message MUST NOT be changed.

   A DIAMETER implementation MAY queue out of order DIAMETER messages
   for subsequent processing.

   The receive window is the maximum number of unacknowledged packets
   that are to be outstanding to a DIAMETER peer. When transmitting
   packets, a DIAMETER peer must obey the receive window size offered by
   its peer. The default window size is 7.  Once the number of
   unacknowledged messages equals the window size, the window is
   'closed.'  Previously transmitted packets may be retransmitted when
   the peer's window is closed.  A peer MAY explicitly specify its
   window size in the Device-Reboot-Ind message in the Receive-Window

   A peer MAY return a Nr value in a ZLB or piggybacked in a non-ZLB
   message which is less than the latest Sr value, due to congestion.
   Returning a value in Nr of the first value in the window will have
   the effect of preventing the communicating peer from sending any new

   See [25] for some examples of how sequence numbers progress.

4.1.1  Receive-Window AVP

   The Receive-Window AVP (AVP Code 277) is of type Integer32 and
   contains the maximum number of outstanding unacknowledged messages
   that it is willing to accept for a given peer. Once the number of
   unacknowledged messages has reached this number, the receive window
   is considered closed. The default value for the receive window is 7,
   and SHOULD be configurable. A simple implementation that does not
   require a high number of transactions per second MAY send a Receive-
   Window AVP set to one (1).

   A node MUST stop sending messages when it detects that the number of
   unacknowledged messages is equal to the peer's receive window size.

4.2 Peer failure recovery

   A DIAMETER message with the Command-Code AVP set to Device-Reboot-Ind

Calhoun et al.              expires May 2000                   [Page 22]

INTERNET DRAFT                                             December 1999

   and the Ns and Nr values set to zero (0) indicates that the peer has
   rebooted.  This message MUST be recognized and supported by a
   DIAMETER implementation. When this event occurs, the Ss and Sr values
   must be reset and the retransmission queue MUST be cleared. Since the
   protocol requires that all new messages include a random identifier
   in the protocol header, a Device-Reboot-Ind that is received with the
   same identifier as the last processed Device-Reboot-Ind is considered
   a retransmission and SHOULD NOT change the peer's state to closed.

   Messages other than the Device-Reboot-Ind MUST NOT be sent to the
   peer until both the acknowledgement for the transmitted Device-
   Reboot-Ind AND the peer's Device-Reboot-Ind have been received. When
   both of these have been received, the peer is considered to be in the
   active state.

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 AVP 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

Calhoun et al.              expires May 2000                   [Page 23]

INTERNET DRAFT                                             December 1999

   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 AVP set
   to 256, provides a generic means of completing transactions by
   indicating errors in the messages that initiated them. The Message-
   Reject-Ind command is a possible response to any DIAMETER command.
   Some DIAMETER commands MAY expect more specialized error messages,
   depending on the error type.

   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. The receiver of a Message-Reject-Ind SHOULD examine the
   Result-Code AVP provided before processing the identification, in
   order to handle the latter appropriately.

   Message Format

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

      <Message-Reject-Ind message> ::= <DIAMETER Header>
                                       <Command-Code AVP = 256>
                                       <Host-IP-Address AVP>
                                       [<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

Calhoun et al.              expires May 2000                   [Page 24]

INTERNET DRAFT                                             December 1999

   The Failed-AVP AVP (AVP Code 279) is of type Data and provides
   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
   value (e.g. unknown Command-Code AVP).

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. 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
         reason.  A DIAMETER Message-Reject message returning this
         result SHOULD whenever possible also contain one or more
         Failed-AVP AVPs indicating the attributes which caused the

      DIAMETER_POOR_REQUEST              2

Calhoun et al.              expires May 2000                   [Page 25]

INTERNET DRAFT                                             December 1999

         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 contained an unknown Session-Id. 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 Session-Id AVP.

         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 AVP that the receiver did
         not recognize or support. The Message-Reject-Ind message MUST
         also contain a Failed-AVP AVP containing the unrecognized
         Command-Code AVP.

      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 Message-Reject-Ind message with this error MUST contain one
         or more Failed-AVP AVP containing the AVPs that caused the

         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
         portion of the NAI requested is unknown.

Calhoun et al.              expires May 2000                   [Page 26]

INTERNET DRAFT                                             December 1999

         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 which the Command Code
         requires be present.  If this result code is sent, a Failed-AVP
         AVP should be included in the Message-Reject-Ind message.  The
         AVP 'Data' in the Failed-AVP has its AVP Code set to the value
         of the missing and required AVP, but does not include any data
         of its own.

6.0  DIAMETER Message Routing

   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.

6.1  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
   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

Calhoun et al.              expires May 2000                   [Page 27]

INTERNET DRAFT                                             December 1999


   The example provided in figure 1 shows a request issued by DIA1,
   requesting authentication and authorization for a user that belongs
   to DIA3's network. When DIA1 receives the request from the access
   device (e.g. NAS), it checks whether the Destination-NAI AVP is
   present, which MUST be in a format consistent with the NAI [8]
   specification. If the Destination-NAI is not present, the server MUST
   use the information found in the User-Name AVP.

   The NAI has a format of user@realm, and DIAMETER servers typically
   have a list of locally supported realms, and MAY have a list of
   externally supported realms with associated DIAMETER servers.
   DIAMETER servers that interface with brokers SHOULD allow for a
   "default" destination for all requests received that are not locally

   In the example below, DIA1 looks up the user's realm, and determines
   that the request is to be forwarded to DIA2. When DIA2 receives the
   request, it MAY decide that some state information needs to be kept
   in order to process the response in a particular fashion.  An example
   would be that DIA2 determines that certain authorization information
   is to be added to the response, when received.

                   (Request)                  (Request)
            (    (
            (   (
                (Proxy-State=x)            (Proxy-State=y)
      +------+      ------>      +------+      ------>      +------+
      |      |                   |      |                   |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
                   (Response)                 (Response)
            (    (
            (    (
                (Proxy-State=x)            (Proxy-State=y)                    
                        Figure 1: DIAMETER Proxying

   There are two methods that MAY be implemented by DIAMETER servers in
   order to keep per-request state information.

      1. DIA2 MAY maintain a state control block, and using the
         session-Id and possibly the Identifier in the header, can match
         the request with the response. The state control block MAY
         include AVPs that need to be added to the corresponding
         response, or any additional policy decisions that will need to

Calhoun et al.              expires May 2000                   [Page 28]

INTERNET DRAFT                                             December 1999

         be done when the response is received.

      2. DIA2 MAY add a Proxy-State AVP (see section 6.1.1), which can
         contain ANY information that will be needed when the
         corresponding response is received. A DIAMETER message MUST
         only include one Proxy-State AVP, so if a new Proxy-State AVP
         is added, the old one MUST be removed.  The new Proxy-State AVP
         MAY include AVPs that are to be added to the response, the
         existing Proxy-State AVP, etc.

         Once DIA2 has completed processing the request, it forwards the
         request to DIA3 following the same procedures defined for DIA1.

         When DIA3 receives the request, and it determines that the
         request is to be processed locally, it authenticates and
         authorizes the user. DIA3 MUST add the Destination-NAI AVP,
         with the same contents as the Host-Name AVP that was found in
         the corresponding request. If the request contained a Proxy-
         State AVP, the same AVP MUST be present in the response.

         When DIA2 receives the response from DIA3, it MUST first
         determine whether the Proxy-State AVP was created locally by
         looking at the address field of the AVP. Since it is the same
         AVP as the one that it added to the request, it will extract
         any embedded information within the Proxy-State AVP. If AVPs
         were encapsulated within the Proxy-State AVP, these SHOULD be
         extracted and added to the response. If the request from DIA1
         included a Proxy-State AVP, the same AVP MUST be present in the
         response back to DIA1.

6.1.1  Proxy-State AVP

   The Proxy-State AVP (AVP Code 33) 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.

   A DIAMETER node that receives such an AVP in a request MUST return
   the identical AVP in the response. Furthermore, no more than one
   Proxy-State AVP MUST be present in a message at any given time, so
   implementations MUST ensure that they remove any Proxy-State AVPs
   before adding their own.

   If the Proxy-State AVP was removed from a request, the same AVP MUST
   be inserted in the corresponding response before forwarding the
   message to the downstream peer.

Calhoun et al.              expires May 2000                   [Page 29]

INTERNET DRAFT                                             December 1999

   The Proxy-State AVP's Address field is 128-bits in length contains
   the IP address of the system created the AVP. If the host creating
   the AVP has an IPv4 address, the leading 96 bits MUST be set to zero
   (0).  This field is intended to assist hosts in determining whether a
   Proxy-State AVP is intended for the local host.

       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.1.2  Destination-NAI AVP

   The Destination-NAI AVP (AVP Code 269) is of type String and MAY be
   included in a request or response message, and 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. This AVP SHOULD be used by intermediate proxies in the
   message routing process.

6.2  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 2,'s DIAMETER server issues
   a request to its broker, which in turn returns a response that
   includes the Result-Code AVP set to a specific value (see section
   5.2). When a response is received with such a value, the message MUST
   also include one or more Redirect-Host AVPs. These AVPs contain
   address information that SHOULD be used to directly communicate with
   the Home DIAMETER Server. Note that the servers MAY cache the home
   server information in order to reduce the latency involved in any
   future messages destined for that home server.

Calhoun et al.              expires May 2000                   [Page 30]

INTERNET DRAFT                                             December 1999

                             +------------------+ +---------+
                             |     DIAMETER     | | CRL DB/ |
                             |      Broker      | |  OCSP   |
                             +------------------+ +---------+
                      Request |  Response +
                              |  Result Code =
                              |  Redirect
                     +----------+              +----------+
                     |  |/            \|  |
                     | DIAMETER |--------------| DIAMETER |
                     |  Server  |\            /|  Server  |
                     +----------+    Direct    +----------+
          Figure 2: DIAMETER Broker Returning Redirect Indication

   When returning the response with the Result-Code set to indicate a
   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.

6.2.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 address information of
   the DIAMETER host to which the request must be redirected. Upon
   receipt of such a Result-Code, and this AVP, a DIAMETER host SHOULD
   send the request directly to the host. A proxy server or broker MAY
   return more than one Redirect-Host AVP if there is more than one
   DIAMETER server that can satisfy the request.

   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].

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

Calhoun et al.              expires May 2000                   [Page 31]

INTERNET DRAFT                                             December 1999

   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 does not have the scaling
   properties associated with a public key infrastructure (PKI), which
   is used in end-to-end security, but MAY be desirable in environments
   where asymmetric technology is not required, or available.

   Hop-by-Hop security implies that each hop along a proxy chain is
   responsible for the following tasks:

      - Validating the message's integrity using the shared secret with
        the sender.

      - Decrypting any encrypted AVPs using the secret shared with the

      - Re-encrypting AVPs using the secret shared with the next server.

      - Computing the message hash using the secret shared with the next
        server, and adding it to the ICV AVP in the DIAMETER message.

               (Shared-Secret-1)          (Shared-Secret-2)
      +------+       ----->      +------+      ------>      +------+
      |      |                   |      |                   |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+                   +------+                   +------+
            Figure 3: 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 very difficult 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 require
   strong authentication and/or confidentiality in a proxy environment
   SHOULD 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

Calhoun et al.              expires May 2000                   [Page 32]

INTERNET DRAFT                                             December 1999

   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 data and is
   used for hop-by-hop authentication and integrity, and is not
   recommended for use with untrusted proxy servers.

   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

   <DIAMETER Message> ::= <DIAMETER Header>
                          <Command-Code AVP>
                          [<Additional AVPs>]
                          <Timestamp AVP>
                          <Nonce 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

Calhoun et al.              expires May 2000                   [Page 33]

INTERNET DRAFT                                             December 1999

         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.

7.1.2  Encrypted-Payload AVP

   The Encrypted-Payload AVP (AVP Code 260) is of type data 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.

   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:

Calhoun et al.              expires May 2000                   [Page 34]

INTERNET DRAFT                                             December 1999

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

   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, using the same algorithm as
   above, 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.

7.3  Timestamp AVP

   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 time is the most
   significant four octets returned from an NTP server that indicates
   the number of seconds expired since Jan. 1, 1900.

   Messages which are older than a certain maximum age SHOULD be
   rejected and a response SHOULD be returned with the Result-Code AVP
   value set to DIAMETER_TIMEOUT.

   Note that the larger the 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.

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

Calhoun et al.              expires May 2000                   [Page 35]

INTERNET DRAFT                                             December 1999

   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].

8.2  Command Code AVP Values

   As defined in section 2.3.1, the Command Code AVPs (AVP Code 256)
   have 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 Designated Expert [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

Calhoun et al.              expires May 2000                   [Page 36]

INTERNET DRAFT                                             December 1999

   the value 1. All remaining values are available for assignment via
   Designated Expert [12].

8.6  Reboot-Type AVP Values

   Section 2.6.3 defines the Reboot-Type AVP (AVP Code 271), which is
   used to inform the peer of the cause for the reboot. This document
   defines the values 1-3. All remaining values are available for
   assignment via Designated Expert [12].

8.7  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
        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

      - 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.  More investigation on this subject is needed in order
        to determine if there exists any possibility for such attacks.

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

10.0  DIAMETER protocol related configurable parameters

Calhoun et al.              expires May 2000                   [Page 37]

INTERNET DRAFT                                             December 1999

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

      Device-Reboot-Ind Timer
         This timer is used to determine how long an implementation
         should issue another DRI message if no response is received.
         Default is 20 seconds.

      Device-Watchdog-Ind Timer
         This is the timer that determines the period of inactivity that
         must occur before a DWI is transmitted to the communicating
         peer. Default is 60 seconds, if DWI messages are sent.

      Receive Window
         The Receive window determines how many unacknowledged DIAMETER
         messages MAY be pending with a communicating peer. This is
         normally configured to a value that allows the node to
         effectively manage its receive buffers. Default is 7.

      Retransmission Timer
         The retransmission timer is the time period that a node will
         retransmit a message if no transport level acknowledgement was
         received. Default is 3 seconds.

      Maximum Retransmissions
         This is the maximum number of times a DIAMETER message will be
         retransmitted before it is determined that the communicating
         peer is no longer reachable.  Default is 3.

      Delayed Acknowledgement Timer
         This timer is defined in [25].

      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.
         There is no default.

      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.

11.0  Security Considerations

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

Calhoun et al.              expires May 2000                   [Page 38]

INTERNET DRAFT                                             December 1999

   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.

   When the DIAMETER protocol is used in an inter-domain network, strong
   application level security MAY be required, such as non-repudiation.
   This the communicating peers do require this level of security either
   for legal or business purposes, the extension defined in [11] MAY be

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
         Communications in a Public World", Prentice Hall, March 1995,
         ISBN 0-13-061466-1.
    [6]  Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
         Authentication", RFC 2104, January 1997.
    [7]  P. Calhoun, W. Bulley, "DIAMETER NASREQ Extension", draft-
         calhoun-diameter-nasreq-00.txt (work in progress), December
    [8]  Aboba, Beadles "The Network Access Identifier." RFC 2486.
         January 1999.
    [9]  Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-
         calhoun-diameter-framework-05.txt (work in progress), December
    [10] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions",
         draft-calhoun-diameter-mobileip-04.txt (work in progress),
         December 1999.
    [11] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
         Extension", draft-calhoun-diameter-strong-security-00.txt (work
         in progress), December 1999.
    [12] Narten, Alvestrand,"Guidelines for Writing an IANA
         Considerations 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.

Calhoun et al.              expires May 2000                   [Page 39]

INTERNET DRAFT                                             December 1999

    [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension",
         draft-calhoun-diameter-accounting-02.txt (work in progress),
         December 1999.
    [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
         Infrastructure Certificate and CRL Profile", RFC 2459, January
    [20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols",
         RFC 2477, January 1999.
    [21] M. Beadles, "Criteria for Evaluating Network Access Server
         Protocols", draft-ietf-nasreq-criteria-03.txt (work in
         progress), October 1999.
    [22] T. Hiller et al., "Cdma2000 Wireless Data Requirements for
         AAA", draft-hiller-cdma2000-AAA-00.txt (work in progress),
         October 1999.
    [23] S. Glass, S. Jacobs, C. Perkin, "Mobile IP Authentication,
         Authorization, and Accounting Requirements", draft-ietf-
         mobileip-aaa-reqs-01.txt (work in progress), October 1999.
    [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-00.txt (work in progress), December 1999.

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 and Glen Zorn

14.0  Author's Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun

Calhoun et al.              expires May 2000                   [Page 40]

INTERNET DRAFT                                             December 1999

      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

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

       Phone:  1-734-995-1697

      Haseeb Akhtar
      Wireless Technology Labs
      Nortel Networks
      2221 Lakeside Blvd.
      Richardson, TX 75082-4399

       Phone: 1-972-684-8850

      Erik Guttman
      Network and Security Research Center, Sun Laboratories
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025

       Phone:  49-7263-911-701

15.0  Full Copyright Statement

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

   This document and translations of it may be copied  and  furnished

Calhoun et al.              expires May 2000                   [Page 41]

INTERNET DRAFT                                             December 1999

   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 Inter- net organizations, except as needed
   for  the  purpose  of  developing 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 limited permis- sions 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  and

Calhoun et al.              expires May 2000                   [Page 42]