This document discusses RADIUS, a protocol for authentication, authorization, and accounting. It describes key RADIUS features like its client/server model and extensibility. It explains how RADIUS operates, including how clients authenticate users and how servers can accept, reject, or challenge requests. The document also covers RADIUS accounting, shortcomings like lack of failover support, and how Diameter evolved from RADIUS to address some of these issues. It introduces SBR as a Juniper RADIUS product and describes its modular design and features like centralized management, proxy support, and 3GPP integration.

1. RADIUS SBR
in a nutshell

2. Outline
●
AAA.
●
Radius Key Features.
●
Radius Operation.
●
Accounting.
●
SBR.
●
Future.

3. AAA
●
Architecture.
●
Distributed Systems.
●
●
Authentication,
Authorization and
Accounting.
Radius, Diameter.

4. Radius – Key Features
●
Client/Server Model.
●
Network Security.
●
Extensibility (TLVs).
●
Flexible
Authentication.

5. Radius Operation
●
User presents auth info to client.
●
Client sends “message” to Server.
●
Can load-balance servers.
●
Server validates the shared secret.
●
●
●
Radius server consults DB when
receiving the request.
Server can “accept”, “reject”,
“challenge” the user.
If all conditions are met, server
sends a list of configuration values
(like IP address, MTU, .. etc) to the
user in the response.

6. Challenge
●
●
Used with devices
such as smart cards.
Unpredictable
number to the user,
encryption, giving
back the result.

7. Proxy
With proxy RADIUS, one RADIUS server receives an authentication
(or accounting) request from a RADIUS client (such as a NAS),
forwards the request to a remote RADIUS server, receives the reply
from the remote server, and sends that reply to the client, possibly with
changes to reflect local administrative policy.

A common use for proxy RADIUS is roaming.
The choice of which server receives the forwarded request SHOULD
be based on the authentication "realm".


8. UDP
●
●
●
●
Retransmission timers are required.
The timing requirements of this particular
protocol are significantly different than TCP
provides.
The stateless nature of this protocol simplifies
the use of UDP.
UDP simplifies the server implementation.

9. Radius Packet

10. Radius Packet – Code Field
The Code field is one octet, and identifies the type of RADIUS packet.
RADIUS Codes (decimal) are assigned as follows:
1
Access-Request
2
Access-Accept
3
Access-Reject
4
Accounting-Request
5
Accounting-Response
11
Access-Challenge
12
Status-Server (experimental)
13
Status-Client (experimental)
255
Reserved

11. Radius Packet – Identifier Field
●
●
Aids in matching requests and replies.
The RADIUS server can detect a duplicate
request if it has the same client source IP
address and source UDP port and Identifier
within a short span of time.

12. Radius Packet – Authenticator Field
●
This value is used to authenticate the reply
from the RADIUS server, and is used in the
password hiding algorithm.
●
Request Authenticator and Response
Authenticator.

13. Radius Packet – Attributes
●
RADIUS Attributes carry the specific authentication,
authorization, information and configuration details for
the request and reply.
1
User-Name
2
User-Password
3
CHAP-Password
4
NAS-IP-Address
5
NAS-Port
6
Service-Type
….

14. Radius Accounting
●
●
●
●
Client generates an Accounting
start packet to accounting server.
Server acknowledges reception of
the packet.
At the end of the service, client
generates a stop packet.
Server acknowledges reception of
the packet.

15. Radius shortcomings
●
Doesn't define fail-over mechanisms.
●
Does not provide support for per-packet confidentiality.
●
●
●
●
●
In Accounting it assumes that replay protection is provided by the backend
server not the protocol.
Doesn't Define re-transmission (UDP), which is a major issue in
accounting.
does not provide for explicit support for agents, including proxies,
redirects, and relays.
Server-initiated messages are optional.
RADIUS does not support error messages, capability negotiation, or a
mandatory/non-mandatory flag for attributes.

16. Diameter
●
It evolved from and replaces RADIUS protocol.
●
Ability to exchange messages and deliver AVPs.
●
Capabilities negotiation.
●
Error notification.
●
●
Extensibility, required in [RFC2989], through addition
of new applications, commands, and AVPs
Basic services necessary for applications, such as the
handling of user sessions or accounting

17. SBR
●
●
●
●
A Juniper Radius product.
Delivers a total authentication, authorization, and accounting
(AAA) solution on the scale required by Internet service
providers and carriers.
Provides data services for wireline, wireless carriers.
Modular design that supports add-on functionality to meet
your specific site requirements (SIM, CDMA, WiMAX, Session
Control Module).

18. SBR - Features
●
●
●
●
Centralized management of user access control and security simplifies access administration.
powerful proxy RADIUS features enable to easily distribute authentication and accounting requests to
the appropriate RADIUS server for processing.
External authentication features enable you to authenticate against multiple, redundant
Structured Query Language (SQL) or Lightweight Directory Access Protocol (LDAP) databases
according to configurable load balancing and retry strategies.
●
Support for a wide variety of 802.1X-compliant access points and other network access servers.
●
You can define user’s allowed access hours
●
Multiple management interfaces (GUI, LCI, CLI, XML/HTTPS, SNMP).
●
3GPP support facilitates the management of mobile sessions and their associated resources