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.

. 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

. 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.

. Operation

     In this section the notation <interface, port> 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 <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 packet 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 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
     <serv-discovery, desired service port>.  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.

. 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.

. 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.

. 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.

. 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.

. 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?

. 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.

. References

     [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT
               Laboratory for Computer Science, April 1992.

. Author's Address

     Charles Honton
     Secant Technologies

     Phone: 216 595 3830
     Fax:   216 595 0199

     EMail: chas@secant.com