1. Diameter Base Protocol (RFC6733)
Session #1
Author: Victor I. Fajardo
Date: Sept. 25, 2013
Diameter Session #1

2. Agenda History of the Diameter Protocol Protocol Details
How did it evolve
Major Features
Protocol Details
Overview
Base protocol
Diameter applications
Protocol Framing
Header
AVPs
Diameter Session #1

3. User Session State machines
Diameter Peers
Connection State machine
Transport
Capabilities exchange
Message Processing
Request Routing
Answer processing
User Session State machines
Stateful and Stateless
Error Handling
Questions
Diameter Session #1

4. History of the Diameter Protocol
Evolution
Developed in 1998 to overcome the limitations of RADIUS
Evolution of true AAA framework
Diverged from RADIUS compatibility as protocol was being developed
RFC initial version
RFC6733 – current version
Diameter Session #1

5. Major Features Reliable transport protocols (TCP or SCTP, not UDP)
Network or transport layer security (IPsec or TLS)
Transition support for RADIUS, although Diameter is not fully compatible with RADIUS
Larger address space for attribute-value pairs (AVPs) and identifiers (32 bits instead of 8 bits)
Client-Server protocol, with the exception of supporting some server-initiated messages as well
Both stateful and stateless models can be used
Dynamic discovery of peers (using DNS SRV and NAPTR)
Capability negotiation
Diameter Session #1

6. Major Features - Continued
Supports application layer acknowledgements, defines failover methods and state machines (RFC 3539)
Error notification
Better roaming support
More easily extended; new commands and attributes can be defined
Aligned on 32-bit boundaries
Basic support for user-sessions and accounting
Diameter Session #1

7. Protocol Details Base protocol Transport Application ID
Transport Profile in RFC3539
Mandatory support for TLS and TCP (port 3868) on server nodes. TCP for client nodes.
Connector MUST run on port 5658
Security - TLS
Guidelines on SCTP
Application ID
Globally unique ID to identify applications and associated messages
MUST have an accompanying RFC
Connections vs. Session
Connection is establishment of transport
Session is the exchange of diameter messages
Diameter Session #1

8. Peer Table List of known diameter adjacent peers
Maintains connectivity state peer known peer
Table Entry
Description
Host Identity
FQDN (Fully qualified domain name) of the diameter peer/node
Status
Current state of the connection. Peer state machine state.
Static or Dynamic
Is the peer dynamically (via DNS) or statically configured
Expiration Time
For dynamically discovered peer, how long before refreshing the connection
Connection type
TLS/TCP and DTLS/SCTP
Diameter Session #1

9. Topology of Diameter Peer
companyB.com
companyA.com
ServerD
ServerA
ServerB
ServerC
ServerE
Message Request Routing
Destination-Realm = companyB.com
Destination-Host=ServerD.companyB.com
Red Line - Peer connectivity
Blue Line – Session connectivity
Diameter Session #1

10. Routing Table Table Entry Description Realm Name
Realm being serviced by this diameter node. Longest match during lookup.
Application ID
Application ID supported by this route
Local Action
Dictates how the request message will be by the node (LOCAL, PROXY, RELAY or REDIRECT)
Server ID
FQDN of the server servicing the request
Static or Dynamic
Whether this route was dynamically discovered or not
Expiration Time
For dynamically discovered routes. How long before refresh.
Diameter Session #1

11. Role of Diameter Agents
Agent Functions
Relay Agent
General request routing
Proxy Agent
Stateful processing
Redirect Agent
Stateless processing
Redirect function
NAS
Agent
Home Server A
Home Server B
Relay and/or Proxy functions
Diameter Session #1

12. Diameter Header Format
Key Fields:
Command Code – Specific command of this application
Application ID – The Diameter application this message belongs to
Hop-by-Hop ID – Used to match replies for a previous request
Diameter Session #1

13. Diameter Message Format
Diameter Message is composed of
A diameter Header
Followed by one or more Diameter AVP’s
Defined by a a an ABNF
Diameter Message
Header
Fixed AVP(s)
Mandatory AVP(s)
Optional AVP(s)
Diameter Session #1

14. Diameter AVP Format Definition of an AVP AVP – Attribute Value Pair
Makes up the message body of a diameter messge
Key Fields:
AVP Code – Unique AVP number
Flags – Tells whether this is vendor specific or part of the standard. It also indicates whether this is a mandatory AVP or not.
New AVP’s can be derived from existing AVP
Diameter Session #1

15. Diameter AVP Format
Data formats for AVP are defined by the base protocol
All AVP’s MUST conform to this format
Important data formats
DiameterIdentity
Used for identifying a diameter node
FQDN/Realm of a node
DiameterURI
Also used for identifying a diameter node with extra information
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
transport-protocol = ( "tcp" / "sctp" / "udp" )
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
Example: aaa://host.example.com:6666;transport=tcp
Diameter Session #1

16. Diameter AVP Format Grouped-AVPs Session-Id AVPS Other important AVP’s
Destination-Host
Destination-Realm
Origin-Host
Origin- Realm
Diameter Session #1

17. Base Protocol Command Codes
Commands for Peer connection maintenance
Commands for User connection maintenance
Diameter Session #1

18. Diameter Peer State Machine
Peer Discovery
Use of DNS and NAPTR records
Capabilities exchange
Use CER/CEA to exchange node capability
Negotiate security between diameter nodes
Negotiate common diameter applications
Announce Firmware-Revision of a diameter node
Declares all Host-IP address to be used for SCTP multi-homing
Exchange of keep-alive test
Watch-Dog exchange
Allow for election
Two(2) peers can negotiate who will initiate a connection between them
Diameter Session #1

19. Diameter Peer State Machine
Diameter Session #1

20. Diameter Peer State Machine
Diameter Session #1

21. Diameter Request Routing
Done via Realms and Application ID’s
Request that can be forwarded uses Destination-Realm
In case of NAS’s the realm can be retrieved in the User-Name AVP (NAI)
Predictive-Loop avoidance
Each node that forwards a request will add its identity to a Route-Record AVP
Redirecting request
Built-in load balancer
Stateless method to tell the sender of the request to forward the message to another node
Relaying and Proxy
Relay is basic request forwarding
Proxy provides extra processing prior to forwarding
Can keep state
Answer Processing
Route answers via Hop-by-Hop identifier
Validation of Session-Id
Diameter Session #1

22. Diameter Request Routing Rules
Request that cannot be forwarded MUST not have Destination-Realm and Destination-Host
Request used to establish connectivity
Request sent to the home realm but not a specific server
Can be re-routed by a redirect agent
Use Destination-Realm
No Destination-Host
Request sent to a specific home server
Use Destination-Host
Validation of shared keys if any
Diameter Session #1

23. Special Note on Relay and Redirection
Diameter Session #1

24. Diameter User State Machine
Applications define the state machine
Base protocol defines
Authorization state machine
Accounting state machine
Both are historical models for AAA frameworks
Contemporary diameter application defines stateless models with single request/response exchanges
Diameter Session #1

25. Diameter Client Stateless Session
Diameter Session #1

26. Diameter Server Stateful Session
Diameter Session #1

27. Diameter Server Stateful Session
Diameter Session #1

28. Diameter Error Handling
Result-Code error types
Informational – can be used as a hint or warning of impending severe errors
Protocol – indication of a problem with implementation
Message validation errors
Transient and Permanent – Indication of environmental/system issues
Connection errors
Routing errors
Application specific errors
Fail-Over and Fail-back
Diameter Session #1

29. Questions ?
Diameter Session #1