--- 1/draft-ietf-ipsecme-esp-null-heuristics-00.txt 2009-09-04 11:12:18.000000000 +0200 +++ 2/draft-ietf-ipsecme-esp-null-heuristics-01.txt 2009-09-04 11:12:18.000000000 +0200 @@ -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: October 18, 2009 April 16, 2009 +Expires: March 7, 2010 September 3, 2009 Heuristics for Detecting ESP-NULL packets - draft-ietf-ipsecme-esp-null-heuristics-00.txt + draft-ietf-ipsecme-esp-null-heuristics-01.txt 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. @@ -22,21 +22,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 October 18, 2009. + This Internet-Draft will expire on March 7, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -48,43 +48,45 @@ NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 - 3. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 5 - 3.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Description of Heuristics . . . . . . . . . . . . . . . . . . 7 - 5. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 6. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 10 - 7. Special and Error Cases . . . . . . . . . . . . . . . . . . . 11 - 8. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 12 - 9. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 13 - 9.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 13 - 9.2. Self Describing Padding Check . . . . . . . . . . . . . . 14 - 9.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 16 - 9.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 17 - 9.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 17 - 9.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 18 - 9.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 18 - 9.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 18 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 + 1.1. Applicability: Heuristic Traffic Inspection and + Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 + 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 5 + 2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Description of Heuristics . . . . . . . . . . . . . . . . . . 7 + 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 10 + 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 11 + 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 12 + 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 13 + 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 14 + 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 16 + 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 17 + 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 17 + 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 18 + 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 18 + 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 18 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 21 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction The ESP (Encapsulated Security Payload [RFC4303]) protocol can be used with NULL encryption [RFC2410] to provide authentication and integrity protection, but not confidentiality. This offers similar @@ -120,33 +122,58 @@ can be implemented immediately, and not after a 5-10 year upgrade- and-deployment time frame. Even with protocol modification for end nodes, the intermediate devices will need heuristics until they can assume that those protocol modifications can be found from all the end devices. To make sure that any solution does not break in the future it would be best if such heuristics are documented, i.e. we need to publish an RFC for what to do now even when there might be a new protocol coming in the future that will solve the same problem better. -2. Requirements notation +1.1. Applicability: Heuristic Traffic Inspection and Wrapped ESP + + There are two ways to enable intermediate security devices to + distinguish between encrypted and unencrypted ESP traffic: + + - The heuristics approach has the intermediate node inspect the + unchanged ESP traffic, to determine with extremely high + probability whether or not the traffic stream is encrypted. + + - The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility], + in contrast, requires the ESP endpoints to be modified to support + the new protocol. WESP allows the intermediate node to + distinguish encrypted and unencrypted traffic deterministically, + using a simpler implementation for the intermediate node. + + Both approaches are being documented simultaneously by the IPsecME + Working Group, with WESP being put on Standards Track while the + heuristics approach is being published as an Informational RFC. + While endpoints are being modified to adopt WESP, we expect both + approaches to coexist for years, because the heuristic approach is + needed to inspect traffic where at least one of the endpoints has not + been modified. In other words, intermediate nodes are expected to + support both approaches in order to achieve good security and + performance during the transition period. + +1.2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. -3. Other Options +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 those. -3.1. AH +2.1. AH The most logical approach would use the already defined protocol which offers authentication and integrity protection, but not confidentiality, namely AH. AH traffic is clearly marked as not encrypted, and can always be inspected by intermediate devices. 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 @@ -161,34 +188,34 @@ support it. ESP-NULL has been defined to be mandatory to implement by Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) [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. -3.2. Mandating by Policy +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 if the machines are not under the same administrative domain. Also, such a solution might require some kind of centralized policy management to make sure everybody uses the same policy. -3.3. Modifying ESP +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 a 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. @@ -201,21 +228,21 @@ IPv6 vs NAT case. 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. -4. Description of Heuristics +3. Description of Heuristics The heuristics to detect ESP-NULL packets will only require changes to the 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 (and especially) end-nodes. In this document it is assumed that an affected intermediate node @@ -242,37 +269,37 @@ 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. -5. IPsec flows +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. As most (if not all) flows of interest to an intermediate device are unicast, it is safer to assume the receiving node also uses a source address, and the intermediate device should 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. When the intermediate device sees an new ESP IPsec flow, i.e. a flow of ESP packets where the source address, destination address, and SPI number forms a triplet which has not been cached, it will start the heuristics to detect whether this flow is ESP-NULL or not. These - heuristics appear in the Section 9. + heuristics appear in the Section 8. When the heuristics finish, they will label the flow as either encrypted (which tells that packets in this flow are encrypted, and cannot be ESP-NULL packets) or as ESP-NULL. This information, along with the ESP-NULL parameters detected by the heuristics, is stored to a flow cache, which will be used in the future when processing packets of the same flow. Both encrypted ESP and ESP-NULL flows are processed based on the local policy. In normal operation encrypted ESP flows are passed @@ -297,21 +324,21 @@ 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. -6. Deep Inspection Engine +5. Deep Inspection Engine A deep inspection engine running on an intermediate node usually checks deeply in to 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 the actual checks done indicated that packets should be dropped, i.e. the packet contained a virus, was a known attack, or something @@ -322,21 +349,21 @@ inspection engine can differentiate the garbage and failure cases, as garbage cases can be used to detect certain error cases (e.g. where the ESP-NULL parameters are incorrect, or the flow is really an encrypted ESP flow, not an ESP-NULL flow). If the deep inspection engine will only return failure for all garbage packets in addition to real failure cases, then a system implementing the ESP-NULL heuristics cannot recover from error situations quickly. -7. Special and Error Cases +6. Special and Error Cases There is a small probability that an encrypted ESP packet (which looks like contain completely random bytes) will have correct bytes in correct locations, such that heuristics will detect the packet as an ESP-NULL packet instead of detecting that it is encrypted ESP packet. The actual probabilities will be computed later in this document. Such a packet will not cause problems, as 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 @@ -360,71 +387,74 @@ 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 treated too quickly as indication of SA reuse. Often, single packets cause state-related errors that block otherwise normal packets from passing. -8. UDP encapsulation +7. UDP encapsulation The flow lookup code needs to detect UDP packets to or from port 4500 in addition to the ESP packets, and perform similar processing to - them after skipping the UDP header. As devices might be using - MOBIKE, that means that the flow cache should be shared between the - UDP encapsulated IPsec flows and non encapsulated IPsec flows. As + them after skipping the UDP header. Each unique port pair makes + separate IPsec flow, i.e. UDP encapsulated IPsec flows are + identified by the source and destination IP, source and destination + port number and SPI number. As devices might be using MOBIKE, that + means that the flow cache should be shared between the UDP + encapsulated IPsec flows and non encapsulated IPsec flows. As previously mentioned, differentiating between garbage and actual policy failures will help in proper detection immensely. Because the checks are also run for packets having source port 4500 in addition to those having destination port 4500, this might cause the checks to be run for non-ESP traffic too. The UDP encapsulation processing should also be avare of that. We cannot limit the checks for only UDP packets having destination port 4500, as return packets from the SGW going towards the NAT box do have source port 4500, and some other port as destination port. -9. Heuristic Checks +8. Heuristic Checks Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability that a random packet will pass the HMAC test. This yields a 99.999999999999999999999999998% probability that an end node will correctly detect a random packet as being invalid. This means that it should be enough for an intermediate device to check around 96 bits from the input packet. By comparing them against known values for the packet we get more or less same probability as an end node is using. This gives an upper limit of how many bits heuristics need to check - there is no point of checking much more than that many bits (since that same probability is acceptable for the end node). In most of the cases the intermediate device does not need that high probability, perhaps something around 32-64 bits is enough. IPsec's ESP has a well-understood packet layout, but its variable- length fields reduce the ability of pure algorithmic matching to one requiring heuristics and assigning probabilities. -9.1. ESP-NULL format +8.1. ESP-NULL format The ESP-NULL format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Payload Data* (variable) | + | Payload Data (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Value-ICV (variable) | ~ ~ | | @@ -436,36 +466,41 @@ the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL we also need to know the Integrity Check Value (ICV) field length and the Initialization Vector (IV) length. The currently defined ESP authentication algorithms have 5 different lengths for the ICV field. Most commonly used is 96 bits for AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, and AUTH_AES_CMAC_96 algorithms. After that comes 128 bit ICV lengths for AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC algorithms. 160, 192, and 256 - bit algorithms are used by AUTH_HMAC_SHA1_160, + bit field lengths are used by AUTH_HMAC_SHA1_160, AUTH_HMAC_SHA2_384_192, and AUTH_HMAC_SHA2_512_256 algorithms, respectively. In addition to the ICV length, there are also two possible values for IV lengths: zero bytes (default) and eight bytes (for AUTH_AES_*_GMAC). Detecting the IV length requires understanding the payload, i.e. the actual protocol data (meaning TCP, UDP, etc). This - is required to distinguish the optional random IV from the actual - protocol data. If the protocol (also known as the, "next header") of - the packet is something that heuristics doesn't have protocol - checking support, then detecting the IV length is impossible, thus - the heuristics cannot finish. In that case heuristics returns - "unsure" and requires further packets. + is required to distinguish the optional IV from the actual protocol + data. How well IV can be distinguished from the actual protocol data + depends how the IV is generated. If IV is generated using method + that generates random looking data (i.e. encrypted counter etc) then + disginguishing protocol data from IV is quite easy. If IV is counter + or similar non-random value, then there are bit more possibilities + for error. If the protocol (also known as the, "next header") of the + packet is something that heuristics doesn't have protocol checking + support, then detecting the IV length is impossible, thus the + heuristics cannot finish. In that case heuristics returns "unsure" + and requires further packets. -9.2. Self Describing Padding Check +8.2. Self Describing Padding Check Before obtaining the next header field, the ICV length must be measured. Five different ICV lengths leads to five 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. @@ -475,23 +510,25 @@ than what is currently inspected. For example, if a packet has a 96- bit ICV and implementation starts first checking for a 256-bit ICV, it is possible that the cleartext part of the payload contains valid looking bytes. If done in the other order, i.e. a packet having a 256-bit ICV and the implementation checks for a 96-bit ICV first, the inspected bytes are part of the longer ICV field, and should be indistinguishable from random noise. Each ESP packet always has between 0-255 bytes of padding, and payload, pad length, and next header are always right aligned within - a 4-byte boundary. 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. + a 4-byte boundary. Normally implementations use minimal amount of + padding, but 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 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%. In the cases where there is 0 bytes of padding, a random encrypted ESP packet has 1-(1-1/256)^5 == @@ -534,21 +571,21 @@ NULL with a known ICV length, but an unknown IV length. Fortunately, in unknown protocol cases the IV length does not matter, as the protocol is unknown to the heuristics, it will most likely be unknown by the deep inspection engine also. It is therefore important that heuristics should support at least those same protocols as the deep inspection engine does. Upon receipt of any inner next header number that is known by the heuristics (and deep inspection engine), the heuristics can detect the IV length properly. -9.3. Protocol Checks +8.3. Protocol Checks Generic protocol checking is much easier with pre-existing state. For example, when many TCP / UDP flows are established over one SA, a rekey with a new SA which needs heuristics. Then it is enough to just check that if the flow is already known by the deep inspection engine, it will give a strong leaning that the new SA is really ESP- NULL. The worst case scenario is when an end node starts up communcation, i.e. it does not have any previous flows through the device. @@ -567,21 +604,21 @@ The second type of check is for variable, but easy-to-parse values. For example, the 4-bit header length field of an inner IPv4 packet. It has a fixed value (5) as long as there are no inner IPv4 options. If the header-length has that specific value, the number of known "good" bits increases. If it has some other value, the known "good" 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. -9.3.1. TCP checks +8.3.1. TCP checks When the first TCP packet is feed 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 what other later packets might have. 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 used to reliably distinguished from random numbers apart from some well-known ports like 25/80/110/143). @@ -602,128 +639,128 @@ 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. The 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. -9.3.2. UDP checks +8.3.2. UDP checks UDP header has even more problems than the TCP header, as UDP has even less known data. The checksum has the same problem as the TCP checksum, due to NATs. The UDP length field might not match the overall packet length, as the sender is allowed to include TFC (traffic flow confidentiality, see section 2.7 of IP Encapsulating Security Payload document [RFC4303]) padding. With UDP packets similar multiple packet methods can be used as with TCP, as UDP protocols usually include several packets using same port numbers going from one end node to another, thus receiving multiple packets having a known pair of UDP port numbers is good indication that the heuristics have passed. Some UDP protocols also use identical source and destination port numbers, thus that is also a good check. -9.3.3. ICMP checks +8.3.3. ICMP checks As ICMP messages are usually sent as return packets for other packets, they are not very common packets to get as first packets for the SA, the ICMP Echo message being a noteworthy exception. ICMP ECHO has known type and code, identifier, and sequence number. The checksum, however, might be incorrect again because of NATs. For error ICMP messages the ICMP message contains part of the original IP packet inside, and then same rules which are used to detect IPv4/IPv6 tunnel checks can be used. -9.3.4. SCTP checks +8.3.4. SCTP checks SCTP [RFC4960] has a self-contained checksum, which is computed over the SCTP payload and is not affected by NATs unless the NAT is SCTP- aware. Even more than the TCP and UDP checksums, the SCTP checksum is expensive, and may be prohibitive even for deep-packet inspections. SCTP chunks can be inspected to see if their lengths are consistent across the total length of the IP datagram, so long as TFC padding is not present. - XXX TBA -- including possible chunk-specific checking. - -9.3.5. IPv4 and IPv6 Tunnel checks +8.3.5. IPv4 and IPv6 Tunnel checks In cases of tunneled traffic the packet inside contains a full IPv4 or IPv6 packet. Many fields are useable. 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 less usable fields, but the version number, packet length (modulo TFC confusion) and next-header all can be used by deep-packet inspection. -10. Security Considerations +9. Security Considerations The whole deep inspection for ESP-NULL flows only has the problem - that attacker can always bypass it by using encrypted ESP instead of - ESP-NULL unless that is not forbidden by policy. This means that in - the end the responsibility whether end node can bypass deep - inspection is for the policy enforcement of the both end nodes, i.e. - if a server allows encrypted connections also, then attacker who - wants to attack the server and wants to bypass 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, - but in that case ESP-NULL detection is easier, as all packets must be - ESP-NULL based on the policy, and further restriction can eliminate - ambiguities in ICV and IV sizes. + that attacker can always bypass it by using encrypted ESP (or some + other encryption or tunneling method) instead of ESP-NULL unless that + is not forbidden by policy. This means that in the end the + responsibility whether end node can bypass deep inspection is for the + policy enforcement of the both end nodes, i.e. if a server allows + encrypted connections also, then attacker who wants to attack the + server and wants to bypass 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, but in that case ESP-NULL + detection is easier, as all packets must be ESP-NULL based on the + policy, and further restriction can eliminate ambiguities in ICV and + IV sizes. -11. References +10. References -11.1. Normative References +10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. -11.2. Informative References +10.2. Informative References [I-D.bhatia-ipsecme-esp-null] Bhatia, M., "Identifying ESP-NULL Packets", draft-bhatia-ipsecme-esp-null-00 (work in progress), December 2008. [I-D.hoffman-esp-null-protocol] Hoffman, P. and D. McGrew, "An Authentication-only Profile for ESP with an IP Protocol Identifier", draft-hoffman-esp-null-protocol-00 (work in progress), August 2007. [I-D.ietf-ipsecme-traffic-visibility] - Grewal, K. and G. Montenegro, "Wrapped ESP for Traffic - Visibility", draft-ietf-ipsecme-traffic-visibility-01 - (work in progress), March 2009. + Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP + for Traffic Visibility", + draft-ietf-ipsecme-traffic-visibility-08 (work in + progress), September 2009. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", @@ -819,20 +856,22 @@ // if not calls heuristics. If IPsec flow is known // then it continues processing based on the policy. // Process ESP: * If packet is fragment * Do full reassembly before processing * If IP_total_len < IP_hdr_len + SPI_offset + 4 * Drop invalid packet * Load SPI from IP_hdr_len + SPI_offset * Initialize State to ESP + // In case this was UDP encapsulated ESP then use UDP_src_port and + // UDP_dst_port also when finding data from SPI cache. * Find IP_Src_IP + IP_Dst_IP + SPI from SPI cache * If SPI found * Load State, IV_len, ICV_len from cache * If SPI not found or State is unsure * Call Autodetect ESP parameters (drop to slowpath) * If State is ESP * Continue Non-ESP-NULL processing * Goto Check ESP-NULL packet //////////////////////////////////////////////////////////// @@ -861,21 +900,21 @@ //////////////////////////////////////////////////////////// // This pseudocode uses following variables: // // SPI_offset, IV_len, ICV_len, State, SPI, // IP_total_len, IP_hdr_len, IP_Src_IP, IP_Dst_IP // as defined in fastpath pseudocode. // // Stored_Check_Bits:Number of bits we have successfully // checked to contain acceptable values // in the actual payload data. This value - // is stored / retreaved from SPI cache. + // is stored / retrieved from SPI cache. // // Check_Bits: Number of bits we have successfully // checked to contain acceptable values // in the actual payload data. This value // is updated during the packet // verification. // // Last_Packet_Data: Contains selected pieces from the // last packet. This is used to compare // certain fields of this packet to @@ -1174,20 +1211,23 @@ // for a suitable amount of bits. If all checks pass, then // we just return Success, and the upper layer will then // later check if we have enough bits checked already. * Load Protocol From IP_total_len - Test_ICV_len - 1 * If Protocol TCP * Goto Verify TCP * If Protocol UDP * Goto Verify UDP // Other protocols can be added here as needed, most likely same // protocols as deep inspection does + // Tunnel mode checks 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