idnits 2.17.1 draft-ietf-dime-extended-naptr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC3588, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 4, 2010) is 5105 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) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and M. Jones 3 Extensions (DIME) Bridgewater Systems 4 Internet-Draft J. Korhonen 5 Updates: 3588 (if approved) Nokia Siemens Networks 6 Intended status: Standards Track May 4, 2010 7 Expires: November 5, 2010 9 Diameter Extended NAPTR 10 draft-ietf-dime-extended-naptr-01 12 Abstract 14 This document describes an extended format for the S-NAPTR 15 Application Service Tag used in dynamic Diameter agent discovery. 16 The extended format allows NAPTR queries to contain Diameter 17 Application-Id information. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on November 5, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . . 4 79 4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 81 5.1. IETF Diameter Application Service Tags . . . . . . . . . . 6 82 5.2. Vendor-Specific Diameter Application Service Tags . . . . . 7 83 5.3. Diameter Application Protocol Tags . . . . . . . . . . . . 7 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 The Diameter base protocol [RFC3588] specifies three mechanisms for 93 the Diameter peer discovery. One of these involves the Diameter 94 implementation performing a NAPTR query [RFC3403] for a server in a 95 particular realm. These NAPTR records provide a mapping from a 96 domain, to the SRV record [RFC2782] or A/AAAA record 97 [RFC1035][RFC3596] for contacting a server with the specific 98 transport protocol in the NAPTR services field. 100 The extended NAPTR usage for Diameter peer discovery defined by this 101 document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic 102 Delegation Discovery System (DDDS) Application defined in [RFC3958]. 103 This document updates the Diameter peer discovery procedure described 104 in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service 105 and Application Procotol Tag values that permit the discovery of 106 Diameter peers that support a specific Diameter application and 107 transport protocol. 109 2. Terminology 111 The Diameter base protocol specification (Section 1.4 of RFC 3588) 112 defines most of the terminology used in this document. 114 3. Extended NAPTR Service Field Format 116 The NAPTR Service Field format defined by the S-NAPTR DDDS in 117 [RFC3958] consists of a S-NAPTR Application Service tag and a S-NAPTR 118 Application Protocol tag delimited by a single colon (":") character. 120 The S-NAPTR Application Service Tag ABNF specification for the 121 discovery of Diameter agents supporting a specific Diameter 122 application is show below. 124 appln-svc-tag = iana-appln-tag / experimental-appln-tag 125 iana-appln-tag = "aaa+ap" appln-id 126 experimental-appln-tag = "x-aaa+ap" appln-id 127 appln-id = *DIGIT 128 ; Application identifier expressed as a 129 ; decimal integer. 131 As stated in [RFC3958], application service tags that start with "x-" 132 are considered experimental, and no provision is made to prevent 133 duplicate use of the same string. Implementors use them at their own 134 risk. 136 The S-NAPTR Application Protocol Tag ABNF specification for the 137 discovery of Diameter agents supporting a specific Diameter transport 138 protocol is shown below. 140 appln-protocol-tag = "diameter." app-protocol 141 app-protocol = "tcp" / "sctp" / "tls.tcp" 143 For example, a NAPTR service field value of: 145 'aaa+ap6:diameter.sctp' 147 Means that the Diameter node in the SRV or A/AAAA record supports 148 the Diameter Session Initiation Protocol (SIP) Application ('6') 149 and SCTP as the transport protocol. 151 The maximum length of the NAPTR service field is 256 octets including 152 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 153 of [RFC1035]). The DNS administrator of some domain SHOULD also 154 provision base RFC 3588 style NAPTR records [RFC2915] in order to 155 guarantee backwards compatibility with legacy RFC 3588 compliant 156 Diameter peers. If the DNS administrator provisions both extended 157 S-NAPTR records as defined in this specification and legacy RFC 3588 158 NAPTR records, then the extended S-NAPTR records MUST have higher 159 priority (e.g. lower order and/or preference values) than legacy 160 NAPTR records. 162 4. Extended NAPTR-based Diameter Peer Discovery 164 The basic Diameter Peer Discover principles are described in Section 165 5.2 of [RFC3588]. This specification updates the NAPTR query 166 procedure in the Diameter peer discovery mechanism by allowing the 167 querying node to determine which applications are supported by 168 resolved Diameter peers. 170 The extended format NAPTR records provide a mapping from a domain, to 171 the SRV record or A/AAAA record for contacting a server supporting a 172 specific transport protocol and Diameter application. The resource 173 record will contain an empty regular expression and a replacement 174 value, which is the SRV record or the A/AAAA record for that 175 particular transport protocol. If the server supports multiple 176 transport protocols, there will be multiple NAPTR records, each with 177 a different Services Field value and potentially different list of 178 supported Diameter applications. 180 The assumption for this mechanism to work is that the DNS 181 administrator of the queried domain has first provisioned the DNS 182 with extended format NAPTR entries. The steps below replace the 183 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 185 a. The Diameter implementation performs a NAPTR query for a server in 186 a particular realm. The Diameter implementation has to know in 187 advance which realm to look for a Diameter agent in and which 188 Application Identifier it is interested in. The realm could be 189 deduced, for example, from the 'realm' in a NAI that a Diameter 190 implementation needed to perform a Diameter operation on. 192 b. If the returned NAPTR service fields contain entries formatted as 193 "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" 194 indicates the transport protocol, the target realm supports the 195 extended format for NAPTR-based Diameter peer discovery defined in 196 this document. 198 If "X" contains the required Application Identifier and "Y" 199 matches a transport protocol supported by the client, the 200 client resolves the "replacement" field entry to a target host 201 using the lookup method appropriate for the "flags" field. 203 If "X" does not contain the required Application Identifier or 204 "Y" does not match a transport protocol supported by the 205 client, the peer discovery is abandoned. 207 c. If the returned NAPTR service fields contain entries formatted as 208 "AAA+D2X" where "X" indicates the transport protocol, the target 209 realm supports the NAPTR-based Diameter peer discovery defined in 210 [RFC3588]. 212 If "X" matches a transport protocol supported by the client, 213 the client continues processing the NAPTR as described in 214 [RFC3588] and [RFC2915]. 216 If "X" does not match a transport protocol supported by the 217 client, the peer discovery is abandoned. 219 d. If the target realm does not support NAPTR-based Diameter peer 220 discovery, the client proceeds with the next peer discovery 221 mechanism described in Section 5.2 of [RFC3588]. 223 5. IANA Considerations 225 5.1. IETF Diameter Application Service Tags 227 IANA is requested to reserve the following S-NAPTR Application 228 Service Tags for existing IETF Diameter applications: 230 +------------------+----------------------------------+ 231 | Tag | Diameter Application | 232 +------------------+----------------------------------+ 233 | aaa+ap1 | NASREQ [RFC3588] | 234 | aaa+ap2 | Mobile IPv4 [RFC4004] | 235 | aaa+ap3 | Base Accounting [RFC3588] | 236 | aaa+ap4 | Credit Control [RFC4006] | 237 | aaa+ap5 | EAP [RFC4072] | 238 | aaa+ap6 | SIP [RFC4740] | 239 | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | 240 | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | 241 | aaa+ap9 | QoS [I-D.ietf-dime-diameter-qos] | 242 | aaa+ap4294967295 | Relay [RFC3588] | 243 +------------------+----------------------------------+ 245 Editor's Note: Update the table with the RFC number assigned to the 246 Diameter QoS Application. 248 Future IETF Diameter applications MUST reserve the S-NAPTR 249 Application Service Tag corresponding to the allocated Diameter 250 Application ID. 252 5.2. Vendor-Specific Diameter Application Service Tags 254 Vendor-Specific Diameter Application IDs are allocated by IANA 255 according to the "First Come First Served" policy and do not require 256 an IETF specification. However, the S-NAPTR Application Service Tag 257 registry created by [RFC3958] defines a registration policy of 258 "Specification Required" with a further stipulation that the 259 "specification" is an RFC (of any category). If a Vendor-Specific 260 Diameter Application requires the functionality defined in this 261 document, an RFC of any category MUST be published which reserves the 262 S-NAPTR Application Service Tag corresponding to the Vendor-Specific 263 Diameter Application ID. 265 5.3. Diameter Application Protocol Tags 267 IANA is requested to reserve the following S-NAPTR Application 268 Protocol Tags for the Diameter transport protocols: 270 +------------------+----------+ 271 | Tag | Protocol | 272 +------------------+----------+ 273 | diameter.tcp | TCP | 274 | diameter.sctp | SCTP | 275 | diameter.tls.tcp | TLS/TCP | 276 +------------------+----------+ 278 6. Security Considerations 280 This document specifies an enhancement to RFC 3588 Diameter base 281 protocol defined NAPTR service field format and also modifications to 282 the NAPTR processing logic defined. The enhancements and 283 modifications are based on the S-NAPTR, which is actually a 284 simplification of the NAPTR, and therefore the same security 285 considerations described in RFC 3588 are applicable to this document. 286 No further extensions are required beyond the security mechanisms 287 offered by RFC 3588. However, a malicious host doing S-NAPTR queries 288 learns applications supported by Diameter agents in a certain realm 289 faster, which might help the malicious host to scan potential targets 290 for an attack more efficiently when some applications have known 291 vulnerabilities. 293 7. References 295 7.1. Normative References 297 [I-D.ietf-dime-diameter-qos] 298 Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., 299 and G. Zorn, "Diameter Quality of Service Application", 300 draft-ietf-dime-diameter-qos-15 (work in progress), 301 March 2010. 303 [RFC1035] Mockapetris, P., "Domain names - implementation and 304 specification", STD 13, RFC 1035, November 1987. 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 310 specifying the location of services (DNS SRV)", RFC 2782, 311 February 2000. 313 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 314 Part Three: The Domain Name System (DNS) Database", 315 RFC 3403, October 2002. 317 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 318 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 320 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 321 "DNS Extensions to Support IP Version 6", RFC 3596, 322 October 2003. 324 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 325 Service Location Using SRV RRs and the Dynamic Delegation 326 Discovery Service (DDDS)", RFC 3958, January 2005. 328 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 329 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 330 August 2005. 332 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 333 Loughney, "Diameter Credit-Control Application", RFC 4006, 334 August 2005. 336 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 337 Authentication Protocol (EAP) Application", RFC 4072, 338 August 2005. 340 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 341 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 342 Initiation Protocol (SIP) Application", RFC 4740, 343 November 2006. 345 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 346 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 347 Agent to Diameter Server Interaction", RFC 5778, 348 February 2010. 350 7.2. Informative References 352 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 353 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 355 Authors' Addresses 357 Mark Jones 358 Bridgewater Systems 360 Email: mark@azu.ca 362 Jouni Korhonen 363 Nokia Siemens Networks 365 Email: jouni.nospam@gmail.com