< draft-anipko-mif-mpvd-arch-00.txt		draft-anipko-mif-mpvd-arch-01.txt >
	MIF Working Group D. Anipko		MIF Working Group D. Anipko
	Internet-Draft Microsoft Corporation		Internet-Draft Microsoft Corporation
	Intended status: Informational July 2013		Intended status: Informational July 23, 2013
	Expires: December 31, 2013		Expires: January 22, 2014
	Multiple Provisioning Domain Architecture		Multiple Provisioning Domain Architecture
	draft-anipko-mif-mpvd-arch-00		draft-anipko-mif-mpvd-arch-01
	Abstract		Abstract
	This document is a product of the work of MIF architecture design		This document is a product of the work of MIF architecture design
	team. It outlines a solution framework for some of the issues,		team. It outlines a solution framework for some of the issues,
	experienced by nodes that can be attached to multiple networks. The		experienced by nodes that can be attached to multiple networks. The
	framework defines the notion of a Provisioning Domain (PVD) - a		framework defines the notion of a Provisioning Domain (PVD) - a
	consistent set of network configuration information, and PVD-aware		consistent set of network configuration information, and PVD-aware
	nodes - nodes which learn PVDs from the attached network(s) and/or		nodes - nodes which learn PVDs from the attached network(s) and/or
	other sources and manage and use multiple PVDs for connectivity		other sources and manage and use multiple PVDs for connectivity
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 31, 2013.		This Internet-Draft will expire on January 22, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	2.1. Explicit and implicit PVDs . . . . . . . . . . . . . . . . 4		2.1. Explicit and implicit PVDs . . . . . . . . . . . . . . . . 4
	2.2. Relationship between PVDs and interfaces . . . . . . . . . 5		2.2. Relationship between PVDs and interfaces . . . . . . . . . 5
	2.3. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5		2.3. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5
	2.4. Relationship to dual-stack networks . . . . . . . . . . . 5		2.4. Relationship to dual-stack networks . . . . . . . . . . . 5
	2.5. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 6		2.5. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 6
	3. Example network configurations and number of PVDs . . . . . . 6		3. Example network configurations and number of PVDs . . . . . . 6
	4. Reference model of PVD-aware node . . . . . . . . . . . . . . 6		4. Reference model of PVD-aware node . . . . . . . . . . . . . . 6
	4.1. Constructions and maintenance of separate PVDs . . . . . . 6		4.1. Constructions and maintenance of separate PVDs . . . . . . 6
	4.2. Consistent use of PVDs for network connections . . . . . . 6		4.2. Consistent use of PVDs for network connections . . . . . . 6
	4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 6		4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 6
	4.2.2. Next-hop and source address selection . . . . . . . . 6		4.2.2. Next-hop and source address selection . . . . . . . . 7
	4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 7		4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 7
	4.4. Relationship to interface management and connection manager 7		4.4. Relationship to interface management and connection manager 7
	5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 7		5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 7		5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 7		5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 7		5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 7		6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 8
	6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 8
	6.2. Authenticated PVDs . . . . . . . . . . . . . . . . . . . . 8		6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 8
	6.3. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 8		6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 9
	6.3.1. Trust via strong ID . . . . . . . . . . . . . . . . . 8		6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 9
	6.3.2. Trust via attachment . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Nodes attached to multiple networks may encounter problems due to		Nodes attached to multiple networks may encounter problems due to
	conflict of the networks configuration and/or simultaneous use of		conflict of the networks configuration and/or simultaneous use of
	the multiple available networks. While existing implementations		the multiple available networks. While existing implementations
	apply various techniques (RFC 6419 [RFC6419]) to tackle such		apply various techniques ([RFC6419]) to tackle such problems, in many
	problems, in many cases the issues may still appear. The MIF problem		cases the issues may still appear. The MIF problem statement
	statement document RFC 6418 [RFC6418] describes the general landscape		document [RFC6418] describes the general landscape as well as
	as well as discusses many specific issues details.		discusses many specific issues details.
	Across the layers, problems enumerated in RFC 6418 [RFC6418] can be		Across the layers, problems enumerated in [RFC6418] can be grouped
	grouped into 3 categories:		into 3 categories:
	1. Lack of consistent and distinctive management of configuration		1. Lack of consistent and distinctive management of configuration
	elements, associated with different networks.		elements, associated with different networks.
	2. Inappropriate mixed use of configuration elements, associated		2. Inappropriate mixed use of configuration elements, associated
	with different networks, in the course of a particular network		with different networks, in the course of a particular network
	activity / connection.		activity / connection.
	3. Use of a particular network, not consistent with the intent of		3. Use of a particular network, not consistent with the intent of
	the scenario / involved parties, leading to connectivity failure		the scenario / involved parties, leading to connectivity failure
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 49 ¶
	1.1. Requirements Language		1.1. 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].
	2. Definitions and types of PVDs		2. Definitions and types of PVDs
	Provisioning Domain: a consistent set of network configuration		Provisioning Domain: a consistent set of network configuration
	information. Usually, the entire set available on a single interface		information. Classically, the entire set available on a single
	is provided by a single source, such as network administrator.		interface is provided by a single source, such as network
	Typical examples of such information, learned from the network, are:		administrator, and can therefore be treated as a single provisioning
	source address prefixes, used by the network, IP address of DNS		domain. In modern IPv6 networks, multihoming can result in more than
	server, name of HTTP proxy server if available, DNS suffixes		one provisioning domain being present on a single link. In some
	associated with the network etc.		scenarios, it is also possible for elements of the same domain to be
			present on multiple links.
	It is also possible for other sources, such as e.g. node local		Typical examples of information in a provisioning domain, learned
	policy, user input or other out of band mechanisms to either		from the network, are: source address prefixes, to be used by
	construct a PVD entirely (analogously to static IP configuration of		connections within the provisioning domain, IP address of DNS server,
	an interface), or supplement with particular elements all or some		name of HTTP proxy server if available, DNS suffixes associated with
	PVDs learned from the network. As an example, node administrator		the network etc.
	could inject a not ISP-specific DNS server into PVDs for any of the
	networks the node could become attached to. Such creation /		In some cases, other sources, such as e.g., node local policy, user
	augmentation of PVD could be static or dynamic. The particular		input or other out of band mechanisms may be used to either construct
	implementation mechanisms are outside of the scope of this document.		a PVD entirely (analogously to static IP configuration of an
			interface), or supplement with particular elements all or some PVDs
			learned from the network.
			As an example, node administrator could inject a not ISP-specific DNS
			server into PVDs for any of the networks the node could become
			attached to. Such creation / augmentation of PVD(s) could be static
			or dynamic. The particular implementation mechanisms are outside of
			the scope of this document.
	PVD-aware node: a node that supports association of network		PVD-aware node: a node that supports association of network
	configuration information into PVDs, and using the resultant PVDs to		configuration information into PVDs, and using the resultant PVDs to
	serve requests for network connections in a way, consistent with		serve requests for network connections in a way, consistent with
	recommendations of this architecture.		recommendations of this architecture.
	2.1. Explicit and implicit PVDs		2.1. Explicit and implicit PVDs
	A node may receive explicit information from the network and/or other		A node may receive explicit information from the network and/or other
	sources, about presence of PVDs and association of particular network		sources, about presence of PVDs and association of particular network
	skipping to change at page 6, line 46 ¶		skipping to change at page 7, line 5 ¶
	form of PVD ID, as determined by the node policy.		form of PVD ID, as determined by the node policy.
	The node may pick multiple PVDs, if e.g., they are general purpose		The node may pick multiple PVDs, if e.g., they are general purpose
	PVDs providing connectivity to the Internet, and the node desires to		PVDs providing connectivity to the Internet, and the node desires to
	maximize chances for connectivity in Happy Eyeballs style. In this		maximize chances for connectivity in Happy Eyeballs style. In this
	case, the node could do the lookups in parallel, or in sequence.		case, the node could do the lookups in parallel, or in sequence.
	Alternatively, the node may use for the lookup only one PVD, based on		Alternatively, the node may use for the lookup only one PVD, based on
	the PVD connectivity properties, user choice of the preferred		the PVD connectivity properties, user choice of the preferred
	Internet PVD, etc.		Internet PVD, etc.
	In either case, by default the node shall use for the following		In either case, by default the node uses information obtained in a
	connection request the PVD, where the lookup results were obtained.		name service lookup to establish connections only within the same PVD
			from which the lookup results were obtained.
			For simplicity, when we say that name service lookup results were
			obtained from a PVD, what we mean is that the name service query was
			issued against a name service the configuration of which is present
			in a particular PVD. In that sense, the results are "from" that
			particular PVD.
	4.2.2. Next-hop and source address selection		4.2.2. Next-hop and source address selection
	For the purpose of this discussion, let's assume the preceding name		For the purpose of this discussion, let's assume the preceding name
	lookup succeeded in a particular PVD. For each obtained destination		lookup succeeded in a particular PVD. For each obtained destination
	address, the node shall perform a next-hop lookup among routers,		address, the node shall perform a next-hop lookup among routers,
	associated with that PVD. As an example, such association could be		associated with that PVD. As an example, such association could be
	determined by the node via matching the source address prefixes/		determined by the node via matching the source address prefixes/
	specific routes advertized by the router against known PVDs, or		specific routes advertized by the router against known PVDs, or
	receiving explicit PVD affiliation advertized through a new Router		receiving explicit PVD affiliation advertized through a new Router
	Discovery [RFC4861] option.		Discovery [RFC4861] option.
	For each destination, once the best next-hop is found, the node		For each destination, once the best next-hop is found, the node
	selects best source address according to the RFC 6724 [RFC6724]		selects best source address according to the [RFC6724] rules, but
	rules, but with a constraint that the source address must belong to a		with a constraint that the source address must belong to a range
	range associated with the used PVD. If needed, the node would use the		associated with the used PVD. If needed, the node would use the
	prefix policy from the same PVD for the best source address selection		prefix policy from the same PVD for the best source address selection
	among multiple candidates.		among multiple candidates.
	When destination/source pairs are identified, then they are sorted		When destination/source pairs are identified, then they are sorted
	using the RFC 6724 [RFC6724] destination sorting rules and the prefix		using the [RFC6724] destination sorting rules and the prefix policy
	policy table from the used PVD.		table from the used PVD.
	4.3. Connectivity tests		4.3. Connectivity tests
	4.4. Relationship to interface management and connection managers		4.4. Relationship to interface management and connection managers
	5. PVD support in APIs		5. PVD support in APIs
	In all cases changes in available PVDs must be somehow exposed,		In all cases changes in available PVDs must be somehow exposed,
	appropriately for each of the approaches.		appropriately for each of the approaches.
	5.1. Basic		5.1. Basic
	Applications are not PVD-aware in any manner, and only submit		Applications are not PVD-aware in any manner, and only submit
	connection requests. The node performs PVD selection implicitly,		connection requests. The node performs PVD selection implicitly,
	without any otherwise applications participation, and based purely on		without any otherwise applications participation, and based purely on
	policies and/or user choice.		node-specific administrative policies and/or choices made by the user
			in a user interface provided by the operating environment, not by the
			application.
	5.2. Intermediate		5.2. Intermediate
	Applications indirectly participate in selection of PVD by specifying		Applications indirectly participate in selection of PVD by specifying
	hard requirements and soft preferences. The node performs PVD		hard requirements and soft preferences. The node performs PVD
	selection, based on applications inputs and policies and/or user		selection, based on applications inputs and policies and/or user
	preferences. Some / all properties of the resultant PVD may be		preferences. Some / all properties of the resultant PVD may be
	exposed to applications.		exposed to applications.
	5.3. Advanced		5.3. Advanced
	PVDs are directly exposed to applications, for enumeration and		PVDs are directly exposed to applications, for enumeration and
	selection, within limits allowed by the node policies and / or user		selection. Node polices and/or user choices, may still override the
	preferences.		application preferences and limit which PVD(s) can be enumerated and/
			or used by the application, irrespectively of any preferences which
			application may have specified. Depending on the implementation,
			such restrictions, imposed per node policy and/or user choice, may or
			may not be visible to the application.
	6. PVD-aware nodes trust to PVDs		6. PVD-aware nodes trust to PVDs
	6.1. Untrusted PVDs		6.1. Untrusted PVDs
	6.2. Authenticated PVDs
	6.3. Trusted PVDs		Implicit and explicit PVDs for which no trust relationship exists are
			considered untrusted. Only PVDs, which meet the requirements in
			Section 6.2, are trusted; any other PVD is untrusted.
	6.3.1. Trust via strong ID		In order to avoid various forms of misinformation that can be
			asserted when PVDs are untrusted, nodes that implement PVD separation
			cannot assume that two explicit PVDs with the same identifier are
			actually the same PVD. A node that did make this assumption would be
			vulnerable to attacks where for example an open Wifi hotspot might
			assert that it was part of another PVD, and thereby might draw
			traffic intended for that PVD onto its own network.
	6.3.2. Trust via attachment		Since implicit PVD identifiers are synthesized by the node, this
			issue cannot arise with implicit PVDs.
			Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide
			configuration information that asserts special knowledge about the
			reachability of resources through that PVD. Such assertions cannot
			be validated unless the node has a trust relationship with the PVD;
			assertions of this type therefore must be ignored by nodes that
			receive them from untrusted PVDs. Failure to ignore such assertions
			could result in traffic being diverted from legitimate destinations
			to spoofed destinations.
			6.2. Trusted PVDs
			Trusted PVDs are PVDs for which two conditions apply. First, a
			trust relationship must exist between the node that is using the PVD
			configuration and the source that provided that configuration; this
			is the authorization portion of the trust relationship. Second,
			there must be some way to validate the trust relationship. This is
			the authentication portion of the trust relationship. Two
			mechanisms for validating the trust relationship are defined.
			6.2.1. Authenticated PVDs
			One way to validate the trust relationship between a node and the
			source of a PVD is through the combination of cryptographic
			authentication and an identifier configured on the node. In some
			cases, the two could be the same; for example, if authentication is
			done with a shared secret, the secret would have to be associated
			with the PVD identifier. Without a (PVD Identifier, shared key)
			tuple, authentication would be impossible, and hence authentication
			and authorization are combined.
			However, if authentication is done using some public key mechanism
			such as a TLS cert or DANE, authentication by itself isn't enough,
			since theoretically any PVD could be authenticated in this way. In
			addition to authentication, the node would need to be configured to
			trust the identifier being authenticated. Validating the
			authenticated PVD name against a list of PVD names configured as
			trusted on the node would constitute the authorization step in this
			case.
			6.2.2. PVDs trusted by attachment
			In some cases a trust relationship may be validated by some means
			other than described in Section 6.2.1, simply by virtue of the
			connection through which the PVD was obtained. For instance, a
			handset connected to a mobile network may know through the mobile
			network infrastructure that it is connected to a trusted PVD, and
			whatever mechanism was used to validate that connection constitutes
			the authentication portion of the PVD trust relationship.
			Presumably such a handset would be configured from the factory, or
			else through mobile operator or user preference settings, to trust
			the PVD, and this would constitute the authorization portion of this
			type of trust relationship.
	7. Acknowledgements		7. Acknowledgements
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Security Considerations		9. Security Considerations
	All drafts are required to have a security considerations section.		All drafts are required to have a security considerations section.
	skipping to change at page 8, line 51 ¶		skipping to change at page 10, line 25 ¶
	Provisioning Domains Problem Statement", RFC 6418,		Provisioning Domains Problem Statement", RFC 6418,
	November 2011.		November 2011.
	[RFC6419] Wasserman, M. and P. Seite, "Current Practices for		[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
	Multiple-Interface Hosts", RFC 6419, November 2011.		Multiple-Interface Hosts", RFC 6419, November 2011.
	[RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown,		[RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, September 2012.		(IPv6)", RFC 6724, September 2012.
			[RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive
			DNS Server Selection for Multi-Interfaced Nodes", RFC
			6731, December 2012.
	Author's Address		Author's Address
	Dmitry Anipko		Dmitry Anipko
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Phone: +1 425 703 7070		Phone: +1 425 703 7070
	Email: dmitry.anipko@microsoft.com		Email: dmitry.anipko@microsoft.com
End of changes. 22 change blocks.
	55 lines changed or deleted		142 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/