idnits 2.17.1 draft-ietf-svrloc-advertising-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 4) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9202 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) ** Downref: Normative reference to an Informational RFC: RFC 1309 (ref. '3') ** Obsolete normative reference: RFC 2052 (ref. '5') (Obsoleted by RFC 2782) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1588 (ref. '8') ** Obsolete normative reference: RFC 1738 (ref. '9') (Obsoleted by RFC 4248, RFC 4266) ** Downref: Normative reference to an Informational RFC: RFC 2378 (ref. '10') ** Obsolete normative reference: RFC 954 (ref. '11') (Obsoleted by RFC 3912) ** Obsolete normative reference: RFC 822 (ref. '12') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1436 (ref. '15') ** Obsolete normative reference: RFC 2065 (ref. '16') (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2168 (ref. '18') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Ryan Moats 3 draft-ietf-svrloc-advertising-05.txt AT&T 4 Expires in six months Martin Hamilton 5 Loughborough University 6 February 1999 8 Advertising Services 9 (Providing information to support service discovery) 10 Filename: draft-ietf-svrloc-advertising-05.txt 12 Status of This Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), 17 its areas, and its working groups. Note that other groups may 18 also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document proposes a solution to the problem of finding 35 information about that services are being offered at a particular 36 Internet domain, based on deployment experience with the Netfind 37 White Pages directory software. 39 This approach makes it possible to supply clients with more 40 information than the DNS aliases that have been widely deployed in 41 this role - notably the port numbers being used by servers. However, 42 it is not without problems, and we have tried to take account of 43 these. 45 1. Rationale 47 There is no one single way of discovering the network services and 48 application protocols supported at a particular Internet domain. The 49 Domain Name System (DNS - [1,2]) provides some basic facilities for 50 finding the hosts that offer particular services, such as DNS servers 51 themselves (NS records), and mail exchangers (MX records). It does 52 not provide a mechanism for locating arbitrary servers of arbitrary 53 protocols, or a search capability. 55 In addition to the name and IP address(es) of the host offering the 56 service, clients also sometimes require further information to make 57 effective use of the service - e.g. TCP or UDP port numbers, protocol 58 version information, and information about the protocol options 59 supported by the server. Another example would be the organization's 60 base within the X.500 [3] Directory Information Tree (DIT), that is 61 needed for X.500 browsing and searching. 63 At the time of our initial draft, it was common practice to "hint" at 64 the services and protocols offered at a given domain via DNS aliases. 65 For example, the alias "www.internic.net" implies that the HTTP 66 server for the domain "internic.net" is running on TCP port 80 of the 67 machine (or machines) that answer to the name "www.internic.net." A 68 slight formalization of this approach [4] has been accepted. Other 69 schemes have been suggested for explicitly registering services 70 either by DNS extensions, as in [5], or by dedicated directory 71 services such as X.500. 73 Several mechanisms have been suggested to address the problem of 74 finding this service information, ranging from new DNS record types 75 to dedicated directory services. No single one of these would-be 76 solutions has as yet gained the competitive edge. If the lengthy 77 gestation period to date is anything to go by, it seems that we can 78 expect even more delay before there is any widespread deployment - 79 unless there is a "killer application" that forces the issue. 81 2. Where Netfind has gone before 83 The Netfind software [6,7] follows what has been proposed in RFC 1588 84 [8]: using URLs [9] for passing directory service information to 85 clients. It uses stylized Text (TXT) record encoding within the DNS 86 and currently understands the following "White Pages" URLs: 88 ----------------------------------------------------------- 89 White Pages URL Information 90 ----------------------------------------------------------- 91 wp-noop:// This site should not be visited 92 wp-dap:// X.500 search base for the site 93 e.g. wp-dap://o=Loughborough%20University,c=GB 94 wp-ph://host/port Suggests CCSO nameserver [10] 95 wp-whois://host/port Suggests WHOIS [11] server 96 wp-smtp-expn-finger://host Use the SMTP [12] EXPN command, 97 and the finger [13] protocol 98 wp-smtp-expn://host/port Suggests the SMTP EXPN command 99 wp-finger://host/port Suggests the finger protocol 100 wp-telnet://host/port Suggests a text based info 101 service that should be used 102 via telnet [14] 103 ----------------------------------------------------------- 105 Note that the notation "protocol://host/port" is used, rather than 106 the "protocol://host:port" format that is being standardized for 107 generic URLs. 109 Note also that these URL schemes have not all been standardized, 110 although wp-ph and wp-whois may be accommodated by translation to the 111 widely supported Internet Gopher Protocol [15]. 113 3. A simple interim solution 115 In this document, we propose that the "service:" URL scheme as 116 described in [17] be encoded in DNS NAPTR records [18] as a solution. 117 With this scheme, software agents would do a DNS lookup on 118 .. The NAPTR record associated with 119 . would have the following syntax: 121 IN NAPTR [preference] [weight] "u" "" "!^.*$!!" . 124 Most of these fields are discussed in [18]. Of note is the regular 125 expression field, which is the central feature of this proposal. As 126 URLs routinely use the "/" character to donate hierarchy, the regular 127 expression should be delimited by the some other character. For 128 purposes of this document, we propose using "!", although another 129 character can be used so long as the service URL does not contain 130 that character. Finally, the regular expression must conform to the 131 requirements of [18]. 133 Further, the Service URL scheme supports the concept of abstract 134 service types that are useful for white pages service advertisement. 135 For general white pages discovery, we propose that software agents do 136 a DNS lookup on wp.. Here, the NAPTR records would 137 contain URLs of the "wp:" abstract service type as documented in 138 [19]. For example, the NAPTR records for wp.lut.ac.uk could be 139 written as 140 wp IN NAPTR 10 0 "u" "" "!^.*$!service:wp:ldap://ldap.lut.ac.uk/ 141 o=Loughborough%20University%20of%20!Technology,c=GB!" . 142 wp IN NAPTR 20 0 "u" "" 143 "!^.*$!service:wp:http://www.lut.ac.uk/cgi-bin/local!" 144 . 146 3.1 Why not TXT records? 148 Previous versions of this document proposed using TXT records for 149 storing the URL information. Rather than continue to propose using 150 TXT records, we have decided to propose using NAPTR records for 151 storing this information as this is the type of information that 152 NAPTR was intended to hold when it was developed. 154 4. Further details and usage scenarios 156 4.1. Finding "White Pages" information 158 This case is already catered for by the Netfind "wp-" prefix. To 159 advertise their White Pages services explicitly, a site would create 160 one or more TXT records under both wp and the service being 161 advertised, e.g. 163 wp IN NAPTR 10 0 "u" "" "!^.*$!service:wp:ldap://ldap.lut.ac.uk/ 164 o=Loughborough%20University%20of%20Technology,c=GB!" . 165 wp IN NAPTR 20 0 "u" "" "!^.*$!service:wp:whois://whois.lut.ac.uk/!" . 166 wp IN NAPTR 30 0 "u" "" "!^.*$!service:wp:ccso://cso.lut.ac.uk/2!" . 168 ldap IN NAPTR 10 0 "u" "" "!^.*$!service:wp:ldap://ldap.lut.ac.uk/ 169 o=Loughborough%20University%20of%20Technology,c=GB!" . 171 whois IN NAPTR 10 0 "u" "" "!^.*$!service:wp:whois://whois.lut.ac.uk/!" 172 . 174 ph IN NAPTR 10 0 "u" "" "!^.*$!service:wp:ccso://cso.lut.ac.uk/2!" . 176 Another example showing the possibility of multiple protocols for 177 accessing a service would be (the domain for this example is 178 aecom.yu.edu): 180 ns IN NAPTR 10 0 "u" "" 181 "!^.*$!service:wp:gopher://gopher.aecom.yu.edu/2!" . 182 ns IN NAPTR 20 0 "u" "" "!^.*$!service:wp:http://www.middlebury.edu/ 183 cgi-bin/WebPh?other_ph_servers!" . 184 ns IN NAPTR 30 0 "u" "" 185 "!^.*$!service:wp:http://faker.ncsa.uiuc.edu:8080/ 186 cgi-bin/phfd!" . 188 It is envisaged that this information could be used in some 189 scenarios. Assuming their Internet domain is already known, mail 190 user agents with integrated support could offer to do directory 191 service lookups to determine a correspondent's address from their 192 name, to verify the contents of address books, and to determine 193 alternative email addresses should delivery fail. This last 194 technique might also be applied by lower level mail delivery 195 software. 197 4.3. Public key lookup 199 Attempts to build a scalable infrastructure for the distribution of 200 public key information, in particular for the public keys of 201 individuals, have been hampered by the lack of a convention that 202 could be used to suggest the public key servers for a site or 203 organization. 205 For these examples, we postulate an abstract service type "keys:", 206 e.g. 208 keys IN NAPTR 10 0 "u" "" "!^.*$!service:keys:finger://mrrl.lut.ac.uk!" 209 . 211 lut.ac.uk IN NAPTR 10 0 "u" "" 212 "!^.*$!service:keys:finger://mrrl.lut.ac.uk!" . 214 It does not, however, address the issue of public key (certificate) 215 format. It is expected that this would be taken care of by format 216 negotiation in the protocol or protocols being used to do the lookup. 218 Public key lookup would be of immediate use in software that has 219 integrated support for public key authentication, signing and 220 encryption - e.g. mail and news user agents. 222 4.4. Finding "Yellow Pages" information 224 By "Yellow Pages" we mean a catch-all category: information about 225 services offered that do not fall into any of the above categories. 226 For this, we propose using the "yp:" abstract service type described 227 in [19]. 229 For example, consider the case of a machine that is running a HTTP 230 server - but not on the IANA registered default port (80) 232 www IN A 204.179.186.65 233 IN A 198.49.45.10 234 IN A 192.20.239.132 235 IN NAPTR 10 0 "u" "" "!^.*$!service:yp:http:// 236 www.ds.internic.net:8888/!" . 238 yp IN A 204.179.186.65 239 IN A 198.49.45.10 240 IN A 192.20.239.132 241 IN NAPTR 10 0 "u" "" "!^.*$!service:yp:http:// 242 www.ds.internic.net:8888/!" . 244 This "Yellow Pages" mechanism provides a means for DNS maintainers to 245 effectively register the existence of their major network services. 246 This can have a variety of uses - e.g. the service information is 247 available to any "web crawler" type applications that might choose to 248 index it, and to interactive applications such as World-Wide Web 249 browsers, that might use it to override their default behavior. 251 4.5 Finding "Directory Agent" information 253 The Service Location Protocol [20] provides the ability to search for 254 services according to their characteristics, as opposed to solely by 255 type. This is useful to clients that need to discover a particular 256 service in a case where a domain offers more than one service of the 257 same type and the services are not identical. Clients can discover 258 what types of services are supported, the attributes of those 259 services and can obtain service URLs by issuing structured queries. 260 Thus, a service may be discovered by description as opposed to by 261 name. 263 To do this, the Service Location Protocol defines a scheme for 264 Directory Agent discovery. The term "directory" in this context 265 refers to a directory of services as opposed to a directory of "white 266 pages" information that is used elsewhere in this document. A site 267 may wish to present services to hosts outside its domain may elect to 268 set up a Directory Agent (with the remote registration features 269 turned off, see [20]) outside its firewall. A client supporting the 270 service location protocol would then make queries for individual 271 services inside the domain. The Directory Agent would be found via 272 the following DNS entries: 274 (Domain entry) 275 catch22.com IN NAPTR 10 0 "u" "" "!^.*$!service:directory-agent: 276 //slp-resolver.catch22.com!" . 278 (host in domain catch22.com) 279 directory-agent IN NAPTR 10 0 "u" "" "!^.*$!service:directory-agent: 280 //slp-resolver.catch22.com!" . 282 5. Limitations of this approach 284 Note that older DNS servers may not support the NAPTR record type. 285 This is because support for SRV and NAPTR have only recently been 286 added to the BIND code base. 288 Some resolvers are not capable of requesting a NAPTR record, or not 289 capable of generating any DNS lookup requests other than a simple 290 address lookup. NAPTR records can actually be requested by setting 291 the question type in the request to 35 (decimal), regardless of the 292 symbolic names defined by the stack's resolver code. Implementing 293 more advanced resolver functionality when the stack only provides 294 address lookup requires a little work, but sample code is freely 295 available. 297 The size limitations on DNS packets will have some effect on the 298 number of URLs that can be associated with a domain name using NAPTR 299 records. Response packets are subject to truncation if they grow to 300 over 576 bytes. 302 Characters that are illegal in URLs must be escaped, for example: 304 "service:wp:ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of 305 %20Technology,c=GB" 307 Domain name compression is normally used to reduce the size of the 308 response packet needed for a given domain name. Clearly, this will 309 not be possible on arbitrary strings embedded within the response 310 packet. 312 Widespread use of NAPTR records in the role proposed by this document 313 would increase the amount of information held in nameserver caches, 314 and in particular might cause problems where negative cacheing is 315 concerned. Consequently we suggest that clients use them as a fall 316 back mechanism if more conventional methods, such as DNS aliases, 317 prove unproductive. 319 7. Security Considerations 321 Since this draft proposes to use DNS for storage of URL information, 322 all the normal security considerations for applications that depend 323 on the DNS apply. The DNS is open to many kinds of "spoofing" 324 attacks, and it cannot be guaranteed that the result returned by a 325 DNS lookup is indeed the genuine information. Spoofing may take the 326 form of denial of service, such as directing of the client to a non- 327 existent address, or a passive attack such as an intruder's server 328 that masquerades as the legitimate one. 330 Work is ongoing to remedy this issue insofar as the DNS is concerned 331 [16]. In the meantime, note that stronger authentication mechanisms 332 such as public key cryptography with large key sizes are a pre- 333 requisite if the DNS is being used in any sensitive environment. 334 Examples of these would be on-line financial transactions, and any 335 scenario where privacy is a concern - such as the querying of medical 336 records over the network. Strong encryption of the network traffic 337 may also be advisable, to protect against TCP connection "hijacking" 338 and packet sniffing. 340 There are some additional considerations that are specific to URLs. 341 Specifically, client applications should be wary of URLs that direct 342 them to alternative Internet domains and/or unusual port numbers. 343 They should also be proactive when passing URLs to external programs, 344 to ensure that the user's environment is not exposed to malevolent 345 meta-characters. Finally, implementors should take care to avoid 346 buffer overruns when processing these DNS response packets. 348 8. Conclusions 350 Whilst far from ideal, we believe the approach outlined in this 351 document does provide a workable interim solution to the problem of 352 locating the network services offered at a particular Internet domain 353 - particularly when used in combination with DNS aliases, as outlined 354 in [4]. Suitable DNS server software is already widely deployed, and 355 client support may be implemented without any great difficulty. 357 It is debatable whether any of this is strictly necessary. Certainly 358 there is less work involved in adding a few lines to an existing DNS 359 server configuration than in setting up a whole new directory 360 service, such as X.500. From this point of view, a new DNS resource 361 record type or types would perhaps address the problem more 362 effectively, but it may be some time before any new types are widely 363 deployed. 365 9. Acknowledgments 367 Special thanks to Erik Guttman for his help with the service location 368 example, information on the "service:" scheme, as well as much e-mail 369 in working out the service schemes proposed here. Thanks to Tim 370 Howes, Sri Sataluri and members of the IETF SVRLOC and IDS working 371 groups for their comments on earlier drafts of this document. This 372 document is partially supported by the National Science Foundation, 373 Cooperative Agreement NCR-9218179, the UK Electronic Libraries 374 Programme (eLib) grant 12/39/01, and the European Commission's 375 Telematics for Research Programme grant RE 1004. 377 The format used for representing Netfind White Pages URLs within the 378 DNS was originally defined by Mike Schwartz, with help from Carl 379 Malamud and Marshall Rose. The Netfind work was supported in part by 380 grants from the National Science Foundation, the Advanced Research 381 Projects Agency, Sun Microsystems' Collaborative Research Program, 382 and AT&T Bell Laboratories. 384 Some of the points in the security considerations section were drawn 385 from [4]. 387 10. References 389 Request For Comments (RFC) and Internet Draft documents are available 390 from numerous sites. 392 [1] P. V. Mockapetris. "Domain names - concepts and 393 facilities," RFC 1034. November 1987. 395 [2] P. V. Mockapetris. "Domain names - implementation 396 and specification," RFC 1035. November 1987. 398 [3] C. Weider, J. Reynolds, S. Heker. "Technical Over- 399 view of Directory Services Using the X.500 Proto- 400 col," RFC 1309. March 1992. 402 [4] M. Hamilton, R. Wright. "Use of DNS Aliases for 403 Network Services," RFC 2219, October 1997. 405 [5] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying 406 the location of services (DNS SRV)," RFC 2052. 407 October 1996. 409 [6] M. F. Schwartz. "Netfind Support for URL-Based 410 Search Customization," June 28, 1994. 411 414 [7] M. F. Schwartz, C. Pu. "Applying an Information 415 Gathering Architecture to Netfind: A White Pages 416 Tool for a Changing and Growing Internet," Univer- 417 sity of Colorado Technical Report CU-CS-656-93. 418 December 1993, revised July 1994. 419 422 [8] J. Postel, C. Anderson. "White Pages Meeting 423 Report," RFC 1588. February 1994. 425 [9] T. Berners-Lee, L. Masinter & M. McCahill. "Uni- 426 form Resource Locators (URL)," RFC 1738. December 427 1994. 429 [10] R. Hedberg, S. Dorner, and P. Pomes. "The CCSO 430 Nameserver (Ph) Architecture," RFC 2378, August 431 1998. 433 [11] K. Harrenstien, M. K. Stahl, E.J. Feinler. 434 "NICNAME/WHOIS," RFC 954. October 1985. 436 [12] D. Crocker. "Standard for the format of ARPA 437 Internet text messages," RFC 822. August 1982. 439 [13] D. Zimmerman. "The Finger User Information Proto- 440 col," RFC 1288. December 1992. 442 [14] J. Postel, J .K. Reynolds. "Telnet Protocol 443 specification," RFC 855. May 1983. 445 [15] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, 446 D. Torrey & B. Albert. "The Internet Gopher Proto- 447 col (a distributed document search and retrieval 448 protocol)," RFC 1436. March 1993. 450 [16] D. E. Eastlake 3rd, C. W. Kaufman. "Domain Name 451 System Security Extensions," RFC 2065, January 452 1997. 454 [17] E. Guttman, C. Perkins, J. Kempf, "The service: URL 455 Scheme," Internet Draft (work in progress), October 456 1997. 458 [18] R. Daniel, M. Mealling. "Resolution of Uniform 459 Resource Identifiers using the Domain Name System," 460 RFC 2168, June 1997. 462 [19] R. Moats, "The "wp" and "yp" Abstract Services," 463 Internet Draft (work in progress), February, 1997. 465 [20] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, 466 "Service Location Protocol," RFC 2165, June 1997. 468 11. Authors' addresses 470 Ryan Moats 471 AT&T 472 15621 Drexel Circle 473 Omaha, NE 68135-2358 474 USA 476 Phone: +1 402 894-9456 477 EMail: jayhawk@att.com 479 Martin Hamilton 480 Department of Computer Studies 481 Loughborough University of Technology 482 Leics. LE11 3TU, UK 484 Email: m.t.hamilton@lut.ac.uk