Internet DRAFT - draft-honton-sdp
draft-honton-sdp
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 <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.
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
