--- 1/draft-ietf-ipsecme-esp-null-heuristics-04.txt 2010-01-28 15:11:29.000000000 +0100 +++ 2/draft-ietf-ipsecme-esp-null-heuristics-05.txt 2010-01-28 15:11:29.000000000 +0100 @@ -1,19 +1,19 @@ IP Security Maintenance and T. Kivinen Extensions (ipsecme) Safenet, Inc. Internet-Draft D. McDonald Intended status: Informational Sun Microsystems, Inc. -Expires: July 31, 2010 January 27, 2010 +Expires: August 1, 2010 January 28, 2010 Heuristics for Detecting ESP-NULL packets - draft-ietf-ipsecme-esp-null-heuristics-04.txt + draft-ietf-ipsecme-esp-null-heuristics-05.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. @@ -32,21 +32,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 July 31, 2010. + This Internet-Draft will expire on August 1, 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 @@ -216,23 +216,22 @@ necessary. The another problem is that in the new IPsec Architecture [RFC4301] the support for AH is now optional, meaning not all implementations support it. ESP-NULL has been defined to be mandatory to implement by the Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) document [RFC4835]. AH has also quite complex processing rules compared to ESP when calculating the ICV, including things like zeroing out mutable - fields. As AH is not as widely used than ESP, the AH support is not - as well tested in the interoperability events, meaning it might have - more bugs than ESP implementations. + fields, also as AH is not as widely used than ESP, the AH support is + not as well tested in the interoperability events. 2.2. Mandating by Policy Another easy way to solve this problem is to mandate the use of ESP- NULL with common parameters within an entire organization. This either removes the need for heuristics (if no ESP encrypted traffic is allowed at all) or simplifies them considerably (only one set of 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 algorithm). This does not work unless one of a pair of communicating @@ -250,31 +249,24 @@ encryption. The following methods have been discussed: adding an IP- option, adding a new IP-protocol number plus an extra header [I-D.ietf-ipsecme-traffic-visibility], adding new IP-protocol numbers 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], and using UDP encapsulation with a different format and ports. All of the aforementioned drafts require modification to ESP, which requires that all end nodes need to be modified before intermediate devices can assume that this new ESP format is in use. Updating end - nodes will require lots of time. An example of the slowness of - endpoint migration vs. intermediate migration can be seen from the - deployment of both IPv6 and NAT. IPv6 required updating all of the - end nodes (and routers too) before it could be effectively used. - This has taken a very long time, and IPv6 deployment is not yet - widespread. NAT, on the other hand, only required modifying an - existing intermediate device or adding a new one, and has spread out - much faster. Another example of slow end-node deployment is IKEv2. - Considering an implementation that requires both IKEv2 and a new ESP - format, it would take several years, possibly as long as a decade, - before widespread deployment. + nodes will require lots of time. An example of slow end-node + deployment is IKEv2. Considering an implementation that requires + both IKEv2 and a new ESP format, it would take several years, + possibly as long as a decade, before widespread deployment. 3. Description of Heuristics The heuristics to detect ESP-NULL packets will only require changes to those intermediate devices which do deep inspection or other operations which require detecting ESP-NULL. As those nodes require changes regardless of any ESP-NULL method, updating intermediate nodes is unavoidable. Heuristics do not require updating or modifying any other devices on the rest of the network, including (especially) end-nodes. @@ -551,21 +543,21 @@ the heuristics, then detecting the IV length is impossible, thus the heuristics cannot finish. In that case, the heuristics return "unsure" and requires further packets. This document does not cover RSA authentication in ESP ([RFC4359]), as it is considered being beyond the scope of this document. 8.2. Self Describing Padding Check Before obtaining the next header field, the ICV length must be - measured. Five different ICV lengths lead to five possible places + measured. Four different ICV lengths lead to four possible places for the pad length and padding. Implementations must be careful when trying larger sizes of ICV such that the inspected bytes do not belong to data that is not payload data. For example, a ten-byte ICMP echo request will have zero-length padding, but any checks for 256-bit ICVs will inspect sequence number or SPI data if the packet actually contains a 96-bit or 128-bit ICV. ICV lengths should always be checked from shortest to longest. It is much more likely to obtain valid-looking padding bytes in the cleartext part of the payload than from the ICV field of a longer ICV @@ -581,46 +573,46 @@ payload, pad length, and next header are always right aligned within a 4-byte boundary. Normally implementations use minimal amount of padding, but the heuristics method would be even more reliable if some extra padding is added. The actual padding data has bytes starting from 01 and ending to the pad length, i.e. exact padding and pad length bytes for 4 bytes of padding would be 01 02 03 04 04. Two cases of ESP-NULL padding are matched bytes (like the 04 04 shown above), or the zero-byte padding case. In cases where there is one or more bytes of padding, a node can perform a very simple and fast - test -- a sequence of N N in any of those five locations. Given five - two-byte locations (assuming the packet size allows all five possible + test -- a sequence of N N in any of those four locations. Given four + two-byte locations (assuming the packet size allows all four possible ICV lengths), the upper-bound probability of finding a random encrypted packet that exhibits non-zero length ESP-NULL properties is: - 1 - (1 - 255 / 65536) ^ 5 == 0.019 == 1.9% + 1 - (1 - 255 / 65536) ^ 4 == 0.015 == 1.5% In the cases where there is 0 bytes of padding, a random encrypted ESP packet has: - 1 - (1 - 1 / 256) ^ 5 == 0.019 == 1.9%. + 1 - (1 - 1 / 256) ^ 4 == 0.016 == 1.6%. - Together, both cases yields a 3.8% upper-bound chance of + Together, both cases yields a 3.1% upper-bound chance of misclassifying an encrypted packet as an ESP-NULL packet. In the matched bytes case, further inspection (counting the pad bytes backward and downward from the pad-length match) can reduce the number of misclassified packets further. A padding length of 255 means a specific 256^254 sequence of bytes must occur. This 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 probability of being correct ESP-NULL padding. This shrinks the - aforementioned 1.9% of matched-pairs to virtually nothing. + aforementioned 1.5% of matched-pairs to virtually nothing. - At this point a maximum of 2% of packets remain, so the next header + At this point a maximum of 1.6% of packets remain, so the next header number is inspected. If the next header number is known (and supported) then the packet can be inspected based on the next header number. If the next header number is unknown (i.e. not any of those with protocol checking support) the packet is marked "unsure", because there is no way to detect the IV length without inspecting the inner protocol payload. 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)), and if IPv6 is in heavy use, that number increases to nine (Fragment @@ -684,24 +676,24 @@ bit count stays the same. A local policy might include reaching a bit count that is over a threshold (for example 96 bits), causing a packet to be marked as valid. 8.3.1. TCP checks 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 less useful information than other later packets might have. The best valid packet checks include: checking that header length and - reserved and other bits have valid values; checking source and - destination port numbers, which in some cases can be used for - heuristics (but in general they cannot be reliably distinguished from - random numbers apart from some well-known ports like 25/80/110/143). + flags have valid values; checking source and destination port + numbers, which in some cases can be used for heuristics (but in + general they cannot be reliably distinguished from random numbers + apart from some well-known ports like 25/80/110/143). 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 numbers used in the checksum are wrong, thus the checksum is wrong. If the checksum is correct that can again be used to increase the valid bit count, but verifying checksums is a costly 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. @@ -1317,22 +1309,20 @@ // protocols as deep inspection does // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for // IPv6) is also left out from here to make the document shorter. * Return Failure //////////////////////////////////////////////////////////// // Verify TCP protocol headers // Verify TCP: // First we check things that must be set correctly. - * Check TCP.reserved_bits are non-zero - * Return Failure * If TCP.Data_Offset field < 5 // TCP head length too small * Return Failure // After that we start to check things that does not // have one definitive value, but can have multiple possible // valid values * If TCP.ACK bit is not set, then check that TCP.Acknowledgment_number field contains 0 // If ACK bit is not set then the acknowledgment // field usually contains 0, but I do not think