idnits 2.17.1 draft-ietf-dhc-slp-00.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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 50: '... scope MUST be a null-terminated str...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 69 has weird spacing: '... Length vari...' -- 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 (27 August 1996) is 10103 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) ** Obsolete normative reference: RFC 1738 (ref. '1') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-16) exists of draft-ietf-svrloc-protocol-14 Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 IBM 3 27 August 1996 5 DHCP Options for Service Location Protocol 6 draft-ietf-dhc-slp-00.txt 8 Status of This Memo 10 This document is a submission to the Dynamic Host Configuration 11 Working Group of the Internet Engineering Task Force (IETF). Comments 12 should be submitted to the dhcp@bucknell.edu mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 The Dynamic Host Configuration Protocol provides a framework for 35 passing configuration information to hosts on a TCP/IP network. 36 Entities using the Service Location Protocol need to find out the 37 address of Directory Agents in order to transact messages. In 38 certain other instances they may need to discover the correct scope 39 and naming authority to be used in conjunction with the service 40 attributes and URLS which are exchanged using the Service Location 41 Protocol. 43 1. Directory Agent Extension 45 This extension specifies a Directory Agent (DA) [3], along with zero 46 or more Naming Authorities [2] known to that DA and zero or more 47 scopes supported by that DA. 49 The code for this extension is 78. Each Naming Authority and each 50 scope MUST be a null-terminated string of ASCII characters. The 51 lengths of the strings are only indicated implicitly by their null 52 termination and the overall length of the extension. 54 0 1 2 3 55 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 56 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 57 | Code | Length |D| NA count | scope count | 58 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 59 | (if present) | 60 | Directory Agent address (16 octets) | 61 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 62 | NA list ... 63 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 64 | scope list ... 65 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 67 Code 78 69 Length variable 71 D If the 'D' bit is set, the Directory Agent address is 72 present. 74 NA count 75 The number of Naming Authorities indicated by strings in 76 the NA list following. 78 scope count 79 The number of scopes indicated by strings in the scope 80 list following. 82 NA list 83 A list of strings denoting Naming Authorities. 85 scope list 86 A list of strings denoting scopes. 88 Note that more than one Directory Agent extension may be present in 89 a DHCP message. Each such extension may have the same or different 90 lists of Naming Authorities and scopes. The client may request a 91 Directory Agent with a particular scope, and/or knowledgeable about 92 schemes defined by a particular Naming Authority, by including the 93 Directory Agent extension in a DHCP Request message with no Directory 94 Agent address included (the 'D' bit set to zero), and the appropriate 95 strings in the NA list and/or scope list. 97 2. Service Scope Extension 99 This extension indicates a scope that should be used by a Service 100 Agent (SA) [3], when responding to Service Request messages as 101 specified by the Service Location Protocol. 103 Code Len 104 +-----+-----+-----+----- 105 | 79 | n | Scope ... 106 +-----+-----+-----+----- 108 Scope is a null-terminated ASCII string, of length 'n' including the 109 terminating null character. 111 3. Naming Authority Extension 113 This extension indicates a naming authority (which specifies the 114 syntax for schemes that may be used in URLs [1]) for use by entities 115 with the Service Location Protocol. 117 Code Len 118 +-----+-----+-----+-----+-----+----- 119 | 80 | n | Naming Authority ... 120 +-----+-----+-----+-----+-----+----- 122 Naming Authority is a null-terminated ASCII string, of length 'n' 123 including the terminating null character. 125 4. Security Considerations 127 If a malicious host is able to insert fraudulent information in 128 DHCPOFFER packets sent to a prospective client of the Service 129 Location Protocol, then the client will be unable to obtain service, 130 and vulnerable to disclosing information to unauthorized service 131 agents. Likewise, a service agent would find that it might rely on 132 fraudulent or otherwise malicious directory agents to advertise its 133 services. Many opportunities for denial of service exist. 135 This difficulty is inherited from the much larger and more serious 136 problem, viz. securing or authenticating any information whatsoever 137 from a DHCP server (or client!) is not possible in common DHCP 138 deployments. 140 5. Acknowledgements 142 Thanks to Erik Guttman for his helpful suggestions in the creation of 143 this draft. 145 References 147 [1] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 148 Locators (URL). RFC 1738, December 1994. 150 [2] Paul E. Hoffman and Ron Daniel, Jr. Generic URN Syntax. 151 draft-ietf-uri-urn-syntax-00.txt -- work in progress, April 1995. 153 [3] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 154 Location Protocol. draft-ietf-svrloc-protocol-14.txt - work in 155 progress, June 1996. 157 Author's Address 159 Questions about this memo can be directed to: 161 Charles Perkins 162 Room J1-A25 163 T. J. Watson Research Center 164 IBM Corporation 165 30 Saw Mill River Rd. 166 Hawthorne, NY 10532 168 Work: +1 914 7847350 169 Fax: +1 914 7847007 170 E-mail: perk@watson.ibm.com