Diameter Base Protocol Details – Diameter Tutorial IETF67 Victor Fajardo and Yoshihiro Ohba
Download ReportTranscript Diameter Base Protocol Details – Diameter Tutorial IETF67 Victor Fajardo and Yoshihiro Ohba
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 Connection Management Base Protocol Diameter Tutorial - IETF67 Routing Management Connection Management Base Protocol
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 AVP AVP AVP Header AVP Data Diameter Header =
Version, Length, Flags, Code, AppId, H2H Id, E2E Id
AVP Header =
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
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 Destination Host 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 Agent Redirect.RealmB.com
Client Client.RealmA.com
2. Request 1. Request Relay/Proxy Agent 3. Redirect Notification 4. Request Server 6. Answer 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 1.
2.
3.
Routing rules: 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) 2. Request (EAP, Server.RealmB.com) Diameter Client Relay/Proxy Agent Request Queue Client.RealmA.com
4. Answer Request Queue Relay.RealmB.com
Example Realm Routing Table for Relay/Proxy Agent: 3. Answer Diameter Server Server.RealmB.com
1.
2.
3.
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 RealmA.com
a.
AppId=xxx, Action=RELAY, Next-Hop=Client.RealmA.com, isStatic=TRUE 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.
If found, forward answer to appropriate peer and remove request from the queue b.
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 re established Client Request Queue Relay2 3. Request T-bit set 2. Request T-bit set 1. Request Request Queue 4. Answer 5. Answer 2. Request Relay1 Request Queue 3. Answer 4. Answer Server 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: 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