< draft-ietf-savi-dhcp-30.txt		draft-ietf-savi-dhcp-31.txt >
	Source Address Validation Improvement J. Bi		Source Address Validation Improvement J. Bi
	Internet-Draft J. Wu		Internet-Draft J. Wu
	Intended status: Standards Track G. Yao		Intended status: Standards Track G. Yao
	Expires: June 6, 2015 Tsinghua Univ.		Expires: July 13, 2015 Tsinghua Univ.
	F. Baker		F. Baker
	Cisco		Cisco
	December 3, 2014		January 9, 2015
	SAVI Solution for DHCP		SAVI Solution for DHCP
	draft-ietf-savi-dhcp-30		draft-ietf-savi-dhcp-31
	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 Source		a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source
	Address Validation Improvements (SAVI) device. The bindings set up		Address Validation Improvements (SAVI) device. The bindings set up
	by this procedure are used to filter packets with forged source IP		by this procedure are used to filter packets with forged source IP
	addresses. This mechanism complements BCP 38 ingress filtering,		addresses. This mechanism complements BCP 38 ingress filtering,
	providing finer-grained source IP address validation.		providing finer-grained source IP address validation.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 June 6, 2015.		This Internet-Draft will expire on July 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Deployment Scenario and Configuration . . . . . . . . . . . . 8		4. Deployment Scenario and Configuration . . . . . . . . . . . . 7
	4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8		4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8
	4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 9		4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 9
	4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 9		4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 9
	4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10		4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10
	4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 10		4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 10
	4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11		4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
	4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11		4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11
	4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12		4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12
	4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 12		4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 12		4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 12
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 30		7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 30
	7.3. Additional Binding States Description . . . . . . . . . . 30		7.3. Additional Binding States Description . . . . . . . . . . 30
	7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 31		7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 31
	7.5. Initial State: state NO_BIND - No binding has been set up 32		7.5. Initial State: state NO_BIND - No binding has been set up 32
	7.5.1. Event: EVE_DATA_UNMATCH: A data packet without		7.5.1. Event: EVE_DATA_UNMATCH: A data packet without
	matched binding is received . . . . . . . . . . . . . 32		matched binding is received . . . . . . . . . . . . . 32
	7.5.2. Events not observed in NO_BIND . . . . . . . . . . . 33		7.5.2. Events not observed in NO_BIND . . . . . . . . . . . 33
	7.6. Initial State: state DETECTION - The address in the entry		7.6. Initial State: state DETECTION - The address in the entry
	is under local duplication detection . . . . . . . . . . 33		is under local duplication detection . . . . . . . . . . 33
	7.6.1. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) . . . . . . . 33		7.6.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 33
	7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor		7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor
	Advertisement(NA) message received from unexpected		Advertisement(NA) message received from unexpected
	system . . . . . . . . . . . . . . . . . . . . . . . 34		system . . . . . . . . . . . . . . . . . . . . . . . 34
	7.6.3. Events not observed in DETECTION . . . . . . . . . . 34		7.6.3. Events not observed in DETECTION . . . . . . . . . . 34
	7.7. Initial State: state RECOVERY - The SAVI device is		7.7. Initial State: state RECOVERY - The SAVI device is
	querying the assignment and lease time of the address in		querying the assignment and lease time of the address in
	the entry through DHCP Leasequery . . . . . . . . . . . . 34		the entry through DHCP Leasequery . . . . . . . . . . . . 34
	7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE		7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
	or LEASEQUERY-REPLY is received . . . . . . . . . . . 34		or LEASEQUERY-REPLY is received . . . . . . . . . . . 34
	7.7.2. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) . . . . . . . 36		7.7.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 36
	7.7.3. Events not observed in RECOVERY . . . . . . . . . . . 36		7.7.3. Events not observed in RECOVERY . . . . . . . . . . . 36
	7.8. Initial State: state BOUND - The binding has been set up 36		7.8. Initial State: state BOUND - The binding has been set up 36
	7.8.1. Event: EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6		7.9. Table of State Machine . . . . . . . . . . . . . . . . . 36
	Renew message is received . . . . . . . . . . . . . . 36
	7.8.2. Event: EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6
	Rebind message is received . . . . . . . . . . . . . 36
	7.8.3. Events not observed in BOUND . . . . . . . . . . . . 37
	7.9. Table of State Machine . . . . . . . . . . . . . . . . . 37
	8. Filtering Specification . . . . . . . . . . . . . . . . . . . 38		8. Filtering Specification . . . . . . . . . . . . . . . . . . . 38
	8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 38		8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 38
	8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 39		8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 38
	9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 40		9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 39
	9.1. Attribute Configuration Restoration . . . . . . . . . . . 40		9.1. Attribute Configuration Restoration . . . . . . . . . . . 39
	9.2. Binding State Restoration . . . . . . . . . . . . . . . . 40		9.2. Binding State Restoration . . . . . . . . . . . . . . . . 39
	10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 41		10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 41		11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	11.1. Security Problems about the Data Snooping Process . . . 41		11.1. Security Problems about the Data Snooping Process . . . 40
	11.2. Client departure issues . . . . . . . . . . . . . . . . 41		11.2. Client departure issues . . . . . . . . . . . . . . . . 41
	11.3. Duplicate Bindings to the Same Address . . . . . . . . . 42		11.3. Duplicate Bindings to the Same Address . . . . . . . . . 42
	11.4. Compatibility with DNA (Detecting Network Attachment) . 43		11.4. Compatibility with DNA (Detecting Network Attachment) . 42
	11.5. Binding Number Limitation . . . . . . . . . . . . . . . 44		11.5. Binding Number Limitation . . . . . . . . . . . . . . . 43
	11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 44		11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 43
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
	13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 44		13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 44
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 45		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	14.1. Normative References . . . . . . . . . . . . . . . . . . 45		14.1. Normative References . . . . . . . . . . . . . . . . . . 44
	14.2. Informative References . . . . . . . . . . . . . . . . . 46		14.2. Informative References . . . . . . . . . . . . . . . . . 45
	1. Introduction		1. Introduction
	This document describes a fine-grained source IPv4 or IPv6 source		This document describes a fine-grained source IPv4 or IPv6 source
	address validation mechanism. This mechanism creates bindings		address validation mechanism. This mechanism creates bindings
	between IP addresses assigned to network interfaces by DHCP and		between IP addresses assigned to network interfaces by DHCP and
	suitable binding anchors (Section 4.3.5). As discussed in Section 3		suitable binding anchors (Section 4.3.5). As discussed in Section 3
	and [RFC7039], a "binding anchor" is an attribute that is immutable		and [RFC7039], a "binding anchor" is an attribute that is immutable
	or difficult to change that may be used to identify the system an IP		or difficult to change that may be used to identify the system an IP
	address has been assigned to; common examples include a MAC address		address has been assigned to; common examples include a MAC address
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 29 ¶
	IP addresses assigned by DHCP and corresponding binding anchors. It		IP addresses assigned by DHCP and corresponding binding anchors. It
	includes the DHCPv4 and v6 snooping process (Section 6), the Data		includes the DHCPv4 and v6 snooping process (Section 6), the Data
	Snooping process (Section 7), as well as a number of other technical		Snooping process (Section 7), as well as a number of other technical
	details. The Data Snooping process is a data-triggered procedure		details. The Data Snooping process is a data-triggered procedure
	that snoops the header of data packet to set up bindings. It is		that snoops the header of data packet to set up bindings. It is
	designed to avoid a permanent block of valid addresses in the case		designed to avoid a permanent block of valid addresses in the case
	that DHCP snooping is insufficient to set up all the valid bindings.		that DHCP snooping is insufficient to set up all the valid bindings.
	This mechanism is designed for the stateful DHCP scenario [RFC2131],		This mechanism is designed for the stateful DHCP scenario [RFC2131],
	[RFC3315]. Stateless DHCP [RFC3736] is out of scope for this		[RFC3315]. Stateless DHCP [RFC3736] is out of scope for this
	document, because it has nothing to do with IP address allocation.		document, as it has nothing to do with IP address allocation. The
	The appropriate SAVI method must be used in those cases. For hosts		appropriate SAVI method must be used in those cases. For hosts using
	using Stateless Auto-Configuration to allocate addresses, SAVI-FCFS		Stateless Auto-Configuration to allocate addresses, SAVI-FCFS
	[RFC6620] should be enabled. Besides, this mechanism is primarily		[RFC6620] should be enabled. Besides, this mechanism is primarily
	designed for pure DHCP scenarios in which only addresses assigned		designed for pure DHCP scenarios in which only addresses assigned
	through DHCP are allowed. However, it does not block link-local		through DHCP are allowed. However, it does not block link-local
	addresses, as they are not assigned using DHCP. It is RECOMMENDED		addresses, as they are not assigned using DHCP. It is RECOMMENDED
	that the administration enable a SAVI solution for link-local		that the administration enable a SAVI solution for link-local
	addresses, e.g., SAVI-FCFS [RFC6620].		addresses, e.g., SAVI-FCFS [RFC6620].
	This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and		This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and
	DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6		DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6
	transition scenarios, e.g., [RFC7341], are beyond the scope of this		transition scenarios, e.g., [RFC7341], are beyond the scope of this
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 14 ¶
	Direct attachment: Ideally, a SAVI device is an access device that		Direct attachment: Ideally, a SAVI device is an access device that
	hosts are attached to directly. In such a case, the hosts are direct		hosts are attached to directly. In such a case, the hosts are direct
	attachments (e.g., they attach directly) to the SAVI device.		attachments (e.g., they attach directly) to the SAVI device.
	Indirect attachment: A SAVI device MAY be an aggregation device that		Indirect attachment: A SAVI device MAY be an aggregation device that
	other access devices are attached to, and which hosts in turn attach		other access devices are attached to, and which hosts in turn attach
	to. In such a case, the hosts are indirect attachments (e.g., they		to. In such a case, the hosts are indirect attachments (e.g., they
	attach indirectly) to the SAVI device.		attach indirectly) to the SAVI device.
	Upstream link: Upstream links are links that connect to hosts that		Unprotected link: Unprotected links are links that connect to hosts
	the device may not see DHCP messages to, and are therefore outside		or networks of hosts that the device may not see DHCP messages to,
	the SAVI perimiter.		and are therefore outside the SAVI perimeter.
	Upstream device: An upstream device is a device associated with an		Unprotected device: An unprotected device is a device associated with
	upstream link. One example might be the gateway router of a network.		an unprotected link. One example might be the gateway router of a
			network.
	Downstream link: Downstream inks are links that connect to hosts that		Protected link: Protected links are links that connect to hosts that
	the device will invariably see DHCP messages to, and are therefore		the device will invariably see DHCP messages to, and are therefore
	within the SAVI perimiter..		within the SAVI perimeter.
	Downstream device: A downstream device is a device associated with a		Protected device: A protected device is a device associated with a
	downstream link. One example might be a desktop switch in the		protected link. One example might be a desktop switch in the
	network, or a host.		network, or a host.
	Cut Vertex: A cut vertex is any vertex whose removal increases the		Cut Vertex: A cut vertex is any vertex whose removal increases the
	number of connected components. This is a concept in graph theory.		number of connected components. This is a concept in graph theory.
	This term is used in Section 6.1 to accurately specify the required		This term is used in Section 6.1 to accurately specify the required
	deployment location of SAVI devices when they only perform the DHCP		deployment location of SAVI devices when they only perform the DHCP
	snooping process.		snooping process.
	Identity Association (IA): "A collection of addresses assigned to a		Identity Association (IA): "A collection of addresses assigned to a
	client." [RFC3315]		client." [RFC3315]
	skipping to change at page 8, line 6 ¶		skipping to change at page 8, line 4 ¶
	Detection message: a Neighbor Solicitation or ARP message intended to		Detection message: a Neighbor Solicitation or ARP message intended to
	detect a duplicate address by the Data Snooping Process.		detect a duplicate address by the Data Snooping Process.
	DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the		DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the
	binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease		binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease
	query exchange [RFC5007] cannot be performed by the SAVI device to		query exchange [RFC5007] cannot be performed by the SAVI device to
	fetch the lease.		fetch the lease.
	4. Deployment Scenario and Configuration		4. Deployment Scenario and Configuration
	4.1. Elements and Scenario		4.1. Elements and Scenario
	The essential elements in a SAVI-DHCP deployment scenario include a		The essential elements in a SAVI-DHCP deployment scenario include a
	DHCP server, zero or more downstream DHCP clients, and one or more		DHCP server (which may or may not be assigned an address using DHCP,
	SAVI devices. It may also include DHCP relays, when the DHCP server		and therefore may or may not be protected), zero or more protected
	is not co-located with a set of clients, and zero or more downstream		DHCP clients, and one or more SAVI devices. It may also include DHCP
	Non-SAVI devices.		relays, when the DHCP server is not co-located with a set of clients,
			and zero or more protected Non-SAVI devices. Outside the perimeter,
			via unprotected links, there may be many unprotected devices.
	+--------+ +------------+ +----------+		+--------+ +------------+ +----------+
	|DHCP |-----| Non-SAVI |----|Bogus DHCP|		|DHCP |-----| Non-SAVI |----|Bogus DHCP|
	|Server A| | Device 1 | |Server |		|Server A| | Device 1 | |Server |
	+--------+ +-----|------+ +----------+		+--------+ +-----|------+ +----------+
	|upstream link		|unprotected link
	. . . . . . . . . . .|. . . . . . . . . . . . . .		. . . . . . . . . . .|. . . . . . . . . . . . . .
	. | .		. | .
	. Protection +---|------+ .		. Protection +---|------+ .
	. Perimeter | SAVI |--------------+ .		. Perimeter | SAVI |--------------+ .
	. | Device C| | .		. | Device C| | .
	. +---|------+ | .		. +---|------+ | .
	. | | .		. | | .
	. +----------+ +---|------+ +------|---+ .		. +----------+ +---|------+ +------|---+ .
	downstream . | SAVI | | Non SAVI| | SAVI | .		protected . | SAVI | | Non SAVI| | SAVI | .
	link +----.-| Device A|----| Device 3|-------| Device B| .		link +----.-| Device A|----| Device 3|-------| Device B| .
	| . +----|--|--+ +----------+ +-|---|----+ .		| . +----|--|--+ +----------+ +-|---|----+ .
	| . | +----------+ . . . . . | | .		| . | +----------+ . . . . . | | .
	| '. . . . . . . | . . | | .		| '. . . . . . . | . . | | .
	| | . | . +--------+ | .		| | . | . +--------+ | .
	+----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ .		+----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ .
	| Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | .		| Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | .
	| Device 2 | |A | . |Relay | . |B | . |Server B| .		| Device 2 | |A | . |Relay | . |B | . |Server B| .
	+----------+ +------+ . +------+ . +------+ . +--------+ .		+----------+ +------+ . +------+ . +------+ . +--------+ .
	. . . . . . . . . . . .		. . . . . . . . . . . .
	skipping to change at page 8, line 52 ¶		skipping to change at page 8, line 51 ¶
	Figure 1 shows a deployment scenario that contains these elements.		Figure 1 shows a deployment scenario that contains these elements.
	Note that a physical device can instantiate multiple elements, e.g.,		Note that a physical device can instantiate multiple elements, e.g.,
	a switch can be both a SAVI device and a DHCP relay, or in a cloud		a switch can be both a SAVI device and a DHCP relay, or in a cloud
	computing environment, a physical host may contain a virtual switch		computing environment, a physical host may contain a virtual switch
	plus some number of virtual hosts. In such cases, the links are		plus some number of virtual hosts. In such cases, the links are
	logical links rather than physical links.		logical links rather than physical links.
	Networks are not usually isolated. As a result, traffic from other		Networks are not usually isolated. As a result, traffic from other
	networks, including transit traffic as specified in [RFC6620] (e.g.,		networks, including transit traffic as specified in [RFC6620] (e.g.,
	traffic from another SAVI switch or a router) may enter a SAVI-DHCP		traffic from another SAVI switch or a router) may enter a SAVI-DHCP
	network through the upstream links. Since SAVI solutions are limited		network through the unprotected links. Since SAVI solutions are
	to validating traffic generated from a local link, SAVI-DHCP does not		limited to validating traffic generated from a local link, SAVI-DHCP
	set up bindings for addresses assigned in other networks and cannot		does not set up bindings for addresses assigned in other networks and
	validate them. Traffic from upstream links should be checked by an		cannot validate them. Traffic from unprotected links should be
	upstream system or [RFC2827] mechanisms. The generation and		checked by an unprotected system or [RFC2827] mechanisms. The
	deployment of such a mechanism is beyond the scope of this document.		generation and deployment of such a mechanism is beyond the scope of
			this document.
	Traffic from downstream links is, however, locally generated, and		Traffic from protected links is, however, locally generated, and
	should be checked by SAVI-DHCP if possible. In the event that there		should be checked by SAVI-DHCP if possible. In the event that there
	is an intervening downstream non-SAVI device between the host and the		is an intervening protected non-SAVI device between the host and the
	SAVI device, however, use of the physical attachment point alone as a		SAVI device, however, use of the physical attachment point alone as a
	binding anchor is insufficiently secure, as the several devices on a		binding anchor is insufficiently secure, as the several devices on a
	port or other point of attachment can spoof each other. Hence,		port or other point of attachment can spoof each other. Hence,
	additional information such as a MAC address SHOULD be used to		additional information such as a MAC address SHOULD be used to
	disambiguate them.		disambiguate them.
	4.2. SAVI Binding Type Attributes		4.2. SAVI Binding Type Attributes
	As illustrated in Figure 1, an system attached to a SAVI device can		As illustrated in Figure 1, an system attached to a SAVI device can
	be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI		be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI
	device. Different actions are performed on traffic originated from		device. Different actions are performed on traffic originated from
	different elements. To distinguish among their requirements, several		different elements. To distinguish among their requirements, several
	properties are associated with their point of attachment on the SAVI		properties are associated with their point of attachment on the SAVI
	device.		device.
	When a binding association is uninstantiated, e.g. when no host is		When a binding association is uninstantiated, e.g., when no host is
	attached to the SAVI device using a given port or other binding		attached to the SAVI device using a given port or other binding
	anchor, the binding port attributes take default values unless		anchor, the binding port attributes take default values unless
	overridden by configuration. By default, a SAVI switch does not		overridden by configuration. By default, a SAVI switch does not
	filter DHCP messages, nor does it attempt to validate source		filter DHCP messages, nor does it attempt to validate source
	addresses. This is because a SAVI switch that depends on DHCP cannot		addresses. This is because a SAVI switch that depends on DHCP cannot
	tell, a priori, which ports have valid DHCP servers attached, or		tell, a priori, which ports have valid DHCP servers attached, or
	which have routers or other equipment that would validly appear to		which have routers or other equipment that would validly appear to
	use an arbitrary set of source addresses.		use an arbitrary set of source addresses.
	4.2.1. Trust Attribute		4.2.1. Trust Attribute
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 42 ¶
	If this attribute is TRUE, DHCP Client-Server messages to points of		If this attribute is TRUE, DHCP Client-Server messages to points of
	attachment with this attribute will trigger creation of bindings		attachment with this attribute will trigger creation of bindings
	based on the DHCP snooping procedure described in Section 6. If it		based on the DHCP snooping procedure described in Section 6. If it
	is FALSE, either the Trust attribute must be TRUE (so that bindings		is FALSE, either the Trust attribute must be TRUE (so that bindings
	become irrelevant) or another SAVI mechanism such as SAVI-FCFS must		become irrelevant) or another SAVI mechanism such as SAVI-FCFS must
	be used on the point of attachment.		be used on the point of attachment.
	The DHCP-Snooping attribute is configured on the DHCP Client's point		The DHCP-Snooping attribute is configured on the DHCP Client's point
	of attachment. This attribute can be also used on the attachments to		of attachment. This attribute can be also used on the attachments to
	downstream Non-SAVI devices that are used by DHCP clients. In		protected Non-SAVI devices that are used by DHCP clients. In
	Figure 1, the attachment from the Client A to the SAVI Device A, the		Figure 1, the attachment from the Client A to the SAVI Device A, the
	attachment from the Client B to the SAVI Device B, and the attachment		attachment from the Client B to the SAVI Device B, and the attachment
	from the Non-SAVI Device 2 to the SAVI Device A can be configured		from the Non-SAVI Device 2 to the SAVI Device A can be configured
	with this attribute.		with this attribute.
	Whenever this attribute is set TRUE on a point of attachment, the		Whenever this attribute is set TRUE on a point of attachment, the
	"Validating Attribute" MUST also be set TRUE.		"Validating Attribute" MUST also be set TRUE.
	4.2.4. Data-Snooping Attribute		4.2.4. Data-Snooping Attribute
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	will be checked based on binding entries on the attachment as		will be checked based on binding entries on the attachment as
	specified in Section 8. If it is FALSE, they will not. Since the		specified in Section 8. If it is FALSE, they will not. Since the
	binding table is used in common with other SAVI algorithms, it merely		binding table is used in common with other SAVI algorithms, it merely
	signifies whether the check will be done, not whether it will be done		signifies whether the check will be done, not whether it will be done
	for SAVI-DHCP originated bindings.		for SAVI-DHCP originated bindings.
	This attribute is by default the inverse of the Trust attribute;		This attribute is by default the inverse of the Trust attribute;
	source addresses on untrusted links are validated by default. It MAY		source addresses on untrusted links are validated by default. It MAY
	be set FALSE by the administration.		be set FALSE by the administration.
			The expected use case is when SAVI is used to monitor but not block
			unvalidated transmissions. The network manager, in that case, may
			set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the
			VALIDATING attribute FALSE.
	4.2.6. Table of Mutual Exclusions		4.2.6. Table of Mutual Exclusions
	Different types of attributes may indicate mutually exclusive actions		Different types of attributes may indicate mutually exclusive actions
	on a packet. Mutually exclusive attributes MUST NOT be set TRUE on		on a packet. Mutually exclusive attributes MUST NOT be set TRUE on
	the same attachment. The compatibility of different attributes is		the same attachment. The compatibility of different attributes is
	listed in Figure 2. Note that although Trust and DHCP-Trust are		listed in Figure 2. Note that although Trust and DHCP-Trust are
	compatible, there is no need to configure DHCP-Trust to TRUE on an		compatible, there is no need to configure DHCP-Trust to TRUE on an
	attachment with Trust attribute TRUE.		attachment with Trust attribute TRUE.
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 52 ¶
	4.3.1. SAVI-DHCP Perimeter Overview		4.3.1. SAVI-DHCP Perimeter Overview
	SAVI devices form a perimeter separating trusted and untrusted		SAVI devices form a perimeter separating trusted and untrusted
	regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]).		regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]).
	The perimeter is primarily designed for scalability. It has two		The perimeter is primarily designed for scalability. It has two
	implications.		implications.
	o SAVI devices only need to establish bindings for directly attached		o SAVI devices only need to establish bindings for directly attached
	clients, or clients indirectly attached through a non-SAVI		clients, or clients indirectly attached through a non-SAVI
	downstream device, rather than all of the clients in the network.		protected device, rather than all of the clients in the network.
	o Each SAVI device only need to validate traffic from clients		o Each SAVI device only need to validate traffic from clients
	attached to it, without checking all the traffic passing by.		attached to it, without checking all the traffic passing by.
	Consider the example in Figure 1. The protection perimeter is formed		Consider the example in Figure 1. The protection perimeter is formed
	by SAVI Devices A, B and C. In this case, SAVI device B does not		by SAVI Devices A, B and C. In this case, SAVI device B does not
	create a binding for client A. However, because SAVI device A filters		create a binding for client A. However, because SAVI device A filters
	spoofed traffic from client A, SAVI device B can avoid receiving		spoofed traffic from client A, SAVI device B can avoid receiving
	spoofed traffic from client A.		spoofed traffic from client A.
	skipping to change at page 13, line 28 ¶		skipping to change at page 13, line 31 ¶
	4.3.2. SAVI-DHCP Perimeter Configuration Guideline		4.3.2. SAVI-DHCP Perimeter Configuration Guideline
	A perimeter separating trusted and untrusted regions of the network		A perimeter separating trusted and untrusted regions of the network
	is formed as follows:		is formed as follows:
	(1) Configure the Validating and DHCP-Snooping attributes TRUE on		(1) Configure the Validating and DHCP-Snooping attributes TRUE on
	the direct attachments of all DHCP clients.		the direct attachments of all DHCP clients.
	(2) Configure the Validating and DHCP-Snooping attributes TRUE on		(2) Configure the Validating and DHCP-Snooping attributes TRUE on
	the indirect attachments of all DHCP clients (i.e., DHCP clients		the indirect attachments of all DHCP clients (i.e., DHCP clients
	on downstream links).		on protected links).
	(3) Configure the Trust attribute TRUE on the attachments to other		(3) Configure the Trust attribute TRUE on the attachments to other
	SAVI devices.		SAVI devices.
	(4) If a Non-SAVI device, or a number of connected Non-SAVI devices,		(4) If a Non-SAVI device, or a number of connected Non-SAVI devices,
	are attached only to SAVI devices, set the Trust attribute TRUE		are attached only to SAVI devices, set the Trust attribute TRUE
	on their attachments.		on their attachments.
	(5) Configure the DHCP-Trust attribute TRUE on the direct		(5) Configure the DHCP-Trust attribute TRUE on the direct
	attachments to trusted DHCP relays and servers.		attachments to trusted DHCP relays and servers.
	In this way, the points of attachments with the Validating attribute		In this way, the points of attachments with the Validating attribute
	TRUE (and generally together with attachments of upstream devices) on		TRUE (and generally together with attachments of unprotected devices)
	SAVI devices can form a perimeter separating DHCP clients and trusted		on SAVI devices can form a perimeter separating DHCP clients and
	devices. Data packet checks are only performed on the perimeter.		trusted devices. Data packet checks are only performed on the
	The perimeter is also a perimeter for DHCP messages. The DHCP-Trust		perimeter. The perimeter is also a perimeter for DHCP messages. The
	attribute is only TRUE on the inside links of the perimeter. Only		DHCP-Trust attribute is only TRUE on the inside links of the
	DHCP server-to-client messages originated within the perimeter are		perimeter. Only DHCP server-to-client messages originated within the
	trusted.		perimeter are trusted.
	4.3.3. On the Placement of the DHCP Server and Relay		4.3.3. On the Placement of the DHCP Server and Relay
	As a result of the configuration guideline, SAVI devices only trust		As a result of the configuration guideline, SAVI devices only trust
	DHCP Server-to-Client messages originated inside the perimeter.		DHCP Server-to-Client messages originated inside the perimeter.
	Thus, the trusted DHCP Relays and DHCP Servers must be placed within		Thus, the trusted DHCP Relays and DHCP Servers must be placed within
	the perimeter. DHCP server-to-client messages will be filtered on		the perimeter. DHCP server-to-client messages will be filtered on
	the perimeter. Server-to-relay messages will not be filtered, as		the perimeter. Server-to-relay messages will not be filtered, as
	they are within the perimeter. In this way, DHCP server-to-client		they are within the perimeter. In this way, DHCP server-to-client
	messages from bogus DHCP servers are filtered on the perimeter,		messages from bogus DHCP servers are filtered on the perimeter,
	skipping to change at page 14, line 40 ¶		skipping to change at page 14, line 40 ¶
	apart from manual configuration of the binding anchor.		apart from manual configuration of the binding anchor.
	Another consideration 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).
	4.3.4. An Alternative Deployment		4.3.4. An Alternative Deployment
	In common deployment practice, the traffic from the upstream network		In common deployment practice, the traffic from the unprotected
	is treated as trustworthy, which is to say that it is not filtered.		network is treated as trustworthy, which is to say that it is not
	In such a case, the Trust attribute can be set TRUE on the upstream		filtered. In such a case, the Trust attribute can be set TRUE on the
	link. If Non-SAVI devices, or a number of connected Non-SAVI		unprotected link. If Non-SAVI devices, or a number of connected Non-
	devices, are only attached to SAVI devices and upstream devices,		SAVI devices, are only attached to SAVI devices and unprotected
	their attachment to SAVI devices can have the Trust attribute set		devices, their attachment to SAVI devices can have the Trust
	TRUE. Then an unclosed perimeter will be formed, as illustrated in		attribute set TRUE. Then an unclosed perimeter will be formed, as
	Figure 3.		illustrated in Figure 3.
	To configure such a perimeter, at minimum the DHCP messages from		To configure such a perimeter, at minimum the DHCP messages from
	upstream networks MUST be ensured to be trustworthy. Achieving this		unprotected networks MUST be ensured to be trustworthy. Achieving
	is beyond the scope of this document.		this is beyond the scope of this document.
	| . . Protection |		| . . Protection |
	| | | Perimeter |		| | | Perimeter |
	| | | |		| | | |
	| Upstream | | Upstream |		| Unprotected | | Unprotected |
	| Link | | Link |		| Link | | Link |
	| | | |		| | | |
	| | | |		| | | |
	| +--------+ +--------+ +--------+ |		| +--------+ +--------+ +--------+ |
	| |SAVI |----|Non-SAVI|----|SAVI | |		| |SAVI |----|Non-SAVI|----|SAVI | |
	| |Device | |Device | |Device | |		| |Device | |Device | |Device | |
	| +--------+ +--------+ +--------+ |		| +--------+ +--------+ +--------+ |
	| | | |		| | | |
	\________________________________________________/		\__________________________________________________/
	| |		| |
	| |		| |
	+--------+ +--------+		+--------+ +--------+
	|DHCP | |DHCP |		|DHCP | |DHCP |
	|Client | |Client |		|Client | |Client |
	+--------+ +--------+		+--------+ +--------+
	Figure 3: Alternative Perimeter Configuration		Figure 3: Alternative Perimeter Configuration
	4.3.5. Considerations regarding Binding Anchors		4.3.5. Considerations regarding Binding Anchors
	The strength of this binding-based mechanism depends on the strength		The strength of this binding-based mechanism depends on the strength
	of the binding anchor. The sample binding anchors in [RFC7039] have		of the binding anchor. The sample binding anchors in [RFC7039] have
	the property that they associate an IP address with a direct physical		the property that they associate an IP address with a direct physical
	or secure virtual interface such as a switch port, a subscriber		or secure virtual interface such as a switch port, a subscriber
	association, or a security association. In addition, especially in		association, or a security association. In addition, especially in
	the case that a downstream non-SAVI device such as a desktop switch		the case that a protected non-SAVI device such as a desktop switch or
	or a hub is between the client device and the SAVI switch, they MAY		a hub is between the client device and the SAVI switch, they MAY be
	be extended to also include a MAC address or other link-layer		extended to also include a MAC address or other link-layer attribute.
	attribute. In short, a binding anchor is intended to associate an IP		In short, a binding anchor is intended to associate an IP address
	address with something unspoofable that identifies a single client		with something unspoofable that identifies a single client system or
	system or one of its interfaces; this may be a physical or virtual		one of its interfaces; this may be a physical or virtual interface or
	interface or that plus disambiguating link-layer information.		that plus disambiguating link-layer information.
	If the binding anchor is spoofable, such as a plain MAC address, or		If the binding anchor is spoofable, such as a plain MAC address, or
	non-exclusive, such as a switch port extended using a non-SAVI		non-exclusive, such as a switch port extended using a non-SAVI
	device, an attacker can use a forged binding anchor to evade		device, an attacker can use a forged binding anchor to evade
	validation. Indeed, using a binding anchor that can be easily		validation. Indeed, using a binding anchor that can be easily
	spoofed can lead to worse outcomes than allowing IP spoofing traffic.		spoofed can lead to worse outcomes than allowing IP spoofing traffic.
	Thus, a SAVI device MUST use a non-spoofable and exclusive binding		Thus, a SAVI device MUST use a non-spoofable and exclusive binding
	anchor.		anchor.
	4.4. Other Device Configuration		4.4. Other Device Configuration
	skipping to change at page 16, line 29 ¶		skipping to change at page 16, line 29 ¶
	Lease query process.		Lease query process.
	5. Binding State Table (BST)		5. Binding State Table (BST)
	The Binding State Table, which may be implemented centrally in the		The Binding State Table, which may be implemented centrally in the
	switch or distributed among its ports, is used to contain the		switch or distributed among its ports, is used to contain the
	bindings between the IP addresses assigned to the attachments and the		bindings between the IP addresses assigned to the attachments and the
	corresponding binding anchors of the attachments. Note that in this		corresponding binding anchors of the attachments. Note that in this
	description, there is a binding entry for each IPv4 or IPv6 address		description, there is a binding entry for each IPv4 or IPv6 address
	associated with each binding anchor, and there may be several of each		associated with each binding anchor, and there may be several of each
	such address, especially if the port is extended using a downstream		such address, especially if the port is extended using a protected
	non-SAVI device. Each binding entry, has 5 fields:		non-SAVI device. Each binding entry, has 5 fields:
	o Binding Anchor(Anchor): the binding anchor, i.e., a physical and/		o Binding Anchor(Anchor): the binding anchor, i.e., a physical and/
	or link-layer property of the attachment.		or link-layer property of the attachment.
	o IP Address(Address): the IPv4 or IPv6 address assigned to the		o IP Address(Address): the IPv4 or IPv6 address assigned to the
	attachment by DHCP.		attachment by DHCP.
	o State: the state of the binding. Possible values of this field		o State: the state of the binding. Possible values of this field
	are listed in Section 6.2 and Section 7.3.		are listed in Section 6.2 and Section 7.3.
	skipping to change at page 28, line 32 ¶		skipping to change at page 29, line 4 ¶
	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_DHCP_LEASEQUERY		LQR: EVE_DHCP_LEASEQUERY
	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 | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE		EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE
	EVE_DHCP_SOLICIT_RC| | |		EVE_DHCP_SOLICIT_RC| | |
	EVE_DHCP_REBOOT | | |		EVE_DHCP_REBOOT | | |
	| | |		| | |
	skipping to change at page 32, line 35 ¶		skipping to change at page 32, line 35 ¶
	[RFC0826] or an ARP probe [RFC5227] on the address; if there is		[RFC0826] or an ARP probe [RFC5227] on the address; if there is
	no response message after DETECTION_TIMEOUT, send another ARP		no response message after DETECTION_TIMEOUT, send another ARP
	Request or ARP probe;		Request or ARP probe;
	(2) IPv6 address: send a Duplicate Address Detection message		(2) IPv6 address: send a Duplicate Address Detection message
	[RFC4861] targeting the address; ideally, only the host on that		[RFC4861] targeting the address; ideally, only the host on that
	point of attachment responds with a Neighbor Advertisement; if		point of attachment responds with a Neighbor Advertisement; if
	more than one Neighbor Advertisement is observed, the BST entry		more than one Neighbor Advertisement is observed, the BST entry
	should be removed.		should be removed.
	Because the delivery of the detection message is unreliable, the		As Duplicate Address Detection is an unreliable process (either the
	detection message may fail to reach the targeting node. If there is		packet to or from the other system may be lost in transit), if there
	a node that has the IP address seen in the Data Snooping Process, it		is no response, it should be repeated, as described in [RFC6620].
	may not get the detection messages. This failure mode enables an
	attack against the Data Snooping Process. Thus, the detection is
	performed again if there is no response after the first detection.
	The packet that triggers this event SHOULD be discarded.		The packet that triggers this event SHOULD be discarded.
	This local conflict process SHOULD be performed. If it is not		This local conflict process SHOULD be performed. If it is not
	performed, the state of the entry is set to RECOVERY, the lifetime is		performed, the state of the entry is set to RECOVERY, the lifetime is
	set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified		set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified
	in the following section will be performed directly.		in the following section will be performed directly.
	An example of the entry is illustrated in Figure 11.		An example of the entry is illustrated in Figure 11.
	skipping to change at page 33, line 34 ¶		skipping to change at page 33, line 34 ¶
	received		received
	EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is		EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
	received		received
	EVE_ENTRY_EXPIRE		EVE_ENTRY_EXPIRE
	7.6. Initial State: state DETECTION - The address in the entry is under		7.6. Initial State: state DETECTION - The address in the entry is under
	local duplication detection		local duplication detection
	7.6.1. Event: EVE_ENTRY_EXPIRE (e.g., Timeout)		7.6.1. Event: EVE_ENTRY_EXPIRE
	(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying		(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying
	by IP address to each DHCPv4 server with IP Address Lease Time		by IP address to each DHCPv4 server with IP Address Lease Time
	option (option 51). A list of authorized DHCP servers are kept		option (option 51). A list of authorized DHCP servers are kept
	by the SAVI device. The list should be pre-configured or		by the SAVI device. The list should be pre-configured or
	discovered by sending DHCPv4 Discover messages and parsing the		discovered by sending DHCPv4 Discover messages and parsing the
	replied DHCPv4 Offer messages. Change the state of the		replied DHCPv4 Offer messages. Change the state of the
	corresponding entry to RECOVERY. Change the lifetime of the		corresponding entry to RECOVERY. Change the lifetime of the
	entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the		entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the
	TID used in the DHCPLEASEQUERY message. If there is no response		TID used in the DHCPLEASEQUERY message. If there is no response
	skipping to change at page 36, line 9 ¶		skipping to change at page 36, line 9 ¶
	In the event that responses are received from multiple DHCP servers,		In the event that responses are received from multiple DHCP servers,
	the conflict resolution mechanisms specified in section 6.8 of		the conflict resolution mechanisms specified in section 6.8 of
	[RFC4388] and section 4.3.4 of [RFC5007] will be used to determine		[RFC4388] and section 4.3.4 of [RFC5007] will be used to determine
	which message should be used.		which message should be used.
	Resulting state: if ARP or ND succeeds (there is a valid response),		Resulting state: if ARP or ND succeeds (there is a valid response),
	BOUND - The binding has been set up. Otherwise, the resulting state		BOUND - The binding has been set up. Otherwise, the resulting state
	is NO_BIND - No binding has been set up		is NO_BIND - No binding has been set up
	7.7.2. Event: EVE_ENTRY_EXPIRE (e.g., Timeout)		7.7.2. Event: EVE_ENTRY_EXPIRE
	Remove the entry		Remove the entry.
	Resulting state: NO_BIND - No binding has been set up		Resulting state: NO_BIND - No binding has been set up
	7.7.3. Events not observed in RECOVERY		7.7.3. Events not observed in RECOVERY
	EVE_DATA_UNMATCH: A data packet without matched binding is received		EVE_DATA_UNMATCH: A data packet without matched binding is received
	EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message		EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
	received from unexpected system		received from unexpected system
	EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received		EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
	EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is		EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
	received		received
	7.8. Initial State: state BOUND - The binding has been set up		7.8. Initial State: state BOUND - The binding has been set up
			Upon entry to the state BOUND, control the system continues as if a
			DHCP message assigning the address has been observed, as in
			Section 6.4.3. The BST entry has been restored.
	Note that the TID field contains no value after the binding state		Note that the TID field contains no value after the binding state
	changes to BOUND. The TID field is recovered from snooping DHCP		changes to BOUND. The TID field is recovered from snooping DHCP
	Renew/Rebind messages. Because TID is used to associate binding		Renew/Rebind messages. Because TID is used to associate binding
	entries with messages from DHCP servers, it must be recovered; or		entries with messages from DHCP servers, it must be recovered; or
	else a number of state transits of this mechanism will be not		else a number of state transits of this mechanism will be not
	executed normally.		executed normally.
	7.8.1. Event: EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message
	is received
	Set the TID field of the corresponding entry to the TID in the
	triggering message.
	Resulting state: BOUND - The binding has been set up
	7.8.2. Event: EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind
	message is received
	Set the TID field of the corresponding entry to the TID in the
	triggering message.
	Resulting state: BOUND - The binding has been set up
	7.8.3. Events not observed in BOUND
	EVE_DATA_UNMATCH: A data packet without matched binding is received
	EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
	received from unexpected system
	EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is
	received
	EVE_ENTRY_EXPIRE
	7.9. Table of State Machine		7.9. Table of State Machine
	The main state transits are listed as follows.		The main state transits are listed as follows.
	State Event Action Next State		State Event Action Next State
	NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION		NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION
	DETECTION EVE_ENTRY_EXPIRE Send Leasequery RECOVERY		DETECTION EVE_ENTRY_EXPIRE Send Leasequery RECOVERY
	DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND		DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
	RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND		RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND
	RECOVERY EVE_ENTRY_EXPIRE Remove entry NO_BIND		RECOVERY EVE_ENTRY_EXPIRE Remove entry NO_BIND
	BOUND RENEW/REBIND Record TID BOUND		BOUND RENEW/REBIND Record TID BOUND
	Figure 13: Table of Transit		Figure 13: Table of Transit
	RENEW: EVE_DHCP_RENEW		RENEW: EVE_DHCP_RENEW
	REBIND: EVE_DHCP_REBIND		REBIND: EVE_DHCP_REBIND
	Timeout: EVE_ENTRY_EXPIRE
	+-------------+		+-------------+
	| |		| |
	/---------| NO_BIND |<--------\		/---------| NO_BIND |<--------\
	| ------>| | | EVE_ENTRY_EXPIRE		| ------>| | | EVE_ENTRY_EXPIRE
	| | +-------------+ |(2nd LQ_DELAY)		| | +-------------+ |(2nd LQ_DELAY)
	EVE_DATA_UNMATCH | | |		EVE_DATA_UNMATCH | | |
	| | |		| | |
	1st | | |		1st | | |
	DETECTION_TIMEOUT | | | 1st LQ_DELAY		DETECTION_TIMEOUT | | | 1st LQ_DELAY
	/------\ | | | /---------\		/------\ | | | /---------\
	skipping to change at page 38, line 46 ¶		skipping to change at page 38, line 17 ¶
	This section specifies how to use bindings to filter out packets with		This section specifies how to use bindings to filter out packets with
	spoofed source addresses.		spoofed source addresses.
	Filtering policies are different for data packets and control		Filtering policies are different for data packets and control
	packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861]		packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861]
	messages are classified as control packets. All other packets are		messages are classified as control packets. All other packets are
	classified as data packets.		classified as data packets.
	8.1. Data Packet Filtering		8.1. Data Packet Filtering
	Data packets from attachments with the Validating attribute MUST be		Data packets from attachments with the Validating attribute TRUE MUST
	checked.		be checked. There is one exception to this rule.
	Packet whose source IP address is a link-local address will not be		A packet whose source IP address is a link-local address cannot be
	checked. Note: as explained in Section 1, a SAVI solution for link-		checked against DHCP assignments, as it is not assigned using DHCP.
	local addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to		Note: as explained in Section 1, a SAVI solution for link-local
	check packets with link-local source address.		addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to check
			packets with a link-local source address.
	If the source IP address of a packet is not a link-local address, but		If the source IP address of a packet is not a link-local address, but
	there is not a matched entry in BST with state BOUND, this packet		there is not a matching entry in BST with state BOUND, this packet
	MUST be discarded. However, the packet may trigger the Data Snooping		MUST be discarded. However, the packet may trigger the Data Snooping
	Process Section 7 if the Data-Snooping attribute is set on the		Process Section 7 if the Data-Snooping attribute is set on the
	attachment.		attachment.
	Data packets from attachments with no attribute will forwarded		Data packets from an attachment with the VALIDATING attribute set
	without being validated.		FALSE will be forwarded without being validated.
	The SAVI device MAY log packets that fail source address validation.		The SAVI device MAY log packets that fail source address validation.
	8.2. Control Packet Filtering		8.2. Control Packet Filtering
	For attachments with the Validating attribute:		For attachments with the Validating attribute:
	DHCPv4 Client-Server messages in which the source IP address is		DHCPv4 Client-Server messages in which the source IP address is
	neither all zeros nor bound with the corresponding binding anchor in		neither all zeros nor bound with the corresponding binding anchor in
	the BST MUST be discarded.		the BST MUST be discarded.
	skipping to change at page 41, line 7 ¶		skipping to change at page 40, line 21 ¶
	Immediately after reboot, the SAVI device SHOULD restore binding		Immediately after reboot, the SAVI device SHOULD restore binding
	states from the non-volatile storage. The system time of save		states from the non-volatile storage. The system time of save
	process MUST be stored. After rebooting, the SAVI device MUST check		process MUST be stored. After rebooting, the SAVI device MUST check
	whether each entry has been obsolete by comparing the saved lifetime		whether each entry has been obsolete by comparing the saved lifetime
	and the difference between the current time and time when the binding		and the difference between the current time and time when the binding
	entry is established.		entry is established.
	10. Constants		10. Constants
	MAX_DHCP_RESPONSE_TIME 120s		The following constants are recommended for use in this context:
	DATA_SNOOPING_INTERVAL 60s and configurable		o MAX_DHCP_RESPONSE_TIME 120s (SOL_MAX_RT from [RFC3315])
	MAX_LEASEQUERY_DELAY 10s		o MAX_LEASEQUERY_DELAY 10s (LQ_MAX_RT from [RFC5007])
	OFFLINK_DELAY 30s		o DETECTION_TIMEOUT 0.5s (TENT_LT from [RFC6620])
	DETECTION_TIMEOUT 0.5s		o DATA_SNOOPING_INTERVAL 60s and configurable (recommendation)
			o OFFLINK_DELAY 30s (recommendation)
	11. Security Considerations		11. Security Considerations
	11.1. Security Problems about the Data Snooping Process		11.1. Security Problems about the Data Snooping Process
	There are two security problems about the Data Snooping Process		There are two security problems about the Data Snooping Process
	Section 7:		Section 7:
	(1) The Data Snooping Process is costly, but an attacker can trigger		(1) The Data Snooping Process is costly, but an attacker can trigger
	it simply through sending a number of data packets. To avoid		it simply through sending a number of data packets. To avoid
	Denial of Services attack against the SAVI device itself, the		Denial of Services attack against the SAVI device itself, the
	Data Snooping Process MUST be rate limited. A constant		Data Snooping Process MUST be rate limited. A constant
	DATA_SNOOPING_INTERVAL is used to control the frequency. Two		DATA_SNOOPING_INTERVAL is used to control the frequency. Two
	Data Snooping Processes on one attachment MUST have a minimum		Data Snooping Processes on one attachment MUST be separated by a
	interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be		minimum interval time DATA_SNOOPING_INTERVAL. If this value is
	configured prudently to avoid Denial of Service attacks.		changed, the value needs to be large enough to minimize denial of
			service attacks.
	(2) The Data Snooping Process may set up wrong bindings if the		(2) The Data Snooping Process may set up incorrect bindings if the
	clients do not reply to the detection probes. An attack will		clients do not reply to the detection probes Section 7.5.1. An
	pass the duplicate detection if the client assigned the target		attack will pass the duplicate detection if the client assigned
	address does not reply to the detection probes. The DHCP Lease		the target address does not reply to the detection probes. The
	query procedure performed by the SAVI device just tells whether		DHCP Lease query procedure performed by the SAVI device just
	the address is assigned in the network or not. However, the SAVI		tells whether the address is assigned in the network or not.
	device cannot determine whether the address is just assigned to		However, the SAVI device cannot determine whether the address is
	the triggering attachment from the DHCP LEASEQUERY Reply.		just assigned to the triggering attachment from the DHCP
			LEASEQUERY Reply.
	11.2. Client departure issues		11.2. Client departure issues
	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 depart temporarily due to signal fade, or		attachment point. It may depart temporarily due to signal fade, or
	permanently by moving to a new attachment point or leaving the		permanently by moving to a new attachment point or leaving the
	network. In the signal fade case, since the client may return		network. In the signal fade case, since the client may return
	shortly, the binding should be kept momentarily, lest legitimate		shortly, the binding should be kept momentarily, lest legitimate
	traffic from the client be blocked. However, if the client leaves		traffic from the client be blocked. However, if the client leaves
	permanently, keeping the binding can be a security issue. If the		permanently, keeping the binding can be a security issue. If the
End of changes. 56 change blocks.
	162 lines changed or deleted		140 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/