idnits 2.17.1 draft-ietf-dime-extended-naptr-02.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 (September 2, 2010) is 4983 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 September 2, 2010 7 Expires: March 6, 2011 9 Diameter Extended NAPTR 10 draft-ietf-dime-extended-naptr-02 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 March 6, 2011. 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. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 6 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 82 6.1. IETF Diameter Application Service Tags . . . . . . . . . . 7 83 6.2. Vendor-Specific Diameter Application Service Tags . . . . . 7 84 6.3. Diameter Application Protocol Tags . . . . . . . . . . . . 7 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 The Diameter base protocol [RFC3588] specifies three mechanisms for 94 the Diameter peer discovery. One of these involves the Diameter 95 implementation performing a NAPTR query [RFC3403] for a server in a 96 particular realm. These NAPTR records provide a mapping from a 97 domain, to the SRV record [RFC2782] or A/AAAA record 98 [RFC1035][RFC3596] for contacting a server with the specific 99 transport protocol in the NAPTR services field. 101 The extended NAPTR usage for Diameter peer discovery defined by this 102 document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic 103 Delegation Discovery System (DDDS) Application defined in [RFC3958]. 104 This document updates the Diameter peer discovery procedure described 105 in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service 106 and Application Procotol Tag values that permit the discovery of 107 Diameter peers that support a specific Diameter application and 108 transport protocol. 110 2. Terminology 112 The Diameter base protocol specification (Section 1.4 of RFC 3588) 113 defines most of the terminology used in this document. 115 3. Extended NAPTR Service Field Format 117 The NAPTR Service Field format defined by the S-NAPTR DDDS in 118 [RFC3958] consists of a S-NAPTR Application Service tag and a S-NAPTR 119 Application Protocol tag delimited by a single colon (":") character. 121 The S-NAPTR Application Service Tag ABNF specification for the 122 discovery of Diameter agents supporting a specific Diameter 123 application is show below. 125 appln-svc-tag = iana-appln-tag / experimental-appln-tag 126 iana-appln-tag = "aaa+ap" appln-id 127 experimental-appln-tag = "x-aaa+ap" appln-id 128 appln-id = *DIGIT 129 ; Application identifier expressed as a 130 ; decimal integer. 132 As stated in [RFC3958], application service tags that start with "x-" 133 are considered experimental, and no provision is made to prevent 134 duplicate use of the same string. Implementors use them at their own 135 risk. 137 The S-NAPTR Application Protocol Tag ABNF specification for the 138 discovery of Diameter agents supporting a specific Diameter transport 139 protocol is shown below. 141 appln-protocol-tag = "diameter." app-protocol 142 app-protocol = "tcp" / "sctp" / "tls.tcp" 144 For example, a NAPTR service field value of: 146 'aaa+ap6:diameter.sctp' 148 Means that the Diameter node in the SRV or A/AAAA record supports 149 the Diameter Session Initiation Protocol (SIP) Application ('6') 150 and SCTP as the transport protocol. 152 The maximum length of the NAPTR service field is 256 octets including 153 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 154 of [RFC1035]). The DNS administrator of some domain SHOULD also 155 provision base RFC 3588 style NAPTR records [RFC2915] in order to 156 guarantee backwards compatibility with legacy RFC 3588 compliant 157 Diameter peers. If the DNS administrator provisions both extended 158 S-NAPTR records as defined in this specification and legacy RFC 3588 159 NAPTR records, then the extended S-NAPTR records MUST have higher 160 priority (e.g. lower order and/or preference values) than legacy 161 NAPTR records. 163 4. Extended NAPTR-based Diameter Peer Discovery 165 The basic Diameter Peer Discover principles are described in Section 166 5.2 of [RFC3588]. This specification updates the NAPTR query 167 procedure in the Diameter peer discovery mechanism by allowing the 168 querying node to determine which applications are supported by 169 resolved Diameter peers. 171 The extended format NAPTR records provide a mapping from a domain, to 172 the SRV record or A/AAAA record for contacting a server supporting a 173 specific transport protocol and Diameter application. The resource 174 record will contain an empty regular expression and a replacement 175 value, which is the SRV record or the A/AAAA record for that 176 particular transport protocol. If the server supports multiple 177 transport protocols, there will be multiple NAPTR records, each with 178 a different Services Field value and potentially different list of 179 supported Diameter applications. 181 The assumption for this mechanism to work is that the DNS 182 administrator of the queried domain has first provisioned the DNS 183 with extended format NAPTR entries. The steps below replace the 184 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 186 a. The Diameter implementation performs a NAPTR query for a server in 187 a particular realm. The Diameter implementation has to know in 188 advance which realm to look for a Diameter agent in and which 189 Application Identifier it is interested in. The realm could be 190 deduced, for example, from the 'realm' in a NAI that a Diameter 191 implementation needed to perform a Diameter operation on. 193 b. If the returned NAPTR service fields contain entries formatted as 194 "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" 195 indicates the transport protocol, the target realm supports the 196 extended format for NAPTR-based Diameter peer discovery defined in 197 this document. 199 If "X" contains the required Application Identifier and "Y" 200 matches a transport protocol supported by the client, the 201 client resolves the "replacement" field entry to a target host 202 using the lookup method appropriate for the "flags" field. 204 If "X" does not contain the required Application Identifier or 205 "Y" does not match a transport protocol supported by the 206 client, the peer discovery is abandoned. 208 c. If the returned NAPTR service fields contain entries formatted as 209 "AAA+D2X" where "X" indicates the transport protocol, the target 210 realm supports the NAPTR-based Diameter peer discovery defined in 211 [RFC3588]. 213 If "X" matches a transport protocol supported by the client, 214 the client continues processing the NAPTR as described in 215 [RFC3588] and [RFC2915]. 217 If "X" does not match a transport protocol supported by the 218 client, the peer discovery is abandoned. 220 d. If the target realm does not support NAPTR-based Diameter peer 221 discovery, the client proceeds with the next peer discovery 222 mechanism described in Section 5.2 of [RFC3588]. 224 5. Usage Guidelines 226 Diameter is a peer to peer protocol whereas most of the applications 227 that extend the base protocol behave like client/server applications. 228 The role of the peer is not advertised in the NAPTR tags and not even 229 communicated during Diameter capability negotiation (CER/CEA). For 230 this reason, NAPTR-based Diameter peer discovery for an application 231 defining client/server roles should only be used by a client to 232 discover servers. 234 6. IANA Considerations 236 6.1. IETF Diameter Application Service Tags 238 IANA is requested to reserve the following S-NAPTR Application 239 Service Tags for existing IETF Diameter applications: 241 +------------------+----------------------------+ 242 | Tag | Diameter Application | 243 +------------------+----------------------------+ 244 | aaa+ap1 | NASREQ [RFC3588] | 245 | aaa+ap2 | Mobile IPv4 [RFC4004] | 246 | aaa+ap3 | Base Accounting [RFC3588] | 247 | aaa+ap4 | Credit Control [RFC4006] | 248 | aaa+ap5 | EAP [RFC4072] | 249 | aaa+ap6 | SIP [RFC4740] | 250 | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | 251 | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | 252 | aaa+ap9 | QoS [RFC5866] | 253 | aaa+ap4294967295 | Relay [RFC3588] | 254 +------------------+----------------------------+ 256 Future IETF Diameter applications MUST reserve the S-NAPTR 257 Application Service Tag corresponding to the allocated Diameter 258 Application ID. 260 6.2. Vendor-Specific Diameter Application Service Tags 262 Vendor-Specific Diameter Application IDs are allocated by IANA 263 according to the "First Come First Served" policy and do not require 264 an IETF specification. However, the S-NAPTR Application Service Tag 265 registry created by [RFC3958] defines a registration policy of 266 "Specification Required" with a further stipulation that the 267 "specification" is an RFC (of any category). If a Vendor-Specific 268 Diameter Application requires the functionality defined in this 269 document, an RFC of any category MUST be published which reserves the 270 S-NAPTR Application Service Tag corresponding to the Vendor-Specific 271 Diameter Application ID. 273 6.3. Diameter Application Protocol Tags 275 IANA is requested to reserve the following S-NAPTR Application 276 Protocol Tags for the Diameter transport protocols: 278 +------------------+----------+ 279 | Tag | Protocol | 280 +------------------+----------+ 281 | diameter.tcp | TCP | 282 | diameter.sctp | SCTP | 283 | diameter.tls.tcp | TLS/TCP | 284 +------------------+----------+ 286 7. Security Considerations 288 This document specifies an enhancement to RFC 3588 Diameter base 289 protocol defined NAPTR service field format and also modifications to 290 the NAPTR processing logic defined. The enhancements and 291 modifications are based on the S-NAPTR, which is actually a 292 simplification of the NAPTR, and therefore the same security 293 considerations described in RFC 3588 are applicable to this document. 294 No further extensions are required beyond the security mechanisms 295 offered by RFC 3588. However, a malicious host doing S-NAPTR queries 296 learns applications supported by Diameter agents in a certain realm 297 faster, which might help the malicious host to scan potential targets 298 for an attack more efficiently when some applications have known 299 vulnerabilities. 301 8. References 303 8.1. Normative References 305 [RFC1035] Mockapetris, P., "Domain names - implementation and 306 specification", STD 13, RFC 1035, November 1987. 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, March 1997. 311 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 312 specifying the location of services (DNS SRV)", RFC 2782, 313 February 2000. 315 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 316 Part Three: The Domain Name System (DNS) Database", 317 RFC 3403, October 2002. 319 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 320 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 322 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 323 "DNS Extensions to Support IP Version 6", RFC 3596, 324 October 2003. 326 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 327 Service Location Using SRV RRs and the Dynamic Delegation 328 Discovery Service (DDDS)", RFC 3958, January 2005. 330 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 331 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 332 August 2005. 334 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 335 Loughney, "Diameter Credit-Control Application", RFC 4006, 336 August 2005. 338 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 339 Authentication Protocol (EAP) Application", RFC 4072, 340 August 2005. 342 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 343 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 344 Initiation Protocol (SIP) Application", RFC 4740, 345 November 2006. 347 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 348 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 349 Agent to Diameter Server Interaction", RFC 5778, 350 February 2010. 352 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 353 and G. Zorn, "Diameter Quality-of-Service Application", 354 RFC 5866, May 2010. 356 8.2. Informative References 358 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 359 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 361 Authors' Addresses 363 Mark Jones 364 Bridgewater Systems 366 Email: mark@azu.ca 367 Jouni Korhonen 368 Nokia Siemens Networks 370 Email: jouni.nospam@gmail.com