Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3588


Diameter Base Protocol

Part 5 of 5, p. 124 to 147
Prev RFC Part


prevText      Top      Up      ToC       Page 124 
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
   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

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      Up      ToC       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      Up      ToC       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      Up      ToC       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

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      Up      ToC       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      Up      ToC       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

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

   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      Up      ToC       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

   Diameter nodes MUST be able to negotiate the following TLS cipher


   Diameter nodes SHOULD be able to negotiate the following TLS cipher


   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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

Top      Up      ToC       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

   Template text:
   -------------------------template begins here-----------------------


     The Diameter protocol is defined by RFC 3588.

     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      Up      ToC       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      Up      ToC       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

   -  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

   -  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 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      Up      ToC       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      Up      ToC       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

Top      Up      ToC       Page 146 
Authors' Addresses

   Pat R. Calhoun
   Airespace, Inc.
   110 Nortech Parkway
   San Jose, California, 95134

   Phone:  +1 408-635-2023
   Fax:  +1 408-635-2020

   John Loughney
   Nokia Research Center
   Itamerenkatu 11-13
   00180 Helsinki

   Phone:  +358 50 483 6242

   Jari Arkko
   02420 Jorvas

   Phone: +358 40 5079256

   Erik Guttman
   Sun Microsystems, Inc.
   Eichhoelzelstr. 7
   74915 Waibstadt

   Phone:  +49 7263 911 701

   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, WA 98004

   Phone:  +1 425 438 8218

Top      Up      ToC       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.