draft-ietf-ipsecme-esp-null-heuristics-05.txt		draft-ietf-ipsecme-esp-null-heuristics-06.txt
	IP Security Maintenance and T. Kivinen		IP Security Maintenance and T. Kivinen
	Extensions (ipsecme) Safenet, Inc.		Extensions (ipsecme) Safenet, Inc.
	Internet-Draft D. McDonald		Internet-Draft D. McDonald
	Intended status: Informational Sun Microsystems, Inc.		Intended status: Informational Sun Microsystems, Inc.
	Expires: August 1, 2010 January 28, 2010		Expires: August 30, 2010 February 26, 2010
	Heuristics for Detecting ESP-NULL packets		Heuristics for Detecting ESP-NULL packets
	draft-ietf-ipsecme-esp-null-heuristics-05.txt		draft-ietf-ipsecme-esp-null-heuristics-06.txt
	Abstract		Abstract
	This document describes a set of heuristics for distinguishing IPsec		This document describes a set of heuristics for distinguishing IPsec
	ESP-NULL (Encapsulating Security Payload without encryption) packets		ESP-NULL (Encapsulating Security Payload without encryption) packets
	from encrypted ESP packets. These heuristics can be used on		from encrypted ESP packets. These heuristics can be used on
	intermediate devices, like traffic analyzers, and deep inspection		intermediate devices, like traffic analyzers, and deep inspection
	engines, to quickly decide whether given packet flow is interesting		engines, to quickly decide whether given packet flow is interesting
	or not. Use of these heuristics does not require any changes made on		or not. Use of these heuristics does not require any changes made on
	existing RFC4303 compliant IPsec hosts.		existing RFC4303 compliant IPsec hosts.
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 1, 2010.		This Internet-Draft will expire on August 30, 2010.
	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 36		skipping to change at page 2, line 36
	4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11		5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11
	6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12		6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12
	7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13		7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13
	8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14		8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14		8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14
	8.2. Self Describing Padding Check . . . . . . . . . . . . . . 16		8.2. Self Describing Padding Check . . . . . . . . . . . . . . 16
	8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 18		8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 18
	8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18		8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18
	8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19		8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19
	8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 19		8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 20
	8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20		8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20
	8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20		8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 21		9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 23		11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	11.2. Informative References . . . . . . . . . . . . . . . . . . 23		11.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25		Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25
	A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25		A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25
	A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27		A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27
	skipping to change at page 5, line 10		skipping to change at page 5, line 10
	Deep inspection engines and similar devices use a cache of flows		Deep inspection engines and similar devices use a cache of flows
	going through the device, and that cache keeps state of all flows		going through the device, and that cache keeps state of all flows
	going through the device.		going through the device.
	IPsec Flow		IPsec Flow
	An IPsec flow is a stream of packets sharing the same source IP,		An IPsec flow is a stream of packets sharing the same source IP,
	destination IP, protocol (ESP/AH) and SPI. Strictly speaking, the		destination IP, protocol (ESP/AH) and SPI. Strictly speaking, the
	source IP does not need to be as part of the flow identification,		source IP does not need to be as part of the flow identification,
	but as it can be there depending on the receiving implementation		but it can be. For this reason, it is safer to assume that the
	it is safer to assume it is always part of the flow		source IP is always part of the flow identification.
	identification.
	2. Other Options		2. Other Options
	This document will discuss the heuristic approach of detecting ESP-		This document will discuss the heuristic approach of detecting ESP-
	NULL packets. There are some other options which can be used, and		NULL packets. There are some other options which can be used, and
	this section will briefly discuss them.		this section will briefly discuss them.
	2.1. AH		2.1. AH
	The most logical approach would use the already defined protocol		The most logical approach would use the already defined protocol
	skipping to change at page 6, line 28		skipping to change at page 6, line 28
	Using AH has two problems. First is that, as it also protects the IP		Using AH has two problems. First is that, as it also protects the IP
	headers, it will also protect against NATs on the path, thus it will		headers, it will also protect against NATs on the path, thus it will
	not work if there is NAT on the path between end nodes. In some		not work if there is NAT on the path between end nodes. In some
	environments this might not be a problem, but some environments		environments this might not be a problem, but some environments
	include heavy use of NATs even inside the internal network of the		include heavy use of NATs even inside the internal network of the
	enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could		enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could
	be extended to support AH also, and the early versions of the NAT-T		be extended to support AH also, and the early versions of the NAT-T
	proposals did include that, but it was left out as it was not seen as		proposals did include that, but it was left out as it was not seen as
	necessary.		necessary.
	The another problem is that in the new IPsec Architecture [RFC4301]		Another problem is that in the new IPsec Architecture [RFC4301] the
	the support for AH is now optional, meaning not all implementations		support for AH is now optional, meaning not all implementations
	support it. ESP-NULL has been defined to be mandatory to implement		support it. ESP-NULL has been defined to be mandatory to implement
	by the Cryptographic Algorithm Implementation Requirements for		by the Cryptographic Algorithm Implementation Requirements for
	Encapsulating Security Payload (ESP) document [RFC4835].		Encapsulating Security Payload (ESP) document [RFC4835].
	AH has also quite complex processing rules compared to ESP when		AH has also quite complex processing rules compared to ESP when
	calculating the ICV, including things like zeroing out mutable		calculating the ICV, including things like zeroing out mutable
	fields, also as AH is not as widely used than ESP, the AH support is		fields. Also as AH is not as widely used than ESP, the AH support is
	not as well tested in the interoperability events.		not as well tested in the interoperability events.
	2.2. Mandating by Policy		2.2. Mandating by Policy
	Another easy way to solve this problem is to mandate the use of ESP-		Another easy way to solve this problem is to mandate the use of ESP-
	NULL with common parameters within an entire organization. This		NULL with common parameters within an entire organization. This
	either removes the need for heuristics (if no ESP encrypted traffic		either removes the need for heuristics (if no ESP encrypted traffic
	is allowed at all) or simplifies them considerably (only one set of		is allowed at all) or simplifies them considerably (only one set of
	parameters needs to be inspected, e.g. everybody in the organization		parameters needs to be inspected, e.g. everybody in the organization
	who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity		who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity
	algorithm). This does not work unless one of a pair of communicating		algorithm). This does work unless one of a pair of communicating
	machines is not under the same administrative domain as the deep		machines is not under the same administrative domain as the deep
	inspection engine. (IPsec Security Associations must be satisfactory		inspection engine. (IPsec Security Associations must be satisfactory
	to all communicating parties, so only one communicating peer needs to		to all communicating parties, so only one communicating peer needs to
	have a sufficiently narrow policy.) Also, such a solution might		have a sufficiently narrow policy.) Also, such a solution might
	require some kind of centralized policy management to make sure		require some kind of centralized policy management to make sure
	everybody in an administrative domain uses the same policy.		everybody in an administrative domain uses the same policy, and that
			changes to that single policy can be coordinated throughout the
			administrative domain.
	2.3. Modifying ESP		2.3. Modifying ESP
	Several internet drafts discuss ways of modifying ESP to offer		Several internet drafts discuss ways of modifying ESP to offer
	intermediate devices information about an ESP packet's use of NULL		intermediate devices information about an ESP packet's use of NULL
	encryption. The following methods have been discussed: adding an IP-		encryption. The following methods have been discussed: adding an IP-
	option, adding a new IP-protocol number plus an extra header		option, adding a new IP-protocol number plus an extra header
	[I-D.ietf-ipsecme-traffic-visibility], adding new IP-protocol numbers		[I-D.ietf-ipsecme-traffic-visibility], adding new IP-protocol numbers
	which tell the ESP-NULL parameters [I-D.hoffman-esp-null-protocol],		which tell the ESP-NULL parameters [I-D.hoffman-esp-null-protocol],
	reserving an SPI range for ESP-NULL [I-D.bhatia-ipsecme-esp-null],		reserving an SPI range for ESP-NULL [I-D.bhatia-ipsecme-esp-null],
	skipping to change at page 8, line 46		skipping to change at page 8, line 46
	intermediate node.		intermediate node.
	For hardware implementations all the flow lookup based on the ESP		For hardware implementations all the flow lookup based on the ESP
	next header number (50), source address, destination address, and SPI		next header number (50), source address, destination address, and SPI
	can be done by the hardware (there is usually already similar		can be done by the hardware (there is usually already similar
	functionality there, for TCP/UDP flows). The heuristics can be		functionality there, for TCP/UDP flows). The heuristics can be
	implemented by the hardware, but using software will allow faster		implemented by the hardware, but using software will allow faster
	updates when new protocol modifications come out or new protocols		updates when new protocol modifications come out or new protocols
	need support.		need support.
	As described in section 7, UDP encapsulated ESP traffic may also have		As described in Section 7, UDP encapsulated ESP traffic may also have
	have NAPT applied to it, and so there is already a 5-tuple state in		have NAPT applied to it, and so there is already a 5-tuple state in
	the stateful inspection gateway		the stateful inspection gateway.
	4. IPsec flows		4. IPsec flows
	ESP is a stateful protocol, meaning there is state stored in the both		ESP is a stateful protocol, meaning there is state stored in both end
	end nodes of the ESP IPsec SA, and the state is identified by the		nodes of the ESP IPsec SA, and the state is identified by the pair of
	pair of destination IP and SPI. End nodes also often fix the source		destination IP and SPI. End nodes also often fix the source IP
	IP address in an SA unless the destination is a multicast group.		address in an SA unless the destination is a multicast group.
	Typically most (if not all) flows of interest to an intermediate		Typically most (if not all) flows of interest to an intermediate
	device are unicast, so it is safer to assume the receiving node also		device are unicast, so it is safer to assume the receiving node also
	uses a source address, and the intermediate device should therefore		uses a source address, and the intermediate device should therefore
	do the same. In some cases this might cause extraneous cached ESP		do the same. In some cases this might cause extraneous cached ESP
	IPsec SA flows, but by using the source address two distinct flows		IPsec SA flows, but by using the source address two distinct flows
	will never be mixed. For sites which heavily use multicast, such		will never be mixed. For sites which heavily use multicast, such
	traffic is deterministically identifiable (224.0.0.0/4 for IPv4 and		traffic is deterministically identifiable (224.0.0.0/4 for IPv4 and
	ff00::0/8 for IPv6), and an implementation can save the space of		ff00::0/8 for IPv6), and an implementation can save the space of
	multiple cache entries for a multicast flow by checking the		multiple cache entries for a multicast flow by checking the
	destination address first.		destination address first.
	skipping to change at page 10, line 11		skipping to change at page 10, line 11
	they are measured). When the next packet to the flow arrives, it is		they are measured). When the next packet to the flow arrives, it is
	heuristically processed again, and the cached flow may continue to be		heuristically processed again, and the cached flow may continue to be
	"unsure", marked as ESP, or marked as an ESP-NULL flow.		"unsure", marked as ESP, or marked as an ESP-NULL flow.
	There are several reasons why a single packet might not be enough to		There are several reasons why a single packet might not be enough to
	detect type of flow. One of them is that the next header number was		detect type of flow. One of them is that the next header number was
	unknown, i.e. if heuristics do not know about the protocol for the		unknown, i.e. if heuristics do not know about the protocol for the
	packet, it cannot verify it has properly detected ESP-NULL		packet, it cannot verify it has properly detected ESP-NULL
	parameters, even when the packet otherwise looks like ESP-NULL. If		parameters, even when the packet otherwise looks like ESP-NULL. If
	the packet does not look like ESP-NULL at all, then encrypted ESP		the packet does not look like ESP-NULL at all, then encrypted ESP
	status can be returned quickly. As ESP-NULL heuristics should know		status can be returned quickly. As ESP-NULL heuristics need to know
	the same protocols as a deep inspection device, an unknown protocol		the same protocols as a deep inspection device, an ESP-NULL instance
	should not be handled any differently than a cleartext instance of an		of an unknown protocol can be handled the same way as a cleartext
	unknown protocol if possible.		instance of the same unknown protocol.
	5. Deep Inspection Engine		5. Deep Inspection Engine
	A deep inspection engine running on an intermediate node usually		A deep inspection engine running on an intermediate node usually
	checks deeply into the packet and performs policy decisions based on		checks deeply into the packet and performs policy decisions based on
	the contents of the packet. The deep inspection engine should be		the contents of the packet. The deep inspection engine should be
	able to tell the difference between success, failure, and garbage.		able to tell the difference between success, failure, and garbage.
	Success means that a packet was successfully checked with the deep		Success means that a packet was successfully checked with the deep
	inspection engine, and it passed the checks and is allowed to be		inspection engine, and it passed the checks and is allowed to be
	forwarded. Failure means that a packet was successfully checked but		forwarded. Failure means that a packet was successfully checked but
	skipping to change at page 12, line 23		skipping to change at page 12, line 23
	the deep inspection engine will most likely reject the packet and		the deep inspection engine will most likely reject the packet and
	return that it is garbage. If the deep inspection engine is		return that it is garbage. If the deep inspection engine is
	rejecting a high number of packets as garbage, it might indicate an		rejecting a high number of packets as garbage, it might indicate an
	original ESP-NULL detection for the flow was wrong (i.e. an encrypted		original ESP-NULL detection for the flow was wrong (i.e. an encrypted
	ESP flow was improperly detected as ESP-NULL). In that case, the		ESP flow was improperly detected as ESP-NULL). In that case, the
	cached flow should be invalidated and discovery should happen again.		cached flow should be invalidated and discovery should happen again.
	Each ESP-NULL flow should also keep statistics about how many packets		Each ESP-NULL flow should also keep statistics about how many packets
	have been detected as garbage by deep inspection, how many have		have been detected as garbage by deep inspection, how many have
	passed checks, or how many have failed checks with policy violations		passed checks, or how many have failed checks with policy violations
	(i.e. failed because actual inspection policy failures, not because		(i.e. failed because of actual inspection policy failures, not
	the packet looked like garbage). If the number of garbage packets		because the packet looked like garbage). If the number of garbage
	suddenly increases (e.g. most of the packets start to be look like		packets suddenly increases (e.g. most of the packets start to be look
	garbage according to the deep inspection engine), it is possible the		like garbage according to the deep inspection engine), it is possible
	old ESP-NULL SA was replaced by an identical-SPI encrypting ESP SA.		the old ESP-NULL SA was replaced by an identical-SPI encrypting ESP
	If both ends use random SPI generation, this is a very unlikely		SA. If both ends use random SPI generation, this is a very unlikely
	situation (1 in 2^32), but it is possible that some nodes reuse SPI		situation (1 in 2^32), but it is possible that some nodes reuse SPI
	numbers (e.g. a 32-bit memory address of the SA descriptor), thus		numbers (e.g. a 32-bit memory address of the SA descriptor), thus
	this situation needs to be handled.		this situation needs to be handled.
	Actual limits for cache invalidation are local policy decisions.		Actual limits for cache invalidation are local policy decisions.
	Sample invalidation policies include: 50% of packets marked as		Sample invalidation policies include: 50% of packets marked as
	garbage within a second; or if a deep inspection engine cannot		garbage within a second; or if a deep inspection engine cannot
	differentiate between garbage and failure, failing more than 95% of		differentiate between garbage and failure, failing more than 95% of
	packets in last 10 seconds. For implementations that do not		packets in last 10 seconds. For implementations that do not
	distinguish between garbage and failure, failures should not be		distinguish between garbage and failure, failures should not be
	skipping to change at page 15, line 11		skipping to change at page 15, line 11
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1		Figure 1
	The output of the heuristics should provide information about whether		The output of the heuristics should provide information about whether
	the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL the		the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL the
	heuristics should also provide the Integrity Check Value (ICV) field		heuristics should also provide the Integrity Check Value (ICV) field
	length and the Initialization Vector (IV) length.		length and the Initialization Vector (IV) length.
	The currently defined ESP authentication algorithms have 4 different		The currently defined ESP authentication algorithms have 4 different
	lengths for the ICV field. Most commonly used is 96 bits, and after		lengths for the ICV field.
	that comes 128 bit ICV lengths.
	Different ICV lengths for different algorithm:		Different ICV lengths for different algorithm:
	Algorithm ICV Length		Algorithm ICV Length
	------------------------------- ----------		------------------------------- ----------
	AUTH_HMAC_MD5_96 96		AUTH_HMAC_MD5_96 96
	AUTH_HMAC_SHA1_96 96		AUTH_HMAC_SHA1_96 96
	AUTH_AES_XCBC_96 96		AUTH_AES_XCBC_96 96
	AUTH_AES_CMAC_96 96		AUTH_AES_CMAC_96 96
	AUTH_HMAC_SHA2_256_128 128		AUTH_HMAC_SHA2_256_128 128
	skipping to change at page 17, line 14		skipping to change at page 17, line 14
	In the matched bytes case, further inspection (counting the pad bytes		In the matched bytes case, further inspection (counting the pad bytes
	backward and downward from the pad-length match) can reduce the		backward and downward from the pad-length match) can reduce the
	number of misclassified packets further. A padding length of 255		number of misclassified packets further. A padding length of 255
	means a specific 256^254 sequence of bytes must occur. This		means a specific 256^254 sequence of bytes must occur. This
	virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding.		virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding.
	Every one of the 255 pairs for padding length N has only a 1 / 256^N		Every one of the 255 pairs for padding length N has only a 1 / 256^N
	probability of being correct ESP-NULL padding. This shrinks the		probability of being correct ESP-NULL padding. This shrinks the
	aforementioned 1.5% of matched-pairs to virtually nothing.		aforementioned 1.5% of matched-pairs to virtually nothing.
	At this point a maximum of 1.6% of packets remain, so the next header		At this point a maximum of 1.6% of possible byte values remain, so
	number is inspected. If the next header number is known (and		the next header number is inspected. If the next header number is
	supported) then the packet can be inspected based on the next header		known (and supported) then the packet can be inspected based on the
	number. If the next header number is unknown (i.e. not any of those		next header number. If the next header number is unknown (i.e. not
	with protocol checking support) the packet is marked "unsure",		any of those with protocol checking support) the packet is marked
	because there is no way to detect the IV length without inspecting		"unsure", because there is no way to detect the IV length without
	the inner protocol payload.		inspecting the inner protocol payload.
	There are six different next header fields which are in common use		There are six different next header fields which are in common use
	(TCP (6), UDP (17), ICMP (1), SCTP (132), IPv4 (4) and IPv6 (41)),		(TCP (6), UDP (17), ICMP (1), SCTP (132), IPv4 (4) and IPv6 (41)),
	and if IPv6 is in heavy use, that number increases to nine (Fragment		and if IPv6 is in heavy use, that number increases to nine (Fragment
	(44), ICMPv6 (58), and IPv6 options (60)). To ensure that no packet		(44), ICMPv6 (58), and IPv6 options (60)). To ensure that no packet
	is misinterpreted as an encrypted ESP packet even when it is an ESP-		is misinterpreted as an encrypted ESP packet even when it is an ESP-
	NULL packet, a packet cannot be marked as a failure even when the		NULL packet, a packet cannot be marked as a failure even when the
	next header number is one of those which is not known and supported.		next header number is one of those which is not known and supported.
	In those cases the packets are marked as "unsure".		In those cases the packets are marked as "unsure".
	skipping to change at page 18, line 20		skipping to change at page 18, line 20
	parameters, and those heuristics benefit from the existing TCP / UDP		parameters, and those heuristics benefit from the existing TCP / UDP
	flows which were present in the previous IPsec SA. In that case it		flows which were present in the previous IPsec SA. In that case it
	is just enough to check that if a new IPsec SA has packets belonging		is just enough to check that if a new IPsec SA has packets belonging
	to the flows of some other IPsec SA (previous IPsec SA before rekey),		to the flows of some other IPsec SA (previous IPsec SA before rekey),
	and if those flows are already known by the deep inspection engine,		and if those flows are already known by the deep inspection engine,
	it will give a strong indication that the new SA is really ESP-NULL.		it will give a strong indication that the new SA is really ESP-NULL.
	The worst case scenario is when an end node starts up communication,		The worst case scenario is when an end node starts up communication,
	i.e. it does not have any previous flows through the device.		i.e. it does not have any previous flows through the device.
	Heuristics will run on the first few packets received from the end		Heuristics will run on the first few packets received from the end
	node. The later subsections mainly cover these bring up cases, as		node. The later subsections mainly cover these start-up cases, as
	they are the most difficult.		they are the most difficult.
	In the protocol checks there are two different types of checks. The		In the protocol checks there are two different types of checks. The
	first check is for packet validity, i.e. certain locations must		first check is for packet validity, i.e. certain locations must
	contain specific values. For example, an inner IPv4 header of an		contain specific values. For example, an inner IPv4 header of an
	IPv4 tunnel packet must have its 4-bit version number set to 4. If		IPv4 tunnel packet must have its 4-bit version number set to 4. If
	it does not, the packet is not valid, and can be marked as a failure.		it does not, the packet is not valid, and can be marked as a failure.
	Other positions depending on ICV and IV lengths must also be checked,		Other positions depending on ICV and IV lengths must also be checked,
	and if all of them are failures, then the packet is a failure. If		and if all of them are failures, then the packet is a failure. If
	any of the checks are "unsure" the packet is marked as such.		any of the checks are "unsure" the packet is marked as such.
	skipping to change at page 19, line 4		skipping to change at page 19, line 4
	When the first TCP packet is fed to the heuristics, it is most likely		When the first TCP packet is fed to the heuristics, it is most likely
	going to be the SYN packet of the new connection, thus it will have		going to be the SYN packet of the new connection, thus it will have
	less useful information than other later packets might have. The		less useful information than other later packets might have. The
	best valid packet checks include: checking that header length and		best valid packet checks include: checking that header length and
	flags have valid values; checking source and destination port		flags have valid values; checking source and destination port
	numbers, which in some cases can be used for heuristics (but in		numbers, which in some cases can be used for heuristics (but in
	general they cannot be reliably distinguished from random numbers		general they cannot be reliably distinguished from random numbers
	apart from some well-known ports like 25/80/110/143).		apart from some well-known ports like 25/80/110/143).
	The most obvious field, TCP checksum, might not be usable, as it is		The most obvious field, TCP checksum, might not be usable, as it is
	possible that the packet has already transited a NAT box, thus the IP		possible that the packet has already transited a NAT box which
	numbers used in the checksum are wrong, thus the checksum is wrong.		changed the IP addresses but assumed any ESP payload was encrypted
	If the checksum is correct that can again be used to increase the		and did not fix the transport checksums with the new IP addresses.
	valid bit count, but verifying checksums is a costly operation, thus		Thus the IP numbers used in the checksum are wrong, thus the checksum
	skipping that check might be best unless there is hardware to help		is wrong. If the checksum is correct that can again be used to
	the calculation. Window size, urgent pointer, sequence number, and		increase the valid bit count, but verifying checksums is a costly
	acknowledgement numbers can be used, but there is not one specific		operation, thus skipping that check might be best unless there is
	known value for them.		hardware to help the calculation. Window size, urgent pointer,
			sequence number, and acknowledgement numbers can be used, but there
			is not one specific known value for them.
	One good method of detection is if a packet is dropped then the next		One good method of detection is if a packet is dropped then the next
	packet will most likely be a retransmission of the previous packet.		packet will most likely be a retransmission of the previous packet.
	Thus if two packets are received with the same source, and		Thus if two packets are received with the same source, and
	destination port numbers, and where sequence numbers are either same		destination port numbers, and where sequence numbers are either same
	or right after each other, then it's likely a TCP packet has been		or right after each other, then it's likely a TCP packet has been
	correctly detected.		correctly detected. This heuristics is most helpful when only one
			packet is outstanding. For example, if a TCP SYN packet is lost (or
			dropped because of policy), the next packet would always be a
			retransmission of the same TCP SYN packet.
	Existing deep inspection engines usually do very good TCP flow		Existing deep inspection engines usually do very good TCP flow
	checking already, including flow tracking, verification of sequence		checking already, including flow tracking, verification of sequence
	numbers, and reconstruction of the whole TCP flow. Similar methods		numbers, and reconstruction of the whole TCP flow. Similar methods
	can be used here, but they are implementation-dependent and not		can be used here, but they are implementation-dependent and not
	described here.		described here.
	8.3.2. UDP checks		8.3.2. UDP checks
	UDP header has even more problems than the TCP header, as UDP has		UDP header has even more problems than the TCP header, as UDP has
	skipping to change at page 21, line 23		skipping to change at page 21, line 23
	encrypted connections also, then an attacker who wants to attack the		encrypted connections also, then an attacker who wants to attack the
	server and wants to bypass a deep inspection device in the middle,		server and wants to bypass a deep inspection device in the middle,
	will use encrypted traffic. This means that the protection of the		will use encrypted traffic. This means that the protection of the
	whole network is only as good as the policy enforcement and		whole network is only as good as the policy enforcement and
	protection of the end node. One way to enforce deep inspection for		protection of the end node. One way to enforce deep inspection for
	all traffic, is to forbid encrypted ESP completely, in which case		all traffic, is to forbid encrypted ESP completely, in which case
	ESP-NULL detection is easier, as all packets must be ESP-NULL based		ESP-NULL detection is easier, as all packets must be ESP-NULL based
	on the policy, and further restrictions can eliminate ambiguities in		on the policy, and further restrictions can eliminate ambiguities in
	ICV and IV sizes.		ICV and IV sizes.
	Using ESP-NULL or especially forcing using of it everywhere inside		Forcing use of ESP-NULL everywhere inside the enterprise, so that
	the enterprise can have increased risk of sending confidential		accounting, logging, network monitoring, and intrusion detection all
	information where eavesdroppers can see it.		work, increases the risk of sending confidential information where
			eavesdroppers can see it.
	10. IANA Considerations		10. IANA Considerations
	No IANA assignments are needed.		No IANA assignments are needed.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and		[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
End of changes. 20 change blocks.
	50 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/