Internet DRAFT - draft-rfced-info-honton
draft-rfced-info-honton
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 11:06:51 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 11 Nov 1997 17:31:00 GMT
ETag: "361fac-16fe-34689654"
Accept-Ranges: bytes
Content-Length: 5886
Connection: close
Content-Type: text/plain
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
