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]