idnits 2.17.1 draft-jones-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 : ---------------------------------------------------------------------------- -- 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 (December 9, 2009) is 5251 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission M. Jones 3 Internet-Draft Bridgewater Systems 4 Updates: 3588 (if approved) J. Korhonen 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: June 12, 2010 December 9, 2009 8 Diameter Extended NAPTR 9 draft-jones-dime-extended-naptr-01 11 Abstract 13 This document describes an extended format for the NAPTR service 14 fields used in dynamic Diameter agent discovery. The extended format 15 allows NAPTR queries to contain Diameter Application-Id information. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 12, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Extended NAPTR Service Field . . . . . . . . . . . . . . . . . 4 78 4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 81 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 The Diameter base protocol [RFC3588] specifies three mechanisms for 87 the Diameter peer discovery. One of these involves the Diameter 88 implementation performing a NAPTR query [RFC3403] for a server in a 89 particular realm. These NAPTR records provide a mapping from a 90 domain, to the SRV record [RFC2782] for contacting a server with the 91 specific transport protocol in the NAPTR services field. 93 Section 11.6 of RFC 3588 defines the following NAPTR service fields: 95 Services Field Protocol 96 AAA+D2T TCP 97 AAA+D2S SCTP 99 However, foreseen network topologies require border AAA nodes that 100 will be specialized by Diameter application and the NAPTR service 101 field does not allow a Diameter implementation to determine the 102 application supported by the AAA node. Without this information, a 103 Diameter implementation must connect and perform a capability 104 negotiation with each candidate AAA node. This document addresses 105 this problem by specifying an extended NAPTR service field format 106 that permits discovery of Diameter peers that support a specific 107 Diameter application. 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 116 The Extended NAPTR service field ABNF specification for the discovery 117 of Diameter agents supporting a specific Diameter application is show 118 below. 120 naptr-svc-field = "AAA+D2" < protocol> [ *appln-list ] 122 protocol = "T" / "S" 123 ; "T" for TCP and "S" for SCTP. 125 appln-list = "+AP:" appln-id [ *( "," appln-id ) ] 126 ; Comma separated list of application 127 ; identifiers prefixed by "+AP:". 129 appln-id = *DIGIT 130 ; Application identifier expressed as a 131 ; decimal integer. 133 For example, a NAPTR service field value of: 135 'AAA+D2S+AP:6' 137 Means that the Diameter node in the SRV record supports the 138 Diameter Session Initiation Protocol (SIP) Application ('6') and 139 SCTP as the transport protocol. 141 'AAA+D2S+AP:6,1,5,4294967295' 143 Means that the Diameter node in the SRV record supports the 144 Diameter Session Initiation Protocol (SIP) Application ('6'), 145 NASREQ Application ('1'), EAP Application ('5') and SCTP as the 146 transport protocol. The Diameter node also provides Relay 147 functionality ('4294967295'). 149 The maximum length of the NAPTR service field is 256 octets including 150 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 151 of [RFC1035]). The DNS administrator of some domain SHOULD also 152 provision base RFC 3588 style NAPTR records in order to guarantee 153 backwards compatibility with legacy RFC 3588 compliant Diameter 154 peers. If the DNS administrator provisions both extended NAPTR 155 records as defined in this specification and legacy RFC 3588 NAPTR 156 records, then the extended NAPTR records MUST have higher priority 157 (e.g. lower order and/or preference values) than legacy NAPTR 158 records. 160 4. Extended NAPTR-based Diameter Peer Discovery 162 The basic Diameter Peer Discover principles are described in Section 163 5.2 of [RFC3588]. This specification extends the NAPTR query 164 procedure in the Diameter peer discovery mechanism by allowing the 165 querying node to determine which applications are supported by 166 resolved Diameter peers. 168 The extended format NAPTR records provide a mapping from a domain, to 169 the SRV record for contacting a server supporting a specific 170 transport protocol and Diameter application. The resource record 171 will contain an empty regular expression and a replacement value, 172 which is the SRV record for that particular transport protocol. If 173 the server supports multiple transport protocols, there will be 174 multiple NAPTR records, each with a different Services Field value 175 and potentially different list of supported Diameter applications. 177 The assumption for this mechanism to work is that the DNS 178 administrator of the queried domain has first provisioned the DNS 179 with extended format NAPTR entries. The steps below replace the 180 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 182 a. The Diameter implementation performs a NAPTR query for a server in 183 a particular realm. The Diameter implementation has to know in 184 advance which realm to look for a Diameter agent in and which 185 Application Identifier it is interested in. The realm could be 186 deduced, for example, from the 'realm' in a NAI that a Diameter 187 implementation needed to perform a Diameter operation on. 189 b. If the returned NAPTR service fields contain entries formatted as 190 "AAA+D2X+AP:Y" where "X" indicates the transport protocol and "Y" 191 is a comma-separated list of Application Identifiers, the target 192 realm supports the extended format for NAPTR-based Diameter peer 193 discovery defined in this document. 195 If "X" matches a transport protocol supported by the client and 196 "Y" contains the required Application Identifier, the client 197 resolves the "replacement" field entry to a target host using 198 the lookup method appropriate for the "flags" field. 200 If "X" does not match a transport protocol supported by the 201 client or "Y" does not contain the required Application 202 Identifier, the peer discovery is abandoned. 204 c. If the returned NAPTR service fields contain entries formatted as 205 "AAA+D2X" where "X" indicates the transport protocol, the target 206 realm supports the NAPTR-based Diameter peer discovery defined in 207 [RFC3588]. 209 If "X" matches a transport protocol supported by the client, 210 the client resolves the "replacement" field entry to a target 211 host using the lookup method appropriate for the "flags" field. 213 If "X" does not match a transport protocol supported by the 214 client, the peer discovery is abandoned. 216 d. If the target realm does not support NAPTR-based Diameter peer 217 discovery, the client proceeds with the next peer discovery 218 mechanism described in Section 5.2 of [RFC3588]. 220 5. IANA Considerations 222 Section 11.6 of [RFC3588] defines a IANA registry for the NAPTR 223 Services Field entries. Although this document does not define a new 224 transport protocol, it is proposed to add the following entries to 225 the existing registry to reflect the extended format of the NAPTR 226 Services Field: 228 Services Field Protocol 229 AAA+D2T+AP:x TCP 230 AAA+D2S+AP:x SCTP 232 Editor's Note: IANA is currently missing the registry for the NAPTR 233 Service Fields defined in [RFC3588]. This oversight will need to be 234 resolved for this document to proceed. 236 6. Security Considerations 238 This document specifies an enhancement to the NAPTR service field 239 format defined in the Diameter base protocol and the same security 240 considerations described in RFC 3588 are applicable to this document. 241 No further extensions are required beyond the security mechanisms 242 offered by RFC 3588. However, a malicious host doing NAPTR queries 243 learns applications supported by Diameter agents in a certain realm 244 faster, which might help the malicious host to scan potential targets 245 for an attack more efficiently when some applications have known 246 vulnerabilities. 248 7. Normative References 250 [RFC1035] Mockapetris, P., "Domain names - implementation and 251 specification", STD 13, RFC 1035, November 1987. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 257 specifying the location of services (DNS SRV)", RFC 2782, 258 February 2000. 260 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 261 Part Three: The Domain Name System (DNS) Database", 262 RFC 3403, October 2002. 264 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 265 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 267 Authors' Addresses 269 Mark Jones 270 Bridgewater Systems 272 Email: mark.jones@bridgewatersystems.com 274 Jouni Korhonen 275 Nokia Siemens Networks 277 Email: jouni.nospam@gmail.com