idnits 2.17.1 draft-ietf-dhc-slp-04.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-19) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) == Outdated reference: A later version (-15) exists of draft-ietf-svrloc-protocol-v2-04 Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins 2 INTERNET DRAFT E. Guttman 3 Sun Microsystems 4 09 October 1998 6 DHCP Options for Service Location Protocol 7 draft-ietf-dhc-slp-04.txt 9 Status of This Memo 11 This document is a submission by the Dynamic Host Configuration 12 Working Group of the Internet Engineering Task Force (IETF). 13 Comments should be submitted to the dhcp-v4@bucknell.edu mailing 14 list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check 29 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 The Dynamic Host Configuration Protocol provides a framework for 37 passing configuration information to hosts on a TCP/IP network. 38 Entities using the Service Location Protocol need to find out the 39 address of Directory Agents in order to transact messages. Another 40 option provides an assignment of scope for configuration of SLP User 41 and Service Agents. 43 1. Introduction 45 The Dynamic Host Configuration Protocol [3] provides a framework 46 for passing configuration information to hosts on a TCP/IP network. 47 Entities using the Service Location Protocol, Version 2 [4] need to 48 obtain the address of Directory Agents and Scope configuration. The 49 Service Location Protocol (SLP) provides a default configuration 50 for Scopes and Directory Agents may be discovered using multicast 51 or broadcast. It is useful in a larger deployment to be able 52 to configure SLP Agents using DHCP, so as to centralize the 53 administration and to deploy SLP in networks where multicast routing 54 is not available. 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [1]. 60 2. Introduction 62 The DHCP options described below are used to configure Agents using 63 the Service Location Protocol, Version 2. 65 The SLP Directory Agent option is used to configure User Agents and 66 Service Agents with the location of Directory Agents in the network. 67 These Directory Agents are assumed to support all of the scopes 68 supplied by the SLP Scope Option. 70 If the SLP Scope Option is absent, the scope string "default" is 71 used instead. If there is a scope string configured using local 72 configuration on the host that is used if no SLP Scope Option has 73 been sent. DHCP configuration takes precedence over the local 74 configuration of SLP scope lists. SLP Agents (be they Directory 75 Agents, User Agents or Service Agents) which use the SLP Directory 76 Agent Option MUST be configured with a scope. 78 3. SLP Directory Agent Option 80 This option specifies the location of one or more SLP Directory 81 Agents. 83 0 1 2 3 84 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | Code = 78 | Length | a1 | a2 | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | a3 | a4 | a1 | ... 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 The SLP Directory Agent Option specifies a list of IP addresses 91 for Directory Agents. Directory Agents MUST be listed in order of 92 preference, if there is an order of preference. 94 The address of the Directory Agent is given in network byte order. 95 The length of the option MUST always be divisible by 4 and has a 96 minimum length of 4. 98 The Directory Agents listed in this option MUST be configured with 99 the a non-empty subset of the scope list that the Agent receiving the 100 Directory Agent Option is configured with. See the notes below. 102 SLPv2 Service Agents which are configured using the SLP Directory 103 Agent Option MUST send a SrvRqst to the DAs in the DHCPOFFER. This 104 SLPv2 SrvRqst sets the Scope List to the value configured by the SLP 105 Scope Option if one was sent or "DEFAULT" otherwise. The service 106 type for the request is "service:directory-agent" and the predicate 107 is omitted. The reply will include the DA's attributes, scope list. 109 The SA MUST register all service with the DA which it advertises 110 which are advertised in one or more of the scopes in the DA's scope 111 list. The SA MUST register no faster than the "min-lifetime" and not 112 slower than the "max-lifetime" attributes of the DA. These attributes 113 are obtained in the DAAdvert solicited by the SA after it receives 114 the SLP Directory Agent Option DHCPOFFER. 116 SLPv2 User Agents which are configured using the SLP Directory Agent 117 Option MUST send their requests to the DAs listed, using the entire 118 list of scopes they are configured with. 120 4. SLP Service Scope Option 122 The scope list is a comma delimited list which indicates the scopes 123 that a SLP Agent is configured to use. 125 0 1 2 3 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Code = 79 | Length | String ... 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 The Length indicates the number of bytes which follow. Since the 132 Scope-List String is encoded using UTF8 characters, it may be the 133 cast that the Length is not the same as the number of characters in 134 the Scope-List String. 136 The minimum length is 0, and the maximum length is 256. This imposes 137 a limit on the size of the Scope-List String which can be delivered 138 which does not exist in SLP. DHCP administrators will therefore have 139 to be careful to not configure very long scope names or very long 140 lists of scopes for any Agents in their network. 142 The Typed Scope List includes a list of scopes for the SLP Agent. 143 The list may be a list of scopes, such as "north,south,east,west". 145 The list may also include items which are 'typed scopes.' These 146 items indicate that SAs MUST advertise particular service types in 147 a scope other than that given in the scope list. UAs MUST issue 148 requests for services of these types in the scopes listed, or some 149 subset of the scopes. DAs ignore typed scopes in the SLP Service 150 Scope Option. 152 For example, "default,(service:printer:lpr=Math Department)" 153 indicates that SAs advertise all services in scope default except 154 for lpr printers, which are advertised in the Math Department scope. 155 UAs will request all services using the "default" scope, except lpr 156 printers, which are advertised in the "Math Department" scope. DAs 157 will simply be configured in the scope "default" since they ignore 158 the typed scope argument. 160 The grammar for the typed scope list is: 162 ts-list = ts-item / ts-item `,' ts-list 163 ts-item = scope-list / `(' srv-type `=' scope-list `)' 164 srv-type = ALPHA *srv-safe [ `.' 1*srv-safe ] 165 srv-safe = ALPHA / DIGIT / `+' / `-' 166 scope-list = scope-item / scope-item "," scope-list 167 scope-item = 1*safe-scope 168 safe-scope = ; Any character except rsvd-scope. 169 ; Reserved characters must be escaped. 170 rsvd-scope = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' 171 CTL / `;' / `*' / `+' 172 escaped = `$\backslash$' HEXDIGIT HEXDIGIT 174 This grammar follows ABNF rules [2]. Reserved characters used in 175 scope names must be escaped. Reserved characters in names 176 are not allowed. Note that names may include a Naming 177 Authority extension. 179 4.1. Zero Length Scope-List String Configuration 181 A SLP Service Scope Option which indicates a Length of 0 configures 182 the SLP Agent to use "User Selectable Scopes". 184 If this is done, the SLP Agent MUST NOT be configured using the SLP 185 Directory Agent Option. 187 Instead, the SLP Agent will discover scopes using Directory Agent 188 discovery (or Service Agent Discovery) as defined in [4]. 190 The SLP Agent will then use the aggregation of all scopes it 191 discovers on the network to configure its own scope list. 193 Note that this configuration is tantamount to removing all 194 centralized control of the configuration hosts on the network. This 195 makes it possible for every User Agent to see every service. This 196 may not be desirable as users may not be able to or desire to decide 197 which services are appropriate for them. 199 5. Security Considerations 201 If a malicious host is able to insert fraudulent information in 202 DHCPOFFER packets sent to a prospective SLP Agent then the SLP Agent 203 will be unable to obtain service, or may unwittingly be directed to 204 use the incorrect services. 206 Many opportunities for denial of service exist. A service agent 207 could find that it might rely on fraudulent or otherwise malicious 208 directory agents to advertise its services. DHCPOFFERs could prevent 209 the regular SLP framework from functioning by directing clients to 210 not use multicast, to use nonexistent directory agents and so on. 212 These difficulties are inherited from the much larger and more 213 serious problem, viz. securing or authenticating any information 214 whatsoever from a DHCP server (or client!) is not possible in common 215 DHCP deployments. 217 References 219 [1] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 220 Levels. RFC 2119, March 1997. 222 [2] D. Crocker and P. Overell. Augmented BNF for Syntax 223 Specifications: ABNF. RFC 2234, November 1997. 225 [3] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 226 1997. 228 [4] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service 229 Location Protocol version 2. draft-ietf-svrloc-protocol-v2-04.txt, 230 March 1998. (work in progress). 232 Author's Address 234 Questions about this memo can be directed to: 236 Charles E. Perkins Erik Guttman 237 Technology Development Group Technology Development Group 238 Mail Stop MPK15-214 Mail Stop UFRA02 239 Sun Microsystems, Inc. Sun Microsystems, Inc. 240 15 Network Circle Bahnstr. 2 241 Menlo Park, CA 94025 74915 Waibstadt, Germany 242 phone: +1 650-786-6464 phone: +49 7263 911 701 243 fax: +1 650-786-6445 or: +1 650 786 5992 244 email: Charles.Perkins@Sun.Com Erik.Guttman@Sun.Com 245 Web: http://www.svrloc.org/~charliep