1. Diameter Tutorial - IETF67
IETF67 – Diameter Tutorial Diameter Base Protocol Details Victor Fajardo and Yoshihiro Ohba Toshiba America Research Inc.
Diameter Tutorial - IETF67

2. 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

3. 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
Connection
Management
Base Protocol
Base Protocol
Diameter Tutorial - IETF67

4. 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

5. Diameter - Message Format
Diameter Header
AVP
AVP
AVP
AVP Header
AVP Data
Diameter Header =
Version, Length, Flags, Code, AppId, H2H Id, E2E Id
Code, Flag, Length, Vendor-Id (Opt)
AVP Header =
Each message must be defined using an ABNF grammar
Pre-defined AVP data types (Integer32, Float, OctetString etc.)
Diameter Tutorial - IETF67

6. 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

7. Connection Management
Peer Discovery
Transport
Capabilities negotiation
Peer liveness and disconnection
Diameter Tutorial - IETF67

8. 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

9. 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

10. 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

11. 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

12. 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

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

14. 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

15. Diameter Tutorial - IETF67
Diameter Agent Overview
Redirect
Agent
2. Request
3. Redirect Notification
1. Request
4. Request
Client
Relay/Proxy
Agent
Server
5. Answer
6. Answer
realmB.com
realmA.com
Request/Answer Path:
Normal Relay or Proxy: 1, 4, 5, 6
Re-directed Agent: 1, 2, 3, 4, 5, 6
Diameter Tutorial - IETF67

16. Diameter Tutorial - IETF67
Request Routing
Information used for routing:
Application-Id: present is in the header
Destination-Host OR Destination-Realm AVP
Routing rules:
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
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

17. Request Routing (Cont’d) 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

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

19. 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
If found, forward answer to appropriate peer and remove request from the queue
Otherwise, discard
Diameter Tutorial - IETF67

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

21. 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 re-established
Relay
3. Request
T-bit set
Request
Queue
4. Answer
2. Request
T-bit set
Server
5. Answer
1. Request
2. Request
Client
Relay
Request
Queue
Request
Queue
3. Answer
4. Answer
Diameter Tutorial - IETF67

22. 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

23. Diameter Tutorial - IETF67
Session Management
Diameter Sessions - definitions
Session types and statefulness
Authentication and Authorization Sessions
Accounting Sessions
Diameter Tutorial - IETF67

24. 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

25. 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

26. 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

27. Diameter Tutorial - IETF67
Accounting Sessions
Uses Base Protocol messages ACR/ACA
Accounting Session State Machines:
CLIENT
SERVER/STATELESS
SERVER/STATEFUL
Diameter Tutorial - IETF67

28. 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

29. 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

30. 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

31. Interoperability with RADIUS
Diameter is upwards compatible with RADIUS, so
Messages and AVPs
AVP codes is reused from RADIUS
Command codes 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

32. Interoperability with RADIUS (Cont’d)
Translations issues
Diameter messages can be larger than maximum RADIUS packet
Ongoing work
Mapping of new RADIUS extension types to Diameter
Diameter Tutorial - IETF67

33. 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

34. Diameter Tutorial - IETF67
End of Tutorial
Thank You
Diameter Tutorial - IETF67