AAA Working Group Pat R. Calhoun Internet-Draft Sun Microsystems, Inc. Category: Standards Track Haseeb Akhtar Nortel Networks Jari Arkko Oy LM Ericsson Ab Erik Guttman Sun Microsystems, Inc. Allan C. Rubens Tut Systems, Inc. Glen Zorn Cisco Systems, Inc. July 2001 Diameter Base Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright (C) The Internet Society 2001. All Rights Reserved. Calhoun et al. expires January 2002 [Page 1] Internet-Draft July 2001 Abstract The Diameter base protocol is intended to provide a AAA framework for Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message format, transport, error reporting and security services to be used by all Diameter applications and MUST be supported by all Diameter implementations. Table of Contents 1.0 Introduction 1.1 Diameter Protocol 1.2 Requirements language 1.3 Terminology 2.0 Protocol Overview 2.1 Transport 2.1.1 SCTP Guidelines 2.2 Securing Diameter Messages 2.3 Diameter Protocol Extensibility 2.3.1 Defining new AVP Values 2.3.2 Creating new AVPs 2.3.3 Creating a new Diameter Applications 2.3.4 Application authentication procedures 2.4 Diameter Application Compliance 2.5 Application Identifiers 2.6 Peer Table 2.7 Realm-Based Routing Table 2.8 Role of Diameter Agents 2.8.1 Relay Agents 2.8.2 Proxy Agents 2.8.3 Redirector Agents 2.8.4 Translation Agents 3.0 Diameter Header 3.1 Command Code Definitions 3.2 Command Code ABNF specification 3.3 Diameter Command Naming Conventions 4.0 Diameter AVPs 4.1 AVP Header 4.2 Optional Header Elements 4.3 AVP Data Formats 4.4 Derived AVP Data Formats 4.5 Grouped AVP Values 4.5.1 Example AVP with a Grouped Data type 4.6 Diameter Base Protocol AVPs 5.0 Diameter Peers 5.1 Connecting to Peers 5.2 Diameter Peer Discovery Calhoun et al. expires January 2002 [Page 2] Internet-Draft July 2001 5.3 Capabilities Negotiation 5.3.1 Capabilities-Exchange-Request 5.3.2 Capabilities-Exchange-Answer 5.3.3 Vendor-Id AVP 5.3.4 Firmware-Revision AVP 5.3.5 Host-IP-Address AVP 5.3.6 Supported-Vendor-Id AVP 5.3.7 Product-Name AVP 5.3.8 Alternate-Peer AVP 5.4 Disconnecting Peer connections 5.4.1 Disconnect-Peer-Request 5.4.2 Disconnect-Peer-Answer 5.4.3 Disconnect-Cause AVP 5.5 Transport Failure Detection 5.5.1 Device-Watchdog-Request 5.5.2 Device-Watchdog-Answer 5.5.3 Transport Failure Algorithm 5.5.4 Failover/Failback Procedures 5.6 Peer State Machine 5.6.1 Incoming connections 5.6.2 Events 5.6.3 Actions 5.6.4 The Election Process 6.0 Diameter message processing 6.1 Diameter request routing overview 6.1.1 Originating a Request 6.1.2 Sending a Request 6.1.3 Receiving Requests 6.1.4 Processing Local Requests 6.1.5 Request Forwarding 6.1.6 Request Routing 6.1.7 Redirecting requests 6.1.8 Relaying and Proxying Requests 6.1.9 Relaying and Proxying Server-Initiated Requests 6.2 Diameter Answer Processing 6.2.1 Processing received Answers 6.2.2 Relaying and Proxying Answers 6.3 Hiding Network Topology 6.4 Origin-Host AVP 6.5 Origin-Realm AVP 6.6 Destination-Host AVP 6.7 Destination-Realm AVP 6.8 Routing AVPs 6.8.1 Route-Record AVP 6.8.2 Proxy-Info AVP 6.8.3 Proxy-Host AVP 6.8.4 Proxy-State AVP 6.8.5 Source-Route AVP Calhoun et al. expires January 2002 [Page 3] Internet-Draft July 2001 6.9 Auth-Application-Id AVP 6.10 Acct-Application-Id AVP 6.11 Vendor-Specific-Application-Id AVP 6.12 Redirect-Host AVP 6.13 Redirect-Host-Usage AVP 6.14 Redirect-Max-Cache-Time AVP 7.0 Error Handling 7.1 Result-Code AVP 7.1.1 Informational 7.1.2 Success 7.1.3 Protocol Errors 7.1.4 Transient Failures 7.1.5 Permanent Failures 7.2 Error Bit 7.3 Error-Message AVP 7.4 Error-Reporting-Host AVP 7.5 Failed-AVP AVP 8.0 Diameter User Sessions 8.1 Authorization Session State Machine 8.2 Accounting Session State Machine 8.3 Server-Initiated Re-Auth 8.3.1 Re-Auth-Request 8.3.2 Re-Auth-Answer 8.4 Session Termination 8.4.1 Session-Termination-Request 8.4.2 Session-Termination-Answer 8.5 Aborting a Session 8.5.1 Abort-Session-Request 8.5.2 Abort-Session-Answer 8.6 Inferring Session Termination from Origin-State-Id 8.7 Auth-Request-Type AVP 8.8 Session-Id AVP 8.9 Authorization-Lifetime AVP 8.10 Auth-Grace-Period AVP 8.11 Auth-Session-State AVP 8.12 Re-Auth-Request-Type AVP 8.13 Session-Timeout AVP 8.14 User-Name AVP 8.15 Termination-Cause AVP 8.16 Origin-State-Id AVP 8.17 Session-Binding AVP 8.18 Session-Server-Failover AVP 8.19 Multi-Round-Time-Out AVP 8.20 Class AVP 9.0 Accounting 9.1 Server Directed Model 9.2 Protocol Messages 9.3 Application document requirements Calhoun et al. expires January 2002 [Page 4] Internet-Draft July 2001 9.4 Fault Resilience 9.5 Accounting Records 9.6 Correlation of Accounting Records 9.7 Accounting Command-Codes 9.7.1 Accounting-Request 9.7.2 Accounting-Answer 9.8 Accounting AVPs 9.8.1 Accounting-Record-Type AVP 9.8.2 Accounting-Interim-Interval AVP 9.8.3 Accounting-Record-Number AVP 9.8.4 Accounting-Session-Id AVP 9.8.5 Accounting-Multi-Session-Id AVP 10.0 AVP Occurrence Table 10.1 Base Protocol Command AVP Table 10.2 Accounting AVP Table 11.0 IANA Considerations 11.1 AVP Header 11.1.1 AVP Code 11.1.2 AVP Flags 11.2 Diameter Header 11.2.1 Command Codes 11.2.2 Message Flags 11.3 Application Identifier Values 11.4 Result-Code AVP Values 11.5 Accounting-Record-Type AVP Values 11.6 Termination-Cause AVP Values 11.7 Redirect-Host-Usage AVP Values 11.8 Session-Server-Failover AVP Values 11.9 Session-Binding AVP Values 11.10 Diameter TCP/SCTP Port Numbers 11.11 Disconnect-Cause AVP Values 11.12 Auth-Request-Type AVP Values 11.13 Auth-Session-State AVP Values 11.14 Re-Auth-Request-Type AVP Values 12.0 Diameter protocol related configurable parameters 13.0 Security Considerations 14.0 References 15.0 Acknowledgements 16.0 Authors' Addresses 17.0 Full Copyright Statement 18.0 Expiration Date Appendix A. Diameter Service Template Calhoun et al. expires January 2002 [Page 5] Internet-Draft July 2001 1.0 Introduction Historically, the RADIUS protocol has been used to provide AAA services for dial-up PPP [42] and terminal server access. Over time, routers and network access servers (NAS) have increased in complexity and density, making the RADIUS protocol increasingly unsuitable for use in such networks. The Roaming Operations Working Group (ROAMOPS) has published a set of specifications [20, 43, 44] that define how a PPP user can gain access to the Internet without having to dial into his/her home service provider's modem pool. This is achieved by allowing service providers to cross-authenticate their users. Effectively, a user can dial into any service provider's point of presence (POP) that has a roaming agreement with his/her home Internet service provider (ISP), the benefit being that the user does not have to incur a long distance charge while traveling, which can sometimes be quite expensive. Given the number of ISPs today, ROAMOPS realized that requiring each ISP to set up roaming agreements with all other ISPs did not scale. Therefore, the working group defined a "broker", which acts as an intermediate server, whose sole purpose is to set up these roaming agreements. A collection of ISPs and a broker is called a "roaming consortium". There are many such brokers in existence today; many also provide settlement services for member ISPs. The Mobile-IP Working Group has recently changed its focus to inter administrative domain mobility, which is a requirement for cellular carriers wishing to deploy IETF-based mobility protocols. The current cellular carriers requirements [22, 23] are very similar to the ROAMOPS model, with the exception that the access protocol is Mobile-IP [45] instead of PPP. The Diameter protocol was not designed from the ground up. Instead, the basic RADIUS model was retained while fixing the flaws in the RADIUS protocol itself. Diameter does not share a common protocol data unit (PDU) with RADIUS, but does borrow sufficiently from the protocol to ease migration. The basic concept behind Diameter is to provide a base protocol that can be extended in order to provide AAA services to new access technologies. Currently, the protocol only concerns itself with Internet access, both in the traditional PPP sense as well as taking into account the ROAMOPS model, and Mobile-IP. Although Diameter could be used to solve a wider set of AAA problems, we are currently limiting the scope of the protocol in order to Calhoun et al. expires January 2002 [Page 6] Internet-Draft July 2001 ensure that the effort remains focused on satisfying the requirements of network access. Note that 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. 1.1 Diameter Protocol The Diameter protocol allows peers to exchange a variety of messages. The base protocol provides the following facilities: - Delivery of AVPs (attribute value pairs) - Capabilities negotiation, as required in [20] - Error notification - Extensibility, through addition of new commands and AVPs, as required in [21] All data delivered by the protocol is in the form of an AVP. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications which employ Diameter. AVPs may be added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs which are explicitly excluded are not included. AVPs are used by 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. - Transporting of service specific authorization information, between client and servers, allowing the peers to decide whether a user's access request should be granted. - Exchanging resource usage information, which MAY be used for accounting purposes, capacity planning, etc. - Relaying, proxying and re-directing of Diameter messages through a server hierarchy. The Diameter base protocol provides the minimum requirements needed for an AAA transport protocol, as required by NASREQ [21], Mobile IP [22, 23], and ROAMOPS [20]. The base protocol is not intended to be used by itself, and must be used with a Diameter application, such as Mobile IP [10]. The Diameter protocol was heavily inspired and builds upon the tradition of the RADIUS [1] protocol. See section 2.4. for more information on Diameter applications. Any node can initiate a request. In that sense, Diameter is a peer to peer protocol. In this document, a Diameter client is the device that normally initiates a request for authentication and/or authorization Calhoun et al. expires January 2002 [Page 7] Internet-Draft July 2001 of a user. A Diameter server is the device that either forwards the request to another Diameter server (known as a proxy), or one that performs the actual authentication and/or authorization of the user based on some profile. Given that the server MAY send unsolicited messages to clients, it is possible for the server to initiate such messages. An example of an unsolicited message would be for a request that the client issue an accounting update. 1.2 Requirements language In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [13]. 1.3 Terminology Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation. Accounting record A session record represents a summary of the resource consumption of a user over the entire session. Accounting gateways creating the session record may do so by processing interim accounting events or accounting events from several 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). AVP The Diameter protocol consists of a header followed by one or more Attribute-Value-Pair (AVP). The AVP includes a header and is used to encapsulation authentication, authorization or accounting information. Broker A broker is a business term commonly used in AAA infrastructures. A broker is either a relay, proxy or redirect server, and MAY be operated by roaming consortiums. Diameter Agent Calhoun et al. expires January 2002 [Page 8] Internet-Draft July 2001 A Diameter Agent is a host that is providing either server, relay, proxy or redirector services. Diameter Client A Diameter Client is a device at the edge of the network that performs access control. An example of a Diameter client is a Network Access Server (NAS) or a Foreign Agent (FA). Diameter Node A Diameter node is a host that implements the Diameter protocol, and acts either as a Client, or as a Proxy, Redirector, Server or Translation agent. Diameter Server A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. By its very nature, a Diameter Server MUST support Diameter applications in addition to the base protocol. Downstream Server Diameter Proxy servers identify a downstream server as one that is providing routing services towards the Diameter client. Home Domain A Home Domain is the administrative domain with whom the user maintains an account relationship. Home Server See Diameter Server. Interim accounting An interim accounting message provides a snapshot of usage during a user's session. It is typically implemented in order to provide for partial accounting of a user's session in the event of a device reboot or other network problem that prevents the reception of a session summary message or session record. Local Domain A local domain is the administrative domain providing services to a user. An administrative domain MAY act as a local domain for certain users, while being a home domain for others. Network Access Identifier The Network Access Identifier, or NAI [3], is used in the Diameter protocol to extract a user's identity and realm. The identity is used to identify the user during authentication and/or authorization, while the realm is used for message routing purposes. Calhoun et al. expires January 2002 [Page 9] Internet-Draft July 2001 Proxy In addition to forwarding requests and responses, proxies enforce policies relating to resource usage and provisioning. This is typically accomplished by tracking the state of NAS devices. While proxies typically do not respond to client Requests prior to receiving a Response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and may not support all Diameter applications. Realm The string in the NAI that immediately follows the '@' character. NAI realm names are required to be unique, and are piggybacked on the administration of the DNS namespace. Diameter makes use of the realm, also loosely referred to as domain, to determine whether messages can be satisfied locally, or whether they must be proxied. Real-time Accounting Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk. Relay Relays forward requests and responses based on routing-related AVPs and domain forwarding table entries. Since relays do not enforce policies, they do not examine or alter non-routing AVPs. As a result, relays never originate messages, do not need to understand the semantics of messages or non-routing AVPs, and are capable of handling any Diameter applications or message type. Since relays make decisions based on information in routing AVPs and domain forwarding tables they do not keep state on NAS resource usage or conversations in progress. Redirector Rather than forwarding requests and responses between clients and servers, Re-directs refer clients to servers and allow them to communicate directly. Since Re-directs do not sit in the forwarding path, they do not alter any AVPs transitting between client and server. Re-direct proxies do not originate messages and are capable of handling any message type, although they may be configured only to re-direct messages of certain types, while acting as Routing or Policy proxies for other types. As with Routing proxies, re-directs do not keep state with respect to conversations or NAS resources. Roaming Relationships Calhoun et al. expires January 2002 [Page 10] Internet-Draft July 2001 Roaming relationships include relationships between companies and ISPs, relationships among peer ISPs within a roaming association, and relationships between an ISP and a roaming consortia. Together, the set of relationships forming a path between a local ISP's authentication proxy and the home authentication server is known as the roaming relationship path. Session The Diameter protocol is session based. When an authorization request is initially transmitted, it includes a session identifier that is used for the duration of the session. The Session- Identifier AVP contains the identifier and must be globally unique. Upstream Server Diameter Proxy servers identify an upstream server as one that is providing routing services towards the home server for a particular message. 2.0 Protocol Overview The base Diameter protocol is never used on its own. It is always extended for a particular application. Three Diameter applications are defined by companion documents: NASREQ [7], Mobile IP [10], CMS Security [11]. These options are introduced in this document but specified elsewhere. Additional Diameter applications MAY be defined in the future (see Section 11.3). Diameter Clients MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application which is needed to implement the client's service, e.g. NASREQ and/or Mobile IP. A Diameter Client which does not support both NASREQ and Mobile IP, MUST be referred to as "Diameter X Client" where X is the application which it supports, and not a "Diameter Client." Diameter Servers must support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application which is needed to implement the intended service, e.g. NASREQ and/or Mobile IP. A Diameter Server which does not support both NASREQ and Mobile IP, MUST be referred to as "Diameter X Server" where X is the application which it supports, and not a "Diameter Server." Diameter Relays and Redirectors are, by definition, protocol transparent, and MUST transparently support the Diameter base protocol, which includes accounting, and all Diameter applications. Calhoun et al. expires January 2002 [Page 11] Internet-Draft July 2001 Diameter Proxies MUST support the base protocol, which includes accounting. in addition, they MUST fully support each Diameter application which is needed to implement proxied services, e.g. NASREQ and/or Mobile IP. A Diameter Proxy which does not support also both NASREQ and Mobile IP, MUST be referred to as "Diameter X Proxy" where X is the application which it supports, and not a "Diameter Proxy." The CMS Diameter security application [11] contains two features: 1. A set of messages that allows a Diameter node to establish a security association, which is used to secure AVPs within a Diameter message, even though the message may traverse intermediate Diameter agents. A set of AVPs are also defined to sign and encrypt AVPs, as well as to transport certificates. This feature MUST be supported by Diameter server and proxy agents, SHOULD be supported by Diameter clients, and MAY be supported by relay and redirector agents. 2. A set of messages, known as PDSR and PDSA, allows a Diameter client to request that an agent establish a Diameter security association with a server in a specific realm. This feature MUST be supported by Diameter clients and Proxy agents, and MAY be supported by Diameter servers, relay and redirector agents. The base Diameter protocol concerns itself with capabilities negotiation, and how messages are sent and how peers may eventually be abandoned. The base protocol also defines certain rules which apply to all exchanges of messages between Diameter peers. Communication between Diameter peers begins with one peer sending a message to another Diameter peer. The set of AVPs included in the message is determined by a particular Diameter application. One AVP that is included to reference a user's session is the Session-Id. The initial request for authentication and/or authorization of a user would include the Session-Id. The Session-Id is then used in all subsequent messages to identify the user's session (see section 8.0 for more information). The communicating party may accept the request, or reject it by returning an answer message with Result-Code AVP set to indicate an error occurred. The specific behavior of the diameter server or client receiving a request depends on the Diameter application employed. Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination- Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular Diameter application. Calhoun et al. expires January 2002 [Page 12] Internet-Draft July 2001 The Diameter base protocol provides the Authorization-Lifetime AVP, which MAY be used by applications to specify the duration of a specific authorized session. 2.1 Transport The base Diameter protocol is run on port TBD of both TCP [27] and SCTP [26] transport protocols (for interoperability test purposes port 1812 will be used until IANA assigns a port to the protocol). When used with TLS [38], The Diameter protocol is run on port TBD of both TCP and SCTP. Diameter clients MUST support either TCP or SCTP, while agents and servers MUST support both. Future versions of this specification MAY mandate that clients support SCTP. A Diameter node MAY initiate connections from any source port, but MUST be prepared to receive connections on port TBD. Note that the source and destination addresses used in request and replies MAY any of a peer's valid IP addresses. A given Diameter process SHOULD use the same port number to send all messages to aid in identifying which process sent a given message. More than one Diameter process MAY exist within a single host, so the sender's port number is needed to discriminate them. When no transport connection exists with a peer, an attempt to connect SHOULD be periodically attempted. This behavior is handled via the Tc timer, whose recommended value is 30 seconds. When connecting to a peer, and either zero or more transports are specified, SCTP SHOULD be tried first, followed by TCP. See section 5.2 for more information on peer discovery. Diameter implementations SHOULD be able to interpret ICMP protocol and port unreachable messages as explicit indications that the server is not reachable, in addition to interpreting ECONNREFUSED (a reset from the transport) and timed-out connection attempts. 2.1.1 SCTP Guidelines The following are guidelines for Diameter implementations that support SCTP: 1. For interoperability: All Diameter nodes MUST be prepared to receive Diameter messages on any SCTP stream in the Calhoun et al. expires January 2002 [Page 13] Internet-Draft July 2001 association. 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the- line blocking. 2.2 Securing Diameter Messages Diameter clients, such as Network Access Servers (NASes) and Foreign Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter servers MUST support TLS, but the administrator MAY opt to configure IPSec instead of using TLS. Operating the Diameter protocol without any security mechanism is not recommended. 2.3 Diameter Protocol Extensibility There are various ways the Diameter protocol can be extended. This section is intended to assist protocol designers in selecting the best method of using the Diameter protocol. 2.3.1 Defining new AVP Values Defining a new AVP value is the best approach when a new application needs to make use of an existing Diameter application, but requires that an existing AVP communicate different service-specific information (e.g. NAS-Port-Type set to avian carriers). When an existing AVP can be used to communicate the new information, this approach is preferred over creating new AVPs. In order to allocate a new AVP value, a request MUST be sent to IANA, with a detailed explanation of the value. Furthermore, if the command code on which the AVP value is to be used would require a different set of mandatory AVPs be present, the list of AVPs must accompany the request. 2.3.2 Creating new AVPs New AVPs may be created when a new application requiring Diameter support can make use of an existing Diameter application, but requires new AVPs to communicate service-specific information. Prior to defining the AVP, the AVP type MUST be one of the types listed in section 4.3. In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, Calhoun et al. expires January 2002 [Page 14] Internet-Draft July 2001 it is highly recommended that a Grouped AVP be used (see Section 4.5). In order to create a new AVP, a request MUST be sent to IANA, with a detailed explanation of the AVP, its type and possible values. Furthermore, the request MUST include the commands that would make use of the AVP. Note that new AVPS to be used with an existing application MUST NOT be defined to have the 'M'andatory bit set. 2.3.3 Creating new Diameter Applications Should a new application require Diameter support, but it cannot 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: - Requiring a whole different set of mandatory AVPs to a command - Requiring a command that has a different number of round trips to satisfy a request (e.g. application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete). - The method used to authenticate the user is drastically different from any existing application, and the authentication information cannot be carried within the AVPs defined in the application. Note that the creation of a new application should be viewed as a last resort. New Diameter applications MUST define at least one Command Code, the expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also define new AVPs. If the Diameter application has any accounting requirements, it MUST also specify the AVPs that are to be present in the Diameter Accounting messages (see section 9.3). When possible, a new Diameter application SHOULD attempt to re-use any existing Diameter AVP, in order to reduce the possibility of having multiple AVPs that carry similar information. Every Diameter application specification MUST have an IANA assigned Application Identifier (see section 2.4). 2.3.4 Application authentication procedures When possible, applications SHOULD be designed such that new Calhoun et al. expires January 2002 [Page 15] Internet-Draft July 2001 authentication methods MAY be added without requiring changes to the application. This MAY require that new AVP values be assigned to represent the new authentication transform, or any other scheme that produces similar results. When possible, authentication frameworks, such as Extensible Authentication Protocol [25], SHOULD be used. 2.4 Diameter Application Compliance Application Identifiers are advertised during the capabilities exchange phase (see section 2.5). For a given application, there are two different ways of advertising support. First, advertising support of the application via the Auth-Application-Id implies that the sender supports all authentication and authorization command codes, and the AVPs specified in the associated ABNFs, described in the specification. Second, advertising support of the application via the Acct-Application-Id implies that the sender supports the Accounting command codes defined in this specification, as well as the accounting AVPs defined in the application's specification. An implementation MAY add arbitrary AVPs to any command defined in an application, including vendor-specific AVPs. However, implementations that add such AVPs with the Mandatory 'M' bit set are not compliant, and are at fault if the peer rejects the request. If the sender of such a message wishes to provide service, it MUST resend the message with the offending AVPs removed. 2.5 Application Identifiers Each Diameter application MUST have an IANA assigned Application Identifier (see section 11.3). The base protocol does not require an application Identifier since its support is mandatory. During the capabilities exchange, Diameter nodes inform their peers of locally supported applications. Furthermore, all Diameter messages contain an application identifier, which is used in the message forwarding process. The following Application Identifier values are defined: NASREQ 1 [7] End-to-End Security 2 [11] Mobile-IP 4 [10] Relay 0xffffffff Relay and redirect agents MUST advertise the Relay application identifier, while all other Diameter nodes MUST advertise locally supported applications. The receiver of a Capabilities Exchange Calhoun et al. expires January 2002 [Page 16] Internet-Draft July 2001 message advertising Relay service MUST assume that the sender supports all current and future applications. Diameter relay and proxy agents are responsible for finding an upstream server that supports the application of a particular message. If none can be found, an error message is returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. 2.6 Peer Table The Diameter Peer Table is used in message forwarding, and referenced by the Domain Routing Table. A Peer Table entry contains the following fields: - Host identity. following the conventions described for the DiameterIdentity derived AVP data format in section 4.4. This MAY be resolved locally, or dynamically updated via the Origin- Host AVP of the CER or CEA messages. - Status. This is the state of the peer entry, and MUST match one of the values listed in section 5.6. - Role. This field specifies whether a peer is a primary, secondary or alternate. - Static or Dynamic. Specifies whether a peer entry was statically configured, or dynamically discovered. - Expiration time. Specifies the time which dynamically discovered peer table entries are to be either refreshed, or expired. - TLS Enabled. Specifies whether TLS is to be used when communicating with the peer. - Additional security information, when needed (e.g. keys, certificates) 2.7 Realm-Based Routing Table All Realm-Based routing lookups are performed against what is commonly known as the Domain Routing Table (see section 12.0). A Domain Routing Table Entry contains the following fields: - Realm Name. This is the field that is typically used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match- from-the-right on the realm rather than requiring an exact match. - Application Identifier. It is possible for a route entry to have a different destination based on the Acct-Application-Id (for accounting messages) or Auth-Application-Id (for non-accounting messages) of the message. This field is typically used as a secondary key field in routing table lookups. - Local Action. The Local Action field is used to identify how a Calhoun et al. expires January 2002 [Page 17] Internet-Draft July 2001 message should be treated. The following actions are supported: 1. LOCAL - Diameter messages that resolve to a route entry with the Local Action set to Local can be satisfied locally, and do not need to be routed to another server. 2. RELAY - All Diameter messages that fall within this category MUST be routed to a next hop server, without modifying any non-routing AVPs. See section 6.1.8 for relaying guidelines 3. PROXY - All Diameter messages that fall within this category MUST be routed to a next hop server. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See section 6.1.8 for relaying guidelines. 4. REDIRECT - Diameter messages that fall within this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the message. See section 6.1.7 for redirect guidelines. - Server Identifier. One or more servers the message is to be routed to. These servers MUST also be present in the Peer table. When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) the message must be routed to. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers the message should be redirected to. - Static or Dynamic. Specifies whether a route entry was statically configured, or dynamically discovered. - Expiration time. Specifies the time which dynamically discovered a route table entry expire. It is important to note that Diameter agents MUST support at least one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents do not need to support all modes of operation in order to conform with the protocol specification, but MUST follow the protocol compliance guidelines in section 2.0. Relay agents MUST NOT reorder AVPs, and proxies SHOULD NOT reorder AVPs. The routing table MAY include a default entry which MUST be used for any requests not matching any of the other entries. The routing table MAY consist of only such an entry. When a request is routed, the target server MUST have advertised the Application Identifier (see section 2.5) for the given message, or have advertised itself as a relay or proxy agent. 2.8 Role of Diameter Agents In addition to client and servers, the Diameter protocol introduces Calhoun et al. expires January 2002 [Page 18] Internet-Draft July 2001 relays, redirectors, proxies and translation gateways, each of which is defined in Section 1.3. These Diameter agents are useful for several reasons: - They can distribute administration of systems to a configurable grouping, including the maintenance of security associations. - They can be used for concentration of requests from an number of co-located or distributed NAS equipment sets to a set of like user groups. - They can do value-added processing to the requests or responses. - They can be used for load balancing. - A complex network will have multiple authentication sources, they can sort requests and forward towards the correct target. The Diameter protocol requires that agents maintain transaction state, which is used for failover purposes. Transaction state implies that upon forwarding a request, it's Hop-by-Hop identifier is saved, the field is replaced with a locally unique identifier, which is restored to its original value when the corresponding answer is received. The request's state is released upon receipt of the answer. A stateless agent is one that only maintains transaction state. The Proxy-Info AVP allows stateless agents to add local state to a Diameter request, with the guarantee that the same state will be present in the answer. However, the protocol's failover procedures require that agents maintain a copy of pending requests. A stateful agent is one that 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. Each authorized session has a expiration, which is communicated by Diameter servers via the Authorized-Lifetime AVP. Maintaining session state MAY be useful in certain applications, such as: - Protocol translation (e.g. RADIUS <-> Diameter) - Limiting resources authorized to a particular user - Per user or transaction auditing A Diameter agent MAY act in a stateful manner for some requests, while be stateless for others. A Diameter implementation MAY act as one type of agent for some requests, and as another type of agent for others. 2.8.1 Relay Agents Relay Agents are Diameter agents that accept requests and route Calhoun et al. expires January 2002 [Page 19] Internet-Draft July 2001 messages to other Diameter agents based on information found in the messages (e.g. Destination-Realm). This routing decision is performed using a list of supported domains, and known peers. This is known as the Diameter Routing Table, as is defined further in section 2.7. Relays MAY be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (POP). The use of Relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information they would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed or deleted. Relays modify Diameter messages by inserting, and removing, routing information, but do not modify any other portion of a message. Further, Relays inherent simplicity implies that they are stateless, and therefore SHOULD NOT maintain session state, but MUST maintain transaction state. +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 2. Request | | | NAS | | DRL | | HMS | | | 4. Answer | | 3. Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 1: Relaying of Diameter messages The example provided in Figure 1 depicts a request issued from NAS, which is an access device, for the user bob@abc.com. Prior to issuing the request, NAS performs a Diameter route lookup, using "abc.com" as the key, and determines that the message is to be relayed to DRL, which is a Diameter Relay. DRL performs the same route lookup as NAS, and relays the message to HMS, which is abc.com's Home Diameter Server. HMS identifies that the request can be locally supported (via the realm), processes the authentication and/or authorization request, and replies with an answer, which is routed back to NAS using Diameter routing AVPs. Since Relays do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier. 2.8.2 Proxy Agents Similarly to Relays, Proxy agents route Diameter messages using the Diameter Routing Table. However, they differ since they modify Calhoun et al. expires January 2002 [Page 20] Internet-Draft July 2001 messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g. access devices) to enforce resource usage, provide admission control, and provisioning. It is important to note that although proxies MAY provide a value-add function for NASes, they do not allow access devices to use the Diameter CMS Security application, since modifying messages breaks authentication. Proxies MAY be used in call control centers or access ISPs that provide outsourced connections, they can monitor the number and types of ports in use, and make allocation and admission decisions according to their configuration. Proxies that wish to limit resources MUST be stateful, and all Proxies MUST maintain transaction state. Proxy agents MUST NOT allow CMS security to be established between two peers if it expects to modify ANY non-routing AVP in messages exchanged between the peers. See [11] for more information. Since enforcing policies requires an understanding of the service being provided, Proxies MUST only advertise the Diameter applications they support. 2.8.3 Redirector Agents Redirector agents provide Realm to Server address resolution, and use the Diameter routing table to determine where a given request should be forwarded. When a request is received by a Diameter redirector, a special answer is created, which includes the identity of the Diameter server(s) the originator of the request should contact directly. Redirectors are useful in scenarios where the Diameter routing configuration needs to be centralized. An example is a redirector that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between domains. This scenario is advantageous since it does not require that the consortium provide routing updates to its members when changes are made to a member's infrastructure. Since redirectors do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages. Since redirectors do not receive answer messages, they cannot maintain session state. Further, since redirectors never relay requests, they are not Calhoun et al. expires January 2002 [Page 21] Internet-Draft July 2001 required to maintain transaction state. The example provided in Figure 2 depicts a request issued from the access device, NAS, for the user bob@abc.com. The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter Routing Table for abc.com. DRL has a default route configured to DRD, which is a redirector that returns a redirect notification to DRL, as well as HMS' contact information. Upon receipt of the redirect notification, DRL establishes a transport connection with HMS, if one doesn't already exist, and forwards the request to it. +------+ | | | DRD | | | +------+ ^ | 2. Request | | 3. Redirection | | Notification | v +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 4. Request | | | NAS | | DRL | | HMS | | | 6. Answer | | 5. Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 2: Redirecting a Diameter Message Since Redirectors do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier. 2.8.4 Translation Agents A Translation Agent is a device that provides translation between two protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded systems to be migrated at a slower pace. Given that the Diameter protocol introduces the concept of long-lived authorized sessions, translation agents MUST be stateful and MUST maintain transaction state. Translation of messages can only occur if the agent recognizes the application of a particular request, and therefore MUST only Calhoun et al. expires January 2002 [Page 22] Internet-Draft July 2001 advertise their locally supported applications. +------+ ---------> +------+ ---------> +------+ | | RADIUS Request | | Diameter Request | | | NAS | | TLA | | HMS | | | RADIUS Answer | | Diameter Answer | | +------+ <--------- +------+ <--------- +------+ mno.net mno.net abc.com Figure 3: Translation of RADIUS to Diameter 3.0 Diameter Header A summary of the Diameter header format is shown below. The fields are transmitted in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Version This Version field MUST be set to 1 to indicate Diameter Version 1. Message Length The Message Length field is three octets and indicates the length of the Diameter message including the header fields. Command Flags The Command Flags field is eight bits. The following bits are assigned: R(equest) - If set, the message is a request. If cleared, the message is an answer. P(roxiable) - If set, the message MAY be proxied. If cleared, the message MUST be locally processed. Calhoun et al. expires January 2002 [Page 23] Internet-Draft July 2001 E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. r(eserved) - this flag bit is reserved for future use, and MUST be set to zero. Command-Code The Command-Code field is three octets, and is used in order to communicate the command associated with the message. The 24-bit address space is managed by IANA (see section 11.2). Vendor-ID In the event that the Command-Code field contains a vendor specific command, the four octet Vendor-ID field contains the IANA assigned "SMI Network Management Private Enterprise Codes" [2] value. If the Command-Code field contains an IETF standard Command, the Vendor-ID field MUST be set to zero (0). Any vendor wishing to implement a vendor-specific Diameter command MUST use their own Vendor-ID along with their privately managed Command- Code address space, guaranteeing that they will not collide with any other vendor's vendor-specific command, nor with future IETF applications. Hop-by-Hop Identifier The Hop-by-Hop Identifier field is four octets, and aids in matching requests and replies. The sender MUST ensure that the Hop-by-Hop identifier in a request is locally unique (to the sender) at any given time, and MAY attempt to ensure that the number is unique across reboots. The sender of an Answer message MUST ensure that the Hop-by-Hop Identifier field contains the same value that was found in the corresponding request. The Hop-by-Hop identifier is normally a monotonically increasing number, whose start value was randomly generated. An answer message that is received with an unknown Hop-by-Hop Identifier MUST be discarded. End-to-End Identifier The End-to-End Identifier is used to detect duplicate messages. Upon reboot, the high order 12 bits are initiated to contain the low order 12 bits of current time, while the low order 20 bits is set to a random value. Senders of request or answer messages MUST insert a unique identifier on each message, by incrementing the identifier by one (1). The End-to-End Identifier MUST NOT be modified by relay agents. The combination of the Origin-Host and this field is used to detect duplicates. Duplicate answer messages that are to be locally consumed (see Section 6.2) SHOULD be Calhoun et al. expires January 2002 [Page 24] Internet-Draft July 2001 silently discarded. AVPs AVPs are a method of encapsulating information relevant to the Diameter message. See section 4. for more information on AVPs. 3.1 Command Codes Each command Request/Answer pair is assigned a command code, and the sub-type (e.g. request or answer) is identified via the 'R' bit in the Command Flags field of the Diameter header. Every Diameter message MUST contain a command code in its header's Command-Code field, which is used to determine the action that is to be taken for a particular message. The following Command Codes are defined in the Diameter base protocol: Command-Name Abbrev. Code Reference -------------------------------------------------------- Abort-Session-Request ASR 274 8.5.1 Abort-Session-Answer ASA 274 8.5.2 Accounting-Request ACR 271 9.7.1 Accounting-Answer ACA 271 9.7.2 Capabilities-Exchange- CER 257 5.3.1 Request Capabilities-Exchange- CEA 257 5.3.2 Answer Device-Watchdog-Request DWR 280 5.5.1 Device-Watchdog-Answer DWA 280 5.5.2 Disconnect-Peer-Request DPR 282 5.4.1 Disconnect-Peer-Answer DPA 282 5.4.2 Re-Auth-Request RAR 258 8.3.1 Re-Auth-Answer RAA 258 8.3.2 Session-Termination- STR 275 8.4.1 Request Session-Termination- STA 275 8.4.2 Answer 3.2 Command Code ABNF specification Every Command Code defined MUST include a corresponding ABNF specification, which is used to define the AVPs that MUST or MAY be present. The following format is used in the definition: command-def = command-name "::=" diameter-message Calhoun et al. expires January 2002 [Page 25] Internet-Draft July 2001 diameter-name = ALPHA *(ALPHA / DIGIT / "-") command-name = diameter-name ; The command-name has to be Command name, ; defined in the base or extended Diameter ; specifications. diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed] header = "< Diameter-Header:" command-id [r-bit] [p-bit] [e-bit] ">" command-id = 1*DIGIT ; The Command Code assigned to the command r-bit = ", REQ" ; If present, the 'R' bit in the Command ; Flags is set, indicating that the message ; is a request, as opposed to an answer. p-bit = ", PXY" ; If present, the 'P' bit in the Command ; Flags is set, indication that the message ; is proxiable. e-bit = ", ERR" ; If present, the 'E' bit in the Command ; Flags is set, indication that the answer ; message contains a Result-Code AVP in ; the "protocol error" class. fixed = [qual] "<" avp-spec ">" ; Defines the fixed position of an AVP required = [qual] "{" avp-spec "}" ; The AVP MUST be present optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. qual = [min] "*" [max] ; See ABNF conventions, RFC 2234 section 6.6. ; The absence of any qualifiers implies that ; one and only one such AVP MUST be present. ; Calhoun et al. expires January 2002 [Page 26] Internet-Draft July 2001 ; NOTE: "[" and "]" have a different meaning ; than in ABNF (see the optional rule, above). ; These braces cannot be used to express ; optional fixed rules (such as an optional ; ICV at the end.) To do this, the convention ; is '0*1fixed'. min = 1*DIGIT ; The minimum number of times the element may ; be present. The default value is zero. max = 1*DIGIT ; The maximum number of times the element may ; be present. The default value is infinity. avp-spec = diameter-name ; The avp-spec has to be an AVP Name, defined ; in the base or extended Diameter ; specifications. avp-name = avp-spec | "AVP" ; The string "AVP" stands for *any* arbitrary ; AVP Name, which does not conflict with the ; required or fixed position AVPs defined in ; the command code definition. The following is a definition of a fictitious command code: Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > { User-Name } * { Origin-Host } * [ AVP ] 3.3 Diameter Command Naming Conventions The following conventions are required for the naming of Diameter messages. Diameter commands typically start with an object name, and end with either the Request or Answer verb. The Request/Answer message pair is used when a Diameter node requests that some action be performed by a peer (e.g. authorize a user, terminate a session). The corresponding answer MUST contain either a positive or negative result code, informing the requester whether the request was successful or not. Other information MAY also be returned in the Answer message. Request and Answer messages share the same command code, and the Calhoun et al. expires January 2002 [Page 27] Internet-Draft July 2001 R(equest) bit in the Diameter header is used to identify whether a message is the request or answer. 4.0 Diameter AVPs Diameter AVPs carry specific authentication, accounting and authorization information, security information as well as configuration details for the request and reply. Some AVPs MAY be listed more than once. The effect of such an AVP is specific, and is specified in each case by the AVP description. Each AVP of type OctetString MUST be padded to align on a 32 bit boundary, while other AVP types align naturally. NULL bytes are added to the end of the AVP Data field till a word boundary is reached. The length of the padding is not reflected in the AVP Length field. 4.1 AVP Header The fields in the AVP header MUST be sent in network byte order. The format of the header is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Code The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. The first 256 AVP numbers are reserved for backward compatibility with RADIUS and are to be interpreted as per NASREQ [7]. AVP numbers 256 and above are used for Diameter, which are allocated by IANA (see section 11.1). AVP Flags The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit Calhoun et al. expires January 2002 [Page 28] Internet-Draft July 2001 SHOULD be considered an error. The 'P' bit is defined in [11]. The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an unrecognized AVP with the 'M' bit set is received by a Diameter node, the message MUST be rejected. Diameter Relay and Redirector agents MUST NOT reject messages with unrecognized AVPs. A Diameter node that sets the 'M' bit in an AVP that is not defined in a given message's ABNF is at fault if the message is rejected. In order to provide service to the user, the node at fault MUST re-issue a request either without the AVP, or without setting its 'M' bit. A Diameter node that rejects a message due to an unrecognized AVP with the 'M' bit set, and the AVP in question is defined in the message's ABNF is at fault. In most cases the initiator of the failing request will not provide service to the user. AVPs with the 'M' bit cleared are informational only and a receiver that receives a message with such an AVP that is not supported MAY simply ignore the AVP. The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space. Unless otherwise noted, AVPs will have the following default AVP Flags field settings: The 'M' bit MUST be set. The 'V' bit MUST NOT be set. AVP Length The AVP Length field is three octets, and indicates the length of this AVP including the AVP Code, AVP Length, AVP Flags, Reserved, the Vendor-ID field (if present) and the AVP data. If a message is received with an invalid attribute length, the message SHOULD be rejected. 4.2 Optional Header Elements The AVP Header contains one optional field. This field is only present if the respective bit-flag is enabled. Vendor-ID The Vendor-ID field is present if the 'V' bit is set in the AVP Flags field. The optional four octet Vendor-ID field contains the Calhoun et al. expires January 2002 [Page 29] Internet-Draft July 2001 IANA assigned "SMI Network Management Private Enterprise Codes" [2] value, encoded in network byte order. Any vendor wishing to implement a vendor-specific Diameter AVP MUST use their own Vendor-ID along with their privately managed AVP address space, guaranteeing that they will not collide with any other vendor's vendor-specific AVP, nor with future IETF applications. A vendor ID value of zero (0) corresponds to the IETF adopted AVP values, as managed by the IANA. Since the absence of the vendor ID field implies that the AVP in question is not vendor specific, implementations SHOULD not use the zero (0) vendor ID. 4.3 AVP Base Data Format The Data field is zero or more octets and contains information specific to the Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field MUST be one of the following base data types or a data type derived from the base data types. In the event that a new AVP Base Data Format is needed, a new version of this RFC must be created. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 8 (12 if the 'V' bit is enabled). AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. Integer32 32 bit signed value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Integer64 64 bit signed value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Unsigned32 32 bit unsigned value, in network byte order. The AVP Length field MUST be set to 12 (16 if the 'V' bit is enabled). Unsigned64 64 bit unsigned value, in network byte order. The AVP Length field MUST be set to 16 (20 if the 'V' bit is enabled). Float32 This represents floating point values of single precision as Calhoun et al. expires January 2002 [Page 30] Internet-Draft July 2001 described by [30]. The 32 bit value is transmitted in network byte order. The AVP Length field MUST be set to 12 (16 if the Float64 This represents floating point values of double precision as described by [30]. The 64 bit value is transmitted in network byte order. The AVP Length field MUST be set to 16 (20 if the Float128 This represents floating point values of quadruple precision as described by [30]. The 128 bit value is transmitted in network byte order. The AVP Length field MUST be set to 24 (28 if the Grouped The Data field is specified as a sequence of AVPs. Each of these AVPs follows - in the order in which they are specified - including their headers and padding. The AVP Length field is set to 8 (12 if the 'V' bit is enabled) plus the total length of all included AVPs, including their headers and padding. 4.4 Derived AVP Data Formats In addition to the AVP Base Data Formats, applications may define data formats derived from the AVP Base Data Formats. New AVP Derived Data Formats MUST be registered with IANA. An application that uses AVP Derived Data Formats other than those defined in the base protocol MUST have a section "AVP Derived Data Formats" that includes each of these formats. In that section, each format is either defined or listed with a reference to the RFC that defines this format. If the AVP Derived Data Format is defined, it SHOULD use a format similar to the format definitions below. The below AVP Derived DATA Formats are commonly used by applications. IPAddress The IPAddress format is derived from the OctetString AVP Base Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most significant octet first. The format of the address (IPv4 or IPv6) is determined by the length. If the attribute value is an IPv4 address, the AVP Length field MUST be 12 (16 if 'V' bit is enabled), otherwise the AVP Length field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 addresses. Time The Time format is derived from the Unsigned32 AVP Base Format. Calhoun et al. expires January 2002 [Page 31] Internet-Draft July 2001 This is 32 bit unsigned value containing the four most significant octets returned from NTP [18], in network byte order. This represent the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. NTP [18] describes a procedure to extend the time to 2104. UTF8String The UTF8String format is derived from the OctetString AVP Base Format. This is a human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an OctetString using the UTF-8 [29] transformation format described in RFC 2279. Since additional code points are added by amendments to the 10646 standard from time to time, implementations MUST be prepared to encounter any code point from 0x00000001 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. Note that since a code point of 0x00000000 is prohibited, no octet will contain a value of 0x00. The use of control codes SHOULD be avoided. When it is necessary to represent a newline, the control code sequence CR LF SHOULD be used. The use of leading or trailing white space SHOULD be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, MAY be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of a UTF8String in octets may be different from the number of characters encoded. Note that the size of an UTF8String is measured in octets, not characters. The UTF8String MUST not contain any octets with a value of zero. Calhoun et al. expires January 2002 [Page 32] Internet-Draft July 2001 DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-Identity = fqdn [ port ] [ transport ] [ protocol ] aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) protocol = ";protocol=" aaa-protocol ; If absent, the default AAA protocol ; is diameter. fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, ; the default Diameter port (TBD) is ; assumed. transport-protocol = ( "tcp" | "sctp" | "udp" ) transport = ";transport=" transport-protocol ; One of the transports used to listen ; for incoming connections. If absent, ; the default SCTP [26] protocol is ; assumed. UDP MUST NOT be used when ; the aaa-protocol field is set to ; diameter. The following are examples of valid Diameter host identities: host.abc.com;transport=tcp host.abc.com:6666;transport=tcp aaa://host.abc.com;protocol=diameter aaa://host.abc.com:6666;protocol=diameter aaa://host.abc.com:6666;transport=tcp;protocol=diameter aaa://host.abc.com:1813;transport=udp;protocol=radius Since multiple Diameter processes on a single host cannot listen for incoming connections on the same port on a given protocol, the DiameterIdentity is guaranteed to be unique per Calhoun et al. expires January 2002 [Page 33] Internet-Draft July 2001 host. A Diameter node MAY advertise different identities on each connection, via the CER and CEA's Origin-Host AVP, but the same identity MUST be used throughout the duration of a connection. When comparing AVPs of this format, it is necessary to add any absent fields with the default values prior to the comparison. For example, diameter-host.abc.com would be expanded to aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp. Enumerated Enumerated is derived from the Integer32 AVP Base Format. This contains a list of valid values and their interpretation and is described in the Diameter application introducing the AVP. IPFilterRule The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. IPFilterRule filters MUST follow the format: action dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" Calhoun et al. expires January 2002 [Page 34] Internet-Draft July 2001 keyword means any protocol will match. src and dst
[ports] The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. The sense of the match can be inverted by preceding an address with the not modifier, causing all other addresses to be matched instead. This does not affect the selection of port numbers. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. The first rule SHOULD be "deny in ip !assigned". With the TCP, UDP and SCTP protocols, optional ports may be specified as: {port|port-port}[,port[,...]] The `-' notation specifies a range of ports (including boundaries). Fragmented packets which have a non-zero offset (i.e. not the first fragment) will never match a rule which has one or more port specifications. See the frag option for details on matching fragmented packets. options: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. Calhoun et al. expires January 2002 [Page 35] Internet-Draft July 2001 ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a `!'. tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a `!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a `!'. A rule which contains a tcpflags specification can never match a fragmented packet which has a non-zero offset. See the frag option for details on matching fragmented packets. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. The supported ICMP types are: echo reply (0), destination unreachable (3), Calhoun et al. expires January 2002 [Page 36] Internet-Draft July 2001 source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls. An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. QoSFilterRule The QosFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be marked or metered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) DSCP values (no mask or range) Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is treated as best effort. QoSFilterRule filters MUST follow the format: action dir proto from src to dst [options] tag - Mark packet with a specific DSCP [49]. The DSCP option MUST be included. Calhoun et al. expires January 2002 [Page 37] Internet-Draft July 2001 meter - Meter traffic. The metering options MUST be included. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. src and dst
[ports] The
may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. The sense of the match can be inverted by preceding an address with the not modifier, causing all other addresses to be matched instead. This does not affect the selection of port numbers. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. The first rule SHOULD be "deny in ip !assigned". With the TCP, UDP and SCTP protocols, optional ports may be specified as: {port|port-port}[,port[,...]] The `-' notation specifies a range of ports (including boundaries). options: DSCP color values as defined in [49]. Exact matching Calhoun et al. expires January 2002 [Page 38] Internet-Draft July 2001 of DSCP values is required (no masks or ranges). the "deny" can replace the color_under or color_over values in the meter action for rate- dependent packet drop. metering The metering option provides Assured Forwarding, as defined in [50], and MUST be present if the action is set to meter. The rate option is the throughput, in bits per second, which is used by the access device to mark packets. Traffic above the rate is marked with the color_over codepoint, while traffic under the rate is marked with the color_under codepoint. The color_under and color_over options contain the drop preferences, and MUST conform to the recommended codepoint keywords described in [50] (e.g. AF13). The metering option also supports the strict limit on traffic required by Expedited Forwarding, as defined in [51]. The color_over option may contain the keyword "drop" to prevent forwarding of traffic that exceeds the rate parameter. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. 4.5 Grouped AVP Values The Diameter protocol allows AVP values of type 'Grouped.' This implies that the Data field is actually a sequence of AVPs. It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. AVPs within an AVP of type Grouped have the same padding requirements as non-Grouped AVPs, as defined in section 4.0. The AVP Code numbering space of all AVPs included in a Grouped AVP is the same as for non-grouped AVPs. Further, if any of the AVPs encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set. All AVPs included in a Grouped AVP Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [31] (with modifications), as defined below. Calhoun et al. expires January 2002 [Page 39] Internet-Draft July 2001 avp-def = name "::=" avp name-fmt = ALPHA *(ALPHA / DIGIT / "-") name = name-fmt ; The name has to be the name of an AVP, ; defined in the base or extended Diameter ; specifications. avp = header [ *fixed] [ *required] [ *optional] [ *fixed] header = "" avpcode = 1*DIGIT ; The AVP Code assigned to the Grouped AVP fixed = [qual] "<" avp-spec ">" required = [qual] "{" avp-spec "}" optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. qual = [min] "*" [max] ; See ABNF conventions, RFC 2234 section 6.6. ; The absence of any qualifiers implies that ; one and only one such AVP MUST be present. ; ; NOTE: "[" and "]" have a different meaning ; than in ABNF (see the optional rule, above). ; These braces cannot be used to express ; optional fixed rules (such as an optional ; ICV at the end.) To do this, the convention ; is '0*1fixed'. min = 1*DIGIT ; The minimum number of times the element may ; be present. max = 1*DIGIT ; The maximum number of times the element may ; be present. avp-spec = name-fmt ; The avp-spec has to be an AVP Name, defined Calhoun et al. expires January 2002 [Page 40] Internet-Draft July 2001 ; in the base or extended Diameter ; specifications. avp-name = avp-spec | "AVP" ; The string "AVP" stands for *any* arbitrary ; AVP Name, which does not conflict with the ; required or fixed position AVPs defined in ; the command code definition. 4.5.1 Example AVP with a Grouped Data type The Example AVP (AVP Code 999999) is of type Grouped and is used to clarify how Grouped AVP values work. The Grouped Data field has the following ABNF grammar: Example-AVP ::= < AVP Header: 999999 > { Origin-Host } 1*{ Session-Id } *[ AVP ] An Example AVP with Grouped Data follows. The Origin-Host AVP is required. In this case: Origin-Host = "example.com". One or more Session-Ids must follow. Here there are two: Session-Id = "grump.example.com:33041;23432;893;0AF3B81" Session-Id = "grump.example.com:33054;23561;2358;0AF3B82" optional AVPs included are Recovery-Policy = 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92 Futuristic-Acct-Record = fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0 Calhoun et al. expires January 2002 [Page 41] Internet-Draft July 2001 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067 d3427475e49968f841 The data for the optional AVPs is represented in hex since the format of these AVPs is neither known at the time of definition of the Example-AVP group, nor (likely) at the time when the example instance of this AVP is interpreted - except by Diameter implementations which support the same set of AVPs. The encoding example illustrates how padding is used, how length fields are calculated and how AVPs do not have to begin on 8 byte boundaries. Also note that AVPs may be present in the Grouped AVP value which the receiver cannot interpret (here, the Recover-Policy and Futuristic-Acct-Record AVPs). This AVP would be encoded as follows: Calhoun et al. expires January 2002 [Page 42] Internet-Draft July 2001 0 1 2 3 4 5 6 7 +-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Example AVP Header (AVP Code = 999999), Length = 468 | +-------+-------+-------+-------+-------+-------+-------+-------+ 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 | +-------+-------+-------+-------+-------+-------+-------+-------+ 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' | +-------+-------+-------+-------+-------+-------+-------+-------+ 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header | +-------+-------+-------+-------+-------+-------+-------+-------+ 32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding| +-------+-------+-------+-------+-------+-------+-------+-------+ 68 | Session-Id AVP Header (AVP Code = 263), Length = 51 | +-------+-------+-------+-------+-------+-------+-------+-------+ 72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding| +-------+-------+-------+-------+-------+-------+-------+-------+ 112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 | +-------+-------+-------+-------+-------+-------+-------+-------+ 120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding| +-------+-------+-------+-------+-------+-------+-------+-------+ 328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137| +-------+-------+-------+-------+-------+-------+-------+-------+ 336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b | +-------+-------+-------+-------+-------+-------+-------+-------+ . . . +-------+-------+-------+-------+-------+-------+-------+-------+ 464 | 0x41 |Padding|Padding|Padding| +-------+-------+-------+-------+ 4.6 Diameter Base Protocol AVPs The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. Calhoun et al. expires January 2002 [Page 43] Internet-Draft July 2001 +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Accounting- 482 9.8.2 Unsigned32 | M | P | | V | Y | Interim-Interval | | | | | | Accounting- 50 9.8.5 OctetString| M | P | | V | Y | Multi-Session-Id | | | | | | Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y | Record-Number | | | | | | Accounting- 480 9.8.1 Enumerated | M | P | | V | Y | Record-Type | | | | | | Accounting- 44 9.8.4 OctetString| M | P | | V | Y | Session-Id | | | | | | Acct- 259 6.10 Integer32 | M | | | V | N | Application-Id | | | | | | Alternate-Peer 275 5.3.8 OctetString| M | | | V | N | Auth- 258 6.9 Integer32 | M | | | V | N | Application-Id | | | | | | Auth-Request- 274 8.7 Enumerated | M | | | V | N | Type | | | | | | Authorization- 291 8.9 Unsigned32 | M | P | | V | N | Lifetime | | | | | | Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N | Period | | | | | | Auth-Session- 277 8.11 Enumerated | M | P | | V | N | State | | | | | | Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N | Type | | | | | | Class 25 8.20 OctetString| M | P | | V | Y | Destination-Host 293 6.6 OctetString| M | | | V | N | Destination- 283 6.7 OctetString| M | | | V | N | Realm | | | | | | Disconnect-Cause 273 5.4.3 Enumerated | M | | | V | N | Error-Message 281 7.3 OctetString| | | | V | N | Error-Reporting- 294 7.4 OctetString| | | | V | N | Host | | | | | | Failed-AVP 279 7.5 OctetString| M | P | | V | N | Firmware- 267 5.3.4 Unsigned32 | | | | V,M | N | Revision | | | | | | Host-IP-Address 257 5.3.5 IPAddress | M | | | V | N | Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y | Time-Out | | | | | | Origin-Host 264 6.4 OctetString| M | | | V | N | Origin-Realm 296 6.5 OctetString| M | | | V | N | -----------------------------------------|----+-----+----+-----|----| Calhoun et al. expires January 2002 [Page 44] Internet-Draft July 2001 +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Origin-State-Id 278 8.16 Unsigned32 | M | | | V | N | Product-Name 269 5.3.7 OctetString| | | | V | N | Proxy-Host 280 6.8.3 IPAddress | M | | | V | N | Proxy-Info 284 6.8.2 Grouped | M | | | V | N | Proxy-State 33 6.8.4 OctetString| M | | | V | N | Redirect-Host 292 6.12 OctetString| M | | | V | N | Redirect-Host- 261 6.13 Enumerated | M | | | V | N | Usage | | | | | | Redirect-Max- 262 6.14 Unsigned32 | M | | | V | N | Cache-Time | | | | | | Result-Code 268 7.1 Unsigned32 | M | | | V | N | Route-Record 282 6.8.1 OctetString| M | | | V | N | Session-Id 263 8.8 OctetString| M | | | V | Y | Session-Timeout 27 8.13 Unsigned32 | M | | | V | N | Session-Binding 270 8.17 Unsigned32 | M | | | V | Y | Session-Server- 271 8.18 Enumerated | M | | | V | Y | Failover | | | | | | Source-Route 286 6.8.5 OctetString| M | | | V | N | Supported- 265 5.3.6 Unsigned32 | M | | | V | N | Vendor-Id | | | | | | Termination- 295 8.15 Enumerated | M | | | V | N | Cause | | | | | | User-Name 1 8.14 OctetString| M | | | V | Y | Vendor-Id 266 5.3.3 Unsigned32 | M | | | V | N | Vendor-Specific- 260 6.11 Grouped | M | | | V | N | Application-Id | | | | | | -----------------------------------------|----+-----+----+-----|----| 5.0 Diameter Peers This section describes how a Diameter nodes establish connections and communicate with peers. 5.1 Peer Connections Although a Diameter node may have many possible peers that it is able to communicate with, it may not be economical to have an established connection to all of them. At a minimum, a Diameter node SHOULD have an established connection with a primary and secondary peer, and MAY have additional connections, if it is deemed necessary. Calhoun et al. expires January 2002 [Page 45] Internet-Draft July 2001 When a peer is deemed suspect, which could occur for various reasons, including not receiving a DWA within an alloted timeframe, no new requests should be forwarded to the peer, but failover procedures are not invoked. When an active peer is moved to this mode, additional connections SHOULD be established to ensure that the necessary number of active connections exists. There are two ways that a peer is removed from the suspect peer list: 1. The peer is no longer reachable, causing the transport connection to be shutdown. The peer is moved to the closed state. 2. Three watchdog messages are exchanged with accepted round trip times, and the connection to the peer is considered stabilized. 5.2 Diameter Peer Discovery Allowing for dynamic Diameter agent discovery will make it possible for simpler and more robust deployment of Diameter services. In order to promote interoperable implementations of Diameter peer discovery, the following mechanisms are described. These are based on existing IETF standards. There are two cases where Diameter peer discovery may be performed. The first is when a Diameter client needs to discover a first-hop Diameter agent. The second case is when a Diameter agent needs to discover another agent - for further handling of a Diameter operation. In both cases, the following 'search order' is recommended: 1. The Diameter implementation consults its list of static (manual) configured Diameter agent locations. These will be used if they exist and respond. 2. The Diameter implementation uses SLPv2 [28] to discover Diameter services. The Diameter service template [32] is included in Appendix A. It is recommended that SLPv2 security be deployed (this requires distributing keys to SLPv2 agents.) This is discussed further in Appendix A. SLPv2 will allow Diameter implementations to discover the location of Diameter agents in the local site, as well as their characteristics. Diameter agents with specific capabilities (say support for the Mobile IP application) can be requested, and only those will be discovered. 3. The Diameter implementation uses DNS to request the SRV RR [33] for the '_diameter._sctp' and/or '_diameter._tcp' server in a Calhoun et al. expires January 2002 [Page 46] Internet-Draft July 2001 particular domain. The Diameter implementation has to know in advance which domain to look for a Diameter agent in. This could be deduced, for example, from the 'realm' in a NAI that a Diameter implementation needed to perform a Diameter operation on. 3.1 If the destination address is a numeric IP address, the requestor contacts the peer at the given address and the port number specified in the SRV record or, if not specified, the default port (TBD). 3.2 The results of the query or queries are merged and ordered based on priority. Then, the searching technique outlined in [46] is used to select servers in order. The requestor attempts to contact each peer in the order listed, at the port number specified in the SRV record. If none of the servers can be contacted, the requestor gives up. If there are no SRV records, DNS address records are used, as described below. 3.3 If there are no SRV records, the requestor queries the DNS server for address records for the destination address '_diameter._sctp'.domain or '_diameter._tcp'.domain. Address records include A RR's, AAAA RR's, A6 RR's or other similar records, chosen according to the requestor's network protocol capabilities. If the DNS server returns no address records, the requestor gives up. If there are address records, the same rules as in step 3.2 apply. Requestors MUST NOT cache query results except according to the rules in [47]. Diameter allows AAA peers to protect the integrity and privacy of communication as well as to perform end-point authentication. Still, it is prudent to employ DNS Security as a precaution when using DNS SRV RRs to look up the location of a Diameter agent [34, 35, 36]. A dynamically discovered peer causes an entry in the Peer Table (see section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value. 5.3 Capabilities Exchange Calhoun et al. expires January 2002 [Page 47] Internet-Draft July 2001 When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see section 5.6). This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, etc.) The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. A receiver of a Capabilities-Exchange-Req (CER) message which does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer connection. Note that receiving a CER or CEA from a peer advertising itself as a Relay (see section 2.5) MUST be interpreted as having common applications with the peer. The CER and CEA messages MUST NOT be proxied, or redirected. Since the CER/CEA messages cannot be proxied, it is still possible that an upstream proxy receives a message for which it has no available peers to handle the application that corresponds to the Command-Code. In such instances, the 'E' bit is set in the answer message (see Section 7.2) to inform the downstream to take action (e.g. re-routing request to an alternate peer). With the exception of the Capabilities-Exchange-Request message, a message of type Request that includes the Auth-Application-Id or Acct-Application-Id AVPs, or a message with an application-specific command code, MAY only be forwarded to a host that has explicitly advertised support for the application (or has advertised the Relay Application Identifier). 5.3.1 Capabilities-Exchange-Request The Capabilities-Exchange-Request (CER), indicated by the Command- Code set to 257 and the Command Flags' 'R' bit set, is sent to inform a peer that a reboot has occurred. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer. When Diameter is run over SCTP [26], which allows for connections to span multiple interfaces, hence multiple IP addresses, the Capabilities-Exchange-Request message MUST contain one Host-IP- Address AVP for each potential IP address that MAY be locally used Calhoun et al. expires January 2002 [Page 48] Internet-Draft July 2001 when transmitting Diameter messages. Message Format ::= < Diameter Header: 257, REQ > { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] * [ Acct-Application-Id ] * [ Alternate-Peer ] [ Destination-Host ] [ Firmware-Revision ] * [ AVP ] 5.3.2 Capabilities-Exchange-Answer The Capabilities-Exchange-Request (CEA), indicated by the Command- Code set to 257 and the Command Flags' 'R' bit cleared, is sent in response to a CER message. When Diameter is run over SCTP [26], which allows for connections to span multiple interfaces, hence multiple IP addresses, the Capabilities-Exchange-Answer message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting Diameter messages. Message Format Calhoun et al. expires January 2002 [Page 49] Internet-Draft July 2001 ::= < Diameter Header: 257 > { Result-Code } { Origin-Host } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } [ Origin-State-Id ] * [ Supported-Vendor-Id ] * [ Auth-Application-Id ] * [ Acct-Application-Id ] * [ Alternate-Peer ] [ Destination-Host ] [ Firmware-Revision ] * [ AVP ] 5.3.3 Vendor-Id AVP The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [2] value assigned to the vendor of the Diameter device. In combination with the Supported-Vendor-Id AVP (section 5.3.6), this MAY be used in order to know which vendor specific attributes may be sent to the peer. It is also envisioned that the combination of the Vendor-Id, Product-Name (section 5.3.7) and the Firmware-Revision (section 5.3.4) AVPs MAY provide very useful debugging information. A Vendor-Id value of zero in the CER or CEA messages is reserved and indicates that the Diameter peer is in the experimental or concept stage and that an IANA Private Enterprise Number has yet to be obtained by the implementor. 5.3.4 Firmware-Revision AVP The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is used to inform a Diameter peer of the firmware revision of the issuing device. For devices that do not have a firmware revision (general purpose computers running Diameter software modules, for instance), the revision of the Diameter software module may be reported instead. 5.3.5 Host-IP-Address AVP Calhoun et al. expires January 2002 [Page 50] Internet-Draft July 2001 The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is used to inform a Diameter peer of the sender's IP address. All source addresses that a Diameter node expects to use with SCTP [26] MUST be advertised in the CER and CEA messages by including a Host- IP-Address AVP for each address. This AVP MUST ONLY be used in the CER and CEA messages. 5.3.6 Supported-Vendor-Id AVP The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [2] value assigned to a vendor other than the device vendor. This is used in the CER and CEA messages in order to inform the peer that the sender supports a subset of the vendor-specific commands and/or AVPs defined by the vendor identified in this AVP. 5.3.7 Product-Name AVP The Product-Name AVP (AVP Code 269) is of type UTF8String, and contains the vendor assigned name for the product. The Product-Name AVP SHOULD remain constant across firmware revisions for the same product. 5.3.8 Alternate-Peer AVP The Alternate-Peer AVP (AVP Code 275) is of type DiameterIdentity, and contains the URI of an alternate peer that MAY be used in server-initiated requests, when routing using the Source-Route AVP. 5.4 Disconnecting Peer connections When a Diameter node disconnects one its transport connections, its peer cannot know the reason for the disconnect, and will most likely assume that a connectivity problem occurred, or that the peer has rebooted. In these cases, the peer may periodically attempt to reconnect, as stated in section 2.1. In the event that the disconnect was a result of either a shortage of internal resources, or simply that the node in question has no intentions of forwarding any Diameter messages to the peer in the foreseeable future, a periodic connection request would not be welcomed. The Disconnection-Reason AVP contains the reason the Diameter node issued the Disconnect- Peer-Request message. The Disconnect-Peer-Request message is used by a Diameter node to Calhoun et al. expires January 2002 [Page 51] Internet-Draft July 2001 inform its peer of its intent to disconnect the transport layer, and that the peer shouldn't reconnect unless it has a valid reason to do so (e.g. message to be forwarded). Upon receipt of the message, the Disconnect-Peer-Answer is returned, which SHOULD contain an error if messages have recently be forwarded, and are likely in flight, which would otherwise cause a race condition. The receiver of the Disconnect-Peer-Answer initiates the transport disconnect. 5.4.1 Disconnect-Peer-Request The Disconnect-Peer-Request (DPR), indicated by the Command-Code set to 282 and the Command Flags' 'R' bit set, is sent to a peer to inform its intentions to shutdown the transport connection. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer. Message Format ::= < Diameter Header: 282, REQ > { Origin-Host } { Origin-Realm } { Destination-Host } { Disconnect-Cause } 5.4.2 Disconnect-Peer-Answer The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set to 282 and the Command Flags' 'R' bit cleared, is sent as a response to the Disconnect-Peer-Request message. Upon receipt of this message, the transport connection is shutdown. Message Format ::= < Diameter Header: 282 > { Result-Code } { Origin-Host } { Origin-Realm } { Destination-Host } 5.4.3 Disconnect-Cause AVP The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A Diameter node MUST include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to Calhoun et al. expires January 2002 [Page 52] Internet-Draft July 2001 shutdown the transport connection. The following values are supported: REBOOTING 0 A scheduled reboot is imminent. BUSY 1 The peer's internal resources are constrained, and it has determined that the transport connection needs to be shutdown. DO_NOT_WANT_TO_TALK_TO_YOU 2 The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the foreseeable future. 5.5 Transport Failure Detection Given the nature of the Diameter protocol, it is recommended that transport failures be detected as soon as possible. Detecting such failures will minimize the occurrence of messages sent to unavailable agents, resulting in unnecessary delays, and will provide better failover performance. The Device-Watchdog-Request and Device- Watchdog-Answer messages, defined in this section, are used to pro- actively detect transport failures. 5.5.1 Device-Watchdog-Request The Device-Watchdog-Request (DWR), indicated by the Command-Code set to 280 and the Command Flags' 'R' bit set, is sent to a peer when no traffic has been exchanged between two peers (see Section 5.5.3). Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer. Message Format ::= < Diameter Header: 280, REQ > { Origin-Host } { Origin-Realm } { Destination-Host } 5.5.2 Device-Watchdog-Answer The Device-Watchdog-Answer (DWA), indicated by the Command-Code set to 280 and the Command Flags' 'R' bit cleared, is sent as a response to the Device-Watchdog-Request message. Calhoun et al. expires January 2002 [Page 53] Internet-Draft July 2001 Message Format ::= < Diameter Header: 280 > { Result-Code } { Origin-Host } { Origin-Realm } { Destination-Host } 5.5.3 Transport Failure Algorithm The watchdog behavior is controlled by an algorithm defined in this section. Note that implementations are not restricted to the algorithm defined herein, but SHOULD implement an algorithm that produces similar results. In this section, we will refer to a memory control structure that contains all information regarding a specific peer as a Peer Control Block, or PCB. For the purposes of illustrating the algorithm, each PCB contains the following fields: Status - This field represents the level of confidence in the algorithm. The following values are defined: OKAY indicates the connection is presumed working WAIT_DWA indicates that a DWR has been sent but a DWA has not yet been received SUSPECT indicates the connection is possibly congested or down Pending - This boolean field is set to TRUE when there are no outstanding unanswered requests. T is the watchdog timer, measured in seconds. Every second, T is decremented. When it reaches 0, the OnTimerElapsed event (see below) is invoked. The algorithm uses the following time constants, which have default values but may be configured differently in an implementation: Ti, the idle time, represents the number of seconds that must elapse when there is no activity, before a DWR is sent. The default value of Ti is 30 seconds. In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, each time Ti is calculated with a jitter by using the Ti configured (or default) value and randomly adding or subtracting a random value drawn between 0.5 and 2 seconds. Calhoun et al. expires January 2002 [Page 54] Internet-Draft July 2001 Alternative calculations to create jitter MAY be used. These MUST be pseudo-random and not cyclic. Tr, the request pending time, represents the number of seconds that must elapse when there are requests pending but no messages have been received, before a DWR is sent. Tr should be less than Ti. The default value of Tr is 10 seconds. Tw, the watchdog pending time, represents the number of seconds that must elapse after a DWR is sent but no DWA has been received, before the PCB's Status field is set to SUSPECT. The default value of Tw is 5 seconds. Td, the disconnect timer, the number of seconds that must elapse when the PCB's Status field is set to SUSPECT and no DWA has been received, before the connection is stopped. The default value of Td is 5 seconds. Pseudo-code for the algorithm is as follows: /* * OnSendRequest() is called whenever a request is sent on * connection */ OnSendRequest(pcb) { if pcb->Status = OKAY AND T > Tr T = Tr } /* * OnReceiveNonDWA() is called whenever a message other * than DWA is received from the peer. This message MAY * be a request or an answer. */ OnReceiveNonDWA(pcb) { if pcb->Status = OKAY if pcb->Pending T = Tr