idnits 2.17.1 draft-honton-sdp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 188 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 31, 1998) is 9400 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Chas Honton 2 draft-honton-sdp-02.txt Secant Technologies 3 Internet Draft January 1997 4 Expires July 31, 1998 6 Simple Server Discovery Protocol 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Summary 29 The Simple Server Discovery Protocol allows clients to use a 30 multicast address to discover the unicast interface of a 31 cooperating server for a desired service port and optionally 32 authenticate the identity of the client and/or server. 34 1. Introduction 36 In a dynamic network environment where servers come and go, it's 37 sometimes hard for a network administrator to keep client programs 38 up to date where the closest server is. This difficulty is 39 compounded when there is a desire to have backup servers in case of 40 a host or communication failure. The Simple Server Discovery 41 Protocol (SSDP) allows clients to use multicasting to find the 42 closest cooperating server. SSDP does not allow 44 2. Design Goals 46 There are three major design goals; 47 1) Client can find a server (preferably a "close" one). 48 2) Client can authenticate the server and vice versa. 49 3) Simple implementation for both client and server -- No central 50 repository or third party is required. 52 3. Operation 54 In this section the notation indicates an IP 55 address consisting of an interface number and port number. 57 The Simple Server Discovery Protocol uses multicast address 58 224.0.1.67 (serv-discovery). 60 Initially, the server process binds to UDP address in addition to its . A client searching for a 63 particular service will send a UDP packet containing a client 64 token to . The client token 65 may be of any length which fits into a single UDP packet. 67 When the packet is received, the server will validate the client 68 token and optionally reply to the the packet's originating address. 69 The reply UDP packet contains a server token. The server token 70 may be of any length which will fit into a single UDP packet. 72 The Time-To-Live (TTL) of the first packet the client sends will be 73 one. After a suitable timeout with no replies, the client will 74 increment (by one or more) the TTL and resend the client token to 75 . The client should wait at 76 least one second between retries. The client should not increase 77 the TTL to extend beyond acceptable network boundaries. 79 With this algorithm, the client is specifing an ever widening 80 network domain and usually the closest service provider will be the 81 first to respond. The client is not expected to cache any unicast 82 addresses found. 84 4. Known limitation 86 An ever widening multicast search is known to find servers which 87 are closer in hops but further away in time, eg. one hop away 88 across a 56K serial line instead of three 100M LAN hops. One 89 solution is using different security domains (see section 6) on 90 each side of the serial line. Another solution is to have routers 91 not pass through any serv-discovery packets on slow lines. A third 92 alternative is to have the client increment the TTL by more than 93 one after each multi-cast and then use the first (fastest) reply 94 which is acceptable. 96 5. Client and Server Tokens 98 Client and Server Tokens can be used to identify some quality of 99 service desired. The client can use its token to request a 100 particular quality and the server can use its token to offer a 101 particular quality. Additionally, the tokens can be used to 102 authenticate whether the client/server belongs to a particular 103 security domain. The following section recommends two 104 authentication schemes using the tokens. 106 6. Authentication 108 An authentication token consists of a 16-octet MD5 digest [RFC1321] 109 followed by a variable length seed. The digest is obtained by 110 applying the MD5 algorithm to the concatentation of the seed, the 111 sender's interface number (in network order), the sender's port 112 number (in network order), and the sender's security domain key. 113 The receiver validates an authentication token by reevaluating the 114 digest and comparing that result with the received digest. 115 Validation requires the sender and receiver to know the same 116 security domain key. 118 When server-only authentication is required, the client sends an 119 empty client token. The server responds to or ignores the client 120 request based on the client's interface number and/or host domain. 121 If the server responds with an authentication token, the client 122 validates the return server authentication token. 124 When mutual authentication is required, the client sends an 125 authentication token. The server validates the client token and 126 responds to or ignores the client request. If the server responds, 127 the return server authentication token will be validated by the 128 client. 130 7. Retrofitting current clients and servers 132 To upgrade a client to use the Simple Server Discovery Protocol, 133 instead of using some persistent data, a UDP socket will be used to 134 multicast and then listen for a cooperating server. 136 To upgrade a server to use the Simple Server Discovery Protocol, an 137 additional UDP socket will need to be added to the select list. 138 The process loop will then check for packets, authenticate the 139 client token, and optionally repond to the client. 141 Inet launched servers need not be changed. Inet can be upgraded to 142 listen to the required serv-discovery ports and authenticate as 143 well as repond for its list of servers. 145 8. Administration 147 Use of the Simple Server Discovery Protocol multicast address will 148 require some administrative decisions. In particular, where are 149 SSDP packets routed and where are they blocked? Which SSDP packets 150 should be tunnelled through the internet or network providers to 151 various outlying campuses of corporate networks? 153 9. Security Considerations 155 The minimum suggested security is server-only authentication. This 156 arrangement prevents clients from using rogue servers. 158 If the server needs to authenticate the client in more robust 159 manner than just knowledge of the client's address permits, mutual 160 authentication should be used. 162 When using mutual authentication, the client send/server receive 163 security domain key may be different than the server send/client 164 receive security domain key. 166 In all security arrangements, security domain keys should be 167 configurable and, of course, be kept secret. The generated 168 seeds should change with the start of each discovery and should 169 not be monotonic. 171 10. References 173 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT 174 Laboratory for Computer Science, April 1992. 176 11. Author's Address 178 Charles Honton 179 Secant Technologies 181 Phone: 216 595 3830 182 Fax: 216 595 0199 184 EMail: chas@secant.com