idnits 2.17.1 draft-honton-sdp-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 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 (June 28, 1998) is 9433 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) == Unused Reference: 'RFC1112' is defined on line 176, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Chas Honton 2 Document: draft-honton-sdp-01.txt Secant Technologies 3 Internet Draft December 1997 4 Expire on June 28, 1998 6 Service Discovery Protocol 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Summary 29 The Service Discovery Protocol allows clients to use a well-known 30 multicast address to discover the unicast interface of a close 31 cooperating server for a desired service port. 33 1. Introduction 35 In a dynamic network environment where servers come and go, it's 36 sometimes hard for a network administrator to keep client programs 37 up to date where the closest server is. The difficulty is 38 compounded when there is a desire to have backup servers in case of 39 a host or communication failure. The service discovery protocol 40 allows clients to use multicasting to find the closest cooperating 41 server. 43 2. Design Goals 45 There are three major design goals; 46 1) Client can find a server (preferably a "close" one). 47 2) Client can authenticate the server and vice versa. 48 3) Simple implementation for both client and server -- No central 49 repository or third party is required. 51 Internet DRAFT Service Discovery Protocol December 29, 1997 53 3. Operation 55 In this section the notation indicates an ip 56 address consisting of an interface number and port number. 58 The Service Discovery Protocol uses multicast address 224.0.1.67 59 (serv-discovery). 61 Initially, the server process binds to UDP address in addition to its . A client searching for a 64 particular service will send a UDP message containing a client 65 token to . The client token 66 may be of any length which fits into a single UDP packet. 68 When the message is received, the server will validate the client 69 token and optionally reply to the the packet's originating address. 70 The reply UDP message contains the server unicast interface number 71 (four bytes in network order) and server token. The server token 72 may be of any length which will fit into a single UDP packet. 74 The Time-To-Live (TTL) of the first packet the client sends will be 75 one. After a suitable timeout with no replies, the client will 76 increment (by one or more) the TTL and resend the client token to 77 . In this algorithm, the 78 client is specifing an ever widening network domain and the closest 79 service provider will be the first to respond. The client is not 80 expected to cache any unicast addresses found. 82 Client Server 83 ------ ------ 84 ________ 85 | client | 86 | token | --> 87 |________| 88 __________________ 89 | service | server | 90 <-- | address | token | 91 |_________|________| 93 4. Authentication 95 The client token can be used by the server in conjunction with the 96 originating host address to determine if the searching client 97 belongs to the same security domain as the server. Likewise, the 98 server token can be used by the client to determine if the 99 responding server belongs to the client's security domain. 101 Internet DRAFT Service Discovery Protocol December 29, 1997 103 When no authentication is required, the client can send an empty 104 client token. The server likewise returns an packet with a zero 105 length server token. 107 When server-only authentication is required, the client sends a 108 variable length seed in the client token. The server responds to 109 or ignores the client based on the client's interface number and/or 110 host domain. If the server responds, the return server token is 111 the 8-octet digest obtained from applying the MD5 algorithm 112 [RFC1321] to the concatentation of the seed and the security domain 113 key. The client determines if the server belongs to the client's 114 security domain by comparing the received digest with the expected 115 return digest. 117 When mutual authentication is required, the client sends an 8-octet 118 digest followed by a variable length seed in the client token. The 119 digest is obtained by applying the MD5 algorithm to the 120 concatentation of the seed and the security domain key. The server 121 validates the client token by reevaluating the digest and comparing 122 the result with the digest in the client token. If the server 123 responds, the return server token is the 8-octet digest obtained 124 from applying the MD5 algorithm to the concatentation of the seed 125 and the security domain key. The client determines if the server 126 belongs to the client's security domain by comparing the received 127 digest with the expected return digest. 129 5. Known limitation 131 An ever widening multicast search is known to find servers which 132 are closer in hops but further away in time, eg. one hop away 133 across a 56K serial line instead of three 100M LAN hops. One 134 solution is using different security domains on each side of the 135 serial line. Another solution is to have routers not pass through 136 any serv-discovery packets. A third alternative is to have the 137 client increment the TTL by more than one after each multi-cast and 138 then use the first (fastest) reply which is acceptable. 140 6. Retrofitting current clients and servers 142 To upgrade a client to use with the Service Discovery Protocol, the 143 initial binding to a server will use a UDP socket with 145 To upgrade a server to use the Service Discovery Protocol, an 146 additional UDP socket will need to be added to the select list. 147 The process loop will then check for messages, authenticate the 148 client token, and optionally repond to the client. 150 Internet DRAFT Service Discovery Protocol December 29, 1997 152 Inet launched servers need not be changed. Inet can be upgraded to 153 listen to the required serv-discovery ports and authenticate as 154 well as repond for its list of servers. 156 7. Security Considerations 158 The minimum suggested security is server-only authentication. This 159 arrangement prevents clients from using rogue servers. 161 If the server needs to authenticate the client in more robust 162 manner than just knowledge of the client's address permits, mutual 163 authentication should be used. 165 When using mutual authentication, the client send/server receive 166 security domain key may be different than the server send/client 167 receive security domain key. 169 In all security arrangements, security domain keys should be 170 configurable and, of course, be kept secret. The client generated 171 seed should change with the start of each discovery and should be 172 randomized. 174 8. References 176 [RFC1112] Deering, S. "Host Extensions for IP Multicasting", 177 Stanford University, August 1989 179 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT 180 Laboratory for Computer Science, April 1992. 182 9. Author's Address 184 Charles Honton 185 Secant Technologies 187 Phone: 216 595 3830 188 Fax: 216 595 0199 190 EMail: chas@secant.com