Diameter Maintenance and J. Winterbottom
Extensions (DIME) Andrew Corporation
Internet-Draft H. Tschofenig
Intended status: Standards Track Nokia Siemens Networks
Expires: April 29, 2010 R. Bellis
Nominet UK
October 26, 2009
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.
Winterbottom, et al. Expires April 29, 2010 [Page 1]
Internet-Draft Diameter Parameter Query October 2009
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Application Identifiers . . . . . . . . . . . . . . . . . 3
1.2. Session Management . . . . . . . . . . . . . . . . . . . . 4
1.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Command Codes . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1. Diameter-PQ-Request . . . . . . . . . . . . . . . . . 4
1.4.2. Diameter-PQ-Answer . . . . . . . . . . . . . . . . . . 5
1.5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1. IP-Address AVP . . . . . . . . . . . . . . . . . . . . 6
1.5.2. Requested-Info AVP . . . . . . . . . . . . . . . . . . 6
1.5.3. AVP-Code AVP . . . . . . . . . . . . . . . . . . . . . 6
1.5.4. Vendor-ID AVP . . . . . . . . . . . . . . . . . . . . 6
1.6. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 7
1.6.1. Success . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.2. Permanent Failures . . . . . . . . . . . . . . . . . . 7
1.7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . 7
1.8. PQR/PQA AVP/Command-Code Table . . . . . . . . . . . . . . 8
1.9. IANA Considerations . . . . . . . . . . . . . . . . . . . 8
1.9.1. Command Codes . . . . . . . . . . . . . . . . . . . . 8
1.9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . 8
1.10. Application Identifier . . . . . . . . . . . . . . . . . . 9
2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . . 13
5.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Winterbottom, et al. Expires April 29, 2010 [Page 2]
Internet-Draft Diameter Parameter Query October 2009
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 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 |
+------------+
Figure 1: Example Instantiation of involved Entities
1.1. Application Identifiers
This specification defines a Diameter applications and their
respective Application Identifiers:
Diameter Parameter Query (DPQ) TBD by IANA
Winterbottom, et al. Expires April 29, 2010 [Page 3]
Internet-Draft Diameter Parameter Query October 2009
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
Figure 2: Command Codes
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.
Winterbottom, et al. Expires April 29, 2010 [Page 4]
Internet-Draft Diameter Parameter Query October 2009
<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]). Additionally, the following AVPs are used as shown in
Winterbottom, et al. Expires April 29, 2010 [Page 5]
Internet-Draft Diameter Parameter Query October 2009
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.
Winterbottom, et al. Expires April 29, 2010 [Page 6]
Internet-Draft Diameter Parameter Query October 2009
1.6. Result-Code AVP Values
This section defines new Result-Code [RFC3588] 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.
Winterbottom, et al. Expires April 29, 2010 [Page 7]
Internet-Draft Diameter Parameter Query October 2009
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].
See Section 1.4 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].
o Device-Identity
o IP-Address
o Requested-Info
o AVP-Code
o Vendor-ID
The AVPs are defined in Section 1.5.
Winterbottom, et al. Expires April 29, 2010 [Page 8]
Internet-Draft Diameter Parameter Query October 2009
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].
Winterbottom, et al. Expires April 29, 2010 [Page 9]
Internet-Draft Diameter Parameter Query October 2009
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] 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(...) |
|<----------------------------------------------------------------|
| |
Figure 3: Example Exchange
Winterbottom, et al. Expires April 29, 2010 [Page 10]
Internet-Draft Diameter Parameter Query October 2009
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]. 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], is completed.
Winterbottom, et al. Expires April 29, 2010 [Page 11]
Internet-Draft Diameter Parameter Query October 2009
4. Acknowledgements
Add your name here.
Winterbottom, et al. Expires April 29, 2010 [Page 12]
Internet-Draft Diameter Parameter Query October 2009
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
5.2. Informative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
Winterbottom, et al. Expires April 29, 2010 [Page 13]
Internet-Draft Diameter Parameter Query October 2009
Authors' Addresses
James Winterbottom
Andrew Corporation
Andrew Building (39)
University of Wollongong, NSW 2500
AU
Email: james.winterbottom@andrew.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo FIN-02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Ray Bellis
Nominet UK
Edmund Halley Road
Oxford OX4 4DQ
United Kingdom
Phone: +44 1865 332211
Email: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Winterbottom, et al. Expires April 29, 2010 [Page 14]