IETF67 Diameter Tutorial

Diameter Base Protocol Details

Victor Fajardo and Yoshihiro Ohba
Toshiba America Research Inc.

Diameter Tutorial - IETF67

Tutorial Outline Diameter

Basic Functionality Message Format

Protocol Details
Connection Management Routing Session Management

Creating new applications Improvements over RADIUS

RADIUS to Diameter Transition Support

Recent Topics
Diameter Tutorial - IETF67

Diameter - Basic Functionality

Diameter Client Node at somerealm.com Diameter Server Node at otherrealm.com

Diameter Client Application

Diameter Server Application

Session Management

Session Management

Routing Management

Routing Management

Connection Management
Base Protocol
Diameter Tutorial - IETF67

Connection Management
Base Protocol

Diameter - Basic Functionality

Base Protocol
Connectivity: Peering and Routing Application support: Application session management

Applications
Purpose specific: NASREQ, MIPv4, SIP etc. Identified by application Id
Every application MUST have an IANA-assigned application identifier Used also for diameter message routing

Diameter Tutorial - IETF67

Diameter - Message Format

Diameter Message:
Diameter Header AVP AVP AVP

AVP Header

AVP Data

Diameter Header = AVP Header =

Version, Length, Flags, Code, AppId, H2H Id, E2E Id Code, Flag, Length, Vendor-Id (Opt)

Each message must be defined using an ABNF grammar

Pre-defined AVP data types (Integer32, Float, OctetString etc.)
Diameter Tutorial - IETF67

Diameter ABNF Example

<CER> ::= < Diameter Header: 257, REQ > { Origin-Host } /* Required AVP, Occurrence: 1 */ { Origin-Realm } 1* { Host-IP-Address } /* Required AVP, Occurrence: 1+ */ { Vendor-Id } { Product-Name } [ Origin-State-Id ] /* Optional AVP, Occurrence: 0 or 1 */ * [ Supported-Vendor-Id ] /* Optional AVP, Occurrence: 0+ */ * [ Auth-Application-Id ] * [ Inband-Security-Id ] * [ Acct-Application-Id ] * [ Vendor-Specific-Application-Id ] [ Firmware-Revision ] * [ AVP ]

Note: /* */ is not part of ABNF

Diameter Tutorial - IETF67

Connection Management
Peer Discovery Transport Capabilities negotiation Peer liveness and disconnection

Diameter Tutorial - IETF67

Peer Discovery

Peer discovery mechanisms (in order of preference)

Static configuration: mandatory SLPv2 and DNS: optional
DNS mechanisms to use (in order of execution)
NAPTR Address of record

Authorization of discovered peer is mandatory

Diameter Tutorial - IETF67

Transport 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 and IPSec

Selection Process (in order of execution)

IPSec, SCTP, TCP, TLS
SCTP or TCP is always attempted prior to capabilities exchange TLS tried after capability negotiation IPSec and TLS maybe used exclusively

Diameter Tutorial - IETF67

Capabilities Negotiation Capabilities Exchange

Use of Capabilities-Exchange (CER/CEA) messages Message exchange advertises:
Peer Identity Security schemes Indicates the use of TLS SCTP host addresses if used

CER/CEA may or may not be protected

Peer Table Creation

Lists all peers that passes capabilities negotiation Indicates the connection status of each peers Also used for message routing
Diameter Tutorial - IETF67

Peer Liveness and Disconnection

Liveness Test
Use of Device-Watchdog exchange (DWR/DWA) Aid in Failover performance: pro-active detection of failure

Disconnection
Use of Disconnect-Peer exchange (DPR/DPA) Provides hints for future reconnection attempts Routing table updates

Diameter Tutorial - IETF67

Routing
Types of Diameter Nodes Request Routing Realm Routing Table Answer Routing Loop Detection Failover-Failback Procedure Duplicate Detection

Diameter Tutorial - IETF67

Types of Diameter Nodes Diameter Clients and Severs

Request and Answer Originators
Where application normally reside

Advertises supported applications only

Diameter Agents
Request and Answer forwarders Adds routing information to the message Relay Agents
Provides basic message forwarding Does not inspect content of the message other than DestinationHost and/or Realm and AppIds Advertises support all applications
Diameter Tutorial - IETF67

Types of Diameter Nodes

Proxy Agents
Inspects and possibly modifies contents of the request or answer it is forwarding.
Useful in scenarios such policy enforcement, admission control, provisioning etc Can maintain session state

Examples: Translation agents, RADIUS<->DIAMETER

Re-Direct Agents
Does not forward messages but notifies the previous hop of the new next-hop to use Advertises support all applications

Diameter Tutorial - IETF67

Diameter Agent Overview

Redirect Agent 2. Request 1. Request 3. Redirect Notification 4. Request Relay/Proxy Agent 6. Answer
Request/Answer Path:
Normal Relay or Proxy: 1, 4, 5, 6 Re-directed Agent: 1, 2, 3, 4, 5, 6
Diameter Tutorial - IETF67

Client

Server
5. Answer

realmA.com

realmB.com

Request Routing
Information used for routing:
Application-Id: present is in the header Destination-Host OR Destination-Realm AVP

Routing rules:
1. 2. 3. If local identity == Destination-Host AVP then process locally, otherwise If peer identity == Destination-Host AVP then send that peer, otherwise Lookup realm table with Destination-Realm and AppId
a. b. If found send to the designated next-hop Otherwise, send an UNABLE_TO_DELIVER answer

Use of Request Queue

Successfully forwarded request are queued
Diameter Tutorial - IETF67

Request Routing (Contd)

Realm Routing Table

List of realm routing entries Realm routing entry looks like:
Realm (*), AppId (**), Action, Next-hop Peer, isStatic, ExpireTime
Realm: Primary key, matched with Destination-Realm Avp AppId: Secondary key, matched with AppId in message header Action: For each matching entry, possible actions are:
LOCAL, RELAY, PROXY, REDIRECT

isStatic: Indication of static or dynamic route ExpireTime: Time before dynamic route are no longer valid
Diameter Tutorial - IETF67

Routing Overview
SomeOtherRealm.com 1. Request (EAP, Server.RealmB.com) 2. Request (EAP, Server.RealmB.com) Diameter Server 3. Answer Server.RealmB.com

Diameter Client
Request Queue

Relay/Proxy Agent
Request Queue

4. Answer Client.RealmA.com Relay.RealmB.com

Example Realm Routing Table for Relay/Proxy Agent: 1. RealmB.com a. AppId=EAP, Action=PROXY, Next-Hop=Server.RealmB.com, isStatic=TRUE b. AppId=xxx, Action=RELAY, Next-Hop=Server.RealmB.com, isStatic=TRUE 2. RealmA.com a. AppId=xxx, Action=RELAY, Next-Hop=Client.RealmA.com, isStatic=TRUE 3. SomeOtherRealm.com a. AppId=EAP, Action=REDIRECT, Next-Hop=Server.RealmB.com, isStatic=FALSE, ExpireTime=3600
Diameter Tutorial - IETF67

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 Lookup Hop-by-Hop Id in request queue
a. b. If found, forward answer to appropriate peer and remove request from the queue Otherwise, discard
Diameter Tutorial - IETF67

For answer forwarders:

Loop Detection Recording the Routing Path

Forwarding agents add Route-Record AVPs

Detection
Local host identity must not be present in the Route-Record AVP Send LOOP_DETECTED answer

Diameter Tutorial - IETF67

Failover-Failback Procedure
Failover: Attempt to re-route pending request to an alternate peer in case of transport failure
T bit is set for re-routed requests

Failback: Switch back to the original next hop when connection is reestablished Relay
2. Request T-bit set
Request Queue

3. Request T-bit set 4. Answer

5. Answer

Server

Client
Request Queue

1. Request

Relay
Request Queue

2. Request 3. Answer

4. Answer

Diameter Tutorial - IETF67

Duplicate Detection
Duplicates can occur
Due to Failover Nodes re-sending un-answered requests: Due to reboot

Detection
End-to-End Id is unique for a node Re-sent request must have T-flag set Therefore, use T-flag as a hint for possible duplication, then
Use End-to-End Id and Origin-Host AVP to detect duplication Duplicate request SHOULD cause the same answer to be sent

Other Considerations
Use of Session-Id for duplicate detection in accounting records Time needed to wait for duplicate messages
Diameter Tutorial - IETF67

Session Management
Diameter Sessions - definitions Session types and statefulness Authentication and Authorization Sessions Accounting Sessions

Diameter Tutorial - IETF67

Diameter Sessions definitions

What is a session?
A session is a related progression of events devoted to a particular activity

Applications provide guidelines as to when a session begins and ends Sessions are identified by Session-Id
Globally and eternally unique
<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]
DiameterIdentity: Senders identity in FQDN High and Low 32 bits: Decimal representation of a 64-bit value, monotonically increased Optional value: Implementation specific, i.e. MAC address, timestamp etc

Diameter Tutorial - IETF67

Session types and statefulness

Two types of sessions by usage

Authorization session is used for authentication and/or authorization Accounting session is used for accounting

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
Diameter Tutorial - IETF67

Authentication and Authorization Sessions Auth-Session-State indicates statefulness For stateful session
Session teardown uses Base Protocol messages ASR/ASA and STR/STA Support for Server-Initiated Re-Auth
Uses Base Protocol message RAR/RAA

Authorization Session State Machines:

CLIENT/STATELESS CLIENT/STATEFUL SERVER/STATELESS SERVER/STATEFUL
Diameter Tutorial - IETF67

Accounting Sessions

Uses Base Protocol messages ACR/ACA Accounting Session State Machines:

CLIENT SERVER/STATELESS SERVER/STATEFUL

Diameter Tutorial - IETF67

Accounting-related AVPs
Accounting-Record-Type AVP indicates type of accounting record: Acct-Interim-Interval AVP specifies how and when to generate accounting records Accounting-Record-Number AVP identifies an accounting record Acct-Session-Id AVP is 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

Diameter Tutorial - IETF67

Creating a new application

Criteria: New application is unable to fit within an existing application without requiring major changes to the specification
Example major changes:
Adding new mandatory-to-support AVPs A command requires different round trips than what is currently in the specification Support for a new authentication method with new AVPs

As a last resort Advocates reuse of existing applications and AVPs

Diameter Tutorial - IETF67

Improvements over Basic RADIUS

Features inherently offered by diameter Reliable and secure transport Failover Agent support Server-initiated messages Capabilities negotiation Peer discovery and configuration
RADIUS Extensions developed in RADEXT WG also provides most of these functionality, such as RFC3576
Diameter Tutorial - IETF67

Interoperability with RADIUS

Diameter is upwards compatible with RADIUS, so Messages and AVPs
AVP codes 1-255 is reused from RADIUS Command codes 0-255 is reused from RADIUS Diameter NASREQ (RFC4005) maps RADIUS messages to/from Diameter AA-Request and AA-Answer message

Use of RADIUS<->Diameter Translation Agents

Diameter Tutorial - IETF67

Interoperability with RADIUS (Contd)

Translations issues
Diameter messages can be larger than maximum RADIUS packet
Ongoing work

Mapping of new RADIUS extension types to Diameter

Ongoing work
Diameter Tutorial - IETF67

Recent topics under discussion

Usage of Nas-Port-Type and Service-Type vs. defining a new Application Id Use of zero(0) AppId for all base protocol messages

Diameter Tutorial - IETF67

End of Tutorial
Thank You

Diameter Tutorial - IETF67