7/30/2019 rfc3588
1/34
Diameter Tutorial - IETF67
IETF67 Diameter Tutorial
Diameter Base Protocol Details
Victor Fajardo and Yoshihiro OhbaToshiba America Research Inc.
7/30/2019 rfc3588
2/34
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
7/30/2019 rfc3588
3/34
Diameter Tutorial - IETF67
Diameter
Client Application
Diameter
Server Application
Routing Management
Connection
Management
Connection
Management
Diameter Client Node at somerealm.com
Base Protocol Base Protocol
Diameter Server Node at otherrealm.com
Session Management
Routing Management
Session Management
Diameter - Basic Functionality
7/30/2019 rfc3588
4/34
Diameter Tutorial - IETF67
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
7/30/2019 rfc3588
5/34
Diameter Tutorial - IETF67
Diameter - Message Format
Diameter Header AVP AVP AVP
Diameter Message:
AVP Header AVP Data
Each message must be defined using an ABNF grammar Pre-defined AVP data types (Integer32, Float, OctetString etc.)
Version, Length, Flags, Code, AppId, H2H Id, E2E IdDiameter Header =
Code, Flag, Length, Vendor-Id (Opt)AVP Header =
7/30/2019 rfc3588
6/34
Diameter Tutorial - IETF67
Diameter ABNF Example
::= < 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
7/30/2019 rfc3588
7/34
Diameter Tutorial - IETF67
Connection Management
Peer Discovery
Transport
Capabilities negotiation
Peer liveness and disconnection
7/30/2019 rfc3588
8/34
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
7/30/2019 rfc3588
9/34
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
7/30/2019 rfc3588
10/34
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
7/30/2019 rfc3588
11/34
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
7/30/2019 rfc3588
12/34
Diameter Tutorial - IETF67
Routing
Types of Diameter Nodes
Request Routing
Realm Routing Table Answer Routing
Loop Detection
Failover-Failback Procedure Duplicate Detection
7/30/2019 rfc3588
13/34
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 Destination-
Host and/or Realm and AppIds
Advertises support all applications
7/30/2019 rfc3588
14/34
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, RADIUSDIAMETER
Re-Direct Agents
Does not forward messages but notifies the previous hop of the new
next-hop to use
Advertises support all applications
7/30/2019 rfc3588
15/34
Diameter Tutorial - IETF67
RedirectAgent
Client
1. Request
2. Request 3. Redirect Notification
4. Request
5. Answer6. Answer
Request/Answer Path:
Normal Relay or Proxy: 1, 4, 5, 6
Re-directed Agent: 1, 2, 3, 4, 5, 6
realmA.com realmB.com
Relay/Proxy
AgentServer
Diameter Agent Overview
7/30/2019 rfc3588
16/34
Diameter Tutorial - IETF67
Request Routing
Information used for routing: Application-Id: present is in the header
Destination-Host OR Destination-Realm AVP
Routing rules:
1. If local identity == Destination-Host AVP then process locally,otherwise
2. If peer identity == Destination-Host AVP then send that peer,
otherwise
3. Lookup realm table with Destination-Realm and AppId
a. If found send to the designated next-hopb. Otherwise, send an UNABLE_TO_DELIVER answer
Use of Request Queue
Successfully forwarded request are queued
7/30/2019 rfc3588
17/34
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
7/30/2019 rfc3588
18/34
Diameter Tutorial - IETF67
1. Request (EAP, Server.RealmB.com)
3. Answer4. Answer
Client.RealmA.com Server.RealmB.com
Relay/Proxy
Agent
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
Routing Overview
2. Request (EAP, Server.RealmB.com)
SomeOtherRealm.com
Diameter
Server
Diameter
Client
Request
Queue
Request
Queue
7/30/2019 rfc3588
19/34
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
For answer forwarders:
Lookup Hop-by-Hop Id in request queue
a. If found, forward answer to appropriate peer and remove request
from the queue
b. Otherwise, discard
7/30/2019 rfc3588
20/34
Diameter Tutorial - IETF67
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
7/30/2019 rfc3588
21/34
Diameter Tutorial - IETF67
Failover-Failback Procedure
Failover: Attempt to re-route pending request to an alternate peer incase of transport failure
T bit is set for re-routed requests
Failback: Switch back to the original next hop when connection is re-
established
Client Relay
Relay
Server
1. Request
4. Answer
2. Request
T-bit set
3. Request
T-bit set
4. Answer
5. Answer
2. Request
3. AnswerRequestQueue
Request
Queue
Request
Queue
7/30/2019 rfc3588
22/34
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
7/30/2019 rfc3588
23/34
Diameter Tutorial - IETF67
Session Management
Diameter Sessions - definitions
Session types and statefulness Authentication and Authorization
Sessions
Accounting Sessions
7/30/2019 rfc3588
24/34
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 sessionbegins and ends
Sessions are identified by Session-Id Globally and eternally unique
;;[;]
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
7/30/2019 rfc3588
25/34
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
7/30/2019 rfc3588
26/34
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
7/30/2019 rfc3588
27/34
Diameter Tutorial - IETF67
Accounting Sessions
Uses Base Protocol messages ACR/ACA
Accounting Session State Machines:
CLIENT
SERVER/STATELESS
SERVER/STATEFUL
7/30/2019 rfc3588
28/34
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 accountingbehavior
7/30/2019 rfc3588
29/34
Diameter Tutorial - IETF67
Creating a new application
Criteria: New application is unable to fit withinan existing application without requiring majorchanges to the specification Example major changes:
Adding new mandatory-to-support AVPs
A command requires different round trips than what iscurrently in the specification
Support for a new authentication method with new AVPs
As a last resort Advocates reuse of existing applications and
AVPs
7/30/2019 rfc3588
30/34
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 alsoprovides most of these functionality, such as RFC3576
7/30/2019 rfc3588
31/34
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 RADIUSDiameter Translation Agents
7/30/2019 rfc3588
32/34
Diameter Tutorial - IETF67
Interoperability with RADIUS (Contd)
Translations issues
Diameter messages can be larger thanmaximum RADIUS packet
Ongoing work
Mapping of new RADIUS extension types to
Diameter Ongoing work
7/30/2019 rfc3588
33/34
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
7/30/2019 rfc3588
34/34
Diameter Tutorial - IETF67
End of Tutorial
Thank You