Chas Honton Document: draft-honton-sdp-01.txt Secant Technologies Internet Draft December 1997 Expire on June 28, 1998 Service Discovery Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Summary The Service Discovery Protocol allows clients to use a well-known multicast address to discover the unicast interface of a close cooperating server for a desired service port. 1. Introduction In a dynamic network environment where servers come and go, it's sometimes hard for a network administrator to keep client programs up to date where the closest server is. The difficulty is compounded when there is a desire to have backup servers in case of a host or communication failure. The service discovery protocol allows clients to use multicasting to find the closest cooperating server. 2. Design Goals There are three major design goals; 1) Client can find a server (preferably a "close" one). 2) Client can authenticate the server and vice versa. 3) Simple implementation for both client and server -- No central repository or third party is required. Honton [Page 1]
Internet DRAFT Service Discovery Protocol December 29, 1997 3. Operation In this section the notation <interface, port> indicates an ip address consisting of an interface number and port number. The Service Discovery Protocol uses multicast address 224.0.1.67 (serv-discovery). Initially, the server process binds to UDP address <serv-discovery, provided service port> in addition to its <standard unicast interface, provided service port>. A client searching for a particular service will send a UDP message containing a client token to <serv-discovery, desired service port>. The client token may be of any length which fits into a single UDP packet. When the message is received, the server will validate the client token and optionally reply to the the packet's originating address. The reply UDP message contains the server unicast interface number (four bytes in network order) and server token. The server token may be of any length which will fit into a single UDP packet. The Time-To-Live (TTL) of the first packet the client sends will be one. After a suitable timeout with no replies, the client will increment (by one or more) the TTL and resend the client token to <serv-discovery, desired service port>. In this algorithm, the client is specifing an ever widening network domain and the closest service provider will be the first to respond. The client is not expected to cache any unicast addresses found. Client Server ------ ------ ________ | client | | token | --> <SDP interface, desired service port> |________| __________________ | service | server | <originating interface, originating port> <-- | address | token | |_________|________| 4. Authentication The client token can be used by the server in conjunction with the originating host address to determine if the searching client belongs to the same security domain as the server. Likewise, the server token can be used by the client to determine if the responding server belongs to the client's security domain. Honton [Page 2]
Internet DRAFT Service Discovery Protocol December 29, 1997 When no authentication is required, the client can send an empty client token. The server likewise returns an packet with a zero length server token. When server-only authentication is required, the client sends a variable length seed in the client token. The server responds to or ignores the client based on the client's interface number and/or host domain. If the server responds, the return server token is the 8-octet digest obtained from applying the MD5 algorithm [RFC1321] to the concatentation of the seed and the security domain key. The client determines if the server belongs to the client's security domain by comparing the received digest with the expected return digest. When mutual authentication is required, the client sends an 8-octet digest followed by a variable length seed in the client token. The digest is obtained by applying the MD5 algorithm to the concatentation of the seed and the security domain key. The server validates the client token by reevaluating the digest and comparing the result with the digest in the client token. If the server responds, the return server token is the 8-octet digest obtained from applying the MD5 algorithm to the concatentation of the seed and the security domain key. The client determines if the server belongs to the client's security domain by comparing the received digest with the expected return digest. 5. Known limitation An ever widening multicast search is known to find servers which are closer in hops but further away in time, eg. one hop away across a 56K serial line instead of three 100M LAN hops. One solution is using different security domains on each side of the serial line. Another solution is to have routers not pass through any serv-discovery packets. A third alternative is to have the client increment the TTL by more than one after each multi-cast and then use the first (fastest) reply which is acceptable. 6. Retrofitting current clients and servers To upgrade a client to use with the Service Discovery Protocol, the initial binding to a server will use a UDP socket with To upgrade a server to use the Service Discovery Protocol, an additional UDP socket will need to be added to the select list. The process loop will then check for messages, authenticate the client token, and optionally repond to the client. Honton [Page 3]
Internet DRAFT Service Discovery Protocol December 29, 1997 Inet launched servers need not be changed. Inet can be upgraded to listen to the required serv-discovery ports and authenticate as well as repond for its list of servers. 7. Security Considerations The minimum suggested security is server-only authentication. This arrangement prevents clients from using rogue servers. If the server needs to authenticate the client in more robust manner than just knowledge of the client's address permits, mutual authentication should be used. When using mutual authentication, the client send/server receive security domain key may be different than the server send/client receive security domain key. In all security arrangements, security domain keys should be configurable and, of course, be kept secret. The client generated seed should change with the start of each discovery and should be randomized. 8. References [RFC1112] Deering, S. "Host Extensions for IP Multicasting", Stanford University, August 1989 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science, April 1992. 9. Author's Address Charles Honton Secant Technologies Phone: 216 595 3830 Fax: 216 595 0199 EMail: chas@secant.com Honton [Page 4]