--- 1/draft-ietf-ipsecme-esp-null-heuristics-06.txt 2010-03-22 18:10:51.000000000 +0100 +++ 2/draft-ietf-ipsecme-esp-null-heuristics-07.txt 2010-03-22 18:10:51.000000000 +0100 @@ -1,29 +1,30 @@ IP Security Maintenance and T. Kivinen -Extensions (ipsecme) Safenet, Inc. +Extensions (ipsecme) AuthenTec, Inc. Internet-Draft D. McDonald -Intended status: Informational Sun Microsystems, Inc. -Expires: August 30, 2010 February 26, 2010 +Intended status: Informational Oracle Corporation +Expires: September 23, 2010 March 22, 2010 Heuristics for Detecting ESP-NULL packets - draft-ietf-ipsecme-esp-null-heuristics-06.txt + draft-ietf-ipsecme-esp-null-heuristics-07.txt Abstract This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep inspection - engines, to quickly decide whether given packet flow is interesting - or not. Use of these heuristics does not require any changes made on - existing RFC4303 compliant IPsec hosts. + engines, to quickly decide whether given packet flow is encrypted or + not, i.e. whether it can be inspected or not. Use of these + heuristics does not require any changes made on existing RFC4303 + compliant IPsec hosts. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -32,21 +33,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -280,27 +281,31 @@ 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 reliability of the heuristics. 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 packets, the node detects parameters of the IPsec flow, it skips detection heuristics, and it can perform direct packet-inspecting action based on its own policy. Once detected, ESP-NULL packets will never be detected as encrypted ESP packets, meaning that valid ESP- - NULL packets will never bypass the deep inspection. The only failure - mode of these heuristics is to assume encrypted ESP packets are ESP- - NULL packets, thus causing completely random packet data to be deeply - inspected. An attacker can easily send random-looking ESP-NULL - packets which will cause heuristics to detect packets as encrypted - ESP, but that is no worse than sending non-ESP fuzz through an - intermediate node. + NULL packets will never bypass the deep inspection. + + The only failure mode of these heuristics is to assume encrypted ESP + packets are ESP-NULL packets, thus causing completely random packet + data to be deeply inspected. An attacker can easily send random- + looking ESP-NULL packets which will cause heuristics to detect + 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 next header number (50), source address, destination address, and SPI can be done by the hardware (there is usually already similar functionality there, for TCP/UDP flows). The heuristics can be implemented by the hardware, but using software will allow faster updates when new protocol modifications come out or new protocols need support. As described in Section 7, UDP encapsulated ESP traffic may also have @@ -698,21 +703,21 @@ operation, thus skipping that check might be best unless there is 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 packet will most likely be a retransmission of the previous packet. Thus if two packets are received with the same source, and destination port numbers, and where sequence numbers are either same 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 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 checking already, including flow tracking, verification of sequence numbers, and reconstruction of the whole TCP flow. Similar methods can be used here, but they are implementation-dependent and not described here. @@ -763,42 +768,46 @@ In cases of tunneled traffic the packet inside contains a full IPv4 or IPv6 packet. Many fields are usable. For IPv4 those fields include version, header length, total length (again TFC padding might confuse things there), protocol number, and 16-bit header checksum. In those cases the intermediate device should give the decapsulated IP packet to the deep inspection engine. IPv6 has fewer usable fields, but the version number, packet length (modulo TFC confusion) and next-header all can be used by deep-packet inspection. - In both IPv4 and IPv6 the heuristics can also check the IP addresses - either to be in the known range (for example check that both IPv6 - source and destination have same prefix etc), or checking addresses - across more than one packet. + If all traffic going through the intermediate device is either from + or to certain address block(s) (for example, either to or from the + company intranet prefix), this can also be checked by the heuristics. 9. Security Considerations Attackers can always bypass ESP-NULL deep packet inspection by using encrypted ESP (or some other encryption or tunneling method) instead, unless the intermediate node's policy requires dropping of packets that it cannot inspect. Ultimately the responsibility for performing deep inspection, or allowing intermediate nodes to perform deep inspection, must rest on the end nodes. I.e. if a server allows encrypted connections also, then an attacker who wants to attack the server and wants to bypass a deep inspection device in the middle, will use encrypted traffic. This means that the protection of the whole network is only as good as the policy enforcement and protection of the end node. One way to enforce deep inspection for all traffic, is to forbid encrypted ESP completely, in which case ESP-NULL detection is easier, as all packets must be ESP-NULL based - on the policy, and further restrictions can eliminate ambiguities in - ICV and IV sizes. + on the policy (heuristics may still be needed to find out the IV and + 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 accounting, logging, network monitoring, and intrusion detection all work, increases the risk of sending confidential information where eavesdroppers can see it. 10. IANA Considerations No IANA assignments are needed. @@ -1416,25 +1425,25 @@ Last_Packet_Data.destination_port = Packet_Data.UDP.destination_port * Increment Check_Bits by 32 * Return Success Figure 4 Authors' Addresses Tero Kivinen - Safenet, Inc. + AuthenTec, Inc. Fredrikinkatu 47 HELSINKI FIN-00100 FI Email: kivinen@iki.fi Daniel L. McDonald - Sun Microsystems, Inc. + Oracle Corporation 35 Network Drive MS UBUR02-212 Burlington, MA 01803 USA Email: danmcd@sun.com