One document matched: draft-winterbottom-dime-param-query-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY RFC4005 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml'>
<!ENTITY RFC2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-winterbottom-dime-param-query-00.txt">
<front>
<title abbrev="Diameter Parameter Query">Diameter Parameter Query</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>FIN-02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="R." surname="Bellis" fullname="Ray Bellis">
<organization>Nominet UK</organization>
<address>
<postal>
<street>Edmund Halley Road</street>
<city>Oxford</city>
<code>OX4 4DQ</code>
<country>United Kingdom</country>
</postal>
<phone>+44 1865 332211</phone>
<email>ray.bellis@nominet.org.uk</email>
<uri>http://www.nominet.org.uk/</uri>
</address>
</author>
<date year="2009"/>
<area>Operations and Management Area</area>
<workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t>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 </t>
<t>
<xref target="arch"/> 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.</t>
<figure anchor="arch" title="Example Instantiation of involved Entities">
<artwork><![CDATA[
+--------+
|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 |
+------------+
]]></artwork>
</figure>
<!-- ====================================================================== -->
<section title="Application Identifiers">
<t>This specification defines a Diameter applications and their respective Application
Identifiers: </t>
<figure>
<artwork><![CDATA[
Diameter Parameter Query (DPQ) TBD by IANA
]]>
</artwork>
</figure>
<t>The DPQ Application Identifier is used when a Diameter client utilizes the Diameter
Parameter Query Request and Response messages. </t>
</section>
<!-- ====================================================================== -->
<section title="Session Management">
<t>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.</t>
</section>
<!-- ====================================================================== -->
<section title="Accounting">
<t>This Diameter application does not make use of accounting. Hence, the Accounting-Request
and the Accounting-Answer message is not used. </t>
</section>
<!-- ====================================================================== -->
<section anchor="Command-Code-Values" title="Command Codes">
<t>The DQP application uses two command codes as shown below. <figure anchor="cmd-eap"
title="Command Codes">
<artwork><![CDATA[
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
Diameter-PQ-Request PQR TBD This doc. DPQ
Diameter-PQ-Answer PQA TBD This doc. DPQ
]]></artwork>
</figure>
</t>
<section title="Diameter-PQ-Request">
<t>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. </t>
<t>
<figure>
<artwork><![CDATA[
<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 ]
]]></artwork>
</figure>
</t>
</section>
<section title="Diameter-PQ-Answer">
<t>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). </t>
<t>
<figure>
<artwork><![CDATA[
<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 ]
]]></artwork>
</figure>
</t>
<t>In case of a successful processing of the request the desired AVPs as indicated in the
Requested-Info AVPs are returned. </t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="avps" title="AVPs">
<t>This document re-uses AVPs defined in Diameter NASREQ (RFC 4005 <xref target="RFC4005"
/>). Additionally, the following AVPs are used as shown in the table below. </t>
<t>
<figure title="AVPs for Mobile IPv6 IKE Application">
<artwork><![CDATA[
+--------------------+
| 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 |
+-----------------------------------------+----+---+------+----+----+
]]></artwork>
</figure>
</t>
<section title="IP-Address AVP">
<t>The IP-Address AVP (AVP Code TBD) is of type Address and contains IPv6 or IPv4 address
of the device. </t>
</section>
<section title="Requested-Info AVP">
<t>The Requested-Info AVP (AVP Code TBD) is of type grouped and is defined as shown below: <figure>
<artwork><![CDATA[
<Requested-Info> ::= < AVP Header: TBD >
{ AVP-Code }
[ Vendor-ID ]
]]></artwork>
</figure>
</t>
</section>
<section title="AVP-Code AVP">
<t>The AVP-Code AVP (AVP Code TBD) is of type Integer32 and contains the Diameter AVP
code. </t>
</section>
<section title="Vendor-ID AVP">
<t>The Vendor-ID AVP (AVP Code TBD) is of type Integer32 and contains the vendor id of a
Diameter AVP. </t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="result" title="Result-Code AVP Values">
<t>This section defines new Result-Code <xref target="RFC3588"/> values that MUST be
supported by all Diameter implementations that conform to this specification.</t>
<section title="Success">
<t>Errors that fall within the Success category are used to inform a peer that a request
has been successfully completed. </t>
<!--
<t>
<list style="hanging">
<t hangText="DIAMETER_SUCCESS_RELOCATE_HA (Status Code TBD)"><vspace
blankLines="1"/> This result code is used by the Diameter
server to inform the HA that the MN MUST be
switched to another HA.
</t>
</list>
</t>
-->
</section>
<section title="Permanent Failures">
<t>Errors that fall within the permanent failures category are used to inform the peer
that the request failed and SHOULD NOT be attempted again. </t>
<!--
<t>
<list style="hanging">
t hangText="DIAMETER_ERROR_END_TO_END_MIP6_KEY_ENCRYPTION (Status Code TBD)"><vspace
blankLines="1"/> This error code is used by the Diameter server to inform the peer that
the requested Mobile IPv6 session keys could not be delivered via a security
association.
<vspace blankLines="1"/>
</t
<t hangText="DIAMETER_ERROR_MIP6_AUTH_MODE (Status Code
TBD)"><vspace blankLines="1"/> This error code is used
by the Diameter server to inform the peer that the
requested Mobile IPv6 Authentication Protocol usage
mode is not supported.
</t>
</list>
</t>
-->
</section>
</section>
<!-- ====================================================================== -->
<section title="AVP Occurrence Tables">
<t>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.</t>
<t>The table uses the following symbols:</t>
<t>
<list style="hanging">
<t hangText="0:"><vspace blankLines="1"/>The AVP MUST NOT be present in the
message.<vspace blankLines="1"/></t>
<t hangText="0+:"><vspace blankLines="1"/>Zero or more instances of the AVP MAY be
present in the message.<vspace blankLines="1"/></t>
<t hangText="0-1:"><vspace blankLines="1"/>Zero or one instance of the AVP MAY be
present in the message.<vspace blankLines="1"/></t>
<t hangText="1:"><vspace blankLines="1"/>One instance of the AVP MUST be present in the
message. </t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section title="PQR/PQA AVP/Command-Code Table">
<t>
<figure>
<artwork><![CDATA[
+-----------------------+
| Command-Code |
|-----+-----+-----------+
AVP Name | PQR | PQA |
-------------------------------|-----+-----+
Device-Identity | 1 | 1 |
Requested-Info | 0+ | 0 |
+-----+-----+
]]></artwork>
</figure>
</t>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<section title="Command Codes">
<t> IANA is requested to allocate a command code value for the following new commands from
the Command Code namespace defined in <xref target="RFC3588"/>. See <xref
target="Command-Code-Values"/> for the assignment of the namespace in this
specification. </t>
<figure>
<artwork><![CDATA[
Command Code | Value
-----------------------------------+------
Diameter-PQ-Request (PQR) | TBD
Diameter-PQ-Answer (PQA) | TBD
]]>
</artwork>
</figure>
</section>
<section title="AVP Codes">
<t> This specification requires IANA to register the following new AVPs from the AVP Code
namespace defined in <xref target="RFC3588"/>.<vspace blankLines="1"/>
<list style="symbols">
<t>Device-Identity</t>
<t>IP-Address</t>
<t>Requested-Info</t>
<t>AVP-Code</t>
<t>Vendor-ID</t>
</list><vspace blankLines="1"/>The AVPs are defined in <xref target="avps"/>. </t>
</section>
</section>
<section title="Application Identifier">
<t> This specification requires IANA to allocate a new Diameter Application "Diameter
Parameter Query (DPQ)" from the Application Identifier namespace defined in <xref
target="RFC3588"/>. </t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="example" title="Example">
<t>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 <xref target="RFC2865"/> to
be returned. </t>
<t>
<figure anchor="example-fig" title="Example Exchange">
<artwork><![CDATA[
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(...) |
|<----------------------------------------------------------------|
| |
]]></artwork>
</figure>
</t>
</section>
<!-- ====================================================================== -->
<section anchor="SecurityConsiderations" title="Security Considerations">
<t> 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 <xref target="RFC3588"/>. 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 <xref target="RFC3588"
/>, is completed. </t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>Add your name here. </t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References"> &RFC3588; &RFC2119; &RFC4005; </references>
<references title="Informative References"> &RFC2865; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:33:59 |