Network Working Group Chas Honton draft-honton-sdp-02.txt Secant Technologies Internet Draft January 1997 Expires July 31, 1998 Simple Server 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 Simple Server Discovery Protocol allows clients to use a multicast address to discover the unicast interface of a cooperating server for a desired service port and optionally authenticate the identity of the client and/or server. 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. This difficulty is compounded when there is a desire to have backup servers in case of a host or communication failure. The Simple Server Discovery Protocol (SSDP) allows clients to use multicasting to find the closest cooperating server. SSDP does not allow 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. 3. Operation In this section the notation indicates an IP address consisting of an interface number and port number. The Simple Server Discovery Protocol uses multicast address 224.0.1.67 (serv-discovery). Initially, the server process binds to UDP address in addition to its . A client searching for a particular service will send a UDP packet containing a client token to . The client token may be of any length which fits into a single UDP packet. When the packet is received, the server will validate the client token and optionally reply to the the packet's originating address. The reply UDP packet contains a 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 . The client should wait at least one second between retries. The client should not increase the TTL to extend beyond acceptable network boundaries. With this algorithm, the client is specifing an ever widening network domain and usually the closest service provider will be the first to respond. The client is not expected to cache any unicast addresses found. 4. 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 (see section 6) on each side of the serial line. Another solution is to have routers not pass through any serv-discovery packets on slow lines. 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. 5. Client and Server Tokens Client and Server Tokens can be used to identify some quality of service desired. The client can use its token to request a particular quality and the server can use its token to offer a particular quality. Additionally, the tokens can be used to authenticate whether the client/server belongs to a particular security domain. The following section recommends two authentication schemes using the tokens. 6. Authentication An authentication token consists of a 16-octet MD5 digest [RFC1321] followed by a variable length seed. The digest is obtained by applying the MD5 algorithm to the concatentation of the seed, the sender's interface number (in network order), the sender's port number (in network order), and the sender's security domain key. The receiver validates an authentication token by reevaluating the digest and comparing that result with the received digest. Validation requires the sender and receiver to know the same security domain key. When server-only authentication is required, the client sends an empty client token. The server responds to or ignores the client request based on the client's interface number and/or host domain. If the server responds with an authentication token, the client validates the return server authentication token. When mutual authentication is required, the client sends an authentication token. The server validates the client token and responds to or ignores the client request. If the server responds, the return server authentication token will be validated by the client. 7. Retrofitting current clients and servers To upgrade a client to use the Simple Server Discovery Protocol, instead of using some persistent data, a UDP socket will be used to multicast and then listen for a cooperating server. To upgrade a server to use the Simple Server Discovery Protocol, an additional UDP socket will need to be added to the select list. The process loop will then check for packets, authenticate the client token, and optionally repond to the client. 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. 8. Administration Use of the Simple Server Discovery Protocol multicast address will require some administrative decisions. In particular, where are SSDP packets routed and where are they blocked? Which SSDP packets should be tunnelled through the internet or network providers to various outlying campuses of corporate networks? 9. 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 generated seeds should change with the start of each discovery and should not be monotonic. 10. References [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science, April 1992. 11. Author's Address Charles Honton Secant Technologies Phone: 216 595 3830 Fax: 216 595 0199 EMail: chas@secant.com