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.

   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.

   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

   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.

   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.

Prev - Next >>