Diameter Base Protocol (RFC-3588)
It was published on September-2003. It is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. It is intended to work in both local as well as in Roaming Situations. The base protocol needs to be supported by all DIAMETER implementations.
Before DIAMETER there were deployed protocols RADIUS and TACACS to provide dial up connections and terminal access. Because of the internet growth the complexity have increased and generated a demand of new AAA protocols.
The requirement for new AAA protocol was: -
1. Failover
2. Transmission level security
3. Reliable transport
4. Agent support
5. Server-initiated messages
6. Auditability
7. Transition support
Now let me explain each point in details: -
Failover Mechanism
RADIUS does not have any kind of failover mechanism, even it can't have failover mechanism because it is UDP based and UDP does not have implicit handshaking procedures. Therefore once packet has sent on RADIUS it is probably assumed that it will reached to the sender in proper order. While diameter defines the Application layer acknowledgements and failover methods which we will define later.
Transmission Layer Security
RADIUS does not provide per packet confidentiality. RFC-3162 provide IPsec but it is not mandatory, while in diameter it is mandatory to apply per packet confidentiality with the help of IPSec (IP Security) and TLS (Transport Layer Security).
Reliable Transport
RADIUS is based on UDP which makes it unreliable implicitly while the diameter runs over reliable transport medium TCP or SCTP.
Agent Support
RADIUS does not provide for explicit support for agents,including Proxies, Redirects and Relays i.e. Radius does not define the functionality of agents, means which part of the radius message is altered by which agent,While Diameter defines agent behavior explicitly i.e. which agent will alter which part of Diameter message. For example Redirect agent will not alter any part of diameter message/ packet. Each agents behviour is defined later.
Server-initiated messages
Server-initiated messages implies; the messages that server initiates him self for the client. For instance the established connection or session between server and client is disconnected due to some undesirable event, Now server sends a message to client for reconnect or reauthenticate himself. In RADIUS server-initiated messages are defined in [DYNAUTH] (Dynamic Authentication),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.
Auditability
Auditability is the property that allows the system to detect whether the untrusted proxies have altered the message attributes (even packet header) or not. 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 but support within Diameter.
Transition support
Initially, it is expected that Diameter will be deployed within new network devices, ans gateways will enable communication between legacy RADIUS devices and Diameter agents.
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.
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. While this is supported in Diameter. It is later defined in detail.
Peer discovery and Configuration
RADIUS deployment requires 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 issue if the Request Authenticator is not globally and temporally unique as required in . Through DNS, Diameter enables dynamic discovery of peers. Dynamic peer discovery is defined later in detail.
Roaming Support
To improve scalability, the concept of proxy chaining is used 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 as explained above, hence RADIUS- based roaming is open to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves.Thus, it is not suitable for wide-scale deployment on the Internet using proxy chaining . Diameter deals with this problem by providing secure and scalable roaming.
