RADIUS/Diameter Protocol Interactions

This section describes some basic guidelines that servers acting as
   AAA Translation Agents may use.  A complete description of all the
   differences between RADIUS and Diameter is beyond the scope of this
   section and document.  Note that this document does not restrict
   implementations from creating additional translation methods, as long
   as the translation function doesn't violate the RADIUS or the
   Diameter protocols.

Although the Diameter protocol is in many ways a superset of RADIUS
   functions, a number of RADIUS representations are not allowed, so
   that new capabilities can be used without the old problems.

   There are primarily two different situations that must be handled:
   one in which a RADIUS request is received that must be forwarded as a
   Diameter request, and another in which the inverse is true.  RADIUS
   does not support a peer-to-peer architecture, and server-initiated
   operations are generally not supported.  See [RADDynAuth] for an
   alternative.

   Some RADIUS attributes are encrypted.  RADIUS security and encryption
   techniques are applied on a hop-per-hop basis.  A Diameter agent will
   have to decrypt RADIUS attribute data entering the Diameter system,
   and if that information is forwarded, the agent MUST secure it by
   using Diameter specific techniques.

   Note that this section uses the two terms, "AVP" and "attribute", in
   a concise and specific manner.  The former is used to signify a
   Diameter AVP, and the latter to signify a RADIUS attribute.

9.1. RADIUS Request Forwarded as Diameter Request

   This section describes the actions that should be taken when a
   Translation Agent receives a RADIUS message to be translated to a
   Diameter message.

   Note that RADIUS servers are assumed to be stateless.  It is also
   quite possible for the RADIUS messages that comprise the session
   (i.e., authentication and accounting messages) to be handled by
   different Translation Agents in the proxy network.  Therefore, a
   RADIUS/Diameter Translation Agent SHOULD NOT be assumed to have an 
When a Translation Agent receives a RADIUS message, the following
   steps should be taken:

      -  If a Message-Authenticator attribute is present, the value MUST
         be checked but not included in the Diameter message.  If it is
         incorrect, the RADIUS message should be silently discarded.
         The gateway system SHOULD generate and include a Message-
         Authenticator in returned RADIUS responses.

      -  The transport address of the sender MUST be checked against the
         NAS identifying attributes.  See the description of NAS-
         Identifier and NAS-IP-Address below.

      -  The Translation Agent must maintain transaction state
         information relevant to the RADIUS request, such as the
         Identifier field in the RADIUS header, any existing RADIUS
         Proxy-State attribute, and the source IP address and port
         number of the UDP packet.  These may be maintained locally in a
         state table or saved in a Proxy-Info AVP group.  A Diameter
         Session-Id AVP value must be created using a session state
         mapping mechanism.

      -  If the RADIUS request contained a State attribute and the
         prefix of the data is "Diameter/", the data following the
         prefix contains the Diameter Origin-Host/Origin-Realm/Session-
         Id.  If no such attributes are present and the RADIUS command
         is an Access-Request, a new Session-Id is created.  The
         Session-Id is included in the Session-Id AVP.

      -  The Diameter Origin-Host and Origin-Realm AVPs MUST be created
         and added by using the information from an FQDN corresponding
         to the NAS-IP-Address attribute (preferred if available),
         and/or to the NAS-Identifier attribute.  (Note that the RADIUS
         NAS-Identifier is not required to be an FQDN.)

      -  The response MUST have an Origin-AAA-Protocol AVP added,
         indicating the protocol of origin of the message.

      -  The Proxy-Info group SHOULD be added, with the local server's
         identity specified in the Proxy-Host AVP.  This should ensure
         that the response is returned to this system.

      -  The Destination-Realm AVP is created from the information found
         in the RADIUS User-Name attribute.
Prev - Next >>