< draft-ietf-savi-mix-07.txt		draft-ietf-savi-mix-08.txt >
	SAVI J. Bi		SAVI J. Bi
	Internet-Draft G. Yao		Internet-Draft G. Yao
	Intended status: Standards Track Tsinghua Univ.		Intended status: Standards Track Tsinghua Univ.
	Expires: September 9, 2015 J. Halpern		Expires: November 14, 2015 J. Halpern
	Newbridge		Newbridge
	E. Levy-Abegnoli, Ed.		E. Levy-Abegnoli, Ed.
	Cisco		Cisco
	March 8, 2015		May 13, 2015
	SAVI for Mixed Address Assignment Methods Scenario		SAVI for Mixed Address Assignment Methods Scenario
	draft-ietf-savi-mix-07		draft-ietf-savi-mix-08
	Abstract		Abstract
	In case that multiple IP address assignment methods are allowed in a		In case that multiple IP address assignment methods are allowed in a
	network, the corresponding SAVI methods should be enabled to prevent		network, the corresponding SAVI methods should be enabled to prevent
	spoofing in the network. This document reviews how multiple SAVI		spoofing in the network. This document reviews how multiple SAVI
	methods can coexist in a single SAVI device and collisions are		methods can coexist in a single SAVI device and collisions are
	resolved when the same binding entry is discovered by two or more		resolved when the same binding entry is discovered by two or more
	methods.		methods.
	skipping to change at page 1, line 39 ¶		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 September 9, 2015.		This Internet-Draft will expire on November 14, 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 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Recommendations for preventing collisions . . . . . . . . . . 5		5. Recommendations for preventing collisions . . . . . . . . . . 5
	6. Resolving binding collisions . . . . . . . . . . . . . . . . 5		6. Resolving binding collisions . . . . . . . . . . . . . . . . 5
	6.1. Same Address on Different Binding Anchors . . . . . . . . 5		6.1. Same Address on Different Binding Anchors . . . . . . . . 5
	6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6		6.1.1. Basic preference . . . . . . . . . . . . . . . . . . 6
	6.1.2. Overwritten preference . . . . . . . . . . . . . . . 6		6.1.2. Overwritten preference . . . . . . . . . . . . . . . 6
	6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 7		6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 7
	6.2. Same Address on the Same Binding Anchor . . . . . . . . . 7		6.2. Same Address on the Same Binding Anchor . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
			10.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	There are currently several SAVI documents ([RFC6620], [savi-dhcp]		There are currently several SAVI documents ([RFC6620], [savi-dhcp]
	and [RFC7219]) that describe the different methods by which a switch		and [RFC7219]) that describe the different methods by which a switch
	can discover and record bindings between a node's IP address and a		can discover and record bindings between a node's IP address and a
	binding anchor and use that binding to perform source address		binding anchor and use that binding to perform source address
	validation. Each of these documents specifies how to learn on-link		validation. Each of these documents specifies how to learn on-link
	addresses, based on the method used for their assignment,		addresses, based on the method used for their assignment,
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 30 ¶
	6.2. Same Address on the Same Binding Anchor		6.2. Same Address on the Same Binding Anchor
	A binding may be set up on the same binding anchor by multiple		A binding may be set up on the same binding anchor by multiple
	methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes		methods, typically SAVI-FCFS and SAVI-DHCP. If the binding lifetimes
	obtained from the two methods are different, priority should be given		obtained from the two methods are different, priority should be given
	to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least		to 1) Manual configuration 2) SAVI-DHCP 3) SAVI-FCFS as the least
	authoritative. The binding will be removed when the prioritized		authoritative. The binding will be removed when the prioritized
	lifetime expires, even if a less authoritative method had a longer		lifetime expires, even if a less authoritative method had a longer
	lifetime.		lifetime.
	7. IANA Considerations		7. Security Considerations
			SAVI MIX does not eliminate the security problems of each SAVI
			method. Thus, the potential attacks, e.g., the DoS attack against
			the SAVI device resource, can still happen. In deployment, the
			security threats from each enabled SAVI methods should be prevented
			by the corresponding proposed solutions in each document.
			SAVI MIX is only a binding setup/removal arbitration mechanism. It
			does not introduce additional security threats only if the principle
			of decision is reasonable. However, there is a slight problem. SAVI
			MIX is more tolerant about binding establish than each SAVI method
			alone. As long as one of the enabled SAVI method generates a
			binding, the binding will be applied. As a result, the allowed
			binding number limitation or allowed binding setup rate limitation
			will be the sum of all the enabled SAVI methods. In deployment,
			whether a SAVI device is capable to support that resource requirement
			should be evaluated.
			8. IANA Considerations
	This memo asks the IANA for no new parameters.		This memo asks the IANA for no new parameters.
	8. Acknowledgment		9. Acknowledgment
	Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and		Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun and
	Jari Arkko for their valuable contributions.		Jari Arkko for their valuable contributions.
	This document was generated using the xml2rfc tool.		10. References
	9. References
	9.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,		[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
	"Source Address Validation Improvement (SAVI) Framework",		"Source Address Validation Improvement (SAVI) Framework",
	RFC 7039, October 2013.		RFC 7039, October 2013.
	[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS		[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
	SAVI: First-Come, First-Served Source Address Validation		SAVI: First-Come, First-Served Source Address Validation
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 39 ¶
	[RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor		[RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor
	Discovery (SEND) Source Address Validation Improvement		Discovery (SEND) Source Address Validation Improvement
	(SAVI)", RFC 7219, May 2014.		(SAVI)", RFC 7219, May 2014.
	[savi-dhcp]		[savi-dhcp]
	Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for		Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
	DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb		DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb
	2015.		2015.
	9.2. Informative References		10.2. Informative References
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	Authors' Addresses		Authors' Addresses
	Jun Bi		Jun Bi
	Tsinghua University		Tsinghua University
	Network Research Center, Tsinghua University		Network Research Center, Tsinghua University
	Beijing 100084		Beijing 100084
	China		China
	EMail: junbi@tsinghua.edu.cn		EMail: junbi@tsinghua.edu.cn
	Guang Yao		Guang Yao
	Tsinghua University		Tsinghua University
End of changes. 12 change blocks.
	18 lines changed or deleted		34 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/