< draft-ietf-savi-dhcp-31.txt		draft-ietf-savi-dhcp-32.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: July 13, 2015 Tsinghua Univ.		Expires: July 30, 2015 Tsinghua Univ.
	F. Baker		F. Baker
	Cisco		Cisco
	January 9, 2015		January 26, 2015
	SAVI Solution for DHCP		SAVI Solution for DHCP
	draft-ietf-savi-dhcp-31		draft-ietf-savi-dhcp-32
	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 July 13, 2015.		This Internet-Draft will expire on July 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 22 ¶
	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 protected 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, a system attached to a SAVI device can be
	be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI		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, which is to say that the binding attributes are ignored
	tell, a priori, which ports have valid DHCP servers attached, or		until SAVI-DHCP is itself enabled. This is because a SAVI switch
	which have routers or other equipment that would validly appear to		that depends on DHCP cannot tell, a priori, which ports have valid
	use an arbitrary set of source addresses.		DHCP servers attached, or which have routers or other equipment that
			would validly appear to use an arbitrary set of source addresses.
			When SAVI has been enabled, the attributes take effect.
	4.2.1. Trust Attribute		4.2.1. Trust Attribute
	The "Trust Attribute" is a Boolean value. If TRUE, it indicates that		The "Trust Attribute" is a Boolean value. If TRUE, it indicates that
	the packets from the corresponding attached device need not have		the packets from the corresponding attached device need not have
	their source addresses validated. Examples of a trusted binding		their source addresses validated. Examples of a trusted binding
	anchor would be a port to another SAVI device, or to an IP router, as		anchor would be a port to another SAVI device, or to an IP router, as
	shown in Figure 1. In both cases, traffic using many source IP		shown in Figure 1. In both cases, traffic using many source IP
	addresses will be seen. By default, the Trust attribute is FALSE,		addresses will be seen. By default, the Trust attribute is FALSE,
	indicating that any device found on that port will seek an address		indicating that any device found on that port will seek an address
End of changes. 6 change blocks.
	10 lines changed or deleted		12 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/