INTERNET DRAFT		EXPIRES MAY 1998	INTERNET DRAFT

			Service Discovery Protocol
                     <draft-rfced-info-honton-00.txt>

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 learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

Summary

   This document suggests a protocol using a well-known multicast address
   [RFC1112] to discover the interface of the closest service provider
   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 (SDP)
   described in this memo allows clients to use multicasting to find the
   closest cooperating server.


2. Operation

   In the following discussion, an address is an interface and port pair
   which will be indcated by <interface, port>.

   Initially, the server process binds to <SDP multicast interface,
   provided service port> in addition to <standard unicast interface,
   provided service port>.  A client searching for a particular service
   will send a UDP message containing a client security token to <SDP
   multicast interface, desired service port>.  The client security
   token may be of any length which fits into a single UDP packet.

   When the message is received, the server will validate the client
   security 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 security token.  The
   server security token may be of any length which will fit into a
   single UDP packet.

   The Time-To-Live (TTL) of the initially sent packet will be one.
   After a suitable timeout with no replies, the client will increment
   the TTL and resend the client security token to <SDP multicast
   interface, desired service port>.  This allows the client to search
   an ever widening network domain and allows the closest service
   provider to be discovered first.

           Client                             Server
           ------                             ------
         ________
        | client |    -->          <SDP interface, desired service port>
        | token  |
        |________|

                                                    __________________
   <originating interface, originating port>  <--  | service | server |
                                                   | address | token  |
                                                   |_________|________|

3. Security Considerations

   The client security 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 security token can be used by the client to determine if
   the responding server belongs to the client's security domain.

   The minimum suggested security arrangment is to have the client send
   a seed in the client security token.  The server responds to or
   ignores the client based on the client's interface number.  If the
   server responds, the server security 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
   can then determine if the server belongs to the client's security
   domain by comparing the received digest with the expected return
   digest.  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, a mutual
   authentication arrangement is required.  In this case, the suggested
   security token consists of an 8-octet digest followed by a variable
   length seed.  The digest is obtained by applying the MD5 algorithm to
   the concatentation of the seed and the security domain key.  The
   receiver can validate the token by reevaluating the digest and
   comparing the result with the digest in the security token.

   In the mutual authentication arrangement, 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.  Client generated seeds should change with the start of each
   discovery.  Server generated seeds should change with every reply.


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

5. Author's Address

   Charles Honton
   Secant Technologies

   Phone: 216 595 3830
   Fax:   216 595 0199

   EMail: chas@secant.com

INTERNET DRAFT		EXPIRES MAY 1998	INTERNET DRAFT