draft-ietf-opsec-ip-security-05.txt		draft-ietf-opsec-ip-security-06.txt
	Operational Security Capabilities F. Gont		Operational Security Capabilities F. Gont
	for IP Network Infrastructure UK CPNI		for IP Network Infrastructure UK CPNI
	(opsec) December 16, 2010		(opsec) January 27, 2011
	Internet-Draft		Internet-Draft
	Intended status: Informational		Intended status: Informational
	Expires: June 19, 2011		Expires: July 31, 2011
	Security Assessment of the Internet Protocol version 4		Security Assessment of the Internet Protocol version 4
	draft-ietf-opsec-ip-security-05.txt		draft-ietf-opsec-ip-security-06.txt
	Abstract		Abstract
	This document contains a security assessment of the IETF		This document contains a security assessment of the IETF
	specifications of the Internet Protocol version 4, and of a number of		specifications of the Internet Protocol version 4, and of a number of
	mechanisms and policies in use by popular IPv4 implementations. It		mechanisms and policies in use by popular IPv4 implementations. It
	is based on the results of a project carried out by the UK's Centre		is based on the results of a project carried out by the UK's Centre
	for the Protection of National Infrastructure (CPNI).		for the Protection of National Infrastructure (CPNI).
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 June 19, 2011.		This Internet-Draft will expire on July 31, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7		1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7
	1.3. Organization of this document . . . . . . . . . . . . . . 7		1.3. Organization of this document . . . . . . . . . . . . . . 8
	2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8		2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8
	3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 8		3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 8
	3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10		3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10
	3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11		3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11
	3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11		3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11
	3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12		3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12
	3.3.2.1. Differentiated Services field . . . . . . . . . . 12		3.3.2.1. Differentiated Services field . . . . . . . . . . 12
	3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13		3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13
	3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 14		3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 14
	skipping to change at page 4, line 16		skipping to change at page 4, line 16
	4.3.5. Broadcast/Multicast addresses, and		4.3.5. Broadcast/Multicast addresses, and
	Connection-Oriented Protocols . . . . . . . . . . . . 62		Connection-Oriented Protocols . . . . . . . . . . . . 62
	4.3.6. Broadcast and network addresses . . . . . . . . . . . 62		4.3.6. Broadcast and network addresses . . . . . . . . . . . 62
	4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62		4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 65		5. Security Considerations . . . . . . . . . . . . . . . . . . . 65
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 65		7.1. Normative References . . . . . . . . . . . . . . . . . . . 65
	7.2. Informative References . . . . . . . . . . . . . . . . . . 67		7.2. Informative References . . . . . . . . . . . . . . . . . . 67
	Appendix A. Changes from previous versions of the draft . . . . . 75		Appendix A. Changes from previous versions of the draft . . . . . 75
	A.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76		A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 75
	A.2. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76		A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 76
	A.3. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76		A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76
	A.4. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76		A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76
	A.5. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76		A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76
	A.6. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76		A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76
	A.7. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 76		A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76
			A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 76
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77
	1. Preface		1. Preface
	1.1. Introduction		1.1. Introduction
	The TCP/IP protocols were conceived in an environment that was quite		The TCP/IP protocols were conceived in an environment that was quite
	different from the hostile environment in which they currently		different from the hostile environment in which they currently
	operate. However, the effectiveness of the protocols led to their		operate. However, the effectiveness of the protocols led to their
	early adoption in production environments, to the point that, to some		early adoption in production environments, to the point that, to some
	skipping to change at page 5, line 31		skipping to change at page 5, line 31
	While the Internet technology evolved since its inception, the		While the Internet technology evolved since its inception, the
	Internet's building blocks are basically the same core protocols		Internet's building blocks are basically the same core protocols
	adopted by the ARPANET more than two decades ago. During the last		adopted by the ARPANET more than two decades ago. During the last
	twenty years, many vulnerabilities have been identified in the TCP/IP		twenty years, many vulnerabilities have been identified in the TCP/IP
	stacks of a number of systems. Some of them were based on flaws in		stacks of a number of systems. Some of them were based on flaws in
	some protocol implementations, affecting only a reduced number of		some protocol implementations, affecting only a reduced number of
	systems, while others were based on flaws in the protocols		systems, while others were based on flaws in the protocols
	themselves, affecting virtually every existing implementation		themselves, affecting virtually every existing implementation
	[Bellovin1989]. Even in the last couple of years, researchers were		[Bellovin1989]. Even in the last couple of years, researchers were
	still working on security problems in the core protocols		still working on security problems in the core protocols [RFC5927]
	[I-D.ietf-tcpm-icmp-attacks] [Watson2004] [NISCC2004] [NISCC2005].		[Watson2004] [NISCC2004] [NISCC2005].
	The discovery of vulnerabilities in the TCP/IP protocols led to		The discovery of vulnerabilities in the TCP/IP protocols led to
	reports being published by a number of CSIRTs (Computer Security		reports being published by a number of CSIRTs (Computer Security
	Incident Response Teams) and vendors, which helped to raise awareness		Incident Response Teams) and vendors, which helped to raise awareness
	about the threats and the best mitigations known at the time the		about the threats and the best mitigations known at the time the
	reports were published. Unfortunately, this also led to the		reports were published. Unfortunately, this also led to the
	documentation of the discovered protocol vulnerabilities being spread		documentation of the discovered protocol vulnerabilities being spread
	among a large number of documents, which are sometimes difficult to		among a large number of documents, which are sometimes difficult to
	identify.		identify.
	skipping to change at page 6, line 32		skipping to change at page 6, line 32
	specifications of the Internet Protocol version 4 (IPv4), from a		specifications of the Internet Protocol version 4 (IPv4), from a
	security point of view. Possible threats were identified and, where		security point of view. Possible threats were identified and, where
	possible, countermeasures were proposed. Additionally, many		possible, countermeasures were proposed. Additionally, many
	implementation flaws that have led to security vulnerabilities have		implementation flaws that have led to security vulnerabilities have
	been referenced in the hope that future implementations will not		been referenced in the hope that future implementations will not
	incur the same problems. Furthermore, this document does not limit		incur the same problems. Furthermore, this document does not limit
	itself to performing a security assessment of the relevant IETF		itself to performing a security assessment of the relevant IETF
	specifications, but also provides an assessment of common		specifications, but also provides an assessment of common
	implementation strategies found in the real world.		implementation strategies found in the real world.
			Many IP implementations have also been subject of the so-called
			"packet-of-death" vulnerabilities, in which a single specially-
			crafted packet causes the IP implementation to crash or otherwise
			misbehave. In most cases, the attack packet is simply malformed; in
			other cases, the attack packet is well-formed, but exercises a little
			used path through the IP stack. Well-designed IP implementations
			should protect against these attacks, and therefore this document
			describes a number of sanity checks that are expected to prevent most
			of the aforementioned "packet-of-death" attack vectors. We note that
			if an IP implementation is is found vulnerable to one of these
			attacks, administrators must resort to mitigating them by packet
			filtering.
	This document does not aim to be the final word on the security of		This document does not aim to be the final word on the security of
	the Internet Protocol (IP). On the contrary, it aims to raise		the Internet Protocol (IP). On the contrary, it aims to raise
	awareness about many security threats based on the IP protocol that		awareness about many security threats based on the IP protocol that
	have been faced in the past, those that we are currently facing, and		have been faced in the past, those that we are currently facing, and
	those we may still have to deal with in the future. It provides		those we may still have to deal with in the future. It provides
	advice for the secure implementation of the Internet Protocol (IP),		advice for the secure implementation of the Internet Protocol (IP),
	but also provides insights about the security aspects of the Internet		but also provides insights about the security aspects of the Internet
	Protocol that may be of help to the Internet operations community.		Protocol that may be of help to the Internet operations community.
	Feedback from the community is more than encouraged to help this		Feedback from the community is more than encouraged to help this
	skipping to change at page 27, line 29		skipping to change at page 27, line 29
	As all packets sent by systems that are not in the same network		As all packets sent by systems that are not in the same network
	segment will have a TTL smaller than 255, those packets will not pass		segment will have a TTL smaller than 255, those packets will not pass
	the check enforced by these two cooperating peers. This check		the check enforced by these two cooperating peers. This check
	reduces the set of systems that may perform attacks against the		reduces the set of systems that may perform attacks against the
	protected application (BGP in this case), thus mitigating the attack		protected application (BGP in this case), thus mitigating the attack
	vectors described in [NISCC2004] and [Watson2004].		vectors described in [NISCC2004] and [Watson2004].
	This same check is enforced for related ICMP error messages, with		This same check is enforced for related ICMP error messages, with
	the intent of mitigating the attack vectors described in		the intent of mitigating the attack vectors described in
	[NISCC2005] and [I-D.ietf-tcpm-icmp-attacks].		[NISCC2005] and [RFC5927].
	The TTL field can be used in a similar way in scenarios in which the		The TTL field can be used in a similar way in scenarios in which the
	cooperating systems are not in the same network segment (i.e., multi-		cooperating systems are not in the same network segment (i.e., multi-
	hop peering). In that case, the following check could be enforced:		hop peering). In that case, the following check could be enforced:
	TTL >= 255 - DeltaHops		TTL >= 255 - DeltaHops
	This means that the set of hosts from which packets will be accepted		This means that the set of hosts from which packets will be accepted
	for the protected application will be reduced to those that are no		for the protected application will be reduced to those that are no
	more than DeltaHops away. While for obvious reasons the level of		more than DeltaHops away. While for obvious reasons the level of
	skipping to change at page 29, line 31		skipping to change at page 29, line 31
	on ingress and egress filtering. [RFC2827] and [RFC3704] discuss		on ingress and egress filtering. [RFC2827] and [RFC3704] discuss
	ingress filtering. [GIAC2000] discusses egress filtering.		ingress filtering. [GIAC2000] discusses egress filtering.
	[SpooferProject] measures the Internet's susceptibility to forged		[SpooferProject] measures the Internet's susceptibility to forged
	Source Address IP packets.		Source Address IP packets.
	Even when the obvious field on which to perform checks for		Even when the obvious field on which to perform checks for
	ingress/egress filtering is the Source Address and Destination		ingress/egress filtering is the Source Address and Destination
	Address fields of the IP header, there are other occurrences of IP		Address fields of the IP header, there are other occurrences of IP
	addresses on which the same type of checks should be performed.		addresses on which the same type of checks should be performed.
	One example is the IP addresses contained in the payload of ICMP		One example is the IP addresses contained in the payload of ICMP
	error messages, as discussed in [I-D.ietf-tcpm-icmp-attacks] and		error messages, as discussed in [RFC5927] and [Gont2006].
	[Gont2006].
	There are a number of sanity checks that should be performed on the		There are a number of sanity checks that should be performed on the
	Source Address of an IP datagram. Details can be found in Section		Source Address of an IP datagram. Details can be found in Section
	4.2 ("Addressing").		4.2 ("Addressing").
	Additionally, there exist freely available tools that allow		Additionally, there exist freely available tools that allow
	administrators to monitor which IP addresses are used with which MAC		administrators to monitor which IP addresses are used with which MAC
	addresses [LBNL2006]. This functionality is also included in many		addresses [LBNL2006]. This functionality is also included in many
	Network Intrusion Detection Systems (NIDS).		Network Intrusion Detection Systems (NIDS).
	skipping to change at page 65, line 18		skipping to change at page 65, line 18
	Protocol (IP) and a number of implementation strategies that help to		Protocol (IP) and a number of implementation strategies that help to
	mitigate a number of vulnerabilities found in the protocol during the		mitigate a number of vulnerabilities found in the protocol during the
	last 25 years or so.		last 25 years or so.
	6. Acknowledgements		6. Acknowledgements
	The author wishes to thank Alfred Hoenes for providing very thorough		The author wishes to thank Alfred Hoenes for providing very thorough
	reviews of earlier versions of this document, thus leading to		reviews of earlier versions of this document, thus leading to
	numerous improvements.		numerous improvements.
	The author would like to thank Jari Arkko, Stewart Bryant, Adrian		The author would like to thank Jari Arkko, Ron Bonica, Stewart
	Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and Andrew		Bryant, Adrian Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and
	Yourtchenko for providing valuable comments on earlier versions of		Andrew Yourtchenko for providing valuable comments on earlier
	this document.		versions of this document.
	This document was written by Fernando Gont on behalf of the UK CPNI		This document was written by Fernando Gont on behalf of the UK CPNI
	(United Kingdom's Centre for the Protection of National		(United Kingdom's Centre for the Protection of National
	Infrastructure), and is heavily based on the "Security Assessment of		Infrastructure), and is heavily based on the "Security Assessment of
	the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008.		the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008.
	The author would like to thank Randall Atkinson, John Day, Juan		The author would like to thank Randall Atkinson, John Day, Juan
	Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka		Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka
	Savola, and Christos Zoulas for providing valuable comments on		Savola, and Christos Zoulas for providing valuable comments on
	earlier versions of [CPNI2008], on which this document is based.		earlier versions of [CPNI2008], on which this document is based.
	skipping to change at page 69, line 41		skipping to change at page 69, line 41
	Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work		Internet-Draft (draft-ietf-cipso-ipsecurity-01.txt), work
	in progress , 1992.		in progress , 1992.
	[CIPSOWG1994]		[CIPSOWG1994]
	CIPSOWG, "Commercial Internet Protocol Security Option		CIPSOWG, "Commercial Internet Protocol Security Option
	(CIPSO) Working Group", http://www.ietf.org/proceedings/		(CIPSO) Working Group", http://www.ietf.org/proceedings/
	94jul/charters/cipso-charter.html, 1994.		94jul/charters/cipso-charter.html, 1994.
	[CPNI2008]		[CPNI2008]
	Gont, F., "Security Assessment of the Internet Protocol",		Gont, F., "Security Assessment of the Internet Protocol",
	http://www.cpni.gov.uk/Docs/InternetProtocol.pdf, 2008.		2008, <http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>.
	[Cerf1974]		[Cerf1974]
	Cerf, V. and R. Kahn, "A Protocol for Packet Network		Cerf, V. and R. Kahn, "A Protocol for Packet Network
	Intercommunication", IEEE Transactions on		Intercommunication", IEEE Transactions on
	Communications Vol. 22, No. 5, May 1974, pp. 637-648,		Communications Vol. 22, No. 5, May 1974, pp. 637-648,
	1974.		1974.
	[Cisco2003]		[Cisco2003]
	Cisco, "Cisco Security Advisory: Cisco IOS Interface		Cisco, "Cisco Security Advisory: Cisco IOS Interface
	Blocked by IPv4 packet", http://www.cisco.com/en/US/		Blocked by IPv4 packet", http://www.cisco.com/en/US/
	skipping to change at page 71, line 7		skipping to change at page 71, line 7
	[Humble1998]		[Humble1998]
	Humble, "Nestea exploit",		Humble, "Nestea exploit",
	http://www.insecure.org/sploits/linux.PalmOS.nestea.html,		http://www.insecure.org/sploits/linux.PalmOS.nestea.html,
	1998.		1998.
	[I-D.ietf-intarea-router-alert-considerations]		[I-D.ietf-intarea-router-alert-considerations]
	Faucheur, F., "IP Router Alert Considerations and Usage",		Faucheur, F., "IP Router Alert Considerations and Usage",
	draft-ietf-intarea-router-alert-considerations-02 (work in		draft-ietf-intarea-router-alert-considerations-02 (work in
	progress), October 2010.		progress), October 2010.
	[I-D.ietf-tcpm-icmp-attacks]
	Gont, F., "ICMP attacks against TCP",
	draft-ietf-tcpm-icmp-attacks-12 (work in progress),
	March 2010.
	[I-D.templin-mtuassurance]		[I-D.templin-mtuassurance]
	Templin, F., "Requirements for IP-in-IP Tunnel MTU		Templin, F., "Requirements for IP-in-IP Tunnel MTU
	Assurance", draft-templin-mtuassurance-02 (work in		Assurance", draft-templin-mtuassurance-02 (work in
	progress), October 2006.		progress), October 2006.
	[IANA2006a]		[IANA2006a]
	Ether Types,		Ether Types,
	"http://www.iana.org/assignments/ethernet-numbers".		"http://www.iana.org/assignments/ethernet-numbers".
	[IANA2006b]		[IANA2006b]
	skipping to change at page 74, line 20		skipping to change at page 74, line 16
	Architecture Label IPv6 Security Option (CALIPSO)",		Architecture Label IPv6 Security Option (CALIPSO)",
	RFC 5570, July 2009.		RFC 5570, July 2009.
	[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-		[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
	Nodes", RFC 5670, November 2009.		Nodes", RFC 5670, November 2009.
	[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline		[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
	Encoding and Transport of Pre-Congestion Information",		Encoding and Transport of Pre-Congestion Information",
	RFC 5696, November 2009.		RFC 5696, November 2009.
			[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
	[SELinux2008]		[SELinux2008]
	Security Enhanced Linux, "http://www.nsa.gov/selinux/".		Security Enhanced Linux, "http://www.nsa.gov/selinux/".
	[Sanfilippo1998a]		[Sanfilippo1998a]
	Sanfilippo, S., "about the ip header id", Post to Bugtraq		Sanfilippo, S., "about the ip header id", Post to Bugtraq
	mailing-list, Mon Dec 14		mailing-list, Mon Dec 14
	1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998.		1998 http://www.kyuzz.org/antirez/papers/ipid.html, 1998.
	[Sanfilippo1998b]		[Sanfilippo1998b]
	Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-		Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-
	skipping to change at page 76, line 5		skipping to change at page 75, line 47
	daemon9, route, and infinity, "IP-spoofing Demystified		daemon9, route, and infinity, "IP-spoofing Demystified
	(Trust-Relationship Exploitation)", Phrack Magazine,		(Trust-Relationship Exploitation)", Phrack Magazine,
	Volume Seven, Issue Forty-Eight, File 14 of 18 http://		Volume Seven, Issue Forty-Eight, File 14 of 18 http://
	www.phrack.org/issues.html?issue=48&id=14&mode=txt, 1988.		www.phrack.org/issues.html?issue=48&id=14&mode=txt, 1988.
	Appendix A. Changes from previous versions of the draft		Appendix A. Changes from previous versions of the draft
	This whole appendix should be removed by the RFC Editor before		This whole appendix should be removed by the RFC Editor before
	publishing this document as an RFC.		publishing this document as an RFC.
	A.1. Changes from draft-ietf-opsec-ip-security-03		A.1. Changes from draft-ietf-opsec-ip-security-05
			o Addresses IESG review comments by Tim Polk (?).
			A.2. Changes from draft-ietf-opsec-ip-security-04
	o Addresses IESG review comments by Jari Arkko, Stewart Bryant,		o Addresses IESG review comments by Jari Arkko, Stewart Bryant,
	Adrian Farrel, Peter Saint-Andre, and Sean Turner.		Adrian Farrel, Peter Saint-Andre, and Sean Turner.
	A.2. Changes from draft-ietf-opsec-ip-security-03		A.3. Changes from draft-ietf-opsec-ip-security-03
	o Addresses feedback received off-list by Warren Kumari.		o Addresses feedback received off-list by Warren Kumari.
	A.3. Changes from draft-ietf-opsec-ip-security-02		A.4. Changes from draft-ietf-opsec-ip-security-02
	o Addresses a very thorough review by Alfred Hoenes (sent off-list)		o Addresses a very thorough review by Alfred Hoenes (sent off-list)
	o Miscellaneous edits (centers expressions, fills missing graphics		o Miscellaneous edits (centers expressions, fills missing graphics
	with ASCII-art, etc.)		with ASCII-art, etc.)
	A.4. Changes from draft-ietf-opsec-ip-security-01		A.5. Changes from draft-ietf-opsec-ip-security-01
	o Addresses rest of the feedback received from Andrew Yourtchenko		o Addresses rest of the feedback received from Andrew Yourtchenko
	(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)		(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)
	o Addresses a very thorough review by Alfred Hoenes (sent off-list)		o Addresses a very thorough review by Alfred Hoenes (sent off-list)
	o Addresses feedback submitted by Joel Jaeggli (off-list)		o Addresses feedback submitted by Joel Jaeggli (off-list)
	o Addresses feedback submitted (off-list) by Bruno Rohee.		o Addresses feedback submitted (off-list) by Bruno Rohee.
	o Miscellaneous edits (centers expressions, fills missing graphics		o Miscellaneous edits (centers expressions, fills missing graphics
	with ASCII-art, etc.)		with ASCII-art, etc.)
	A.5. Changes from draft-ietf-opsec-ip-security-00		A.6. Changes from draft-ietf-opsec-ip-security-00
	o Addresses part of the feedback received from Andrew Yourtchenko		o Addresses part of the feedback received from Andrew Yourtchenko
	(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)		(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)
	A.6. Changes from draft-gont-opsec-ip-security-01		A.7. Changes from draft-gont-opsec-ip-security-01
	o Draft resubmitted as draft-ietf, as a result of wg consensus on		o Draft resubmitted as draft-ietf, as a result of wg consensus on
	adopting the document as an opsec wg item.		adopting the document as an opsec wg item.
	A.7. Changes from draft-gont-opsec-ip-security-00		A.8. Changes from draft-gont-opsec-ip-security-00
	o Fixed author's affiliation.		o Fixed author's affiliation.
	o Added Figure 6.		o Added Figure 6.
	o Fixed a few typos.		o Fixed a few typos.
	o (no technical changes)		o (no technical changes)
	Author's Address		Author's Address
End of changes. 22 change blocks.
	35 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/