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