< draft-ietf-savi-mix-08.txt		draft-ietf-savi-mix-09.txt >
	SAVI J. Bi		SAVI J. Bi
	Internet-Draft G. Yao		Internet-Draft Tsinghua Univ.
	Intended status: Standards Track Tsinghua Univ.		Intended status: Standards Track G. Yao
	Expires: November 14, 2015 J. Halpern		Expires: January 20, 2016 Baidu
			J. Halpern
	Newbridge		Newbridge
	E. Levy-Abegnoli, Ed.		E. Levy-Abegnoli, Ed.
	Cisco		Cisco
	May 13, 2015		July 19, 2015
	SAVI for Mixed Address Assignment Methods Scenario		SAVI for Mixed Address Assignment Methods Scenario
	draft-ietf-savi-mix-08		draft-ietf-savi-mix-09
	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 38 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 14, 2015.		This Internet-Draft will expire on January 20, 2016.
	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 28 ¶		skipping to change at page 2, line 29 ¶
	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. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	There are currently several SAVI documents ([RFC6620], [savi-dhcp]		There are currently several SAVI documents ([RFC6620], [RFC7513] and
	and [RFC7219]) that describe the different methods by which a switch		[RFC7219]) that describe the different methods by which a switch can
	can discover and record bindings between a node's IP address and a		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,
	respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host		respectively: StateLess Autoconfiguration (SLAAC), Dynamic Host
	Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each		Control Protocol (DHCP) and Secure Neighbor Discovery (SeND). Each
	of these documents describes separately how one particular method		of these documents describes separately how one particular method
	deals with address collisions (same address, different binding		deals with address collisions (same address, different binding
	anchor).		anchor).
	While multiple IP assignment methods can be used in the same layer-2		While multiple IP assignment methods can be used in the same layer-2
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	methods come up with competing bindings.		methods come up with competing bindings.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Problem Scope		3. Problem Scope
	There are three IP address assignment methods identified and reviewed		Three different IP address assignment methods have been analyzed for
	in one of the SAVI document:		SAVI:
	1. StateLess Address AutoConfiguration (SLAAC) - reviewed in SAVI-		1. StateLess Address AutoConfiguration (SLAAC) - analyzed in SAVI-
	FCFS[RFC6620]		FCFS[RFC6620]
	2. Dynamic Host Control Protocol address assignment (DHCP) -		2. Dynamic Host Control Protocol address assignment (DHCP) -
	reviewed in SAVI-DHCP[savi-dhcp]		analyzed in SAVI-DHCP[RFC7513]
	3. Secure Neighbor Discovery (SeND) address assignment, reviewed in		3. Secure Neighbor Discovery (SeND) address assignment, analyzed in
	SAVI-SEND[RFC7219]		SAVI-SEND[RFC7219]
	In addition, there is a fourth method for installing a bindings on		In addition, there is a fourth method for managing (i.e., creation,
	the switch, referred to as "manual". It is based on manual (address		management, deletion) a binding on the switch, referred to as
	or prefix) binding configuration and is reviewed in [RFC6620] and		"manual". It is based on manual binding configuration and is
	[RFC7039].		analyzed in [RFC6620] and [RFC7039].
	All combinations of address assignment methods can coexist within a		All combinations of address assignment methods can coexist within a
	layer-2 domain. A SAVI device will have to implement the		layer-2 domain. A SAVI device MUST implement the corresponding
	corresponding binding setup methods (referred to as a "SAVI method")		binding setup methods (referred to as a "SAVI method") to enable
	to enable Source Address Validation. If more than one SAVI method is		Source Address Validation. If more than one SAVI method is enabled
	enabled on a SAVI device, the method is referred to as "mix address		on a SAVI device, the method is referred to as "mix address
	assignment method" in this document.		assignment method" in this document.
	SAVI methods are independent from each other, each one handling its		SAVI methods are independent from each other, each one handling its
	own entries. In the absence of reconciliation, each method will		own entries. In the absence of reconciliation, each method will
	reject packets sourced with an address it did not discovered. To		reject packets sourced with an address it did not discovered. To
	prevent addresses discovered by one method to be filtered out by		prevent addresses discovered by one method to be filtered out by
	another, the binding table should be shared by all the solutions.		another, the binding table should be shared by all the solutions.
	However this could create some conflict when the same entry is		However this could create some conflict when the same entry is
	discovered by two different methods: the purpose of this document is		discovered by two different methods. The purpose of this document is
	of two folds: provide recommendations and method to avoid conflicts,		of two folds: provide recommendations and methods to avoid conflicts,
	and resolve conflicts if and when they happen. Collisions happening		and resolve conflicts if and when they happen. Collisions happening
	within a given method are outside the scope of this document.		within a given method are outside the scope of this document.
	4. Architecture		4. Architecture
	A SAVI device may enable multiple SAVI methods. This mechanism,		A SAVI device may enable multiple SAVI methods. This mechanism,
	called SAVI-MIX, is proposed as a arbiter of the binding generation		called SAVI-MIX, is proposed as a arbiter of the binding generation
	algorithms, generating the final working binding entries Figure 1.		algorithms, generating the final binding entries as illustrated in
			Figure 1. Once a SAVI method generates a candidate binding, it will
	Once a SAVI method generates a candidate binding, it will request		request SAVI-MIX to set up a corresponding entry in the binding
	SAVI-MIX to set up a corresponding entry in the binding table. Then		table. Then SAVI-MIX will check if there is any conflict in the
	SAVI-MIX will check if there is any conflict in the binding table. A		binding table. A new binding will be generated if there is no
	new binding will be generated if there is no conflict. If there is a		conflict. If there is a conflict, SAVI-MIX will determine whether to
	conflict, SAVI-MIX will determine whether to replace the existing		replace the existing binding or reject the candidate binding based on
	binding or reject the candidate binding based on the policies		the policies specified in Section 6.
	specified in Section 6.
	The packet filtering will not be performed by each SAVI method		The packet filtering will not be performed by each SAVI method
	separately. Instead, SAVI-MIX will perform filtering based on the		separately. Instead, SAVI-MIX will perform filtering based on the
	entries in the binding table.		entries in the binding table.
	+--------------------------------------------------------+		+--------------------------------------------------------+
	| |		| |
	| SAVI Device |		| SAVI Device |
	| |		| |
	| |		| |
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set		1. DHCP/SLAAC: use non-overlapping prefix for DHCP and SLAAC. Set
	the A bit in Prefix information option of Router Advertisement		the A bit in Prefix information option of Router Advertisement
	for SLAAC prefix, and set the M bit in Router Advertisement for		for SLAAC prefix, and set the M bit in Router Advertisement for
	DHCP prefix. For detail explanations on these bits, refer to		DHCP prefix. For detail explanations on these bits, refer to
	[RFC4861][RFC4862].		[RFC4861][RFC4862].
	2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND		2. SeND/non-SeND: avoid mixed environment (where SeND and non-SeND
	nodes are deployed) or separate the prefixes announced to SeND		nodes are deployed) or separate the prefixes announced to SeND
	and non-SenD nodes. One way to separate the prefixes is to have		and non-SenD nodes. One way to separate the prefixes is to have
	the router(s) announcing different (non-overlapping) prefixes to		the router(s) announcing different (non-overlapping) prefixes to
	SeND and to non-SeND nodes, using unicast Router Advertisements,		SeND and to non-SeND nodes, using unicast Router
	in response to SeND/non-SeND Router Solicit.		Advertisements[RFC6085], in response to SeND/non-SeND Router
			Solicit.
	6. Resolving binding collisions		6. Resolving binding collisions
	In situations where collisions could not be avoided, two cases should		In situations where collisions could not be avoided, two cases should
	be considered:		be considered:
	1. The same address is bound on two different binding anchors by		1. The same address is bound on two different binding anchors by
	different SAVI methods.		different SAVI methods.
	2. The same address is bound on the same binding anchor by different		2. The same address is bound on the same binding anchor by different
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	node X, installed in the binding table using SAVI-FCFS, anchored to		node X, installed in the binding table using SAVI-FCFS, anchored to
	"anchor-X". Later, the same address is assigned by DHCP to node Y,		"anchor-X". Later, the same address is assigned by DHCP to node Y,
	and SAVI-DHCP will generate a candidate binding entry, anchored to		and SAVI-DHCP will generate a candidate binding entry, anchored to
	"anchor-Y".		"anchor-Y".
	6.1.1. Basic preference		6.1.1. Basic preference
	The SAVI device must decide whom the address should be bound with		The SAVI device must decide whom the address should be bound with
	(anchor-X or anchor-Y in this example). Current standard documents		(anchor-X or anchor-Y in this example). Current standard documents
	of address assignment methods have implied the prioritization		of address assignment methods have implied the prioritization
	relationship (first-come). In the absence of any configuration or		relationship, i.e., first-come.
	protocol hint (see Section 6.1.2) the SAVI device should choose the
	first-come binding anchor, whether it was learnt from SLACC, SeND or		1. SLAAC: s5.4.5 of [RFC4862]
	DHCP.
			2. DHCPv4: s3.1-p5 of [RFC2131]
			3. DHCPv6: s18.1.8 of [RFC3315]
			4. SeND: s8 of [RFC3971]
			In the absence of any configuration or protocol hint (see
			Section 6.1.2) the SAVI device should choose the first-come binding
			anchor, whether it was learnt from SLAAC, SeND or DHCP.
	6.1.2. Overwritten preference		6.1.2. Overwritten preference
	There are two identified exceptions to the general prioritization		There are two identified exceptions to the general prioritization
	model, one of them being CGA addresses, another one controlled by the		model, one of them being CGA addresses, another one controlled by the
	configuration of the switch.		configuration of the switch.
	6.1.2.1. CGA preference		6.1.2.1. CGA preference
	When CGA addresses are used, and a collision is detected, preference		When CGA addresses are used, and a collision is detected, preference
	should be given to the anchor that carries the CGA credentials once		should be given to the anchor that carries the CGA credentials once
	they are verified, in particular the CGA parameters and the RSA		they are verified, in particular the CGA parameters and the RSA
	options. Note that if an attacker was trying to replay CGA		options. Note that if an attacker was trying to replay CGA
	credentials, he would then compete on the base of fcfs (first-come,		credentials, he would then compete on the base of "First-Come, First-
	first-serve).		Served" (FCFS) principle.
	6.1.2.2. configuration preference		6.1.2.2. configuration preference
	For configuration driven exceptions, the SAVI device may allow the		For configuration driven exceptions, the SAVI device may allow the
	configuration of a triplet ("prefix", "anchor", "method") or		configuration of a triplet ("prefix", "anchor", "method") or
	("address", "anchor", "method"), where at least one of ("anchor",		("address", "anchor", "method"), where at least one of ("anchor",
	"method") should be specified. Later, if a DAD message is received		"method") should be specified. Later, if a DAD message is received
	with the following conditions verified:		with the following conditions verified:
	1. The target in the DAD message does not exist in the binding table		1. The target in the DAD message does not exist in the binding table
	2. The target is within configured "prefix" (or equal to "address")		2. The target is within configured "prefix" (or equal to "address")
	3. The anchor bound to target is different from the configured		3. The anchor bound to target is different from the configured
	anchor, when specified		anchor, when specified
	4. The configured method, if any, is different from SAVI-FCFS		4. The configured method, if any, is different from SAVI-FCFS
	the switch should defend the address by responding to the DAD		the switch should defend the address by responding to the DAD
	message. It should not at this point install the entry into the		message, with a NA message or an ARP response, on behalf of the
	binding table. It will simply prevent the node to assign the		target node. Plain NA will be replied to SeND DAD. SeND accepts
	address, and will de-facto prioritize the configured anchor. This is		plain NA for the first time (see s8 of [RFC3971]). The probability
	especially useful to protect well known bindings such as a static		for a SeND node to generate a colliding address more than one time is
	address of a server over anybody, even when the server is down. It		trivial in practice, thus the response can effectively protect an
	is also a way to give priority to a binding learnt from SAVI-DHCP		existing binding.
	over a binding for the same address, learnt from SAVI-FCFS.
			It should not at this point install the entry into the binding table.
			It will simply prevent the node to assign the address, and will de-
			facto prioritize the configured anchor. This is especially useful to
			protect well known bindings such as a static address of a server over
			anybody, even when the server is down. It is also a way to give
			priority to a binding learnt from SAVI-DHCP over a binding for the
			same address, learnt from SAVI-FCFS.
	6.1.3. Multiple SAVI Device Scenario		6.1.3. Multiple SAVI Device Scenario
	A single SAVI device doesn't have the information of all bound		A single SAVI device doesn't have the information of all bound
	addresses on the perimeter. Therefore it is not enough to lookup		addresses on the perimeter. Therefore it is not enough to lookup
	local bindings to identify a collision. However, assuming DAD is		local bindings to identify a collision. However, assuming DAD is
	performed throughout the security perimeter for all addresses		performed throughout the security perimeter for all addresses
	regardless of the assignment method, then DAD response will inform		regardless of the assignment method, then DAD response will inform
	all SAVI devices about any collision. In that case, FCFS will apply		all SAVI devices about any collision. In that case, FCFS will apply
	the same way as in a single switch scenario. If the admin configured		the same way as in a single switch scenario. If the admin configured
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 32 ¶
	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.
	10. References		10. References
	10.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,		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	"Source Address Validation Improvement (SAVI) Framework",		RFC 2131, DOI 10.17487/RFC2131, March 1997,
	RFC 7039, October 2013.		<http://www.rfc-editor.org/info/rfc2131>.
			[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
			C., and M. Carney, "Dynamic Host Configuration Protocol
			for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
			2003, <http://www.rfc-editor.org/info/rfc3315>.
			[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
			"SEcure Neighbor Discovery (SEND)", RFC 3971,
			DOI 10.17487/RFC3971, March 2005,
			<http://www.rfc-editor.org/info/rfc3971>.
			[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
			"Address Mapping of IPv6 Multicast Packets on Ethernet",
			RFC 6085, DOI 10.17487/RFC6085, January 2011,
			<http://www.rfc-editor.org/info/rfc6085>.
	[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
	Improvement for Locally Assigned IPv6 Addresses", RFC		Improvement for Locally Assigned IPv6 Addresses",
	6620, May 2012.		RFC 6620, DOI 10.17487/RFC6620, May 2012,
			<http://www.rfc-editor.org/info/rfc6620>.
			[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
			"Source Address Validation Improvement (SAVI) Framework",
			RFC 7039, DOI 10.17487/RFC7039, October 2013,
			<http://www.rfc-editor.org/info/rfc7039>.
	[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, DOI 10.17487/RFC7219, May 2014,
			<http://www.rfc-editor.org/info/rfc7219>.
	[savi-dhcp]		[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
	Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for		Validation Improvement (SAVI) Solution for DHCP",
	DHCP", draft-ietf-savi-dhcp-34 (work in progress), Feb		RFC 7513, DOI 10.17487/RFC7513, May 2015,
	2015.		<http://www.rfc-editor.org/info/rfc7513>.
	10.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.		DOI 10.17487/RFC4861, September 2007,
			<http://www.rfc-editor.org/info/rfc4861>.
	[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,
			DOI 10.17487/RFC4862, September 2007,
			<http://www.rfc-editor.org/info/rfc4862>.
	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		Baidu
	Network Research Center, Tsinghua University		Baidu Science and Technology Park, Building 1
	Beijing 100084		Beijing 100193
	China		China
	EMail: yaoguang.china@gmail.com		EMail: yaoguang.china@gmail.com
	Joel M. Halpern		Joel M. Halpern
	Newbridge Networks Inc		Newbridge Networks Inc
	EMail: jmh@joelhalpern.com		EMail: jmh@joelhalpern.com
	Eric Levy-Abegnoli (editor)		Eric Levy-Abegnoli (editor)
End of changes. 28 change blocks.
	66 lines changed or deleted		109 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/