idnits 2.17.1 draft-ietf-svrloc-advertising-01.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-25) 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 10 longer pages, the longest (page 2) being 60 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 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 3 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 1997) is 9931 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') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** 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') -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 11 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-01.txt AT&T 4 Expires in six months Martin Hamilton 5 Loughborough University 6 February 1997 8 Advertising Services 9 (Providing information to support service discovery) 10 Filename: draft-ietf-svrloc-advertising-01.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), ds.internic.net (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), which is 60 needed for X.500 browsing and searching. 62 At the time of writing, it was common practice to "hint" at the 63 services and protocols offered at a given domain via DNS aliases. For 64 example, the alias "www.internic.net" implies that the HTTP server 65 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 is proposed by [4]. 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 Indicates CCSO nameserver [10] 94 wp-whois://host/port Indicates 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 Indicates the SMTP EXPN command 98 wp-finger://host/port Indicates the finger protocol 99 wp-telnet://host/port Indicates 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 TXT records as a solution. With 116 this scheme, software agents would do a DNS lookup on 117 .. The TXT record associated with 118 . would have the following syntax: 120 IN TXT "service:- [preference] [protocol 121 specific information]" 123 where the preference value and protocol specific information are 124 optional and are separated by spaces. Alternatively, software agents 125 could do a lookup on the parent domain, but this could lead to 126 overloading the DNS response packet. 128 We propose that the following values be used for 130 --------------------------------------------------------------------- 131 Prefix Meaning 132 --------------------------------------------------------------------- 133 keys Public key server info 134 wp "White Pages" service info 135 yp "Yellow Pages" service info 136 --------------------------------------------------------------------- 138 This scheme is not compatible with the Netfind "wp-" scheme, but that 139 is not viewed as a problem owing to lack of deployment of "wp-" URLs. 141 Alternatively, clients may support both "wp-" URLs and "service:" 142 URLs. 144 Thus for general white pages discovery, we propose that software 145 agents do a DNS lookup on wp.. Here, the TXT records 146 would contain URLs of the "wp-" service type. For example, the TXT 147 records for wp.lut.ac.uk could be written as 149 service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of%20 150 Technology,c=GB 151 service:wp-http://www.lut.ac.uk/cgi-bin/local 153 Whilst not an optimal solution, for reasons we will discuss below, 154 this approach does provide an additional level of flexibility and 155 only requires a trivial amount of work to deploy - typically adding a 156 single line to the site's DNS configuration file for each service 157 being advertised. In addition, several of the "service:" URL schemes 158 proposed here are documented in [19]. 160 4. Further details and usage scenarios 162 4.1. Finding "White Pages" information 164 This is the case that is already catered for by the Netfind "wp-" 165 prefix. To advertise their White Pages services explicitly, a site 166 would create one or more TXT records under both wp and the service 167 being advertised, e.g. 169 wp IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University 170 %20of%20Technology,c=GB" 171 wp IN TXT "service:wp-whois://whois.lut.ac.uk/" 172 wp IN TXT "service:wp-ccso://cso.lut.ac.uk/2" 174 ldap IN TXT "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University 175 %20of%20Technology,c=GB" 177 whois IN TXT "service:wp-whois://whois.lut.ac.uk/" 179 ph IN TXT "service:wp-ccso://cso.lut.ac.uk/2" 181 Another example showing the possibility of multiple protocols for 182 accessing a service would be (the domain for this example is 183 aecom.yu.edu): 185 ns IN TXT "service:wp-gopher://gopher.aecom.yu.edu/2" 186 ns IN TXT "service:wp-http://www.middlebury.edu/cgi-bin/ 187 WebPh?other_ph_servers" 188 ns IN TXT "service:wp-http://faker.ncsa.uiuc.edu:8080/cgi-bin/phfd" 190 It is envisaged that this information could be used in some 191 scenarios. Assuming their Internet domain is aleady known, mail user 192 agents with integrated support could offer to do directory service 193 lookups to determine a correspondent's address from their name, to 194 verify the contents of address books, and to determine alternative 195 email addresses should delivery fail. This last technique might also 196 be applied by lower level mail delivery software. 198 4.3. Public key lookup 200 Attempts to build a scalable infrastructure for the distribution of 201 public key information, in particular for the public keys of 202 individuals, have been hampered by the lack of a convention that 203 could be used to suggest the public key servers for a site or 204 organization. 206 The "keys-" prefix gives us a flexible means by which this may be 207 done, e.g. 209 keys IN TXT "service:keys-finger://mrrl.lut.ac.uk 5" 211 lut.ac.uk IN TXT "service:keys-finger://mrrl.lut.ac.uk 5" 213 It does not, however, address the issue of public key (certificate) 214 format. It is expected that this would be taken care of by format 215 negotiation in the protocol or protocols being used to do the lookup. 217 Public key lookup would be of immediate use in software that has 218 integrated support for public key authentication, signing and 219 encryption - e.g. mail and news user agents. 221 4.4. Finding "Yellow Pages" information 223 By "Yellow Pages" we mean a catch-all category: information about 224 services offered that do not fall into any of the above categories. 226 For example, consider the case of a machine that is running a HTTP 227 server - but not on the IANA registered default port (80) 229 www IN A 204.179.186.65 230 IN A 198.49.45.10 231 IN A 192.20.239.132 232 IN TXT "service:yp-http://www.ds.internic.net:8888/" 234 yp IN A 204.179.186.65 235 IN A 198.49.45.10 236 IN A 192.20.239.132 237 IN TXT "service:yp-http://www.ds.internic.net:8888/" 239 This "Yellow Pages" mechanism provides a means for DNS maintainers to 240 effectively register the existence of their major network services. 241 This can have a variety of uses - e.g. the service information is 242 available to any "web crawler" type applications that might choose to 243 index it, and to interactive applications such as World-Wide Web 244 browsers, that might use it to override their default behavior. 246 4.5 Finding "Directory Agent" information 248 [20] also defines a scheme for Directory Agent discovery (Here 249 directory is being used in the SVRLOC context, not the IDS context). 250 A site may wish to present services to hosts outside its domain may 251 elect to set up a Directory Agent (with the remote registration 252 features turned off, see [20]) outside its firewall. A client 253 supporting the service location protocol would then make queries for 254 individual services inside the domain. The Directory Agent would be 255 found via the following DNS entries: 257 (Domain entry) 258 catch22.com IN TXT "service:directory-agent://slp-resolver.catch22.com" 260 (host in domain catch22.com) 261 directory-agent IN TXT "service:directory-agent://slp-resolver.catch22.com" 263 5. Support in DNS clients and servers 265 This scheme is completely compatible with SRV and NAPTR (see [18]) 266 DNS records, that are currently being implemented in BIND. 268 6. Limitations of this approach 270 Note that older DNS servers may not support the TXT record type, and 271 some servers fail to implement it properly - e.g. BIND 4.9.2 misses 272 out every other letter in the TXT record. Further, support for SRV 273 has only recently been added to the BIND code base. 275 Some resolvers are not capable of requesting a TXT record, or not 276 capable of generating any DNS lookup requests other than a simple 277 address lookup. TXT records can actually be requested by setting the 278 question type in the request to 16 (decimal), regardless of the 279 symbolic names defined by the stack's resolver code. Implementing 280 more advanced resolver functionality when the stack only provides 281 address lookup requires a little work, but sample code is freely 282 available. 284 The size limitations on DNS packets will have some effect on the 285 number of URLs that can be associated with a domain name using TXT 286 records. Response packets are liable to be truncated if they grow to 287 over 576 bytes. 289 Characters that are illegal in URLs must be escaped, for example: 291 "service:wp-ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of 292 %20Technology,c=GB" 294 Domain name compression is normally used to reduce the size of the 295 response packet needed for a given domain name. Clearly, this will 296 not be possible on arbitrary strings embedded within the response 297 packet. 299 Widespread use of TXT records in the role proposed by this document 300 would increase the amount of information held in nameserver caches, 301 and in particular might cause problems where negative caching is 302 concerned. Consequently we suggest that clients use them as a fall 303 back mechanism if more conventional methods, such as DNS aliases, 304 prove unproductive. 306 7. Security Considerations 308 Since this draft proposes to use DNS for storage of URL information, 309 all the normal security considerations for applications that depend 310 on the DNS apply. The DNS is open to many kinds of "spoofing" 311 attacks, and it cannot be guaranteed that the result returned by a 312 DNS lookup is indeed the genuine information. Spoofing may take the 313 form of denial of service, such as directing of the client to a non- 314 existent address, or a passive attack such as an intruder's server 315 that masquerades as the legitimate one. 317 Work is ongoing to remedy this issue insofar as the DNS is concerned 318 [16]. In the meantime, note that stronger authentication mechanisms 319 such as public key cryptography with large key sizes are a pre- 320 requisite if the DNS is being used in any sensitive environment. 321 Examples of these would be on-line financial transactions, and any 322 scenario where privacy is a concern - such as the querying of medical 323 records over the network. Strong encryption of the network traffic 324 may also be advisable, to protect against TCP connection "hijacking" 325 and packet sniffing. 327 There are some additional considerations that are specific to URLs. 328 Specifically, client applications should be wary of URLs that direct 329 them to alternative Internet domains and/or unusual port numbers. 330 They should also be proactive when passing URLs to external programs, 331 to ensure that the user's environment is not exposed to malevolent 332 meta-characters. Finally, implementors should take care to avoid 333 buffer overruns when processing these DNS response packets. 335 8. Conclusions 337 Whilst far from ideal, we believe the approach outlined in this 338 document does provide a workable interim solution to the problem of 339 locating the network services offered at a particular Internet domain 340 - particularly when used in combination with DNS aliases, as outlined 341 in [4]. Suitable DNS server software is already widely deployed, and 342 client support may be implemented without any great difficulty. 344 It is debatable whether any of this is strictly necessary. Certainly 345 there is less work involved in adding a few lines to an existing DNS 346 server configuration than in setting up a whole new directory 347 service, such as X.500. From this point of view, a new DNS resource 348 record type or types would perhaps address the problem more 349 effectively, but it may be some time before any new types are widely 350 deployed. 352 9. Acknowledgments 354 Special thanks to Erik Guttman for his help with the service location 355 example, information on the "service:" scheme, as well as much e-mail 356 in working out the service schemes proposed here. Thanks to Tim 357 Howes, Sri Sataluri and <> for their comments on 358 earlier drafts of this document. This document is partially supported 359 by the National Science Foundation, Cooperative Agreement NCR- 360 9218179, the UK Electronic Libraries Programme (eLib) grant 12/39/01, 361 and the European Commission's Telematics for Research Programme grant 362 RE 1004. 364 The format used for representing Netfind White Pages URLs within the 365 DNS was originally defined by Mike Schwartz, with help from Carl 366 Malamud and Marshall Rose. The Netfind work was supported in part by 367 grants from the National Science Foundation, the Advanced Research 368 Projects Agency, Sun Microsystems' Collaborative Research Program, 369 and AT&T Bell Laboratories. 371 Some of the points in the security considerations section were drawn 372 from [4]. 374 10. References 376 Request For Comments (RFC) and Internet Draft documents are available 377 from and numerous mirror sites. 379 [1] P. V. Mockapetris. "Domain names - concepts and 380 facilities," RFC 1034. November 1987. 382 [2] P. V. Mockapetris. "Domain names - implementation 383 and specification," RFC 1035. November 1987. 385 [3] C. Weider, J. Reynolds, S. Heker. "Technical Over- 386 view of Directory Services Using the X.500 Proto- 387 col," RFC 1309. March 1992. 389 [4] M. Hamilton, R. Wright. "Use of DNS Aliases for 390 Network Services," Internet Draft (work in pro- 391 gress). June 1996. 393 [5] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying 394 the location of services (DNS SRV)," RFC 2052. 395 October 1996. 397 [6] M. F. Schwartz. "Netfind Support for URL-Based 398 Search Customization," June 28, 1994. 399 402 [7] M. F. Schwartz, C. Pu. "Applying an Information 403 Gathering Architecture to Netfind: A White Pages 404 Tool for a Changing and Growing Internet," Univer- 405 sity of Colorado Technical Report CU-CS-656-93. 406 December 1993, revised July 1994. 407 410 [8] J. Postel, C. Anderson. "White Pages Meeting 411 Report," RFC 1588. February 1994. 413 [9] T. Berners-Lee, L. Masinter & M. McCahill. "Uni- 414 form Resource Locators (URL)," RFC 1738. December 415 1994. 417 [10] R. Hedberg, S. Dorner, and P. Pomes. "The CCSO 418 Nameserver (Ph) Architecture," Internet Draft (work 419 in progress), January 1996. 421 [11] K. Harrenstien, M. K. Stahl, E.J. Feinler. 422 "NICNAME/WHOIS," RFC 954. October 1985. 424 [12] D. Crocker. "Standard for the format of ARPA 425 Internet text messages," RFC 822. August 1982. 427 [13] D. Zimmerman. "The Finger User Information Proto- 428 col," RFC 1288. December 1992. 430 [14] J. Postel, J .K. Reynolds. "Telnet Protocol 431 specification," RFC 855. May 1983. 433 [15] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, 434 D. Torrey & B. Albert. "The Internet Gopher Proto- 435 col (a distributed document search and retrieval 436 protocol)," RFC 1436. March 1993. 438 [16] D. E. Eastlake 3rd, C. W. Kaufman. "Domain Name 439 System Security Extensions," Internet Draft (work 440 in progress). August 1996. 442 [17] E. Guttman, "The service: URL Scheme," Internet 443 Draft (work in progress), November 1996. 445 [18] R. Daniel, M. Mealling. "Resolution of Uniform 446 Resource Identifiers using the Domain Name System," 447 Internet Draft (work in progress), Oct. 30 1996. 449 [19] R. Moats, "Defining White Pages and Yellow Pages 450 Services," Internet Draft (work in progress), 451 February, 1997. 453 [20] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, 454 "Service Location Protocol," Internet Draft (work 455 in progress), January 1997. 457 11. Authors' addresses 459 Ryan Moats 460 AT&T 461 15621 Drexel Circle 462 Omaha, NE 68135-2358 463 USA 465 Phone: +1 402 894-9456 466 EMail: jayhawk@ds.internic.net 468 Martin Hamilton 469 Department of Computer Studies 470 Loughborough University of Technology 471 Leics. LE11 3TU, UK 473 Email: m.t.hamilton@lut.ac.uk 475 This Internet Draft expires August 31, 1997.