draft-ietf-dhc-vpn-option-04.txt   draft-ietf-dhc-vpn-option-05.txt 
Network Working Group R. Johnson Network Working Group R. Johnson
Internet-Draft J. Kumarasamy Internet-Draft J. Kumarasamy
Expires: August 10, 2005 K. Kinnear Expires: December 31, 2005 K. Kinnear
M. Stapp M. Stapp
Cisco Cisco
February 9, 2005 June 29, 2005
Virtual Subnet Selection Option Virtual Subnet Selection Option
draft-ietf-dhc-vpn-option-04.txt draft-ietf-dhc-vpn-option-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 10, 2005. This Internet-Draft will expire on December 31, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo defines a new DHCP option for passing Virtual Subnet This memo defines a new DHCP option for passing Virtual Subnet
Selection (VSS) information between the DHCP client and the DHCP Selection (VSS) information between the DHCP client and the DHCP
server. It is intended for use primarily by DHCP proxy clients in server. It is intended for use primarily by DHCP proxy clients in
skipping to change at page 6, line 19 skipping to change at page 6, line 19
Potential exposures to attack are discussed in section 7 of the DHCP Potential exposures to attack are discussed in section 7 of the DHCP
protocol specification in [2]. protocol specification in [2].
The VSS Information option could be used by a client in order to The VSS Information option could be used by a client in order to
obtain an IP address from a VSS other than the one where it should. obtain an IP address from a VSS other than the one where it should.
DHCP relays MAY choose to remove the option before passing on DHCP relays MAY choose to remove the option before passing on
DHCPDISCOVER packets. Another possible defense would be for the DHCP DHCPDISCOVER packets. Another possible defense would be for the DHCP
relay to insert a Relay option containing a VSS Information relay to insert a Relay option containing a VSS Information
Suboption, which would override the DHCP VSS Information option. Suboption, which would override the DHCP VSS Information option.
This option would allow a client to perform a more complete This option would allow a client to perform a more complete address-
address-pool exhaustion attack since the client would no longer be pool exhaustion attack since the client would no longer be restricted
restricted to attacking address-pools on just its local subnet. to attacking address-pools on just its local subnet.
Servers that implement the VSS Information option MUST by default Servers that implement the VSS Information option MUST by default
disable use of the feature; it must specifically be enabled through disable use of the feature; it must specifically be enabled through
configuration. Moreover, a server SHOULD provide the ability to configuration. Moreover, a server SHOULD provide the ability to
selectively enable use of the feature under restricted conditions, selectively enable use of the feature under restricted conditions,
e.g., by enabling use of the option only from explicitly configured e.g., by enabling use of the option only from explicitly configured
client-ids, enabling its use only by clients on a particular subnet, client-ids, enabling its use only by clients on a particular subnet,
or restricting the VSSs from which addresses may be requested. or restricting the VSSs from which addresses may be requested.
4. IANA Considerations 4. IANA Considerations
skipping to change at page 8, line 12 skipping to change at page 8, line 12
Option. The type bytes and data formats of the VSS Information Option. The type bytes and data formats of the VSS Information
Option and VSS Information Suboption MUST always be identical. Option and VSS Information Suboption MUST always be identical.
5. Acknowledgements 5. Acknowledgements
This document is the result of work done within Cisco Systems. This document is the result of work done within Cisco Systems.
Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work
on this option definition and the other related work for which this on this option definition and the other related work for which this
is necessary. is necessary.
6 References 6. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[3] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor [3] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[4] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", [4] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999. RFC 2685, September 1999.
[5] Droms, R., "Authentication for DHCP Messages", RFC 3118, June [5] Droms, R., "Authentication for DHCP Messages", RFC 3118,
2001. June 2001.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
[7] Volz, B., "Reclassifying Dynamic Host Configuration Protocol [7] Volz, B., "Reclassifying Dynamic Host Configuration Protocol
version 4 (DHCPv4) Options", RFC 3942, November 2004. version 4 (DHCPv4) Options", RFC 3942, November 2004.
Authors' Addresses Authors' Addresses
Richard A. Johnson Richard A. Johnson
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408 526 4000 Phone: +1 408 526 4000
EMail: raj@cisco.com Email: raj@cisco.com
Jay Kumarasamy Jay Kumarasamy
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408 526 4000 Phone: +1 408 526 4000
EMail: jayk@cisco.com Email: jayk@cisco.com
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
US US
Phone: +1 978 244 8000 Phone: +1 978 244 8000
EMail: kkinnar@cisco.com Email: kkinnar@cisco.com
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
US US
Phone: +1 978 244 8000 Phone: +1 978 244 8000
EMail: mjs@cisco.com Email: mjs@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/