IANA Considerations AVP Header AVP Codes AVP Flags Diameter Header Command Codes
|Published (Last):||27 January 2014|
|PDF File Size:||15.40 Mb|
|ePub File Size:||8.84 Mb|
|Price:||Free* [*Free Regsitration Required]|
Accounting Command-Codes Accounting AVPs AVP Occurrence Table Accounting AVP Table IANA Considerations AVP Header AVP Code AVP Flags Diameter Header Command Codes Command Flags Application Identifiers AVP Values Diameter Protocol Related Configurable Parameters Security Considerations IPsec Usage TLS Usage Peer-to-Peer Considerations Normative References Informative References Diameter Service Template Duplicate Detection Intellectual Property Statement Over time, with the growth of the Internet and the introduction of new access technologies, including wireless, DSL, Mobile IP and Ethernet, routers and network access servers NAS have increased in complexity and density, putting new demands on AAA protocols.
These include: Failover [ RADIUS ] does not define failover mechanisms, and as a result, failover behavior differs between implementations. In order to provide well defined failover behavior, Diameter supports application-layer acknowledgements, and defines failover algorithms and the associated state machine.
This is described in Section 5. Transmission-level security [ RADIUS ] defines an application-layer authentication and integrity scheme that is required only for use with Response packets. In accounting, [ RADACCT ] assumes that replay protection is provided by the backend billing server, rather than within the protocol itself. Since within [ IKE ] authentication occurs only within Phase 1 prior to the establishment of IPsec SAs in Phase 2, it is typically not possible to define separate trust or authorization schemes for each application.
This limits the usefulness of IPsec in inter-domain AAA applications such as roaming where it may be desirable to define a distinct certificate hierarchy for use in a AAA deployment. In order to provide universal support for transmission-level security, and enable both intra- and inter-domain AAA deployments, IPsec support is mandatory in Diameter, and TLS support is optional.
Security is discussed in Section Calhoun, et al. Since the expected behavior is not defined, it varies between implementations. Diameter defines agent behavior explicitly; this is described in Section 2. Support for server-initiated messages is mandatory in Diameter, and is described in Section 8. Auditability RADIUS does not define data-object security mechanisms, and as a result, untrusted proxies may modify attributes or even packet headers without being detected.
Combined with lack of support for capabilities negotiation, this makes it very difficult to determine what occurred in the event of a dispute.
While implementation of data object security is not mandatory within Diameter, these capabilities are supported, and are described in [ AAACMS ]. Initially, it is expected that Diameter will be deployed within new network devices, as well as within gateways enabling communication between legacy RADIUS devices and Diameter agents.
Diameter includes support for error handling Section 7 , capability negotiation Section 5. Peer discovery and configuration RADIUS implementations typically require that the name or address of servers or clients be manually configured, along with the corresponding shared secrets.
This results in a large administrative burden, and creates the temptation to reuse the RADIUS shared secret, which can result in major security vulnerabilities if the Request Authenticator is not globally and temporally unique as required in [ RADIUS ]. Through DNS, Diameter enables dynamic discovery of peers.
Derivation of dynamic session keys is enabled via transmission-level security. However, since RADIUS does not provide explicit support for proxies, and lacks auditability and transmission-level security features, RADIUS- based roaming is vulnerable to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves. By providing explicit support for inter-domain roaming and message routing Sections 2.
Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. AVPs are used by the base Diameter protocol to support the following required features: - Transporting of user authentication information, for the purposes of enabling the Diameter server to authenticate the user.
It is also possible for the base protocol to be extended for use in new applications, via the addition of new commands or AVPs. At this time the focus of Diameter is network access and accounting applications. A truly generic AAA protocol used by many applications might provide functionality not provided by Diameter. Therefore, it is imperative that the designers of new applications understand their requirements before using Diameter.
Any node can initiate a request. In that sense, Diameter is a peer- to-peer protocol. A Diameter client generates Diameter messages to request authentication, authorization, and accounting services for the user.
A Diameter node MAY act as an agent for certain requests while acting as a server for others. The Diameter protocol also supports server-initiated messages, such as a request to abort service to a particular user.
This document also defines the Diameter failover algorithm and state machine. In summary, this document defines the base protocol specification for AAA, which includes support for accounting. Reuse simplifies standardization and implementation and avoids potential interoperability issues. For AVPs of type Enumerated, an application may require a new value to communicate some service-specific information.
In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, it is recommended that a Grouped AVP be used see Section 4. Standards Track [Page 11] RFC Diameter Based Protocol September Should a new Diameter usage scenario find itself unable to fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application.
Major changes to an application include: - Adding new AVPs to the command, which have the "M" bit set. Since a new EAP authentication method can be supported within Diameter without requiring new AVPs, addition of EAP methods does not require the creation of a new authentication application. Creation of a new application should be viewed as a last resort. An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application.
Please refer to Section However, just because a new authentication application id is required, does not imply that a new accounting application id is required. Application Identifiers are still required for Diameter capability exchange. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application.
The creation of a new accounting application should be viewed as a last resort and MUST NOT be used unless a new command or additional mechanisms e. Within an accounting command, setting the "M" bit implies that a backend server e. The combination of the home domain and the accounting application Id can be used in order to route the request to the appropriate accounting server.
If the base accounting is used without any mandatory AVPs, new commands or additional mechanisms e. This MAY require that new AVP values be assigned to represent the new authentication transform, or any other scheme that produces similar results.
Accounting The act of collecting information on resource usage for the purpose of capacity planning, auditing, billing or cost allocation. Accounting Record An accounting record represents a summary of the resource consumption of a user over the entire session.
Accounting servers creating the accounting record may do so by processing interim accounting events or accounting events from several devices serving the same user.
Authentication The act of verifying the identity of an entity subject. Authorization The act of determining whether a requesting entity subject will be allowed access to a resource object.
An AVP includes a header and is used to encapsulate protocol-specific data e. Broker A broker is a business term commonly used in AAA infrastructures. A broker is either a relay, proxy or redirect agent, and MAY be operated by roaming consortiums. Depending on the business model, a broker may either choose to deploy relay agents or proxy agents. Diameter Client A Diameter Client is a device at the edge of the network that performs access control.
Diameter Server A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. Downstream Downstream is used to identify the direction of a particular Diameter message from the home server towards the access device.
When relays or proxy are involved, this hop-by-hop security does not protect the entire Diameter user session. End-to-end security is security between two Diameter nodes, possibly communicating through Diameter Agents. This security protects the entire Diameter communications path from the originating Diameter node to the terminating Diameter node.
Home Realm A Home Realm is the administrative domain with which the user maintains an account relationship. Home Server See Diameter Server. Local Realm A local realm is the administrative domain providing services to a user. An administrative domain MAY act as a local realm for certain users, while being a home realm for others.
Multi-session A multi-session represents a logical linking of several sessions. Multi-sessions are tracked by using the Acct-Multi-Session-Id.
Fajardo, Ed. Loughney Nokia Research Center G. Zorn, Ed. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications.
RFC 3588 - Diameter Base Protocol
Accounting Command-Codes Accounting AVPs AVP Occurrence Table Accounting AVP Table IANA Considerations
Calhoun Request for Comments: Airespace, Inc. Category: Standards Track J. Loughney Nokia E. Guttman Sun Microsystems, Inc. Zorn Cisco Systems, Inc. Arkko Ericsson September Diameter Base Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.