Dynamic Host Configuration Working V. Vinokour Group W. Dec Internet-Draft Cisco Systems Intended status: Standards Track J. Bristow Expires: December 8, 2008 Swisscom Schweiz AG Network Development D. Miles Alcatel-Lucent June 6, 2008 DHCP Reconfigure Extension Option draft-vinokour-dhcp-reconfigure-option-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 8, 2008. Abstract The current use of DHCP (Dynamic Host Configuration Protocol) Reconfigure extension is limited by a requirement that FORCERENEW message is authenticated. This document defines a mechanism allowing the use of FORCERENEW without DHCP authentication. Vinokour, et al. Expires December 8, 2008 [Page 1] Internet-Draft DHCP Reconfigure Extension Option June 2008 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 Intellectual Property and Copyright Statements . . . . . . . . . . 6 Vinokour, et al. Expires December 8, 2008 [Page 2] Internet-Draft DHCP Reconfigure Extension Option June 2008 1. Introduction The DHCP Reconfigure Extension defined in [RFC3203] is a useful mechanism allowing dynamic reconfiguration of a single host triggered by the DHCP server. Its application is currently limited by a requirement that FORCERENEW message is always authenticated using procedures as described in [RFC3118]. The mandatory authentication was originally motivated by a legitimate security concern whereby in some network environments a FORCERENEW message can be spoofed. However, in some networks native security mechanisms already provide sufficient protection against spoofing of DHCP traffic. An example of such network is a DSL Forum TR-101 [TR-101] compliant access network. In such environments the mandatory coupling between FORCERENEW and DHCP Authentication can be relaxed. This document provides a mechanism allowing DHCP server and client to negotiate use of FORCERENEW without authentication. 2. Proposal We suggest defining a new DHCP option TBD that, when inserted by DHCP Server in DHCPOFFER and DHCPACK messages, would instruct the client to enable processing of unauthenticated FORCERENEW messages. The format of option TBD is as follows: Code Len Value +-----+-----+-----+ | TBD | 1 | 0/1 | +-----+-----+-----+ The client would indicate that it supports the functionality by inserting an Parameter Request List option (option 55, RFC 3203 [RFC2131]) containing option TBD in DHCPDISCOVER and DHCPREQUEST messages. In its response the server will only include the option TBD if it is specified in Parameter Request List received from the client. The value of the option indicates whether unauthenticated FORCERENEW messages are permitted in the network (value = 1) or not (value = 0) thus giving the network administrator control over their usage. A DHCP client receiving a DHCPOFFER or DHCPACK reply containing option TBD MUST accept unauthenticated FORCERENEW messages. 3. IANA Considerations This document requests IANA to allocate an option code for the newly Vinokour, et al. Expires December 8, 2008 [Page 3] Internet-Draft DHCP Reconfigure Extension Option June 2008 defined DHCP option as described in the text. Note to RFC Editor: this section may be removed on publication as an RFC. 4. Security Considerations The potential security risks of using DHCP reconfigure extension with unauthenticated FORCERENEW message are outlined in [RFC3203], and led to the original authentication requirement. Therefore, enabling this functionality should be done judiciously by network administrators. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001. [TR-101] DSLHome-Technical Working Group, "Migration to Ethernet- Based DSL Aggregation", April 2006, . Authors' Addresses Vitali Vinokour Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 USA Phone: +1-978-936-0774 Fax: Email: vvinokou@cisco.com Vinokour, et al. Expires December 8, 2008 [Page 4] Internet-Draft DHCP Reconfigure Extension Option June 2008 Wojciech Dec Cisco Systems Haarlerbergpark Haarlerbergweg 13-19 Amsterdam, NOORD-HOLLAND 1101 CH Netherlands Phone: Fax: Email: wdec@cisco.com URI: James Bristow Swisscom Schweiz AG Network Development Zentweg 9 Bern, 3050 Switzerland Phone: Fax: Email: James.Bristow@swisscom.com URI: David Miles Alcatel-Lucent Melbourne, Australia Phone: Fax: Email: david.miles@alcatel-lucent.com URI: Vinokour, et al. Expires December 8, 2008 [Page 5] Internet-Draft DHCP Reconfigure Extension Option June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Vinokour, et al. Expires December 8, 2008 [Page 6]