< draft-ietf-savi-dhcp-25.txt		draft-ietf-savi-dhcp-26.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: December 1, 2014 Tsinghua Univ.		Expires: December 2, 2014 Tsinghua Univ.
	F. Baker		F. Baker
	Cisco		Cisco
	May 30, 2014		May 31, 2014
	SAVI Solution for DHCP		SAVI Solution for DHCP
	draft-ietf-savi-dhcp-25		draft-ietf-savi-dhcp-26
	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 December 1, 2014.		This Internet-Draft will expire on December 2, 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 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	Binding entry limit: The maximum number of binding entries that may		Binding entry limit: The maximum number of binding entries that may
	be associated with any one binding anchor. Limiting the number of		be associated with any one binding anchor. Limiting the number of
	binding entries per binding anchor prevents a malicious or		binding entries per binding anchor prevents a malicious or
	malfunctioning node from overloading the binding table on a SAVI		malfunctioning node from overloading the binding table on a SAVI
	device.		device.
	Direct attachment: Ideally, a SAVI device should be an access device		Direct attachment: Ideally, a SAVI device should be an access device
	which is directly attached by hosts. In such case, the hosts are		which is directly attached by hosts. In such case, the hosts are
	direct attachments of the SAVI device.		direct attachments of the SAVI device.
	Indirect attachment: A SAVI device can be an aggregration device		Indirect attachment: A SAVI device can be an aggregation device which
	which is connected with a number of access devices, which are		is connected with a number of access devices, which are attached by
	attached by hosts. In such case, the hosts are indirect attachments		hosts. In such case, the hosts are indirect attachments of the SAVI
	of the SAVI device. Sometimes, it is expressed as "the hosts are		device. Sometimes, it is expressed as "the hosts are indirectly
	indirectly attached to the SAVI device".		attached to the SAVI device".
	Upstream link: Upstream links are links connected to non-SAVI devices		Upstream link: Upstream links are links connected to non-SAVI devices
	from which the valid source address space of traffic contains the		from which the valid source address space of traffic contains the
	prefixes of other networks.		prefixes of other networks.
	Upstream device: An upstream device is a non-SAVI device associated		Upstream device: An upstream device is a non-SAVI device associated
	with an upstream link. For example, the gateway router of the		with an upstream link. For example, the gateway router of the
	network.		network.
	Downstream link: Downstream links are links connected to non-SAVI		Downstream link: Downstream links are links connected to non-SAVI
	skipping to change at page 14, line 43 ¶		skipping to change at page 14, line 43 ¶
	Neighbor Advertisement messages.		Neighbor Advertisement messages.
	(2) The perimeter in SAVI-DHCP is not only a perimeter for data		(2) The perimeter in SAVI-DHCP is not only a perimeter for data
	packets, but also a perimeter for DHCP messages. The placement		packets, but also a perimeter for DHCP messages. The placement
	of DHCP Relay/Server, which is not involved in SAVI-FCFS , is		of DHCP Relay/Server, which is not involved in SAVI-FCFS , is
	related with the construction of the perimeter. The requirement		related with the construction of the perimeter. The requirement
	on the placement and configuration of DHCP Relay/Server are		on the placement and configuration of DHCP Relay/Server are
	discussed in Section 4.3.3.		discussed in Section 4.3.3.
	(3) Downstream/upstream links MUST be distinguished when configuring		(3) Downstream/upstream links MUST be distinguished when configuring
	the perimeter to avoid estabilshing binding for addresses of		the perimeter to avoid establishing binding for addresses of
	other networks.		other networks.
	4.3.2. SAVI-DHCP Perimeter Configuration Guideline		4.3.2. SAVI-DHCP Perimeter Configuration Guideline
	Through configuring attribute of each attachment properly, a		Through configuring attribute of each attachment properly, a
	perimeter separating untrusted area and trusted area can be formed:		perimeter separating untrusted area and trusted area can be formed:
	(1) Configure Validating and DHCP-Snooping attribute on the direct		(1) Configure Validating and DHCP-Snooping attribute on the direct
	attachments of all the DHCP clients.		attachments of all the DHCP clients.
	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 14 ¶
	associated binding anchor of DHCP messages in such case.		associated binding anchor of DHCP messages in such case.
	Note that even if a DHCP server is valid, it may be not contained in		Note that even if a DHCP server is valid, it may be not contained in
	the perimeter based on the guideline. For example, in Figure 1, DHCP		the perimeter based on the guideline. For example, in Figure 1, DHCP
	server A is valid, but it is attached to a Non-SAVI device. The Non-		server A is valid, but it is attached to a Non-SAVI device. The Non-
	SAVI device may be attached by attackers which generate fabricated		SAVI device may be attached by attackers which generate fabricated
	DHCP messages. This binding based mechanism may not have the ability		DHCP messages. This binding based mechanism may not have the ability
	to distinguish whether a message received from the attachment of the		to distinguish whether a message received from the attachment of the
	Non-SAVI device 1 is from DHCP server A or the attackers. If the		Non-SAVI device 1 is from DHCP server A or the attackers. If the
	DHCP server A is contained in the perimeter, the Non-SAVI device 1		DHCP server A is contained in the perimeter, the Non-SAVI device 1
	will also be contained in the perimter. However, the Non-SAVI device		will also be contained in the perimeter. However, the Non-SAVI
	1 can introduce fabricated DHCP messages into the perimeter. Thus,		device 1 can introduce fabricated DHCP messages into the perimeter.
	the DHCP server A cannot be contained in the perimeter.		Thus, the DHCP server A cannot be contained in the perimeter.
	In this case, the SAVI devices can set up bindings for addresses		In this case, the SAVI devices can set up bindings for addresses
	assigned by DHCP server A through snooping the messages relayed by		assigned by DHCP server A through snooping the messages relayed by
	trusted relay in the network. For example, the DHCP relay may relay		trusted relay in the network. For example, the DHCP relay may relay
	messages between DHCP server A and the clients in the network, and		messages between DHCP server A and the clients in the network, and
	the SAVI devices can snoop messages from the DHCP relay which is		the SAVI devices can snoop messages from the DHCP relay which is
	inside the perimeter. The authentication mechanism (i.e., IPSec, as		inside the perimeter. The authentication mechanism (i.e., IPSec, as
	specified in section 21.1 of [RFC3315]) enforced between the DHCP		specified in section 21.1 of [RFC3315]) enforced between the DHCP
	relay and the DHCP server outside the perimeter can compensate this		relay and the DHCP server outside the perimeter can compensate this
	binding based mechanism. It is SUGGESTED to configure IPSec between		binding based mechanism. It is SUGGESTED to configure IPSec between
	the DHCP relay and the DHCP server in such case. If source address		the DHCP relay and the DHCP server in such case. If source address
	validation is enforced in the whole network, which makes the source		validation is enforced in the whole network, which makes the source
	IP address trustable, the DHCP relay and the DHCP server can simply		IP address trustable, the DHCP relay and the DHCP server can simply
	authenticate the messages from each other based on the source IP		authenticate the messages from each other based on the source IP
	address without the requriement to deploy IPSec.		address without the requirement to deploy IPSec.
	Another considration on the placement is that if the DHCP server/		Another consideration on the placement is that if the DHCP server/
	relay is not inside the perimeter, the SAVI devices may not be able		relay is not inside the perimeter, the SAVI devices may not be able
	to set up bindings correctly, because the SAVI devices may not be on		to set up bindings correctly, because the SAVI devices may not be on
	the path between the clients and the server/relay, or the DHCP		the path between the clients and the server/relay, or the DHCP
	messages are encapsulated (e.g., Relay-reply and Relay-forward).		messages are encapsulated (e.g., Relay-reply and Relay-forward).
	5. Binding State Table (BST)		5. Binding State Table (BST)
	Binding State Table is used to contain the bindings between the IP		Binding State Table is used to contain the bindings between the IP
	addresses assigned to the attachments and the corresponding binding		addresses assigned to the attachments and the corresponding binding
	anchors of the attachments. Each entry of the table, i.e., binding		anchors of the attachments. Each entry of the table, i.e., binding
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 17 ¶
	disjoin the DHCP client and the remaining network containing the DHCP		disjoin the DHCP client and the remaining network containing the DHCP
	server(s)/relay(s). For most of the networks whose topologies are		server(s)/relay(s). For most of the networks whose topologies are
	simple, it is possible to deploy this SAVI function at proper devices		simple, it is possible to deploy this SAVI function at proper devices
	to meet this requirement.		to meet this requirement.
	However, a deployment of this SAVI function may not meet the		However, a deployment of this SAVI function may not meet the
	requirement. For example, there are multiple paths from a DHCP		requirement. For example, there are multiple paths from a DHCP
	client to the DHCP server and the SAVI device is only on one of them.		client to the DHCP server and the SAVI device is only on one of them.
	Then the SAVI device may not be able to snoop the DHCP procedure.		Then the SAVI device may not be able to snoop the DHCP procedure.
	Host movement may also make this requirement can not be met. For		Host movement may also make this requirement can not be met. For
	exmaple, when a DHCP client moves from one attachment to another		example, when a DHCP client moves from one attachment to another
	attachment in the same network, it may not reinitialize its interface		attachment in the same network, it may not reinitialize its interface
	or send a Confirm message because of imcomplete protocol		or send a Confirm message because of incomplete protocol
	implementation. Thus, there can be scenarios in which only		implementation. Thus, there can be scenarios in which only
	performing this DHCP snooping process is insufficient to set up		performing this DHCP snooping process is insufficient to set up
	bindings for all the valid DHCP addresses. These exceptions and the		bindings for all the valid DHCP addresses. These exceptions and the
	solutions are discussed in Section 7.		solutions are discussed in Section 7.
	6.2. Binding States Description		6.2. Binding States Description
	Following binding states present in this process and the		Following binding states present in this process and the
	corresponding state machine:		corresponding state machine:
	skipping to change at page 19, line 23 ¶		skipping to change at page 19, line 23 ¶
	option is received.		option is received.
	EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received.		EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received.
	EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is		EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
	received.		received.
	EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is		EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
	received.		received.
	EVE_DCHP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to		EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to
	section 4.3.3 of [RFC5007]) is received.		section 4.3.3 of [RFC5007]) is received.
	Note: the events listed here do not cover all the DHCP messages in		Note: the events listed here do not cover all the DHCP messages in
	section 3. The messages which do not really determine address usage		section 3. The messages which do not really determine address usage
	(DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit,		(DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit,
	DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6		DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6
	Reconfigure), and which are not neccessary to snoop (DHCPv4 NAK,		Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer
	refer to section 6.4.2.1), are not included.		to section 6.4.2.1), are not included.
	Moreover, only if a DHCP message can pass the following checks, the		Moreover, only if a DHCP message can pass the following checks, the
	corresponding event is regarded as a valid event:		corresponding event is regarded as a valid event:
	o Attribute check: the DHCP Server-Client messages and		o Attribute check: the DHCP Server-Client messages and
	LEASEQUERY_REPLY should be from attachments with DHCP-Trust		LEASEQUERY_REPLY should be from attachments with DHCP-Trust
	attribute; the DHCP Client-Server messages should be from		attribute; the DHCP Client-Server messages should be from
	attachments with DHCP-Snooping attribute.		attachments with DHCP-Snooping attribute.
	o Destination check: the DHCP Server-Client messages should be		o Destination check: the DHCP Server-Client messages should be
	skipping to change at page 20, line 7 ¶		skipping to change at page 20, line 7 ¶
	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		Besides, this check is not performed on DHCP Renew/Rebind
	messagesSection 6.4.3.		messages (Section 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 24, line 12 ¶		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_DCHP_RENEW, EVE_DCHP_REBIND.		EVE_DHCP_REPLY, EVE_DHCP_LEASEQUERY, EVE_DHCP_RENEW, EVE_DHCP_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:		If the trigger event is EVE_DHCP_RENEW/EVE_DHCP_REBIND:
	The message MUST be forwarded.		The message MUST be forwarded.
	In such case, a new TID will be used by the client. The TID field of		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		the corresponding entries MUST be set to the new TID. Note that TID
	chekc will not be performed on such messages.		check 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
	skipping to change at page 25, line 10 ¶		skipping to change at page 25, line 10 ¶
	Address option in each IA option. If the valid lifetime of an IA		Address option in each IA option. If the valid lifetime of an IA
	address option is 0, the binding entry with matched TID and address		address option is 0, the binding entry with matched TID and address
	is removed. Or else, set the Lifetime field of the binding entry		is removed. Or else, set the Lifetime field of the binding entry
	with matched TID and address to be the sum of the new valid lifetime		with matched TID and address to be the sum of the new valid lifetime
	and MAX_DHCP_RESPONSE_TIME.		and MAX_DHCP_RESPONSE_TIME.
	The SAVI device does not specially process IA options in Reply		The SAVI device does not specially process IA options in Reply
	message with status NoBinding, because no address is contained in		message with status NoBinding, because no address is contained in
	such IA options and no actions will be performed.		such IA options and no actions will be performed.
	If the trigger event is EVE_DCHP_LEASEQUERY:		If the trigger event is EVE_DHCP_LEASEQUERY:
	The message MUST be forwarded.		The message MUST be forwarded.
	The message should be in response to the Leasequery message sent in		The message should be in response to the Leasequery message sent in
	Section 6.4.2. The related binding entry can be determined based on		Section 6.4.2. The related binding entry can be determined based on
	the address in the IA Address option in the Leasequery-reply message.		the address in the IA Address option in the Leasequery-reply message.
	The Lifetime field of the corresponding binding entry is set to the		The Lifetime field of the corresponding binding entry is set to the
	sum of the lease time in the LEASEQUERY_REPLY message and		sum of the lease time in the LEASEQUERY_REPLY message and
	MAX_DHCP_RESPONSE_TIME.		MAX_DHCP_RESPONSE_TIME.
	skipping to change at page 26, line 8 ¶		skipping to change at page 26, line 8 ¶
	RC: EVE_DHCP_SOLICIT_RC		RC: EVE_DHCP_SOLICIT_RC
	RE: EVE_DHCP_REBOOT		RE: EVE_DHCP_REBOOT
	RPL: EVE_DHCP_REPLY		RPL: EVE_DHCP_REPLY
	DCL: EVE_DHCP_DECLINE		DCL: EVE_DHCP_DECLINE
	RLS: EVE_DHCP_RELEASE		RLS: EVE_DHCP_RELEASE
	LQR: EVE_DCHP_LEASEQUERY		LQR: EVE_DHCP_LEASEQUERY
	Timeout: EVE_ENTRY_EXPIRE		Timeout: EVE_ENTRY_EXPIRE
	+-------------+		+-------------+
	| |		| |
	/---------| NO_BIND |<----------\		/---------| NO_BIND |<----------\
	| ------>| | |		| ------>| | |
	| | +-------------+ |EVE_DHCP_RELEASE		| | +-------------+ |EVE_DHCP_RELEASE
	EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE		EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE
	EVE_DHCP_CONFIRM | |TIMEOUT |TIMEOUT		EVE_DHCP_CONFIRM | |TIMEOUT |TIMEOUT
	skipping to change at page 26, line 32 ¶		skipping to change at page 26, line 32 ¶
	| | |		| | |
	v | |		v | |
	+-------------+ +------------+		+-------------+ +------------+
	| | EVE_DHCP_REPLY | |		| | EVE_DHCP_REPLY | |
	| INIT_BIND ------------------------>| BOUND |<-\		| INIT_BIND ------------------------>| BOUND |<-\
	| | | | |		| | | | |
	+-------------+ +------------+ |		+-------------+ +------------+ |
	| |		| |
	\--------/		\--------/
	EVE_DHCP_REPLY		EVE_DHCP_REPLY
	EVE_DCHP_LEASEQUERY		EVE_DHCP_LEASEQUERY
	Figure 9: Diagram of Transit		Figure 9: Diagram of Transit
	7. Data Snooping Process		7. Data Snooping Process
	7.1. Scenario		7.1. Scenario
	The rationale of the DHCP Snooping Process specified in Section 6 is		The rationale of the DHCP Snooping Process specified in Section 6 is
	that if a DHCP client's use of a DHCP address is legitimate, the		that if a DHCP client's use of a DHCP address is legitimate, the
	corresponding DHCP address assignment procedure must have been		corresponding DHCP address assignment procedure must have been
	skipping to change at page 36, line 19 ¶		skipping to change at page 36, line 19 ¶
	The SAVI device MAY record any violation.		The SAVI device MAY record any violation.
	9. State Restoration		9. State Restoration
	If a SAVI device reboots, the information kept in volatile memory		If a SAVI device reboots, the information kept in volatile memory
	will be lost. This section specifies the restoration of attribute		will be lost. This section specifies the restoration of attribute
	configuration and BST.		configuration and BST.
	9.1. Attribute Configuration Restoration		9.1. Attribute Configuration Restoration
	The lost of attribute configuration will not break the network: no		The loss of attribute configuration will not break the network: no
	action will be performed on traffic from attachments with no		action will be performed on traffic from attachments with no
	attribute. However, the lost of attribute configuration makes this		attribute. However, the loss of attribute configuration makes this
	SAVI function unable to work.		SAVI function unable to work.
	To avoid the loss of binding anchor attribute configuration, the		To avoid the loss of binding anchor attribute configuration, the
	configuration MUST be able to be stored in non-volatile storage.		configuration MUST be able to be stored in non-volatile storage.
	After the reboot of SAVI device, if the configuration of binding		After the reboot of SAVI device, if the configuration of binding
	anchor attribute can be found in non-volatile storage, the		anchor attribute can be found in non-volatile storage, the
	configuration MUST be used.		configuration MUST be used.
	9.2. Binding State Restoration		9.2. Binding State Restoration
	skipping to change at page 37, line 49 ¶		skipping to change at page 37, line 49 ¶
	the SAVI device cannot determine whether the address is just		the SAVI device cannot determine whether the address is just
	assigned to the triggering attachment from the DHCP Leasequery		assigned to the triggering attachment from the DHCP Leasequery
	Reply.		Reply.
	11.2. Issues about Leaving Clients		11.2. Issues about Leaving Clients
	After a binding is set up, the corresponding client may leave its		After a binding is set up, the corresponding client may leave its
	attachment point. It may leave temporarily due to link flapping, or		attachment point. It may leave temporarily due to link flapping, or
	permanently by moving to a new attachment point or leaving the		permanently by moving to a new attachment point or leaving the
	network. Since the client may return shortly, the binding should be		network. Since the client may return shortly, the binding should be
	kept, or legtimate traffic from the client will be blocked. However,		kept, or legitimate traffic from the client will be blocked.
	if the client leaves permanently, it may be insecure to keep the		However, if the client leaves permanently, it may be insecure to keep
	binding. If the binding anchor is a property of the attachment point		the binding. If the binding anchor is a property of the attachment
	rather than the client, e.g., the switch port, an attacker which is		point rather than the client, e.g., the switch port, an attacker
	attached to the attachment point of the leaving client can send		which is attached to the attachment point of the leaving client can
	spoofing packets with the addresses assigned to the client. Even if		send spoofing packets with the addresses assigned to the client.
	the binding anchor is a property of the client, it is a waste of		Even if the binding anchor is a property of the client, it is a waste
	binding resources to keep bindings for departed clients.		of binding resources to keep bindings for departed clients.
	The following mechanism is designed to handle the leaving of client:		The following mechanism is designed to handle the leaving of client:
	(1) Whenever a client with the Validating attribute leaves, a timer		(1) Whenever a client with the Validating attribute leaves, a timer
	of duration OFFLINK_DELAY is set on the corresponding binding		of duration OFFLINK_DELAY is set on the corresponding binding
	entries.		entries.
	(2) If a DAD Neighbor Solicitation/Gratuitous ARP request is		(2) If a DAD Neighbor Solicitation/Gratuitous ARP request is
	received that targets the address during OFFLINK_DELAY, the		received that targets the address during OFFLINK_DELAY, the
	entry MAY be removed.		entry MAY be removed.
	skipping to change at page 39, line 27 ¶		skipping to change at page 39, line 27 ¶
	an attacker can perform reachability test with an address bound to		an attacker can perform reachability test with an address bound to
	another client. If binding is migrated to the attacker, the attacker		another client. If binding is migrated to the attacker, the attacker
	can successfully obtain the binding from the victim. Because this		can successfully obtain the binding from the victim. Because this
	mechanism wouldn't set up a binding based on snooping the DNA		mechanism wouldn't set up a binding based on snooping the DNA
	procedure, it cannot achieve perfect compatibility with DNA.		procedure, it cannot achieve perfect compatibility with DNA.
	However, it only means the re-configuration of the interface is		However, it only means the re-configuration of the interface is
	slowed but not prevented. Details are discussed as follows.		slowed but not prevented. Details are discussed as follows.
	In Simple DNAv6 [RFC6059], the probe is sent with the source address		In Simple DNAv6 [RFC6059], the probe is sent with the source address
	set to a link-local address, and such messages will not be discarded		set to a link-local address, and such messages will not be discarded
	by the policy specified in section Section 8.2. If a client is re-		by the policy specified in Section 8.2. If a client is re-attached
	attached to a previous network, the detection will be completed, and		to a previous network, the detection will be completed, and the
	the address will be regarded as valid by the client. However, the		address will be regarded as valid by the client. However, the
	candidate address is not contained in the probe. Thus, the binding		candidate address is not contained in the probe. Thus, the binding
	cannot be recovered through snooping the probe. As the client will		cannot be recovered through snooping the probe. As the client will
	perform DHCP exchange at the same time, the binding will be recovered		perform DHCP exchange at the same time, the binding will be recovered
	from the DHCP Snooping Process. The DHCP Request messages will not		from the DHCP Snooping Process. The DHCP Request messages will not
	be filtered out in this case because they have link-local source		be filtered out in this case because they have link-local source
	addresses. Before the DHCP procedure is completed, packets will be		addresses. Before the DHCP procedure is completed, packets will be
	filtered out by the SAVI device. In other words, if this SAVI		filtered out by the SAVI device. In other words, if this SAVI
	function is enabled, Simple DNAv6 will not help reduce the handover		function is enabled, Simple DNAv6 will not help reduce the handover
	latency. If Data-Snooping attribute is configured on the new		latency. If Data-Snooping attribute is configured on the new
	attachment of the client, the data triggered procedure may reduce		attachment of the client, the data triggered procedure may reduce
End of changes. 24 change blocks.
	40 lines changed or deleted		40 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/