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

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

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

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 RFC3588 - initial version RFC6733 – current version Diameter Session #1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Diameter Peer State Machine Diameter Session #1

Diameter Peer State Machine Diameter Session #1

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

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

Special Note on Relay and Redirection Diameter Session #1

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

Diameter Client Stateless Session Diameter Session #1

Diameter Server Stateful Session Diameter Session #1

Diameter Server Stateful Session Diameter Session #1

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

Questions ? Diameter Session #1