idnits 2.17.1 draft-ietf-svrloc-advertising-03.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 5 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 (October 1997) is 9689 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' -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Ryan Moats 2 draft-ietf-svrloc-advertising-03.txt AT&T 3 Expires in six months Martin Hamilton 4 Loughborough University 5 October 1997 7 Advertising Services 8 (Providing information to support service discovery) 9 Filename: draft-ietf-svrloc-advertising-03.txt 11 Status of This Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as ``work 22 in progress.'' 24 To learn the current status of any Internet-Draft, please check 25 the ``1id-abstracts.txt'' listing contained in the Internet- 26 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 27 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 This document proposes a solution to the problem of finding 33 information about that services are being offered at a particular 34 Internet domain, based on deployment experience with the Netfind 35 White Pages directory software. 37 This approach makes it possible to supply clients with more 38 information than the DNS aliases that have been widely deployed in 39 this role - notably the port numbers being used by servers. However, 40 it is not without problems, and we have tried to take account of 41 these. 43 1. Rationale 45 There is no one single way of discovering the network services and 46 application protocols supported at a particular Internet domain. The 47 Domain Name System (DNS - [1,2]) provides some basic facilities for 48 finding the hosts that offer particular services, such as DNS servers 49 themselves (NS records), and mail exchangers (MX records). It does 50 not provide a mechanism for locating arbitrary servers of arbitrary 51 protocols, or a search capability. 53 In addition to the name and IP address(es) of the host offering the 54 service, clients also sometimes require further information to make 55 effective use of the service - e.g. TCP or UDP port numbers, protocol 56 version information, and information about the protocol options 57 supported by the server. Another example would be the organization's 58 base within the X.500 [3] Directory Information Tree (DIT), that is 59 needed for X.500 browsing and searching. 61 At the time of writing, it was common practice to "hint" at the 62 services and protocols offered at a given domain via DNS aliases. For 63 example, the alias "www.internic.net" implies that the HTTP server 64 for the domain "internic.net" is running on TCP port 80 of the 65 machine (or machines) that answer to the name "www.internic.net." A 66 slight formalization of this approach is proposed by [4]. Other 67 schemes have been suggested for explicitly registering services 68 either by DNS extensions, as in [5], or by dedicated directory 69 services such as X.500. 71 Several mechanisms have been suggested to address the problem of 72 finding this service information, ranging from new DNS record types 73 to dedicated directory services. No single one of these would-be 74 solutions has as yet gained the competitive edge. If the lengthy 75 gestation period to date is anything to go by, it seems that we can 76 expect even more delay before there is any widespread deployment - 77 unless there is a "killer application" that forces the issue. 79 2. Where Netfind has gone before 81 The Netfind software [6,7] follows what has been proposed in RFC 1588 82 [8]: using URLs [9] for passing directory service information to 83 clients. It uses stylized Text (TXT) record encoding within the DNS 84 and currently understands the following "White Pages" URLs: 86 ----------------------------------------------------------- 87 White Pages URL Information 88 ----------------------------------------------------------- 89 wp-noop:// This site should not be visited 90 wp-dap:// X.500 search base for the site 91 e.g. wp-dap://o=Loughborough%20University,c=GB 92 wp-ph://host/port Suggests CCSO nameserver [10] 93 wp-whois://host/port Suggests WHOIS [11] server 94 wp-smtp-expn-finger://host Use the SMTP [12] EXPN command, 95 and the finger [13] protocol 96 wp-smtp-expn://host/port Suggests the SMTP EXPN command 97 wp-finger://host/port Suggests the finger protocol 98 wp-telnet://host/port Suggests a text based info 99 service that should be used 100 via telnet [14] 101 ----------------------------------------------------------- 103 Note that the notation "protocol://host/port" is used, rather than 104 the "protocol://host:port" format that is being standardized for 105 generic URLs. 107 Note also that these URL schemes have not all been standardized, 108 although wp-ph and wp-whois may be accommodated by translation to the 109 widely supported Internet Gopher Protocol [15]. 111 3. A simple interim solution 113 In this document, we propose that the "service:" URL scheme as 114 described in [17] be encoded in DNS TXT records as a solution. With 115 this scheme, software agents would do a DNS lookup on 116 .. The TXT record associated with 117 . would have the following syntax: 119 IN TXT " [preference] [protocol specific 120 information]" 122 where the preference value and protocol specific information are 123 optional and are separated by spaces. Alternatively, software agents 124 could do a lookup on the parent domain, but this could lead to 125 overloading the DNS response packet. 127 Further, the Service URL scheme supports the concept of abstract 128 service types which are very useful for white pages service 129 advertisement. For general white pages discovery, we propose that 130 software agents do a DNS lookup on wp.. Here, the TXT 131 records would contain URLs of the "wp:" abstract service type as 132 documented in [19]. For example, the TXT records for wp.lut.ac.uk 133 could be written as 135 service:wp:ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of%20 136 Technology,c=GB 137 service:wp:http://www.lut.ac.uk/cgi-bin/local 139 Whilst not an optimal solution, for reasons we will discuss below, 140 this approach does provide an additional level of flexibility and 141 only requires a trivial amount of work to deploy - typically adding a 142 single line to the site's DNS configuration file for each service 143 being advertised. 145 4. Further details and usage scenarios 147 4.1. Finding "White Pages" information 149 This case is already catered for by the Netfind "wp-" prefix. To 150 advertise their White Pages services explicitly, a site would create 151 one or more TXT records under both wp and the service being 152 advertised, e.g. 154 wp IN TXT "service:wp:ldap://ldap.lut.ac.uk/o=Loughborough%20University 155 %20of%20Technology,c=GB" 156 wp IN TXT "service:wp:whois://whois.lut.ac.uk/" 157 wp IN TXT "service:wp:ccso://cso.lut.ac.uk/2" 159 ldap IN TXT "service:wp:ldap://ldap.lut.ac.uk/o=Loughborough%20University 160 %20of%20Technology,c=GB" 162 whois IN TXT "service:wp:whois://whois.lut.ac.uk/" 164 ph IN TXT "service:wp:ccso://cso.lut.ac.uk/2" 166 Another example showing the possibility of multiple protocols for 167 accessing a service would be (the domain for this example is 168 aecom.yu.edu): 170 ns IN TXT "service:wp:gopher://gopher.aecom.yu.edu/2" 171 ns IN TXT "service:wp:http://www.middlebury.edu/cgi-bin/ 172 WebPh?other_ph_servers" 173 ns IN TXT "service:wp:http://faker.ncsa.uiuc.edu:8080/cgi-bin/phfd" 175 It is envisaged that this information could be used in some 176 scenarios. Assuming their Internet domain is already known, mail 177 user agents with integrated support could offer to do directory 178 service lookups to determine a correspondent's address from their 179 name, to verify the contents of address books, and to determine 180 alternative email addresses should delivery fail. This last 181 technique might also be applied by lower level mail delivery 182 software. 184 4.3. Public key lookup 186 Attempts to build a scalable infrastructure for the distribution of 187 public key information, in particular for the public keys of 188 individuals, have been hampered by the lack of a convention that 189 could be used to suggest the public key servers for a site or 190 organization. 192 For these examples, we postulate a abstract service type "keys:", 193 e.g. 195 keys IN TXT "service:keys:finger://mrrl.lut.ac.uk 5" 197 lut.ac.uk IN TXT "service:keys:finger://mrrl.lut.ac.uk 5" 199 It does not, however, address the issue of public key (certificate) 200 format. It is expected that this would be taken care of by format 201 negotiation in the protocol or protocols being used to do the lookup. 203 Public key lookup would be of immediate use in software that has 204 integrated support for public key authentication, signing and 205 encryption - e.g. mail and news user agents. 207 4.4. Finding "Yellow Pages" information 209 By "Yellow Pages" we mean a catch-all category: information about 210 services offered that do not fall into any of the above categories. 211 For this, we propose using the "yp:" abstract service type described 212 in [19]. 214 For example, consider the case of a machine that is running a HTTP 215 server - but not on the IANA registered default port (80) 217 www IN A 204.179.186.65 218 IN A 198.49.45.10 219 IN A 192.20.239.132 220 IN TXT "service:yp:http://www.ds.internic.net:8888/" 222 yp IN A 204.179.186.65 223 IN A 198.49.45.10 224 IN A 192.20.239.132 225 IN TXT "service:yp:http://www.ds.internic.net:8888/" 227 This "Yellow Pages" mechanism provides a means for DNS maintainers to 228 effectively register the existence of their major network services. 229 This can have a variety of uses - e.g. the service information is 230 available to any "web crawler" type applications that might choose to 231 index it, and to interactive applications such as World-Wide Web 232 browsers, that might use it to override their default behavior. 234 4.5 Finding "Directory Agent" information 235 The Service Location Protocol [20] provides the ability to search for 236 services according to their characteristics, as opposed to solely by 237 type. This is useful to clients that need to discover a particular 238 service in a case where a domain offers more than one service of the 239 same type and the services are not identical. Clients can discover 240 what types of services are supported, the attributes of those 241 services and can obtain service URLs by issuing structured queries. 242 Thus, a service may be discovered by description as opposed to by 243 name. 245 To do this, the Service Location Protocol defines a scheme for 246 Directory Agent discovery. The term "directory" in this context 247 refers to a directory of services as opposed to a directory of "white 248 pages" information that is used elsewhere in this document. A site 249 may wish to present services to hosts outside its domain may elect to 250 set up a Directory Agent (with the remote registration features 251 turned off, see [20]) outside its firewall. A client supporting the 252 service location protocol would then make queries for individual 253 services inside the domain. The Directory Agent would be found via 254 the following DNS entries: 256 (Domain entry) 257 catch22.com IN TXT "service:directory-agent://slp-resolver.catch22.com" 259 (host in domain catch22.com) 260 directory-agent IN TXT "service:directory-agent://slp-resolver.catch22.com" 262 5. Support in DNS clients and servers 264 This scheme is completely compatible with SRV and NAPTR (see [18]) 265 DNS records, that are currently being implemented in BIND. 267 6. Limitations of this approach 269 Note that older DNS servers may not support the TXT record type, and 270 some servers fail to implement it properly - e.g. BIND 4.9.2 misses 271 out every other letter in the TXT record. Further, support for SRV 272 has only recently been added to the BIND code base. 274 Some resolvers are not capable of requesting a TXT record, or not 275 capable of generating any DNS lookup requests other than a simple 276 address lookup. TXT records can actually be requested by setting the 277 question type in the request to 16 (decimal), regardless of the 278 symbolic names defined by the stack's resolver code. Implementing 279 more advanced resolver functionality when the stack only provides 280 address lookup requires a little work, but sample code is freely 281 available. 283 The size limitations on DNS packets will have some effect on the 284 number of URLs that can be associated with a domain name using TXT 285 records. Response packets are subject to truncation if they grow to 286 over 576 bytes. 288 Characters that are illegal in URLs must be escaped, for example: 290 "service:wp:ldap://ldap.lut.ac.uk/o=Loughborough%20University%20of 291 %20Technology,c=GB" 293 Domain name compression is normally used to reduce the size of the 294 response packet needed for a given domain name. Clearly, this will 295 not be possible on arbitrary strings embedded within the response 296 packet. 298 Widespread use of TXT records in the role proposed by this document 299 would increase the amount of information held in nameserver caches, 300 and in particular might cause problems where negative caching is 301 concerned. Consequently we suggest that clients use them as a fall 302 back mechanism if more conventional methods, such as DNS aliases, 303 prove unproductive. 305 7. Security Considerations 307 Since this draft proposes to use DNS for storage of URL information, 308 all the normal security considerations for applications that depend 309 on the DNS apply. The DNS is open to many kinds of "spoofing" 310 attacks, and it cannot be guaranteed that the result returned by a 311 DNS lookup is indeed the genuine information. Spoofing may take the 312 form of denial of service, such as directing of the client to a non- 313 existent address, or a passive attack such as an intruder's server 314 that masquerades as the legitimate one. 316 Work is ongoing to remedy this issue insofar as the DNS is concerned 317 [16]. In the meantime, note that stronger authentication mechanisms 318 such as public key cryptography with large key sizes are a pre- 319 requisite if the DNS is being used in any sensitive environment. 320 Examples of these would be on-line financial transactions, and any 321 scenario where privacy is a concern - such as the querying of medical 322 records over the network. Strong encryption of the network traffic 323 may also be advisable, to protect against TCP connection "hijacking" 324 and packet sniffing. 326 There are some additional considerations that are specific to URLs. 327 Specifically, client applications should be wary of URLs that direct 328 them to alternative Internet domains and/or unusual port numbers. 329 They should also be proactive when passing URLs to external programs, 330 to ensure that the user's environment is not exposed to malevolent 331 meta-characters. Finally, implementors should take care to avoid 332 buffer overruns when processing these DNS response packets. 334 8. Conclusions 336 Whilst far from ideal, we believe the approach outlined in this 337 document does provide a workable interim solution to the problem of 338 locating the network services offered at a particular Internet domain 339 - particularly when used in combination with DNS aliases, as outlined 340 in [4]. Suitable DNS server software is already widely deployed, and 341 client support may be implemented without any great difficulty. 343 It is debatable whether any of this is strictly necessary. Certainly 344 there is less work involved in adding a few lines to an existing DNS 345 server configuration than in setting up a whole new directory 346 service, such as X.500. From this point of view, a new DNS resource 347 record type or types would perhaps address the problem more 348 effectively, but it may be some time before any new types are widely 349 deployed. 351 9. Acknowledgments 353 Special thanks to Erik Guttman for his help with the service location 354 example, information on the "service:" scheme, as well as much e-mail 355 in working out the service schemes proposed here. Thanks to Tim 356 Howes, Sri Sataluri and members of the IETF SVRLOC and IDS working 357 groups for their comments on earlier drafts of this document. This 358 document is partially supported by the National Science Foundation, 359 Cooperative Agreement NCR-9218179, the UK Electronic Libraries 360 Programme (eLib) grant 12/39/01, and the European Commission's 361 Telematics for Research Programme grant RE 1004. 363 The format used for representing Netfind White Pages URLs within the 364 DNS was originally defined by Mike Schwartz, with help from Carl 365 Malamud and Marshall Rose. The Netfind work was supported in part by 366 grants from the National Science Foundation, the Advanced Research 367 Projects Agency, Sun Microsystems' Collaborative Research Program, 368 and AT&T Bell Laboratories. 370 Some of the points in the security considerations section were drawn 371 from [4]. 373 10. References 375 Request For Comments (RFC) and Internet Draft documents are available 376 from and numerous mirror sites. 378 [1] P. V. Mockapetris. "Domain names - concepts and 379 facilities," RFC 1034. November 1987. 381 [2] P. V. Mockapetris. "Domain names - implementation 382 and specification," RFC 1035. November 1987. 384 [3] C. Weider, J. Reynolds, S. Heker. "Technical Over- 385 view of Directory Services Using the X.500 Proto- 386 col," RFC 1309. March 1992. 388 [4] M. Hamilton, R. Wright. "Use of DNS Aliases for 389 Network Services," RFC 2219, October 1997. 391 [5] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying 392 the location of services (DNS SRV)," RFC 2052. 393 October 1996. 395 [6] M. F. Schwartz. "Netfind Support for URL-Based 396 Search Customization," June 28, 1994. 397 400 [7] M. F. Schwartz, C. Pu. "Applying an Information 401 Gathering Architecture to Netfind: A White Pages 402 Tool for a Changing and Growing Internet," Univer- 403 sity of Colorado Technical Report CU-CS-656-93. 404 December 1993, revised July 1994. 405 408 [8] J. Postel, C. Anderson. "White Pages Meeting 409 Report," RFC 1588. February 1994. 411 [9] T. Berners-Lee, L. Masinter & M. McCahill. "Uni- 412 form Resource Locators (URL)," RFC 1738. December 413 1994. 415 [10] R. Hedberg, S. Dorner, and P. Pomes. "The CCSO 416 Nameserver (Ph) Architecture," Internet Draft (work 417 in progress), January 1996. 419 [11] K. Harrenstien, M. K. Stahl, E.J. Feinler. 420 "NICNAME/WHOIS," RFC 954. October 1985. 422 [12] D. Crocker. "Standard for the format of ARPA 423 Internet text messages," RFC 822. August 1982. 425 [13] D. Zimmerman. "The Finger User Information Proto- 426 col," RFC 1288. December 1992. 428 [14] J. Postel, J .K. Reynolds. "Telnet Protocol 429 specification," RFC 855. May 1983. 431 [15] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, 432 D. Torrey & B. Albert. "The Internet Gopher Proto- 433 col (a distributed document search and retrieval 434 protocol)," RFC 1436. March 1993. 436 [16] D. E. Eastlake 3rd, C. W. Kaufman. "Domain Name 437 System Security Extensions," RFC 2065, January 438 1997. 440 [17] E. Guttman, C. Perkins, J. Kempf, "The service: URL 441 Scheme," Internet Draft (work in progress), October 442 1997. 444 [18] R. Daniel, M. Mealling. "Resolution of Uniform 445 Resource Identifiers using the Domain Name System," 446 RFC 2168, June 1997. 448 [19] R. Moats, "Defining White Pages and Yellow Pages 449 Services," Internet Draft (work in progress), 450 February, 1997. 452 [20] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, 453 "Service Location Protocol," Internet Draft (work 454 in progress), April 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 April 30, 1998.