< draft-ietf-ipsp-roadmap-00.txt		draft-ietf-ipsp-roadmap-01.txt >
	IPSP Working Group L.A. Sanchez		IPSP Working Group L.A. Sanchez
	INTERNET-DRAFT BBN Technologies		INTERNET-DRAFT BBN Technologies
	Expire in March, 2001 H. Orman		Expire in March, 2001 H. Orman
	Novell Corporation		Novell Corporation
	September 25, 2000		November 16, 2000
	A Roadmap for IPsec Policy Management		A Roadmap for IPsec Policy Management
	draft-ietf-ipsp-roadmap-00.txt		draft-ietf-ipsp-roadmap-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are		all provisions of Section 10 of RFC2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF),		working documents of the Internet Engineering Task Force (IETF),
	its areas, and its working groups. Note that other groups may also		its areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	skipping to change at line 76 ¶		skipping to change at line 76 ¶
	the path of the communication.		the path of the communication.
	2. Roadmap to a solution		2. Roadmap to a solution
	In essence the IPSP WG will produce a set of documents and working		In essence the IPSP WG will produce a set of documents and working
	code. To accomplish this the IPSP WG will work on the items listed		code. To accomplish this the IPSP WG will work on the items listed
	below. Please note, that not all items require code		below. Please note, that not all items require code
	development. Below, you will find a complete list of all		development. Below, you will find a complete list of all
	items. The IPSP WG will:		items. The IPSP WG will:
	1) first establish the requirements for IPsec policy		1) first establish the requirements for IPsec policy
	management. Any solution developed under the IPSP umbrella		management. Any solution developed under the IPSP umbrella
	MUST meet these requirements. The requirements document		MUST meet these requirements. The requirements document
	will cover all aspects of IPsec policy management including:		will cover all aspects of IPsec policy management including:
	- IPsec data model		- IPsec data model
	- IPsec policy architecture		- IPsec policy architecture
	- IPsec policy specification		- IPsec policy specification
	- IPsec policy provisioning		- IPsec policy provisioning
	- IPsec security gateway discovery		- IPsec security gateway discovery
	- IPsec policy discovery, negotiation, conflict		- IPsec policy discovery, negotiation, conflict
	resolution and compliance checking		resolution and compliance checking
	This WG item will produce a standards-track document.		This WG item will produce a standards-track document.
	2) define a data model for IPsec policies. This model will be		2) define a data model for IPsec policies. This model will be
	compatible with the P-CIM [PCIM]. This WG item will		compatible with the P-CIM [PCIM]. This WG item will
	produce a standards-track document.		produce a standards-track document.
	3) develop an architecture for IPsec policy management. The		3) develop an architecture for IPsec policy management. The
	document will discuss and cover the following topics:		document will discuss and cover the following topics:
	- IPsec data model		- IPsec data model
	- IPsec policy specification		- IPsec policy specification
	- IPsec policy provisioning		- IPsec policy provisioning
	- IPsec security gateway discovery		- IPsec security gateway discovery
	- IPsec policy discovery, negotiation, conflict		- IPsec policy discovery, negotiation, conflict
	resolution and compliance checking		resolution and compliance checking
	This WG item will produce a standards-track document.		This WG item will produce a standards-track document.
	4) develop a flexible, vendor-independent language to		4) develop a flexible, vendor-independent language to
	represent IPsec policies. The language MUST follow the		represent IPsec policies. The language MUST follow the
	IPsec data model which in turns follows the P-CIM.		IPsec data model which in turns follows the P-CIM.
	This WG item will produce a standards-track document and		This WG item will produce a standards-track document and
	parser implementations.		parser implementations.
	5) develop guidelines for the provisioning of IPsec policies		5) develop guidelines for the provisioning of IPsec policies
	using existing policy provisioning protocols. This includes		using existing policy provisioning protocols. This includes
	profiles for distributing IPsec policies over protocols		profiles for distributing IPsec policies over protocols
	such as LDAP, COPS, SNMPCONF, FTP, etc.		such as LDAP, COPS, SNMPCONF, FTP, etc.
	This WG item will produce standards-track documents and		This WG item will produce standards-track documents and
	implementations.		implementations.
	6) specify and develop adopt or develop an IPsec policy		6) specify and develop adopt or develop an IPsec policy
	exchange and negotiation protocol. The protocol must be		exchange and negotiation protocol. The protocol must be
	capable of:		capable of:
	i) discovering security gateways		i) discovering security gateways
	ii) exchanging and negotiating security policies, and;		ii) exchanging and negotiating security policies, and;
	iii) resolving policy conflicts in both intra/inter		iii) resolving policy conflicts in both intra/inter
	domain environments. The protocol must be		domain environments. The protocol must be
	independent of any security protocol suite and key		independent of any security protocol suite and key
	management protocol.		management protocol.
	Note that the WG MAY decide to divide the above-mentioned		Note that the WG MAY decide to divide the above-mentioned
	functionality into one or more protocols. This WG item will		functionality into one or more protocols. This WG item will
	produce a standards-track document and implementations.		produce a standards-track document and implementations.
	3. Roadmap Nutshell		3. Roadmap Nutshell
	Roadmap Document		Requirements document. Standards track.
	Information Model		Roadmap Document. This is the roadmap document. Standards track.
	Specification Language		Data Information Model. Standards track.
	Provisioning Guidelines		Policy Management Architecture. Standards track.
	Gateway Discovery, policy exchange,		Specification Language. Standards track document and a reference
			implementation of the parser.
	3. Security Considerations		Provisioning Guidelines. Standards track document and implementations
			using existing provisioning protocols.
			Policy Exchange and Negotiation Protocol. At least one standards
			track document and implementation.
			4. Security Considerations
	The document provides a framework for applications to identify the		The document provides a framework for applications to identify the
	relevant policies in place across the network. Policies must be		relevant policies in place across the network. Policies must be
	communicated in a secure way so as not to jeopardize the ability		communicated in a secure way so as not to jeopardize the ability
	of the application to run. It is also important to ensure that the		of the application to run. It is also important to ensure that the
	policies that are communicated statically or dynamically to the		policies that are communicated statically or dynamically to the
	Policy Enforcement device are doen so, securely. Not doing so could		Policy Enforcement device are doen so, securely. Not doing so could
	compromise the security of the entire network.		compromise the security of the entire network.
	REFERENCES		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", RFC2119, March 1997.		Requirement Levels", RFC2119, March 1997.
	[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet		[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
	Protocol", RFC 2401.		Protocol", RFC 2401.
	[RFC2403] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402		[RFC2403] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402
	[RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload		[RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
	(ESP)", RFC 2406.		(ESP)", RFC 2406.
	[PCIM] Moore, et al., "Policy Core Information Model -- Version 1		[PCIM] Moore, et al., "Policy Core Information Model -- Version 1
	Specification"		Specification"
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-07.txt		ftp://ftp.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-07.txt
	[RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation		[RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation
	for ISAKMP", RFC 2407.		for ISAKMP", RFC 2407.
	[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",		[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
	RFC 2409.		RFC 2409.
	Authors' Addresses		Authors' Addresses
	Luis A. Sanchez		Luis A. Sanchez
	BBN Technologies		BBN Technologies
	GTE Internetworking		GTE Internetworking
	10 Moulton Street		10 Moulton Street
End of changes. 25 change blocks.
	40 lines changed or deleted		47 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/