< draft-ietf-savi-dhcp-24.txt		draft-ietf-savi-dhcp-25.txt >
	SAVI J. Bi		SAVI J. Bi
	Internet-Draft J. Wu		Internet-Draft J. Wu
	Intended status: Standards Track G. Yao		Intended status: Standards Track G. Yao
	Expires: November 6, 2014 Tsinghua Univ.		Expires: December 1, 2014 Tsinghua Univ.
	F. Baker		F. Baker
	Cisco		Cisco
	May 5, 2014		May 30, 2014
	SAVI Solution for DHCP		SAVI Solution for DHCP
	draft-ietf-savi-dhcp-24		draft-ietf-savi-dhcp-25
	Abstract		Abstract
	This document specifies the procedure for creating a binding between		This document specifies the procedure for creating a binding between
	a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI		a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI
	(Source Address Validation Improvements) device. The bindings set up		(Source Address Validation Improvements) device. The bindings set up
	by this procedure can be used to filter out packets with forged		by this procedure can be used to filter out packets with forged
	source IP address in DHCP scenario. This mechanism is proposed as a		source IP address in DHCP scenario. This mechanism is proposed as a
	complement to ingress filtering to provide finer-grained source IP		complement to ingress filtering to provide finer-grained source IP
	address validation.		address validation.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on November 6, 2014.		This Internet-Draft will expire on December 1, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 44 ¶
	6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 21		6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 21
	6.4.2.1. Trigger Events . . . . . . . . . . . . . . . . . . 21		6.4.2.1. Trigger Events . . . . . . . . . . . . . . . . . . 21
	6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 22		6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 22
	6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 24		6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 24
	6.4.3.1. Trigger Events . . . . . . . . . . . . . . . . . . 24		6.4.3.1. Trigger Events . . . . . . . . . . . . . . . . . . 24
	6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 24		6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 24
	6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 25		6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 25
	7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 26		7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 26
	7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 26		7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27		7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.3. Additional Binding States Description . . . . . . . . . . 27		7.3. Additional Binding States Description . . . . . . . . . . 28
	7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 28		7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	7.5. State Machine of Binding Recovery Process . . . . . . . . 29		7.5. State Machine of Binding Recovery Process . . . . . . . . 29
	7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 29		7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 29
	7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 29		7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 29
	7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 29		7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 29
	7.5.2. From DETECTION to Other States . . . . . . . . . . . . 30		7.5.2. From DETECTION to Other States . . . . . . . . . . . . 30
	7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 30		7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 30
	7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 30		7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 30
	7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 31		7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 31
	7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 31		7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 31
	7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 31		7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 32
	7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 32		7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 33
	7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 32		7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 33
	7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 33		7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 33
	7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 33		7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 33
	8. Filtering Specification . . . . . . . . . . . . . . . . . . . 34		8. Filtering Specification . . . . . . . . . . . . . . . . . . . 34
	8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 35		8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 35
	8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 35		8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 35
	9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 36		9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 36
	9.1. Attribute Configuration Restoration . . . . . . . . . . . 36		9.1. Attribute Configuration Restoration . . . . . . . . . . . 36
	9.2. Binding State Restoration . . . . . . . . . . . . . . . . 36		9.2. Binding State Restoration . . . . . . . . . . . . . . . . 36
	10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37		10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 37		11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	skipping to change at page 20, line 6 ¶		skipping to change at page 20, line 6 ¶
	o Binding anchor check: the DHCP Client-Server messages which may		o Binding anchor check: the DHCP Client-Server messages which may
	trigger modification or removal of an existing binding entry must		trigger modification or removal of an existing binding entry must
	have matched binding anchor with the corresponding entry.		have matched binding anchor with the corresponding entry.
	o TID check: the DHCP Server-Client/Client-Server messages which		o TID check: the DHCP Server-Client/Client-Server messages which
	may cause modification on existing binding entries must have		may cause modification on existing binding entries must have
	matched TID with the corresponding entry. Note that this check		matched TID with the corresponding entry. Note that this check
	is not performed on Leasequery and Leasequery-reply messages as		is not performed on Leasequery and Leasequery-reply messages as
	they are exchanged between the SAVI devices and the DHCP servers.		they are exchanged between the SAVI devices and the DHCP servers.
			Besides, this check is not performed on DHCP Renew/Rebind
			messagesSection 6.4.3.
	o Binding limitation check: the DHCP messages must not cause new		o Binding limitation check: the DHCP messages must not cause new
	binding setup on an attachment whose binding entry limitation has		binding setup on an attachment whose binding entry limitation has
	been reached. (refer to Section 11.6).		been reached. (refer to Section 11.6).
	o Address check: the source address of the DHCP messages should		o Address check: the source address of the DHCP messages should
	pass the check specified in Section 8.2.		pass the check specified in Section 8.2.
	On receiving a DHCP message without triggering a valid event, the		On receiving a DHCP message without triggering a valid event, the
	state will not transit and actions will not be performed. Note that		state will not transit and actions will not be performed. Note that
	skipping to change at page 22, line 47 ¶		skipping to change at page 22, line 47 ¶
	message querying by IP address to All_DHCP_Servers multicast address		message querying by IP address to All_DHCP_Servers multicast address
	[RFC3315] or a list of configured DHCP server addresses. The		[RFC3315] or a list of configured DHCP server addresses. The
	Leasequery message is generated for each IP address if multiple		Leasequery message is generated for each IP address if multiple
	addresses are confirmed. The Lifetime of corresponding entries is		addresses are confirmed. The Lifetime of corresponding entries is
	set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after		set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after
	MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example		MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example
	of the entries is illustrated in Figure 6. The related security		of the entries is illustrated in Figure 6. The related security
	problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the		problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the
	SAVI device does not send the LEASEQUERY message, a pre-configured		SAVI device does not send the LEASEQUERY message, a pre-configured
	lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry.		lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry.
			(Note: it is SUGGESUTED to use T1 configured on DHCP servers as the
			DHCP_DEFAULT_LEASE.)
	2.2 If there are IA options in the Reply message, the SAVI device		2.2 If there are IA options in the Reply message, the SAVI device
	checks each IA option. When the first assigned address is found, the		checks each IA option. When the first assigned address is found, the
	Address field of the binding entry with matched TID is set to the		Address field of the binding entry with matched TID is set to the
	address. The Lifetime field is set to the sum of the lease time in		address. The Lifetime field is set to the sum of the lease time in
	Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed		Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed
	to BOUND. If there are more than one address assigned in the		to BOUND. If there are more than one address assigned in the
	message, new binding entries are set up for the remaining address		message, new binding entries are set up for the remaining address
	assigned in the IA options. An example of the entries is illustrated		assigned in the IA options. An example of the entries is illustrated
	in Figure 7. SAVI devices do not specially process IA options with		in Figure 7. SAVI devices do not specially process IA options with
	skipping to change at page 24, line 10 ¶		skipping to change at page 24, line 12 ¶
	If the trigger event is EVE_ENTRY_EXPIRE:		If the trigger event is EVE_ENTRY_EXPIRE:
	The entry MUST be deleted from BST.		The entry MUST be deleted from BST.
	6.4.3. From BOUND to Other States		6.4.3. From BOUND to Other States
	6.4.3.1. Trigger Events		6.4.3.1. Trigger Events
	Trigger events: EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE,		Trigger events: EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE,
	EVE_DHCP_REPLY, EVE_DCHP_LEASEQUERY.		EVE_DHCP_REPLY, EVE_DCHP_LEASEQUERY, EVE_DCHP_RENEW, EVE_DCHP_REBIND.
	6.4.3.2. Following Actions		6.4.3.2. Following Actions
	If the trigger event is EVE_ENTRY_EXPIRE:		If the trigger event is EVE_ENTRY_EXPIRE:
	Remove the corresponding entry in BST.		Remove the corresponding entry in BST.
	If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE:		If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE:
	The message MUST be forwarded.		The message MUST be forwarded.
	The SAVI device first gets all the addresses ("Requested IP address"		The SAVI device first gets all the addresses ("Requested IP address"
	in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the		in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the
	IA options of DHCPv6 Decline/Release) to decline/release in the		IA options of DHCPv6 Decline/Release) to decline/release in the
	message. Then the corresponding entries MUST be removed.		message. Then the corresponding entries MUST be removed.
			If the trigger event is EVE_DCHP_RENEW/EVE_DCHP_REBIND:
			The message MUST be forwarded.
			In such case, a new TID will be used by the client. The TID field of
			the corresponding entries MUST be set to the new TID. Note that TID
			chekc will not be performed on such messages.
	If the trigger event is EVE_DHCP_REPLY:		If the trigger event is EVE_DHCP_REPLY:
	The message MUST be forwarded.		The message MUST be forwarded.
	The DHCP Reply messages received in current states should be in		The DHCP Reply messages received in current states should be in
	response to DHCP Renew/Rebind.		response to DHCP Renew/Rebind.
	If the message is DHCPv4 ACK, the SAVI device just simply update the		If the message is DHCPv4 ACK, the SAVI device just simply update the
	binding entry with matched TID, with the Lifetime field set to be the		binding entry with matched TID, with the Lifetime field set to be the
	sum of the new lease time and MAX_DHCP_RESPONSE_TIME.		sum of the new lease time and MAX_DHCP_RESPONSE_TIME.
End of changes. 10 change blocks.
	9 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/