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