IETF 67 – Diameter Tutorial Diameter Base Protocol Details Victor Fajardo and Yoshihiro Ohba Toshiba America Research Inc. Diameter Tutorial - IETF 67
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 Tutorial - IETF 67
Diameter - Basic Functionality Diameter Client Node at somerealm. com Diameter Server Node at otherrealm. com Diameter Client Application Diameter Server Application Session Management Routing Management Connection Management Base Protocol Diameter Tutorial - IETF 67
Diameter - Basic Functionality • Base Protocol – Connectivity: Peering and Routing – Application support: Application session management • Applications – Purpose specific: NASREQ, MIPv 4, SIP etc. – Identified by application Id • Every application MUST have an IANA-assigned application identifier • Used also for diameter message routing Diameter Tutorial - IETF 67
Diameter - Message Format • Diameter Message: Diameter Header AVP Header Diameter Header = AVP AVP AVP Data Version, Length, Flags, Code, App. Id, H 2 H Id, E 2 E Id Code, Flag, Length, Vendor-Id (Opt) • Each message must be defined using an ABNF grammar • Pre-defined AVP data types (Integer 32, Float, Octet. String etc. ) Diameter Tutorial - IETF 67
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 - IETF 67
Connection Management • • Peer Discovery Transport Capabilities negotiation Peer liveness and disconnection Diameter Tutorial - IETF 67
Peer Discovery • Peer discovery mechanisms (in order of preference) – – Static configuration: mandatory SLPv 2 and DNS: optional • DNS mechanisms to use (in order of execution) – – • NAPTR Address of record Authorization of discovered peer is mandatory Diameter Tutorial - IETF 67
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 - IETF 67
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 Diameter Tutorial - IETF 67
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 Diameter Tutorial - IETF 67
Routing • Types of Diameter Nodes • Request Routing – Realm Routing Table • Answer Routing • Loop Detection • Failover-Failback Procedure • Duplicate Detection Diameter Tutorial - IETF 67
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 – Relay Agents • Provides basic message forwarding • Does not inspect content of the message other than Destination-Host and/or Realm and App. Ids • Advertises support all applications Diameter Tutorial - IETF 67
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 - IETF 67
Diameter Agent Overview Redirect Agent 2. Request 3. Redirect Notification 1. Request Relay/Proxy Agent Client realm. A. com 4. Request 6. Answer Server 5. Answer Request/Answer Path: • Normal Relay or Proxy: 1, 4, 5, 6 • Re-directed Agent: 1, 2, 3, 4, 5, 6 Diameter Tutorial - IETF 67 realm. B. com
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 Lookup realm table with Destination-Realm and App. Id 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 - IETF 67
Request Routing (Cont’d) • Realm Routing Table – List of realm routing entries – Realm routing entry looks like: Realm (*), App. Id (**), Action, Next-hop Peer, is. Static, Expire. Time • Realm: Primary key, matched with Destination-Realm Avp • App. Id: Secondary key, matched with App. Id in message header • Action: For each matching entry, possible actions are: – LOCAL, RELAY, PROXY, REDIRECT • is. Static: Indication of static or dynamic route • Expire. Time: Time before dynamic route are no longer valid Diameter Tutorial - IETF 67
Routing Overview Some. Other. Realm. com 1. Request (EAP, Server. Realm. B. com) Diameter Client Request Queue 2. Request (EAP, Server. Realm. B. com) Relay/Proxy Agent Request Queue 4. Answer Client. Realm. A. com Relay. Realm. B. com Diameter Server 3. Answer Server. Realm. B. com Example Realm Routing Table for Relay/Proxy Agent: 1. Realm. B. com a. App. Id=EAP, Action=PROXY, Next-Hop=Server. Realm. B. com, is. Static=TRUE b. App. Id=xxx, Action=RELAY, Next-Hop=Server. Realm. B. com, is. Static=TRUE 2. Realm. A. com a. App. Id=xxx, Action=RELAY, Next-Hop=Client. Realm. A. com, is. Static=TRUE 3. Some. Other. Realm. com a. App. Id=EAP, Action=REDIRECT, Next-Hop=Server. Realm. B. com, is. Static=FALSE, Expire. Time=3600 Diameter Tutorial - IETF 67
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 - IETF 67
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 - IETF 67
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 Relay 2. Request T-bit set Client Request Queue 1. Request 4. Answer Request Queue 4. Answer Server 5. Answer Relay Request Queue 2. Request 3. Answer Diameter Tutorial - IETF 67
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 - IETF 67
Session Management • Diameter Sessions - definitions • Session types and statefulness • Authentication and Authorization Sessions • Accounting Sessions Diameter Tutorial - IETF 67
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 <Diameter. Identity>; <high 32 bits>; <low 32 bits>[; <optional value>] • Diameter. Identity: 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 - IETF 67
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 - IETF 67
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 - IETF 67
Accounting Sessions • Uses Base Protocol messages ACR/ACA • Accounting Session State Machines: – CLIENT – SERVER/STATELESS – SERVER/STATEFUL Diameter Tutorial - IETF 67
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 - IETF 67
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 - IETF 67
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 v RADIUS Extensions developed in RADEXT WG also provides most of these functionality, such as RFC 3576 Diameter Tutorial - IETF 67
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 (RFC 4005) maps RADIUS messages to/from Diameter AA-Request and AA-Answer message – Use of RADIUS<->Diameter Translation Agents Diameter Tutorial - IETF 67
Interoperability with RADIUS (Cont’d) • Translations issues – Diameter messages can be larger than maximum RADIUS packet • Ongoing work – Mapping of new RADIUS extension types to Diameter • Ongoing work Diameter Tutorial - IETF 67
Recent topics under discussion • Usage of Nas-Port-Type and Service-Type vs. defining a new Application Id • Use of zero(0) App. Id for all base protocol messages Diameter Tutorial - IETF 67
End of Tutorial Thank You Diameter Tutorial - IETF 67
Скачать презентацию IETF 67 Diameter Tutorial Diameter Base Protocol
fad5d1dfb9b43b88fc1d92ddefd66374.ppt