idnits 2.17.1 draft-winterbottom-dime-param-query-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 26, 2009) is 5296 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 415, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Winterbottom 3 Extensions (DIME) Andrew Corporation 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: April 29, 2010 R. Bellis 7 Nominet UK 8 October 26, 2009 10 Diameter Parameter Query 11 draft-winterbottom-dime-param-query-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 29, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 In an emergency services environment a Location Information Server 50 (LIS) receives requests from end hosts, SIP proxies or Public Safety 51 Answering Points (PSAPs). When receiving these requests a LIS has to 52 perform a location determination procedure that depends on the 53 specific network deployment. In any case, an interation with other 54 network elements is needed, particularly with AAA servers, that store 55 information about the current attachment of the end host. 57 This document descirbes a Diameter application, called Diameter 58 Parameter Query, which allows a Location Information Server to 59 interact with a Diameter server to obtain information needed for the 60 location determination procedure. The style of the described 61 Diameter application offers flexibility for different deployments. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Application Identifiers . . . . . . . . . . . . . . . . . 3 67 1.2. Session Management . . . . . . . . . . . . . . . . . . . . 4 68 1.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.4. Command Codes . . . . . . . . . . . . . . . . . . . . . . 4 70 1.4.1. Diameter-PQ-Request . . . . . . . . . . . . . . . . . 4 71 1.4.2. Diameter-PQ-Answer . . . . . . . . . . . . . . . . . . 5 72 1.5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.5.1. IP-Address AVP . . . . . . . . . . . . . . . . . . . . 6 74 1.5.2. Requested-Info AVP . . . . . . . . . . . . . . . . . . 6 75 1.5.3. AVP-Code AVP . . . . . . . . . . . . . . . . . . . . . 6 76 1.5.4. Vendor-ID AVP . . . . . . . . . . . . . . . . . . . . 6 77 1.6. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 7 78 1.6.1. Success . . . . . . . . . . . . . . . . . . . . . . . 7 79 1.6.2. Permanent Failures . . . . . . . . . . . . . . . . . . 7 80 1.7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . 7 81 1.8. PQR/PQA AVP/Command-Code Table . . . . . . . . . . . . . . 8 82 1.9. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 83 1.9.1. Command Codes . . . . . . . . . . . . . . . . . . . . 8 84 1.9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . 8 85 1.10. Application Identifier . . . . . . . . . . . . . . . . . . 9 86 2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 89 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 5.1. Normative References . . . . . . . . . . . . . . . . . . . 13 91 5.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 The AAA backend infrastructure stores information about various 97 device related interactions, such as network attachments, accounting 98 streams, etc. In certain cases, parts of this information needs to 99 be shared with other entities in the operators network to provide 100 smooth network operation. An example of this interaction is when a 101 Location Server is deployed in an IP-based network and needs to 102 obtain information about the users point of attachment to make 103 location information for emergency services. This document describes 104 how such a Diameter based interface can help a location server to 105 query inforation from the backend infrastructure. In particular, it 106 allows the query to contain the IP address of the device and to 107 request information about 109 Figure 1 shows an example of how the Diameter interface used in this 110 document can be used by a Location Server receiving a request to 111 query a Diameter Server. 113 +--------+ 114 |Diameter| 115 |Server | 116 +--------+ 117 ^ 118 Back-End | Diameter Parameter 119 Protocol | Query / Response 120 Support | Interaction 121 | (this document) 122 v 123 +------------+ +---------------+ 124 | Emergency | Front-End Protocol |Location Server| 125 | Service |<-------------------->|Diameter Client| 126 | Routing | Example: HELD +---------------+ 127 | Proxy / | 128 | Public | 129 | Safety | 130 | Answering | 131 | Point | 132 +------------+ 134 Figure 1: Example Instantiation of involved Entities 136 1.1. Application Identifiers 138 This specification defines a Diameter applications and their 139 respective Application Identifiers: 141 Diameter Parameter Query (DPQ) TBD by IANA 143 The DPQ Application Identifier is used when a Diameter client 144 utilizes the Diameter Parameter Query Request and Response messages. 146 1.2. Session Management 148 The Diameter server is stateless in the protocol interaction 149 described by this document. As such, the Session-Termination-Request 150 (STR), the Session-Termination-Answer (STA), Abort-Session-Request 151 (ASR) nor the Abort-Session-Answer (ASA) message is used by this 152 Diameter application. 154 1.3. Accounting 156 This Diameter application does not make use of accounting. Hence, 157 the Accounting-Request and the Accounting-Answer message is not used. 159 1.4. Command Codes 161 The DQP application uses two command codes as shown below. 163 Command-Name Abbrev. Code Reference Application 164 --------------------------------------------------------------------- 165 Diameter-PQ-Request PQR TBD This doc. DPQ 166 Diameter-PQ-Answer PQA TBD This doc. DPQ 168 Figure 2: Command Codes 170 1.4.1. Diameter-PQ-Request 172 The Diameter-PQ-Request (PQR) message, indicated by the Command-Code 173 field set to TBD and the 'R' bit set in the Command Flags field, is 174 sent by the Diameter Client to the Diameter server to query for 175 parameters. This Diameter application builds on top of Diameter 176 NASREQ. 178 ::= < Diameter Header: TBD, REQ, PXY > 179 < Session-Id > 180 { Auth-Application-Id } 181 { Origin-Host } 182 { Origin-Realm } 183 { Destination-Realm } 184 { Auth-Request-Type } 185 [ Destination-Host ] 186 [ NAS-Identifier ] 187 [ NAS-IP-Address ] 188 [ NAS-IPv6-Address ] 189 [ NAS-Port-Type ] 190 ... 191 Diameter NASREQ defined AVPs 192 ... 193 { Device-Identity } 194 * [ Requested-Info ] 195 * [ AVP ] 197 1.4.2. Diameter-PQ-Answer 199 The Diameter-PQ-Answer (PQA) message, indicated by the Command-Code 200 field set to TBD and 'R' bit cleared in the Command Flags field, is 201 sent in response to the Diameter-PQ-Request message. The 202 Application-Id field in the Diameter message header MUST be set to 203 DPQ Application-Id (value of TBD). 205 ::= < Diameter Header: TBD, REQ, PXY > 206 < Session-Id > 207 { Auth-Application-Id } 208 { Auth-Request-Type } 209 { Result-Code } 210 { Origin-Host } 211 { Origin-Realm } 212 ... 213 Diameter NASREQ defined AVPs 214 ... 215 { Device-Identity } 216 * [ AVP ] 218 In case of a successful processing of the request the desired AVPs as 219 indicated in the Requested-Info AVPs are returned. 221 1.5. AVPs 223 This document re-uses AVPs defined in Diameter NASREQ (RFC 4005 224 [RFC4005]). Additionally, the following AVPs are used as shown in 225 the table below. 227 +--------------------+ 228 | AVP Flag Rules | 229 +----+---+------+----+----+ 230 AVP Defined | | |SHOULD|MUST|MAY | 231 Attribute Name Code in Value Type |MUST|MAY| NOT | NOT|Encr| 232 +-----------------------------------------+----+---+------+----+----+ 233 |Device-Identity TBD TBD Grouped | M | P | | V | Y | 234 +-----------------------------------------+----+---+------+----+----+ 235 |User-Name 1 RFC3588 UTF8String | M | P | | V | Y | 236 +-----------------------------------------+----+---+------+----+----+ 237 |IP-Address TBD TBD Address | M | P | | V | Y | 238 +-----------------------------------------+----+---+------+----+----+ 239 |Requested-Info TBD TBD Grouped | M | P | | V | Y | 240 +-----------------------------------------+----+---+------+----+----+ 241 |AVP-Code TBD TBD Integer32 | M | P | | V | Y | 242 +-----------------------------------------+----+---+------+----+----+ 243 |Vendor-ID TBD TBD Integer32 | M | P | | V | Y | 244 +-----------------------------------------+----+---+------+----+----+ 246 1.5.1. IP-Address AVP 248 The IP-Address AVP (AVP Code TBD) is of type Address and contains 249 IPv6 or IPv4 address of the device. 251 1.5.2. Requested-Info AVP 253 The Requested-Info AVP (AVP Code TBD) is of type grouped and is 254 defined as shown below: 256 ::= < AVP Header: TBD > 257 { AVP-Code } 258 [ Vendor-ID ] 260 1.5.3. AVP-Code AVP 262 The AVP-Code AVP (AVP Code TBD) is of type Integer32 and contains the 263 Diameter AVP code. 265 1.5.4. Vendor-ID AVP 267 The Vendor-ID AVP (AVP Code TBD) is of type Integer32 and contains 268 the vendor id of a Diameter AVP. 270 1.6. Result-Code AVP Values 272 This section defines new Result-Code [RFC3588] values that MUST be 273 supported by all Diameter implementations that conform to this 274 specification. 276 1.6.1. Success 278 Errors that fall within the Success category are used to inform a 279 peer that a request has been successfully completed. 281 1.6.2. Permanent Failures 283 Errors that fall within the permanent failures category are used to 284 inform the peer that the request failed and SHOULD NOT be attempted 285 again. 287 1.7. AVP Occurrence Tables 289 The following tables present the AVPs defined in this document and 290 their occurrences in Diameter messages. Note that AVPs that can only 291 be present within a Grouped AVP are not represented in this table. 293 The table uses the following symbols: 295 0: 297 The AVP MUST NOT be present in the message. 299 0+: 301 Zero or more instances of the AVP MAY be present in the message. 303 0-1: 305 Zero or one instance of the AVP MAY be present in the message. 307 1: 309 One instance of the AVP MUST be present in the message. 311 1.8. PQR/PQA AVP/Command-Code Table 313 +-----------------------+ 314 | Command-Code | 315 |-----+-----+-----------+ 316 AVP Name | PQR | PQA | 317 -------------------------------|-----+-----+ 318 Device-Identity | 1 | 1 | 319 Requested-Info | 0+ | 0 | 320 +-----+-----+ 322 1.9. IANA Considerations 324 1.9.1. Command Codes 326 IANA is requested to allocate a command code value for the following 327 new commands from the Command Code namespace defined in [RFC3588]. 328 See Section 1.4 for the assignment of the namespace in this 329 specification. 331 Command Code | Value 332 -----------------------------------+------ 333 Diameter-PQ-Request (PQR) | TBD 334 Diameter-PQ-Answer (PQA) | TBD 336 1.9.2. AVP Codes 338 This specification requires IANA to register the following new AVPs 339 from the AVP Code namespace defined in [RFC3588]. 341 o Device-Identity 343 o IP-Address 345 o Requested-Info 347 o AVP-Code 349 o Vendor-ID 351 The AVPs are defined in Section 1.5. 353 1.10. Application Identifier 355 This specification requires IANA to allocate a new Diameter 356 Application "Diameter Parameter Query (DPQ)" from the Application 357 Identifier namespace defined in [RFC3588]. 359 2. Example 361 The following example shows a request with an IP address and User- 362 Name as the device identity asking for the Callback-Number AVP 363 defined in RFC 2865 [RFC2865] to be returned. 365 Diameter Diameter 366 Client Server 367 | | 368 | Diameter-PQ-Request | 369 | Device-Identity=(IP-Address=...,User-Name=...) | 370 | Requested-Info=(AVP-Code=19) | 371 |---------------------------------------------------------------->| 372 | | 373 | | 374 | Diameter-PQ-Answer | 375 | Device-Identity=(IP-Address=...) | 376 | Callback-Number(...) | 377 |<----------------------------------------------------------------| 378 | | 380 Figure 3: Example Exchange 382 3. Security Considerations 384 AAA servers MUST prevent exposure of information (particularly the 385 mapping of IP address to the subscriber information like identity or 386 some form of location information, which can be an invasion of the 387 subscribers privacy) by employing access control techniques. A pre- 388 requisity of this authorization step is authentication, which is 389 provided by the Diameter base specification [RFC3588]. Furthermore, 390 it is recommended that a AAA server configuration is available to 391 control the granularity of the information exchange to restrict the 392 exposure of information to those attributes previously agreed on 393 between the involved parties, namely the Diameter client, the 394 Diameter server and the subscriber as the owner of the information. 395 The latter aspect is particularly important since the distribution of 396 information for a stated purpose requires explicit consent of the 397 subscriber since is a regulatory requirement in many juristictions. 398 Because of the strong security requirements stated above it is 399 envisioned that the Diameter application described in this document 400 is used only between two entities belonging to the same 401 administrative domain. Distributed denial of service attacks against 402 the Diameter by repeated requests from the Diameter client are not 403 considered a threat since the Diameter client will be known to the 404 Diameter server once cryptographic authentication, using TLS or IPsec 405 as described in [RFC3588], is completed. 407 4. Acknowledgements 409 Add your name here. 411 5. References 413 5.1. Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 419 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 421 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 422 "Diameter Network Access Server Application", RFC 4005, 423 August 2005. 425 5.2. Informative References 427 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 428 "Remote Authentication Dial In User Service (RADIUS)", 429 RFC 2865, June 2000. 431 Authors' Addresses 433 James Winterbottom 434 Andrew Corporation 435 Andrew Building (39) 436 University of Wollongong, NSW 2500 437 AU 439 Email: james.winterbottom@andrew.com 441 Hannes Tschofenig 442 Nokia Siemens Networks 443 Linnoitustie 6 444 Espoo FIN-02600 445 Finland 447 Phone: +358 (50) 4871445 448 Email: Hannes.Tschofenig@gmx.net 449 URI: http://www.tschofenig.priv.at 451 Ray Bellis 452 Nominet UK 453 Edmund Halley Road 454 Oxford OX4 4DQ 455 United Kingdom 457 Phone: +44 1865 332211 458 Email: ray.bellis@nominet.org.uk 459 URI: http://www.nominet.org.uk/