idnits 2.17.00 (12 Aug 2021) /tmp/idnits61098/draft-winterbottom-dime-param-query-00.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 16, 2009) is 4599 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 417, 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 19, 2010 R. Bellis 7 Nominet UK 8 October 16, 2009 10 Diameter Parameter Query 11 draft-winterbottom-dime-param-query-00.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 19, 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 AVPs for Mobile IPv6 IKE Application 248 1.5.1. IP-Address AVP 250 The IP-Address AVP (AVP Code TBD) is of type Address and contains 251 IPv6 or IPv4 address of the device. 253 1.5.2. Requested-Info AVP 255 The Requested-Info AVP (AVP Code TBD) is of type grouped and is 256 defined as shown below: 258 ::= < AVP Header: TBD > 259 { AVP-Code } 260 [ Vendor-ID ] 262 1.5.3. AVP-Code AVP 264 The AVP-Code AVP (AVP Code TBD) is of type Integer32 and contains the 265 Diameter AVP code. 267 1.5.4. Vendor-ID AVP 269 The Vendor-ID AVP (AVP Code TBD) is of type Integer32 and contains 270 the vendor id of a Diameter AVP. 272 1.6. Result-Code AVP Values 274 This section defines new Result-Code [RFC3588] values that MUST be 275 supported by all Diameter implementations that conform to this 276 specification. 278 1.6.1. Success 280 Errors that fall within the Success category are used to inform a 281 peer that a request has been successfully completed. 283 1.6.2. Permanent Failures 285 Errors that fall within the permanent failures category are used to 286 inform the peer that the request failed and SHOULD NOT be attempted 287 again. 289 1.7. AVP Occurrence Tables 291 The following tables present the AVPs defined in this document and 292 their occurrences in Diameter messages. Note that AVPs that can only 293 be present within a Grouped AVP are not represented in this table. 295 The table uses the following symbols: 297 0: 299 The AVP MUST NOT be present in the message. 301 0+: 303 Zero or more instances of the AVP MAY be present in the message. 305 0-1: 307 Zero or one instance of the AVP MAY be present in the message. 309 1: 311 One instance of the AVP MUST be present in the message. 313 1.8. PQR/PQA AVP/Command-Code Table 315 +-----------------------+ 316 | Command-Code | 317 |-----+-----+-----------+ 318 AVP Name | PQR | PQA | 319 -------------------------------|-----+-----+ 320 Device-Identity | 1 | 1 | 321 Requested-Info | 0+ | 0 | 322 +-----+-----+ 324 1.9. IANA Considerations 326 1.9.1. Command Codes 328 IANA is requested to allocate a command code value for the following 329 new commands from the Command Code namespace defined in [RFC3588]. 330 See Section 1.4 for the assignment of the namespace in this 331 specification. 333 Command Code | Value 334 -----------------------------------+------ 335 Diameter-PQ-Request (PQR) | TBD 336 Diameter-PQ-Answer (PQA) | TBD 338 1.9.2. AVP Codes 340 This specification requires IANA to register the following new AVPs 341 from the AVP Code namespace defined in [RFC3588]. 343 o Device-Identity 345 o IP-Address 347 o Requested-Info 349 o AVP-Code 351 o Vendor-ID 353 The AVPs are defined in Section 1.5. 355 1.10. Application Identifier 357 This specification requires IANA to allocate a new Diameter 358 Application "Diameter Parameter Query (DPQ)" from the Application 359 Identifier namespace defined in [RFC3588]. 361 2. Example 363 The following example shows a request with an IP address and User- 364 Name as the device identity asking for the Callback-Number AVP 365 defined in RFC 2865 [RFC2865] to be returned. 367 Diameter Diameter 368 Client Server 369 | | 370 | Diameter-PQ-Request | 371 | Device-Identity=(IP-Address=...,User-Name=...) | 372 | Requested-Info=(AVP-Code=19) | 373 |---------------------------------------------------------------->| 374 | | 375 | | 376 | Diameter-PQ-Answer | 377 | Device-Identity=(IP-Address=...) | 378 | Callback-Number(...) | 379 |<----------------------------------------------------------------| 380 | | 382 Figure 3: Example Exchange 384 3. Security Considerations 386 AAA servers MUST prevent exposure of information (particularly the 387 mapping of IP address to the subscriber information like identity or 388 some form of location information, which can be an invasion of the 389 subscribers privacy) by employing access control techniques. A pre- 390 requisity of this authorization step is authentication, which is 391 provided by the Diameter base specification [RFC3588]. Furthermore, 392 it is recommended that a AAA server configuration is available to 393 control the granularity of the information exchange to restrict the 394 exposure of information to those attributes previously agreed on 395 between the involved parties, namely the Diameter client, the 396 Diameter server and the subscriber as the owner of the information. 397 The latter aspect is particularly important since the distribution of 398 information for a stated purpose requires explicit consent of the 399 subscriber since is a regulatory requirement in many juristictions. 400 Because of the strong security requirements stated above it is 401 envisioned that the Diameter application described in this document 402 is used only between two entities belonging to the same 403 administrative domain. Distributed denial of service attacks against 404 the Diameter by repeated requests from the Diameter client are not 405 considered a threat since the Diameter client will be known to the 406 Diameter server once cryptographic authentication, using TLS or IPsec 407 as described in [RFC3588], is completed. 409 4. Acknowledgements 411 Add your name here. 413 5. References 415 5.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 421 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 423 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 424 "Diameter Network Access Server Application", RFC 4005, 425 August 2005. 427 5.2. Informative References 429 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 430 "Remote Authentication Dial In User Service (RADIUS)", 431 RFC 2865, June 2000. 433 Authors' Addresses 435 James Winterbottom 436 Andrew Corporation 437 Andrew Building (39) 438 University of Wollongong, NSW 2500 439 AU 441 Email: james.winterbottom@andrew.com 443 Hannes Tschofenig 444 Nokia Siemens Networks 445 Linnoitustie 6 446 Espoo FIN-02600 447 Finland 449 Phone: +358 (50) 4871445 450 Email: Hannes.Tschofenig@gmx.net 451 URI: http://www.tschofenig.priv.at 453 Ray Bellis 454 Nominet UK 455 Edmund Halley Road 456 Oxford OX4 4DQ 457 United Kingdom 459 Phone: +44 1865 332211 460 Email: ray.bellis@nominet.org.uk 461 URI: http://www.nominet.org.uk/