tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3588


Pages: 147
Top     in Index     Prev     Next
 

Diameter Base Protocol

Part 1 of 5, p. 1 to 25
None       Next RFC Part

Obsoleted by:    6733
Updated by:    5729    5719    6408


Top       ToC       Page 1 
Network Working Group                                         P. Calhoun
Request for Comments: 3588                               Airespace, Inc.
Category: Standards Track                                    J. Loughney
                                                                   Nokia
                                                              E. Guttman
                                                  Sun Microsystems, Inc.
                                                                 G. Zorn
                                                     Cisco Systems, Inc.
                                                                J. Arkko
                                                                Ericsson
                                                          September 2003


                         Diameter Base Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   The Diameter base protocol is intended to provide an Authentication,
   Authorization and Accounting (AAA) framework for applications such as
   network access or IP mobility.  Diameter is also intended to work in
   both local Authentication, Authorization & Accounting and roaming
   situations.  This document specifies the message format, transport,
   error reporting, accounting and security services to be used by all
   Diameter applications.  The Diameter base application needs to be
   supported by all Diameter implementations.

Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [KEYWORD].

Top       Page 2 
Table of Contents

   1.  Introduction.................................................   6
       1.1.   Diameter Protocol.....................................   9
              1.1.1.   Description of the Document Set..............  10
       1.2.   Approach to Extensibility.............................  11
              1.2.1.   Defining New AVP Values......................  11
              1.2.2.   Creating New AVPs............................  11
              1.2.3.   Creating New Authentication Applications.....  11
              1.2.4.   Creating New Accounting Applications.........  12
              1.2.5.   Application Authentication Procedures........  14
       1.3.   Terminology...........................................  14
   2.  Protocol Overview............................................  18
       2.1.   Transport.............................................  20
              2.1.1.   SCTP Guidelines..............................  21
       2.2.   Securing Diameter Messages............................  21
       2.3.   Diameter Application Compliance.......................  21
       2.4.   Application Identifiers...............................  22
       2.5.   Connections vs. Sessions..............................  22
       2.6.   Peer Table............................................  23
       2.7.   Realm-Based Routing Table.............................  24
       2.8.   Role of Diameter Agents...............................  25
              2.8.1.   Relay Agents.................................  26
              2.8.2.   Proxy Agents.................................  27
              2.8.3.   Redirect Agents..............................  28
              2.8.4.   Translation Agents...........................  29
       2.9.   End-to-End Security Framework.........................  30
       2.10.  Diameter Path Authorization...........................  30
   3.  Diameter Header..............................................  32
       3.1.   Command Codes.........................................  35
       3.2.   Command Code ABNF specification.......................  36
       3.3.   Diameter Command Naming Conventions...................  38
   4.  Diameter AVPs................................................  38
       4.1.   AVP Header............................................  39
              4.1.1.   Optional Header Elements.....................  41
       4.2.   Basic AVP Data Formats................................  41
       4.3.   Derived AVP Data Formats..............................  42
       4.4.   Grouped AVP Values....................................  49
              4.4.1.   Example AVP with a Grouped Data Type.........  50
       4.5.   Diameter Base Protocol AVPs...........................  53
   5.  Diameter Peers...............................................  56
       5.1.   Peer Connections......................................  56
       5.2.   Diameter Peer Discovery...............................  56
       5.3.   Capabilities Exchange.................................  59
              5.3.1.   Capabilities-Exchange-Request................  60
              5.3.2.   Capabilities-Exchange-Answer.................  60
              5.3.3.   Vendor-Id AVP................................  61
              5.3.4.   Firmware-Revision AVP........................  61

Top      ToC       Page 3 
              5.3.5.   Host-IP-Address AVP..........................  62
              5.3.6.   Supported-Vendor-Id AVP......................  62
              5.3.7.   Product-Name AVP.............................  62
       5.4.   Disconnecting Peer Connections........................  62
              5.4.1.   Disconnect-Peer-Request......................  63
              5.4.2.   Disconnect-Peer-Answer.......................  63
              5.4.3.   Disconnect-Cause AVP.........................  63
       5.5.   Transport Failure Detection...........................  64
              5.5.1.   Device-Watchdog-Request......................  64
              5.5.2.   Device-Watchdog-Answer.......................  64
              5.5.3.   Transport Failure Algorithm..................  65
              5.5.4.   Failover and Failback Procedures.............  65
       5.6.   Peer State Machine....................................  66
              5.6.1.   Incoming connections.........................  68
              5.6.2.   Events.......................................  69
              5.6.3.   Actions......................................  70
              5.6.4.   The Election Process.........................  71
   6.  Diameter Message Processing..................................  71
       6.1.   Diameter Request Routing Overview.....................  71
              6.1.1.   Originating a Request........................  73
              6.1.2.   Sending a Request............................  73
              6.1.3.   Receiving Requests...........................  73
              6.1.4.   Processing Local Requests....................  73
              6.1.5.   Request Forwarding...........................  74
              6.1.6.   Request Routing..............................  74
              6.1.7.   Redirecting Requests.........................  74
              6.1.8.   Relaying and Proxying Requests...............  75
       6.2.   Diameter Answer Processing............................  76
              6.2.1.   Processing Received Answers..................  77
              6.2.2.   Relaying and Proxying Answers................  77
       6.3.   Origin-Host AVP.......................................  77
       6.4.   Origin-Realm AVP......................................  78
       6.5.   Destination-Host AVP..................................  78
       6.6.   Destination-Realm AVP.................................  78
       6.7.   Routing AVPs..........................................  78
              6.7.1.   Route-Record AVP.............................  79
              6.7.2.   Proxy-Info AVP...............................  79
              6.7.3.   Proxy-Host AVP...............................  79
              6.7.4.   Proxy-State AVP..............................  79
       6.8.   Auth-Application-Id AVP...............................  79
       6.9.   Acct-Application-Id AVP...............................  79
       6.10.  Inband-Security-Id AVP................................  79
       6.11.  Vendor-Specific-Application-Id AVP....................  80
       6.12.  Redirect-Host AVP.....................................  80
       6.13.  Redirect-Host-Usage AVP...............................  80
       6.14.  Redirect-Max-Cache-Time AVP...........................  81
       6.15.  E2E-Sequence AVP......................................  82

Top      ToC       Page 4 
   7.  Error Handling...............................................  82
       7.1.   Result-Code AVP.......................................  84
              7.1.1.   Informational................................  84
              7.1.2.   Success......................................  84
              7.1.3.   Protocol Errors..............................  85
              7.1.4.   Transient Failures...........................  86
              7.1.5.   Permanent Failures...........................  86
       7.2.   Error Bit.............................................  88
       7.3.   Error-Message AVP.....................................  89
       7.4.   Error-Reporting-Host AVP..............................  89
       7.5.   Failed-AVP AVP........................................  89
       7.6.   Experimental-Result AVP...............................  90
       7.7.   Experimental-Result-Code AVP..........................  90
   8.  Diameter User Sessions.......................................  90
       8.1.   Authorization Session State Machine...................  92
       8.2.   Accounting Session State Machine......................  96
       8.3.   Server-Initiated Re-Auth.............................. 101
              8.3.1.   Re-Auth-Request.............................. 102
              8.3.2.   Re-Auth-Answer............................... 102
       8.4.   Session Termination................................... 103
              8.4.1.   Session-Termination-Request.................. 104
              8.4.2.   Session-Termination-Answer................... 105
       8.5.   Aborting a Session.................................... 105
              8.5.1.   Abort-Session-Request........................ 106
              8.5.2.   Abort-Session-Answer......................... 106
       8.6.   Inferring Session Termination from Origin-State-Id.... 107
       8.7.   Auth-Request-Type AVP................................. 108
       8.8.   Session-Id AVP........................................ 108
       8.9.   Authorization-Lifetime AVP............................ 109
       8.10.  Auth-Grace-Period AVP................................. 110
       8.11.  Auth-Session-State AVP................................ 110
       8.12.  Re-Auth-Request-Type AVP.............................. 110
       8.13.  Session-Timeout AVP................................... 111
       8.14.  User-Name AVP......................................... 111
       8.15.  Termination-Cause AVP................................. 111
       8.16.  Origin-State-Id AVP................................... 112
       8.17.  Session-Binding AVP................................... 113
       8.18.  Session-Server-Failover AVP........................... 113
       8.19.  Multi-Round-Time-Out AVP.............................. 114
       8.20.  Class AVP............................................. 114
       8.21.  Event-Timestamp AVP................................... 115
   9.  Accounting................................................... 115
       9.1.   Server Directed Model................................. 115
       9.2.   Protocol Messages..................................... 116
       9.3.   Application Document Requirements..................... 116
       9.4.   Fault Resilience...................................... 116
       9.5.   Accounting Records.................................... 117
       9.6.   Correlation of Accounting Records..................... 118

Top      ToC       Page 5 
       9.7.   Accounting Command-Codes.............................. 119
              9.7.1.   Accounting-Request........................... 119
              9.7.2.   Accounting-Answer............................ 120
       9.8.   Accounting AVPs....................................... 121
              9.8.1.   Accounting-Record-Type AVP................... 121
              9.8.2.   Acct-Interim-Interval AVP.................... 122
              9.8.3.   Accounting-Record-Number AVP................. 123
              9.8.4.   Acct-Session-Id AVP.......................... 123
              9.8.5.   Acct-Multi-Session-Id AVP.................... 123
              9.8.6.   Accounting-Sub-Session-Id AVP................ 123
              9.8.7.   Accounting-Realtime-Required AVP............. 123
   10. AVP Occurrence Table......................................... 124
       10.1.  Base Protocol Command AVP Table....................... 124
       10.2.  Accounting AVP Table.................................. 126
   11. IANA Considerations.......................................... 127
       11.1.  AVP Header............................................ 127
              11.1.1.  AVP Code..................................... 127
              11.1.2.  AVP Flags.................................... 128
       11.2.  Diameter Header....................................... 128
              11.2.1.  Command Codes................................ 128
              11.2.2.  Command Flags................................ 129
       11.3.  Application Identifiers............................... 129
       11.4.  AVP Values............................................ 129
              11.4.1.  Result-Code AVP Values....................... 129
              11.4.2.  Accounting-Record-Type AVP Values............ 130
              11.4.3.  Termination-Cause AVP Values................. 130
              11.4.4.  Redirect-Host-Usage AVP Values............... 130
              11.4.5.  Session-Server-Failover AVP Values........... 130
              11.4.6.  Session-Binding AVP Values................... 130
              11.4.7.  Disconnect-Cause AVP Values.................. 130
              11.4.8.  Auth-Request-Type AVP Values................. 130
              11.4.9.  Auth-Session-State AVP Values................ 130
              11.4.10. Re-Auth-Request-Type AVP Values.............. 131
              11.4.11. Accounting-Realtime-Required AVP Values...... 131
       11.5.  Diameter TCP/SCTP Port Numbers........................ 131
       11.6.  NAPTR Service Fields.................................. 131
   12. Diameter Protocol Related Configurable Parameters............ 131
   13. Security Considerations...................................... 132
       13.1.  IPsec Usage........................................... 133
       13.2.  TLS Usage............................................. 134
       13.3.  Peer-to-Peer Considerations........................... 134
   14. References................................................... 136
       14.1.  Normative References.................................. 136
       14.2.  Informative References................................ 138
   15. Acknowledgements............................................. 140
   Appendix A.  Diameter Service Template........................... 141
   Appendix B.  NAPTR Example....................................... 142
   Appendix C.  Duplicate Detection................................. 143

Top      ToC       Page 6 
   Appendix D.  Intellectual Property Statement..................... 145
   Authors' Addresses............................................... 146
   Full Copyright Statement......................................... 147

1.  Introduction

   Authentication, Authorization and Accounting (AAA) protocols such as
   TACACS [TACACS] and RADIUS [RADIUS] were initially deployed to
   provide dial-up PPP [PPP] and terminal server access.  Over time,
   with the growth of the Internet and the introduction of new access
   technologies, including wireless, DSL, Mobile IP and Ethernet,
   routers and network access servers (NAS) have increased in complexity
   and density, putting new demands on AAA protocols.

   Network access requirements for AAA protocols are summarized in
   [AAAREQ].  These include:

   Failover
      [RADIUS] does not define failover mechanisms, and as a result,
      failover behavior differs between implementations.  In order to
      provide well defined failover behavior, Diameter supports
      application-layer acknowledgements, and defines failover
      algorithms and the associated state machine.  This is described in
      Section 5.5 and [AAATRANS].

   Transmission-level security
      [RADIUS] defines an application-layer authentication and integrity
      scheme that is required only for use with Response packets.  While
      [RADEXT] defines an additional authentication and integrity
      mechanism, use is only required during Extensible Authentication
      Protocol (EAP) sessions.  While attribute-hiding is supported,
      [RADIUS] does not provide support for per-packet confidentiality.
      In accounting, [RADACCT] assumes that replay protection is
      provided by the backend billing server, rather than within the
      protocol itself.

      While [RFC3162] defines the use of IPsec with RADIUS, support for
      IPsec is not required.  Since within [IKE] authentication occurs
      only within Phase 1 prior to the establishment of IPsec SAs in
      Phase 2, it is typically not possible to define separate trust or
      authorization schemes for each application.  This limits the
      usefulness of IPsec in inter-domain AAA applications (such as
      roaming) where it may be desirable to define a distinct
      certificate hierarchy for use in a AAA deployment.  In order to
      provide universal support for transmission-level security, and
      enable both intra- and inter-domain AAA deployments, IPsec support
      is mandatory in Diameter, and TLS support is optional.  Security
      is discussed in Section 13.

Top      ToC       Page 7 
   Reliable transport
      RADIUS runs over UDP, and does not define retransmission behavior;
      as a result, reliability varies between implementations.  As
      described in [ACCMGMT], this is a major issue in accounting, where
      packet loss may translate directly into revenue loss.  In order to
      provide well defined transport behavior, Diameter runs over
      reliable transport mechanisms (TCP, SCTP) as defined in
      [AAATRANS].

   Agent support
      [RADIUS] does not provide for explicit support for agents,
      including Proxies, Redirects and Relays.  Since the expected
      behavior is not defined, it varies between implementations.
      Diameter defines agent behavior explicitly; this is described in
      Section 2.8.

   Server-initiated messages
      While RADIUS server-initiated messages are defined in [DYNAUTH],
      support is optional.  This makes it difficult to implement
      features such as unsolicited disconnect or
      reauthentication/reauthorization on demand across a heterogeneous
      deployment.  Support for server-initiated messages is mandatory in
      Diameter, and is described in Section 8.

   Auditability
      RADIUS does not define data-object security mechanisms, and as a
      result, untrusted proxies may modify attributes or even packet
      headers without being detected.  Combined with lack of support for
      capabilities negotiation, this makes it very difficult to
      determine what occurred in the event of a dispute.  While
      implementation of data object security is not mandatory within
      Diameter, these capabilities are supported, and are described in
      [AAACMS].

   Transition support
      While Diameter does not share a common protocol data unit (PDU)
      with RADIUS, considerable effort has been expended in enabling
      backward compatibility with RADIUS, so that the two protocols may
      be deployed in the same network.  Initially, it is expected that
      Diameter will be deployed within new network devices, as well as
      within gateways enabling communication between legacy RADIUS
      devices and Diameter agents.  This capability, described in
      [NASREQ], enables Diameter support to be added to legacy networks,
      by addition of a gateway or server speaking both RADIUS and
      Diameter.

Top      ToC       Page 8 
   In addition to addressing the above requirements, Diameter also
   provides support for the following:

   Capability negotiation
      RADIUS does not support error messages, capability negotiation, or
      a mandatory/non-mandatory flag for attributes.  Since RADIUS
      clients and servers are not aware of each other's capabilities,
      they may not be able to successfully negotiate a mutually
      acceptable service, or in some cases, even be aware of what
      service has been implemented.  Diameter includes support for error
      handling (Section 7), capability negotiation (Section 5.3), and
      mandatory/non-mandatory attribute-value pairs (AVPs) (Section
      4.1).

   Peer discovery and configuration
      RADIUS implementations typically require that the name or address
      of servers or clients be manually configured, along with the
      corresponding shared secrets.  This results in a large
      administrative burden, and creates the temptation to reuse the
      RADIUS shared secret, which can result in major security
      vulnerabilities if the Request Authenticator is not globally and
      temporally unique as required in [RADIUS].  Through DNS, Diameter
      enables dynamic discovery of peers.  Derivation of dynamic session
      keys is enabled via transmission-level security.

   Roaming support
      The ROAMOPS WG provided a survey of roaming implementations
      [ROAMREV], detailed roaming requirements [ROAMCRIT], defined the
      Network Access Identifier (NAI) [NAI], and documented existing
      implementations (and imitations) of RADIUS-based roaming
      [PROXYCHAIN].  In order to improve scalability, [PROXYCHAIN]
      introduced the concept of proxy chaining via an intermediate
      server, facilitating roaming between providers.  However, since
      RADIUS does not provide explicit support for proxies, and lacks
      auditability and transmission-level security features, RADIUS-
      based roaming is vulnerable to attack from external parties as
      well as susceptible to fraud perpetrated by the roaming partners
      themselves.  As a result, it is not suitable for wide-scale
      deployment on the Internet [PROXYCHAIN].  By providing explicit
      support for inter-domain roaming and message routing (Sections 2.7
      and 6), auditability [AAACMS], and transmission-layer security
      (Section 13) features, Diameter addresses these limitations and
      provides for secure and scalable roaming.

   In the decade since AAA protocols were first introduced, the
   capabilities of Network Access Server (NAS) devices have increased
   substantially.  As a result, while Diameter is a considerably more
   sophisticated protocol than RADIUS, it remains feasible to implement

Top      ToC       Page 9 
   within embedded devices, given improvements in processor speeds and
   the widespread availability of embedded IPsec and TLS
   implementations.

1.1.  Diameter Protocol

   The Diameter base protocol provides the following facilities:

   -  Delivery of AVPs (attribute value pairs)
   -  Capabilities negotiation
   -  Error notification
   -  Extensibility, through addition of new commands and AVPs (required
      in [AAAREQ]).
   -  Basic services necessary for applications, such as handling of
      user sessions or accounting

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

   -  Transporting of user authentication information, for the purposes
      of enabling the Diameter server to authenticate the user.

   -  Transporting of service specific authorization information,
      between client and servers, allowing the peers to decide whether a
      user's access request should be granted.

   -  Exchanging resource usage information, which MAY be used for
      accounting purposes, capacity planning, etc.

   -  Relaying, proxying and redirecting of Diameter messages through a
      server hierarchy.

   The Diameter base protocol provides the minimum requirements needed
   for a AAA protocol, as required by [AAAREQ].  The base protocol may
   be used by itself for accounting purposes only, or it may be used
   with a Diameter application, such as Mobile IPv4 [DIAMMIP], or
   network access [NASREQ].  It is also possible for the base protocol
   to be extended for use in new applications, via the addition of new
   commands or AVPs.  At this time the focus of Diameter is network
   access and accounting applications.  A truly generic AAA protocol
   used by many applications might provide functionality not provided by
   Diameter.  Therefore, it is imperative that the designers of new
   applications understand their requirements before using Diameter.

Top      ToC       Page 10 
   See Section 2.4 for more information on Diameter applications.

   Any node can initiate a request.  In that sense, Diameter is a peer-
   to-peer protocol.  In this document, a Diameter Client is a device at
   the edge of the network that performs access control, such as a
   Network Access Server (NAS) or a Foreign Agent (FA).  A Diameter
   client generates Diameter messages to request authentication,
   authorization, and accounting services for the user.  A Diameter
   agent is a node that does not authenticate and/or authorize messages
   locally; agents include proxies, redirects and relay agents.  A
   Diameter server performs authentication and/or authorization of the
   user.  A Diameter node MAY act as an agent for certain requests while
   acting as a server for others.

   The Diameter protocol also supports server-initiated messages, such
   as a request to abort service to a particular user.

1.1.1.  Description of the Document Set

   Currently, the Diameter specification consists of a base
   specification (this document), Transport Profile [AAATRANS] and
   applications: Mobile IPv4 [DIAMMIP], and NASREQ [NASREQ].

   The Transport Profile document [AAATRANS] discusses transport layer
   issues that arise with AAA protocols and recommendations on how to
   overcome these issues.  This document also defines the Diameter
   failover algorithm and state machine.

   The Mobile IPv4 [DIAMMIP] application defines a Diameter application
   that allows a Diameter server to perform AAA functions for Mobile
   IPv4 services to a mobile node.

   The NASREQ [NASREQ] application defines a Diameter Application that
   allows a Diameter server to be used in a PPP/SLIP Dial-Up and
   Terminal Server Access environment.  Consideration was given for
   servers that need to perform protocol conversion between Diameter and
   RADIUS.

   In summary, this document defines the base protocol specification for
   AAA, which includes support for accounting.  The Mobile IPv4 and the
   NASREQ  documents describe applications that use this base
   specification for Authentication, Authorization and Accounting.

Top      ToC       Page 11 
1.2.  Approach to Extensibility

   The Diameter protocol is designed to be extensible, using several
   mechanisms, including:

      -  Defining new AVP values
      -  Creating new AVPs
      -  Creating new authentication/authorization applications
      -  Creating new accounting applications
      -  Application authentication procedures

   Reuse of existing AVP values, AVPs and Diameter applications are
   strongly recommended.  Reuse simplifies standardization and
   implementation and avoids potential interoperability issues.  It is
   expected that command codes are reused; new command codes can only be
   created by IETF Consensus (see Section 11.2.1).

1.2.1.  Defining New AVP Values

   New applications should attempt to reuse AVPs defined in existing
   applications when possible, as opposed to creating new AVPs.  For
   AVPs of type Enumerated, an application may require a new value to
   communicate some service-specific information.

   In order to allocate a new AVP value, a request MUST be sent to IANA
   [IANA], along with an explanation of the new AVP value.  IANA
   considerations for Diameter are discussed in Section 11.

1.2.2.  Creating New AVPs

   When no existing AVP can be used, a new AVP should be created.  The
   new AVP being defined MUST use one of the data types listed in
   Section 4.2.

   In the event that a logical grouping of AVPs is necessary, and
   multiple "groups" are possible in a given command, it is recommended
   that a Grouped AVP be used (see Section 4.4).

   In order to create a new AVP, a request MUST be sent to IANA, with a
   specification for the AVP.  The request MUST include the commands
   that would make use of the AVP.

1.2.3.  Creating New Authentication Applications

   Every Diameter application specification MUST have an IANA assigned
   Application Identifier (see Section 2.4) or a vendor specific
   Application Identifier.

Top      ToC       Page 12 
   Should a new Diameter usage scenario find itself unable to fit within
   an existing application without requiring major changes to the
   specification, it may be desirable to create a new Diameter
   application.  Major changes to an application include:

   -  Adding new AVPs to the command, which have the "M" bit set.

   -  Requiring a command that has a different number of round trips to
      satisfy a request (e.g., application foo has a command that
      requires one round trip, but new application bar has a command
      that requires two round trips to complete).

   -  Adding support for an authentication method requiring definition
      of new AVPs for use with the application.  Since a new EAP
      authentication method can be supported within Diameter without
      requiring new AVPs, addition of EAP methods does not require the
      creation of a new authentication application.

   Creation of a new application should be viewed as a last resort.  An
   implementation MAY add arbitrary non-mandatory AVPs to any command
   defined in an application, including vendor-specific AVPs without
   needing to define a new application.  Please refer to Section 11.1.1
   for details.

   In order to justify allocation of a new application identifier,
   Diameter applications MUST define one Command Code, or add new
   mandatory AVPs to the ABNF.

   The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see
   Section 3.2).  If the Diameter application has accounting
   requirements, it MUST also specify the AVPs that are to be present in
   the Diameter Accounting messages (see Section 9.3).  However, just
   because a new authentication application id is required, does not
   imply that a new accounting application id is required.

   When possible, a new Diameter application SHOULD reuse existing
   Diameter AVPs, in order to avoid defining multiple AVPs that carry
   similar information.

1.2.4.  Creating New Accounting Applications

   There are services that only require Diameter accounting.  Such
   services need to define the AVPs carried in the Accounting-Request
   (ACR)/ Accounting-Answer (ACA) messages, but do not need to define
   new command codes.  An implementation MAY add arbitrary non-mandatory
   AVPs (AVPs with the "M" bit not set) to any command defined in an

Top      ToC       Page 13 
   application, including vendor-specific AVPs, without needing to
   define a new accounting application.  Please refer to Section 11.1.1
   for details.

   Application Identifiers are still required for Diameter capability
   exchange.  Every Diameter accounting application specification MUST
   have an IANA assigned Application Identifier (see Section 2.4) or a
   vendor specific Application Identifier.

   Every Diameter implementation MUST support accounting.  Basic
   accounting support is sufficient to handle any application that uses
   the ACR/ACA commands defined in this document, as long as no new
   mandatory AVPs are added.  A mandatory AVP is defined as one which
   has the "M" bit set when sent within an accounting command,
   regardless of whether it is required or optional within the ABNF for
   the accounting application.

   The creation of a new accounting application should be viewed as a
   last resort and MUST NOT be used unless a new command or additional
   mechanisms (e.g., application defined state machine) is defined
   within the application, or new mandatory AVPs are added to the ABNF.

   Within an accounting command, setting the "M" bit implies that a
   backend server (e.g., billing server) or the accounting server itself
   MUST understand the AVP in order to compute a correct bill.  If the
   AVP is not relevant to the billing process, when the AVP is included
   within an accounting command, it MUST NOT have the "M" bit set, even
   if the "M" bit is set when the same AVP is used within other Diameter
   commands (i.e., authentication/authorization commands).

   A DIAMETER base accounting implementation MUST be configurable to
   advertise supported accounting applications in order to prevent the
   accounting server from accepting accounting requests for unbillable
   services.  The combination of the home domain and the accounting
   application Id can be used in order to route the request to the
   appropriate accounting server.

   When possible, a new Diameter accounting application SHOULD attempt
   to reuse existing AVPs, in order to avoid defining multiple AVPs that
   carry similar information.

   If the base accounting is used without any mandatory AVPs, new
   commands or additional mechanisms (e.g., application defined state
   machine), then the base protocol defined standard accounting
   application Id (Section 2.4) MUST be used in ACR/ACA commands.

Top      ToC       Page 14 
1.2.5.  Application Authentication Procedures

   When possible, applications SHOULD be designed such that new
   authentication methods MAY be added without requiring changes to the
   application.  This MAY require that new AVP values be assigned to
   represent the new authentication transform, or any other scheme that
   produces similar results.  When possible, authentication frameworks,
   such as Extensible Authentication Protocol [EAP], SHOULD be used.

1.3.  Terminology

   AAA
      Authentication, Authorization and Accounting.

   Accounting
      The act of collecting information on resource usage for the
      purpose of capacity planning, auditing, billing or cost
      allocation.

   Accounting Record
      An accounting record represents a summary of the resource
      consumption of a user over the entire session.  Accounting servers
      creating the accounting record may do so by processing interim
      accounting events or accounting events from several devices
      serving the same user.

   Authentication
      The act of verifying the identity of an entity (subject).

   Authorization
      The act of determining whether a requesting entity (subject) will
      be allowed access to a resource (object).

   AVP
      The Diameter protocol consists of a header followed by one or more
      Attribute-Value-Pairs (AVPs).  An AVP includes a header and is
      used to encapsulate protocol-specific data (e.g., routing
      information) as well as authentication, authorization or
      accounting information.

   Broker
      A broker is a business term commonly used in AAA infrastructures.
      A broker is either a relay, proxy or redirect agent, and MAY be
      operated by roaming consortiums.  Depending on the business model,
      a broker may either choose to  deploy relay agents or proxy
      agents.

Top      ToC       Page 15 
   Diameter Agent
      A Diameter Agent is a Diameter node that provides either relay,
      proxy, redirect or translation services.

   Diameter Client
      A Diameter Client is a device at the edge of the network that
      performs access control.  An example of a Diameter client is a
      Network Access Server (NAS) or a Foreign Agent (FA).

   Diameter Node
      A Diameter node is a host process that implements the Diameter
      protocol, and acts either as a Client, Agent or Server.

   Diameter Peer
      A Diameter Peer is a Diameter Node to which a given Diameter Node
      has a direct transport connection.

   Diameter Security Exchange
      A Diameter Security Exchange is a process through which two
      Diameter nodes establish end-to-end security.

   Diameter Server
      A Diameter Server is one that handles authentication,
      authorization and accounting requests for a particular realm.  By
      its very nature, a Diameter Server MUST support Diameter
      applications in addition to the base protocol.

   Downstream
      Downstream is used to identify the direction of a particular
      Diameter message from the home server towards the access device.

   End-to-End Security
      TLS and IPsec provide hop-by-hop security, or security across a
      transport connection.  When relays or proxy are involved, this
      hop-by-hop security does not protect the entire Diameter user
      session.  End-to-end security is security between two Diameter
      nodes, possibly communicating through Diameter Agents.  This
      security protects the entire Diameter communications path from the
      originating Diameter node to the terminating Diameter node.

   Home Realm
      A Home Realm is the administrative domain with which the user
      maintains an account relationship.

   Home Server
      See Diameter Server.

Top      ToC       Page 16 
   Interim accounting
      An interim accounting message provides a snapshot of usage during
      a user's session.  It is typically implemented in order to provide
      for partial accounting of a user's session in the case of a device
      reboot or other network problem prevents the reception of a
      session summary message or session record.

   Local Realm
      A local realm is the administrative domain providing services to a
      user.  An administrative domain MAY act as a local realm for
      certain users, while being a home realm for others.

   Multi-session
      A multi-session represents a logical linking of several sessions.
      Multi-sessions are tracked by using the Acct-Multi-Session-Id.  An
      example of a multi-session would be a Multi-link PPP bundle.  Each
      leg of the bundle would be a session while the entire bundle would
      be a multi-session.

   Network Access Identifier
      The Network Access Identifier, or NAI [NAI], is used in the
      Diameter protocol to extract a user's identity and realm.  The
      identity is used to identify the user during authentication and/or
      authorization, while the realm is used for message routing
      purposes.

   Proxy Agent or Proxy
      In addition to forwarding requests and responses, proxies make
      policy decisions relating to resource usage and provisioning.
      This is typically accomplished by tracking the state of NAS
      devices.  While proxies typically do not respond to client
      Requests prior to receiving a Response from the server, they may
      originate Reject messages in cases where policies are violated.
      As a result, proxies need to understand the semantics of the
      messages passing through them, and may not support all Diameter
      applications.

   Realm
      The string in the NAI that immediately follows the '@' character.
      NAI realm names are required to be unique, and are piggybacked on
      the administration of the DNS namespace.  Diameter makes use of
      the realm, also loosely referred to as domain, to determine
      whether messages can be satisfied locally, or whether they must be
      routed or redirected.  In RADIUS, realm names are not necessarily
      piggybacked on the DNS namespace but may be independent of it.

Top      ToC       Page 17 
   Real-time Accounting
      Real-time accounting involves the processing of information on
      resource usage within a defined time window.  Time constraints are
      typically imposed in order to limit financial risk.

   Relay Agent or Relay
      Relays forward requests and responses based on routing-related
      AVPs and realm routing table entries.  Since relays do not make
      policy decisions, they do not examine or alter non-routing AVPs.
      As a result, relays never originate messages, do not need to
      understand the semantics of messages or non-routing AVPs, and are
      capable of handling any Diameter application or message type.
      Since relays make decisions based on information in routing AVPs
      and realm forwarding tables they do not keep state on NAS resource
      usage or sessions in progress.

   Redirect Agent
      Rather than forwarding requests and responses between clients and
      servers, redirect agents refer clients to servers and allow them
      to communicate directly.  Since redirect agents do not sit in the
      forwarding path, they do not alter any AVPs transiting between
      client and server.  Redirect agents do not originate messages and
      are capable of handling any message type, although they may be
      configured only to redirect messages of certain types, while
      acting as relay or proxy agents for other types.  As with proxy
      agents, redirect agents do not keep state with respect to sessions
      or NAS resources.

   Roaming Relationships
      Roaming relationships include relationships between companies and
      ISPs, relationships among peer ISPs within a roaming consortium,
      and relationships between an ISP and a roaming consortium.

   Security Association
      A security association is an association between two endpoints in
      a Diameter session which allows the endpoints to communicate with
      integrity and confidentially, even in the presence of relays
      and/or proxies.

   Session
      A session is a related progression of events devoted to a
      particular activity.  Each application SHOULD provide guidelines
      as to when a session begins and ends.  All Diameter packets with
      the same Session-Identifier are considered to be part of the same
      session.

Top      ToC       Page 18 
   Session state
      A stateful agent is one that maintains session state information,
      by keeping track of all authorized active sessions.  Each
      authorized session is bound to a particular service, and its state
      is considered active either until it is notified otherwise, or by
      expiration.

   Sub-session
      A sub-session represents a distinct service (e.g., QoS or data
      characteristics) provided to a given session.  These services may
      happen concurrently (e.g., simultaneous voice and data transfer
      during the same session) or serially.  These changes in sessions
      are tracked with the Accounting-Sub-Session-Id.

   Transaction state
      The Diameter protocol requires that agents maintain transaction
      state, which is used for failover purposes.  Transaction state
      implies that upon forwarding a request, the Hop-by-Hop identifier
      is saved; the field is replaced with a locally unique identifier,
      which is restored to its original value when the corresponding
      answer is received.  The request's state is released upon receipt
      of the answer.  A stateless agent is one that only maintains
      transaction state.

   Translation Agent
      A translation agent is a stateful Diameter node that performs
      protocol translation between Diameter and another AAA protocol,
      such as RADIUS.

   Transport Connection
      A transport connection is a TCP or SCTP connection existing
      directly between two Diameter peers, otherwise known as a Peer-
      to-Peer Connection.

   Upstream
      Upstream is used to identify the direction of a particular
      Diameter message from the access device towards the home server.

   User
      The entity requesting or using some resource, in support of which
      a Diameter client has generated a request.

2.  Protocol Overview

   The base Diameter protocol may be used by itself for accounting
   applications, but for use in authentication and authorization it is
   always extended for a particular application.  Two Diameter
   applications are defined by companion documents:  NASREQ [NASREQ],

Top      ToC       Page 19 
   Mobile IPv4 [DIAMMIP].  These applications are introduced in this
   document but specified elsewhere.  Additional Diameter applications
   MAY be defined in the future (see Section 11.3).

   Diameter Clients MUST support the base protocol, which includes
   accounting.  In addition, they MUST fully support each Diameter
   application that is needed to implement the client's service, e.g.,
   NASREQ and/or Mobile IPv4.  A Diameter Client that does not support
   both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
   Client" where X is the application which it supports, and not a
   "Diameter Client".

   Diameter Servers MUST support the base protocol, which includes
   accounting.  In addition, they MUST fully support each Diameter
   application that is needed to implement the intended service, e.g.,
   NASREQ and/or Mobile IPv4.  A Diameter Server that does not support
   both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
   Server" where X is the application which it supports, and not a
   "Diameter Server".

   Diameter Relays and redirect agents are, by definition, protocol
   transparent, and MUST transparently support the Diameter base
   protocol, which includes accounting, and all Diameter applications.

   Diameter proxies MUST support the base protocol, which includes
   accounting.  In addition, they MUST fully support each Diameter
   application that is needed to implement proxied services, e.g.,
   NASREQ and/or Mobile IPv4.  A Diameter proxy which does not support
   also both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X
   Proxy" where X is the application which it supports, and not a
   "Diameter Proxy".

   The base Diameter protocol concerns itself with capabilities
   negotiation, how messages are sent and how peers may eventually be
   abandoned.  The base protocol also defines certain rules that apply
   to all exchanges of messages between Diameter nodes.

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

   The initial request for authentication and/or authorization of a user
   would include the Session-Id.  The Session-Id is then used in all
   subsequent messages to identify the user's session (see Section 8 for
   more information).  The communicating party may accept the request,
   or reject it by returning an answer message with the Result-Code AVP

Top      ToC       Page 20 
   set to indicate an error occurred.  The specific behavior of the
   Diameter server or client receiving a request depends on the Diameter
   application employed.

   Session state (associated with a Session-Id) MUST be freed upon
   receipt of the Session-Termination-Request, Session-Termination-
   Answer, expiration of authorized service time in the Session-Timeout
   AVP, and according to rules established in a particular Diameter
   application.

2.1.  Transport

   Transport profile is defined in [AAATRANS].

   The base Diameter protocol is run on port 3868 of both TCP [TCP] and
   SCTP [SCTP] transport protocols.

   Diameter clients MUST support either TCP or SCTP, while agents and
   servers MUST support both.  Future versions of this specification MAY
   mandate that clients support SCTP.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   MUST be prepared to receive connections on port 3868.  A given
   Diameter instance of the peer state machine MUST NOT use more than
   one transport connection to communicate with a given peer, unless
   multiple instances exist on the peer in which case a separate
   connection per process is allowed.

   When no transport connection exists with a peer, an attempt to
   connect SHOULD be periodically made.  This behavior is handled via
   the Tc timer, whose recommended value is 30 seconds.  There are
   certain exceptions to this rule, such as when a peer has terminated
   the transport connection stating that it does not wish to
   communicate.

   When connecting to a peer and either zero or more transports are
   specified, SCTP SHOULD be tried first, followed by TCP.  See Section
   5.2 for more information on peer discovery.

   Diameter implementations SHOULD be able to interpret ICMP protocol
   port unreachable messages as explicit indications that the server is
   not reachable, subject to security policy on trusting such messages.
   Diameter implementations SHOULD also be able to interpret a reset
   from the transport and timed-out connection attempts.

Top      ToC       Page 21 
   If Diameter receives data up from TCP that cannot be parsed or
   identified as a Diameter error made by the peer, the stream is
   compromised and cannot be recovered.  The transport connection MUST
   be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT
   message (graceful closure is compromised).

2.1.1.  SCTP Guidelines

   The following are guidelines for Diameter implementations that
   support SCTP:

   1. For interoperability: All Diameter nodes MUST be prepared to
      receive Diameter messages on any SCTP stream in the association.

   2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
      streams available to the association to prevent head-of-the-line
      blocking.

2.2.  Securing Diameter Messages

   Diameter clients, such as Network Access Servers (NASes) and Mobility
   Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS].
   Diameter servers MUST support TLS and IPsec.  The Diameter protocol
   MUST NOT be used without any security mechanism (TLS or IPsec).

   It is suggested that IPsec can be used primarily at the edges and in
   intra-domain traffic, such as using pre-shared keys between a NAS a
   local AAA proxy.  This also eases the requirements on the NAS to
   support certificates.  It is also suggested that inter-domain traffic
   would primarily use TLS.  See Sections 13.1 and 13.2 for more details
   on IPsec and TLS usage.

2.3.  Diameter Application Compliance

   Application Identifiers are advertised during the capabilities
   exchange phase (see Section 5.3).  For a given application,
   advertising support of an application implies that the sender
   supports all command codes, and the AVPs specified in the associated
   ABNFs, described in the specification.

   An implementation MAY add arbitrary non-mandatory AVPs to any command
   defined in an application, including vendor-specific AVPs.  Please
   refer to Section 11.1.1 for details.

Top      ToC       Page 22 
2.4.  Application Identifiers

   Each Diameter application MUST have an IANA assigned Application
   Identifier (see Section 11.3).  The base protocol does not require an
   Application Identifier since its support is mandatory.  During the
   capabilities exchange, Diameter nodes inform their peers of locally
   supported applications.  Furthermore, all Diameter messages contain
   an Application Identifier, which is used in the message forwarding
   process.

   The following Application Identifier values are defined:

      Diameter Common Messages      0
      NASREQ                        1 [NASREQ]
      Mobile-IP                     2 [DIAMMIP]
      Diameter Base Accounting      3
      Relay                         0xffffffff

   Relay and redirect agents MUST advertise the Relay Application
   Identifier, while all other Diameter nodes MUST advertise locally
   supported applications.  The receiver of a Capabilities Exchange
   message advertising Relay service MUST assume that the sender
   supports all current and future applications.

   Diameter relay and proxy agents are responsible for finding an
   upstream server that supports the application of a particular
   message.  If none can be found, an error message is returned with the
   Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

2.5.  Connections vs. Sessions

   This section attempts to provide the reader with an understanding of
   the difference between connection and session, which are terms used
   extensively throughout this document.

   A connection is a transport level connection between two peers, used
   to send and receive Diameter messages.  A session is a logical
   concept at the application layer, and is shared between an access
   device and a server, and is identified via the Session-Id AVP

Top      ToC       Page 23 
          +--------+          +-------+          +--------+
          | Client |          | Relay |          | Server |
          +--------+          +-------+          +--------+
                   <---------->       <---------->
                peer connection A   peer connection B

                   <----------------------------->
                           User session x

               Figure 1: Diameter connections and sessions

   In the example provided in Figure 1, peer connection A is established
   between the Client and its local Relay.  Peer connection B is
   established between the Relay and the Server.  User session X spans
   from the Client via the Relay to the Server.  Each "user" of a
   service causes an auth request to be sent, with a unique session
   identifier. Once accepted by the server, both the client and the
   server are aware of the session.  It is important to note that there
   is no relationship between a connection and a session, and that
   Diameter messages for multiple sessions are all multiplexed through a
   single connection.

2.6.  Peer Table

   The Diameter Peer Table is used in message forwarding, and referenced
   by the Realm Routing Table.  A Peer Table entry contains the
   following fields:

   Host identity
      Following the conventions described for the DiameterIdentity
      derived AVP data format in Section 4.4. This field contains the
      contents of the Origin-Host (Section 6.3) AVP found in the CER or
      CEA message.

   StatusT
      This is the state of the peer entry, and MUST match one of the
      values listed in Section 5.6.

   Static or Dynamic
      Specifies whether a peer entry was statically configured, or
      dynamically discovered.

   Expiration time
      Specifies the time at which dynamically discovered peer table
      entries are to be either refreshed, or expired.

Top      ToC       Page 24 
   TLS Enabled
      Specifies whether TLS is to be used when communicating with the
      peer.

   Additional security information, when needed (e.g., keys,
   certificates)

2.7.  Realm-Based Routing Table

   All Realm-Based routing lookups are performed against what is
   commonly known as the Realm Routing Table (see Section 12).  A Realm
   Routing Table Entry contains the following fields:

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

   Application Identifier
      An application is identified by a vendor id and an application id.
      For all IETF standards track Diameter applications, the vendor id
      is zero.  A route entry can have a different destination based on
      the application identification AVP of the message.  This field
      MUST be 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 route entry with
         the Local Action set to Local can be satisfied locally, and do
         not need to be routed to another server.

      2. RELAY - All Diameter messages that fall within this category
         MUST be routed to a next hop server, without modifying any
         non-routing AVPs.  See Section 6.1.8 for relaying guidelines

      3. PROXY - All Diameter messages that fall within this category
         MUST be routed 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 routing.  See Section 6.1.8 for
         proxying guidelines.

      4. 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.1.7
         for redirect guidelines.

Top      ToC       Page 25 
   Server Identifier
      One or more servers the message is to be routed to.  These servers
      MUST also be present in the Peer table. When the Local Action is
      set to RELAY or PROXY, this field contains the identity of the
      server(s) the message must be routed to.  When the Local Action
      field is set to REDIRECT, this field contains the identity of one
      or more servers the message should be redirected to.

   Static or Dynamic
      Specifies whether a route entry was statically configured, or
      dynamically discovered.

   Expiration time
      Specifies the time which a dynamically discovered route table
      entry expires.

   It is important to note that Diameter agents MUST support at least
   one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation.
   Agents do not need to support all modes of operation in order to
   conform with the protocol specification, but MUST follow the protocol
   compliance guidelines in Section 2.  Relay agents MUST NOT reorder
   AVPs, and proxies MUST NOT reorder AVPs.

   The routing table MAY include a default entry that MUST be used for
   any requests not matching any of the other entries.  The routing
   table MAY consist of only such an entry.

   When a request is routed, the target server MUST have advertised the
   Application Identifier (see Section 2.4) for the given message, or
   have advertised itself as a relay or proxy agent.  Otherwise, an
   error is returned with the Result-Code AVP set to
   DIAMETER_UNABLE_TO_DELIVER.



(page 25 continued on part 2)

Next RFC Part