Diameter

Diameter is a networking protocol which is derived from RADIUS protocol. It is considered to be the next generation Authentication, Authorization, and Accounting (AAA) protocol. This is the other core protocol used in the IP Multimedia Subsystem (IMS) architecture for IMS Entities to exchange AAA related information. Cisco Prime Access Registrar (Prime Access Registrar) supports Diameter Applications based on the Diameter Base Protocol defined in RFC 6733.

Diameter is composed of a base protocol and a set of applications which allows it to extend its services to new access technologies. The base protocol provides basic mechanisms for reliable transport, message delivery, and error handling. Each application is defined by an application identifier and associated with commands. Each command is defined with mandatory Attribute Value Pairs (AVPs) and non-mandatory AVPs including vendor-specific AVPs.

The base protocol must be used in conjunction with a Diameter application. Each application relies on the services of the base protocol to support a specific type of network access.

The following is the list of applications supported by Prime Access Registrar:

Diameter with EAP Support

The Extensible Authentication Protocol (EAP), is an authentication framework which supports multiple authentication mechanisms. EAP may be used on dedicated links, switched circuits, and wired as well as wireless links. For more information on EAP support in Prime Access Registrar, see Chapter5, “Extensible Authentication Protocols”

Prime Access Registrar supports Diameter EAP application that carries EAP packets between a Network Access Server (NAS) working as an EAP Authenticator and a back-end authentication server. The Diameter EAP application is based on the Diameter Network Access Server Application [NASREQ] and is intended for environments similar to NASREQ.

In the Diameter EAP application, authentication occurs between the EAP client and its home Diameter server. This end-to-end authentication reduces the possibility for fraudulent authentication, such as replay and man-in-the-middle attacks. End-to-end authentication also provides a possibility for mutual authentication, which is not possible with PAP and CHAP in a roaming PPP environment.

Advertising Application Support

Diameter nodes conforming to this specification must advertise support by including the Diameter EAP Application ID value of 5 in the Auth-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [BASE].

If the NAS receives a response with the Result-Code set to DIAMETER_APPLICATION_UNSUPPORTED [BASE], it indicates that the Diameter server in the home realm does not support EAP. If possible, the access device may attempt to negotiate another authentication protocol, such as PAP or CHAP. An access device must be cautious when determining whether a less secure authentication protocol will be used, since this could result from a downgrade attack.

Diameter EAP Conversation Flow

The EAP conversation between the authenticating peer and the access device begins with the initiation of EAP within a link layer, such as PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been initiated, the access device will typically send a Diameter-EAP- Request message with an empty EAP-Payload AVP to the Diameter server, signifying an EAP-Start. Prime Access Registrar routes the message to the Diameter EAP service through the rules and policy engine (and/or client, server and vendor scripting point) through which the packet is processed. The Diameter EAP Service forms a Diameter-EAP-Answer message containing an EAP-Payload AVP that includes an encapsulated EAP packet. The Result-Code AVP in the message will be set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is expected.

The access device issues the EAP-Request/Identity message to the EAP client, and forwards the EAP-Response/Identity packet, encapsulated within the EAP-Payload AVP, as a Diameter-EAP-Request to Prime Access Registrar as shown in Figure 4-2. This reduces the number of Diameter message round trips.

Figure 4-2 Diameter EAP Response Flow

The conversation continues until the Diameter server sends a Diameter-EAP-Answer with a Result-Code AVP indicating success or failure, and an optional EAP-Payload. The Result-Code AVP is used by the access device to determine whether service is to be provided to the EAP client or not. The access device must not rely on the contents of the optional EAP-Payload to determine whether service is to be provided or not.

Diameter Stack Level Messages

Capabilities Exchange Message

When Diameter peers establish a transport connection to Prime Access Registrar, they will exchange the Capabilities Exchange messages. This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc.)

Configuring Local Authentication and Authorization

In Diameter, an AA-Request packet is a request for authentication and authorization. Authentication checks username and password credentials, while authorization typically involves returning the correct information to allow the service a user is authorized to have. Prime Access Registrar performs AA and returns the appropriate Diameter attributes in an AA-Answer packet.

Note Prime Access Registrar can only listen to one port for diameter connections. In the above configuration, the port number is 3868. All of the diameter clients must use this port number to communicate with the Prime Access Registrar.

Registering Applications IDs

You need to register the applications IDs for which Prime Access Registrar needs to route the Diameter Messages.

Step 2 Set the AuthApplicationIdList to list of colon separated values of Application Ids.

--> set AuthApplicationIdList "4"

Set AuthApplicationIdList 4

Configuring the Diameter Peers

You need to configure the Diameter Peers such as clients and servers in the
/radius/clients
and /radius/remoteservers directories. The following is an example for configuring a Diameter client:

[ //localhost/Radius/Clients/70dia ]

Name = 70dia

Description =

Protocol = diameter

HostName = 10.81.79.241

PeerPort = 3868

Vendor =

IncomingScript~ =

OutgoingScript~ =

AdvertisedHostName =

AdvertisedRealm =

InitialTimeout = 1000

MaxIncomingRequestRate = 0

WatchDogTimeout = 500

SCTP-Enabled = FALSE

TLS-Enabled = FALSE

The following is an example for configuring a Diameter remote server:

[ //localhost/Radius/RemoteServers/lap ]

Name = lap

Description =

Protocol = diameter

HostName = 10.77.144.34

Port = 3868

DestinationRealm = cisco.com

ReactivateTimerInterval = 300000

Vendor =

IncomingScript~ =

OutgoingScript~ =

MaxTries = 3

MaxTPSLimit = 0

MaxSessionLimit = 0

InitialTimeout = 2000

LimitOutstandingRequests = FALSE

MaxPendingPackets = 0

MaxOutstandingRequests = 0

DWatchDogTimeout = 2500

SCTP-Enabled = FALSE

TLS-Enabled = FALSE

AdvertiseHostName =

AdvertiseRealm =

For description of these properties, see .

Note In order to resolve the hostnames and get the IP addresses, the Prime Access Registrar should either be configured with a DNS server IP, or the client's hostnames and IP addresses should be included in the /etc/hosts file.# Do not remove the following line, or various programs# that require network functionality will fail.127.0.0.1 Prime Access Registrar localhost.localdomain localhost172.16.29.7 GGSN-Gy::1 localhost6.localdomain6 localhost6

Step 5 Set DefaultAuthenticationService and DefaultAuthorizationService in /Radius directory.

--> set DefaultAuthenticationService dia-proxy

Set DefaultAuthenticationService dia-proxy

--> set DefaultAuthorizationService dia-proxy

Set DefaultAuthorizationService dia-proxy

--> save

Validating //localhost...

Saving //localhost...

--> exit

Logging out of localhost...

Step 6 Restart thePrime Access Registrar server.

/cisco-ar/bin/arserver restart

The following illustrates the diameter proxy service configuration which load balances the diameter messages to the remote peers.

[ /Radius/Services/dia-proxy ]

Name = dia-proxy

Description =

Type = diameter

IncomingScript~ =

OutgoingScript~ =

EnableSticky = TRUE

StickySessionKey = Session-Id#1

StickyCreationCmdList = 265

StickyDeletionCmdList = 275

MultiplePeersPolicy = RoundRobin

PeerTimeOutPolicy = FailOver

DiaRemoteServers/

Entries 1 to 2 from 2 total entries

Current filter: <all>

dia1/

Name = dia1

Metric = 2

Weight = 0

IsActive = TRUE

dia2/

Name = dia2

Metric = 3

Weight = 0

IsActive = TRUE

For description of these properties, see .

Group-Based Load Balancing in Diameter Proxy Server Configuration

Prime Access Registrar allows you to create two or more groups of Diameter remote servers in a Diameter proxy service configuration. Each of these groups will have a unique set of remote servers, i.e. no two groups will share the same remote server.

The traffic between each of these groups is load-balanced in failover mode; while traffic between remote servers within the same group is load-balanced based on round-robin or failover mode depending on the existing Diameter configuration. The priority of each of the groups is set with the help of metrics.

The workflow for group-based load balancing is as given below:

1. Traffic from Prime Access Registrar to remote server, via Diameter proxy service, is directed through the first group, till Prime Access Registrar has active communication channel with at least one remote server belonging to the first group.

2. When Prime Access Registrar loses connectivity with all the remote servers in the first group, it directs the rest of the Diameter traffic towards remote servers belonging to the second group.

3. Within a group, the load-balancing logic is chosen based on the configuration:

a. If the load-balancing logic is configured to be round-robin, the traffic is distributed across all the active remote servers.

b. If the load-balancing logic is configured to be failover, the traffic is directed towards first priority remote server. When Prime Access Registrar loses connectivity with the first priority remote server, it directs the subsequent traffic towards the second priority remote server. The priority of the Diameter remote servers, in case of failover logic, is set with the help of metrics.

For more information about Diameter server group parameters, see GroupServers.

Scripting in Diameter

Prime Access Registrar supports 'rex' scripts for Diameter protocol. The script can be configured only as the server incoming script. The commands available for scripting are restricted to 'get' and 'put' on the dictionaries. While setting a value to an attribute, the following convention needs to be followed "<type number>,<value>". For example, if a 'Class' attribute needs to be added to the response dictionary with value as "classvalue", then set it as follows in the script:
pResponse->put( pResponse, "Class", "1,classvalue", REX_REPLACE );

The following is the list of supported scripting types with the respective type numbers:

AVP_STRING_TYPE = 1

AVP_ADDRESS_TYPE = 2

AVP_INTEGER32_TYPE = 3

AVP_UINTEGER32_TYPE = 4

AVP_UTF8_STRING_TYPE = 6

AVP_ENUM_TYPE = 7

AVP_TIME_TYPE = 11

Setting response attributes via a script is the only mechanism to add authorization attributes for Diameter requests.

Diameter Environment Variables

This section lists the environment variables that you can use in scripts for Diameter messages.

Translation Framework for Diameter

The following services are created to set up the translation framework:

Radius-Diameter—For translation of incoming RADIUS request to Diameter equivalent and then the Diameter response to RADIUS equivalent.

Diameter-Radius—For translation of incoming Diameter request to RADIUS equivalent and then the RADIUS response to Diameter equivalent.

For both the translation services, Prime Access Registrar uses the following scripting points to operate on the original packet and on the newly translated packet based on request and response mapping:

PostRequestTranslationScript—To add/modify/delete translated Diameter/RADIUS attributes in the request after translation

PreResponseTranslationScript—To add/modify/delete Diameter/RADIUS attribute values in the response before translation

PostResponseTranslationScript—To add/modify/delete RADIUS/Diameter attributes in the response after translation

RADIUS to Diameter translation comes with 3GPP reverse authorization, if the property is set as True. In that case, the request command mapping must not be defined because the new diameter request is created from the radius request by the 3GPP reverse authorization service. When the diameter response is received from the diameter proxy service, it translates the Diameter response to RADIUS response based on the response mapping configuration and sends radius response to the client.

Both these translation services create and maintain appropriate states (with the necessary identifiers, packet pointers, etc) to correlate Request to Response. The states will be cleared if present beyond the ‘Timeout’ property value and all the retries have been exhausted. You can configure the number of retries under Diameter-RemoteServers.

For more information about the translation parameters, see Simple Services.

CLI for RADIUS-Diameter Translation

Following is the CLI for RADIUS to Diameter translation:

[ /Radius/Services/rad-dia ]

Name = rad-dia

Description =

Type = radius-diameter

DiameterApplicationId = 1

ProxyServiceName = dia-proxy

EnableCommandMappings = True

PreRequestTranslationScript~ =

PostRequestTranslationScript~ =

PreResponseTranslationScript~ =

PostResponseTranslationScript~ =

RequestMapping/

CommandMappings/

Radius-Access-Request = AA

AVPMappings/

NAS-Identifier = Origin-Host

User-Name = User-Name

AVPsToBeAdded/

Origin-Realm = cisco.com

EnvironmentMappings/

ResponseMapping/

ResultCodeMappings/

Diameter-Success = Radius-Access-Accept

Diameter-Unable-To-Deliver = Radius-Access-Reject

AVPMappings/

AVPsToBeAdded/

EnvironmentMappings/

CLI for Diameter-RADIUS Translation

Following is the CLI for Diameter to RADIUS translation:

[ /Radius/Services/dia-rad ]

Name = dia-rad

Description =

Type = diameter-radius

ProxyServiceName = rad-proxy

PreRequestTranslationScript~ =

PostRequestTranslationScript~ = dia-rad-addpassword

PreResponseTranslationScript~ =

PostResponseTranslationScript~ = diareadwritetest

RequestMapping/

CommandMappings/

AA = Radius-Access-Request

AVPMappings/

Origin-Host = NAS-Identifier

User-Name = User-Name

AVPsToBeAdded/

NAS-Port = 1

EnvironmentMappings/

ResponseMapping/

ResultCodeMappings/

Radius-Access-Accept = Diameter-Success

Radius-Access-Reject = Diameter-Unable-To-Deliver

AVPMappings/

AVPsToBeAdded/

EnvironmentMappings/

TLS Support for Diameter

Prime Access Registrar supports Transport Level Security (TLS) mechanism for Diameter stack. The system provides an option to enable TLS for Diameter client and Diameter remote server. When the TLS option is disabled, communication is established directly using the transport layer without applying any encryption. The Diameter TLS feature uses the CiscoSSL libraries, which are available as part of the Prime Access Registrar package.

Following is the CLI configuration of a Diameter client with TLS support:

[ /Radius/Clients/vm31 ]

Name = vm31

Description =

Protocol = diameter

HostName = ar-lnx-vm031.cisco.com

PeerPort = 3868

Vendor =

IncomingScript~ =

OutgoingScript~ =

AdvertisedHostName =

AdvertisedRealm =

MaxIncomingRequestRate = 0

WatchDogTimeout = 500

SCTP-Enabled = FALSE

TLS-Enabled = TRUE

TLSOptions/

PrivateKeyPassword = cisco

ServerCertificateFile = /opt/CSCOar/pki/cert.pem

ServerKeyFile = /opt/CSCOar/pki/key.pem

CACertificateFile = /opt/CSCOar/pki/root-cert.pem

CACertificatePath =

PeerVerificationMode = None/Optional/RequireCertificate

VerificationDepth = 4

EnableAutoChaining = True

Following is the CLI configuration of a Diameter remote server with TLS support:

Managing Diameter Sessions

Diameter provides two kinds of services namely authentication/authorization and accounting only (optional). Diameter sessions can be created when an authentication/authorization request comes from an access point or when an accounting start comes from an access point. When a Diameter client issues an authentication request, Prime Access Registrar sends the packet with a Session-Id AVP, which can be used to correlate a Diameter message with a user-session. When a Session Termination Request (STR) message is received from the Diameter client, Prime Access Registrar releases the sessions. Also Re-authentication requests must be mapped to the corresponding user session. In case of accounting packets, the session is created when the accounting start is received from the Diameter client. The session is deleted when the accounting stop message is received.

Prime Access Registrar creates a new session when it receives an authentication or accounting request packet from a Diameter client and when a user session is not already present. It allocates the resources for the particular session from the resource manager and stores the session in a session backing store. This session backing store is a file where session information is written. When a session termination message or an accounting stop message comes from the Diameter client, the session data is deleted from the backing store. Apart from this, Prime Access Registrar maintains the session state for every session it creates. Session cache will be supported for grouped AVPs.

For more information on session manager and its support for Diameter client, see SessionManagers.

Blacklisting Support for Diameter Remote Server

You can choose to configure blacklisting as part of the outgoing script of a Diameter remote server with EAP-SIM or EAP-AKA service. For more information about blacklisting, see .

SCTP Multihoming Support for Diameter Client and Remote Server

Stream Control Transmission Protocol (SCTP) is an IP transport protocol that supports data exchange between exactly two endpoints. Multihoming feature of SCTP provides the ability for a single SCTP endpoint to support multiple IP addresses. With this feature, each of the two endpoints during an SCTP association can specify multiple points of attachment. Each endpoint will be able to receive messages from any of the addresses associated with the other endpoint. With the use of multiple interfaces, data can be sent to alternate addresses when failures occur and thus Prime Access Registrar runs successfully even during network failures.

Prime Access Registrar provides SCTP multihoming support for Diameter client and remote server. With this feature, you can configure multiple source and destination addresses on the Diameter client and remote server.

Note When you use Prime Access Registrar with CentOS, ensure that you configure the Diameter SCTP client and remote servers with different source ports in Prime Access Registrar.

The following shows an example configuration of Diameter remote server with multiple source and destination addresses:

[ //localhost/Radius/RemoteServers/Diameter-SCTP-Remote-Server ]

Name = Diameter-SCTP-Remote-Server

Description =

Protocol = diameter

HostName = 10.197.66.73

DestinationPort = 3868

DestinationRealm = cisco.com

ReactivateTimerInterval = 2000

Vendor =

IncomingScript~ =

OutgoingScript~ =

MaxTries = 1

MaxTPSLimit = 0

MaxSessionLimit = 0

InitialTimeout = 1500

LimitOutstandingRequests = FALSE

MaxPendingPackets = 0

MaxOutstandingRequests = 0

DWatchDogTimeout = 2000

SCTP-Enabled = TRUE

TLS-Enabled = FALSE

AdvertiseHostName =

AdvertiseRealm =

SCTPParameters/

SourcePort = 3868

RTOInitial = 300

RTOMin = 200

RTOMax = 300

MaxInitRetransmits = 8

AssociationMaxRetrans = 10

PathMaxRetrans = 10

RTOCookieLife = 60000

HBInterval = 50

SACKTimeout = 400

InitNumOstreams = 65535

InitMaxInstreams = 65535

SCTPAdvertisedHostName/

Local/

1. 10.197.66.80

2. 10.197.66.146

Remote/

1. 10.197.66.73

2. 10.197.66.144

The following shows an example configuration of Diameter client with multiple source and destination addresses: