1). Feature Benefits of Diameter:
A). SCTP replaced UDP : Better Transport
§ Diameter runs over a reliable transport, TCP or SCTP.
§ Lost packets are retransmitted at each hop.
§ TCP and SCTP adapt to network congestion.
§ SCTP offers reliable transport, since each node now is responsible for the retransmission of unacknowledged messages. This also avoids inappropriate retransmissions by the NAS.
§ Also, SCTP is a connection-oriented transport protocol with flow control and congestion avoidance mechanisms. As an alternative, TCP can still be used at the loss of the advantages introduced by SCTP.
§ A persistent connection with an application-level heartbeat message (Watchdog message) supports timely failover.
B). Keep-alive messages implemented
§ With a connection-oriented transport layer and the Diameter keep-alive messages, a Diameter node can detect the local failure of a peer.
§ This also offers a failover functionality, which avoids lengthy delay of services if an alternate server needs to be contacted.
C). Peer-to-Peer replaces Client/Server
§ While a RADIUS server was unable to terminate connections due to the client/server architecture of the system.
§ Diameter
D). Timestamp implemented
§ The timestamp in Diameter prevents the system for replay attacks, since every message can be uniquely identified and is not answered twice.
E). Space for extensions
§ The Diameter protocol offers room for vendor-specific commands and attributes, allowing for customizing without threatening interoperability.
F). IPSec and TLS implemented
§ As opposed to RADIUS, security is no longer accomplished by a mandatory shared secret, but by IP Security (IPsec) or Transport Layer Security (TLS).
G). Better Proxying
§ Hop-by-hop transport failure detection allows failover to occur at the appropriate place — proxies can locally failover to an alternate next-hop peer.
§ The proxy automatically does retransmission of pending request messages following a failover.
§ An AVP that identifies the ultimate destination allows multiple transactions for a given session to be routed to the same home server.
H). Better Session Control
§ Session management is independent of accounting.
§ Accounting information can be routed to a different server than authentication/ authorization messages.
§ Session termination is conveyed by a specific Session-Termination message rather than an Accounting Stop message.
§ The server may initiate a message to request session termination.
§ The server may initiate a message to request re-authentication and/or reauthorization of a user.
I). CMS (Cryptographic Message Syntax) allows End-to-End Security
§ The CMS Security module does not only admit hop-by-hop security as in previous protocols, but now also allows end-to-end security through digital signatures, while encryption prevents unauthorized reading of the messages' content
§ Hop-by-hop security is provided using IPSec or TLS.
§ End-to-end security protects the integrity and/or confidentiality of sensitive AVPs through intermediate proxies.
§ Diameter CMS application - end to end Diameter encryption and validation
CMS Security Application
§ The Diameter protocol may employ either IPsec or TLS for hop-by-hop integrity and confidentiality between two Diameter peers. However, Diameter endpoints might communicate through relay and proxy agents, and in such environments, security may be compromised.
§ The Diameter CMS (Cryptographic Message Syntax) application provides end-to-end authentication, integrity, confidentiality and non-repudiation at the AVP level. Individual AVP may be digitally signed and/or encrypted. Diameter proxies can add, delete or modify unsecured AVP in a message.
§ The Diameter CMS security application defines the Diameter messages and AVPs that are used to establish a security association between two Diameter nodes, and the AVPs used to subsequently carry secured data within Diameter messages.
§ The Diameter CMS security application makes use of two main techniques. Digital Signatures, along with Digital Certificates, provide authentication, integrity and nonrepudiation. Encryption provides confidentiality. The techniques can be used simultaneously to provide the required security.
J). Interoperability
§ The RADIUS protocol supports vendor-specific attributes but not vendor-specific commands. This has enticed vendors to create private command codes with resulting interoperability problems.
§ The Diameter protocol supports both vendor-specific attributes and vendor-specific commands.
2-1). Diameter Overview
§ Diameter is a protocol designed by IETF in RFC3588 for Authentication, Authorization and Accounting (AAA) purposes.
§ It consists of a base protocol and a set of extension.
§ The base protocol is not intended to be used by itself. It must be used with a service-specific extension.
§ IETF’s IANA defines the application id, command code, base AVP code, vendor id for Vendor Specific AVPs. They are designed to be unique.
2-2). Diameter Applications
§ Diameter must be used with a service-specific extension - Multiple standard org.s or network operators define their applications on diameter: IETF (NASREQ, Credit Control Application, etc.), 3GPP(Cx, Sh, Rf, etc), etc.
§ There are, at the moment, five applications for Diameter standardized by the IETF: Mobile IPv4, NASREQ, Credit control, EAP and SIP.
Multiple standard org.s or network operators define their applications on diameter:
§ Diameter Base Protocol (DBP)
§ NASREQ Application (NASREQ)
§ Mobile-IP Application (M-IP)
§ Diameter Credit Control Application (DCCA)
§ 3GPP/3GPP2 IMS Cx/Sh/Rf/Ro/...
2-3). Diameter Nodes
§ A Diameter node is a client, agent or server.
§ A Diameter client is a device at the edge of the network that performs access control.
§ A Diameter server handles the authentication, authorization and accounting requests for a specific realm.
§ A Diameter agent can be a relay, proxy, redirect or translation agent.
§ A Diameter agent may act in a Stateful manner for some requests while being stateless for others.
§ Diameter Agents might be Stateless (only maintains transaction state) or Stateful (maintains session state information, by keeping track of all authorized active sessions.
§ Each authorized session is bound to a particular service, and its state is considered active either until it is notified otherwise or by expiration)
§ A Realm is an administrative domain where the server resides in and often associated with ownership.
§ An administrative domain is the collection of resources (hosts, routers and the interconnecting networks) under the control of a single administrative authority.
§ The internet service provider “abc” has a network that is registered under one domain, e.g. abc.uk.
§ The difference between a domain and a realm is that a domain can consist of multiple realms.
§ Roaming among multiple realms is the situation where the user is connected to a network that is not the network of its own internet service provider.
A). Diameter Nodes: CLIENT
§ A Diameter client - Requests AAA services - is a device at the edge of the network that performs access control.
B). Diameter Nodes: SERVER
§ SERVER: Handles AAA requests - Handles authentication, authorization, accounting for a realm
§ A Diameter server handles the authentication, authorization and accounting requests for a specific realm.
C). Diameter Nodes: RELAY AGENT
§ Routes messages based on content - Routing of diameter messages
§ A relay agent routes messages to other Diameter nodes based on the information found in the messages.
§ A relay agent is allowed to modify the messages by inserting and removing routing information only, but is not allowed to modify other parts of the messages.
§ The relay agent has a realm routing table which contains a list of supported realms and known peers.
§ Forward Diameter messages based on routing-related information and realm-routing table entries
§ Must maintain transaction state
§ Should not maintain session state
D). Diameter Nodes: PROXY AGENT
§ PROXY AGENT: A Relay that may modify the contents of messages - Routing; implements policy decisions
§ Forwards diameter messages
§ Makes policy decisions
§ Must maintain transaction state
§ Must maintain session state
§ Proxy agents also route messages, but they can modify those messages to implement policy enforcements.
§ Due to the fact that the proxy agent can modify messages, no end-to-end security is possible.
§ There is no difference in flow compared to the relay agent,
E). Diameter Nodes: REDIRECT AGENT
§ REDIRECT AGENT: Sends routing info in response to request messages - Routing; centralized source for Realm-to-Server address mapping
§ refers clients to servers and allows them to communicate directly
§ Not maintain any state (for both session and transaction)
§ A redirect agent can tell to an agent where to find another Diameter server, for example a home-server for a particular user.
§ Redirect agents can be used when the Diameter routing configuration needs to be centralized.
§ Because redirect agents do not handle messages, they also do not modify the messages.
§ They only return an answer to the Diameter agent needed to set up a direct communication path.
§ When a request enters the relay agent, the redirect agent is asked where the home server is located.
§ The relay agent can setup a connection with the home server
F). Diameter Nodes: TRANSLATION AGENT
§ TRANSLATION AGENT: Translates between two protocols - Radius and Diameter
§ Provides translation between two protocols (RADIUS <->Diameter)
§ Must maintain transaction state
§ Must maintain session state
§ The translation agent provides the protocol translation between two protocols, like RADIUS and Diameter or the even older protocol TACACS+ [RFC 1492] and Diameter.
§ The translation agent can only perform this translation for the Diameter applications it is familiar with.
§ The translation agent always resides in the Diameter domain, while it is a Diameter agent.
§ The RADIUS client or server is not aware of the existence of another protocol and sees the Diameter translation agent just as another RADIUS agent.
2-4). Function between Diameter Peers
A). Peer-to-Peer:
§ Diameter is a peer-to-peer protocol. In this section the connection establishment and communication with peers is described.
§ Diameter runs over Transmission Control Protocol (TCP) [RFC 793] or Stream Control Transmission Protocol (SCTP) [RFC 2960].
§ The different Diameter nodes are interconnected in a peer-to-peer structure.
§ The Diameter framework enables push and pull application models and architectures
§ First DIAMETER message exchange between two peers (after establishing the transport connection).
§ A Diameter node should at least have two peers per realm, the primary and secondary peer, for robustness.
§ The peers to whom the Diameter node is connected to are stored in the Peer Table.
§ Diameter peers, the set of Diameter nodes with which a given Diameter node will directly communicate, may be statically configured or may be dynamically discovered using SLPv2 or DNS SRV RRs.
B). Peer Discovery Mechanism:
§ Peer discovery can occur when the client needs to discover a first-hop Diameter agent or when the client needs to discover another agent for further handling of a Diameter operation.
§ Before Diameter, system administrators had to manually configure the Network Access Server with the location of its AAA server, so that when a user came in, the device could send a request to the correct address.
§ Besides manual configuration, which must be supported by all Diameter nodes, two options -- SRVLOC and DNS -- may be supported for dynamic peer discovery.
§ Peer discovery mechanisms are based on existing IETF standards. The possible discovery mechanisms are: manually configured list of agent locations, Service Location Protocol (SRVLOC) [RFC 2608] and Domain Name Server (DNS) [RFC 1034; RFC 1035].
§ The concept here is that it is required for Diameter server, or Diameter agent, to broadcast which applications they support, along with the provided security level.
§ Diameter clients can then depend on the desired Diameter application, security level, and realm info to look up suitable first-hop Diameter nodes to which they can forward Diameter messages.
For a Diameter node, the discovered peer location as well as routing configuration will be stored locally using two Diameter tables:
§ Peer Table: A Peer Table is mainly used to store the host address of known Diameter nodes. Other information, like whether a Diameter node was looked up dynamically, its status, and security-related information of that node, is also included in this table.
§ Peer Routing Table: There are four important columns of this table requiring extra attention for message routing. The first two are the Realm Name and Application Name, which act as the selection criteria for message routing. The third is the action to be taken for the target message, which could be PROXY, RELAY, REDIRECT, or LOCAL. LOCAL means the message should be processed locally instead of forwarding to other nodes.
§ The last one is a reference to an entry in the Peer Table, used to determine the actual host address of the destination.
§ Note that a Peer Routing Table will always contain a default entry for messages not meeting the routing criteria.
C). Session and Connection:
§ A session is actually the concept of a sequence of activities within a timeframe, and refers to the interactions between a Diameter client and a Diameter server in a given period.
§ Compared with a connection, a session is a logical connection between two Diameter nodes, and can cross multiple connections.
§ The Session-Id is then used to identify a particular session during further communication.
§ Each session in Diameter is associated with a client-generated Session-Id that is globally and eternally unique.
§ After an appropriate peer has been discovered, the next step is to establish a connection with that peer.
§ Compared with UDP, used in RADIUS, these two protocols provide more reliable transportation, which is critical for applications exchanging accounting-related information.
§ A connection is a physical link between two Diameter nodes. It is mandatory for the Diameter protocol to run over either TCP or SCTP.
§ Diameter protocol explicitly defines that a Diameter node must establish a connection with two peers per realm at a minimum, which act as primary and secondary contacts. The additional connections could be established when necessary.
§ During the session, a Diameter server might initiate a re-authentication or re-authorization request.
D). Establish a Connection with a Peer:
§ When two nodes want to establish a connection, they must use the capability exchange messages to find out the peer’s identity and its capabilities.
§ The capability exchange possibility can only be used by next-hop peers.
Session initiation
§ Like most client-server communication models, a Diameter session starts by issuing a request message from the client to the server.
§ In Diameter context, a Diameter client will send an auth-request message containing a unique Session-Id to a Diameter server (or a Diameter proxy if message forwarding is required).
§ After accepting the auth-request message, the Diameter server may include an Authorization-Lifetime AVP in the response messaging.
§ This AVP is used to indicate the amount of time in seconds that the Diameter client needs to be re-authorized.
§ After the timeout and acceptable Auth-Grace-Period have passed, the Diameter server will remove the session from its session list and release all resources allocated for the session.
E). Capabilities Exchange messages:
§ The first Diameter messages exchanged between two Diameter peers, after establishing the transport connection, are Capabilities Exchange messages.
§ A Capabilities Exchange message carries a peer's identity and its capabilities (protocol version number, supported Diameter applications, etc.).
§ A Diameter node only transmits commands to peers that have advertised support for the Diameter application associated with the given command.
§ Carries a peer’s identity and capabilities (protocol version number, supported diameter applications, …)
§ After a Capability-Exchange-Request (CER) always a Capability-Exchange-Answer (CEA) follows, even if the peers have no applications in common.
F). Disconnection with a Peer:
§ When disconnecting with a peer, the Disconnect-Peer-Request (DPR) should be used to inform the peer of its intent to disconnect the transport layer
§ If a peer disconnects without a Disconnect-Peer message, the node will periodically attempt to reconnect.
§ Session termination messages are only used in the context of authentication and authorization, and only when the session state was maintained.
§ For accounting services, an accounting stop message is used instead.
§ A session termination message can be initiated by either the Diameter client or the Diameter server.
§ When a session is deemed to be closed, the Diameter client sends a Session-Termination-Request (STR) message to the Diameter server.
§ Alternately, if the Diameter server detects that the session should be closed -- perhaps because the user runs out of credit or just for administrative purposes -- the Diameter server sends an Abort-Session-Request (ASR) message to the Diameter client.
G). Authentication and Authorization
§ Because authentication and authorization mechanisms vary among applications, the Diameter base protocol doesn't define command codes and AVPs specific to authentication and authorization.
§ It is the responsibility of Diameter applications to define their own messages and corresponding attributes based on the application's characteristics.
§ The AA-Request (
§ Accounting in Diameter essentially follows a server directed model, which means the device that generates accounting records follows the direction of an authorization server.
§ The accounting record should be sent from client to server, or if the accounting record should be generated continuously within an accounting session.
§ Depending on the service to be provided, there are two kinds of accounting records:
§ For one-time invocation-based services, the EVENT_RECORD is used.
§ If the service will be provided in a measurable period, the accounting record types START_RECORD, INTERIM_RECORD, and STOP_RECORD could be used to mark the start, update, and end of a session.
§ To prevent duplicated accounting records, each accounting message is associated with a Session-Id AVP along with an Accounting-Record-Number AVP.
§ As this combination can uniquely identify an accounting record, a Diameter node acting as a Diameter agent can use this information to detect duplicated accounting messages being sent to the Diameter server, thereby avoiding unnecessary processing for the Diameter server. This situation might come from temporary network problems or client shutdowns.
§ The Diameter client keep a local cache of outgoing accounting messages until an acknowledgement message arrives.
I). Error Handling:
§ Two types of errors can occur: protocol errors and application errors.
§ The protocol errors are errors at the base level of the protocol including routing problems etc.
§ Protocol errors refer to something being wrong with the underlying protocol used to carry Diameter messages, perhaps incorrect routing information or temporary network failure.
§ The application errors are problems with a function specified in a Diameter application.
§ Applications errors result from the failure of the Diameter protocol itself, and there are plenty of sources that will cause application errors. For example, when a mandatory AVP is missing in a particular Diameter command, a DIAMETER_MISSING_AVP error code is returned.
§ For error handling purposes different Result-Code AVP values are specified to indicate if the request was completed successfully or an error occurred.
§ Each The behavior and message to be exchanged for accounting is clearly defined.
§ Diameter answer message must have a Result-Code AVP. Every response message in Diameter will carry a Result-Code AVP, and the receiver of a response message can check this AVP to see if the previous message was successfully processed.
§ The Diameter protocol shares the same semantics of error code definition as the HTTP protocol.
§ The return status of messages can be easily identified by checking the first digit of the return code:
1. 1xxx: means the request can't be satisfied and additional information is required for the service to be granted.
2. 2xxx: means the request was processed successfully.
3. 3xxx: means there was a protocol error when transmitting a Diameter message. Generally, a Diameter proxy should try to fix this problem by either routing the message to another Diameter server, or by keeping the message in a local cache and sending it again later.
4. 4xxx: means the requested message cannot be satisfied at the moment, but it might work in the future. An example is a server that temporarily lacks physical storage space to handle any incoming requests.
5. 5xxx: means there was an application error when the server was processing the request message. The sender should not try to send the same message again. Instead, the sender will have to determine the cause of the application error by checking the error code, and then fix the problem.
§ Besides the Return-Code AVP, the message sender can also check other AVPs that carry additional information for error handling.
§ The Error-Message AVP carries human readable error messages and can be used to determine the actual cause.
§ The Error-Reporting-Host AVP contains the identity of the host generating the Result-Code. This AVP is very helpful for troubleshooting to spot the location of a problem.
§ The Failed-AVP contains the group of AVPs that caused the exception.
J). Transport failure detection:
Device-Watchdog-Request and Device-Watchdog-Answer
§ Application-level heartbeat messages called the Device-Watchdog-Request (DWR) and Device-Watchdog-Answer (DWA) messages are used to proactively detect transport failures.
§ These messages are sent periodically when a peer connection is idle and when a timely response has not been received for an outstanding request.
§ To support early connection failure detection, the Diameter protocol defined a Device-Watchdog-Request message.
§ When two connected Diameter nodes don't exchange messages for a certain length of time, this message is sent from either of these nodes to detect possible network problems.
§ If a transport failure is detected with a peer, the messages pending are forwarded to another agent, and the T flag is set. This is the failover mechanism of Diameter.
§ Sent periodically when a peer connection is idle and when a timely response has not been received for an outstanding request
§ Device-Watchdog-Request / Answer (DWR/DWA)
K). Fail-over/fail-back procedures
§ After an error has been detected, the sending node forwards all pending messages to an alternative Diameter node. This process is called FailOver.
§ In order for a Diameter node to perform failover procedures, it is necessary for the node to maintain a pending message queue for a given peer.
§ A pending message is a message that has been sent, but hasn't received its corresponding answer yet.
§ It is required for each Diameter node to keep a local copy of its outgoing messages.
§ When an answer message is received, the corresponding request is removed from the queue.
§ Diameter Agents must maintain transaction state for failover purposes.
§ If a transport failure is detected with a peer, a Diameter node attempts to failover to an alternate peer, which means that all pending request messages sent to the failed peer will be forwarded to the alternate peer.
§ A node periodically tries to re-establish the transport connection: Fail-back to this peer if connection is re-established
§ A Diameter node periodically attempts to re-establish the transport connection with a failed peer. If a connection is re-established, a node can failback to this peer (i.e., messages can once again be forwarded to this peer).
§ A failover to an alternate proxy agent may result in the reception of duplicate request messages by the home server.
L). Security in Diameter Connection
§ Using security in Diameter is mandatory.
§ Either IP security (IPSec) [RFC 4301] or TLS (Transport Layer Security) [RFC 4346] should be used.
§ TLS is recommended to be used as inter-domain security, in connections between administrative domains.
§ IPSec is to be used for intra-domain usage when pre-shared secrets are used as a security mechanism [RFC 3588].
§ End-to-end security by using TLS or IPSec is strongly recommended for all Diameter applications by the base protocol.
§ When the distribution of authentication keys takes place and there are untrusted Diameter agents in the path, IPSec or TLS must be used to eliminate the agents in the path.
沒有留言:
張貼留言