Diameter Parameter Query
draft-winterbottom-dime-param-query-01.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 29, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

In an emergency services environment a Location Information Server (LIS) receives requests from end hosts, SIP proxies or Public Safety Answering Points (PSAPs). When receiving these requests a LIS has to perform a location determination procedure that depends on the specific network deployment. In any case, an interation with other network elements is needed, particularly with AAA servers, that store information about the current attachment of the end host.

This document descirbes a Diameter application, called Diameter Parameter Query, which allows a Location Information Server to interact with a Diameter server to obtain information needed for the location determination procedure. The style of the described Diameter application offers flexibility for different deployments.

Table of Contents

1.  Introduction
    1.1.  Application Identifiers
    1.2.  Session Management
    1.3.  Accounting
    1.4.  Command Codes
        1.4.1.  Diameter-PQ-Request
        1.4.2.  Diameter-PQ-Answer
    1.5.  AVPs
        1.5.1.  IP-Address AVP
        1.5.2.  Requested-Info AVP
        1.5.3.  AVP-Code AVP
        1.5.4.  Vendor-ID AVP
    1.6.  Result-Code AVP Values
        1.6.1.  Success
        1.6.2.  Permanent Failures
    1.7.  AVP Occurrence Tables
    1.8.  PQR/PQA AVP/Command-Code Table
    1.9.  IANA Considerations
        1.9.1.  Command Codes
        1.9.2.  AVP Codes
    1.10.  Application Identifier
2.  Example
3.  Security Considerations
4.  Acknowledgements
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Authors' Addresses

1.  Introduction

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

Figure 1 (Example Instantiation of involved Entities) 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.

                                     +--------+
                                     |Diameter|
                                     |Server  |
                                     +--------+
                                         ^
                                Back-End | Diameter Parameter
                                Protocol | Query / Response
                                Support  | Interaction
                                         | (this document)
                                         v
 +------------+                      +---------------+
 | Emergency  |  Front-End Protocol  |Location Server|
 | Service    |<-------------------->|Diameter Client|
 | Routing    |  Example: HELD       +---------------+
 | Proxy /    |
 | Public     |
 | Safety     |
 | Answering  |
 | Point      |
 +------------+

1.1.  Application Identifiers

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

   Diameter Parameter Query   (DPQ)  TBD by IANA

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

1.2.  Session Management

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.

1.3.  Accounting

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

1.4.  Command Codes

The DQP application uses two command codes as shown below.

Command-Name          Abbrev. Code  Reference    Application
---------------------------------------------------------------------
Diameter-PQ-Request    PQR     TBD  This doc.    DPQ
Diameter-PQ-Answer     PQA     TBD  This doc.    DPQ

1.4.1.  Diameter-PQ-Request

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-PQ-Request> ::= < 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 ]

1.4.2.  Diameter-PQ-Answer

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-PQ-Answer> ::= < 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.

1.5.  AVPs

This document re-uses AVPs defined in Diameter NASREQ (RFC 4005 [RFC4005] (Calhoun, P., Zorn, G., Spence, D., and D. Mitton, “Diameter Network Access Server Application,” August 2005.)). Additionally, the following AVPs are used as shown in the table below.

                                          +--------------------+
                                          |   AVP Flag Rules   |
                                          +----+---+------+----+----+
                 AVP  Defined             |    |   |SHOULD|MUST|MAY |
 Attribute Name  Code in       Value Type |MUST|MAY| NOT  | NOT|Encr|
+-----------------------------------------+----+---+------+----+----+
|Device-Identity TBD  TBD      Grouped    |  M | P |      | V  | Y  |
+-----------------------------------------+----+---+------+----+----+
|User-Name       1    RFC3588  UTF8String |  M | P |      | V  | Y  |
+-----------------------------------------+----+---+------+----+----+
|IP-Address      TBD  TBD      Address    |  M | P |      | V  | Y  |
+-----------------------------------------+----+---+------+----+----+
|Requested-Info  TBD  TBD      Grouped    |  M | P |      | V  | Y  |
+-----------------------------------------+----+---+------+----+----+
|AVP-Code        TBD  TBD      Integer32  |  M | P |      | V  | Y  |
+-----------------------------------------+----+---+------+----+----+
|Vendor-ID       TBD  TBD      Integer32  |  M | P |      | V  | Y  |
+-----------------------------------------+----+---+------+----+----+

1.5.1.  IP-Address AVP

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

1.5.2.  Requested-Info AVP

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

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

1.5.3.  AVP-Code AVP

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

1.5.4.  Vendor-ID AVP

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

1.6.  Result-Code AVP Values

This section defines new Result-Code [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) values that MUST be supported by all Diameter implementations that conform to this specification.

1.6.1.  Success

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

1.6.2.  Permanent Failures

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

1.7.  AVP Occurrence Tables

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:

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.

1:

One instance of the AVP MUST be present in the message.

1.8.  PQR/PQA AVP/Command-Code Table

                                  +-----------------------+
                                  |     Command-Code      |
                                  |-----+-----+-----------+
   AVP Name                       | PQR | PQA |
   -------------------------------|-----+-----+
   Device-Identity                |  1  |  1  |
   Requested-Info                 |  0+ |  0  |
                                  +-----+-----+

1.9.  IANA Considerations

1.9.1.  Command Codes

IANA is requested to allocate a command code value for the following new commands from the Command Code namespace defined in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). See Section 1.4 (Command Codes) for the assignment of the namespace in this specification.

Command Code                       | Value
-----------------------------------+------
Diameter-PQ-Request (PQR)          | TBD
Diameter-PQ-Answer (PQA)           | TBD

1.9.2.  AVP Codes

This specification requires IANA to register the following new AVPs from the AVP Code namespace defined in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).

• Device-Identity
• IP-Address
• Requested-Info
• AVP-Code
• Vendor-ID

The AVPs are defined in Section 1.5 (AVPs).

1.10.  Application Identifier

This specification requires IANA to allocate a new Diameter Application "Diameter Parameter Query (DPQ)" from the Application Identifier namespace defined in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).

2.  Example

The following example shows a request with an IP address and User-Name as the device identity asking for the Callback-Number AVP defined in RFC 2865 [RFC2865] (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.) to be returned.

Diameter                                                    Diameter
Client                                                        Server
 |                                                                 |
 |  Diameter-PQ-Request                                            |
 |  Device-Identity=(IP-Address=...,User-Name=...)                 |
 |  Requested-Info=(AVP-Code=19)                                   |
 |---------------------------------------------------------------->|
 |                                                                 |
 |                                                                 |
 |                Diameter-PQ-Answer                               |
 |                Device-Identity=(IP-Address=...)                 |
 |                Callback-Number(...)                             |
 |<----------------------------------------------------------------|
 |                                                                 |

3.  Security Considerations

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 [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). 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 [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.), is completed.

4.  Acknowledgements

Add your name here.

5.  References

5.1. Normative References

5.2. Informative References

Authors' Addresses