--- 1/draft-ietf-ipsecme-esp-null-heuristics-05.txt 2010-02-26 14:10:55.000000000 +0100 +++ 2/draft-ietf-ipsecme-esp-null-heuristics-06.txt 2010-02-26 14:10:55.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: August 1, 2010 January 28, 2010 +Expires: August 30, 2010 February 26, 2010 Heuristics for Detecting ESP-NULL packets - draft-ietf-ipsecme-esp-null-heuristics-05.txt + draft-ietf-ipsecme-esp-null-heuristics-06.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 August 1, 2010. + This Internet-Draft will expire on August 30, 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 @@ -70,21 +70,21 @@ 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 16 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 18 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18 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.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27 @@ -181,23 +181,22 @@ 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. IPsec Flow An IPsec flow is a stream of packets sharing the same source IP, destination IP, protocol (ESP/AH) and SPI. Strictly speaking, the source IP does not need to be as part of the flow identification, - but as it can be there depending on the receiving implementation - it is safer to assume it is always part of the flow - identification. + but it can be. For this reason, it is safer to assume that the + source IP is always part of the flow identification. 2. Other Options This document will discuss the heuristic approach of detecting ESP- NULL packets. There are some other options which can be used, and this section will briefly discuss them. 2.1. AH The most logical approach would use the already defined protocol @@ -208,46 +207,48 @@ 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 not work if there is NAT on the path between end nodes. In some environments this might not be a problem, but some environments include heavy use of NATs even inside the internal network of the enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could 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 necessary. - The another problem is that in the new IPsec Architecture [RFC4301] - the support for AH is now optional, meaning not all implementations + 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, 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. 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 + algorithm). This does work unless one of a pair of communicating machines is not under the same administrative domain as the deep inspection engine. (IPsec Security Associations must be satisfactory to all communicating parties, so only one communicating peer needs to have a sufficiently narrow policy.) Also, such a solution might 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 Several internet drafts discuss ways of modifying ESP to offer intermediate devices information about an ESP packet's use of NULL 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], @@ -295,30 +296,30 @@ intermediate node. 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 + 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 - the stateful inspection gateway + the stateful inspection gateway. 4. IPsec flows - ESP is a stateful protocol, meaning there is state stored in the both - end nodes of the ESP IPsec SA, and the state is identified by the - pair of destination IP and SPI. End nodes also often fix the source - IP address in an SA unless the destination is a multicast group. + ESP is a stateful protocol, meaning there is state stored in both end + nodes of the ESP IPsec SA, and the state is identified by the pair of + destination IP and SPI. End nodes also often fix the source IP + address in an SA unless the destination is a multicast group. Typically most (if not all) flows of interest to an intermediate device are unicast, so it is safer to assume the receiving node also uses a source address, and the intermediate device should therefore do the same. In some cases this might cause extraneous cached ESP IPsec SA flows, but by using the source address two distinct flows will never be mixed. For sites which heavily use multicast, such 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 multiple cache entries for a multicast flow by checking the destination address first. @@ -354,24 +355,24 @@ they are measured). When the next packet to the flow arrives, it is heuristically processed again, and the cached flow may continue to be "unsure", marked as ESP, or marked as an ESP-NULL flow. 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 unknown, i.e. if heuristics do not know about the protocol for the packet, it cannot verify it has properly detected ESP-NULL parameters, even when the packet otherwise looks like ESP-NULL. If the packet does not look like ESP-NULL at all, then encrypted ESP - status can be returned quickly. As ESP-NULL heuristics should know - the same protocols as a deep inspection device, an unknown protocol - should not be handled any differently than a cleartext instance of an - unknown protocol if possible. + status can be returned quickly. As ESP-NULL heuristics need to know + the same protocols as a deep inspection device, an ESP-NULL instance + of an unknown protocol can be handled the same way as a cleartext + instance of the same unknown protocol. 5. Deep Inspection Engine A deep inspection engine running on an intermediate node usually checks deeply into the packet and performs policy decisions based on the contents of the packet. The deep inspection engine should be able to tell the difference between success, failure, and garbage. Success means that a packet was successfully checked with the deep inspection engine, and it passed the checks and is allowed to be forwarded. Failure means that a packet was successfully checked but @@ -402,26 +403,26 @@ the deep inspection engine will most likely reject the packet and return that it is garbage. If the deep inspection engine is 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 ESP flow was improperly detected as ESP-NULL). In that case, the cached flow should be invalidated and discovery should happen again. Each ESP-NULL flow should also keep statistics about how many packets have been detected as garbage by deep inspection, how many have passed checks, or how many have failed checks with policy violations - (i.e. failed because actual inspection policy failures, not because - the packet looked like garbage). If the number of garbage packets - suddenly increases (e.g. most of the packets start to be look like - garbage according to the deep inspection engine), it is possible the - old ESP-NULL SA was replaced by an identical-SPI encrypting ESP SA. - If both ends use random SPI generation, this is a very unlikely + (i.e. failed because of actual inspection policy failures, not + because the packet looked like garbage). If the number of garbage + packets suddenly increases (e.g. most of the packets start to be look + like garbage according to the deep inspection engine), it is possible + the old ESP-NULL SA was replaced by an identical-SPI encrypting ESP + 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 numbers (e.g. a 32-bit memory address of the SA descriptor), thus this situation needs to be handled. Actual limits for cache invalidation are local policy decisions. Sample invalidation policies include: 50% of packets marked as garbage within a second; or if a deep inspection engine cannot differentiate between garbage and failure, failing more than 95% of packets in last 10 seconds. For implementations that do not distinguish between garbage and failure, failures should not be @@ -498,22 +499,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 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 heuristics should also provide the Integrity Check Value (ICV) field length and the Initialization Vector (IV) length. The currently defined ESP authentication algorithms have 4 different - lengths for the ICV field. Most commonly used is 96 bits, and after - that comes 128 bit ICV lengths. + lengths for the ICV field. Different ICV lengths for different algorithm: Algorithm ICV Length ------------------------------- ---------- AUTH_HMAC_MD5_96 96 AUTH_HMAC_SHA1_96 96 AUTH_AES_XCBC_96 96 AUTH_AES_CMAC_96 96 AUTH_HMAC_SHA2_256_128 128 @@ -598,27 +598,27 @@ 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.5% of matched-pairs to virtually nothing. - 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. + At this point a maximum of 1.6% of possible byte values 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 (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- 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. In those cases the packets are marked as "unsure". @@ -649,21 +649,21 @@ parameters, and those heuristics benefit from the existing TCP / UDP 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 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, 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, i.e. it does not have any previous flows through the device. 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. In the protocol checks there are two different types of checks. The first check is for packet validity, i.e. certain locations must 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 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, 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. @@ -682,35 +682,40 @@ 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 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. + possible that the packet has already transited a NAT box which + changed the IP addresses but assumed any ESP payload was encrypted + and did not fix the transport checksums with the new IP addresses. + 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. 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. + 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 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. 8.3.2. UDP checks UDP header has even more problems than the TCP header, as UDP has @@ -781,23 +786,24 @@ 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. - Using ESP-NULL or especially forcing using of it everywhere inside - the enterprise can have increased risk of sending confidential - information where eavesdroppers can see it. + 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. 11. References 11.1. Normative References [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and