Diameter Parameter Query

The AAA backend infrastructure stores information about various device related interactions, such as network attachments, accounting streams, etc. In certain cases, parts of this information needs to be shared with other entities in the operators network to provide smooth network operation. An example of this interaction is when a Location Server is deployed in an IP-based network and needs to obtain information about the users point of attachment to make location information for emergency services. This document describes how such a Diameter based interface can help a location server to query inforation from the backend infrastructure. In particular, it allows the query to contain the IP address of the device and to request information about shows an example of how the Diameter interface used in this document can be used by a Location Server receiving a request to query a Diameter Server.

This specification defines a Diameter applications and their respective Application Identifiers:

The DPQ Application Identifier is used when a Diameter client utilizes the Diameter Parameter Query Request and Response messages.

The Diameter server is stateless in the protocol interaction described by this document. As such, the Session-Termination-Request (STR), the Session-Termination-Answer (STA), Abort-Session-Request (ASR) nor the Abort-Session-Answer (ASA) message is used by this Diameter application.

This Diameter application does not make use of accounting. Hence, the Accounting-Request and the Accounting-Answer message is not used.

The DQP application uses two command codes as shown below.

The Diameter-PQ-Request (PQR) message, indicated by the Command-Code field set to TBD and the 'R' bit set in the Command Flags field, is sent by the Diameter Client to the Diameter server to query for parameters. This Diameter application builds on top of Diameter NASREQ.

::= < Diameter Header: TBD, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ Destination-Host ] [ NAS-Identifier ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [ NAS-Port-Type ] ... Diameter NASREQ defined AVPs ... { Device-Identity } * [ Requested-Info ] * [ AVP ] ]]>

The Diameter-PQ-Answer (PQA) message, indicated by the Command-Code field set to TBD and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-PQ-Request message. The Application-Id field in the Diameter message header MUST be set to DPQ Application-Id (value of TBD).

::= < Diameter Header: TBD, REQ, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } ... Diameter NASREQ defined AVPs ... { Device-Identity } * [ AVP ] ]]> In case of a successful processing of the request the desired AVPs as indicated in the Requested-Info AVPs are returned.

This document re-uses AVPs defined in Diameter NASREQ (RFC 4005 ). Additionally, the following AVPs are used as shown in the table below.

The IP-Address AVP (AVP Code TBD) is of type Address and contains IPv6 or IPv4 address of the device.

The Requested-Info AVP (AVP Code TBD) is of type grouped and is defined as shown below:

::= < AVP Header: TBD > { AVP-Code } [ Vendor-ID ] ]]>

The AVP-Code AVP (AVP Code TBD) is of type Integer32 and contains the Diameter AVP code.

The Vendor-ID AVP (AVP Code TBD) is of type Integer32 and contains the vendor id of a Diameter AVP.

This section defines new Result-Code values that MUST be supported by all Diameter implementations that conform to this specification.

Errors that fall within the Success category are used to inform a peer that a request has been successfully completed.

Errors that fall within the permanent failures category are used to inform the peer that the request failed and SHOULD NOT be attempted again.

The following tables present the AVPs defined in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. The table uses the following symbols: The AVP MUST NOT be present in the message. Zero or more instances of the AVP MAY be present in the message. Zero or one instance of the AVP MAY be present in the message. One instance of the AVP MUST be present in the message.

IANA is requested to allocate a command code value for the following new commands from the Command Code namespace defined in . See for the assignment of the namespace in this specification.

This specification requires IANA to register the following new AVPs from the AVP Code namespace defined in . Device-Identity IP-Address Requested-Info AVP-Code Vendor-ID The AVPs are defined in .

This specification requires IANA to allocate a new Diameter Application "Diameter Parameter Query (DPQ)" from the Application Identifier namespace defined in .

AAA servers MUST prevent exposure of information (particularly the mapping of IP address to the subscriber information like identity or some form of location information, which can be an invasion of the subscribers privacy) by employing access control techniques. A pre-requisity of this authorization step is authentication, which is provided by the Diameter base specification . Furthermore, it is recommended that a AAA server configuration is available to control the granularity of the information exchange to restrict the exposure of information to those attributes previously agreed on between the involved parties, namely the Diameter client, the Diameter server and the subscriber as the owner of the information. The latter aspect is particularly important since the distribution of information for a stated purpose requires explicit consent of the subscriber since is a regulatory requirement in many juristictions. Because of the strong security requirements stated above it is envisioned that the Diameter application described in this document is used only between two entities belonging to the same administrative domain. Distributed denial of service attacks against the Diameter by repeated requests from the Diameter client are not considered a threat since the Diameter client will be known to the Diameter server once cryptographic authentication, using TLS or IPsec as described in , is completed.