Diameter Training Session

interne Groupe
Diameter Training Session
Auteurs:
Lionel Morand FT/ OLNC/ OLN/ CNC/ NCA/ A2M
Carlos Pereira FT/ OLNC/ OLN/ CNC/ GPC/ FMA
Orange Labs recherche & développement

Contents
1 Introduction
2 Diameter Overview
3 Diameter Message and AVP Formats
4 Diameter Connection Management
5 Diameter Routing
6 Diameter Session Management
7 Diameter Accounting
2 France Telecom Group confidential

Orange Labs - Research & Development
1 2 3 4 5 6 7
Introduction
3 FT Group Confidential
Intro
Diameter, successor of RADIUS
 The Diameter protocol was derived from RADIUS, and designed to be

a general framework for future AAA applications, as an enhanced
version of RADIUS protocol. Back-end
AAA client AAA server
 Features inherently offered by diameter
” Reliable and secure transport
Access
” Failover Internet
network
” Agent support
Client host
” Server-initiated messages NAS
” Capabilities negotiation Front-end

” Dynamic Peer discovery and configuration
 Note:
” New RADIUS Extensions developed in IETF provide now most of these
functionalities but are foreseen only for legacy system
Intro
History
 1997: RADIUS as RFC (RFC 2058)
” originally developed by Livingston Enterprises for their PortMaster series of Network
Access Servers
 2000: RADIUSv2 (RFC 2865)
” Closed some issues of the first version widely implemented
” Acknowledgement of issues when used in large scale systems
” Dedicated IETF's AAA working group to develop a successor
 2000: Set of requirements for generic AAA architecture
” Main drivers: roaming, Network access requirement enhancements, Mobile IP
 2001 (February): first draft of the Diameter base protocol
” Pushed by Sun Microsystems
 2001 (June): Diameter selected as transport protocol
” Preferred to COPS. Other candidates: RADIUS++ and SNMP
 2003: Diameter Base Protocol as RFC (RFC 3588)
 2005 -2006: Feedback from first operational deployment (IMS, CDMA2000, etc.)
” and first IOT issues
 2008: Diameter Extensibility and Diameter Routing Design teams
” Clarification of the rules for extensibility/routing
 2012: new version of the Diameter base protocol RFC (RFC6733)
FT Group Confidential
Intro
Diameter in mobile networks
 The Diameter base protocol and applications developed above

Diameter are ‚widely‛ used in new mobile network
architectures to perform various procedures such as:
” Authentication and authorization management;
” Accounting;
” Location and mobility management;
” User profile management;
” QoS management;
” …and now even for transport of SMS
Intro
“Some” Applications in 3GPP Mobile networks

8 Standard Applications
Application IETF Diameter Application

identifier
0 Diameter common message
1 NASREQ
3 Diameter base accounting
4 Diameter Credit Control
5 Diameter EAP
7 Diameter Mobile IPv6 IKE (MIP6I)
8 Diameter Mobile IPv6 Auth
(MIP6A)
4294967295 Relay
Intro
“Some” Applications in 3GPP Mobile networks

8 Standard Applications and at least 30 3GPP specific Applications
Application IETF Diameter Application Application 3GPP Diameter Application 3GPP Diameter
identifier identifier Application identifier Application
0 Diameter common message 16777216 3GPP Cx/Px 16777236 3GPP Rx
1 NASREQ 16777217 3GPP Sh/Ph 16777238 3GPP Gx
3 Diameter base accounting 16777218 3GPP Re 16777250 3GPP STa
4 Diameter Credit Control 16777219 3GPP Wx 16777251 3GPP S6a
5 Diameter EAP 16777220 3GPP Zn 16777252 3GPP S13/S13’
7 Diameter Mobile IPv6 IKE (MIP6I) 16777221 3GPP Zh 16777255 3GPP SLg
8 Diameter Mobile IPv6 Auth
16777222 3GPP Gq 16777264 3GPP SWm
(MIP6A)
4294967295 Relay 16777223 3GPP Gmb 16777265 3GPP SWx
16777224 3GPP Gx 16777266 3GPP Gxx
16777225 3GPP Gx over Gy 16777267 3GPP S9
16777226 3GPP MM10 16777268 3GPP Zpn
16777229 3GPP Rx 16777272 3GPP S6b
16777230 3GPP Pr 16777291 3GPP SLh
16777308 3GPP S7a/S7d 16777292 3GPP SGmb
16777309 3GPP Tsp 16777310 3GPP S6m
16777311 3GPP T4 16777312 3GPP S6c
16777313 3GPP SGd
1 2 3 4 5 6 7
Diameter Overview
Overview
Diameter - Basic Functionality
 Diameter is built on a framework that consists of:
Data
Data
Data
Data
Data
Data
” A Transport layer …
– Reliable (TCP or SCTP) and secure (IPsec, TLS,
DTLS)
AVP
AVP
AVP
AVP
AVP
AVP
” A Base Protocol …
– Set of common commands and Attribute-Value-
Pairs (AVPs) supported by any Diameter peer
– used for: Command
” Dynamic peer discovery
DTLS/TLS
” Connectivity management
” Basic request routing base don realm
TCP/SCTP
” Session creation and termination
” accounting management IPSec
” Error handling management

Overview
Diameter Application
 A set of Applications used in extension of the Base protocol

” Set of specific commands and AVPs used for specific purposes:
– e.g. user authentication and specific application procedures (profile
handling, pre-paid services, QoS, etc)
” A specific set of error results.
 Each application is identified by a specific Application-Id advertized in
the command header and used for determining routing and command
processing.
 A Diameter peers discovers the applications supported by the other
peer during the Diameter connection set-up
” A given Diameter peer has to support only the set of applications
required to serve the user.
” Every Diameter peer supports the Diameter base application

Overview
Diameter Extensibility
 Base protocol or applications can be extended via addition of commands

and/or AVPs
 A new application is defined when:
” Creation of new Commands implies a new Application
” Addition of new AVP mandatory to understand in existing commands
 Addition of new AVP optional to understand does not change the
application
 New command or AVP can be:
” Standard i.e. defined at IETF
” vendor-specific i.e. defined by a vendor or external SDO under their own
vendor-id.
 Any new application needs to be registered at IANA
” Internet Assigned Number Authority (IANA) manages a registry dedicated for
Diameter parameters.
” Ensure uniqueness of code values and avoid IOT issues
Overview
Types of Diameter nodes
 Diameter Clients and Severs

” End-point in which applications reside
” Request and Answer messages Originators
” Advertises only supported applications
” BUT Diameter is a peer-to-peer protocol!
– a ‚server‛ can initiate requests towards the ‚client‛
 Diameter Agents
” In the path of the Diameter signaling between client and servers
” Request and Answer messages Forwarders
” Adds routing information to the message
” Types: Relay, Proxy, Redirect

Overview
Diameter Agents
 Relay Agents
” Provides basic routing functionality to forward requests to the next hop
” Does not inspect content of the message other than Destination-Host
and/or Realm and AppIds
” Does not maintain session state
” By definition, a Relay supports all applications and advertises the Relay
application id ("0xffffffff")
 Proxy Agents
” Same as Relay but…
” Inspects and possibly modifies contents of the request/answer
according to application rules and/or local policies.
– Useful in scenarios such policy enforcement, admission control,
provisioning, etc.
– Can maintain session state, depending of requirements
” Advertises only the (set of) application(s) supported
1. Request 2. Request
Relay/Proxy
Client Server
Agent
4. Answer 3. Answer
realmA.com realmB.com
Overview
Diameter Agents
 Redirect Agents
” Does not forward messages but notifies the previous hop of the new
next-hop to use.
” Advertises the Relay application id ("0xffffffff")
Redirect
Agent
1. Request 2. Redirect Notification
3. Request
Client Server
4. Answer

Overview
Diameter Agents
 Translation agent
” Provides translation between two protocols
– (e.g., RADIUS<->Diameter, MAP<->Diameter).
” Mainly used as gateway between Diameter infrastructure and legacy
systems
” Must be defined along the application allowing this translation
– e.g. IWF between S6a/S6d and MAP Gr interfaces
4. MAP Operation
1. Diameter Request
Translation
Client Server
Agent
6. Answer 5. MAP Answer


Overview
Connections vs. Sessions
 Connection: transport-level connection between two peers that

is used to send and receive Diameter messages.
 Session: logical concept at the application layer that exists
between the Diameter client and the Diameter server, identified
with a Session identifier (via the Session-Id AVP)
 no relationship between a connection and a session
” Diameter messages for multiple sessions are all multiplexed
through a single connection
Relay/Proxy
Client Server
Connection A Agent Connection B
realmA.com User Session x realmB.com

Overview
Diameter Routing principles
 All the Diameter nodes in a Domain are peers i.e. sharing a least one
connection
 Each Diameter node maintains two tables used for Routing:
” A Peer table that lists the Diameter peers with which the node has a direct
connection
” A Routing table that indicates which nodes to use for request sent to a
domain for a given application I-d.
 Routing between two Diameter nodes based on hop-by-hop approach
” “if I can answer to a message, I try to forward the request to someone that
may know what to do with it”.
 the Routing table is used to identify the next Peer to which to forward the
request
 the Peer table is used to select the connection to use to forward the
request
 The answer follows the request path i.e. no routing look-up

Overview
Diameter Framework
Diameter Client Node @ some.realm.com Diameter Server Node @ other.realm.com
Diameter Diameter Diameter Diameter

Client Application Client Application Server Application Server Application
App-id 1 App-id 2 App-id 1 App-id 2
Session Management Session Management

Routing based on:
“ Application-Id
Routing Management “ Destination Routing Management
-Diameter node id
an/or domain name
Connection Connection
Management Management
Base Protocol Base Protocol

Overview
As a summary
 Any Diameter node will support the Diameter base protocol

” provide basic functions i.e. connection, routing, accounting, session
management
 Additional feature will be provided by an application only supported by
specific peers
 Application Id identifies:
” a set of command
” a set of AVP
” a set of error
 Routing is based on hop-by-hop approach using Realm and
Application-Id as key entries for routing table look-up.

1 2 3 4 5 6 7
Diameter Command and AVP
formats
Format
Diameter Message Format

Version Message Length
R P E T r r r r Command Code
Application-Id
Hop-by-Hop Identifier
End-to-End Identifier
AVP 1 AVP 2 AVP 3 Etc.
22 Orange Labs - Research & Development France Telecom Group confidential

Format •3 octets for length
Diameter Message Format •Max size: 16,7 Mo
Version Message Length

Application-Id

Version Message Length •Code value identifying a

command pair (request/answer)
Application-Id


Application-Id
Hop-by-Hop Identifier •Identifier of the Application
using this command
End-to-End Identifier •For example, '16777251' (S6a)


Application-Id
using this command
• Matching requests and answers per connection

•In requests, it is replaced at each hop as the Diameter
message is relayed to its final destination.
•The sender of an Answer message returns the same
value that was found in the corresponding received
request


Application-Id
using this command

Command Flags:
• R(equest): If set, request. If cleared, answer. •In requests, it is replaced at each hop as the Diameter
•P(roxiable): If set, MAY be proxied, relayed, or redirected. message is relayed to its final destination.
•E(rror) : If set, protocol error. •The sender of an Answer message returns the same
•T(Potentially retransmitted message): if set, Retransmitted message value that was found in the corresponding received
request


Application-Id
using this command

Command Flags:
• R(equest): If set, request. If cleared, answer. •In requests, it is replaced at each hop as the Diameter
•P(roxiable): If set, MAY be proxied, relayed, or redirected. message is relayed to its final destination.
•E(rror) : If set, protocol error. •The sender of an Answer message returns the same
•T(Potentially retransmitted message): if set, Retransmitted message value that was found in the corresponding received
request
•Request identifier unmodified between the client and the server
•Used by the server to detect duplicate requests (e.g. retransmission)
•Answer message carries the same value of the corresponding

request

Format
Command Code Format (CCF) specification

 Every Command Code must be defined with a a corresponding
Command Code Format (CCF) specification,
 Used to define the AVPs that MUST or MAY be present when sending
the message.
 Example: <RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id > [ Fixed AVP, Occurrence: 1 ]
{ Origin-Host } [ Required AVP, Occurrence: 1 ]
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ] [ Optional AVP, Occurrence: 0 or 1 ]
[ Origin-State-Id ]
* [ Proxy-Info ] [ Optional AVP, Occurrence: 0+ ]
* [ Route-Record ]
* [ AVP ]

Format
Diameter AVP Format
 Data is carried within a Diameter message as a collection of Attribute Value Pairs

(AVPs)
AVP Code
V M P r r r r AVP Length
Vendor-Id (optional)
Data…
The Vendor-ID field present if the 'V' bit is set in the AVP Flags field.
Contains the IANA-assigned "SMI Network Management Private

Enterprise Codes" value of the vendor defining this vendor-specific
AVP
AVP Flags:
•The 'M' Bit, known as the Mandatory bit, indicates whether the receiver of the AVP MUST parse and
understand the semantic of the AVP including its content.
•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 'P' bit has been reserved in RFC 6733 for future usage of end-to-end security
Format
'M' bit, known as the Mandatory bit
 When set in an AVP, the receiver of the AVP MUST parse and
understand the semantics of the AVP including its content.
” The receiving entity MUST return an appropriate error message if it
receives an AVP that has the M-bit except Relay and Redirect Agents
 When cleared in an AVP, the AVP is informational and the receiver can
simply it if not supported.
 Setting of the 'M' bit defined in the application specification that
introduces or reuses this AVP, either for all command types or for
each command type.

Format
Data Type
 The format of the Data field MUST be one of the following base data
types:
” OctetString, Integer32 or Interger64, Unsigned32 or Unsigned64,
Float32 or Float64
 or a data type derived from the base data types:

” Address, Time, UTF8String, DiameterIdentity, DiameterURI,
Enumerated, IPFilterRule
 A set of AVP can be concatenated in the Data field of a single AVP

"Grouped‛.

1 2 3 4 5 6 7
Diameter Connection
Management
Diameter
Diameter Peer Discovery
 There are two cases:

” when a Diameter client needs to discover a first-hop Diameter agent.
” when a Diameter agent needs to discover another agent for further
handling of a Diameter operation.
 Search order:
” The Diameter implementation consults its list of statically (manually)
configured Diameter agent locations. These will be used if they exist and
respond.
” If no entry, NAPTR query for a server in a particular realm.
” If no NAPTR records are found, SRV records query
 Dynamically discovered peer causes a new entry in the peer table and
Routing table
 If a peer is discovered outside of the local realm, a routing table entry
for the peer's realm is created

Diameter
Transport Connection between peers

 Protocols
” Certain nodes MUST support at least SCTP or TCP (i.e. Diameter Client)
” Others MUST support SCTP and TCP (i.e. Diameter Servers and
Agents)
 Security
” TLS, IPSec, DTLS
” Normally, the Diameter protocol MUST NOT be used without one of
TLS, DTLS, or IPsec.
– however, a lot of of existing implementations rely only on the notion
of trusted domains and no transport security is applied
 Transport Selection Process (in order of execution)
” TLS/TCP SHOULD be tried first,
” followed by DTLS/SCTP,
” then TCP and finally by SCTP, both with IPsec
 The Tc timer (default: 30s) controls the frequency that transport
connection attempts are done to a peer with whom no active
transport connection exists

Diameter
Diameter Capabilities Exchange

 After transport SCTP/TCP connection set-up, exchange of
Capabilities Exchange messages (CER/CEA)
” Allow the discovery of a peer's identity and its capabilities (protocol
version number, the identifiers of supported Diameter applications,
security mechanisms, etc.)
” Discovered application Id are associated to the peer to ensure that
unrecognized commands and/or AVPs are not unnecessarily sent to a
peer
 The sender of the Capabilities-Exchange-Request (CER includes all
the Application-Id that it’s willing to support over the connection.
 The receiver of the CER determines common applications by
computing the intersection of its own set of supported Application Ids
against all of the Application-Id AVPs present in the CER
” if no application in common, DIAMETER_NO_COMMON_APPLICATION
error and disconnection
 The sender of the Capabilities-Exchange-Answer (CEA) SHOULD
include all of its supported applications as a hint to the receiver
regarding all of its application capabilities.

Diameter
CER/CEA Message Format

<CER> ::= < Diameter Header: 257, REQ > <CEA> ::= < Diameter Header: 257 >
{ Origin-Host } { Result-Code }
{ Origin-Realm } { Origin-Host }
1* { Host-IP-Address } { Origin-Realm }
{ Vendor-Id } 1* { Host-IP-Address }
{ Product-Name } { Vendor-Id }
[ Origin-State-Id ] { Product-Name }
* [ Supported-Vendor-Id ] [ Origin-State-Id ]
* [ Auth-Application-Id ] * [ Supported-Vendor-Id ]
* [ Inband-Security-Id ] * [ Auth-Application-Id ]
* [ Acct-Application-Id ] * [ Inband-Security-Id ]
* [ Vendor-Specific-Application-Id ] * [ Acct-Application-Id ]
[ Firmware-Revision ] * [ Vendor-Specific-
Application-Id ]
* [ AVP ]
[ Firmware-Revision ]
* [ AVP ]
Diameter
Example: CER sent by an MME

Diameter Example: CEA sent back by a Proxy

Diameter
Transport Failure Detection
 transport failures need be detected as soon as possible.

” minimize the occurrence of messages sent to unavailable agents,
resulting in unnecessary delays, and better failover performance.
 The Device-Watchdog-Request and Device- Watchdog-Answer
messages used to pro- actively detect transport failures
 When no Diameter messages are received on a given connection, a
DWR is sent and the Tw timer is set (default: 30s)
 If no response received at the Tw expiration, the peer is suspect and
possible message will be sent to an alternate peer
 The transport connection with the suspect peer is closed after 2xTw ,
unless a message is received.
 The Tc timer (default: 30s) controls the frequency of transport
connection re-attempts.

Diameter
Diameter DWR/DWA Message Format
<DWR> ::= < Diameter Header: 280, REQ >

{ Origin-Host }
{ Origin-Realm }
[ Origin-State-Id ]
* [ AVP ]
<DWA> ::= < Diameter Header: 280 >

{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ AVP ]
Diameter
Disconnecting Peer Connections
 The Disconnect-Peer-Request message is used by a Diameter node

to inform its peer of its intent to disconnect the transport layer and
that the peer shouldn't reconnect unless it has a valid reason to do so
(e.g., message to be forwarded).
” The Disconnect-Cause AVP in the message contains the reason the
Diameter node issued the Disconnect-Peer- Request message.
 Upon receipt of the message, the Disconnect-Peer-Answer message
is returned
 The receiver of the Disconnect-Peer-Answer message initiates the
transport disconnect. The sender of the Disconnect-Peer-Answer
message should be able to detect the transport closure and clean up
the connection.

Diameter
Diameter DPR/DPA Message Format
<DPR> ::= < Diameter Header: 282, REQ >

{ Origin-Host }
{ Origin-Realm }
{ Disconnect-Cause }
* [ AVP ]
<DPA> ::= < Diameter Header: 282 >

{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Error-Message ]
[ Failed-AVP ]
* [ AVP ]

Diameter
Peer Table entry

Peer Table Entry Fields Comments
Host Identity Contents of the Origin-Host AVP found

in the CER or CEA message.
StatusT State of the peer entry
Static or Dynamic Specifies whether a peer entry was

statically configured, or dynamically
discovered
Expiration Time Specifies the time at which dynamically
discovered peer table entries are to be
either refreshed, or expired.
TLS/TCP and DTLS/SCTP Enabled Specifies whether TLS is to be used
when communicating with the peer.
Additional Security information e.g. security keys, certificates, etc. (If

required)

Diameter
Realm Routing table
 List of realm routing entries

 Realm routing entry looks like:
Realm Routing Table Entry Fields Comments
Realm Name Used as a primary key in the routing
table lookups.
Application Identifier(s) Used as a secondary key field in routing
table lookups.
Local Action identify how a message should be treated
(Local, Relay, Proxy, Redirect)
Server Identifier Server(s) present in the Peer table to
which the message is to be routed.
Static or Dynamic Specifies whether a route entry was
statically configured, or dynamically
discovered
Expiration Time Specifies the time which a dynamically
discovered route table entry expires

1 2 3 4 5 6 7
Diameter Routing
Diameter
Diameter Routing Principles

 The routing of Diameter messages is based on the hop-by-hop
paradigm, using the connections established between adjacent peers
 Key info is:
” the requested domain name , identified in the Destination-Realm AVP
” the requested node identity, identified in the Destination-Host AVP
 It is up to the Application to define how the domain name
” Usually retrieved from the User identity received from the access
network and reused as User-Name AVP in a NAI format
– ex: lionel.morand@orange.com  realm= orange.com
” if no domain, a mechanism needs to be defined to derive one from the
user identity
– ex. build a domain from MCC/MNC contained in the IMSI
 A request is first sent to a domain, then to a node
 If the destination node can be selected in the Destination realm, there
is no need of Diameter node identity in the request
 The answer always follows the path of the corresponding request
Diameter
IMSI-based domain name derivation for EPC

 the Home Network Realm/Domain of an IMSI shall be derived as
described in the following steps:
1. take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is
used (see 3GPP TS 31.102 [27]) and separate them into MCC and
MNC; if the MNC is 2 digits then a zero shall be added at the
beginning;
2. use the MCC and MNC derived in step 1 to create the
"mnc<MNC>.mcc<MCC>.3gppnetwork.org" domain name;
3. add the label "epc" to the beginning of the domain name.
 An example of a Home Network Realm/Domain is:
” IMSI received from the access network: 234150999999999;
– MCC = 234;
– MNC = 15;
– MSIN = 0999999999;
 Which gives the Home Network Realm/Domain name:
epc.mnc015.mcc234.3gppnetwork.org

Diameter
Diameter Routing Principles
 Request Routing rules:

1. If local identity = Destination-Host AVP then process locally,
otherwise
2. If peer identity = Destination-Host AVP then send to that peer,
otherwise
3. Lookup realm table with Destination-Realm and AppI-d
a) If found send to the designated next-hop
b) Otherwise, send an UNABLE_TO_DELIVER answer
 Request forwarding :
” done using the Diameter Realm routing table and Diameter peer table.
” The Diameter peer table contains all of the peers with which the local
node is able to directly communicate.

Diameter
Answer Routing
 Information used for routing

” Hop-by-Hop Id is used instead of Destination-Host or
Destination-Realm AVP
” Hop-by-Hop Id is unique within each hop
” Answer routing path is the reverse of the request path
 Routing Rules:
” For answer originators:
– Use the same Hop-by-Hop Id found in the request
” For answer forwarders:
– Lookup Hop-by-Hop Id in the list of pending requests
a) If found, forward answer to appropriate peer and remove
request from the queue
b) Otherwise, discard

Diameter Request Routing
MME cannot directly contact the HSS

Diameter Peer (Relay or Proxy)
 CER/CEA not performed between them
 CER/CEA with both MME and HSS
 MME is configured with only the intermediary Diameter Node
 Can take the decision of which HSS to
as peer
use according to the Destination-
 The Diameter name of the HSS is not known by the MME
Realm, Application-Id as S6a …
before any answer has been received from that HSS
 For a Proxy, the IMSI can also be used
 Only the Diameter Realm of the HSS is mandatory in the
if that subscriber is handled by specific
requests from the MME, not the Diameter identity of the HSS
HSS

Diameter Answer Routing
Hop-By-Hop ID
Matching requests and replies.
In requests, it is replaced at each hop as
the Diameter message is relayed to its
final destination.
An answer is always sent back to the

Diameter peer that sent to us the
relative request.
The sender of an answer message
returns the same Hop-By-Hop that was
found in the corresponding request

Diameter Failover-Failback procedures
Pending Answer Timer Expiration

 As soon as a Diameter peer sends a request, a timer is
triggered to limit the time for waiting an answer.
 At expiration of that timer, the Diameter peer consider that the
routing of the request has failed and try to re route the request
stored in the ‚pending request list‛ to another peer (using the
T flag).
 If no additional route is possible, the Diameter peer will return
an answer message with an unsuccessful Result-Code to the
initiator of the request.
Answer with an unsuccessful Result-Code

 The Diameter node receives an answer but with an
unsuccessful Result-Code .
 By configuration, the Diameter Node can be allowed to re
route the request to another peer if possible.

Diameter Failover-Failback procedures
Duplication Detection
 At expiration of that timer, the Diameter peer
consider that the routing of the request has
failed and try to re route the request to
another peer (T flag).
 In fact, the delay between ‘Peer 1’ and
‘Server’ is very bad and the request has
reached the Server after the timer expiration
in ‘Peer 1’.
 The ‘Server’ will receive twice the request.
End-To-End ID
 In conjunction with the Origin-Host, it is
used to detect duplicate request messages.
 It is unmodified as a request is forwarded to
its final destination. Only the T flag is set in
retransmitted requests.
 The originator of an Answer message
returns the same value that was found in
the corresponding request.

Diameter
Error Handling
 There are two different types of errors in Diameter;

” protocol errors
” application errors.
 A protocol error is one that occurs at the base protocol level and
require per-hop attention (e.g., a message routing error).
 Application errors generally occur due to a problem with a function
specified in a Diameter application (e.g., user authentication, missing
AVP).
 When a request message is received that causes a protocol error, an
answer message is returned with the 'E' bit set, and the Result-Code
AVP is set to the appropriate protocol error value. As the answer is
sent back towards the originator of the request, each proxy or relay
agent MAY take action on the message.

Diameter
Result-Code AVP
 The Result-Code AVP indicates whether a particular request was
completed successfully or an error occurred.
 The Result-Code data field contains an IANA-managed 32-bit
address space representing errors.
 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)
 Any application supports the result-codes defined in the base
protocol
 Any application can defined its own set of result codes when
more appropriate, using in the Experimental-Result AVP
instead of the Result-Code AVP when defined for a vendor-
specific application
Diameter
Typical Result-Code values

 Success
” DIAMETER_SUCCESS (2001)
 Protocol Error
” DIAMETER_UNABLE_TO_DELIVER (3002)
” DIAMETER_TOO_BUSY (3004)
” DIAMETER_REDIRECT_INDICATION (3006)
 Transient failures
” DIAMETER_AUTHENTICATION_REJECTED (4001)
 Permanent failures
” DIAMETER_AUTHORIZATION_REJECTED (5003)
” DIAMETER_INVALID_AVP_VALUE (5004)
– offending AVP within a Failed-AVP AVP.
” DIAMETER_MISSING_AVP (5005)
” DIAMETER_UNABLE_TO_COMPLY (5012)
1 2 3 4 5 6 7
Diameter Session Management
Diameter
Diameter User Session
 Diameter can provide two different types of services to applications.

” authentication and authorization, and optionally accounting.
” only accounting.
 The first request related to auth/accounting contains a Session-Id AVP
that starts a session
” the session id is used in all subsequent messages relating to the user's
session.
” The Session-Id AVP is a means for the client and servers to correlate a
Diameter message with a user session.
” Session-Id is globally and eternally unique
<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]

Diameter
Diameter User Session
 A session can be stateful or stateless

” Depending on whether the application requires the session to be maintained
for a certain duration
” Stateful sessions normally spans multiple message exchanges
 An client that does not expect to send a re-authorization or a session
termination request to the server can include the Auth-Session-State AVP
with the value set to NO_STATE_MAINTAINED as a hint to the server.
 If the answer message from the server contains a different value in the
Auth-Session-State AVP, the client must follow the server's directives.
 When STATE_MAINTAINED is used, all messages pertaining to a specific
session will include the same Session-Id value throughout the life of a
session.
 When NO_STATE_MAINTAINED is used, all sessions are implicitly
terminating when the answer to the corresponding request is received.
Diameter
Server-Initiated re-auth
 A Diameter server may initiate a re-authentication and/or re-authorization

service for a particular session by issuing a Re-Auth-Request (RAR).
” e.g. for prepaid services, the Diameter server that originally authorized a
session may need some confirmation that the user is still using the services.
” e.g. the Diameter server may want to re-authenticate the user before
expiration of the session.
 An access device that receives an RAR message with the Session-Id
equal to a currently active session MUST initiate a re-auth towards the
user (if supported by the service).
 Each Diameter application MUST state whether server-initiated re-auth is
supported, since some applications do not allow access devices to
prompt the user for re-auth.

Diameter
Diameter RAR/RAA Message Format
<RAR> ::= < Diameter Header: 258, REQ, PXY > <RAA> ::= < Diameter Header: 258, PXY >
< Session-Id > < Session-Id >
{ Destination-Realm } { Origin-Realm }
{ Destination-Host } [ User-Name ]
{ Auth-Application-Id } [ Origin-State-Id ]
{ Re-Auth-Request-Type } [ Error-Message ]
[ User-Name ] [ Error-Reporting-Host ]
[ Origin-State-Id ] [ Failed-AVP ]
* [ Proxy-Info ] * [ Redirect-Host ]
* [ Route-Record ] [ Redirect-Host-Usage ]
* [ AVP ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
62 Orange Labs - Research & Development * [ AVP ] France Telecom Group confidential
Diameter
Session Termination
 Client-initiated:
” When a user session that required Diameter authorization terminates, the
client issues a Session-Termination-Request (STR) message to the Diameter
server that authorized the service, to notify it that the session is no longer
active.
” A Diameter server that receives an STR message cleans up
resources (e.g., session state) associated with the Session-Id
specified in the STR and returns a Session-Termination-Answer
(STA).
 Server-initiated:
” A Diameter server may request that the access device stop
providing service for a particular session by issuing an Abort-
Session-Request (ASR).
” The client that receives the ASR may accept the termination
request, answer back with Abort-Session-Answer (ASA) and initiate
an STR
Diameter
Diameter STR/STA Message Format

<STR> ::= < Diameter Header: 275, REQ, PXY > <STA> ::= < Diameter Header: 275, PXY >
{ Auth-Application-Id } [ User-Name ]
{ Termination-Cause } * [ Class ]
[ User-Name ] [ Error-Message ]
[ Destination-Host ] [ Error-Reporting-Host ]
* [ Class ] [ Failed-AVP ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Redirect-Host ]
* [ Route-Record ] [ Redirect-Host-Usage ]
* [ AVP ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
France Telecom Group confidential
64 Orange Labs - Research & Development
* [ AVP ]
Diameter
Diameter ASR/ASA Message Format
<ASR> ::= < Diameter Header: 274, REQ, PXY > <ASA> ::= < Diameter Header: 274, PXY >
{ Destination-Host } [ User-Name ]
{ Auth-Application-Id } [ Origin-State-Id ]
[ User-Name ] [ Error-Message ]
[ Origin-State-Id ] [ Error-Reporting-Host ]
* [ Proxy-Info ] [ Failed-AVP ]
* [ Route-Record ] * [ Redirect-Host ]
* [ AVP ] [ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
65 Orange Labs - Research & Development * [ AVP ] France Telecom Group confidential
1 2 3 4 5 6 7
Accounting
Diameter
Accounting Session
 The Diameter base protocol provides basic functionality for offline
accounting
” Application-Id ‚3‛ is used for accouting messages (instead of ‚0‛)
” Diameter Credit Control Application (RFC 4006) used of online
 The device generating the accounting data gets information from either
the authorization server (if contacted) or the accounting server regarding
the way accounting data shall be forwarded.
 The Accounting-Request (ACR) message is used by the client to transmit
the accounting information to the Diameter server, which replies with the
Accounting-Answer (ACA) message to confirm reception.
 The server (or agents) uses the Acct-Interim-Interval and Accounting-
Realtime-Required AVPs to control the operation of the Diameter peer
operating as a client.
” The Acct-Interim-Interval AVP instructs the Diameter node acting as a client
to produce accounting records continuously even during a session.
” Accounting-Realtime-Required AVP is used to control the behavior of the
client when the transfer of accounting records from the Diameter client is
delayed or unsuccessful.
Diameter
Diameter ACR/ACA Message Format

<ACR> ::= < Diameter Header: 271, REQ, PXY > <ACA> ::= < Diameter Header: 271, PXY >
{ Accounting-Record-Type } { Accounting-Record-Type }
{ Accounting-Record-Number } { Accounting-Record-Number }
[ Acct-Application-Id ] [ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ] [ Vendor-Specific-Application-Id ]
[ User-Name ] [ User-Name ]
[ Destination-Host ] [ Accounting-Sub-Session-Id ]
[ Accounting-Sub-Session-Id ] [ Acct-Session-Id ]
[ Acct-Session-Id ] [ Acct-Multi-Session-Id ]
[ Acct-Multi-Session-Id ] [ Error-Message ]
[ Acct-Interim-Interval ] [ Error-Reporting-Host ]
[ Accounting-Realtime-Required ] [ Failed-AVP ]
[ Origin-State-Id ] [ Acct-Interim-Interval ] [
[ Event-Timestamp ] Accounting-Realtime-Required ]
* [ Proxy-Info ] [ Origin-State-Id ]
* [ Route-Record ] [ Event-Timestamp ]
* [ AVP ] * [ Proxy-Info ]
* [ AVP ]
Diameter
Accounting related AVPs
 Accounting-Record-Type AVP:
” type of accounting record
 Acct-Interim-Interval AVP:
” how/when to generate accounting records
 Accounting-Record-Number AVP:
” identify accounting record
 Acct-Session-Id AVP:
” used for RADIUS/Diameter translation
 Acct-Multi-Session-Id AVP:
” co-relates multiple accounting sessions
 Acct-Sub-Session-Id:
” sub-divides an accounting session
 Accounting-Realtime-Required AVP:
” specifies realtime accounting behavior

Annex
interne
OrangeGroupe
Labs -France Télécom
Research & Development - presentation title – date
Ongoing Works
Diameter
Ongoing works
 Protocol extensions for bulk and grouped AAA session

management.
” The aim of this work is to study and standardize a solution for
handling groups of AAA sessions within the Diameter base
protocol context. The solution would define how to identify and
handle grouped AAA sessions in commands and operations.
 Diameter overload control.
” The aim of this work is to identify the limitations of the Diameter
protocol level overload control provided by the current Diameter
Base protocol. A set of requirements will be
provided to define a new Diameter level overload control
mechanism.
 Diameter End-To-End Security
” Provide Diameter with a mechanism that will ensure integrity
and confidentiality of AVP carried in Diameter messages

Changes from RFC 3588
Diameter
Changes between RFC 6733 and RFC 3588
 The RFC 6733 obsoletes RFC 3588 but is fully backward

compatible with that document.
 The changes introduced in the RFC 6733 document focus on
fixing issues that have surfaced during the implementation of
Diameter (RFC 3588).
 An overview of some the major changes are given in the
following slides.

Diameter
 Deprecated the use of the Inband-Security AVP for negotiating

Transport Layer Security (TLS).
” It has been generally considered that bootstrapping of TLS via Inband-
Security AVP creates certain security risks because it does not
completely protect the information carried in the CER/CEA (Capabilities-
Exchange-Request/Capabilities-Exchange-Answer). This version of
Diameter adopts the common approach of defining a well-known
secured port that peers should use when communicating via TLS/TCP
and DTLS/SCTP. This new approach augments the existing in-band
security negotiation, but it does not completely replace it. The old
method is kept for backward compatibility reasons.
 Deprecated the exchange of CER/CEA messages in the open state.
” This feature was implied in the peer state machine table of RFC 3588,
but it was not clearly defined anywhere else in that document. As work
on this document progressed, it became clear that the multiplicity of
meaning and use of Application-Id AVPs in the CER/CEA messages
(and the messages themselves) is seen as an abuse of the Diameter
extensibility rules and thus required simplification.

Diameter
 Simplified security requirements.

” The use of a secured transport for exchanging Diameter messages
remains mandatory. However, TLS/ TCP and DTLS/SCTP have become
the primary methods of securing Diameter with IPsec as a secondary
alternative. The support for the End-to-End security framework (E2E-
Sequence AVP and 'P'-bit in the AVP header) has also been
deprecated.
 Changed Diameter extensibility.
” This includes fixes to the Diameter extensibility description to better aid
Diameter application designers; in addition, the new specification
relaxes the policy with respect to the allocation of Command Codes for
vendor-specific uses.

Diameter
 Clarified Application Id usage.

” Clarify the proper use of Application Id information, which can be found
in multiple places within a Diameter message. This includes correlating
Application Ids found in the message headers and AVPs. These
changes also clearly specify the proper Application Id value to use for
specific base protocol messages (ASR/ASA, STR/STA) as well as clarify
the content and use of Vendor-Specific-Application-Id.
 Clarified routing fixes.
” This document more clearly specifies what information (AVPs and
Application Ids) can be used for making general routing decisions. A rule
for the prioritization of redirect routing criteria when multiple route entries
are found via redirects has also been added.
 Simplified Diameter peer discovery.
” The Diameter discovery process now supports only widely used
discovery schemes; the rest have been deprecated.

Diameter Training Session - Nov 2013 - v01 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diameter Training Session - Nov 2013 - v01 PDF

Uploaded by

Copyright:

Available Formats

interne Groupe

Orange Labs recherche & développement

3 Diameter Message and AVP Formats

4 Diameter Connection Management

6 Diameter Session Management

2 France Telecom Group confidential

Diameter, successor of RADIUS

 The Diameter protocol was derived from RADIUS, and designed to be

” Capabilities negotiation Front-end

Diameter in mobile networks

 The Diameter base protocol and applications developed above

“Some” Applications in 3GPP Mobile networks

Application IETF Diameter Application

“Some” Applications in 3GPP Mobile networks

Diameter - Basic Functionality

 Diameter is built on a framework that consists of:

Orange Labs - Research & Development

 A set of Applications used in extension of the Base protocol

Orange Labs - Research & Development

 Base protocol or applications can be extended via addition of commands

Types of Diameter nodes

 Diameter Clients and Severs

Orange Labs - Research & Development

1. Request 2. Redirect Notification

Orange Labs - Research & Development

6. Answer 5. MAP Answer

Orange Labs - Research & Development

Connections vs. Sessions

 Connection: transport-level connection between two peers that

realmA.com User Session x realmB.com

Diameter Routing principles

Orange Labs - Research & Development

Diameter Client Node @ some.realm.com Diameter Server Node @ other.realm.com

Diameter Diameter Diameter Diameter

Session Management Session Management

Orange Labs - Research & Development

 Any Diameter node will support the Diameter base protocol

Orange Labs - Research & Development

Diameter Message Format

22 Orange Labs - Research & Development France Telecom Group confidential

Diameter Message Format •Max size: 16,7 Mo

Version Message Length

23 Orange Labs - Research & Development France Telecom Group confidential

Diameter Message Format •Max size: 16,7 Mo

Version Message Length •Code value identifying a

24 Orange Labs - Research & Development France Telecom Group confidential

Diameter Message Format •Max size: 16,7 Mo

Version Message Length •Code value identifying a

AVP 1 AVP 2 AVP 3 Etc.

25 Orange Labs - Research & Development France Telecom Group confidential

Diameter Message Format •Max size: 16,7 Mo

Version Message Length •Code value identifying a

AVP 1 AVP 2 AVP 3 Etc.

• Matching requests and answers per connection

26 Orange Labs - Research & Development France Telecom Group confidential

Diameter Message Format •Max size: 16,7 Mo

Version Message Length •Code value identifying a

AVP 1 AVP 2 AVP 3 Etc.

• Matching requests and answers per connection

27 Orange Labs - Research & Development France Telecom Group confidential

Diameter Message Format •Max size: 16,7 Mo

Version Message Length •Code value identifying a