draft-ietf-dhc-vpn-option-10.txt		draft-ietf-dhc-vpn-option-11.txt
	DHC Working Group Kim Kinnear		DHC Working Group Kim Kinnear
	Internet Draft Richard Johnson		Internet Draft Richard Johnson
	Intended Status: Standards Track Mark Stapp		Intended Status: Standards Track Mark Stapp
	Expires: September 3, 2009 Jay Kumarasamy		Expires: September 4, 2009 Jay Kumarasamy
	Cisco Systems		Cisco Systems
	March 3, 2009		March 4, 2009
	Virtual Subnet Selection Options for DHCPv4 and DHCPv6		Virtual Subnet Selection Options for DHCPv4 and DHCPv6
	<draft-ietf-dhc-vpn-option-10.txt>		<draft-ietf-dhc-vpn-option-11.txt>
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 September 3, 2009		This Internet-Draft will expire on September 4, 2009
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 28		skipping to change at page 2, line 28
	1. Introduction................................................. 2		1. Introduction................................................. 2
	2. Terminology.................................................. 3		2. Terminology.................................................. 3
	3. Virtual Subnet Selection Option and Sub-Option Definitions... 5		3. Virtual Subnet Selection Option and Sub-Option Definitions... 5
	3.1. DHCPv4 Virtual Subnet Selection Option..................... 5		3.1. DHCPv4 Virtual Subnet Selection Option..................... 5
	3.2. DHCPv4 Virtual Subnet Selection Sub-Option................. 5		3.2. DHCPv4 Virtual Subnet Selection Sub-Option................. 5
	3.3. DHCPv6 Virtual Subnet Selection Option..................... 6		3.3. DHCPv6 Virtual Subnet Selection Option..................... 6
	3.4. Virtual Subnet Selection Type and Information.............. 6		3.4. Virtual Subnet Selection Type and Information.............. 6
	4. Overview of Virtual Subnet Selection Usage................... 7		4. Overview of Virtual Subnet Selection Usage................... 7
	5. Relay Agent Behavior......................................... 10		5. Relay Agent Behavior......................................... 10
	5.1. VPN assignment by the DHCP server.......................... 12		5.1. VPN assignment by the DHCP server.......................... 12
	5.2. DHCP Leasequery............................................ 12		5.2. DHCP Leasequery............................................ 13
	6. Client Behavior.............................................. 12		6. Client Behavior.............................................. 13
	7. Server Behavior.............................................. 13		7. Server Behavior.............................................. 14
	7.1. Returning the DHCPv4 or DHCPv6 Option...................... 14		7.1. Returning the DHCPv4 or DHCPv6 Option...................... 15
	7.2. Returning the DHCPv4 Sub-Option............................ 15		7.2. Returning the DHCPv4 Sub-Option............................ 15
	7.3. Making sense of conflicting VSS information................ 15		7.3. Making sense of conflicting VSS information................ 16
	8. Security..................................................... 16		8. Security..................................................... 16
	9. IANA Considerations.......................................... 17		9. IANA Considerations.......................................... 17
	10. Acknowledgments............................................. 17		10. Acknowledgments............................................. 18
	11. References.................................................. 18		11. References.................................................. 18
	11.1. Normative References...................................... 18		11.1. Normative References...................................... 18
	11.2. Informative References.................................... 18		11.2. Informative References.................................... 19
	12. Authors' Addresses.......................................... 19		12. Authors' Addresses.......................................... 20
	1. Introduction		1. Introduction
	There is a growing use of Virtual Private Network (VPN)		There is a growing use of Virtual Private Network (VPN)
	configurations. The growth comes from many areas; individual client		configurations. The growth comes from many areas; individual client
	systems needing to appear to be on the home corporate network even		systems needing to appear to be on the home corporate network even
	when traveling, ISPs providing extranet connectivity for customer		when traveling, ISPs providing extranet connectivity for customer
	companies, etc. In some of these cases there is a need for the DHCP		companies, etc. In some of these cases there is a need for the DHCP
	server to know the VPN (hereafter called a "Virtual Subnet Selector"		server to know the VPN (hereafter called a "Virtual Subnet Selector"
	or "VSS") from which an address, and other resources, should be		or "VSS") from which an address, and other resources, should be
	skipping to change at page 3, line 48		skipping to change at page 3, line 48
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document uses the following terms:		This document uses the following terms:
	o "DHCP client"		o "DHCP client"
	A DHCP client is a host using DHCP to obtain configuration		A DHCP client is a host using DHCP to obtain configuration
	parameters such as a network address.		parameters such as a network address.
			o "DHCP proxy"
			A DHCP proxy is a DHCP client which acquires IP addresses not
			for its own use, but rather on behalf of another entity. There
			are a variety of ways that a DHCP proxy can supply the addresses
			it acquires to other entities that need them.
	o "DHCP relay agent"		o "DHCP relay agent"
	A DHCP relay agent is a third-party agent that transfers BOOTP		A DHCP relay agent is an agent that transfers BOOTP and DHCP
	and DHCP messages between clients and servers residing on		messages between clients and servers residing on different
	different subnets, per [RFC951] and [RFC1542].		subnets, per [RFC951], [RFC1542], and [RFC3315].
	o "DHCP server"		o "DHCP server"
	A DHCP server is a host that returns configuration parameters to		A DHCP server is a host that returns configuration parameters to
	DHCP clients.		DHCP clients.
	o "DHCPv4 option"		o "DHCPv4 option"
	An option used to implement a capability defined by the DHCPv4		An option used to implement a capability defined by the DHCPv4
	RFCs [RFC2131][RFC2132]. These options have one-octet code and		RFCs [RFC2131][RFC2132]. These options have one-octet code and
	skipping to change at page 7, line 23		skipping to change at page 7, line 40
	a VSS option with a Type field containing any value other than		a VSS option with a Type field containing any value other than
	zero (0), one (1), or 255 SHOULD be ignored.		zero (0), one (1), or 255 SHOULD be ignored.
	4. Overview of Virtual Subnet Selection Usage		4. Overview of Virtual Subnet Selection Usage
	At the highest level, the VSS option or sub-option determines the VPN		At the highest level, the VSS option or sub-option determines the VPN
	on which a DHCP client is supposed to receive an IP address. How the		on which a DHCP client is supposed to receive an IP address. How the
	option or sub-option is entered and processed is discussed below, but		option or sub-option is entered and processed is discussed below, but
	the point of all of the discussion is to determine the VPN on which		the point of all of the discussion is to determine the VPN on which
	the DHCP client resides. This will affect a relay agent, in that it		the DHCP client resides. This will affect a relay agent, in that it
	will have to ensure that the packets sent to and received from the		will have to ensure that DHCP packets sent to and received from the
	DHCP client flow over the correct VPN. This will affect the DHCP		DHCP client flow over the correct VPN. This will affect the DHCP
	server in that it determines the IP address space used for the IP		server in that it determines the IP address space used for the IP
	address allocation.		address allocation.
	A DHCP server has as part of its configuration some IP address space		A DHCP server has as part of its configuration some IP address space
	from which it allocates IP addresses to DHCP clients. These		from which it allocates IP addresses to DHCP clients. These
	allocations are typically for a limited time, and thus the DHCP		allocations are typically for a limited time, and thus the DHCP
	client gets a lease on the IP address. In the absence of any VPN		client gets a lease on the IP address. In the absence of any VPN
	information, the IP address space is in the global or default VPN		information, the IP address space is in the global or default VPN
	used throughout the Internet. When a DHCP server deals with VPN		used throughout the Internet. When a DHCP server deals with VPN
	skipping to change at page 14, line 35		skipping to change at page 15, line 10
	In a similar manner, a DHCP server may use the Virtual Subnet		In a similar manner, a DHCP server may use the Virtual Subnet
	Selection option to inform a DHCP client that the address (or		Selection option to inform a DHCP client that the address (or
	addresses) it allocated for the client is on a particular VPN.		addresses) it allocated for the client is on a particular VPN.
	In either case above, care should be taken to ensure that a client or		In either case above, care should be taken to ensure that a client or
	relay agent receiving a reply containing a VSS option will correctly		relay agent receiving a reply containing a VSS option will correctly
	understand the VSS option. Otherwise, the client or relay agent will		understand the VSS option. Otherwise, the client or relay agent will
	end up using the address as though it were a global address.		end up using the address as though it were a global address.
			If a server uses a different VPN than what was specified in the VSS
			option or sub-option, it SHOULD send back the VPN information using
			the same type as the received type. It MAY send back a different type
			if it is not possible to use the same type (such as the RFC2685 VPN-
			ID if no ASCII VPN identifier exists).
	7.1. Returning the DHCPv4 or DHCPv6 Option		7.1. Returning the DHCPv4 or DHCPv6 Option
	DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option		DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option
	processing, see below) MUST return an instance of this option in the		processing, see below) MUST return an instance of this option in the
	reply packet or message if the server successfully uses this option		reply packet or message if the server successfully uses this option
	to allocate an IP address, and it MUST NOT include an instance of		to allocate an IP address, and it MUST NOT include an instance of
	this option if the server is unable to support, is not configured to		this option if the server is unable to support, is not configured to
	support, or does not implement support for VSS information in general		support, or does not implement support for VSS information in general
	or the requested VPN in particular.		or the requested VPN in particular.
	skipping to change at page 15, line 14		skipping to change at page 15, line 43
	this document.		this document.
	7.2. Returning the DHCPv4 Sub-Option		7.2. Returning the DHCPv4 Sub-Option
	The case of the DHCPv4 sub-option is a bit more complicated. Note		The case of the DHCPv4 sub-option is a bit more complicated. Note
	that [RFC3046] specifies that a DHCPv4 server which supports the		that [RFC3046] specifies that a DHCPv4 server which supports the
	relay-agent-information option SHALL copy all sub-options received in		relay-agent-information option SHALL copy all sub-options received in
	a relay-agent-information option into any outgoing relay-agent-		a relay-agent-information option into any outgoing relay-agent-
	information option. Thus, the default behavior for any DHCPv4 server		information option. Thus, the default behavior for any DHCPv4 server
	is to return any VSS sub-option received to the relay agent whether		is to return any VSS sub-option received to the relay agent whether
	or not the DHCPv4 server understand the VSS sub-option. A server		or not the DHCPv4 server understands the VSS sub-option. A server
	which implements the VSS sub-option MUST include the VSS sub-option		which implements the VSS sub-option MUST include the VSS sub-option
	in the relay-agent-information option in the reply packet if it		in the relay-agent-information option in the reply packet if it
	successfully acted upon the VSS information in the incoming VSS sub-		successfully acted upon the VSS information in the incoming VSS sub-
	option.		option.
	Moreover, if a server uses different VSS information to allocate an		Moreover, if a server uses different VSS information to allocate an
	IP address than it receives in a particular DHCPv4 sub-option, it		IP address than it receives in a particular DHCPv4 sub-option, it
	MUST include that alternative VSS information in a sub-option that it		MUST include that alternative VSS information in a sub-option that it
	returns to the DHCPv4 relay agent.		returns to the DHCPv4 relay agent.
	skipping to change at page 16, line 47		skipping to change at page 17, line 25
	option. Potential exposures to attack are discussed in section 7 of		option. Potential exposures to attack are discussed in section 7 of
	the DHCP protocol specification in [RFC2131].		the DHCP protocol specification in [RFC2131].
	For DHCPv6 use of the VSS option, the "Security Considerations"		For DHCPv6 use of the VSS option, the "Security Considerations"
	section of [RFC3315] details the general threats to DHCPv6, and thus		section of [RFC3315] details the general threats to DHCPv6, and thus
	to messages using the VSS option. The "Authentication of DHCP		to messages using the VSS option. The "Authentication of DHCP
	Messages" section of [RFC3315] describes securing communication		Messages" section of [RFC3315] describes securing communication
	between relay agents and servers, as well as clients and servers.		between relay agents and servers, as well as clients and servers.
	The VSS option could be used by a client in order to obtain an IP		The VSS option could be used by a client in order to obtain an IP
	address from a VPN other than the one where it should. This option		address from any VPN. This option would allow a client to perform a
	would allow a client to perform a more complete address-pool		more complete address-pool exhaustion attack since the client would
	exhaustion attack since the client would no longer be restricted to		no longer be restricted to attacking address-pools on just its local
	attacking address-pools on just its local subnet.		subnet.
	A DHCP server that implements these options and sub-option should be		A DHCP server that implements these options and sub-option should be
	aware of this possibility and use whatever techniques that can be		aware of this possibility and use whatever techniques that can be
	devised to prevent such an attack. Information such as the giaddr in		devised to prevent such an attack. Information such as the giaddr in
	DHCPv4 or link address in the Relay-forward DHCPv6 message might be		DHCPv4 or link address in the Relay-forward DHCPv6 message might be
	used to detect and prevent this sort of attack.		used to detect and prevent this sort of attack.
	One possible defense would be for the DHCP relay to insert a VSS		One possible defense would be for the DHCP relay to insert a VSS
	option or sub-option to override the DHCP client's VSS option.		option or sub-option to override the DHCP client's VSS option.
	skipping to change at page 17, line 34		skipping to change at page 18, line 14
	IANA is requested to assign sub-option number 151 for the DHCPv4		IANA is requested to assign sub-option number 151 for the DHCPv4
	sub-option defined in Section 3.2 from the DHCP Relay Agent Sub-		sub-option defined in Section 3.2 from the DHCP Relay Agent Sub-
	options space [RFC3046], in accordance with the spirit of [RFC3942].		options space [RFC3046], in accordance with the spirit of [RFC3942].
	While [RFC3942] doesn't explicitly mention the sub-option space for		While [RFC3942] doesn't explicitly mention the sub-option space for
	the DHCP Relay Agent Information option [RFC3046], sub-option 151 is		the DHCP Relay Agent Information option [RFC3046], sub-option 151 is
	already in use by existing implementations of this sub-option and the		already in use by existing implementations of this sub-option and the
	current draft is essentially compatible with these current		current draft is essentially compatible with these current
	implementations.		implementations.
	IANA has assigned the value of TBD for the DHCPv6 VSS option defined		IANA is requested to assign the value of TBD for the DHCPv6 VSS
	in Section 3.3.		option defined in Section 3.3 from the DHCPv6 option registry.
	While the type byte defined in Section 3.4 defines a number space		While the type byte defined in Section 3.4 defines a number space
	that could be managed by IANA, expansion of this number space is not		that could be managed by IANA, expansion of this number space is not
	anticipated and so creation of a registry of these numbers is not		anticipated and so creation of a registry of these numbers is not
	required by this document. In the event that additional values for		required by this document. In the event that additional values for
	the type byte are defined in subsequent documents, IANA should at		the type byte are defined in subsequent documents, IANA should at
	that time create a registry for these type bytes. New values for the		that time create a registry for these type bytes. New values for the
	type byte may only be defined by IETF Consensus, as described in		type byte may only be defined by IETF Consensus, as described in
	[RFC5226]. Basically, this means that they are defined by RFCs		[RFC5226]. Basically, this means that they are defined by RFCs
	approved by the IESG.		approved by the IESG.
End of changes. 15 change blocks.
	23 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/