--- 1/draft-ietf-ipsecme-esp-null-heuristics-03.txt 2010-01-27 16:11:24.000000000 +0100 +++ 2/draft-ietf-ipsecme-esp-null-heuristics-04.txt 2010-01-27 16:11:24.000000000 +0100 @@ -1,19 +1,29 @@ IP Security Maintenance and T. Kivinen Extensions (ipsecme) Safenet, Inc. Internet-Draft D. McDonald Intended status: Informational Sun Microsystems, Inc. -Expires: June 3, 2010 November 30, 2009 +Expires: July 31, 2010 January 27, 2010 Heuristics for Detecting ESP-NULL packets - draft-ietf-ipsecme-esp-null-heuristics-03.txt + draft-ietf-ipsecme-esp-null-heuristics-04.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. 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,76 +32,70 @@ 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 June 3, 2010. + This Internet-Draft will expire on July 31, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + 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 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 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. + 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. 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 2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 7 3. Description of Heuristics . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . 15 - 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 17 + 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.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 . . . . . . . . . . . . . . . . . 24 - A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 24 - A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 + Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25 + A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25 + A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction The ESP (Encapsulating Security Payload [RFC4303]) protocol can be 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 @@ -270,24 +274,24 @@ The heuristics to detect ESP-NULL packets will only require changes to those intermediate devices which do deep inspection or other operations which require detecting ESP-NULL. As those nodes require changes regardless of any ESP-NULL method, updating intermediate nodes is unavoidable. Heuristics do not require updating or modifying any other devices on the rest of the network, including (especially) end-nodes. 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 - also be used without storing any state, but performance will be worse - in that case, as heuristic checks will need to be done for each + state of the IPsec flows - where flows are defined by the ESP SPI and + IP addresses forming an IPsec SA - going through it. The heuristics + can also be used without storing any state, but performance will be + worse in that case, as heuristic checks will need to be done for each packet, not only once per flow. This will also affect the reliability of the heuristics. Generally, an intermediate node runs heuristics only for the first few packets of the new flow (i.e. the new IPsec SA). After those few packets, the node detects parameters of the IPsec flow, it skips detection heuristics, and it can perform direct packet-inspecting action based on its own policy. Once detected, ESP-NULL packets will never be detected as encrypted ESP packets, meaning that valid ESP- NULL packets will never bypass the deep inspection. The only failure @@ -501,59 +505,63 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 5 different + 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. 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 - AUTH_AES_192_GMAC 128 - AUTH_AES_256_GMAC 128 - AUTH_HMAC_SHA1_160 160 AUTH_HMAC_SHA2_384_192 192 AUTH_HMAC_SHA2_512_256 256 Figure 2 + In addition to the ESP authentication algorithms listed above, there + is also encryption algorithm ENCR_NULL_AUTH_AES_GMAC which does not + provide confidentiality but provides authentication, just like ESP- + NULL does. This algorithm has ICV Length of 128 bits, and it also + requires eight bytes of IV. + 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 a method - that generates random looking data (i.e. encrypted counter etc) then - 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 + ENCR_NULL_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 a method that generates random looking data (i.e. + encrypted counter etc) then 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. + This document does not cover RSA authentication in ESP ([RFC4359]), + as it is considered being beyond the scope of this document. + 8.2. Self Describing Padding Check Before obtaining the next header field, the ICV length must be measured. Five different ICV lengths lead to five possible places 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. @@ -821,27 +829,31 @@ [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., Montenegro, G., and M. Bhatia, "Wrapped ESP for Traffic Visibility", - draft-ietf-ipsecme-traffic-visibility-10 (work in - progress), November 2009. + draft-ietf-ipsecme-traffic-visibility-12 (work in + progress), January 2010. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. + [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within + Encapsulating Security Payload (ESP) and Authentication + Header (AH)", RFC 4359, January 2006. + [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [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", RFC 4960, September 2007. @@ -895,20 +907,24 @@ //////////////////////////////////////////////////////////// // This is the main processing code for the packet // This will check if the packet requires ESP processing, // Process packet: * If IP protocol is ESP * Set SPI_offset to 0 bytes * Goto Process ESP * If IP protocol is UDP * Goto Process UDP + * If IP protocol is WESP + // For information about WESP processing see WESP + // specification. + * Continue WESP processing * Continue Non-ESP processing //////////////////////////////////////////////////////////// // This code is run for UDP packets, and it checks if the // packet is UDP encapsulated UDP packet, or UDP // encapsulated IKE packet, or keepalive packet. // Process UDP: // Reassembly is not mandatory here, we could // do reassembly also only after detecting the @@ -918,36 +934,41 @@ // for checking if the UDP header is in this // packet or not. // Reassembly is to simplify things * If packet is fragment * Do full reassembly before processing * If UDP_src_port != 4500 and UDP_dst_port != 4500 * Continue Non-ESP processing * Set SPI_offset to 8 bytes * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000 * Continue Non-ESP processing (pass IKE-packet) + * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000002 + * Continue WESP processing * If UDP_len == 1 and first byte is 0xff * Continue Non-ESP processing (pass NAT-Keepalive Packet) * Goto Process ESP //////////////////////////////////////////////////////////// // This code is run for ESP packets (or UDP encapsulated ESP // packets). This checks if IPsec flow is known, and // 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 - + // If this packet was UDP encapsulated ESP packet then + // this might be valid UDP packet which might + // be passed or dropped depending on policy + * Continue normal packet processing * 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 @@ -956,21 +977,26 @@ //////////////////////////////////////////////////////////// // This code is run for ESP-NULL packets, and this // finds out the data required for deep inspection // engine (protocol number, and offset to data) // and calls the deep inspection engine. // Check ESP-NULL packet: * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) - * Drop invalid packet + // This packet was detected earlier as being part of + // ESP-NULL flow, so this means that either ESP-NULL + // was replaced with other flow or this is invalid packet. + // Either drop or pass the packet, or restart + // heuristics based on the policy + * Continue packet processing * Load Protocol from IP_total_len - ICV_len - 1 * Set Protocol_off to IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no) * Do normal deep inspection on packet. Figure 3 A.2. Slowpath The following example pseudocode show the actual heuristics part of @@ -1042,23 +1067,20 @@ // was changed to ESP, we check other // ICV/IV_len values, i.e. fall through // ICV lengths are tested in order of ICV lengths, // from shortest to longest. * Call Try standard algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info * Call Try 128bit algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info - * Call Try 160bit algorithms - * If State is ESP-NULL - * Goto Store ESP-NULL SPI cache info * Call Try 192bit algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info * Call Try 256bit algorithms * If State is ESP-NULL * Goto Store ESP-NULL SPI cache info // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from // this document. // If any of those test above set state to unsure // we mark IPsec flow as unsure. @@ -1152,30 +1175,30 @@ // AUTH_AES_CMAC_96 * Set Test_ICV_len to 12, Test_IV_len to 0 * Goto Check packet //////////////////////////////////////////////////////////// // Check for 128-bit algorithms, this is only one that // can have IV, so we need to check different IV_len values // here too. // Try 128bit algorithms: - // AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 - // AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC + // AUTH_HMAC_SHA2_256_128, ENCR_NULL_AUTH_AES_GMAC * Set Test_ICV_len to 16, Test_IV_len to 0 * If IP_total_len < IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) * Return * Call Verify padding * If verify padding returned Failure * Return + * Initialize Check_Bits to 0 * Call Verify packet * If verify packet returned Failure * Goto Try GMAC // Ok, packet seemed ok, but go now and check if we have enough // data bits so we can assume it is ESP-NULL * Goto Check if done for unsure //////////////////////////////////////////////////////////// // Check for GMAC macs, i.e. macs having 8 byte IV. @@ -1174,44 +1197,36 @@ * If verify packet returned Failure * Goto Try GMAC // Ok, packet seemed ok, but go now and check if we have enough // data bits so we can assume it is ESP-NULL * Goto Check if done for unsure //////////////////////////////////////////////////////////// // Check for GMAC macs, i.e. macs having 8 byte IV. // Try GMAC: - // AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC + // ENCR_NULL_AUTH_AES_GMAC * Set Test_IV_len to 8 * If IP_total_len < IP_hdr_len + SPI_offset + Test_IV_len + Test_ICV_len + 4 (spi) + 4 (seq no) + 4 (protocol + padding) * Return * Initialize Check_Bits to 0 * Call Verify packet * If verify packet returned Failure // Guess was wrong, continue * Return // Ok, packet seemed ok, but go now and check if we have enough // data bits so we can assume it is ESP-NULL * Goto Check if done for unsure //////////////////////////////////////////////////////////// - // Check for 160-bit algorithms. - // - Try 160bit algorithms: - // AUTH_HMAC_SHA1_160 - * Set Test_ICV_len to 20, Test_IV_len to 0 - * Goto Check packet - - //////////////////////////////////////////////////////////// // Check for 192-bit algorithms. // Try 192bit algorithms: // AUTH_HMAC_SHA2_384_192 * Set Test_ICV_len to 24, Test_IV_len to 0 * Goto Check packet //////////////////////////////////////////////////////////// // Check for 256-bit algorithms. //