rfc3588

7/30/2019 rfc3588

1/34

Diameter Tutorial - IETF67

IETF67 Diameter Tutorial

Diameter Base Protocol Details

Victor Fajardo and Yoshihiro OhbaToshiba America Research Inc.

7/30/2019 rfc3588

2/34


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

7/30/2019 rfc3588

3/34


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

7/30/2019 rfc3588

4/34


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

7/30/2019 rfc3588

5/34


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 IdDiameter Header =

Code, Flag, Length, Vendor-Id (Opt)AVP Header =

7/30/2019 rfc3588

6/34


Diameter ABNF Example

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

7/30/2019 rfc3588

7/34


Connection Management

Peer Discovery

Transport

Capabilities negotiation

Peer liveness and disconnection

7/30/2019 rfc3588

8/34


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

7/30/2019 rfc3588

9/34


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

7/30/2019 rfc3588

10/34


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

7/30/2019 rfc3588

11/34


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

7/30/2019 rfc3588

12/34


Routing

Types of Diameter Nodes

Request Routing

Realm Routing Table Answer Routing

Loop Detection

Failover-Failback Procedure Duplicate Detection

7/30/2019 rfc3588

13/34



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

7/30/2019 rfc3588

14/34



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

Re-Direct Agents

Does not forward messages but notifies the previous hop of the new

next-hop to use

Advertises support all applications

7/30/2019 rfc3588

15/34


RedirectAgent

Client

1. Request

2. Request 3. Redirect Notification

4. Request

5. Answer6. 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

AgentServer

Diameter Agent Overview

7/30/2019 rfc3588

16/34


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-hopb. Otherwise, send an UNABLE_TO_DELIVER answer

Use of Request Queue

Successfully forwarded request are queued

7/30/2019 rfc3588

17/34


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

7/30/2019 rfc3588

18/34


1. Request (EAP, Server.RealmB.com)

3. Answer4. 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

7/30/2019 rfc3588

19/34


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

7/30/2019 rfc3588

20/34


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

7/30/2019 rfc3588

21/34


Failover-Failback Procedure

Failover: Attempt to re-route pending request to an alternate peer incase 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. AnswerRequestQueue

Request

Queue

Request

Queue

7/30/2019 rfc3588

22/34


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

7/30/2019 rfc3588

23/34


Session Management

Diameter Sessions - definitions

Session types and statefulness Authentication and Authorization

Sessions

Accounting Sessions

7/30/2019 rfc3588

24/34


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 sessionbegins and ends

Sessions are identified by Session-Id Globally and eternally unique

;;[;]

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

7/30/2019 rfc3588

25/34


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

7/30/2019 rfc3588

26/34


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

7/30/2019 rfc3588

27/34


Accounting Sessions

Uses Base Protocol messages ACR/ACA

Accounting Session State Machines:

CLIENT

SERVER/STATELESS

SERVER/STATEFUL

7/30/2019 rfc3588

28/34


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 accountingbehavior

7/30/2019 rfc3588

29/34


Creating a new application

Criteria: New application is unable to fit withinan existing application without requiring majorchanges to the specification Example major changes:

Adding new mandatory-to-support AVPs

A command requires different round trips than what iscurrently in the specification

Support for a new authentication method with new AVPs

As a last resort Advocates reuse of existing applications and

AVPs

7/30/2019 rfc3588

30/34


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 alsoprovides most of these functionality, such as RFC3576

7/30/2019 rfc3588

31/34


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 RADIUSDiameter Translation Agents

7/30/2019 rfc3588

32/34


Interoperability with RADIUS (Contd)

Translations issues

Diameter messages can be larger thanmaximum RADIUS packet

Ongoing work

Mapping of new RADIUS extension types to

Diameter Ongoing work

7/30/2019 rfc3588

33/34


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

7/30/2019 rfc3588

34/34


End of Tutorial

Thank You

rfc3588

Documents

Transcript of rfc3588