idnits 2.17.1 draft-johnson-dhc-server-override-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 24, 2002) is 7853 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) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-auth-suboption-00 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Richard Johnson 3 Internet Draft Kim Kinnear 4 Expiration: April 2003 Mark Stapp 5 File: draft-johnson-dhc-server-override-00.txt Jay Kumarasamy 6 Cisco Systems, Inc. 8 DHCP Server-ID Override Suboption 9 11 October 24, 2002 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This memo defines a new suboption of the DHCP relay information 41 option [6] which allows the DHCP relay to specify a new value for the 42 Server-ID option, which is inserted by the DHCP Server. In some 43 cases it is convenient for the DHCP relay to act as the actual DHCP 44 server such that DHCP RENEWAL requests will come to the relay instead 45 of going to the server directly. This gives the relay the 46 opportunity to include the Relay Agent option with appropriate 47 suboptions even on RENEWAL messages. 49 This new relay agent suboption allows the relay to tell the DHCP 50 server what value to use in the Server-ID option [3]. If this 51 suboption is not present, the server should build the Server-ID 52 option in the normal fashion. 54 1.0 Introduction 56 There are many situations where the DHCP relay is involved and can 57 insert a relay agent option with appropriate suboptions easily into 58 DHCP DISCOVER messages. Once the lease has been granted, however, 59 future DHCP RENEWAL messages are sent directly to the DHCP Server as 60 specified in the Server-ID option. This means that the relay may not 61 see the DHCP RENEWAL messages (depending upon network topology) and 62 thus can not provide the same relay agent option information 63 in the RENEWAL messages. 65 This new DHCP relay agent suboption, Server-ID override, allows the 66 relay to tell the DHCP server what value to place into the Server-ID 67 option. Using this, the relay agent can force RENEWAL messages to 68 come to it instead of the server. The relay may then insert the 69 relay agent option with appropriate suboptions and relay the request 70 to the actual server. In this fashion the DHCP server will be 71 provided with the same relay agent information upon renewals (such as 72 Circuit-ID, Remote-ID, Device Class, etc.) as was provided in the 73 initial DISCOVER message. In effect, this makes a RENEWAL into a 74 REBINDING. 76 This new suboption could also be used by the DHCP relay in order to 77 allow the relay to appear as the actual DHCP server to the client. 78 This has the advantage that the relay can more easily keep up-to-date 79 information about leases granted, etc. 81 1.1 Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC-2119 [1]. 87 2.0 Server-ID Override Suboption Definition 89 The format of the suboption is: 91 Code Len Overridden Server-ID address 92 +-----+-----+-----+-----+-----+-----+ 93 | TBD | n | a1 | a2 | a3 | a4 | 94 +-----+-----+-----+-----+-----+-----+ 96 The option length (n) is 4. The octets "a1" through "a4" specify the 97 value which SHOULD be inserted into the Server-ID option by the DHCP 98 Server upon reply. 100 DHCP Servers SHOULD use this value as the value to insert into the 101 Server-ID option ONLY when the protocol is in the SELECTING and 102 REQUESTING and REBINDING states. If this suboption appears in a DHCP 103 request which is part of a lease RENEWAL, it SHOULD be ignored. 105 3.0 IANA Considerations 107 None. 109 4.0 Acknowledgements 111 This document is the result of work done within Cisco Systems. 112 Thanks to Jay Kumarasamy, Kim Kinnear, and Mark Stapp for their work 113 on this suboption definition and the other related work for which 114 this is necessary. 116 5.0 Security Considerations 118 Message authentication in DHCP for intradomain use where the out-of- 119 band exchange of a shared secret is feasible is defined in RFC 3118 120 [5]. Potential exposures to attack are discussed in section 7 of the 121 DHCP protocol specification in RFC 2131 [2]. 123 The DHCP Relay Agent option depends on a trusted relationship between 124 the DHCP relay agent and the server, as described in section 5 of RFC 125 3046. While the introduction of fraudulent relay-agent options can 126 be prevented by a perimeter defense that blocks these options unless 127 the relay agent is trusted, a deeper defense using the authentication 128 option for relay agent options [4] SHOULD be deployed as well. 130 If a rouge DHCP relay were inserted between the client and the 131 server, it could redirect clients to it using this suboption. This 132 would allow such a system to later deny renew requests and thus force 133 clients to discontinue use of their allocated address. This 134 interception, however, would need to be done during the initial 135 DISCOVER and OFFER phase, since the suboption value SHOULD be ignored 136 by the server during RENEWAL state. Either DHCP Authentication [5] 137 or DHCP Relay Agent option authentication [4] would address this 138 case. 140 References 142 [1] Bradner, S., "Key words for use in RFCs to Indicate 143 Requirement Levels", RFC 2119, BCP 14, March 1997. 145 [2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 146 March 1997. 148 [3] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 149 Extensions", RFC 2132, March 1997. 151 [4] Stapp, M. "The Authentication Suboption for the DHCP 152 Relay Agent Option", draft-ietf-dhc-auth-suboption-00.txt, 153 June 23, 2002 155 [5] Droms, R. "Authentication for DHCP Messages", RFC 3118, 156 June 2001 158 [6] Patrick, M., "DHCP Relay Agent Information Option", 159 RFC 3046, January 2001 161 Author Information: 163 Richard Johnson 164 Jay Kumarasamy 165 Cisco Systems 166 170 W. Tasman Dr. 167 San Jose, CA 95134 169 Phone: (408) 526-4000 171 EMail: jayk@cisco.com 172 raj@cisco.com 174 Kim Kinnear 175 Mark Stapp 176 Cisco Systems 177 250 Apollo Drive 178 Chelmsford, MA 01824 180 Phone: (978) 244-8000 182 EMail: kkinnear@cisco.com 183 mjs@cisco.com