AAA Solutions
draft-ietf-aaa-solutions-01

Versions: 00 01                                                         
INTERNET DRAFT                                                Jari Arkko
Category: Informational                                Oy LM Ericsson Ab
Title: draft-ietf-aaa-solutions-01.txt                    Pat R. Calhoun
Date: November 2000                                         Erik Guttman
                                                  Sun Microsystems, Inc.
                                                             Dave Nelson
                                                Enterasys Networks, Inc.
                                                            Barney Wolff
                                                            Databus Inc.


                             AAA Solutions



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at:

      http://www.ietf.org/ietf/1id-abstracts.txt

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

      http://www.ietf.org/shadow.html.

   This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the diameter@diameter.org and aaa-wg@merit.edu
   mailing lists.

   Distribution of this memo is unlimited.

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


Abstract




Calhoun et al.              expires May 2001                    [Page 1]


INTERNET DRAFT                                             November 2000


   The AAA Design Team has issued a document that lists issues with the
   DIAMETER protocol. This accompanying document is intended as an archive
   of proposed solutions. Once accepted, these solutions will find their
   way into the relevant DIAMETER specifications.


Table of Contents

      1.0  Introduction
            1.1  Requirements language
      2.0  Error Codes and Messages
            2.1  Result-Code AVP
            2.2  Error-Message AVP
      3.0  Accounting
            3.1  Universal Approach
                  3.1.1  Base Accounting Protocol Layer
                  3.1.2  Application Specific Accounting Layer
            3.2  Batch Accounting
            3.3  Proxy Accounting Issues
            3.4. Semantics Issues
            3.5  Bloat Issues
            3.6  Format Issues
      4.0  IPv6 Support
            4.1  NAS-IPv6-Address
            4.2  Login-IPv6-Host
            4.3  Framed-Interface-Id
            4.4  Framed-IPv6-Prefix
            4.5  Framed-IPv6-Route
      5.0  Transports
            5.1  Failover & Recovery Sending
      6.0  Proxies
            6.1  Realm-Based Message Routing
            6.2  Behavior of Proxy and Redirect Servers
                  6.2.1  Proxy and Redirect Server handling of requests
            6.3  Redirect Server
                  6.3.1  Redirect-Host AVP
                  6.3.2  Redirect-Host-Port AVP
            6.4  Proxy Server
                  6.4.1  Proxying Requests
                  6.4.2  Proxying Responses
                        6.4.2.1  Route-Record AVP
                        6.4.2.2  Proxy-State AVP
                        6.4.2.3  Home-Realm AVP
            6.5  Applying Local Policies
            6.6  Hiding Network Topology
      7.0  RADIUS Compatibility
      8.0  End-to-End Security
      9.0  Data Model



Calhoun et al.              expires May 2001                    [Page 2]


INTERNET DRAFT                                             November 2000


            9.1  Separability of DIAMETER Header and Message
            9.2  Data Types supported in DIAMETER
            9.3  Formal notation for application specific data types
            9.4  Ordering of Data
            9.5  Semantics of the "M" bit
      10.0 SNMP Support (DIAMETER MIB)
      11.0 Re-Authentication & Authorization
      12.0 Server/Resource Management State
            12.1  Loose Consistency
            12.2  Tight Consistency
      13.0 Access Rules and Filters
            13.1  Filter-Rule AVP
            13.2  Non-IP Filters
      14.0 AAA Server Discovery
            14.1 AAA Service Template
      15.0 Loop Detection
            15.1  Loop Detection
      16.0 IANA Considerations
      17.0 Security Considerations
      18.0 Acknowledgments
      19.0 References
      20.0 Authors' Addresses
      21.0 Full Copyright Statement
      Appendix A - DIAMETER Data Dictionary XML DTD



























Calhoun et al.              expires May 2001                    [Page 3]


INTERNET DRAFT                                             November 2000


1.0  Introduction

   The AAA Design Team has issued a document that lists issues with the
   DIAMETER protocol [11]. This accompanying document is intended as an
   archive of proposed solutions. Once accepted, these solutions will
   find their way into the relevant DIAMETER specifications.

   Each main section should specify which DIAMETER documents its sub-
   sections are targetted at. Ideally, the section should also state
   whether the proposed text is intended to replace existing text, or
   added as new text.


2.0  Error Codes and Messages

   Section 2.1 below is intended to replace the current section 5.2 in
   the Base Protocol [1] specification. Section 2.2 is intended as a new
   section 5.3 in the Base Protocol [1].

   The existing Base Protocol defines the Result-Code AVP to be of type
   Complex, while the following section defines the Result-Code AVP to
   be of type Integer, and a separate Error-Message AVP of type String.


2.1  Result-Code AVP

   The Result-Code AVP (AVP Code 268) is of type Integer 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.

   The Result Code field contains an IANA-managed 32-bit address space
   representing errors (see section 8.4). The DIAMETER provides five
   different classes of errors, all identified by the thousands digit:
      - 1xxx (Informational)
      - 2xxx (Success)
      - 3xxx (Redirect Notification)
      - 4xxx (Transient Failures)
      - 5xxx (Permanent Failure)


2.1.1  Informational

   Errors that fall within the Informational category are used to inform
   a requestor that the request cannot be immediately satisfied and a
   further response will be issued in the near future.

      DIAMETER_BE_PATIENT                1001



Calhoun et al.              expires May 2001                    [Page 4]


INTERNET DRAFT                                             November 2000


         The DIAMETER server responsible for authentication and/or
         authorizing the user cannot satisfy the request at the moment,
         and will respond within the next 3 seconds.


2.1.2  Success

   Errors that fall within the Success category are used to inform a
   peer that a request has been successfully completed.

      DIAMETER_SUCCESS                   2000
         The Request was successfully completed.


2.1.3  Redirect Notification

   Errors that fall within the Redirect Notification category are used
   to inform a peer that the request cannot be satisfied locally and
   should instead be forwarded to another server.

      DIAMETER_REDIRECT_INDICATION       3001
         A proxy or redirect server 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.


2.1.4  Transient Failures

   Errors that fall within the transient failures category are used to
   inform a peer that the request could not be satified at the time it
   was received, but MAY be able to satisfy the request in the future.

      DIAMETER_TIME_INVALID              4001
         This Result-Code value is return to inform a peer that the
         message received contained an invalid timestamp value (in
         Timestamp AVP).

      DIAMETER_AUTHENTICATION_REJECTED   4002
         The authentication process for the user failed, most likely due
         to an invalid password used by the user. Further attempts MUST
         only be tried after prompting the user for a new password.

      DIAMETER_AUTHORIZATION_FAILED      4003
         A request was received for which the user could not be
         authorized at this time. This error could occur when the user
         has already expended allowed resources, or is only permitted to



Calhoun et al.              expires May 2001                    [Page 5]


INTERNET DRAFT                                             November 2000


         access services within a time period.

      DIAMETER_UNABLE_TO_DELIVER         4004
         The request could not be delivered to a host that handles the
         realm requested at this time.

      DIAMETER_NO_END_2_END_SECURITY     4005
         A proxy has detected that end-to-end security has been applied
         to portions of the DIAMETER message, and the proxy does not
         allow this security mode since it needs to alter the message by
         applying some local policies.

      DIAMETER_CONTRADICTING_AVPS        4006
         The Home DIAMETER server has detected AVPs in the request that
         contradicted each other, and is not willing to provide service
         to the user. One or more Failed-AVP MUST be present, containing
         the AVPs that contradicted each other.


2.1.5  Permanent Failures

   Errors that fall within the permanent failures category are used to
   inform the peer that the request failed, and should not be attempted
   again.

      DIAMETER_USER_UNKNOWN              5001
         A request was received for a user that is unknown, therefore
         authentication and/or authorization failed.

      DIAMETER_COMMAND_UNSUPPORTED       5002
         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
         Command-Code.

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

      DIAMETER_REALM_NOT_SERVED          5004
         A proxy or redirect server has determined that it is unable to
         forward the request or provide redirect information since the
         realm portion of the NAI requested is unknown.

      DIAMETER_UNSUPPORTED_TRANSFORM     5005
         A message was received that included an Integrity-Check-Value



Calhoun et al.              expires May 2001                    [Page 6]


INTERNET DRAFT                                             November 2000


         or CMS-Data AVP [11] that made use of an unsupported transform.

      DIAMETER_UNKNOWN_SESSION_ID        5006
         The request or response contained an unknown Session-Id.

      DIAMETER_AUTHORIZATION_REJECTED    5007
         A request was received for which the user could not be
         authorized.  This error could occur if the service requested is
         not permitted to the user.

      DIAMETER_INVALID_AVP_VALUE         5008
         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               5009
         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.

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

      DIAMETER_LOOP_DETECTED             5011
         A Proxy or Redirect server detected a loop while trying to get
         the message to the Home DIAMETER server. Further attempts
         should not be attempted until the loop has been fixed.


2.2  Error-Message AVP

   The Error-Message AVP (AVP Code 281) is of type String and MAY be
   present if the message also contains a non-successful Result-Code
   AVP. The AVP MUST contain a human readable error message. The Error-
   Message AVP is not intended to be useful in real-time, and SHOULD NOT
   be expected to be parsed by network entities.


3.0  Accounting

   This section contains the solutions for the Accounting related
   issues, described in [11]. The following issues do not yet have any
   proposed solutions:
      - Where to place ADIF applicability statements
      - Whether to strongly secure at all



Calhoun et al.              expires May 2001                    [Page 7]


INTERNET DRAFT                                             November 2000


      - Multi-party trust, counter signatures etc in a broker proxy
        environment.
      - Accounting-State/Accounting-Status-Ind issues from section 3.4
      - Issues with polling


3.1  Universal Approach

   This section describes a new structure of the accounting
   specification [6] in order to clarify what DIAMETER nodes need to
   support in different environments. If accepted, the accounting
   specification is split to several documents

   A two-layer approach is proposed. On the base protocol layer, the
   basic accounting messages and AVPs are defined. On the application
   extension layer, the specific applications define their specific
   requirements on what data is included in the accounting records, when
   the records are produced, and what specific parts of the base
   accounting protocol must be used in the particular application. For
   instance, the Mobile IP DIAMETER extension [4] could specify its
   requirements on what specific attribute values are required within
   the ADIF records, which events should produce records, and whether
   strong security is required. The application extension layer should
   be documented in the corresponding application extension document,
   such as the DIAMETER Mobile IP extension.

   The base accounting protocol layer is documented in the same manner
   as the current draft [6] stands. However, it is proposed that the
   parts which are mandatory and optional are clearly marked.  Right now
   everything in the base accounting protocol as mandatory, leading to
   unnecessary complexity for applications that do not require all the
   baggage. The purpose of specifying optional parts is to provide a
   simple accounting base protocol that can be easily implemented, while
   also supporting more complex applications in optional parts.

   Furthermore, batch accounting functionality is removed from the
   accounting protocol. Of course, operational experience and/or new
   requirements may later lead to the introduction of a DIAMETER batch
   accounting extension as well.

   The following new structure for the DIAMETER accounting protocol is
   therefore proposed.


3.1.1  Base Accounting Protocol Layer

   The current accounting protocol specification [6] is logically
   organized to the following parts, each with a different extension



Calhoun et al.              expires May 2001                    [Page 8]


INTERNET DRAFT                                             November 2000


   number:

      - Accounting-Base (Mandatory)

        This is the basic operations: Accounting-Request, Accounting-
        Answer, Accounting-Status-Ind as well as the AVPs Record-Type,
        ADIF-Record, Record-Number, State, and Interim-Interval would be
        contained here.

        The messages specified in [6] are modified to no longer require
        strong security, i.e.  the CMS-Data AVPs in the messages are
        made optional.

        Support for this protocol provides real-time accounting support
        of single record/message, as well as Interim accounting. It is
        extremely simple to implement.

        The elimination of several records makes many things easier e.g.
        splitting of Accounting-Answers through proxies is no longer a
        problem.

      - Polling (Optional)

        This contains Accounting-Poll-Ind and related functionality.
        This extension can only be used between consenting servers in a
        non-roaming situation due to the scalability problems involved
        in a global polling scenario.


3.1.2  Application Specific Accounting Layer

   All DIAMETER extensions MUST have an Accounting Considerations
   section. The following information MUST be present in the section:

      - Whether accounting is required by the application
      - Which application specific events cause the production of an
        accounting record
      - What data, and in which format, is included in the accounting
        records.
      - Applicability statement regarding how ADIF is used for this
        particular application
      - Which parts of the base accounting protocol layer are required
        and optional in this particular application

   [Note that the application specific accounting can not have an own
   extension number since otherwise the accounting messages could not be
   transmitted through proxies not having special support for this
   particular kind of application.]



Calhoun et al.              expires May 2001                    [Page 9]


INTERNET DRAFT                                             November 2000


3.2  Batch Accounting

   Batch accounting is removed from the protocol.  The reasons for this
   recommendation are as follows:

      1. For low granularity of batching, i.e. on the order of a second
         or two, the underlying network transport layer may provide
         sufficient batching properties, via "nageling" such that small,
         inefficient packet sizes are avoided.

      2. For high granularity of batching, i.e. many minutes or hours,
         FTP may be a more appropriate protocol for the transfer of
         accounting data.

      3. Proxy operations, in which the DIAMETER client sends accounting
         data to the first hop proxy, for a co-mingled collection of
         ultimate destinations, i.e. home accounting servers, is
         problematic.  If the proxy server has forwarded accounting
         records to multiple destinations, based in NAI, and one or more
         of those accounting servers is not responding, the proxy server
         has no reasonable way to inform the DIAMETER client that only
         part of the accounting data has been acknowledged.  This
         potentially creates a head of line blocking problem.  The
         proxy's Accounting-Answer will need to be delayed until an
         Accounting-Answer is received for *all* of the records in the
         batch. This in turn will require more NAS non-volatile storage,
         at exactly the time when that storage is likely to be filling
         up.  Allowing for only "real time" accounting, in which there
         are no co-mingled destinations, solves this problem.

      4. The added complexity of batch accounting seems to outweigh its
         possible benefits.


3.3  Proxy Accounting Issues

   The complete removal of batch accounting functionality removes the
   problems in dealing with partial Accounting-Answer messages.

3.4. Semantics Issues

   A new transient error code is proposed in order to optimize retry
   behaviour in an out-of-disk-space situation:

      DIAMETER_OUT_OF_SPACE           4007
         A DIAMETER node received the accounting request but was unable
         to commit it to stable storage due to a temporary lack of
         space.



Calhoun et al.              expires May 2001                   [Page 10]


INTERNET DRAFT                                             November 2000


3.5  Bloat Issues

   Given that section 3.1. above proposed that CMS-Data AVPs be made
   optional, it is further proposed that the ADIF-Record AVP is only
   included in Accounting-Answer if the CMS-Data AVP is. This would
   remove the bloat in environments that do not require strong security.

   Therefore, it is proposed that the Accounting-Answer command be
   changed as follows:

      <Accounting-Answer> ::= <DIAMETER Header, Command-Code = 272>
                              <Result-Code AVP>
                              <Host-Name AVP>
                              <Destination-NAI AVP>
                              <Grouped-AVP {
                                   <Session-Id AVP> &&
                                   <Accounting-Record-Number> &&
                                   [<ADIF-Record AVP> &&
                                   <CMS-Data AVP>]
                              }
                              [<Timestamp AVP>
                               <Nonce AVP>
                               <Integrity-Check-Value AVP>]

   The AVPs ADIF-Record and CMS-Data MUST be present if and only if
   CMS-Data AVP was present in the corresponding Accounting-Request
   command. Therefore, if the CMS-Data AVP was not present in the
   request, none of the accounting data from the record would be copied
   to the answer. Only the Session-Id and Accounting-Record-Number AVPs
   would be returned in order to correlate the answer to the request.

   Typically, a service provider's DIAMETER proxy would add CMS-Data
   AVPs to accounting requests where the business relationships call for
   strong security and/or non-repudiation of accounting data.


3.6  Format Issues

   Given that section 3.1. above requires accounting considerations
   specification for each application, and requires an ADIF
   applicability statement in that specificaion.

   It is proposed that ADIF continues as the only DIAMETER accounting
   record format to maximize interoperability. However, the new
   structure of the accounting specification allows the IETF to later
   revisit this decision if it proves necessary to provide other formats
   for special applications.




Calhoun et al.              expires May 2001                   [Page 11]


INTERNET DRAFT                                             November 2000


4.0  IPv6 Support

   The AAA Issues [11] document described an issue where the IPv6
   attributes defined in the RADIUS protocol [21] MUST be supported by
   the DIAMETER protocol. Each RADIUS attribute is listed in this
   section and the recommended DIAMETER protocol change to support this
   functionality. When a change is recommended to the protocol the
   section will contain the actual text to be included in [2].


4.1  NAS-IPv6-Address

   The DIAMETER base protocol [1] defines the Host-IP-Address AVP to be
   of type Address, which can contain both IPv4 and IPv6 addresses. A
   protocol gateway server will have to identify the address type in the
   Host-IP-Address AVP and insert the value in the RADIUS attribute that
   corresponds to the IP version number.


4.2  Login-IPv6-Host

   The DIAMETER NASREQ extension [2] defines the Login-IP-Host AVP to be
   of type Address, which can contain both IPv5 and IPv6 addresses. A
   protocol gateway server will have to identify the address type in the
   Login-IP-Host AVP and insert the value in the RADIUS attribute that
   corresponds to the IP version number.


4.3  Framed-Interface-Id

   The Framed-Interface-Id AVP (AVP Code TBD) is of type Integer64 and
   contains the IPv6 interface identifier to be configured for the user.


4.4  Framed-IPv6-Prefix

   The Framed-IPv6-Prefix AVP (AVP Code TBD) is of type Address and
   contains the IPv6 prefix to be configured for the user.


4.5  Framed-IPv6-Route

   The Framed-IPv6-Route AVP (AVP Code TBD) is of type String and
   contains the routing information to be configured for the user on the
   NAS.  Zero or more such AVPs MAY be present in an authorization
   response.

   For IPv6 routes, it SHOULD contain a destination prefix optionally



Calhoun et al.              expires May 2001                   [Page 12]


INTERNET DRAFT                                             November 2000


   followed by a slash and a decimal length specifier stating how many
   high order bits of the prefix to use. That is followed by a space, a
   gateway address, a space, and one or more metrics separated by
   spaces.

   Whenever the gateway address is specified as zero the IP address of
   the user SHOULD be used as the gateway address.


5.0  Transports

   With the exception of section 5.1, DIAMETER transport is For Further
   Study (FFS). However, the work items that have been identified by the
   Design Team are:

      1. Is TCP appropriate as a MAY?
      2. What are the Proxy behavior requirements for congestion control
         under SCTP?
      3. Is UDP a valid transport mapping?


5.1  Failover & Recovery Sending

   When DIAMETER is run over a connection-oriented transport layer that
   reacts sufficiently quickly to endpoint failure, a DIAMETER peer MAY
   rely on a failure indication from the transport.  If not, the
   DIAMETER peer SHOULD implement its own algorithm to determine peer
   failure.

   In either case, if the DIAMETER implementation originates requests,
   and has a backup peer configured or can discover one, it SHOULD send
   new requests to the backup peer.  During this time, it SHOULD monitor
   the primary peer for possible recovery.  When DIAMETER is run over a
   connection-oriented transport, the originator of the failed
   connection SHOULD periodically attempt to re-establish the transport
   connection.  When DIAMETER is run over a connectionless transport,
   the only way to determine peer recovery is to send a dummy request.
   [[Such a NOP request needs to be defined.]]  A typical interval for
   attempts to discover primary peer recovery might be 60 seconds, but a
   longer randomized interval is advisable where the number of clients
   of a single server is large, to avoid overwhelming the server as it
   recovers.

   The health of a backup peer SHOULD also be monitored, even when it is
   not needed to satisfy live requests.  Murphy's law implies that a
   backup that has not been monitored will surely be found to have
   failed or been misconfigured when it is most needed.




Calhoun et al.              expires May 2001                   [Page 13]


INTERNET DRAFT                                             November 2000


6.0  Proxies

   This section contains text that is intended to replace all of section
   6 in the DIAMETER Base protocol [1]. This section contains
   clarifications on the expected behavior of DIAMETER proxies and
   redirect servers, and also introduces new AVPs.


6.1  Realm-Based Message Routing

   DIAMETER Message routing is done through the use of the realm portion
   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.

   There are instances where the User-Name AVP is not present in
   authorization requests. This is typically true in networks where a
   request is sent to the network before the call was even answered.
   However, such requests MAY need to be proxied. In such cases, the
   first hop DIAMETER proxy MUST append the Home-Realm AVP to the
   DIAMETER message, by using a DNIS or ANI to Home-Realm association
   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: Realm-Based Routing



Calhoun et al.              expires May 2001                   [Page 14]


INTERNET DRAFT                                             November 2000


6.2  Behavior of Proxy and Redirect Servers

   This section describes the behavior of DIAMETER proxy and redirect
   servers in detail. In both cases, determining the next hop for a
   DIAMETER message is done via the Home-Realm or the User-Name AVP [1],
   whose syntax must comply with the Network Access Identifier (NAI)
   [12] specification.  When present, the Home-Realm takes precedence
   over the User-Name AVP for routing decisions. The Home-Realm AVP, or
   the realm portion of the User-Name AVP is used to identify the next
   hop server the message must be forwarded to.

   Note the processing rules contained in this section are intended to
   be used as general guidelines to DIAMETER developers. Certain
   implementations MAY use different methods than the ones described
   here, and still be in compliance with the protocol specification.


6.2.1  Proxy and Redirect Server handling of requests

   Any request received by a DIAMETER server MUST perform a next hop
   lookup.  Lookups are performed against what is commonly known as the
   Domain Routing Table (see section 10.0). A Domain Routing Table Entry
   contains the following fields:
      - Domain Name. The Domain Name is analogous to the realm portion
        of the NAI.  This is the field that is typically used as a
        primary key in the routing table lookups. Note that some
        implementations perform their lookups based on longest-match-
        from-the-right on the realm rather than requiring an exact
        match.
      - Extension Id. It is possible for a routing entry to have a
        different destination based on the extension identifier of the
        message. This field is typically used as a secondary key field
        in routing table lookups.
      - Local Action. The Local Action field is used to identify how a
        message should be treated. The following actions are supported:
           1. LOCAL - DIAMETER messages that resolve to a routing entry
              with the Local Action set to Local can be satisfied
              locally, and do not need to be forwarded to another
              server.
           2. PROXY - All DIAMETER messages that fall within this
              category MUST be forwarded to a next hop server. The local
              server MAY apply its local policies to the message by
              including new AVPs to the message prior to forwarding.
              See section 6.4 for more information.
           3. REDIRECT - DIAMETER messages that fall within this
              category MUST have the identity of the home DIAMETER
              server(s) appended, and returned to the sender of the
              message. See section 6.3 for more information.



Calhoun et al.              expires May 2001                   [Page 15]


INTERNET DRAFT                                             November 2000


           4. OTHER - If anyone has any ideas, please let me know what
              an "other" really is.
      - Server Identifier - One or more servers the message is to be
        forwarded to.  When the Local Action is set to PROXY, this field
        contains the identities of the server the message must be
        forwarded to. When the Local Action field is set to REDIRECT,
        this field contains the Home DIAMETER server(s) for the realm.

   It is important to note that DIAMETER servers MUST support at least
   one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do
   not need to support all modes of operation in order to conform with
   the protocol specification.  Server MUST NOT reorder AVPs with the
   same AVP Code.


6.3  Redirect Server

   A Redirect Server is one that provides NAI Realm to DIAMETER Home
   Server address resolution. When a message is received by a peer, the
   Home-Realm or the realm portion of the User-Name AVP is extracted
   from the message, and the realm portion is used to perform a lookup
   in the domain routing table.  Implementations SHOULD also use the
   Extension Id as a secondary key in the domain routing table lookup.

   Successful routing table lookups will return one or more home
   DIAMETER server that could satisfy the message. The home servers are
   encoded in one or more Redirected-Host, and optional Redirect-Host-
   Port AVPs [1]. In the event that more than one such home server is
   returned, each AVP pair MUST be encapsulated within a Grouped-AVP.

                             +------------------+
                             |     DIAMETER     |
                             | Redirect Server  |
                             +------------------+
                              ^    |
                      Request |    | Response +
                  joe@xyz.com |    | Result Code =
                              |    | Redirect
                              |    v
                            +----------+   Request    +----------+
                            | abc.net  |------------->| xyz.net  |
                            | DIAMETER |              | DIAMETER |
                            |  Server  |<-------------|  Server  |
                            +----------+   Response   +----------+
                    Figure 4: DIAMETER Redirect Server

   Lastly, the Result-Code AVP is added with the value of the AVP set to
   DIAMETER_REDIRECT_INDICATION [1], and the message is returned to the



Calhoun et al.              expires May 2001                   [Page 16]


INTERNET DRAFT                                             November 2000


   sender of the request. Redirect servers MAY also include the
   certificate of the Home server(s). These certificates are
   encapsulated in a CMS-Data AVP [11].  When this occurs, the server
   forwarding the request directly to the Home DIAMETER server SHOULD
   include its own certificate in the message.


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
   of such a Result-Code, and this AVP, a DIAMETER host SHOULD send the
   request directly to one of the hosts.


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.


6.4  Proxy Server

   This section outlines the processing rules for DIAMETER proxy
   servers.  A proxy server can either be stateful or stateless. A Proxy
   server MAY act in a stateful manner for some requests, and be
   stateless for others. There are two types of states that servers MAY
   wish to maintain; transaction and session.

   Maintaining transaction state implies that a server keeps a copy of a
   request, which is then used when the corresponding response is
   received.  This could be done to apply local policies to the message,
   or simply for auditing purposes. Maintaining session state implies
   that a server keeps track of all "active" users. An active user is
   one that has been authorized for a particular service, and the server
   has not received any indication that the user has relinquished
   access.

   A stateless proxy is one that does not maintain transaction, nor
   session state. It frees the messages sent once acknowledgements are
   received by the transport layer.



Calhoun et al.              expires May 2001                   [Page 17]


INTERNET DRAFT                                             November 2000


   A stateful proxy can be viewed as a DIAMETER Server upon receiving a
   request, and as a Client when forwarding the message. For all
   intensive purposes, stateful servers terminate an upstream "session",
   and initiates a downstream "session" (see figure x), and MAY provide
   the following features:
      - Protocol translation (e.g. RADIUS <-> DIAMETER)
      - Limiting resources authorized to a particular user
      - Per user or transaction auditing

        +--------+           +-----------------+          +--------+
        | Client | --------> | Server | Client | -------> | Server |
        +--------+           +-----------------+          +--------+
                     Figure x - Example of Stateful Proxy

   A stateful proxy that maintains transaction state SHOULD release
   transaction information after a request's corresponding response has
   been forwarded towards the recipient, and has been acknowledged by
   the underlying transport.

   A stateful proxy that maintains session state SHOULD release the
   session state once it is informed that a user and/or device is has
   relinquished access.

   Home servers processing requests that include the Route-Record and/or
   the Proxy-State AVPs MUST return these AVPs in the same order in the
   corresponding response.


6.4.1  Proxying Requests

   A proxy server MUST check for forwarding loops before proxying a
   request.  A request has been looped if the server finds its own
   address in a Route-Record AVP (see [1] for more information on loop
   detection).

   A DIAMETER server that proxies a request MUST append a Route-Record
   AVP, which includes its identity. DIAMETER Servers that receive
   messages MUST validate the last Route-Record AVP in the message and
   ensure that the host identified in the AVP is the same as the sender
   of the message.

   A Proxy Server MAY also include the Proxy-State AVP, which is used to
   encode local state information. The Proxy-State AVP is guaranteed to
   be present in the corresponding response. If the Proxy-State AVP is
   present, both the Route-Record and the Proxy-State AVPs MUST be
   encapsulated within the Grouped-AVP AVP.

   The message is then forwarded to the downstream DIAMETER server, as



Calhoun et al.              expires May 2001                   [Page 18]


INTERNET DRAFT                                             November 2000


   identified in the Domain Routing Table.


6.4.2  Proxying Responses

   A proxy server MUST only process responses whose last Route-Record
   AVP matches one of its addresses. Any responses that do not conform
   to this rule MUST be dropped. The last Route-Record AVP MUST be
   removed from the message before it is forwarded to the next hop,
   which is identified by the second to last Route-Record AVP.


6.4.2.1  Route-Record AVP

   The Route-Record AVP (AVP Code 282) is of type String, and contains
   the Fully Qualified Domain Name of the Proxy appending the AVP to a
   DIAMETER message.


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


6.4.2.3  Home-Realm AVP

   The Home-Realm AVP (AVP Code 283) is of type String and contains the
   realm portion of the Network Access Identifier. When present, the
   Home-Realm AVP MUST be used to perform any message routing decisions.


6.5  Applying Local Policies

   Proxies MAY apply local access policies to DIAMETER requests, or
   responses, by adding, changing or deleting AVPs in the messages.
   Proxies that apply local policies MUST NOT allow end-to-end security
   on any messages that traverse through it, unless security is
   terminated locally.

   A proxy wishing to modify a DIAMETER message to enforce some local
   policy that detects that end-to-end security has been applied to the
   message MUST return a reponse to the originator with the Result-Code
   set to DIAMETER_NO_END_2_END_SECURITY.  The originator of the request
   MAY re-issue the request with no end-to-end security if it falls



Calhoun et al.              expires May 2001                   [Page 19]


INTERNET DRAFT                                             November 2000


   within its local policy.

   In the event that the Home DIAMETER server receives a request with
   contradictory information (possibly due to some proxy adding a local
   policy), it MAY accept the latest AVP, or MAY return the response
   with the Result Code AVP set to DIAMETER_CONTRADICTING_AVPS. However,
   a NAS receiving a response that contains contradictory information
   SHOULD reject service to the user.


6.6  Hiding Network Topology

   Stateful proxies forwarding requests to servers outside of their
   administrative domain MAY hide the internal network topology. Servers
   perform this by removing all Route-Record AVPs in the message, and
   maintains the Route-Record AVPs to add to the corresponding response.
   Such stateful servers MUST still add their own Route-Record AVP to
   the request prior to forwarding.


7.0  RADIUS Compatibility

   The AAA Design Team has concluded that the protocol gateway
   procedures described in [x] is the correct approach. The procedures
   need to be validated to confirm that no errors exist.

   It is possible that a new RADIUS attribute and DIAMETER AVP could be
   created and included when protocol translation occurs. This could be
   useful for troubleshooting purposes, but would have virtually no
   real-time benefits.


8.0  End-to-End Security

   The DIAMETER Strong Security extension currently ONLY supports CMS in
   an asymmetric mode. It has been brought to the WGs attention that not
   all transactions require this level of security. The following
   additional security mechanisms need to be evaluated, and incorporated
   into the DIAMETER protocol (if they are deemed appropriate):

      1. Symmetric CMS mode [22]. This allows for keys to be exchanged
         by DIAMETER peers via the CMS security system. However, it is
         not clear how such peers would agree on the keying material
         prior to the normal DIAMETER message flows. Further
         investigation is required.
      2. Kerberos has been proposed as an alternative to establish
         dynamic security assocations (keying material) between DIAMETER
         peers. Further investigation needs to be completed before a



Calhoun et al.              expires May 2001                   [Page 20]


INTERNET DRAFT                                             November 2000


         determination can be made.


9.0 Data Model

   The sections which follow correspond to those in [11].  The data
   model 'solutions' address those issues which were identified in that
   document or recommend that these issues are better left unaddressed
   for now.


9.1  Separability of DIAMETER Header and Message

   Suggestion:  Use the DIAMETER message header Flags field, which is
   currently reserved.  Assign the following flags.

      0x04 ('E' Expect Reply) The message solicits a response.
      0x02 ('I' Interrogation) The message is a Query or a Reply.
      0x01 ('R' Response) The message is a response another message.

   The following describes all combinations and their interpretation.

      - - -    The message is an Indication
      - - R    Not allowed.
      - I -    Not allowed.
      - I R    Not Allowed.
      E - -    The message is a Request.
      E - R    The message is an Answer.
      E I -    The message is a Query.
      E I R    The message is a Reply.

   By examining these flags, even if a DIAMETER extension is not
   supported, it will still be clear what *kind* of DIAMETER message
   follows.  Carrying this information in the message header separates
   the base protocol from the payload data.  This has been shown to be
   useful in other protocols which are extensible and carry otherwise
   opaque data, such as SNMP. [19] The operation identifier can be used
   for logging, security policies, etc.

   It is not clear in the current text why there is a 'Request/Answer'
   and is the result of the command.  A 'Query' obtains some data which
   is returned in the 'Reply,' but no action is taken.  Text clarifying
   the difference should be included in the base protocol specification.


9.2  Data Types supported in DIAMETER

   The base data types in the current DIAMETER specification include



Calhoun et al.              expires May 2001                   [Page 21]


INTERNET DRAFT                                             November 2000


      Data, String, Address, Integer32, Integer64, Time and Complex.

   It is recommended that this list be changed to:

      Address, Integer32, Unsigned32, Integer64, Unsigned64, Float32,
      Float64, Float128, OctetString, Grouped and List.

   It is thuse recommended that the following data types no longer be
   supported:

      String, Time and Complex.

   Data will now be used for any piece of data - including a String.

   Address is defined as in [1].

   Unsigned32 is an unsigned 32 bit integer.  Integer32 is a signed 32
   bit integer.  Unsigned32 replaces Time.

   Unsigned64 is an unsigned 64 bit integer.  Signed64 is a signed 64
   bit integer.

   Float32 is a 32 bit IEEE floating point number.  Float64 is a 64 bit
   IEEE floating point number.  Float128 is a 128 bit IEEE floating
   point number.

   Group is a specific sequence of other data elements, each with their
   own type, defined in a particular AVP.  For example, a group could be
   comprised of the data element of the following sequence:

      {Foo AVP, Bar AVP}

   A data element of this Group type MUST include both of these
   components, in the order specified.  A Group is represented on the
   wire simply as each AVP is defined - one after the other.  The Group
   type is analogous to an ASN.1 SEQUENCE [20].

   List is a collection of 0 or more data elements of the same type.
   For example, one could have a List of Foo AVPs.  A List is
   represented on the wire as an Unsigned32 value 'n' (which is set to
   the number of AVPs which follow.)  The next 'n' AVPs which follow
   MUST be the type assigned by the DIAMETER Extension.  In the case of
   this example, they would all be Foo AVPs.  Note that the order of the
   data elements in the List is arbitrary (the list is not assumed to be
   sorted).  The List type is analogous to an ASN.1 SET.

   All quantities (address, signed, unsigned and floating point) are
   represented in network byte order.



Calhoun et al.              expires May 2001                   [Page 22]


INTERNET DRAFT                                             November 2000


   Correct interpretation of the data element requires knowledge of the
   specific DIAMETER extension in which the AVP is defined.  For
   example, Data could be anything - including a String.  Unsigned32
   could be any quantity - including Time.  String and Time data values
   are not supported explicitely, according to this recommendation.
   Instead, they are implicit in a specific AVP definition.


9.3  Formal notation for application specific data types

   Specific data type notations are in the process of being defined in
   separate documents (one example is provided in Appendix A).  This is
   recommended for the following purposes:

      - Allow extensible functionality for DIAMETER implementations,
        such as storage and type checking of new AVP types, without
        requiring new code,
      - Allow extensible functionality for packet sniffers, debuggers
        management tools and human interfaces potentially without adding
        new code.

   The formal notation is NOT intended to be used for the following
   purposes:

      - As the definitive 'on-the-wire data representation'
        specification for specific AVPs
      - As the definitive interpretation of the semantics of specific
        AVPs

   In both cases, implementors must use the relevent DIAMETER Extension
   RFC where the DIAMETER AVP is defined.


9.4  Ordering of Data

   Each AVP is self-describing (in the AVP header).  It is possible for
   a DIAMETER implementation to accumulate all AVPs in a message without
   requiring the AVPs to be strictly ordered in the message.

   There is a trade-off between simplicity and flexibility.  Flexibility
   has shown itself useful in DIAMETER and RADIUS implementations in the
   past.  It is not wise to impose arbitrary restrictions on protocols
   when they do not significantly simplify or result in better
   interoperability of protocol implementations.  The recommendation is
   to not require strict ordering of AVPs within a message, except where
   this is required by a Group or List data type, as described in
   Section 9.2.




Calhoun et al.              expires May 2001                   [Page 23]


INTERNET DRAFT                                             November 2000


9.5  Semantics of the "M" bit

   Some confusion has been expressed over the "M" bit in the header of
   DIAMETER AVPs.  Concerns has been expressed about applicability of
   the "M" bit to non-IETF standard AVPs.


9.5.1  What does it mean?

   The appropriate interpretation of the semantics of the "M", or
   mandatory, flag bit for DIAMETER AVPs is that the associated AVP is
   considered crucial to correct and secure delivery of the service
   specified by the collection of AVPs in a DIAMETER message.  Proxies
   MUST NOT eliminate or modify the AVP and clients MUST NOT discard or
   fail to enforce the AVP.


9.5.2  From whose perspective?

   The DIAMETER peer that sets an "M" bit on an AVP does so because
   there is a local policy that indicates that the AVP in question is
   crucial to the correct or secure provision of the service.  These
   local policies are typically based on business requirements, rather
   than protocol or network operations requirements. AVPs with the "M"
   bit set are not "negotiable" by other DIAMETER peers.


9.5.3  What are correct error responses?

   If a DIAMETER peer receives an AVP with the "M" bit set, and it does
   not recognize the AVP or does not support the service described by
   the AVP, it must reject the access request or treat the access
   response as if it were a rejection.


9.5.4  Can Vendor Specific AVPs use the "M" bit?

   Vendor Specific AVPs may use the "M" bit to signify the importance of
   the AVP to the correct ands secure provision of service.  If a
   DIAMETER peer rejects the DIAMETER message because it is unknown or
   unsupported, the rejection is to be considered correct protocol
   behavior, rather than an operational deficiency.

   The issuer of the Vendor Specific AVP attaching the "M" bit MUST
   expect that rejection of service will occur in these cases, and take
   administrative action to correct the misconfiguration.





Calhoun et al.              expires May 2001                   [Page 24]


INTERNET DRAFT                                             November 2000


10.0 SNMP Support (DIAMETER MIB)

   Certain work items in this area require short term attention, while
   some others requires longer term attention (and others are not to be
   done). These work items need to be identified and prioritized in a
   future version of this document.


11.0 Re-Authentication & Authorization

   The text found in the section 11.1 is to be added in the NASREQ
   extension [2], while the text in section 11.2 is to be added to the
   DIAMETER base protocol [1].


11.1  Re-authentication/Re-authorization

   The DIAMETER protocol allows for users to be periodically re-
   authenticated and/or re-authorized. In such instances, an AAR message
   would be sent with a Session-Id AVP that MUST be the same value as
   the one in the original authentication/authorization message. A
   DIAMETER server informs the NAS of the authorized session lifetime
   via the Authorization-Lifetime AVP.

   A NAS MUST re-authenticate and/or authorize after the period provided
   by the server. Furthermore, it is possible for DIAMETER servers to
   issue an unsolicited re-authentication and/or re-authorization by
   issuing an AA-Challenge-Ind message to the NAS. The Session-Id AVP
   MUST have the same value as the original request. Upon receipt of
   such a message, the NAS is instructed to issue a request to re-
   authenticate and/or re-authorize the client.


11.2  Authorization-Lifetime AVP

   The Authorization-Lifetime AVP (AVP Code TBD) is of type Integer32
   and contains the maximum number of seconds of service to be provided
   to the user before the user is to be re-authenticated and/or re-
   authorized. Great care should be taken when the Authorization-
   Lifetime value is determined, since a low value could create
   significant DIAMETER traffic, which could congest both the network
   and the servers.

   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.



Calhoun et al.              expires May 2001                   [Page 25]


INTERNET DRAFT                                             November 2000


12.0 Server/Resource Management State

   There are several significant technical issues to be solved in the
   area of distributed resource management, not the least of which is
   recovery of state in the face of failures of clients, servers or
   networks.  The maintenance and recovery of state may be broken down
   into two classes, tight consistency and loose consistency.


12.1  Loose Consistency

   Loosely consistent distributed state is arguably easier to achieve in
   a reliable, scalable fashion. Loose consistency is characterized by:

      1. delay state recovery until the information is actually needed

      2. recovery of information in a directed fashion, avoiding the use
         of broadcast messages

      3. be only as restrictive as necessary for correct network
         operation and substantial revenue loss avoidance.

   There are two major classes of resource management that are important
   in the areas of applicability for DIAMETER.  The first is the
   assignment of a network address.  The second is the limitation of
   simultaneous login of users.

   In the case of network address assignment, it is important for
   reasons of correct network operation to avoid assigning duplicate
   addresses.  After a loss of state at the server, it may be possible
   to delay state reconciliation on any given address until that address
   is to be (re) assigned.  One possible solution would to be to PING
   addresses before assignment, to determine their availability.

   In the case of exclusive login, state is maintained for the single,
   or possibly limited multiple, login session(s) of a single user.  In
   the event of loss of state, it may be reasonable to give the benefit
   of the doubt to an new user, until such time as state might be
   recovered.  If the new user is determined to be a duplicate, that
   session could be terminated, by server request.  It may be
   sufficient, in terms of limitation of potential revenue loss, to
   loosely control the simultaneous login.

   While additional work must be done to specify the details of a loose
   consistency approach, it may be possible to do so within the time
   goals for protocol development, and yet sufficiently meet the
   business requirements for resource management, so as to make this a
   useful feature of the protocol.



Calhoun et al.              expires May 2001                   [Page 26]


INTERNET DRAFT                                             November 2000


12.2  Tight Consistency

   The problem of obtaining reliable, scalable, distributed resource
   state, in a tightly consistent fashion is a difficult problem.  It is
   not clear that there are valid underlying requirements for tight
   consistency, nor valid business reasons to support it at this time.
   This is a topic for further study.


13.0  Access Rules and Filters

   The following text is intended to replace the current filter format,
   described in section 2.1.2 of [2].

13.1  Filter-Rule AVP

   The Filter-Rule AVP (AVP Code 400) is of type String and provides
   filter rules that need to be configured on the NAS for the user. One
   or more such AVPs MAY be present in an authorization response.

   Each packet can be filtered based on the following information that
   is associated with it:

      Direction                          (in or out)
      Source and destination IP address  (possibly masked)
      Protocol
      Source and destination port        (lists or ranges)
      TCP flags
      IP fragment flag
      IP options
      ICMP types

   Rules for the appropriate direction are evaluated in order, with the
   first matched rule terminating the evaluation.  Each packet is
   evaluated once. If no rule matches, the packet is dropped if the last
   rule evaluated was a permit, and passed if the last rule was a deny.

   The filters in the Filter-Rule AVP MUST follow the format:

      action dir proto from src to dst [options]

      action       permit - Allow packets that match the rule.
                   deny - Drop packets that match the rule.

      dir          "in" is from the terminal, "out" is to the terminal.

      proto        An IP protocol specified by number.  The "ip" keyword
                   means any protocol will match.



Calhoun et al.              expires May 2001                   [Page 27]


INTERNET DRAFT                                             November 2000


      src and dst  <address/mask> [ports]

                   The <address/mask> may be specified as:
                   ipno       An IPv4 or IPv6 number in dotted-quad or
                              canonical IPv6 form. Only this exact IP
                              number will match the rule.
                   ipno/bits  An IP number as above with a mask width of
                              the form 1.2.3.4/24.  In this case all IP
                              numbers from 1.2.3.0 to 1.2.3.255 will
                              match.  The bit width MUST be valid for
                              the IP version and the IP number MUST NOT
                              have bits set beyond the mask.

                   The sense of the match can be inverted by preceding
                   an address with the not modifier, causing all other
                   addresses to be matched instead.  This does not
                   affect the selection of port numbers.

                      The keyword "any" is 0.0.0.0/0 or the IPv6
                      equivalent.  The keyword "assigned" is the address
                      or set of addresses assigned to the terminal.  It
                      is strongly suggested that the first rule be "deny
                      in ip !assigned".  [[I would go further and state
                      that this rule is mandatory and implied, so the
                      NAS MUST provide source address assurance in all
                      cases.  BW]]

                   With the TCP and UDP protocols, optional ports may be
                   specified as:

                      {port|port-port}[,port[,...]]

                   The `-' notation specifies a range of ports
                   (including bound- aries).

                   Fragmented packets which have a non-zero offset (i.e.
                   not the first fragment) will never match a rule which
                   has one or more port specifications.  See the frag
                   option for details on matching fragmented packets.

      options:
         frag    Match if the packet is a fragment and this is not the
                 first fragment of the datagram.  frag may not be used
                 in conjunction with either tcpflags or TCP/UDP port
                 specifi- cations.

         ipoptions spec
                 Match if the IP header contains the comma separated



Calhoun et al.              expires May 2001                   [Page 28]


INTERNET DRAFT                                             November 2000


                 list of options specified in spec. The supported IP
                 options are:

                 ssrr (strict source route), lsrr (loose source route),
                 rr (record packet route) and ts (timestamp). The
                 absence of a particular option may be denoted with a
                 `!'.

         tcpoptions spec
                 Match if the TCP header contains the comma separated
                 list of options specified in spec. The supported TCP
                 options are:

                 mss (maximum segment size), window (tcp window
                 advertisement), sack (selective ack), ts (rfc1323
                 timestamp) and cc (rfc1644 t/tcp connection count).
                 The absence of a particular option may be denoted with
                 a `!'.

         established
                 TCP packets only. Match packets that have the RST or
                 ACK bits set.

         setup   TCP packets only. Match packets that have the SYN bit
                 set but no ACK bit.

         tcpflags spec
                 TCP packets only. Match if the TCP header contains the
                 comma separated list of flags specified in spec. The
                 supported TCP flags are:

                 fin, syn, rst, psh, ack and urg. The absence of a
                 particular flag may be denoted with a `!'. A rule which
                 contains a tcpflags specification can never match a
                 fragmented packet which has a non-zero offset.  See the
                 frag option for details on matching fragmented packets.

         icmptypes types
                 ICMP packets only.  Match if the ICMP type is in the
                 list types. The list may be specified as any
                 combination of ranges or individual types separated by
                 commas.  The supported ICMP types are:

                 echo reply (0), destination unreachable (3), source
                 quench (4), redirect (5), echo request (8), router
                 advertisement (9), router solicitation (10), time-to-
                 live exceeded (11), IP header bad (12), timestamp
                 request (13), timestamp reply (14), information request



Calhoun et al.              expires May 2001                   [Page 29]


INTERNET DRAFT                                             November 2000


                 (15), information reply (16), address mask request (17)
                 and address mask reply (18).

   There is one kind of packet that the NAS MUST always discard, that is
   an IP fragment with a fragment offset of one.  This is a valid
   packet, but it only has one use, to try to circumvent firewalls.

      A NAS that is unable to interpret or apply a deny rule MUST
      terminate the session.  A NAS that is unable to interpret or apply
      a permit rule MAY apply a more restrictive rule.  A NAS MAY apply
      deny rules of its own before the supplied rules, for example to
      protect the NAS owner's infrastructure.

   The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the
   ipfw.c code may provide a useful base for implementations.


13.2  Non-IP Filters

   Filter syntax and semantics of equivalent power should be provided
   for other session protocols supported by DIAMETER.  Details are for
   further study.


14.0 AAA Server Discovery

   Allowing for dynamic AAA server discovery will make it possible for
   simpler and more robust deployment of AAA services.  In order to
   promote interoperable implemenations of AAA server discovery, the
   following mechanisms are described.  These are based on existing IETF
   standards.

   There are two cases where AAA server discovery may be performed.  The
   first is when a AAA client needs to discover a first-hop AAA server.
   The second case is when an AAA server needs to discover another AAA
   server - for further handling of an AAA operation.  In both cases,
   the following 'search order' is recommended:

      1. The AAA implementation consults its list of static (manual)
         configured AAA server locations.  These will be used if they
         exist and respond.

      2. The AAA implementation uses SLPv2 [13] to discover DIAMETER
         services.  The AAA service template [14] is included below, in
         section 14.1.  It is recommended that SLPv2 security be
         deployed (this requires distributing keys to SLPv2 agents.)
         This is discussed further in Section 14.1.




Calhoun et al.              expires May 2001                   [Page 30]


INTERNET DRAFT                                             November 2000


         SLPv2 will allow AAA implementations to discover the location
         of AAA servers in the local site, as well as their
         characteristics.  AAA servers with specific capabilities (say
         support for the Accounting extension) can be requested, and
         only those will be discovered.

      3. The AAA implementation uses DNS to request the SRV RR [15] for
         the '_diameter._sctp' server in a particular domain.  The AAA
         implementation has to know in advance which domain to look for
         an AAA server in.  This could be deduced, for example, from the
         'realm' in a NAI that an AAA implementation needed to perform
         an AAA operation on.

         DIAMETER allows AAA peers to protect the integrity and privacy
         of communication as well as to perform end-point
         authentication.  Still, it is prudent to employ DNS Security as
         a precaution when using DNS SRV RRs to look up the location of
         a DIAMETER server.  [16, 17, 18]


14.1 AAA Service Template

   The following service template describes the attributes used by AAA
   servers to advertise themselves.  This simplifies the process of
   selecting an appropriate server to communicate with.  An AAA client
   can request specific AAA servers based on characteristics of the AAA
   service desired (for example, an AAA server to use for accounting.)

   Name of submitter:  "Erik Guttman" <Erik.Guttman@sun.com>
   Language of service template:  en


   Security Considerations:
      AAA clients and servers use various cryptographic mechanisms to
      protect communication integrity, confidentiality as well as
      perform end-point authentication.  It would thus be difficult if
      not impossible for an attacker to advertise itself using SLPv2 and
      pose as a legitimate AAA peer without proper preconfigured secrets
      or cryptographic keys.  Still, as AAA services are vital for
      network operation it is important to use SLPv2 authentication to
      prevent an attacker from modifying or eliminating service
      advertisements for legitimate AAA servers.

   Template text:
   -------------------------template begins here-----------------------
   template-type=service:diameter

   template-version=0.0



Calhoun et al.              expires May 2001                   [Page 31]


INTERNET DRAFT                                             November 2000


   template-description=
     The DIAMETER protocol is defined by draft-calhoun-diameter-17.txt

   template-url-syntax=
     url-path= ; The standard service URL syntax is used.
               ; For example: 'service:diameter://aaa.example.com:1812

      supported-extensions= string L M
      # This attribute lists the DIAMETER extensions supported by the
      # AAA implementation.  The extensions currently defined are:
      #  Extension Name       Defined by
      #  ---------------      -----------------------------------
      #  NASREQ               draft-calhoun-diameter-nasreq-05.txt
      #  MobileIP             draft-calhoun-diameter-mobileip-11.txt
      #  Accounting           draft-calhoun-diameter-accounting-08.txt
      #  Strong Security      draft-calhoun-diameter-strong-crypto-05.txt
      #  Resource Management  draft-calhoun-diameter-res-mgmt-06.txt
      #
      # Notes:
      #   . AAA implementations support one or more extensions.
      #   . Additional extensions may be defined in the future.
      #     An updated service template will be created at that time.
      #
      NASREQ,MobileIP,Accounting,Strong Security,Resource Management

      supported-transports= string L M
      SCTP
      # This attribute lists the supported transports that the DIAMETER
      # implementation accepts.  Note that a compliant DIAMETER
      # implementation MUST support SCTP, though it MAY support other
      # transports, too.
      SCTP,TCP

   -------------------------template ends here-----------------------


15.0 Loop Detection

   This section describes how proxies detect messages that are looping
   through the same set of entities. This section is targetted to be
   numbered 6.7 in the DIAMETER Base protocol [1].

15.1  Loop Detection

   When a DIAMETER Proxy or Redirect server receives a request, it MUST
   examine all Route-Record AVPs in the message to determine whether
   such an AVP already exists with the local server's identity. If an
   AVP with the local host's identity is found in the request, it is an



Calhoun et al.              expires May 2001                   [Page 32]


INTERNET DRAFT                                             November 2000


   indication that the message is being looped through the same set of
   proxies. When such an event occurs, the DIAMETER server that detects
   the loop returns a response with the Result-Code AVP set to
   DIAMETER_LOOP_DETECTED.


16.0  IANA Considerations

   DIAMETER makes extensive use of IDs (command codes, extensions,
   result codes, AVP attributes, Integrity-Check-Value AVP Transform
   code).  These are collected in the base protocol specification, but
   defined in the DIAMETER extension docs. The Working Group needs to
   make sure that IANA is notified that a registry needs to be created
   to keep track of all DIAMETER identifiers.


17.0  Security Considerations

   DIAMETER [1] is a framework providing authentication and
   authorization services for network access.  Section 11 and 13 concern
   how these features could be refined or improved in subsequent work.

   DIAMETER itself contains a number of security features.  Section 8
   discusses how these could be redesigned for less reliance on public
   key cryptography.

   The security implications of using attribute-based service discovery
   to locate AAA servers is discussed in Section 14.1.


18.0  Acknowledgments

   The authors would like to thank the AAA Design Team for raising the
   issues in [11], which were used in the creation of this document.


19.0  References


   [1]  P. Calhoun, A. Rubens, H. Akhtar, E. Guttman.  "DIAMETER Base
        Protocol", draft-calhoun-diameter-17.txt, IETF work in progress,
        September 2000.

   [2]  P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ
        Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
        progress, September 2000.

   [3]  Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-



Calhoun et al.              expires May 2001                   [Page 33]


INTERNET DRAFT                                             November 2000


        calhoun-diameter-framework-08.txt, IETF work in progress, June
        2000.

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

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

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

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

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

   [9]  Aboba et al, "Network Access AAA Evaluation Criteria", IETF work
        in progress, draft-ietf-aaa-na-reqts-07.txt, August 2000.

   [10] Mitton et al, "Authentication, Authorization, and Accounting:
        Protocol Evaluation", IETF work in progress, draft-ietf-aaa-
        proto-eval-00.txt, July 2000.

   [11] Calhoun et al., "AAA Problem Statements", IETF work in progress,
        draft-ietf-aaa-issues-01.txt, October 2000.

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

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

   [14] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Ser-
        vice: Schemes", RFC 2609, June 1999.

   [15] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying
        the location of services (DNS SRV)", RFC 2782, February 2000.

   [16] D. Eastlake, "Domain Name System Security Extensions", RFC 2535,
        March 1999.




Calhoun et al.              expires May 2001                   [Page 34]


INTERNET DRAFT                                             November 2000


   [17] D. Eastlake, "DNS Security Operational Considerations", RFC
        2541, March 1999.

   [18] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s
        )", RFC 2931, September 2000.

   [19] D. Harrington et. al., "An Architecture for Describing SNMP
        Management Frameworks", RFC 2571, May 1999.

   [20] Information processing systems - Open Systems Interconnection,
        "Specification of Abstract Syntax Notation One (ASN.1)", Inter-
        national Organization for Standardization, International Stan-
        dard 8824, December 1987.

   [21] B. Aboba, G. Zorn, D. Mitton, "RADIUS and IPv6", draft-aboba-
        radius-ipv6-02.txt, IETF Work in Progress, August 2000.

   [22] S. Farrell, S. Turner, "Reuse of CMS Content Encryption Keys",
        draft-ietf-smime-rcek-00.txt, IETF work in progress, September
        2000.


20.0  Authors' Addresses

   Questions about this memo can be directed to:

      Jari Arkko
      Oy LM Ericsson Ab
      02420 Jorvas
      Finland

       Phone: +358 40 5079256
      E-Mail: Jari.Arkko@ericsson.com


      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  +1 650-786-7733
         Fax:  +1 650-786-6445
      E-mail:  pcalhoun@eng.sun.com


      Erik Guttman



Calhoun et al.              expires May 2001                   [Page 35]


INTERNET DRAFT                                             November 2000


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

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


      David B. Nelson
      Enterasys Networks, Inc. (a Cabletron Systems company)
      50 Minuteman Road
      Andover, MA 01810-1008
      USA

       Phone:  +1 978 684 1330
      E-Mail:  dnelson@enterasys.com


      Barney Wolff, Pres.
      Databus Inc.
      15 Victor Drive
      Irvington, NY 10533-1919 USA
      USA

       Phone:  +1 914 591 5677
      E-mail:  barney@databus.com


21.0  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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



Calhoun et al.              expires May 2001                   [Page 36]


INTERNET DRAFT                                             November 2000


   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
   CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
   TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.













































Calhoun et al.              expires May 2001                   [Page 37]


INTERNET DRAFT                                             November 2000


Appendix A - DIAMETER Data Dictionary XML DTD

   <?xml version="1.0" standalone="yes" ?>
   <!DOCTYPE diameter [

      <!-- NOTE:  This DTD describes the set of AVPs which may be  -->
      <!-- supported by a particular DIAMETER implementation.      -->

      <!-- Since DIAMETER is extensible, not every DIAMETER        -->
      <!-- implementation will support all the AVPs described in a -->
      <!-- a document conforming to this DTD.                      -->

      <!-- This DTD describes AVPs for the purpose of simplifying  -->
      <!-- extensibility of DIAMETER implementations, protocol     -->
      <!-- analyzers and tools.  This DTD does not define the      -->
      <!-- on-the-wire presentation of AVPs.  For this information -->
      <!-- refer to the cited specifications for the base protocol -->
      <!-- and extensions.                                         -->

      <!-- ------------------------------------------------------- -->
      <!-- diameter data dictionary definition                     -->
      <!-- ------------------------------------------------------- -->

      <!-- 'diameter' describes the base protocol and the AVPs     -->
      <!-- it supports.                                            -->
      <!ELEMENT diameter ( base avp* extension+ )>

      <!-- 'base' is the url of the spec of the base protocol.     -->
      <!ELEMENT base (#PCDATA)>


      <!-- ------------------------------------------------------- -->
      <!-- extension definition                                    -->
      <!-- ------------------------------------------------------- -->

      <!ELEMENT extension ( extname doc avp+ )>

      <!-- 'extname' is the name of the extension.                 -->
      <!ELEMENT extname (#PCDATA)>

      <!-- 'doc' is the url of the spec defining the extension.    -->
      <!ELEMENT doc (#PCDATA)>


      <!-- ------------------------------------------------------- -->
      <!-- avp definition                                          -->
      <!-- ------------------------------------------------------- -->




Calhoun et al.              expires May 2001                   [Page 38]


INTERNET DRAFT                                             November 2000


      <!-- 'avp' describes the attributes in the extension.        -->
      <!ELEMENT avp ( name description? type value* )>

      <!-- 'name' is the name of an AVP in the DIAMETER extension. -->
      <!ELEMENT name (#PCDATA)>

      <!-- 'description' text describes the AVP.                   -->
      <!ELEMENT description (#PCDATA)>

      <!-- 'value' is a value-item/description pair defined for    -->
      <!--  the AVP.                                               -->
      <!ELEMENT value (val desc)>

      <!-- 'val' is a specific value.                         -->
      <!ELEMENT val (#PCDATA)>

      <!-- 'desc' describes the specific value.         -->
      <!ELEMENT desc (#PCDATA)>

      <!-- ------------------------------------------------------- -->
      <!--  avp type definition                                    -->
      <!-- ------------------------------------------------------- -->

      <!-- 'type' is the data type for AVPs.                       -->
      <!-- Values can be: OctetString, Unsigned32,                 -->
      <!--   Integer32, Unsigned64, Integer64, Float32, Float64,   -->
      <!--   Float128, Grouped or List.                            -->
      <!--   In the case of Grouped or List, AVPs are              -->
      <!--   nested in the AVP definition as specified below.      -->
      <!ELEMENT type (#PCDATA | grouped | list)>

      <!-- 'grouped' defines a sequence of AVPs that constitute    -->
      <!-- an AVP type collectively.  2 or more AVPs are included  -->
      <!-- in each grouped value.  An instance of an AVP with type -->
      <!-- 'grouped' is followed by instances of the given         -->
      <!--  sequence of AVPs.                                      -->
      <!ELEMENT grouped ( seq-name seq-name+)>

      <!-- 'list' defines an unordered set of AVPs of the same     -->
      <!-- type.  One AVP is included.  An AVP with type 'list'    -->
      <!-- contains an Unsigned32 number 'n', which is followed    -->
      <!-- by n instances of the AVP given.                        -->
      <!ELEMENT list (set-name)>


      <!-- ------------------------------------------------------- -->
      <!-- Mandatory avp attributes                                -->
      <!-- ------------------------------------------------------- -->



Calhoun et al.              expires May 2001                   [Page 39]


INTERNET DRAFT                                             November 2000


      <!-- 'code' is the reserved unsigned 32 bit ID of the avp.   -->
      <!ATTLIST avp code CDATA #REQUIRED)>

      <!-- 'may-encrypt' : is encrpytion permitted?                -->
      <!ATTLIST avp may-encrypt (true false) #REQUIRED>


      <!-- ------------------------------------------------------- -->
      <!-- Optional avp and type attributes                        -->
      <!-- ------------------------------------------------------- -->

      <!-- 'mandatory-flag' : is the 'M' flag disallowed? required?-->
      <!--   If not included, use of the flag is OPTIONAL.         -->
      <!ATTLIST avp mandatory-flag (disallowed allowed required)
        #IMPLIED "allowed" >

      <!-- 'vendor-flag' : is the 'V' flag disallowed?             -->
      <!--   If not included, use of the flag is allowed.          -->
      <!ATTLIST avp vendor-flag (disallowed allowed)
        #IMPLIED "allowed">

      <!-- 'constrained' : is the list of legal values constrained -->
      <!--   to those in the value list?                           -->
      <!ATTLIST avp constrained (true false) #IMPLIED "false">

      <!-- 'printable' is used to indicate that data of type       -->
      <!--   OctetString contains a printable string.  This        -->
      <!--   distinguishes between a printable string and opaque   -->
      <!--   octets.                                               -->
      <!ATTLIST data printable (true false) #IMPLIED "false">

      <!-- 'ip-address' is used to indicate that data of type      -->
      <!--   OctetString contains an IP address.                   -->
      <!ATTLIST data ip-address (true false) #IMPLIED "false">

      <!-- 'time' is used to indicate that data of type Unsigned32 -->
      <!--   is in fact a time value - the four most significant   -->
      <!--   bytes of an NTP timestamp. [RFC 2030]                 -->
      <!ATTLIST data time (true false) #IMPLIED "false">
   ]>

   <diameter>
     <base>
       ftp://ftp.ietf.org/internet-drafts/draft-calhoun-diameter-17.txt

       <avp code="1" may-encrypt="true">
         <name> User-Name </name>
         <type printable="true"> OctetString </type>



Calhoun et al.              expires May 2001                   [Page 40]


INTERNET DRAFT                                             November 2000


       </avp>


       <avp code="27" may-encrypt="true">
         <name> Session-Timeout </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="33" may-encrypt="false"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Proxy-State </name>
         <type>
           <grouped>
             <member-name> State-Creator </member-name>
             <member-name> State-Opaque </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="TBD" may-encrypt="false">
         <name> State-Creator </name>
         <type ip-address="true"> OctetString </type>
         <description>
           The value of this AVP contains the address of the creator
           of the proxy state.
         </description>
       </avp>

       <avp code="TBD" may-encrypt="false">
         <name> State-Opaque </name>
         <type> OctetString </type>
         <description>
           The value of this AVP contains arbitrary state data.
         </description>
       </avp>

       <avp code="257" may-encrypt="false"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Host-IP-Address </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="258" may-encrypt="true">
         <name> Extension-Id</name>
         <type> Unsigned32 </type>
         <value>
           <val> 1 </val>
           <desc> NASREQ </desc>



Calhoun et al.              expires May 2001                   [Page 41]


INTERNET DRAFT                                             November 2000


         </value>
         <value>
           <val> 2 </val>
           <desc> Strong Security </desc>
         </value>
         <value>
           <val> 3 </val>
           <desc> Resource Management </desc>
         </value>
         <value>
           <val> 4 </val>
           <desc> Mobile-IP </desc>
         </value>
         <value>
           <val> 5 </val>
           <desc> Accounting </desc>
         </value>
       </avp>

       <avp code="259" may-encrypt="false">
         <name> Integrity-Check-Vector </name>
         <type>
           <grouped>
             <member-name> Transform-ID </member-name>
             <member-name> Key-ID </member-name>
             <member-name> ICV-Data </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="TBD" may-encrypt="false">
         <name> Transform-ID </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="TBD" may-encrypt="false">
         <name> Key-ID </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="TBD" may-encrypt="false">
         <name> ICV-Data </name>
         <type> OctetString </type>
       </avp>

       <avp code="260" may-encrypt="false">
         <name> Encrypted-Payload </name>
         <type>



Calhoun et al.              expires May 2001                   [Page 42]


INTERNET DRAFT                                             November 2000


           <grouped>
             <member-name> Transform-ID </member-name>
             <member-name> Key-ID </member-name>
             <member-name> Encrypted-Payload-Data </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="TBD" may-encrypt="false">
         <name> Encrypted-Payload-Data </name>
         <type> OctetString </type>
       </avp>

       <avp code="261" may-encrypt="false">
         <name> Nonce </name>
         <type> OctetString </type>
       </avp>

       <avp code="262" may-encrypt="false">
         <name> Timestamp </name>
         <type time="true"> Unsigned32 </type>
       </avp>

       <avp code="263" may-encrypt="true">
         <name> Session-Id </name>
         <type> OctetString </type>
       </avp>

       <avp code="264" may-encrypt="false"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Host-Name </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="266" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="disallowed">
         <name> Vendor-Name </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="267" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="disallowed">
         <name> Firmware-Revision </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="268" may-encrypt="false">
         <name> Result-Code </name>



Calhoun et al.              expires May 2001                   [Page 43]


INTERNET DRAFT                                             November 2000


         <type>
           <grouped>
             <member-name> Result-Error-Code </member-name>
             <member-name> Result-Error-String </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="TBD" may-encrypt="false constrained="true">
         <name> Result-Error-Code </name>
         <type> Unsigned32 </type>
         <description>
           This  DIAMETER error codes.
         </description>
         <value>
           <val>  0 </val>
           <desc> DIAMETER_SUCCESS </desc>
         </value>
         <value>
           <val>  1 </val>
           <desc> DIAMETER_FAILURE </desc>
         </value>
         <value>
           <val>  2 </val>
           <desc> DIAMETER_POOR_REQUEST </desc>
         </value>
         <value>
           <val>  3 </val>
           <desc> DIAMETER_INVALID_AUTH </desc>
         </value>
         <value>
           <val>  4 </val>
           <desc> DIAMETER_UNKNOWN_SESSION_ID </desc>
         </value>
         <value>
           <val>  5 </val>
           <desc> DIAMETER_USER_UNKNOWN </desc>
         </value>
         <value>
           <val>  6 </val>
           <desc> DIAMETER_COMMAND_UNSUPPORTED </desc>
         </value>
         <value>
           <val>  7 </val>
           <desc> DIAMETER_TIMEOUT </desc>
         </value>
         <value>
           <val>  8 </val>



Calhoun et al.              expires May 2001                   [Page 44]


INTERNET DRAFT                                             November 2000


           <desc> DIAMETER_AVP_UNSUPPORTED </desc> </value>
         <value>
           <val>  9 </val>
           <desc> DIAMETER_REDIRECT_INDICATION </desc>
         </value>
         <value>
           <val> 10 </val>
           <desc> DIAMETER_REALM_NOT_SERVED </desc>
         </value>
         <value>
           <val> 11 </val>
           <desc> DIAMETER_UNSUPPORTED_TRANSFORM </desc>
         </value>
         <value>
           <val> 12 </val>
           <desc> DIAMETER_AUTHENTICATION_REJECTED </desc>
         </value>
         <value>
           <val> 13 </val>
           <desc> DIAMETER_AUTHORIZATION_REJECTED </desc>
         </value>
         <value>
           <val> 14 </val>
           <desc> DIAMETER_INVALID_AVP_VALUE </desc>
         </value>
         <value>
           <val> 15 </val>
           <desc> DIAMETER_MISSING_AVP </desc>
         </value>
         <value>
           <val> 16 </val>
           <desc> DIAMETER_ERROR_BAD_KEY </desc>
         </value>
         <value>
           <val> 17 </val>
           <desc> DIAMETER_ERROR_BAD_HOME_ADDRESS </desc>
         </value>
         <value>
           <val> 18 </val>
           <desc> DIAMETER_ERROR_TOO_BUSY </desc>
         </value>
         <value>
           <val> 19 </val>
           <desc> DIAMETER_ERROR_MIP_REPLY_FAILURE </desc>
         </value>
         <value>
           <val> 20 </val>
           <desc> DIAMETER_INVALID_CMS_DATA </desc>



Calhoun et al.              expires May 2001                   [Page 45]


INTERNET DRAFT                                             November 2000


         </value>
         <value>
           <val> 21 </val>
        <desc> DIAMETER_ERROR_BAD_HAR-day </desc>
         </value>
       </avp>

       <avp code="TBD" may-encrypt="false>
         <name> Result-Error-String </name>
         <type printable="true"> OctetString </type>
         <description>
           This contains an optional human readable string.  If this
           field is not included, the printable string data is of 0
           length.
         </description>
       </avp>

       <avp code="269" may-encrypt="true">
         <name> Destination-NAI </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="270" may-encrypt="true">
         <name> Unknown-Command-Code </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="279" may-encrypt="true">
         <name> Failed-AVP </name>
         <type> OctetString </type>
       </avp>

       <avp code="278" may-encrypt="true">
         <name> Redirect-Host </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="277" may-encrypt="true">
         <name> Redirect-Host-Port </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="280" may-encrypt="false">
         <name> Grouped </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="278" may-encrypt="false">



Calhoun et al.              expires May 2001                   [Page 46]


INTERNET DRAFT                                             November 2000


         <name> Redirect-Host </name>
         <type ip-address="true"> OctetString </type>
       </avp>

     </base>

     <!-- -------------------------------------------------------- -->

     <extension>

       <extname> DIAMETER NASREQ Extensions </extname>

       <doc>
          ftp://ftp.ietf.org/internet-drafts/
          draft-calhoun-diameter-nasreq-05.txt
       </doc>

       <avp code="2" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> User-Password </name>
         <type> OctetString </type>
       </avp>

       <avp code="3" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> CHAP-Password </name>
         <type> OctetString </type>
       </avp>

       <avp code="4" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> NAS-IP-Address </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="5" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> NAS-Port </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="6" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Service-Type </name>
         <type> Unsigned32 </type>
         <value>
           <val> 1 </val>
           <desc> Login </desc>



Calhoun et al.              expires May 2001                   [Page 47]


INTERNET DRAFT                                             November 2000


         </value>
         <value>
           <val> 2 </val>
           <desc> Framed </desc>
         </value>
         <value>
           <val> 3 </val>
           <desc> Callback Login </desc>
         </value>
         <value>
           <val> 4 </val>
           <desc> Callback Framed </desc>
         </value>
         <value>
           <val> 5 </val>
           <desc> Outbound </desc>
         </value>
         <value>
           <val> 6 </val>
           <desc> Administrative </desc>
         </value>
         <value>
           <val> 7 </val>
           <desc> NAS Prompt </desc>
         </value>
         <value>
           <val> 8 </val>
           <desc> Authenticate Only </desc>
         </value>
         <value>
           <val> 9 </val>
           <desc> Callback NAS Prompt </desc>
         </value>
       </avp>

       <avp code="7" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-Protocol </name>
         <type> Unsigned32 </type>
         <value> <val> 1 </val> <desc> PPP </desc> </value>
         <value> <val> 2 </val> <desc> PPP </desc> </value>
         <value>
           <val> 3 </val>
           <desc> AppleTalk Remote Access Protocol (ARAP) </desc>
         </value>
         <value>
           <val> 4 </val>
           <desc>



Calhoun et al.              expires May 2001                   [Page 48]


INTERNET DRAFT                                             November 2000


          Gandalf proprietary SingleLink/MultiLink protocol
           </desc>
         </value>
         <value>
           <val> 5 </val>
           <desc> Xylogics proprietary IPX/SLIP </desc>
         </value>
         <value> <val> 6 </val> <desc> X.75 Synchronous </desc> </value>
       </avp>

       <avp code="8" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-IP-Address </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="9" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-IP-Netmask </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="10" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-Routing </name>
         <type> Unsigned32 </type>
         <value> <val> 0  </val> <desc> None </desc> </value>
         <value>
           <val> 1 </val>
           <desc> Send routing packets </desc>
         </value>
         <value>
           <val> 2 </val>
           <desc> Listen for routing packets </desc>
         </value>
         <value> <val> 3 </val> <desc> Send and Listen </desc> </value>
       </avp>

       <avp code="11" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Filter-Id </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="12" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-MTU </name>
         <type> Unsigned32 </type>



Calhoun et al.              expires May 2001                   [Page 49]


INTERNET DRAFT                                             November 2000


       </avp>

       <avp code="13" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-Compression </name>
         <type> Unsigned32 </type>
         <value>
           <val> 0 </val>
        <desc> None </desc>
         </value>
         <value>
           <val> 1 </val>
        <desc> VJ TCP/IP header compression </desc>
         </value>
         <value>
           <val> 2 </val>
        <desc> IPX header compression </desc>
         </value>
         <value>
           <val> 3 </val>
        <desc> Stac-LZS compression </desc>
         </value>
       </avp>

       <avp code="14" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Login-IP-Host </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="15" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Login-Service </name>
         <type> Unsigned32 </type>
         <value>
           <val> 0 </val>
        <desc> Telnet </desc>
         </value>
         <value>
           <val> 1 </val>
        <desc> Rlogin </desc>
         </value>
         <value>
           <val> 2 </val>
        <desc> TCP Clear </desc>
         </value>
         <value>
           <val> 3 </val>



Calhoun et al.              expires May 2001                   [Page 50]


INTERNET DRAFT                                             November 2000


        <desc> PortMaster (proprietary) </desc>
         </value>
         <value>
           <val> 4 </val>
        <desc> LAT </desc>
         </value>
         <value>
           <val> 5 </val>
        <desc> X25-PAD </desc>
         </value>
         <value>
           <val> 6 </val>
        <desc> X25-T3POS </desc>
         </value>
         <value>
           <val> 8 </val>
        <desc>
             TCP Clear Quiet (supresses any NAS-generated
             connect string)
           </desc>
         </value>

       </avp>

       <avp code="16" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Login-TCP-Port </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="18" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Reply-Message </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="19" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Callback-Number </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="20" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Callback-Id </name>
         <type printable="true"> OctetString </type>
       </avp>




Calhoun et al.              expires May 2001                   [Page 51]


INTERNET DRAFT                                             November 2000


       <avp code="22" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-IP-Route </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="23" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-IPX-Route </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="28" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Idle-Timeout </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="30" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Called-Station-Id </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="31" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Calling-Station-Id </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="32" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> NAS-Identifier </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="34" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Login-LAT-Service </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="35" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Login-LAT-Node </name>
         <type printable="true"> OctetString </type>
       </avp>




Calhoun et al.              expires May 2001                   [Page 52]


INTERNET DRAFT                                             November 2000


       <avp code="36" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Login-LAT-Group </name>
         <type> OctetString </type>
       </avp>

       <avp code="37" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-Appletalk-Link </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="38" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-Appletalk-Network </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="39" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Framed-Appletalk-Zone</name>
         <type> OctetString </type>
       </avp>

       <avp code="60" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> CHAP-Challenge </name>
         <type> OctetString </type>
       </avp>

       <avp code="61" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> NAS-Port-Type </name>
         <type> Unsigned32 </type>
         <value> <val> 0 </val> <desc> Async </desc> </value>
         <value> <val> 1 </val> <desc> Sync </desc>     </value>
         <value> <val> 2 </val> <desc> ISDN Sync </desc> </value>
         <value> <val> 3 </val> <desc> ISDN Async V.120 </desc> </value>
         <value> <val> 4 </val> <desc> ISDN Async V.110 </desc> </value>
         <value> <val> 5 </val> <desc> Virtual </desc> </value>
         <value> <val> 6 </val> <desc> PIAFS </desc> </value>
         <value>
           <val> 7 </val>
           <desc>  HDLC Clear Channel</desc>
         </value>
         <value> <val> 8 </val> <desc> X.25 </desc> </value>
         <value> <val> 9 </val> <desc> X.75 </desc> </value>
         <value> <val> 10 </val> <desc> G.3 Fax </desc> </value>



Calhoun et al.              expires May 2001                   [Page 53]


INTERNET DRAFT                                             November 2000


         <value>
           <val> 11 </val>
           <desc> </desc>
         </value>
         <value>
           <val> 12 </val>
           <desc> </desc>
         </value>
         <value>
           <val> 13 </val>
           <desc> </desc>
         </value>
         <value>
           <val> 14 </val>
           <desc> </desc>
         </value>
         <value> <val> 15 </val> <desc> Ethernet </desc> </value>
         <value> <val> 16 </val> <desc> xDSL </desc> </value>
         <value> <val> 17 </val> <desc> Cable </desc> </value>
         <value>
           <val> 18 </val>
           <desc> Wireless - Other </desc>
         </value>
         <value>
           <val> 19 </val>
           <desc> Wireless - IEEE 802.11  </desc>
         </value>
       </avp>

       <avp code="62" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Port-Limit </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="63" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Login-LAT-Port </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Group </name>
         <type>
           <grouped>
             <member-name> Tunnel-Type </member-name>
             <member-name> Tunnel-Medium-Type </member-name>



Calhoun et al.              expires May 2001                   [Page 54]


INTERNET DRAFT                                             November 2000


             <member-name> Tunnel-Preference </member-name>
             <member-name> Tunnel-Client-Endpoint </member-name>
             <member-name> Tunnel-Server-Endpoint </member-name>
             <member-name> Tunnel-Password </member-name>
             <member-name> Tunnel-Private-Group-ID </member-name>
             <member-name> Tunnel-Assignment-Id </member-name>
             <member-name> Tunnel-Preference </member-name>
             <member-name> Tunnel-Client-Auth-ID </member-name>
             <member-name> Tunnel-Server-Auth-ID </member-name>
             </grouped>
         </type>
         <description>
           Tunnel AVPs are all accumulated into a Tunnel-Group.
           Each potential tunnel configuration is represented by
           a Tunnel-Group AVP.
         </description>
       </avp>

       <avp code="64" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Type </name>
         <type> Unsigned32 </type>
         <value>
           <val> 1 </val>
        <desc> Point-to-Point Tunneling Protocol (PPTP) </desc>
         </value>
         <value>
           <val> 2 </val>
        <desc> Layer Two Forwarding (L2F) </desc>
         </value>
         <value>
           <val> 3 </val>
        <desc> Layer Two Tunneling Protocol (L2TP) </desc>
         </value>
         <value>
           <val> 4 </val>
        <desc> Ascend Tunnel Management Protocol (ATMP) </desc>
         </value>
         <value>
           <val> 5 </val>
        <desc>  Virtual Tunneling Protocol (VTP)</desc>
         </value>
         <value>
           <val> 6 </val>
        <desc>
             IP Authentication Header in the Tunnel-mode (AH)
           </desc>
         </value>



Calhoun et al.              expires May 2001                   [Page 55]


INTERNET DRAFT                                             November 2000


         <value>
           <val> 7 </val>
        <desc> IP-in-IP Encapsulation (IP-IP) </desc>
         </value>
         <value>
           <val> 8 </val>
        <desc> Minimal IP-in-IP Encapsulation (MIN-IP-IP) </desc>
         </value>
         <value>
           <val> 9 </val>
        <desc>
             IP Encapsulating Security Payload in the Tunnel-mode
           </desc>
         </value>
         <value>
           <val> 10 </val>
        <desc> Generic Route Encapsulation (GRE) </desc>
         </value>
         <value>
           <val> 11 </val>
        <desc> Bay Dial Virtual Services </desc>
         </value>
         <value>
           <val> 12 </val>
        <desc> IP-in-IP Tunneling </desc>
         </value>
       </avp>

       <avp code="65" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Medium-Type </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="66" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Client-Endpoint </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="67" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Server-Endpoint </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="69" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">



Calhoun et al.              expires May 2001                   [Page 56]


INTERNET DRAFT                                             November 2000


         <name> Tunnel-Password </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="81" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Private-Group-ID</name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="82" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Assignment-Id </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="83" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Preference </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="90" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Client-Auth-ID </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="91" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Tunnel-Server-Auth-ID </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="400" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> </name>
         <type printable="true" > OctetString </type>
       </avp>

       <avp code="401" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> </name>
         <type> Unsigned32 </type>
         <value>
           <val> 1 </val>
           <desc> AUTHENTICATE_ONLY </desc>
         </value>



Calhoun et al.              expires May 2001                   [Page 57]


INTERNET DRAFT                                             November 2000


         <value>
           <val> 2 </val>
           <desc> AUTHORIZE_ONLY </desc>
         </value>
         <value>
           <val> 3 </val>
           <desc> AUTHORIZE_AUTHENTICATE </desc>
         </value>
       </avp>

       <avp code="402" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> EAP-Payload </name>
         <type> OctetString </type>
       </avp>

     </extension>


     <!-- -------------------------------------------------------- -->

     <extension>

       <extname> DIAMETER Resource Management Extensions </extname>

       <doc>
          ftp://ftp.ietf.org/internet-drafts/
          draft-calhoun-diameter-res-mgmt-06.txt
       </doc>

       <avp code="500" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Query-Index </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="501" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Resource-Token </name>
         <type>
           <grouped>
             <member-name> Session-ID </member-name>
             <member-name> Host-Name </member-name>
             <member-name> User-Name </member-name>
             <member-name> Timestamp </member-name>
             <member-name> Extension-Id </member-name>
             <member-name> Resource-Bag </member-name>
           </grouped>



Calhoun et al.              expires May 2001                   [Page 58]


INTERNET DRAFT                                             November 2000


         </type>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Resource-Bag </name>
         <type> OctetString </type>
         <description>
           This AVP encapsulates arbitrary user data.  This could
           be in the form of a vendor specified AVP with a group
           data type, for example.
         </description>
       </avp>

     </extension>

     <!-- -------------------------------------------------------- -->

     <extension>

       <extname> DIAMETER Strong Security Extension </extname>

       <doc>
          ftp://ftp.ietf.org/internet-drafts/
          draft-calhoun-diameter-strong-crypto-05.txt
       </doc>

       <avp code="300" may-encrypt="false">
         <name> CMS-Data </name>
         <type> OctetString </type>
         <description>
           The value of this AVP is a CMS object encrypted according
           to the S/MIME v3 message specification. [RFC 2633]  The
           contents of encapsulating encrypted MIME is a set of
           DIAMETER AVPs.
         </description>
       </avp>

     </extension>

     <!-- -------------------------------------------------------- -->

     <extension>

       <extname> DIAMETER Mobile IP Extensions </extname>

       <doc>
          ftp://ftp.ietf.org/internet-drafts/



Calhoun et al.              expires May 2001                   [Page 59]


INTERNET DRAFT                                             November 2000


          draft-calhoun-diameter-mobileip-11.txt
       </doc>

       <avp code="320" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> MIP-Reg-Request </name>
         <type> OctetString </type>
       </avp>

       <avp code="321" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> MIP-Reg-Reply </name>
         <type> OctetString </type>
       </avp>

       <avp code="322" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> MN-AAA-Auth </name>
         <type>
           <group>
             <member-name> MN-AAA-SPI </member-name>
             <member-name> Authentication-Input-Data-Length </member-name>
             <member-name> Authenticator-Length </member-name>
             <member-name> Authenticator-Offset </member-name>
           </group>
         </type>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> MN-AAA-SPI </name>
         <type> Unsigned32 </type>
         <description>
            The SPI which indicates the algorithm by which the targeted
            AAA server (AAAH) should attempt to validate the
            Authenticator computed by the mobile node over the
            Registration Request data
         </description>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Authentication-Input-Data-Length </name>
         <type> Unsigned32 </type>
         <description>
            The length in bytes of the Registration Request data (data
            portion of MIP-Reg-Request AVP) that should be used as
            input to the algorithm (indicated by the MN-AAA SPI) used



Calhoun et al.              expires May 2001                   [Page 60]


INTERNET DRAFT                                             November 2000


            to determine whether the Authenticator Data supplied by the
            Mobile Node is valid.
         </description>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Authenticator-Length </name>
         <type> Unsigned32 </type>
         <description>
            The length of the authenticator to be validated by the
            targeted AAA server (i.e., AAAH).
         </description>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Authenticator-Offset </name>
         <type> Unsigned32 </type>
         <description>
            The offset into the Registration Request Data, of the
            authenticator to be validated by the targeted AAA server
            (i.e., AAAH).
        </description>
       </avp>


       <avp code="325" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> MN-to-FA-Key </name>
         <type>
           <grouped>
             <member-name> Peer-SPI </member-name>
             <member-name> Mobility-SA-Key </member-name>
           </grouped>
         </type>
         <description>
            The MN-to-FA-Key AVP contains the data immediately
            following the Mobile IP extension header of the
            "Unsolicited MN-FA Key From AAA Subtype", as documented
            in draft-calhoun-mobileip-aaa-key-01.txt.
         </description>
       </avp>

       <avp code="331" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> MN-to-HA-Key </name>
         <type>



Calhoun et al.              expires May 2001                   [Page 61]


INTERNET DRAFT                                             November 2000


           <grouped>
             <member-name>  Peer-SPI </member-name>
             <member-name>  Mobility-SA-Key </member-name>
           </grouped>
         </type>
         <description>
            The HA-to-MN-Key AVP contains the data immediately
            following the Mobile IP extension header of the
            "Unsolicited MN-HA Key From AAA Subtype", as documented
            in draft-calhoun-mobileip-aaa-key-01.txt.
         </description>
       </avp>

       <avp code="326" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> FA-to-MN-Key </name>
         <type>
           <grouped>
             <member-name> Peer-SPI  </member-name>
             <member-name> Mobility-SA-Key </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="328" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> FA-to-HA-Key </name>
         <type>
           <grouped>
             <member-name> Peer-SPI  </member-name>
             <member-name> Mobility-SA-Key </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="332" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> HA-to-MN-Key </name>
         <type>
           <grouped>
             <member-name> Peer-SPI  </member-name>
             <member-name> Mobility-SA-Key </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="329" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">



Calhoun et al.              expires May 2001                   [Page 62]


INTERNET DRAFT                                             November 2000


         <name> HA-to-FA-Key </name>
         <type>
           <grouped>
             <member-name> Peer-SPI  </member-name>
             <member-name> </member-name>
           </grouped>
         </type>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Peer-SPI </name>
         <type> Unsigned32 </type>
         <description>
            A 32-bit opaque value, which the target MUST use to index
            all the necessary information recovered from the security
            information after it is decoded.
         </description>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Mobility-SA-Key </name>
         <type> OctetString </type>
         <description>
           This contains the key used to create a Mobility Security
           Association between the mobility nodes.
         </description>
       </avp>

       <avp code="324" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> FA-MN-Preferred-SPI </name>
         <type> Unsigned32 </type>
         <description>
         </description>
       </avp>

       <avp code="327" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> FA-HA-Preferred-SPI </name>
         <type> Unsigned32 </type>
         <description>
         </description>
       </avp>

       <avp code="TBD" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">



Calhoun et al.              expires May 2001                   [Page 63]


INTERNET DRAFT                                             November 2000


         <name> </name>
         <type> </type>
         <description>
         </description>
       </avp>

       <avp code="333" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Mobile-Node-Address </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="334" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Home-Agent-Address </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="335" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Previous-FA-NAI </name>
         <type printable="true"> OctetString </type>
       </avp>

       <avp code="336" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Previous-FA-Addr </name>
         <type ip-address="true"> OctetString </type>
       </avp>

       <avp code="337" may-encrypt="true" constrained="false"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> MIP-Feature-Vector </name>
         <type> Unsigned32 </type>
         <description>
           The value of this AVP is added with flag values set
        by the Foreign Agent or by the AAAF owned by the
        same administrative domain as the Foreign Agent.
         </description>
         <value>
           <val> 1 </val>
        <desc> Mobile-Node-Home-Address-Requested </desc>
         </value>
         <value>
           <val> 2 </val>
        <desc> Home-Address-Allocatable-Only-in-Home-Domain </desc>
         </value>
         <value>



Calhoun et al.              expires May 2001                   [Page 64]


INTERNET DRAFT                                             November 2000


           <val> 4 </val>
        <desc> Home-Agent-Requested </desc>
         </value>
         <value>
           <val> 8 </val>
        <desc> Foreign-Home-Agent-Available </desc>
         </value>
         <value>
           <val> 16 </val>
        <desc> MN-HA-Key-Request </desc>
         </value>
         <value>
           <val> 32 </val>
        <desc> MN-FA-Key-Request </desc>
         </value>
         <value>
           <val> 64 </val>
        <desc> FA-HA-Key-Request </desc>
         </value>
         <value>
           <val> 128 </val>
        <desc> Home-Agent-In-Foreign-Network </desc>
         </value>
       </avp>

     </extension>

     <!-- -------------------------------------------------------- -->

     <extension>

       <extname> DIAMETER Accounting Extension </extname>

       <doc>
          ftp://ftp.ietf.org/internet-drafts/
          draft-calhoun-diameter-accounting-08.txt
       </doc>

       <avp code="480" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Accounting-Record-Type </name>
         <type> Unsigned32 </type>
         <value>
           <val> 1 </val>
        <desc>
          EVENT_RECORD
             An Accounting Event Record is used to indicate
          that a one-time event has occurred (meaning that



Calhoun et al.              expires May 2001                   [Page 65]


INTERNET DRAFT                                             November 2000


          the start and end of the event are simultaneous).
          This record contains all information relevant to
          the service, and is the only record of the service.
           </desc>
         </value>
         <value>
           <val> 2 </val>
        <desc>
             START_RECORD
             An Accounting Start, Interim, and Stop Records are
          used to indicate that a service of a measurable
          length has been given.  An Accounting Start Record
          is used to initiate an accounting session, and
          contains accounting information that is relevant
             to the initiation of the session.
           </desc>
         </value>
         <value>
           <val> 3 </val>
        <desc>
             INTERIM_RECORD
             An Accounting Stop Record is sent to terminate
          an accounting session and contains cumulative
          accounting information relevant to the existing
          session.
           </desc>
         </value>
         <value>
           <val> 4 </val>
        <desc>
             STOP_RECORD
             An Accounting Stop Record is sent to terminate an
          accounting session and contains cumulative accounting
          information relevant to the existing session.
           </desc>
         </value>
       </avp>

       <avp code="481" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> ADIF-Record </name>
         <type> OctetString </type>
       </avp>

       <avp code="482" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Accounting-Interim-Interval </name>
         <type> Unsigned32 </type>



Calhoun et al.              expires May 2001                   [Page 66]


INTERNET DRAFT                                             November 2000


       </avp>

       <avp code="483" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Accounting-Delivery-Max-Batch </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="484" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Accounting-Delivery-Max-Delay </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="485" may-encrypt="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Accounting-Record-Number </name>
         <type> Unsigned32 </type>
       </avp>

       <avp code="486" may-encrypt="true" constrained="true"
        vendor-flag="disallowed" mandatory-flag="required">
         <name> Accounting-State </name>
         <type> Unsigned32 </type>
         <value> <val> 1 </val> <desc> ENABLED </desc> </value>
         <value> <val> 2 </val> <desc> DISABLED </desc> </value>
       </avp>

     </extension>

   </diameter>




















Calhoun et al.              expires May 2001                   [Page 67]