Download Report

IETF67 – Diameter Tutorial
Diameter Base Protocol Details
Victor Fajardo and Yoshihiro Ohba
Toshiba America Research Inc.
Diameter Tutorial - IETF67
Tutorial Outline
• Diameter
– Basic Functionality
– Message Format
• Protocol Details
– Connection Management
– Routing
– Session Management
• Creating new applications
• Improvements over Basic RADIUS
– Interoperability with RADIUS
• Recent Topics
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
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
Diameter - Message Format
• Diameter Message:
Diameter Header
AVP Header
Diameter Header =
AVP Header =
AVP
AVP
AVP
AVP Data
Version, Length, Flags, Code, AppId, H2H Id, E2E Id
Code, Flag, Length, Vendor-Id (Opt)
• Each message must be defined using an ABNF grammar
• Pre-defined AVP data types (Integer32, Float, OctetString etc.)
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
Connection Management
•
•
•
•
Peer Discovery
Transport
Capabilities negotiation
Peer liveness and disconnection
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 records for destination address ‘_diameter._sctp’.realm or
‘_diameter._tcp’.realm
Authorization of discovered peer is mandatory
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
Capabilities Negotiation
• Capabilities Exchange
– Use of Capabilities-Exchange (CER/CEA) messages
– Message exchange advertises:
•
•
•
•
Supported applications
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
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 and peer table updates
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
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 (Route-Record AVP)
– Relay Agents
• Provides basic message forwarding
• Does not inspect content of the message other than DestinationHost and/or Realm and AppIds
• Advertises support all applications
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, 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
Diameter Agent Overview
Redirect.RealmB.com
Redirect
Agent
2. Request
3. Redirect Notification
1. Request
4. Request
Relay/Proxy
Agent
Client
6. Answer
Client.RealmA.com
Server
5. Answer
Server.RealmB.com
Request/Answer Path:
• Normal Relay or Proxy: 1, 4, 5, 6
• Re-directed Agent: 1, 2, 3, 4, 5, 6
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.
2.
3.
If local identity == Destination-Host AVP then process locally,
otherwise
If peer identity == Destination-Host AVP then send that peer,
otherwise (use Peer Table)
Lookup realm table with Destination-Realm and AppId
a.
b.
•
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
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
Routing Overview
SomeOtherRealm.com
1. Request (EAP, RealmB.com)
Diameter
Client
Request
Queue
2. Request (EAP, Server.RealmB.com)
Relay/Proxy
Agent
Request
Queue
4. Answer
Client.RealmA.com
Relay.RealmB.com
Diameter
Server
3. Answer
Server.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
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.
b.
If found, forward answer to appropriate peer and remove request
from the queue
Otherwise, discard
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
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 reestablished
3. Request
T-bit set
Relay2
2. Request
T-bit set
Client
Request
Queue
1. Request
4. Answer
Request
Queue
4. Answer
Server
5. Answer
Relay1
Request
Queue
2. Request
3. Answer
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
Session Management
• Diameter Sessions - definitions
• Session types and statefulness
• Authentication and Authorization
Sessions
• Accounting Sessions
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
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
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
Accounting Sessions
• Uses Base Protocol messages ACR/ACA
• Accounting Session State Machines:
– CLIENT
– SERVER/STATELESS
– SERVER/STATEFUL
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 accounting
behavior
Diameter Tutorial - IETF67
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
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
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
Diameter Tutorial - IETF67
Interoperability with RADIUS (Cont’d)
• Translations issues (to be resolved?)
– Diameter MTU is larger than RADIUS MTU
– Maximum Diameter AVP size is larger than
maximum RADIUS attribute size
– Mapping of RADIUS extended attributes to
Diameter AVPs
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
• Explicit Routing
Diameter Tutorial - IETF67
End of Tutorial
Thank You
Diameter Tutorial - IETF67