idnits 2.17.1 draft-ietf-dhc-server-override-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 16, 2007) is 5999 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 informational reference (is this intentional?): RFC 3315 (ref. '7') (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Johnson 3 Internet-Draft J. Jumarasamy 4 Expires: May 19, 2008 K. Kinnear 5 M. Stapp 6 Cisco Systems, Inc. 7 November 16, 2007 9 DHCP Server Identifier Override Suboption 10 draft-ietf-dhc-server-override-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This memo defines a new suboption of the DHCP relay information 44 option which allows the DHCP relay to specify a new value for the 45 Server Identifier option, which is inserted by the DHCP Server. This 46 allows the DHCP relay to act as the actual DHCP server such that 47 RENEW DHCPREQUESTs will come to the relay instead of going to the 48 server directly. This gives the relay the opportunity to include the 49 Relay Agent option with appropriate suboptions even on DHCP RENEW 50 messages. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Server Identifier Override Suboption Definition . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 6. Intellectual Property Rights and Copyright . . . . . . . . . . 9 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 64 Intellectual Property and Copyright Statements . . . . . . . . . . 12 66 1. Introduction 68 There are many situations where the DHCP relay is involved and can 69 insert a relay agent option [3] with appropriate suboptions easily 70 into DHCP DISCOVER messages. Once the lease has been granted, 71 however, future DHCP RENEWAL messages are sent directly to the DHCP 72 Server as specified in the Server Identifier option. This means that 73 the relay may not see the DHCP RENEWAL messages (depending upon 74 network topology) and thus can not provide the same relay agent 75 option information in the RENEWAL messages. 77 This new DHCP relay agent suboption, Server Identifier override, 78 allows the relay to tell the DHCP server what value to place into the 79 Server Identifier option [5]. Using this, the relay agent can force 80 RENEWAL messages to come to it instead of the server. The relay may 81 then insert the relay agent option with appropriate suboptions and 82 relay the DHCPREQUEST to the actual server. In this fashion the DHCP 83 server will be provided with the same relay agent information upon 84 renewals (such as Circuit-ID, Remote-ID, Device Class, etc.) as was 85 provided in the initial DISCOVER message. In effect, this makes a 86 RENEWAL into a REBINDING. 88 This new suboption could also be used by the DHCP relay in order to 89 allow the relay to appear as the actual DHCP server to the client. 90 This has the advantage that the relay can more easily keep up-to-date 91 information about leases granted, etc. 93 In short, this new suboption allows the DHCPv4 relay to function in 94 the same fashion as the DHCPv6 relay [7] currently does. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 100 document are to be interpreted as described in [1]. 102 3. Server Identifier Override Suboption Definition 104 The format of the suboption is: 106 Code Len Overriding Server Identifier address 107 +-----+-----+-----+-----+-----+-----+ 108 | TBD | n | a1 | a2 | a3 | a4 | 109 +-----+-----+-----+-----+-----+-----+ 111 Figure 1 113 The option length (n) is 4. The octets "a1" through "a4" specify the 114 value which MUST be inserted into the Server Identifier option by the 115 DHCP Server upon reply. 117 DHCP Servers which implement this Relay Suboption MUST use this 118 value, if present, as the value to insert into the Server Identifier 119 option whenever responding to a DHCP Client. 121 If a DHCP Server does not understand/implement this Relay Suboption, 122 it will ignore the Suboption, and thus will insert it's own 123 appropriate interface address as the Server Identifier address. In 124 this case, the DHCP Relay will not receive RENEW DHCPREQUEST packets 125 from the client. When configuring a DHCP Relay to use this 126 Suboption, the administrator of the Relay should take into account 127 whether or not the DHCP Server to which the packet will be relayed 128 will correctly understand this Suboption. 130 When servicing a DHCPREQUEST packet the DHCP Server would normally 131 look at the Server Identifier option for verification that the 132 address specified there is one of the addresses associated with the 133 DHCP Server, silently ignoring the DHCPREQUEST if it does not match a 134 configured DHCP Server interface address. If the DHCPREQUEST packet 135 contains a Server Identifier Override Suboption, however, comparison 136 should be made between this suboption and the Server Identifier 137 option. If both of the Server Identifier Override Suboption and the 138 Server Identifier Option specify the same address, then the Server 139 should accept the DHCPREQUEST packet for processing, regardless of 140 whether or not the Server Identifier Option matchs a DHCP Server 141 interface. 143 The DHCP Relay should fill in the giaddr field when relaying the 144 packet just as it normally would do. 146 In a situation where the DHCP Relay is configured to forward packets 147 to more than one server, the DHCP Relay should forward all DHCP 148 packets to all servers. This applies to DHCP RENEW packets as well. 150 The intent is that the DHCP Relay should not need to maintain state 151 information about the DHCP lease. 153 DHCP Relays using this suboption SHOULD also implement and use the 154 DHCPv4 Relay Agent Flags Suboption [4] in order to specify whether 155 the DHCP Relay received the original packet as a broadcast or 156 unicast. The DHCP Server receiving a packet containing the Server 157 Identifier Override Suboption may use this additional information in 158 processing the packet. 160 Note that if the DHCP Relay becomes inaccessible by the DHCP Client 161 or loses network access to the DHCP Server, further DHCP RENEW 162 packets from the DHCP Client may not be properly processed and the 163 DHCP Client's lease may time out. 165 4. Security Considerations 167 Message authentication in DHCP for intradomain use where the out-of- 168 band exchange of a shared secret is feasible is defined in [6]. 169 Potential exposures to attack are discussed in section 7 of the DHCP 170 protocol specification in [2]. 172 The DHCP Relay Agent option depends on a trusted relationship between 173 the DHCP relay agent and the server, as described in section 5 of RFC 174 3046. While the introduction of fraudulent relay-agent options can 175 be prevented by a perimeter defense that blocks these options unless 176 the relay agent is trusted, a deeper defense using the authentication 177 option for relay agent options [8] SHOULD be deployed as well. 179 If a rogue DHCP relay were inserted between the client and the 180 server, it could redirect clients to it using this suboption. This 181 would allow such a system to later deny RENEW DHCPREQUEST and thus 182 force clients to discontinue use of their allocated address. It 183 could also allow the rogue relay to change, insert, or delete DHCP 184 options in DHCPACK messages and extend leases beyond what the server 185 has allowed. This interception, however, would need to be done 186 during the initial DISCOVER and OFFER phase, since the suboption 187 value SHOULD be ignored by the server during RENEWAL state. DHCP 188 Authentication [6] and/or DHCP Relay Agent option authentication [8] 189 would address this case. (Note that, as is always the case, lack of 190 DHCP Authentication would allow a rogue DHCP relay to change the 191 Server-ID option in the DHCPOFFER and DHCPACK packets without 192 detection. This threat is not new to the Server-ID-Override 193 suboption.) 195 This draft does not add any new vulnerabilities that were not already 196 present, except in the case where DHCP authentication is already in 197 place and DHCP clients require its use. It is suggested that DHCP 198 Authentication and DHCP Relay Agent Option Authentication SHOULD be 199 deployed when this option is used, or protection should be provided 200 against the insertion of rogue DHCP relays and server. 202 This relay sub-option is not intended, by itself, to provide any 203 additional security benefits. 205 5. IANA Considerations 207 IANA is requested to assign a suboption number for the Server 208 Identifier Override Suboption from the DHCP Relay Agent Information 209 Option [3] suboption number space. 211 6. Intellectual Property Rights and Copyright 213 The IETF has been notified of intellectual property rights claimed in 214 regard to some or all of the specification contained in this 215 document. For more information consult the online list of claimed 216 rights. 218 7. References 220 7.1. Normative References 222 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 223 Levels", BCP 14, RFC 2119, March 1997. 225 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 226 March 1997. 228 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 229 January 2001. 231 [4] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host 232 Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags 233 Suboption", RFC 5010, September 2007. 235 7.2. Informative References 237 [5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 238 Extensions", RFC 2132, March 1997. 240 [6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 241 RFC 3118, June 2001. 243 [7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 244 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 245 RFC 3315, July 2003. 247 [8] Stapp, M. and T. Lemon, "The Authentication Suboption for the 248 Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", 249 RFC 4030, March 2005. 251 Authors' Addresses 253 Richard A. Johnson 254 Cisco Systems, Inc. 255 170 W. Tasman Dr. 256 San Jose, CA 95134 257 US 259 Phone: +1 408 526 4000 260 Email: raj@cisco.com 262 Jay Kumarasamy 263 Cisco Systems, Inc. 264 170 W. Tasman Dr. 265 San Jose, CA 95134 266 US 268 Phone: +1 408 526 4000 269 Email: jayk@cisco.com 271 Kim Kinnear 272 Cisco Systems, Inc. 273 170 W. Tasman Dr. 274 San Jose, CA 95134 275 US 277 Phone: +1 408 526 4000 278 Email: kkinnear@cisco.com 280 Mark Stapp 281 Cisco Systems, Inc. 282 170 W. Tasman Dr. 283 San Jose, CA 95134 284 US 286 Phone: +1 408 526 4000 287 Email: mjs@cisco.com 289 Full Copyright Statement 291 Copyright (C) The IETF Trust (2007). 293 This document is subject to the rights, licenses and restrictions 294 contained in BCP 78, and except as set forth therein, the authors 295 retain all their rights. 297 This document and the information contained herein are provided on an 298 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 299 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 300 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 301 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 302 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 305 Intellectual Property 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org. 329 Acknowledgment 331 Funding for the RFC Editor function is provided by the IETF 332 Administrative Support Activity (IASA).