--- 1/draft-ietf-ipsecme-esp-null-heuristics-02.txt 2009-11-30 17:12:39.000000000 +0100 +++ 2/draft-ietf-ipsecme-esp-null-heuristics-03.txt 2009-11-30 17:12:40.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: May 27, 2010 November 23, 2009 +Expires: June 3, 2010 November 30, 2009 Heuristics for Detecting ESP-NULL packets - draft-ietf-ipsecme-esp-null-heuristics-02.txt + draft-ietf-ipsecme-esp-null-heuristics-03.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,42 +22,42 @@ 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 May 27, 2010. + This Internet-Draft will expire on June 3, 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 and restrictions with respect to this document. Abstract - This document describes an algorithm for distinguishing IPsec ESP- - NULL (Encapsulating Security Payload without encryption) packets from - encrypted ESP packets. The algorithm 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 this algorithm does not require any changes made on existing - RFC4303 compliant IPsec hosts. + 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability: Heuristic Traffic Inspection and Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 6 @@ -67,135 +67,139 @@ 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 . . . . . . . . . . . . . . 15 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 17 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 19 - 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 19 + 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 - Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 23 - A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 23 - A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 + Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 24 + A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 24 + A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction The ESP (Encapsulating Security Payload [RFC4303]) protocol can be - used with NULL encryption [RFC2410] to provide authentication and - integrity protection, but not confidentiality and optionally replay - detection. This offers similar properties to IPsec's AH - (Authentication Header [RFC4302]). One reason to use ESP-NULL - instead of AH is that AH cannot be used if there are NATs (Network - Address Translation devices) on the path. With AH it would be easy - to detect packets which have only authentication and integrity - protection, as AH has its own protocol number and deterministic - packet length. With ESP-NULL such detection is nondeterministic, in - spite of the base ESP packet format being fixed. + used with NULL encryption [RFC2410] to provide authentication, + integrity protection, and optionally replay detection; but not + confidentiality. NULL encryption with ESP (referred to as ESP-NULL) + offers similar properties to IPsec's AH (Authentication Header + [RFC4302]). One reason to use ESP-NULL instead of AH is that AH + cannot be used if there are NATs (Network Address Translation + devices) on the path. With AH it would be easy to detect packets + which have only authentication and integrity protection, as AH has + its own protocol number and deterministic packet length. With ESP- + NULL such detection is nondeterministic, in spite of the base ESP + packet format being fixed. In some cases intermediate devices would like to detect ESP-NULL packets so they could perform deep inspection or enforce access control. This kind of deep inspection includes virus detection, spam filtering, and intrusion detection. As end nodes might be able to bypass those checks by using encrypted ESP instead of ESP-NULL, these kinds of scenarios also require very specific policies to forbid such circumvention. These sorts of policy requirements usually mean that the whole - network needs to be controlled, i.e. under the same adminstrative + network needs to be controlled, i.e. under the same administrative domain. Such setups are usually limited to inside the network of one enterprise or organization, and encryption is not used as the network is considered safe enough from eavesdroppers. Because the traffic inspected is usually host to host traffic inside one organization, that usually means transport mode IPsec is used. Note, that most of the current uses of the IPsec are not host to host traffic inside one organization, but for the intended use cases for the heuristics this will most likely be the case. Also tunnel mode case is much easier to solve than transport mode as it is much easier to detect the IP header inside the ESP-NULL packet. It should also be noted that even if new protocol modifications for ESP support easier detection of ESP-NULL in the future, this document will aid in transition of older end-systems. That way, a solution 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 + future it would be best if such heuristics are documented - i.e. + publishing 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. 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: o 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. o 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 + While endpoints are being modified to adopt WESP, both approaches + will likely 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. Terminology This document uses following terminology: Flow - TCP/UDP or IPsec flow is a stream of packets part of the same TCP/ - UDP or IPsec stream, i.e. TCP flow is a stream of packets having - same 5 tuple (source and destination ip and port, and TCP - protocol). + A TCP/UDP or IPsec flow is a stream of packets part of the same + TCP/UDP or IPsec stream, i.e. TCP or UDP flow is a stream of + packets having same 5 tuple (source and destination IP and port, + and TCP/UDP protocol). Note, that this kind of flow is also + called microflow in some documents. Flow Cache - Deep inspection engines and similar use cache of flows going - through the device, and that cache keeps state of all flows going - through the device. + 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 - IPsec flow stream of packets having same source IP, destination - IP, protocol (ESP/AH) and SPI. Strictly speaking 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. + 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. 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. + this section will briefly discuss them. 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 @@ -203,73 +207,75 @@ 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 support it. ESP-NULL has been defined to be mandatory to implement - by Cryptographic Algorithm Implementation Requirements for - Encapsulating Security Payload (ESP) [RFC4835]. + 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. 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. + algorithm). This does not 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. 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. + [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 - 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. + 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. 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 + 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. In this document it is assumed that an affected intermediate node will act as a stateful interception device, meaning it will keep state of the flows - where flows are defined by the ESP SPI and IP addresses forming an IPsec SA - going through it. The heuristics can @@ -279,45 +285,54 @@ 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 packet, thus causing completely random packet data to be deeply + 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. 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 + have NAPT applied to it, and so there is already a 5-tuple state in + 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. 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. + 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. When the intermediate device sees a new ESP IPsec flow, i.e. a new 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 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 @@ -376,31 +391,31 @@ 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. 6. Special and Error Cases There is a small probability that an encrypted ESP packet (which - looks like contain completely random bytes) will have plausible bytes - in expected 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 - 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. + looks like it contains completely random bytes) will have plausible + bytes in expected 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 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 @@ -415,51 +430,53 @@ 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. 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. Each unique port pair - constitutes a 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 ([RFC4555]), 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. + them after skipping the UDP header. Port-translation by NAT often + rewrites what was originally 4500 into a different value, which means + each unique port pair constitutes a 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 ([RFC4555]), that also 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 aware 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. + Because the checks are run for packets having just source port 4500 + or packets having just destination port 4500, this might cause checks + to be run for non-ESP traffic too. Some traffic may randomly use + port 4500 for other reasons, especially if a port-translating NAT is + involved. The UDP encapsulation processing should also be aware of + that possibility. 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 the 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. + for the packet, a deep inspection engine gains more or less the 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. 8.1. ESP-NULL format The ESP-NULL format is as follows: 0 1 2 3 @@ -479,30 +496,30 @@ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - The output of the heuristics should provide us information whether - 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 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 5 different lengths for the ICV field. Most commonly used is 96 bits, and after that comes 128 bit ICV lengths. - Different ICV lengths for different algorithsm: + 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_MD5_128 128 AUTH_HMAC_SHA2_256_128 128 AUTH_AES_128_GMAC 128 @@ -513,33 +530,34 @@ AUTH_HMAC_SHA2_512_256 256 Figure 2 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 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 + depends how the IV is generated. If IV is generated using a 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 one that is not supported by the heuristics, then detecting - the IV length is impossible, thus the heuristics cannot finish. In - that case heuristics returns "unsure" and requires further packets. + distinguishing protocol data from IV is quite easy. If an IV is a + counter or similar non-random value, then there are more + possibilities for error. If the protocol (also known as the, "next + header") of the packet is one that is not supported by 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. 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 + measured. Five different ICV lengths lead 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. 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 @@ -547,24 +565,24 @@ bit ICV and the 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. 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. + 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 ICV lengths), the upper-bound probability of finding a random encrypted packet that exhibits non-zero length ESP-NULL properties is: @@ -593,57 +610,57 @@ 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 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". + 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". An intermediate node's policy, however, can aid in detecting an ESP- NULL flow even when the protocol is not a common-case one. By counting how many "unsure" returns obtained via heuristics, and after the receipt of a consistent, but unknown, next-header number in same location (i.e. likely with the same ICV length), the node can conclude that the flow has high probability of being ESP-NULL (since it is unlikely that so many packets would pass the integrity check at the destination unless they are legitimate). The flow can be classified as ESP-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 + Fortunately, in unknown protocol cases the IV length does not matter. + If 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. 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 IPsec SA, a rekey produces a new SA which needs heuristics to detect its 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 leaning that the new SA is really ESP-NULL. + 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 communcation, + 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 bringup 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. @@ -657,49 +674,49 @@ 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. 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. 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). + 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). The most obvious field, TCP checksum, might not be usable, as it is - possible that the packet has already transitted 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 + 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. 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. - 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. + 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 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. @@ -709,94 +726,100 @@ 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. 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. + the SA, the ICMP ECHO_REQUEST message being a noteworthy exception. + ICMP ECHO_REQUEST has a 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 the same rules which are used to + For ICMP error messages, the ICMP message contains part of the + original IP packet inside. Then the same rules which are used to detect IPv4/IPv6 tunnel checks can be used. 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. 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 + 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. 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 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, 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. + 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 enterprice can have increased risk of sending confidential + the enterprise can have increased risk of sending confidential information where eavesdroppers can see it. -10. References +10. IANA Considerations -10.1. Normative References + No IANA assignments are needed. + +11. References + +11.1. Normative References [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. -10.2. Informative References +11.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), @@ -1062,21 +1085,21 @@ * Continue Check non-ESP-NULL packet //////////////////////////////////////////////////////////// // Store unsure flow status to IPsec flow cache. // Here we also store the Check_Bits. // Store unsure SPI cache info: * Store State, IV_len, ICV_len, Stored_Check_Bits to SPI cache using IP_Src_IP + IP_Dst_IP + SPI as key - * Contine Check unknown packet + * Continue Check unknown packet //////////////////////////////////////////////////////////// // Verify this packet against the previously selected // ICV_len and IV_len values. This will either // fail (and set state to ESP to mark we do not yet // know what type of flow this is), or it will // increment Check_Bits. // Verify next packet: // We already have IV_len, ICV_len and State loaded