--- 1/draft-ietf-dhc-server-override-00.txt 2006-02-04 23:05:46.000000000 +0100 +++ 2/draft-ietf-dhc-server-override-01.txt 2006-02-04 23:05:46.000000000 +0100 @@ -1,24 +1,29 @@ Internet Engineering Task Force Richard Johnson Internet Draft Kim Kinnear -Expiration: August 2003 Mark Stapp -File: draft-ietf-dhc-server-override-00.txt Jay Kumarasamy +Expiration: March 2005 Mark Stapp +File: draft-ietf-dhc-server-override-01.txt Jay Kumarasamy Cisco Systems, Inc. DHCP Server-ID Override Suboption - + - February 5, 2003 + September 27, 2004 Status of this Memo + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. + This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 @@ -93,24 +98,35 @@ Code Len Overridden Server-ID address +-----+-----+-----+-----+-----+-----+ | TBD | n | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+ The option length (n) is 4. The octets "a1" through "a4" specify the value which SHOULD be inserted into the Server-ID option by the DHCP Server upon reply. - DHCP Servers SHOULD use this value as the value to insert into the - Server-ID option ONLY when the protocol is in the SELECTING and - REQUESTING and REBINDING states. If this suboption appears in a DHCP - request which is part of a lease RENEWAL, it SHOULD be ignored. + DHCP Servers SHOULD use this value, if present, as the value to + insert into the Server-ID option whenever responding to a DHCP + Client. + + When servicing a DHCP REQUEST packet the DHCP Server would normally + look at the Server-ID option for verification that the address + specified there is one of the addresses associated with the DHCP + Server, silently ignoring the REQUEST if it does not match a + configured DHCP Server interface address. If the REQUEST packet + contains a Server-ID Override Suboption, however, comparison should + be made between this suboption and the Server-ID option. If both of + the Server-ID Override Suboption and the Server-ID Option specify the + same address, then the Server should accept the REQUEST packet for + processing, regardless of whether or not the Server-ID Option matchs + a DHCP Server interface. 3.0 IANA Considerations None. 4.0 Acknowledgements This document is the result of work done within Cisco Systems. Thanks to Jay Kumarasamy, Kim Kinnear, and Mark Stapp for their work on this suboption definition and the other related work for which @@ -123,30 +139,49 @@ [5]. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [2]. The DHCP Relay Agent option depends on a trusted relationship between the DHCP relay agent and the server, as described in section 5 of RFC 3046. While the introduction of fraudulent relay-agent options can be prevented by a perimeter defense that blocks these options unless the relay agent is trusted, a deeper defense using the authentication option for relay agent options [4] SHOULD be deployed as well. - If a rouge DHCP relay were inserted between the client and the + If a rogue DHCP relay were inserted between the client and the server, it could redirect clients to it using this suboption. This would allow such a system to later deny renew requests and thus force clients to discontinue use of their allocated address. This interception, however, would need to be done during the initial DISCOVER and OFFER phase, since the suboption value SHOULD be ignored by the server during RENEWAL state. Either DHCP Authentication [5] or DHCP Relay Agent option authentication [4] would address this case. +6.0 Intellectual Property Rights and Copyright + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + Copyright (C) The Internet Society (2004). 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 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. + References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.