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.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/