< draft-bellovin-useipsec-01.txt		draft-bellovin-useipsec-02.txt >
	Network Working Group Steven M. Bellovin		Network Working Group Steven M. Bellovin
	Internet Draft AT&T Labs Research		Internet Draft AT&T Labs Research
	Expiration Date: April 2004 October 2003		Expiration Date: April 2004 October 2003
	Guidelines for Mandating the Use of IPsec		Guidelines for Mandating the Use of IPsec
	draft-bellovin-useipsec-01.txt		draft-bellovin-useipsec-02.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.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	particular, it becomes impossible to apply protection at any finer		particular, it becomes impossible to apply protection at any finer
	grain than "destination host". Thus, traffic embedded in an L2TP		grain than "destination host". Thus, traffic embedded in an L2TP
	[RFC2661] session cannot be protected selectively by IPsec above the		[RFC2661] session cannot be protected selectively by IPsec above the
	L2TP layer, because IPsec has no selectors defined that let it peer		L2TP layer, because IPsec has no selectors defined that let it peer
	into the L2TP packet to find the TCP port numbers. Similarly, SCTP		into the L2TP packet to find the TCP port numbers. Similarly, SCTP
	[RFC2960] did not exist when [RFC2401] was written; thus, protecting		[RFC2960] did not exist when [RFC2401] was written; thus, protecting
	individual SCTP applications on the basis of port number could not be		individual SCTP applications on the basis of port number could not be
	done until a new document is written that defines new selectors for		done until a new document is written that defines new selectors for
	IPsec.		IPsec.
			The granularity of protection available may have side-effects. If
			certain traffic between a pair of machines is protected by IPsec,
			does the implementation permit other traffic to be unprotected, or
			protected by different policies? Alternatively, if the
			implementation is such that it is only capable of protecting all
			traffic or none, does the device have sufficient CPU capacity to
			encrypt everything? Note that some low-end devices may have limited
			secure storage capacity for keys, etc.
	Implementation issues are also a concern here. As before, too many		Implementation issues are also a concern here. As before, too many
	vendors have not implemented the full specifications; too many IPsec		vendors have not implemented the full specifications; too many IPsec
	implementations are not capable of using port numbers in their		implementations are not capable of using port numbers in their
	selectors. Protection of traffic between two hosts is thus on an all		selectors. Protection of traffic between two hosts is thus on an all
	or nothing basis when these non-compliant implementations are		or nothing basis when these non-compliant implementations are
	employed.		employed.
	7. Broadcast and Multicast		7. Broadcast and Multicast
	Although the designers of IPsec tried to leave room for protection of		Although the designers of IPsec tried to leave room for protection of
	skipping to change at page 9, line 17 ¶		skipping to change at page 9, line 17 ¶
	10. Security Considerations		10. Security Considerations
	IPsec provides transmission security and simple access control only.		IPsec provides transmission security and simple access control only.
	There are many other dimensions to protocol security that are beyond		There are many other dimensions to protocol security that are beyond
	the scope of this memo. Within its scope, the security of any		the scope of this memo. Within its scope, the security of any
	resulting protocol depends heavily on the accuracy of the analysis		resulting protocol depends heavily on the accuracy of the analysis
	that resulted in a decision to use IPsec.		that resulted in a decision to use IPsec.
	11. Acknowledgments		11. Acknowledgments
	Ran Atkinson, Barbara Fraser, Paul Hoffman, and Stephen Kent made		Ran Atkinson, Barbara Fraser, Paul Hoffman, Stephen Kent, Eric
	many useful suggestions.		Fleischman, and others have made many useful suggestions.
	12. References		12. References
	[Bell96] "Problem Areas for the IP Security Protocols", S.M.		[Bell96] "Problem Areas for the IP Security Protocols", S.M.
	Bellovin, Proc. Sixth Usenix Security Symposium, 1996, pp.		Bellovin, Proc. Sixth Usenix Security Symposium, 1996, pp.
	205-214.		205-214.
	[Kent00a] "Secure Border Gateway Protocol (Secure-BGP)", S. Kent, C.		[Kent00a] "Secure Border Gateway Protocol (Secure-BGP)", S. Kent, C.
	Lynn, and K. Seo, IEEE Journal on Selected Areas in		Lynn, and K. Seo, IEEE Journal on Selected Areas in
	Communications 18:4, April 2000, pp. 582-592.		Communications 18:4, April 2000, pp. 582-592.
End of changes. 3 change blocks.
	3 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/