RFC 3588

Diameter Tutorial - IETF67
IETF67 Diameter Tutorial

Diameter Base Protocol Details

Victor Fajardo and Yoshihiro Ohba
Toshiba America Research Inc.
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
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

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 - 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 Id
Diameter Header =
Code, Flag, Length, Vendor-Id (Opt)
AVP Header =
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
Connection Management

Peer Discovery
Transport
Capabilities negotiation
Peer liveness and disconnection

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
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
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
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
Routing

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


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


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

Redirect
Agent
Client
1. Request
2. Request 3. Redirect Notification
4. Request
5. Answer
6. 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
Agent
Server
Diameter Agent Overview
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-hop
b. Otherwise, send an UNABLE_TO_DELIVER answer
Use of Request Queue
Successfully forwarded request are queued
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
1. Request (EAP, Server.RealmB.com)
3. Answer 4. 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
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
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
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

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. Answer Request
Queue
Request
Queue
Request
Queue
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

Session Management

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

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

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
Accounting Sessions

Uses Base Protocol messages ACR/ACA
Accounting Session State Machines:
CLIENT
SERVER/STATELESS
SERVER/STATEFUL
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
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
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

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

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
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
End of Tutorial
Thank You

RFC 3588

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

RFC 3588

Caricato da

Copyright:

Formati disponibili

Diameter Tutorial - IETF67

IETF67 Diameter Tutorial

Potrebbero piacerti anche