draft-ietf-opsec-ip-security-04.txt		draft-ietf-opsec-ip-security-05.txt
	Operational Security Capabilities F. Gont		Operational Security Capabilities F. Gont
	for IP Network Infrastructure UK CPNI		for IP Network Infrastructure UK CPNI
	(opsec) October 21, 2010		(opsec) December 16, 2010
	Internet-Draft		Internet-Draft
	Intended status: Informational		Intended status: Informational
	Expires: April 24, 2011		Expires: June 19, 2011
	Security Assessment of the Internet Protocol version 4		Security Assessment of the Internet Protocol version 4
	draft-ietf-opsec-ip-security-04.txt		draft-ietf-opsec-ip-security-05.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 April 24, 2011.		This Internet-Draft will expire on June 19, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 23		skipping to change at page 2, line 23
	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
	3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 15		3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 16
	3.5.1. Some Workarounds Implemented by the Industry . . . . . 16		3.5.1. Some Workarounds Implemented by the Industry . . . . . 16
	3.5.2. Possible security improvements . . . . . . . . . . . . 17		3.5.2. Possible security improvements . . . . . . . . . . . . 17
	3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17		3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17
	3.5.2.2. Connectionless Transport Protocols . . . . . . . 18		3.5.2.2. Connectionless Transport Protocols . . . . . . . 18
	3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19		3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 21		3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 21
	3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 22		3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 22
	3.8.1. Fingerprinting the operating system in use by the		3.8.1. Fingerprinting the operating system in use by the
	source host . . . . . . . . . . . . . . . . . . . . . 24		source host . . . . . . . . . . . . . . . . . . . . . 24
	3.8.2. Fingerprinting the physical device from which the		3.8.2. Fingerprinting the physical device from which the
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 28		3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 28
	3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 28		3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 28
	3.12. Destination Address . . . . . . . . . . . . . . . . . . . 29		3.12. Destination Address . . . . . . . . . . . . . . . . . . . 29
	3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 30		3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 30
	3.13.1. General issues with IP options . . . . . . . . . . . . 31		3.13.1. General issues with IP options . . . . . . . . . . . . 31
	3.13.1.1. Processing requirements . . . . . . . . . . . . . 31		3.13.1.1. Processing requirements . . . . . . . . . . . . . 31
	3.13.1.2. Processing of the options by the upper layer		3.13.1.2. Processing of the options by the upper layer
	protocol . . . . . . . . . . . . . . . . . . . . 32		protocol . . . . . . . . . . . . . . . . . . . . 32
	3.13.1.3. General sanity checks on IP options . . . . . . . 32		3.13.1.3. General sanity checks on IP options . . . . . . . 32
	3.13.2. Issues with specific options . . . . . . . . . . . . . 33		3.13.2. Issues with specific options . . . . . . . . . . . . . 34
	3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 34		3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 34
	3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 34		3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 34
	3.13.2.3. Loose Source and Record Route (LSRR)		3.13.2.3. Loose Source and Record Route (LSRR)
	(Type=131) . . . . . . . . . . . . . . . . . . . 34		(Type=131) . . . . . . . . . . . . . . . . . . . 34
	3.13.2.4. Strict Source and Record Route (SSRR)		3.13.2.4. Strict Source and Record Route (SSRR)
	(Type=137) . . . . . . . . . . . . . . . . . . . 37		(Type=137) . . . . . . . . . . . . . . . . . . . 37
	3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 39		3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 39
	3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 40		3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 40
	3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 40		3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 40
	3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 43		3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 43
	skipping to change at page 4, line 15		skipping to change at page 4, line 15
	4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 62		4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 62
	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. Advice and guidance to vendors . . . . . . . . . . . 76		Appendix A. Changes from previous versions of the draft . . . . . 75
	Appendix B. Changes from previous versions of the draft . . . . . 76		A.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76
	B.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76		A.2. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76
	B.2. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76		A.3. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76
	B.3. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76		A.4. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76
	B.4. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77		A.5. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76
	B.5. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77		A.6. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76
	B.6. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77		A.7. 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 6, line 22		skipping to change at page 6, line 22
	between that which provides correct advisory, and that which provides		between that which provides correct advisory, and that which provides
	misleading advisory based on inaccurate or wrong assumptions.		misleading advisory based on inaccurate or wrong assumptions.
	There is a clear need for a companion document to the IETF		There is a clear need for a companion document to the IETF
	specifications that discusses the security aspects and implications		specifications that discusses the security aspects and implications
	of the protocols, identifies the possible threats, discusses the		of the protocols, identifies the possible threats, discusses the
	possible countermeasures, and analyzes their respective		possible countermeasures, and analyzes their respective
	effectiveness.		effectiveness.
	This document is the result of an assessment of the IETF		This document is the result of an assessment of the IETF
	specifications of the Internet Protocol (IP), from a security point		specifications of the Internet Protocol version 4 (IPv4), from a
	of view. Possible threats were identified and, where possible,		security point of view. Possible threats were identified and, where
	countermeasures were proposed. Additionally, many implementation		possible, countermeasures were proposed. Additionally, many
	flaws that have led to security vulnerabilities have been referenced		implementation flaws that have led to security vulnerabilities have
	in the hope that future implementations will not incur the same		been referenced in the hope that future implementations will not
	problems. Furthermore, this document does not limit itself to		incur the same problems. Furthermore, this document does not limit
	performing a security assessment of the relevant IETF specifications,		itself to performing a security assessment of the relevant IETF
	but also provides an assessment of common implementation strategies		specifications, but also provides an assessment of common
	found in the real world.		implementation strategies found in the real world.
	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.
	skipping to change at page 8, line 32		skipping to change at page 8, line 32
	a building block for other transport services (reliable data		a building block for other transport services (reliable data
	transport services, etc.).		transport services, etc.).
	o It represents the minimum network service assumption, which		o It represents the minimum network service assumption, which
	enables IP to be run over virtually any network technology.		enables IP to be run over virtually any network technology.
	3. Internet Protocol Header Fields		3. Internet Protocol Header Fields
	The IETF specifications of the Internet Protocol define the syntax of		The IETF specifications of the Internet Protocol define the syntax of
	the protocol header, along with the semantics of each of its fields.		the protocol header, along with the semantics of each of its fields.
	Figure 1 shows the format of an IP datagram.		Figure 1 shows the format of an IP datagram, as specified in
			[RFC0791].
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Version| IHL |Type of Service| Total Length |		|Version| IHL |Type of Service| Total Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identification |Flags| Fragment Offset |		| Identification |Flags| Fragment Offset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Time to Live | Protocol | Header Checksum |		| Time to Live | Protocol | Header Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 14, line 7		skipping to change at page 14, line 7
	ECN is an end-to-end transport protocol mechanism based on		ECN is an end-to-end transport protocol mechanism based on
	notifications by routers through which a packet flow passes. To		notifications by routers through which a packet flow passes. To
	allow this interaction to happen on the fast path of routers, the ECN		allow this interaction to happen on the fast path of routers, the ECN
	field is located at a fixed location in the IP header. However, its		field is located at a fixed location in the IP header. However, its
	use must be negotiated at the transport layer, and the accumulated		use must be negotiated at the transport layer, and the accumulated
	congestion notifications must be communicated back to the sending		congestion notifications must be communicated back to the sending
	node using transport protocol means. Thus, ECN support must be		node using transport protocol means. Thus, ECN support must be
	specified per transport protocol.		specified per transport protocol.
			[RFC6040] specifies how the explicit congestion notification (ECN)
			field of the IP header should be constructed on entry to and exit
			from any IP-in-IP tunnel.
	The security implications of ECN are discussed in detail in a number		The security implications of ECN are discussed in detail in a number
	of Sections of RFC 3168. Of the possible threats discussed in the		of Sections of RFC 3168. Of the possible threats discussed in the
	ECN specification, we believe that one that can be easily exploited		ECN specification, we believe that one that can be easily exploited
	is that of a host falsely indicating ECN-Capability.		is that of a host falsely indicating ECN-Capability.
	An attacker could set the ECT codepoint in the packets it sends, to		An attacker could set the ECT codepoint in the packets it sends, to
	signal the network that the endpoints of the transport protocol are		signal the network that the endpoints of the transport protocol are
	ECN-capable. Consequently, when experiencing moderate congestion,		ECN-capable. Consequently, when experiencing moderate congestion,
	routers using active queue management based on RED would mark the		routers using active queue management based on RED would mark the
	packets (with the CE codepoint) rather than discard them. In this		packets (with the CE codepoint) rather than discard them. In this
	skipping to change at page 17, line 26		skipping to change at page 17, line 29
	services of IP is connection-oriented or connection-less.		services of IP is connection-oriented or connection-less.
	3.5.2.1. Connection-Oriented Transport Protocols		3.5.2.1. Connection-Oriented Transport Protocols
	To avoid the security implications of the information leakage		To avoid the security implications of the information leakage
	described above, a pseudo-random number generator (PRNG) could be		described above, a pseudo-random number generator (PRNG) could be
	used to set the IP Identification field on a {Source Address,		used to set the IP Identification field on a {Source Address,
	Destination Address} basis (for each connection-oriented transport		Destination Address} basis (for each connection-oriented transport
	protocol).		protocol).
			[RFC4086] provides advice on the generation of pseudo-random
			numbers.
	[Klein2007] is a security advisory that describes a weakness in		[Klein2007] is a security advisory that describes a weakness in
	the pseudo random number generator (PRNG) in use for the		the pseudo random number generator (PRNG) in use for the
	generation of the IP Identification by a number of operating		generation of the IP Identification by a number of operating
	systems.		systems.
	While in theory a pseudo-random number generator could lead to		While in theory a pseudo-random number generator could lead to
	scenarios in which a given Identification number is used more than		scenarios in which a given Identification number is used more than
	once in the same time-span for datagrams that end up getting		once in the same time-span for datagrams that end up getting
	fragmented (with the corresponding potential reassembly problems), in		fragmented (with the corresponding potential reassembly problems), in
	practice this is unlikely to cause trouble.		practice this is unlikely to cause trouble.
	skipping to change at page 18, line 31		skipping to change at page 18, line 38
	o Applications will be used in environments in which packet		o Applications will be used in environments in which packet
	reordering is very unlikely (such as Local Area Networks), as the		reordering is very unlikely (such as Local Area Networks), as the
	transport protocol itself does not provide data sequencing.		transport protocol itself does not provide data sequencing.
	o The data transfer rates will be low enough that flow control will		o The data transfer rates will be low enough that flow control will
	be unnecessary.		be unnecessary.
	o Packet loss is can be tolerated and/or is unlikely.		o Packet loss is can be tolerated and/or is unlikely.
	With these assumptions in mind, the Identification field could still		With these assumptions in mind, the Identification field could still
	be set according to a pseudo-random number generator (PRNG). In the		be set according to a pseudo-random number generator (PRNG).
	event a given Identification number was reused while the first
			[RFC4086] provides advice on the generation of pseudo-random
			numbers.
			In the event a given Identification number was reused while the first
	instance of the same number is still on the network, the first IP		instance of the same number is still on the network, the first IP
	datagram would be reassembled before the fragments of the second IP		datagram would be reassembled before the fragments of the second IP
	datagram get to their destination.		datagram get to their destination.
	In the event this was not the case, the reassembly of fragments would		In the event this was not the case, the reassembly of fragments would
	result in a corrupt datagram. While some existing work		result in a corrupt datagram. While some existing work
	[Silbersack2005] assumes that this error would be caught by some		[Silbersack2005] assumes that this error would be caught by some
	upper-layer error detection code, the error detection code in		upper-layer error detection code, the error detection code in
	question (such as UDP's checksum) might not be able to reliably		question (such as UDP's checksum) might not be able to reliably
	detect data corruption arising from the replacement of a complete		detect data corruption arising from the replacement of a complete
	skipping to change at page 19, line 36		skipping to change at page 19, line 47
	standardization)		standardization)
	o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment		o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment
	o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments		o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments
	The DF bit is usually set to implement the Path-MTU Discovery (PMTUD)		The DF bit is usually set to implement the Path-MTU Discovery (PMTUD)
	mechanism described in [RFC1191]. However, it can also be exploited		mechanism described in [RFC1191]. However, it can also be exploited
	by an attacker to evade Network Intrusion Detection Systems. An		by an attacker to evade Network Intrusion Detection Systems. An
	attacker could send a packet with the DF bit set to a system		attacker could send a packet with the DF bit set to a system
	monitored by a NIDS, and depending on the Path-MTU to the intended		monitored by a Network Intrusion Detection System (NIDS), and
	recipient, the packet might be dropped by some intervening router		depending on the Path-MTU to the intended recipient, the packet might
	(because of being too big to be forwarded without fragmentation),		be dropped by some intervening router (because of being too big to be
	without the NIDS being aware of it.		forwarded without fragmentation), without the NIDS being aware of it.
	+---+		+---+
	| H |		| H |
	+---+ Victim host		+---+ Victim host
	|		|
	Router A | MTU=1500		Router A | MTU=1500
	|		|
	+---+ +---+ +---+		+---+ +---+ +---+
	| R |-----| R |---------| R |		| R |-----| R |---------| R |
	+---+ +---+ +---+		+---+ +---+ +---+
	skipping to change at page 20, line 31		skipping to change at page 20, line 31
	_ ___/---\______ Attacker		_ ___/---\______ Attacker
	/ \_/ \_ +---+		/ \_/ \_ +---+
	/ Internet |---------| H |		/ Internet |---------| H |
	\_ __/ +---+		\_ __/ +---+
	\__ __ ___/ <------		\__ __ ___/ <------
	\___/ \__/ 17914-byte packet		\___/ \__/ 17914-byte packet
	DF bit set		DF bit set
	Figure 5: NIDS evasion by means of the Internet Protocol DF bit		Figure 5: NIDS evasion by means of the Internet Protocol DF bit
	In Figure 3, an attacker sends a 17914-byte datagram meant to the		In Figure 3, an attacker sends a 17914-byte datagram meant for the
	victim host in the same figure. The attacker's packet probably		victim host in the same figure. The attacker's packet probably
	contains an overlapping IP fragment or an overlapping TCP segment,		contains an overlapping IP fragment or an overlapping TCP segment,
	aiming at "confusing" the NIDS, as described in [Ptacek1998]. The		aiming at "confusing" the NIDS, as described in [Ptacek1998]. The
	packet is screened by the NIDS sensor at the network perimeter, which		packet is screened by the NIDS sensor at the network perimeter, which
	probably reassembles IP fragments and TCP segments for the purpose of		probably reassembles IP fragments and TCP segments for the purpose of
	assessing the data transferred to and from the monitored systems.		assessing the data transferred to and from the monitored systems.
	However, as the attacker's packet should transit a link with an MTU		However, as the attacker's packet should transit a link with an MTU
	smaller than 17914 bytes (1500 bytes in this example), the router		smaller than 17914 bytes (1500 bytes in this example), the router
	that encounters that this packet cannot be forwarded without		that encounters that this packet cannot be forwarded without
	fragmentation (Router B) discards the packet, and sends an ICMP		fragmentation (Router B) discards the packet, and sends an ICMP
	skipping to change at page 24, line 10		skipping to change at page 24, line 10
	o Improving the security of applications that make use of the		o Improving the security of applications that make use of the
	Internet Protocol (IP).		Internet Protocol (IP).
	o Limiting spread of packets.		o Limiting spread of packets.
	3.8.1. Fingerprinting the operating system in use by the source host		3.8.1. Fingerprinting the operating system in use by the source host
	Different operating systems use a different default TTL for the		Different operating systems use a different default TTL for the
	packets they send. Thus, asserting the TTL with which a packet was		packets they send. Thus, asserting the TTL with which a packet was
	originally sent will help heuristics to reduce the number of possible		originally sent will help heuristics to reduce the number of possible
	operating systems in use by the source host.		operating systems in use by the source host. It should be noted that
			since most systems use only a handful of different default values,
	However, these defaults may be configurable (system-wide or per		the granularity of OS fingerprinting that this technique provides is
	protocol) and managed systems may employ such opportunities for		negligible. Additionally, these defaults may be configurable
	operational purposes and to defeat the capability of fingerprinting		(system-wide or per protocol), and managed systems may employ such
	heuristics.		opportunities for operational purposes and to defeat the capability
			of fingerprinting heuristics.
	3.8.2. Fingerprinting the physical device from which the packets		3.8.2. Fingerprinting the physical device from which the packets
	originate		originate
	When several systems are behind a middle-box such as a NAT or a load		When several systems are behind a middle-box such as a NAT or a load
	balancer, the TTL may help to count the number of systems behind the		balancer, the TTL may help to count the number of systems behind the
	middle-box. If each of the systems behind the middle-box uses a		middle-box. If each of the systems behind the middle-box uses a
	different default TTL value for the packets it sends, or each system		different default TTL value for the packets it sends, or each system
	is located at different distances in the network topology, an		is located at different distances in the network topology, an
	attacker could stimulate responses from the devices being		attacker could stimulate responses from the devices being
	skipping to change at page 30, line 27		skipping to change at page 30, line 27
	modules, both in hosts and gateways (i.e., end-systems and		modules, both in hosts and gateways (i.e., end-systems and
	intermediate-systems). This means that the general rules for		intermediate-systems). This means that the general rules for
	assembling, parsing, and processing of IP options must be		assembling, parsing, and processing of IP options must be
	implemented. RFC 791 defines a set of options that "must be		implemented. RFC 791 defines a set of options that "must be
	understood", but this set has been updated by RFC 1122 [RFC1122], RFC		understood", but this set has been updated by RFC 1122 [RFC1122], RFC
	1812 [RFC1812], and other documents. Section 3.13.2 of this document		1812 [RFC1812], and other documents. Section 3.13.2 of this document
	describes for each option type the current understanding of the		describes for each option type the current understanding of the
	implementation requirements. IP systems are required to ignore		implementation requirements. IP systems are required to ignore
	options they do not implement.		options they do not implement.
			It should be noted that while a number of IP options have been
			specified, they are generally only used for troubleshooting
			purposes (except for the Router Alert option and the different
			Security options).
	There are two cases for the format of an option:		There are two cases for the format of an option:
	o Case 1: A single byte of option-type.		o Case 1: A single byte of option-type.
	o Case 2: An option-type byte, an option-length byte, and the actual		o Case 2: An option-type byte, an option-length byte, and the actual
	option-data bytes.		option-data bytes.
	In Case 2, the option-length byte counts the option-type byte and the		In Case 2, the option-length byte counts the option-type byte and the
	option-length byte, as well as the actual option-data bytes.		option-length byte, as well as the actual option-data bytes.
	skipping to change at page 38, line 11		skipping to change at page 38, line 11
	provide a system-wide toggle to enable support for this option for		provide a system-wide toggle to enable support for this option for
	those scenarios in which this option is required. Such system-wide		those scenarios in which this option is required. Such system-wide
	toggle should default to "off" (or "disable").		toggle should default to "off" (or "disable").
	[OpenBSD1998] is a security advisory about an improper		[OpenBSD1998] is a security advisory about an improper
	implementation of such a system-wide toggle in 4.4BSD kernels.		implementation of such a system-wide toggle in 4.4BSD kernels.
	In the event processing of the SSRR option were explicitly enabled,		In the event processing of the SSRR option were explicitly enabled,
	the same sanity checks described for the LSRR option in		the same sanity checks described for the LSRR option in
	Section 3.13.2.3 should be performed on the SSRR option. Namely,		Section 3.13.2.3 should be performed on the SSRR option. Namely,
	sanity checks shoudl be performed on the option length (SSRR.Length)		sanity checks should be performed on the option length (SSRR.Length)
	and the pointer field (SSRR.Pointer).		and the pointer field (SSRR.Pointer).
	If the packet passes the aforementioned sanity checks, the receiving		If the packet passes the aforementioned sanity checks, the receiving
	system should determine whether the Destination Address of the packet		system should determine whether the Destination Address of the packet
	corresponds to one of its IP addresses. If does not, it should be		corresponds to one of its IP addresses. If does not, it should be
	dropped, and this event should be logged (e.g., a counter could be		dropped, and this event should be logged (e.g., a counter could be
	incremented to reflect the packet drop).		incremented to reflect the packet drop).
	Contrary to the IP Loose Source and Record Route (LSRR) option,		Contrary to the IP Loose Source and Record Route (LSRR) option,
	the SSRR option does not allow in the route other routers than		the SSRR option does not allow in the route other routers than
	skipping to change at page 44, line 10		skipping to change at page 44, line 10
	reflect the packet drop).		reflect the packet drop).
	A packet that contains a Router Alert option with an option value		A packet that contains a Router Alert option with an option value
	corresponding to functionality supported by an active module in the		corresponding to functionality supported by an active module in the
	router will not go through the router's fast-path but will be		router will not go through the router's fast-path but will be
	processed in the slow path of the router, handing it over for closer		processed in the slow path of the router, handing it over for closer
	inspection to the modules that has registered the matching option		inspection to the modules that has registered the matching option
	value. Therefore, this option may impact the performance of the		value. Therefore, this option may impact the performance of the
	systems that handle the packet carrying it.		systems that handle the packet carrying it.
			[I-D.ietf-intarea-router-alert-considerations] analyzes the
			security implications of the Router Alert option, and identifies
			controlled environments in which the Router Alert option can be
			used safely.
	As explained in RFC 2113 [RFC2113], hosts should ignore this option.		As explained in RFC 2113 [RFC2113], hosts should ignore this option.
	3.13.2.9. Probe MTU (Type=11) (obsolete)		3.13.2.9. Probe MTU (Type=11) (obsolete)
	This option was defined in RFC 1063 [RFC1063], and originally		This option was defined in RFC 1063 [RFC1063], and originally
	provided a mechanism to discover the Path-MTU.		provided a mechanism to discover the Path-MTU.
	This option is obsolete, and therefore any packet that is received		This option is obsolete, and therefore any packet that is received
	containing this option should be dropped, and this event should be		containing this option should be dropped, and this event should be
	logged (e.g., a counter could be incremented to reflect the packet		logged (e.g., a counter could be incremented to reflect the packet
	skipping to change at page 55, line 21		skipping to change at page 55, line 21
	create some free space in the fragment buffer, on the premise that		create some free space in the fragment buffer, on the premise that
	this will allow for new and legitimate fragments to be processed by		this will allow for new and legitimate fragments to be processed by
	the IP module, thus letting communication survive the overwhelming		the IP module, thus letting communication survive the overwhelming
	situation. On the other hand, the idea of flushing a somewhat large		situation. On the other hand, the idea of flushing a somewhat large
	portion of the buffer is to avoid flushing always the same set of		portion of the buffer is to avoid flushing always the same set of
	packets.		packets.
	4.1.2.3. A more selective fragment buffer flushing strategy		4.1.2.3. A more selective fragment buffer flushing strategy
	One of the difficulties in implementing countermeasures for the		One of the difficulties in implementing countermeasures for the
	fragmentation attacks described in throughout Section 4.1 is that it		fragmentation attacks described throughout Section 4.1 is that it is
	is difficult to perform validation checks on the received fragments.		difficult to perform validation checks on the received fragments.
	For instance, the fragment on which validity checks could be		For instance, the fragment on which validity checks could be
	performed, the first fragment, may be not the first fragment to		performed, the first fragment, may be not the first fragment to
	arrive at the destination host.		arrive at the destination host.
	Fragments can not only arrive out of order because of packet		Fragments can not only arrive out of order because of packet
	reordering performed by the network, but also because the system (or		reordering performed by the network, but also because the system (or
	systems) that fragmented the IP datagram may indeed transmit the		systems) that fragmented the IP datagram may indeed transmit the
	fragments out of order. A notable example of this is the Linux		fragments out of order. A notable example of this is the Linux
	TCP/IP stack, which transmits the fragments in reverse order.		TCP/IP stack, which transmits the fragments in reverse order.
	skipping to change at page 62, line 8		skipping to change at page 62, line 8
	dropped, and this event should be logged (e.g., a counter could be		dropped, and this event should be logged (e.g., a counter could be
	incremented to reflect the packet drop). Additionally, if an IP		incremented to reflect the packet drop). Additionally, if an IP
	packet with a multicast Destination Address is received for a		packet with a multicast Destination Address is received for a
	connection-oriented protocol (e.g., TCP), the packet should be		connection-oriented protocol (e.g., TCP), the packet should be
	dropped (see Section 4.3.5), and this event should be logged (e.g., a		dropped (see Section 4.3.5), and this event should be logged (e.g., a
	counter could be incremented to reflect the packet drop).		counter could be incremented to reflect the packet drop).
	4.3.4. Former Class E Addresses (240/4 Address Block)		4.3.4. Former Class E Addresses (240/4 Address Block)
	The former Class E addresses correspond to the 240/4 address block,		The former Class E addresses correspond to the 240/4 address block,
	and are currently reserved for experimental use. As a result, a		and are currently reserved for experimental use. As a result, a most
	number of implementations discard packets that contain a "Class" E		routers discard packets that contain a "Class" E address as the
	address as the Source Address or Destination Address.		Source Address or Destination Address. If a packet is received with
			a 240/4 address as the Source Address and/or the Destination Address,
	However, there exists ongoing work to reclassify the former Class E		the packet should be dropped and this event should be logged (e.g., a
	(240/4) address block as usable unicast address spaces [Fuller2008a]		counter could be incremented to reflect the packet drop).
	[I-D.fuller-240space] [I-D.wilson-class-e]. Therefore, we recommend
	implementations to accept addresses in the 240/4 block as valid
	addresses for the Source Address and Destination Address.
	It should be noted that the broadcast address 255.255.255.255 still		It should be noted that the broadcast address 255.255.255.255 still
	must be treated as indicated in Section 4.3.7 of this document.		must be treated as indicated in Section 4.3.7 of this document.
	4.3.5. Broadcast/Multicast addresses, and Connection-Oriented Protocols		4.3.5. Broadcast/Multicast addresses, and Connection-Oriented Protocols
	For connection-oriented protocols, such as TCP, shared state is		For connection-oriented protocols, such as TCP, shared state is
	maintained between only two endpoints at a time. Therefore, if an IP		maintained between only two endpoints at a time. Therefore, if an IP
	packet with a multicast (or broadcast) Destination Address is		packet with a multicast (or broadcast) Destination Address is
	received for a connection-oriented protocol (e.g., TCP), the packet		received for a connection-oriented protocol (e.g., TCP), the packet
	skipping to change at page 65, line 20		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 Joel Jaeggli, Warren Kumari, Bruno		The author would like to thank Jari Arkko, Stewart Bryant, Adrian
	Rohee, and Andrew Yourtchenko for providing valuable comments on		Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and Andrew
	earlier versions of this document.		Yourtchenko for providing valuable comments on earlier 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 67, line 25		skipping to change at page 67, line 23
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, September 2001.		RFC 3168, September 2001.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
	[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic		[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
	Configuration of IPv4 Link-Local Addresses", RFC 3927,		Configuration of IPv4 Link-Local Addresses", RFC 3927,
	May 2005.		May 2005.
			[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
			Requirements for Security", BCP 106, RFC 4086, June 2005.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, August 2006.		Plan", BCP 122, RFC 4632, August 2006.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
	[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.		[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
	Pignataro, "The Generalized TTL Security Mechanism		Pignataro, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 5082, October 2007.		(GTSM)", RFC 5082, October 2007.
	[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the		[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the
	IPv4 and IPv6 Router Alert Options", RFC 5350,		IPv4 and IPv6 Router Alert Options", RFC 5350,
	September 2008.		September 2008.
	[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",		[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
	BCP 153, RFC 5735, January 2010.		BCP 153, RFC 5735, January 2010.
			[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
			Notification", RFC 6040, November 2010.
	7.2. Informative References		7.2. Informative References
	[Anderson2001]		[Anderson2001]
	Anderson, J., "An Analysis of Fragmentation Attacks",		Anderson, J., "An Analysis of Fragmentation Attacks",
	Available at: http://www.ouah.org/fragma.html , 2001.		Available at: http://www.ouah.org/fragma.html , 2001.
	[Arkin2000]		[Arkin2000]
	Arkin, "IP TTL Field Value with ICMP (Oops - Identifying		Arkin, "IP TTL Field Value with ICMP (Oops - Identifying
	Windows 2000 again and more)", http://		Windows 2000 again and more)", http://
	ofirarkin.files.wordpress.com/2008/11/		ofirarkin.files.wordpress.com/2008/11/
	skipping to change at page 70, line 27		skipping to change at page 70, line 28
	broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c,		broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c,
	Phile #0x0c of 0x10 http://www.phrack.org/		Phile #0x0c of 0x10 http://www.phrack.org/
	issues.html?issue=60&id=12&mode=txt, 2002.		issues.html?issue=60&id=12&mode=txt, 2002.
	[FIPS1994]		[FIPS1994]
	FIPS, "Standard Security Label for Information Transfer",		FIPS, "Standard Security Label for Information Transfer",
	Federal Information Processing Standards Publication. FIP		Federal Information Processing Standards Publication. FIP
	PUBS 188 http://csrc.nist.gov/publications/fips/fips188/		PUBS 188 http://csrc.nist.gov/publications/fips/fips188/
	fips188.pdf, 1994.		fips188.pdf, 1994.
	[Fuller2008a]
	Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The
	Future Begins Now", Routing SIG Meeting, 25th APNIC Open
	Policy Meeting, February 25 - 29 2008, Taipei, Taiwan http
	://www.apnic.net/meetings/25/program/routing/
	fuller-240-future.pdf, 2008.
	[Fyodor2004]		[Fyodor2004]
	Fyodor, "Idle scanning and related IP ID games",		Fyodor, "Idle scanning and related IP ID games",
	http://www.insecure.org/nmap/idlescan.html, 2004.		http://www.insecure.org/nmap/idlescan.html, 2004.
	[GIAC2000]		[GIAC2000]
	GIAC, "Egress Filtering v 0.2",		GIAC, "Egress Filtering v 0.2",
	http://www.sans.org/y2k/egress.htm, 2000.		http://www.sans.org/y2k/egress.htm, 2000.
	[Gont2006]		[Gont2006]
	Gont, F., "Advanced ICMP packet filtering",		Gont, F., "Advanced ICMP packet filtering",
	skipping to change at page 71, line 7		skipping to change at page 70, line 50
	[Haddad2004]		[Haddad2004]
	Haddad, I. and M. Zakrzewski, "Security Distribution for		Haddad, I. and M. Zakrzewski, "Security Distribution for
	Linux Clusters", Linux		Linux Clusters", Linux
	Journal http://www.linuxjournal.com/article/6943, 2004.		Journal http://www.linuxjournal.com/article/6943, 2004.
	[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.fuller-240space]		[I-D.ietf-intarea-router-alert-considerations]
	Fuller, V., "Reclassifying 240/4 as usable unicast address		Faucheur, F., "IP Router Alert Considerations and Usage",
	space", draft-fuller-240space-02 (work in progress),		draft-ietf-intarea-router-alert-considerations-02 (work in
	March 2008.		progress), October 2010.
	[I-D.ietf-tcpm-icmp-attacks]		[I-D.ietf-tcpm-icmp-attacks]
	Gont, F., "ICMP attacks against TCP",		Gont, F., "ICMP attacks against TCP",
	draft-ietf-tcpm-icmp-attacks-12 (work in progress),		draft-ietf-tcpm-icmp-attacks-12 (work in progress),
	March 2010.		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.
	[I-D.wilson-class-e]
	Wilson, P., Michaelson, G., and G. Huston, "Redesignation
	of 240/4 from "Future Use" to "Private Use"",
	draft-wilson-class-e-02 (work in progress),
	September 2008.
	[IANA2006a]		[IANA2006a]
	Ether Types,		Ether Types,
	"http://www.iana.org/assignments/ethernet-numbers".		"http://www.iana.org/assignments/ethernet-numbers".
	[IANA2006b]		[IANA2006b]
	IP Parameters,		IP Parameters,
	"http://www.iana.org/assignments/ip-parameters".		"http://www.iana.org/assignments/ip-parameters".
	[IANA2006c]		[IANA2006c]
	Protocol Numbers,		Protocol Numbers,
	skipping to change at page 76, line 7		skipping to change at page 75, line 45
	[Zakrzewski2002]		[Zakrzewski2002]
	Zakrzewski, M. and I. Haddad, "Linux Distributed Security		Zakrzewski, M. and I. Haddad, "Linux Distributed Security
	Module", http://www.linuxjournal.com/article/6215, 2002.		Module", http://www.linuxjournal.com/article/6215, 2002.
	[daemon91996]		[daemon91996]
	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. Advice and guidance to vendors		Appendix A. Changes from previous versions of the draft
	Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they
	think they may be affected by the issues described in this document.
	As the lead coordination center for these issues, CPNI is well placed
	to give advice and guidance as required.
	CPNI works extensively with government departments and agencies,
	commercial organizations and the academic community to research
	vulnerabilities and potential threats to IT systems especially where
	they may have an impact on Critical National Infrastructure's (CNI).
	Other ways to contact CPNI, plus CPNI's PGP public key, are available
	at http://www.cpni.gov.uk .
	Appendix B. 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.
	B.1. Changes from draft-ietf-opsec-ip-security-03		A.1. Changes from draft-ietf-opsec-ip-security-03
			o Addresses IESG review comments by Jari Arkko, Stewart Bryant,
			Adrian Farrel, Peter Saint-Andre, and Sean Turner.
			A.2. 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.
	B.2. Changes from draft-ietf-opsec-ip-security-02		A.3. 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.)
	B.3. Changes from draft-ietf-opsec-ip-security-01		A.4. 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.)
	B.4. Changes from draft-ietf-opsec-ip-security-00		A.5. 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)
	B.5. Changes from draft-gont-opsec-ip-security-01		A.6. 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.
	B.6. Changes from draft-gont-opsec-ip-security-00		A.7. 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. 33 change blocks.
	91 lines changed or deleted		95 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/