< draft-ietf-ipsecme-esp-null-heuristics-06.txt		draft-ietf-ipsecme-esp-null-heuristics-07.txt >
	IP Security Maintenance and T. Kivinen		IP Security Maintenance and T. Kivinen
	Extensions (ipsecme) Safenet, Inc.		Extensions (ipsecme) AuthenTec, Inc.
	Internet-Draft D. McDonald		Internet-Draft D. McDonald
	Intended status: Informational Sun Microsystems, Inc.		Intended status: Informational Oracle Corporation
	Expires: August 30, 2010 February 26, 2010		Expires: September 23, 2010 March 22, 2010
	Heuristics for Detecting ESP-NULL packets		Heuristics for Detecting ESP-NULL packets
	draft-ietf-ipsecme-esp-null-heuristics-06.txt		draft-ietf-ipsecme-esp-null-heuristics-07.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 encrypted or
	or not. Use of these heuristics does not require any changes made on		not, i.e. whether it can be inspected or not. Use of these
	existing RFC4303 compliant IPsec hosts.		heuristics does not require any changes made on existing RFC4303
			compliant IPsec hosts.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 44 ¶
	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 30, 2010.		This Internet-Draft will expire on September 23, 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 8, line 30 ¶		skipping to change at page 8, line 30 ¶
	worse in that case, as heuristic checks will need to be done for each		worse in that case, as heuristic checks will need to be done for each
	packet, not only once per flow. This will also affect the		packet, not only once per flow. This will also affect the
	reliability of the heuristics.		reliability of the heuristics.
	Generally, an intermediate node runs heuristics only for the first		Generally, an intermediate node runs heuristics only for the first
	few packets of the new flow (i.e. the new IPsec SA). After those few		few packets of the new flow (i.e. the new IPsec SA). After those few
	packets, the node detects parameters of the IPsec flow, it skips		packets, the node detects parameters of the IPsec flow, it skips
	detection heuristics, and it can perform direct packet-inspecting		detection heuristics, and it can perform direct packet-inspecting
	action based on its own policy. Once detected, ESP-NULL packets will		action based on its own policy. Once detected, ESP-NULL packets will
	never be detected as encrypted ESP packets, meaning that valid ESP-		never be detected as encrypted ESP packets, meaning that valid ESP-
	NULL packets will never bypass the deep inspection. The only failure		NULL packets will never bypass the deep inspection.
	mode of these heuristics is to assume encrypted ESP packets are ESP-
	NULL packets, thus causing completely random packet data to be deeply		The only failure mode of these heuristics is to assume encrypted ESP
	inspected. An attacker can easily send random-looking ESP-NULL		packets are ESP-NULL packets, thus causing completely random packet
	packets which will cause heuristics to detect packets as encrypted		data to be deeply inspected. An attacker can easily send random-
	ESP, but that is no worse than sending non-ESP fuzz through an		looking ESP-NULL packets which will cause heuristics to detect
	intermediate node.		packets as encrypted ESP, but that is no worse than sending non-ESP
			fuzz through an intermediate node. The only way an ESP-NULL flow can
			be mistaken for an encrypted ESP flow is if the ESP-NULL flow uses an
			authentication algorithm of which the packet inspector has no
			knowledge.
	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
	skipping to change at page 19, line 20 ¶		skipping to change at page 19, line 20 ¶
	operation, thus skipping that check might be best unless there is		operation, thus skipping that check might be best unless there is
	hardware to help the calculation. Window size, urgent pointer,		hardware to help the calculation. Window size, urgent pointer,
	sequence number, and acknowledgement numbers can be used, but there		sequence number, and acknowledgement numbers can be used, but there
	is not one specific known value for them.		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. This heuristics is most helpful when only one		correctly detected. This heuristic is most helpful when only one
	packet is outstanding. For example, if a TCP SYN packet is lost (or		packet is outstanding. For example, if a TCP SYN packet is lost (or
	dropped because of policy), the next packet would always be a		dropped because of policy), the next packet would always be a
	retransmission of the same TCP SYN packet.		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.
	skipping to change at page 20, line 41 ¶		skipping to change at page 20, line 41 ¶
	In cases of tunneled traffic the packet inside contains a full IPv4		In cases of tunneled traffic the packet inside contains a full IPv4
	or IPv6 packet. Many fields are usable. For IPv4 those fields		or IPv6 packet. Many fields are usable. For IPv4 those fields
	include version, header length, total length (again TFC padding might		include version, header length, total length (again TFC padding might
	confuse things there), protocol number, and 16-bit header checksum.		confuse things there), protocol number, and 16-bit header checksum.
	In those cases the intermediate device should give the decapsulated		In those cases the intermediate device should give the decapsulated
	IP packet to the deep inspection engine. IPv6 has fewer usable		IP packet to the deep inspection engine. IPv6 has fewer usable
	fields, but the version number, packet length (modulo TFC confusion)		fields, but the version number, packet length (modulo TFC confusion)
	and next-header all can be used by deep-packet inspection.		and next-header all can be used by deep-packet inspection.
	In both IPv4 and IPv6 the heuristics can also check the IP addresses		If all traffic going through the intermediate device is either from
	either to be in the known range (for example check that both IPv6		or to certain address block(s) (for example, either to or from the
	source and destination have same prefix etc), or checking addresses		company intranet prefix), this can also be checked by the heuristics.
	across more than one packet.
	9. Security Considerations		9. Security Considerations
	Attackers can always bypass ESP-NULL deep packet inspection by using		Attackers can always bypass ESP-NULL deep packet inspection by using
	encrypted ESP (or some other encryption or tunneling method) instead,		encrypted ESP (or some other encryption or tunneling method) instead,
	unless the intermediate node's policy requires dropping of packets		unless the intermediate node's policy requires dropping of packets
	that it cannot inspect. Ultimately the responsibility for performing		that it cannot inspect. Ultimately the responsibility for performing
	deep inspection, or allowing intermediate nodes to perform deep		deep inspection, or allowing intermediate nodes to perform deep
	inspection, must rest on the end nodes. I.e. if a server allows		inspection, must rest on the end nodes. I.e. if a server allows
	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 (heuristics may still be needed to find out the IV and
	ICV and IV sizes.		ICV lengths, unless further policy restrictions eliminate the
			ambiguities).
			Section 3 discusses failure modes of the heuristics. An attacker can
			poison flows, tricking inspectors into ignoring legitimate ESP-NULL
			flows, but that is no worse than injecting fuzz.
	Forcing use of ESP-NULL everywhere inside the enterprise, so that		Forcing use of ESP-NULL everywhere inside the enterprise, so that
	accounting, logging, network monitoring, and intrusion detection all		accounting, logging, network monitoring, and intrusion detection all
	work, increases the risk of sending confidential information where		work, increases the risk of sending confidential information where
	eavesdroppers can see it.		eavesdroppers can see it.
	10. IANA Considerations		10. IANA Considerations
	No IANA assignments are needed.		No IANA assignments are needed.
	skipping to change at page 37, line 8 ¶		skipping to change at page 37, line 8 ¶
	Last_Packet_Data.destination_port =		Last_Packet_Data.destination_port =
	Packet_Data.UDP.destination_port		Packet_Data.UDP.destination_port
	* Increment Check_Bits by 32		* Increment Check_Bits by 32
	* Return Success		* Return Success
	Figure 4		Figure 4
	Authors' Addresses		Authors' Addresses
	Tero Kivinen		Tero Kivinen
	Safenet, Inc.		AuthenTec, Inc.
	Fredrikinkatu 47		Fredrikinkatu 47
	HELSINKI FIN-00100		HELSINKI FIN-00100
	FI		FI
	Email: kivinen@iki.fi		Email: kivinen@iki.fi
	Daniel L. McDonald		Daniel L. McDonald
	Sun Microsystems, Inc.		Oracle Corporation
	35 Network Drive		35 Network Drive
	MS UBUR02-212		MS UBUR02-212
	Burlington, MA 01803		Burlington, MA 01803
	USA		USA
	Email: danmcd@sun.com		Email: danmcd@sun.com
End of changes. 11 change blocks.
	24 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/