Basics of Diameter

Agenda • Diameter Base Protocol • Introduction of Diameter  Diameter Base Protocol  Diameter Applications  Types of Diameter nodes

• Typical Diameter Message Exchanges  Capabilities Exchange procedure  Transport Failure Detection  Diameter error handling

• Diameter Packet Format  Diameter Header Format  AVP Header Format

• Comparison with RADIUS

• Diameter Credit Control Application

Signaling in EPS

Introduction to Diameter • Diameter is an authentication, authorization and ing protocol for computer networks • It is a successor to RADIUS • It was initially developed by Pat R. Calhoun, Glen Zorn and Ping Pan in 1998 • The Diameter base protocol is defined by RFC 3588 (Obsoleted by RFC 6733) • Diameter Applications can extend the base protocol, by adding new commands and/or attributes

Diameter overview • • •

AAA protocol that improves and can replace Radius T or SCTP as reliable transport protocol Diameter Security provided by IPsec or TLS T SCTP

•

One Diameter session can carry many ”connections” that consist of ”transactions” (request - answer pairs)

• Base protocol & Applications

Base Protocol •

Base protocol defines basic principles – – – – –

• •

Message format that is based on attribute-value (AVP) pairs Transport connection setup, monitoring and failover Request routing Error reporting & security Relaying, proxying, redirection and translation of messages

Functionality common to all ed services. The base Diameter protocol is never used on its own. It is always extended for a particular application, which defines DIAMETER command codes

Diameter Applications • A Diameter Application is not a software application • It is a protocol based on the Diameter base protocol • Each application is defined by an application identifier • New command codes and/or new mandatory AVPs can be added • Adding a new optional AVP does not require a new application

Diameter Applications Cont. •

”Diameter applications” define application specific AVPs and semantics         

RFC 4004 Diameter Mobile IPv4 Application RFC 4005 Diameter Network Access Server Application RFC 4006 Diameter Credit-Control Application RFC 4072 Diameter Extensible Authentication Protocol (EAP) Application RFC 4740 Diameter Session Initiation Protocol (SIP) Application RFC 5224 Diameter Policy Processing Application RFC 5431 Diameter ITU-T Rw Policy Enforcement Interface Application RFC 5866 Diameter Quality-of-Service Application RFC 6737 The Diameter Capabilities Update Application.

Why Diameter was needed • It provides a Authentication, Authorization, and ing (AAA) framework that could overcome the limitations of RADIUS • RADIUS had issues with reliability, scalability, security and flexibility • RADIUS cannot effectively deal well with remote access, IP mobility and policy control

Why Diameter was needed (Cont.) • Like RADIUS, Diameter provides AAA functionality, but in addition it is made more reliable by using T and SCTP instead of UDP • lt is further enhanced by the development of the 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS) • The Cx, Dh, Dx, Rf, Ro, and Sh interfaces are ed by Diameter applications • The Diameter protocol defines a policy protocol used by clients to perform Policy, AAA and Resource Control • This allows a single server to handle policies for many services

Types of Diameter Nodes

JMi / 11/2007

Typical Diameter Message Exchanges Client

Agent

Server

Peer Discovery

Discovery via DNS or Static Configuration Peer Discovery

Capabilities Exchange Request

Capabilities Exchange Answer

Capabilities Exchange Request Capabilities Exchange Answer

A Capabilities Exchange message carries a peer's identity and its capabilities (protocol version number, ed Diameter applications, etc.). A Diameter node only transmits commands to peers that have d for the Diameter application associated with the given command.

Device Watchdog Request Device Watchdog Answer

Request Request Answer Answer

Application-level heartbeat messages are used to proactively detect transport failures. These messages are sent periodically when a peer connection is idle and when a timely response has not been received for an outstanding request. There are two types of messages, Requests and Answers.. Every answer message carries a Result-Code AVP. The data value of the Result-Code AVP is an integer code indicating whether a particular request was completed successfully or whether an error occurred.

Capabilities Exchange procedure • Mandatory procedure once transport connection is established • Capabilities are cached. • Originating peer sends CER command announcing ed applications • Terminating peer sends CEA command with its ed applications. • Result-Code AVP in CEA will usually contain: – DIAMETER_SUCCESS (2001) – DIAMETER_NO_COMMON_APPLICATION (5010) – DIAMETER_UNKNOWN_PEER (3010)

• In case of failure, transport connection is closed

Transport Failure Detection • Application layer watchdog procedure is used • DWR command is sent when no traffic has been exchanged in transport connection for “Tw” seconds • If no DWA has been received, transport connection will be closed. • DWR message isn’t retransmitted because diameter uses realiable transport protocols (T, SCTP) • All requests will forwarded to the alternate peer.

Diameter error handling •

There are two different types of errors in Diameter; protocol and application errors. – A protocol error is one that occurs at the base protocol level, and MAY require per hop attention (e.g., message routing error). – Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application (e.g., authentication, Missing AVP).

•

•

•

All Diameter answer messages defined in IETF applications MUST include one Result-Code AVP. A non-successful Result-Code AVP (one containing a non 2xxx value other than DIAMETER_REDIRECT_INDICATION) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. Diameter provides the following classes of errors, all identified by the thousands digit in the decimal notation: – – – – –

1xxx (Informational) 2xxx (Success) 3xxx (Protocol Errors) 4xxx (Transient Failures) 5xxx (Permanent Failure)

Diameter Packet Format MAC header

• • • • •

IP header

T header

Diameter header

AVPs…

Command is a Request or Response. Both have the same command code. Commands are used to exchange information between peers. A command is identified by its code, flags and application id. For every Request command there’s an Answer command. The information is carried as list of AVPs.

Diameter Packet Format (Cont.) • The 'R'(Request) bit, If set, the message is a request. If cleared, the message is an answer • The 'P'(Proxiable) Bit, If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed • The 'E'(Error) bit, If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set are commonly referred to as error messages. This bit MUST NOT be set in request messages • The 'T'( Potentially re-transmitted message) bit , This flag is set after a link failover procedure, to aid the removal of duplicate requests. It is set when resending requests not yet acknowledged, as an indication of a possible duplicate due to a link failure

Diameter Command-Code values •

There are separate commands for DCCA application layer and Base Diameter Protocol. Base Diameter Command Codes Command-Name

Abbr.

Code

Abort-Session-Request

ASR

274

Abort-Session-Answer

ASA

274

ing-Request

ACR

271

ing-Answer

ACA

271

Capabilities-Exchange-Request

CER

257

Capabilities-Exchange-Answer

CEA

257

Device-Watchdog-Request

DWR

280

Device-Watchdog-Answer

DWA

280

Disconnect-Peer-Request

DPR

282

Disconnect-Peer-Answer

DPA

282

Re-Auth-Request

RAR

258

Re-Auth-Answer

RAA

258

Session-Termination-Request

STR

275

Session-Termination-Answer

STA

275

Diameter Command Codes for DCCA Command-Name

Abbr .

Code

Credit-Control-Request

CCR

272

Credit-Control-Answer

CCA

272

Attribute Value Pairs (AVP) • An AVP is a container for data delivered by Diameter. Some of the 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. • AVPs are used by the base Diameter protocol to the following required features: – Transporting of authentication information, for the purposes of enabling the Diameter server to authenticate the . – Transporting of service specific authorization information, between client and servers, allowing the peers to decide whether a ’s access request should be granted. – Exchanging resource usage information, which MAY be used for ing purposes, capacity planning, etc. – Relaying, proxying and redirecting of Diameter messages through a server hierarchy.

AVP Header Format • The packet consists of a AVP header and a variable data

AVP Header Format (Cont.) • The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space • The 'M' Bit, known as the Mandatory bit, indicates whether of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and redirect agents MUST NOT reject messages with unrecognized AVPs • The 'P' bit indicates the need for encryption for end-to-end security • 3GPP specific AVP codes are listed in TS29.230

Comparison Radius & Diameter

JMi / 11/2007

Comparison Radius & Diameter Cont.

JMi / 11/2007

Diameter Credit Control Application

3GPP PCC Logical Architecture

Credit Control Application Overview • Specified in RFC 4006 • Can be used to provide real time credit control for various applications, e.g. messaging services, gaming services • Used between the network element providing the service (client) and credit control server (server) • Uses Application-Id 4, Command code 272

Credit Control Application Messages • Credit Control Request (CCR) – Sent from client to server to request authorization for a given service

• Credit Control Answer (CCA) – Sent from server to client and carries the result of the corresponding authorization request

• Reauthorization Request (RAR) - Base – Sent by server to trigger a new CCR, e.g. after successful credit replenishment during a service

• Reauthorization Answer (RAA) - Base – Sent by client as an answer to RAR

Operation Modes •

Event Based – –

•

A single CCR/CCA exchange in each session Used when it is sure that requested service event will be successful

Session Based – – – –

Multiple CCR/CCA exchanges in a session Required when there is a need to reserve credits before providing the service Requires state maintenance on the server side Server first reserves the credits and debits them after receiving the subsequent CCR

Some important AVPs • CC-Request-Type AVP – Indicates type of the request for a CCR – Possible values are INITIAL_REQUEST, UPDATE_REQUEST, TERMINATION_REQUEST for session based scenarios and EVENT_REQUEST for event based scenarios

• CC-Request-Number AVP – Identifies a request within a session

• Requested-Action AVP – Used to indicate type of the requested action for event based scenarios. Possible values are DIRECT_DEBITING, REFUND_, CHECK_BALANCE and PRICE_ENQUIRY

Event Based Scenario Example Server

Client CCR, Session-Id = S-Id1, Service-Identifier CC-Request-Type = EVENT_BASED Requested-Action = PRICE_ENQUIRY CCA, Session-Id = S-Id1 Cost-Information CCR, Session-Id = S-Id2, Subscription-Id, CC-Request-Type = EVENT_BASED Requested-Action = BALANCE_CHECK, Service-Identifier CCA, Session-Id = S-Id2 Check-Balance-Result CCR, Session-Id = S-Id3, Service-Identifier CC-Request-Type = EVENT_BASED Requested-Action = DIRECT_DEBITING Subscription-Id CCA, Session-Id = S-Id3 Granted-Service-Unit

Session Based Scenario Example Client

Server CCR, Session-Id = S-Id1, Requested-Service-Unit CC-Request-Type = INITIAL_REQUEST Subscription-Id CCA, Session-Id = S-Id1 Granted-Service-Unit, Validity-Time CCR, Session-Id = S-Id1, Requested-Service-Unit, CC-Request-Type = UPDATE_REQUEST Subscription-Id CCA, Session-Id = S-Id1 Granted-Service-Unit, Validity-Time CCR, Session-Id = S-Id1, CC-Request-Type = TERMINATION_REQUEST Used-Service-Unit CCA, Session-Id = S-Id1 Cost-Information

Thank You

Presentation / Author / Date