Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 3588

Diameter Base Protocol

Pages: 147
Obsoleted by:  6733
Updated by:  572957196408
Part 5 of 5 – Pages 124 to 147
First   Prev   None

ToP   noToC   RFC3588 - Page 124   prevText

10. AVP Occurrence Table

The following tables presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. The table uses the following symbols: 0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message. 0-1 Zero or one instance of the AVP MAY be present in the message. It is considered an error if there are more than one instance of the AVP. 1 One instance of the AVP MUST be present in the message. 1+ At least one instance of the AVP MUST be present in the message.

10.1. Base Protocol Command AVP Table

The table in this section is limited to the non-accounting Command Codes defined in this specification.
ToP   noToC   RFC3588 - Page 125
                       |                  Command-Code                 |
   Acct-Interim-       |0  |0  |0  |0  |0  |0  |0-1|0  |0  |0  |0  |0  |
     Interval          |   |   |   |   |   |   |   |   |   |   |   |   |
   Accounting-Realtime-|0  |0  |0  |0  |0  |0  |0-1|0  |0  |0  |0  |0  |
     Required          |   |   |   |   |   |   |   |   |   |   |   |   |
   Acct-Application-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Application-Id |0+ |0+ |0  |0  |0  |0  |1  |0  |1  |0  |1  |0  |
   Auth-Grace-Period   |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Request-Type   |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Session-State  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Authorization-      |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Lifetime          |   |   |   |   |   |   |   |   |   |   |   |   |
   Class               |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0+ |0+ |
   Destination-Host    |0  |0  |0  |0  |0  |0  |1  |0  |1  |0  |0-1|0  |
   Destination-Realm   |0  |0  |0  |0  |0  |0  |1  |0  |1  |0  |1  |0  |
   Disconnect-Cause    |0  |0  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Error-Message       |0  |0-1|0  |0-1|0  |0-1|0  |0-1|0  |0-1|0  |0-1|
   Error-Reporting-Host|0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
   Failed-AVP          |0  |0+ |0  |0+ |0  |0+ |0  |0+ |0  |0+ |0  |0+ |
   Firmware-Revision   |0-1|0-1|0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Host-IP-Address     |1+ |1+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Inband-Security-Id  |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Multi-Round-Time-Out|0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Origin-Host         |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |
   Origin-Realm        |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |1  |
   Origin-State-Id     |0-1|0-1|0  |0  |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
   Product-Name        |1  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Proxy-Info          |0  |0  |0  |0  |0  |0  |0+ |0+ |0+ |0+ |0+ |0+ |
   Redirect-Host       |0  |0  |0  |0  |0  |0  |0  |0+ |0  |0+ |0  |0+ |
   Redirect-Host-Usage |0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
   Redirect-Max-Cache- |0  |0  |0  |0  |0  |0  |0  |0-1|0  |0-1|0  |0-1|
     Time              |   |   |   |   |   |   |   |   |   |   |   |   |
   Result-Code         |0  |1  |0  |1  |0  |1  |0  |1  |0  |0  |0  |1  |
   Re-Auth-Request-Type|0  |0  |0  |0  |0  |0  |1  |0  |0  |0  |0  |0  |
   Route-Record        |0  |0  |0  |0  |0  |0  |0+ |0  |0+ |0  |0+ |0  |
   Session-Binding     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Session-Id          |0  |0  |0  |0  |0  |0  |1  |1  |1  |1  |1  |1  |
   Session-Server-     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Failover          |   |   |   |   |   |   |   |   |   |   |   |   |
   Session-Timeout     |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Supported-Vendor-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Termination-Cause   |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |1  |0  |
   User-Name           |0  |0  |0  |0  |0  |0  |0-1|0-1|0-1|0-1|0-1|0-1|
   Vendor-Id           |1  |1  |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
ToP   noToC   RFC3588 - Page 126
   Vendor-Specific-    |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
     Application-Id    |   |   |   |   |   |   |   |   |   |   |   |   |

10.2. Accounting AVP Table

The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages. These AVP occurrence requirements are guidelines, which may be expanded, and/or overridden by application-specific requirements in the Diameter applications documents. +-----------+ | Command | | Code | +-----+-----+ Attribute Name | ACR | ACA | ------------------------------+-----+-----+ Acct-Interim-Interval | 0-1 | 0-1 | Acct-Multi-Session-Id | 0-1 | 0-1 | Accounting-Record-Number | 1 | 1 | Accounting-Record-Type | 1 | 1 | Acct-Session-Id | 0-1 | 0-1 | Accounting-Sub-Session-Id | 0-1 | 0-1 | Accounting-Realtime-Required | 0-1 | 0-1 | Acct-Application-Id | 0-1 | 0-1 | Auth-Application-Id | 0 | 0 | Class | 0+ | 0+ | Destination-Host | 0-1 | 0 | Destination-Realm | 1 | 0 | Error-Reporting-Host | 0 | 0+ | Event-Timestamp | 0-1 | 0-1 | Origin-Host | 1 | 1 | Origin-Realm | 1 | 1 | Proxy-Info | 0+ | 0+ | Route-Record | 0+ | 0+ | Result-Code | 0 | 1 | Session-Id | 1 | 1 | Termination-Cause | 0-1 | 0-1 | User-Name | 0-1 | 0-1 | Vendor-Specific-Application-Id| 0-1 | 0-1 | ------------------------------+-----+-----+
ToP   noToC   RFC3588 - Page 127

11. IANA Considerations

This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Diameter protocol, in accordance with BCP 26 [IANA]. The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action". This section explains the criteria to be used by the IANA for assignment of numbers within namespaces defined within this document. Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. For Designated Expert with Specification Required, the request is posted to the AAA WG mailing list (or, if it has been disbanded, a successor designated by the Area Director) for comment and review, and MUST include a pointer to a public specification. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the AAA WG mailing list or its successor. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.

11.1. AVP Header

As defined in Section 4, the AVP header contains three fields that requires IANA namespace management; the AVP Code, Vendor-ID and Flags field.

11.1.1. AVP Codes

The AVP Code namespace is used to identify attributes. There are multiple namespaces. Vendors can have their own AVP Codes namespace which will be identified by their Vendor-ID (also known as Enterprise-Number) and they control the assignments of their vendor- specific AVP codes within their own namespace. The absence of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA controlled AVP Codes namespace. The AVP Codes and sometimes also possible values in an AVP are controlled and maintained by IANA.
ToP   noToC   RFC3588 - Page 128
   AVP Code 0 is not used. AVP Codes 1-255 are managed separately as
   RADIUS Attribute Types [RADTYPE].  This document defines the AVP
   Codes 257-274, 276-285, 287, 291-300, 480, 483 and 485-486.  See
   Section 4.5 for the assignment of the namespace in this

   AVPs may be allocated following Designated Expert with Specification
   Required [IANA].  Release of blocks of AVPs (more than 3 at a time
   for a given purpose) should require IETF Consensus.

   Note that Diameter defines a mechanism for Vendor-Specific AVPs,
   where the Vendor-Id field in the AVP header is set to a non-zero
   value.  Vendor-Specific AVPs codes are for Private Use and should be
   encouraged instead of allocation of global attribute types, for
   functions specific only to one vendor's implementation of Diameter,
   where no interoperability is deemed useful.  Where a Vendor-Specific
   AVP is implemented by more than one vendor, allocation of global AVPs
   should be encouraged instead.

11.1.2. AVP Flags

There are 8 bits in the AVP Flags field of the AVP header, defined in Section 4. This document assigns bit 0 ('V'endor Specific), bit 1 ('M'andatory) and bit 2 ('P'rotected). The remaining bits should only be assigned via a Standards Action [IANA].

11.2. Diameter Header

As defined in Section 3, the Diameter header contains two fields that require IANA namespace management; Command Code and Command Flags.

11.2.1. Command Codes

The Command Code namespace is used to identify Diameter commands. The values 0-255 are reserved for RADIUS backward compatibility, and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256- 16,777,213 are for permanent, standard commands, allocated by IETF Consensus [IANA]. This document defines the Command Codes 257, 258, 271, 274-275, 280 and 282. See Section 3.1 for the assignment of the namespace in this specification. The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands, as outlined in [IANA-EXP].
ToP   noToC   RFC3588 - Page 129

11.2.2. Command Flags

There are eight bits in the Command Flags field of the Diameter header. This document assigns bit 0 ('R'equest), bit 1 ('P'roxy), bit 2 ('E'rror) and bit 3 ('T'). Bits 4 through 7 MUST only be assigned via a Standards Action [IANA].

11.3. Application Identifiers

As defined in Section 2.4, the Application Identifier is used to identify a specific Diameter Application. There are standards-track application ids and vendor specific application ids. IANA [IANA] has assigned the range 0x00000001 to 0x00ffffff for standards-track applications; and 0x01000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. The following values are allocated. Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff Assignment of standards-track application IDs are by Designated Expert with Specification Required [IANA]. Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier space. Vendor-Specific Application Identifiers, are for Private Use. Vendor-Specific Application Identifiers are assigned on a First Come, First Served basis by IANA.

11.4. AVP Values

Certain AVPs in Diameter define a list of values with various meanings. For attributes other than those specified in this section, adding additional values to the list can be done on a First Come, First Served basis by IANA.

11.4.1. Result-Code AVP Values

As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017. All remaining values are available for assignment via IETF Consensus [IANA].
ToP   noToC   RFC3588 - Page 130

11.4.2. Accounting-Record-Type AVP Values

As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code 480) defines the values 1-4. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.3. Termination-Cause AVP Values

As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295) defines the values 1-8. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.4. Redirect-Host-Usage AVP Values

As defined in Section 6.13, the Redirect-Host-Usage AVP (AVP Code 261) defines the values 0-5. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.5. Session-Server-Failover AVP Values

As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code 271) defines the values 0-3. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.6. Session-Binding AVP Values

As defined in Section 8.17, the Session-Binding AVP (AVP Code 270) defines the bits 1-4. All remaining bits are available for assignment via IETF Consensus [IANA].

11.4.7. Disconnect-Cause AVP Values

As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273) defines the values 0-2. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.8. Auth-Request-Type AVP Values

As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274) defines the values 1-3. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.9. Auth-Session-State AVP Values

As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277) defines the values 0-1. All remaining values are available for assignment via IETF Consensus [IANA].
ToP   noToC   RFC3588 - Page 131

11.4.10. Re-Auth-Request-Type AVP Values

As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code 285) defines the values 0-1. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.11. Accounting-Realtime-Required AVP Values

As defined in Section 9.8.7, the Accounting-Realtime-Required AVP (AVP Code 483) defines the values 1-3. All remaining values are available for assignment via IETF Consensus [IANA].

11.4.12. Inband-Security-Id AVP (code 299)

As defined in Section 6.10, the Inband-Security-Id AVP (AVP Code 299) defines the values 0-1. All remaining values are available for assignment via IETF Consensus [IANA].

11.5. Diameter TCP/SCTP Port Numbers

The IANA has assigned TCP and SCTP port number 3868 to Diameter.

11.6. NAPTR Service Fields

The registration in the RFC MUST include the following information: Service Field: The service field being registered. An example for a new fictitious transport protocol called NCTP might be "AAA+D2N". Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with reference to a document that describes the transport protocol. For example - "New Connectionless Transport Protocol (NCTP), RFC 5766". Name and Contact Information: The name, address, email address and telephone number for the person performing the registration. The following values have been placed into the registry: Services Field Protocol AAA+D2T TCP AAA+D2S SCTP

12. Diameter protocol related configurable parameters

This section contains the configurable parameters that are found throughout this document:
ToP   noToC   RFC3588 - Page 132
   Diameter Peer
      A Diameter entity MAY communicate with peers that are statically
      configured.  A statically configured Diameter peer would require
      that either the IP address or the fully qualified domain name
      (FQDN) be supplied, which would then be used to resolve through

   Realm Routing Table
      A Diameter proxy server routes messages based on the realm portion
      of a Network Access Identifier (NAI).  The server MUST have a
      table of Realm Names, and the address of the peer to which the
      message must be forwarded to.  The routing table MAY also include
      a "default route", which is typically used for all messages that
      cannot be locally processed.

   Tc timer
      The Tc timer controls the frequency that transport connection
      attempts are done to a peer with whom no active transport
      connection exists.  The recommended value is 30 seconds.

13. Security Considerations

The Diameter base protocol assumes that messages are secured by using either IPSec or TLS. This security mechanism is acceptable in environments where there is no untrusted third party agent. In other situations, end-to-end security is needed. Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH] and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. Diameter implementations MUST use transmission-level security of some kind (IPsec or TLS) on each connection. If a Diameter connection is not protected by IPsec, then the CER/CEA exchange MUST include an Inband-Security-ID AVP with a value of TLS. For TLS usage, a TLS handshake will begin when both ends are in the open state, after completion of the CER/CEA exchange. If the TLS handshake is successful, all further messages will be sent via TLS. If the handshake fails, both ends move to the closed state. It is suggested that IPsec be used primarily at the edges for intra- domain exchanges. For NAS devices without certificate support, pre- shared keys can be used between the NAS and a local AAA proxy. For protection of inter-domain exchanges, TLS is recommended. See Sections 13.1 and 13.2 for more details on IPsec and TLS usage.
ToP   noToC   RFC3588 - Page 133

13.1. IPsec Usage

All Diameter implementations MUST support IPsec ESP [IPsec] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST support the replay protection mechanisms of IPsec. Diameter implementations MUST support IKE for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [IPSECDOI]. Diameter implementations MUST support peer authentication using a pre-shared key, and MAY support certificate- based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's Sections 5.2 and 5.3 [IKE] SHOULD NOT be used. Conformant implementations MUST support both IKE Main Mode and Aggressive Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD use pertinent certificate revocation checks before accepting a PKI certificate for use in IKE's authentication procedures. The Phase 2 Quick Mode exchanges used to negotiate protection for Diameter connections MUST explicitly carry the Identity Payload fields (IDci and IDcr). The DOI provides for several types of identification data. However, when used in conformant implementations, each ID Payload MUST carry a single IP address and a single non-zero port number, and MUST NOT use the IP Subnet or IP Address Range formats. This allows the Phase 2 security association to correspond to specific TCP and SCTP connections. Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down a Diameter connection. Rather, it is preferable to leave the connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing connections up and down.
ToP   noToC   RFC3588 - Page 134

13.2. TLS Usage

A Diameter node that initiates a connection to another Diameter node acts as a TLS client according to [TLS], and a Diameter node that accepts a connection acts as a TLS server. Diameter nodes implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, the Diameter node acting as TLS server must request a certificate from the Diameter node acting as TLS client, and the Diameter node acting as TLS client MUST be prepared to supply a certificate on request. Diameter nodes MUST be able to negotiate the following TLS cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Diameter nodes SHOULD be able to negotiate the following TLS cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA Diameter nodes MAY negotiate other TLS cipher suites.

13.3. Peer-to-Peer Considerations

As with any peer-to-peer protocol, proper configuration of the trust model within a Diameter peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the Diameter peer. These root CAs are likely to be unique to Diameter usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the Diameter peer and other organizations. As a result, a Diameter peer will typically not be configured to allow connectivity with any arbitrary peer. When certificate authentication Diameter peers may not be known beforehand, and therefore peer discovery may be required. Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs for each application individually; the same policy must be used for all applications. This implies, for example, that a root CA trusted for use with Diameter must also be
ToP   noToC   RFC3588 - Page 135
   trusted to protect SNMP.  These restrictions can be awkward at best.
   Since TLS supports application-level granularity in certificate
   policy, TLS SHOULD be used to protect Diameter connections between
   administrative domains.  IPsec is most appropriate for intra-domain
   usage when pre-shared keys are used as a security mechanism.

   When pre-shared key authentication is used with IPsec to protect
   Diameter, unique pre-shared keys are configured with Diameter peers,
   who are identified by their IP address (Main Mode), or possibly their
   FQDN (Aggressive Mode).  As a result, it is necessary for the set of
   Diameter peers to be known beforehand.  Therefore, peer discovery is
   typically not necessary.

   The following is intended to provide some guidance on the issue.

   It is recommended that a Diameter peer implement the same security
   mechanism (IPsec or TLS) across all its peer-to-peer connections.
   Inconsistent use of security mechanisms can result in redundant
   security mechanisms being used (e.g., TLS over IPsec) or worse,
   potential security vulnerabilities.  When IPsec is used with
   Diameter, a typical security policy for outbound traffic is "Initiate
   IPsec, from me to any, destination port Diameter"; for inbound
   traffic, the policy would be "Require IPsec, from any to me,
   destination port Diameter".

   This policy causes IPsec to be used whenever a Diameter peer
   initiates a connection to another Diameter peer, and to be required
   whenever an inbound Diameter connection occurs.  This policy is
   attractive, since it does not require policy to be set for each peer
   or dynamically modified each time a new Diameter connection is
   created; an IPsec SA is automatically created based on a simple
   static policy.  Since IPsec extensions are typically not available to
   the sockets API on most platforms, and IPsec policy functionality is
   implementation dependent, use of a simple static policy is the often
   the simplest route to IPsec-enabling a Diameter implementation.

   One implication of the recommended policy is that if a node is using
   both TLS and IPsec, there is not a convenient way in which to use
   either TLS or IPsec, but not both, without reserving an additional
   port for TLS usage.  Since Diameter uses the same port for TLS and
   non-TLS usage, where the recommended IPsec policy is put in place, a
   TLS-protected connection will match the IPsec policy, and both IPsec
   and TLS will be used to protect the Diameter connection.  To avoid
   this, it would be necessary to plumb peer-specific policies either
   statically or dynamically.
ToP   noToC   RFC3588 - Page 136
   If IPsec is used to secure Diameter peer-to-peer connections, IPsec
   policy SHOULD be set so as to require IPsec protection for inbound
   connections, and to initiate IPsec protection for outbound
   connections.  This can be accomplished via use of inbound and
   outbound filter policy.

14. References

14.1. Normative References

[AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [ASSIGNNO] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [DIFFSERV] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [DIFFSERVAF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [DIFFSERVEF] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB", RFC 3246, March 2002. [DNSSRV] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [FLOATPOINT] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985. [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
ToP   noToC   RFC3588 - Page 137
   [IANAADFAM]    IANA; "Address Family Numbers",

   [IANAWEB]      IANA, "Number assignment",

   [IKE]          Harkins, D. and D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC 2409, November 1998.

   [IPComp]       Shacham, A., Monsour, R., Pereira, R. and M. Thomas,
                  "IP Payload Compression Protocol (IPComp)", RFC 3173,
                  September 2001.

   [IPSECDOI]     Piper, D., "The Internet IP Security Domain of
                  Interpretation for ISAKMP", RFC 2407, November 1998.

   [IPV4]         Postel, J., "Internet Protocol", STD 5, RFC 791,
                  September 1981.

   [IPV6]         Hinden, R. and S. Deering, "IP Version 6 Addressing
                  Architecture", RFC 2373, July 1998.

   [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [NAI]          Aboba, B. and M. Beadles, "The Network Access
                  Identifier", RFC 2486, January 1999.

   [NAPTR]        Mealling, M. and R. Daniel, "The naming authority
                  pointer (NAPTR) DNS resource record," RFC 2915,
                  September 2000.

   [RADTYPE]      IANA, "RADIUS Types",

   [SCTP]         Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
                  Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
                  Zhang, L. and V. Paxson, "Stream Control Transmission
                  Protocol", RFC 2960, October 2000.

   [SLP]          Veizades, J., Guttman, E., Perkins, C. and M. Day,
                  "Service Location Protocol, Version 2", RFC 2165, June

   [SNTP]         Mills, D., "Simple Network Time Protocol (SNTP)
                  Version 4 for IPv4, IPv6 and OSI", RFC 2030, October
ToP   noToC   RFC3588 - Page 138
   [TCP]          Postel, J. "Transmission Control Protocol", STD 7, RFC
                  793, January 1981.

   [TEMPLATE]     Guttman, E., Perkins, C. and J. Kempf, "Service
                  Templates and Service: Schemes", RFC 2609, June 1999.

   [TLS]          Dierks, T. and C. Allen, "The TLS Protocol Version
                  1.0", RFC 2246, January 1999.

   [TLSSCTP]      Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport
                  Layer Security over Stream Control Transmission
                  Protocol", RFC 3436, December 2002.

   [URI]          Berners-Lee, T., Fielding, R. and L. Masinter,
                  "Uniform Resource Identifiers (URI): Generic Syntax",
                  RFC 2396, August 1998.

   [UTF8]         Yergeau, F., "UTF-8, a transformation format of ISO
                  10646", RFC 2279, January 1998.

14.2. Informative References

[AAACMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Application", Work in Progress. [AAAREQ] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Walsh, P., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Xu, Y., Campbell, E., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000. [ACCMGMT] Aboba, B., Arkko, J. and D. Harrington. "Introduction to Accounting Management", RFC 2975, October 2000. [CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, Y., Baba, S., Ayaki, T., Seki, T. and A. Hameed, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [DIAMMIP] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", Work in Progress.
ToP   noToC   RFC3588 - Page 139
   [DYNAUTH]      Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
                  Aboba, "Dynamic Authorization Extensions to Remote
                  Authentication Dial In User Service (RADIUS)", RFC
                  3576, July 2003.

   [IANA-EXP]     T. Narten, "Assigning Experimental and Testing Numbers
                  Considered Useful", Work in Progress.

   [MIPV4]        Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
                  August 2002.

   [MIPREQ]       Glass, S., Hiller, T., Jacobs, S. and C. Perkins,
                  "Mobile IP Authentication, Authorization, and
                  Accounting Requirements", RFC 2977, October 2000.

   [NASNG]        Mitton, D. and M. Beadles, "Network Access Server
                  Requirements Next Generation (NASREQNG) NAS Model",
                  RFC 2881, July 2000.

   [NASREQ]       P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter
                  NASREQ Application", Work in Progress.

   [NASCRIT]      Beadles, M. and D. Mitton, "Criteria for Evaluating
                  Network Access Server Protocols", RFC 3169, September

   [PPP]          Simpson, W., "The Point-to-Point Protocol (PPP)", STD
                  51, RFC 1661, July 1994.

   [PROXYCHAIN]   Aboba, B. and J. Vollbrecht, "Proxy Chaining and
                  Policy Implementation in Roaming", RFC 2607, June

   [RADACCT]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RADEXT]       Rigney, C., Willats, W. and P. Calhoun, "RADIUS
                  Extensions", RFC 2869, June 2000.

   [RADIUS]       Rigney, C., Willens, S., Rubens, A. and W. Simpson,
                  "Remote Authentication Dial In User Service (RADIUS)",
                  RFC 2865, June 2000.

   [ROAMREV]      Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang,
                  "Review of Roaming Implementations", RFC 2194,
                  September 1997.

   [ROAMCRIT]     Aboba, B. and G. Zorn, "Criteria for Evaluating
                  Roaming Protocols", RFC 2477, January 1999.
ToP   noToC   RFC3588 - Page 140
   [SECARCH]      Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [TACACS]       Finseth, C., "An Access Control Protocol, Sometimes
                  Called TACACS", RFC 1492, July 1993.

15. Acknowledgements

The authors would like to thank Nenad Trifunovic, Tony Johansson and Pankaj Patel for their participation in the pre-IETF Document Reading Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided invaluable assistance in working out transport issues, and similarly with Steven Bellovin in the security area. Paul Funk and David Mitton were instrumental in getting the Peer State Machine correct, and our deep thanks go to them for their time. Text in this document was also provided by Paul Funk, Mark Eklund, Mark Jones and Dave Spence. Jacques Caron provided many great comments as a result of a thorough review of the spec. The authors would also like to acknowledge the following people for their contribution in the development of the Diameter protocol: Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell, David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien, Bob Kopacz, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and Jeff Weisberg. Finally, Pat Calhoun would like to thank Sun Microsystems since most of the effort put into this document was done while he was in their employ.
ToP   noToC   RFC3588 - Page 141

Appendix A. Diameter Service Template

The following service template describes the attributes used by Diameter servers to advertise themselves. This simplifies the process of selecting an appropriate server to communicate with. A Diameter client can request specific Diameter servers based on characteristics of the Diameter service desired (for example, an AAA server to use for accounting.) Name of submitter: "Erik Guttman" <> Language of service template: en Security Considerations: Diameter clients and servers use various cryptographic mechanisms to protect communication integrity, confidentiality as well as perform end-point authentication. It would thus be difficult if not impossible for an attacker to advertise itself using SLPv2 and pose as a legitimate Diameter peer without proper preconfigured secrets or cryptographic keys. Still, as Diameter services are vital for network operation it is important to use SLPv2 authentication to prevent an attacker from modifying or eliminating service advertisements for legitimate Diameter servers. Template text: -------------------------template begins here----------------------- template-type=service:diameter template-version=0.0 template-description= The Diameter protocol is defined by RFC 3588. template-url-syntax= url-path= ; The Diameter URL format is described in Section 2.9. ; Example: 'aaa://;transport=tcp supported-auth-applications= string L M # This attribute lists the Diameter applications supported by the # AAA implementation. The applications currently defined are: # Application Name Defined by # ---------------- ----------------------------------- # NASREQ Diameter Network Access Server Application # MobileIP Diameter Mobile IP Application # # Notes: # . Diameter implementations support one or more applications. # . Additional applications may be defined in the future. # An updated service template will be created at that time.
ToP   noToC   RFC3588 - Page 142

      supported-acct-applications= string L M
      # This attribute lists the Diameter applications supported by the
      # AAA implementation.  The applications currently defined are:
      #  Application Name     Defined by
      #  ----------------     -----------------------------------
      #  NASREQ               Diameter Network Access Server Application
      #  MobileIP             Diameter Mobile IP Application
      # Notes:
      #   . Diameter implementations support one or more applications.
      #   . Additional applications may be defined in the future.
      #     An updated service template will be created at that time.

      supported-transports= string L M
      # This attribute lists the supported transports that the Diameter
      # implementation accepts.  Note that a compliant Diameter
      # implementation MUST support SCTP, though it MAY support other
      # transports, too.

   -------------------------template ends here-----------------------

Appendix B. NAPTR Example

As an example, consider a client that wishes to resolve The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "AAA+D2S" "" IN NAPTR 100 50 "s" "AAA+D2T" "" This indicates that the server supports SCTP, and TCP, in that order. If the client supports over SCTP, SCTP will be used, targeted to a host determined by an SRV lookup of That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 IN SRV 0 2 5060
ToP   noToC   RFC3588 - Page 143

Appendix C. Duplicate Detection

As described in Section 9.4, accounting record duplicate detection is based on session identifiers. Duplicates can appear for various reasons: - Failover to an alternate server. Where close to real-time performance is required, failover thresholds need to be kept low and this may lead to an increased likelihood of duplicates. Failover can occur at the client or within Diameter agents. - Failure of a client or agent after sending of a record from non- volatile memory, but prior to receipt of an application layer ACK and deletion of the record. record to be sent. This will result in retransmission of the record soon after the client or agent has rebooted. - Duplicates received from RADIUS gateways. Since the retransmission behavior of RADIUS is not defined within [RFC2865], the likelihood of duplication will vary according to the implementation. - Implementation problems and misconfiguration. The T flag is used as an indication of an application layer retransmission event, e.g., due to failover to an alternate server. It is defined only for request messages sent by Diameter clients or agents. For instance, after a reboot, a client may not know whether it has already tried to send the accounting records in its non- volatile memory before the reboot occurred. Diameter servers MAY use the T flag as an aid when processing requests and detecting duplicate messages. However, servers that do this MUST ensure that duplicates are found even when the first transmitted request arrives at the server after the retransmitted request. It can be used only in cases where no answer has been received from the Server for a request and the request is sent again, (e.g., due to a failover to an alternate peer, due to a recovered primary peer or due to a client re-sending a stored record from non-volatile memory such as after reboot of a client or agent). In some cases the Diameter accounting server can delay the duplicate detection and accounting record processing until a post-processing phase takes place. At that time records are likely to be sorted according to the included User-Name and duplicate elimination is easy in this case. In other situations it may be necessary to perform real-time duplicate detection, such as when credit limits are imposed or real-time fraud detection is desired.
ToP   noToC   RFC3588 - Page 144
   In general, only generation of duplicates due to failover or re-
   sending of records in non-volatile storage can be reliably detected
   by Diameter clients or agents.  In such cases the Diameter client or
   agents can mark the message as possible duplicate by setting the T
   flag.  Since the Diameter server is responsible for duplicate
   detection, it can choose to make use of the T flag or not, in order
   to optimize duplicate detection.  Since the T flag does not affect
   interoperability, and may not be needed by some servers, generation
   of the T flag is REQUIRED for Diameter clients and agents, but MAY be
   implemented by Diameter servers.

   As an example, it can be usually be assumed that duplicates appear
   within a time window of longest recorded network partition or device
   fault, perhaps a day.  So only records within this time window need
   to be looked at in the backward direction.  Secondly, hashing
   techniques or other schemes, such as the use of the T flag in the
   received messages, may be used to eliminate the need to do a full
   search even in this set except for rare cases.

   The following is an example of how the T flag may be used by the
   server to detect duplicate requests.

      A Diameter server MAY check the T flag of the received message to
      determine if the record is a possible duplicate.  If the T flag is
      set in the request message, the server searches for a duplicate
      within a configurable duplication time window backward and
      forward.  This limits database searching to those records where
      the T flag is set.  In a well run network, network partitions and
      device faults will presumably be rare events, so this approach
      represents a substantial optimization of the duplicate detection
      process.  During failover, it is possible for the original record
      to be received after the T flag marked record, due to differences
      in network delays experienced along the path by the original and
      duplicate transmissions.  The likelihood of this occurring
      increases as the failover interval is decreased.  In order to be
      able to detect out of order duplicates, the Diameter server should
      use backward and forward time windows when performing duplicate
      checking for the T flag marked request.  For example, in order to
      allow time for the original record to exit the network and be
      recorded by the accounting server, the Diameter server can delay
      processing records with the T flag set until a time period
      TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing
      of the original transport connection.  After this time period has
      expired, then it may check the T flag marked records against the
      database with relative assurance that the original records, if
      sent, have been received and recorded.
ToP   noToC   RFC3588 - Page 145

Appendix D. Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
ToP   noToC   RFC3588 - Page 146

Authors' Addresses

Pat R. Calhoun Airespace, Inc. 110 Nortech Parkway San Jose, California, 95134 USA Phone: +1 408-635-2023 Fax: +1 408-635-2020 EMail: John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland Phone: +358 50 483 6242 EMail: Jari Arkko Ericsson 02420 Jorvas Finland Phone: +358 40 5079256 EMail: Erik Guttman Sun Microsystems, Inc. Eichhoelzelstr. 7 74915 Waibstadt Germany Phone: +49 7263 911 701 EMail: Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA Phone: +1 425 438 8218
ToP   noToC   RFC3588 - Page 147
Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.