draft-ietf-ipsecme-esp-null-heuristics-04.txt   draft-ietf-ipsecme-esp-null-heuristics-05.txt 
IP Security Maintenance and T. Kivinen IP Security Maintenance and T. Kivinen
Extensions (ipsecme) Safenet, Inc. Extensions (ipsecme) Safenet, Inc.
Internet-Draft D. McDonald Internet-Draft D. McDonald
Intended status: Informational Sun Microsystems, Inc. Intended status: Informational Sun Microsystems, Inc.
Expires: July 31, 2010 January 27, 2010 Expires: August 1, 2010 January 28, 2010
Heuristics for Detecting ESP-NULL packets Heuristics for Detecting ESP-NULL packets
draft-ietf-ipsecme-esp-null-heuristics-04.txt draft-ietf-ipsecme-esp-null-heuristics-05.txt
Abstract Abstract
This document describes a set of heuristics for distinguishing IPsec This document describes a set of heuristics for distinguishing IPsec
ESP-NULL (Encapsulating Security Payload without encryption) packets ESP-NULL (Encapsulating Security Payload without encryption) packets
from encrypted ESP packets. These heuristics can be used on from encrypted ESP packets. These heuristics can be used on
intermediate devices, like traffic analyzers, and deep inspection intermediate devices, like traffic analyzers, and deep inspection
engines, to quickly decide whether given packet flow is interesting engines, to quickly decide whether given packet flow is interesting
or not. Use of these heuristics does not require any changes made on or not. Use of these heuristics does not require any changes made on
existing RFC4303 compliant IPsec hosts. existing RFC4303 compliant IPsec hosts.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 31, 2010. This Internet-Draft will expire on August 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 36 skipping to change at page 6, line 36
necessary. necessary.
The another problem is that in the new IPsec Architecture [RFC4301] The another problem is that in the new IPsec Architecture [RFC4301]
the support for AH is now optional, meaning not all implementations the support for AH is now optional, meaning not all implementations
support it. ESP-NULL has been defined to be mandatory to implement support it. ESP-NULL has been defined to be mandatory to implement
by the Cryptographic Algorithm Implementation Requirements for by the Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) document [RFC4835]. Encapsulating Security Payload (ESP) document [RFC4835].
AH has also quite complex processing rules compared to ESP when AH has also quite complex processing rules compared to ESP when
calculating the ICV, including things like zeroing out mutable calculating the ICV, including things like zeroing out mutable
fields. As AH is not as widely used than ESP, the AH support is not fields, also as AH is not as widely used than ESP, the AH support is
as well tested in the interoperability events, meaning it might have not as well tested in the interoperability events.
more bugs than ESP implementations.
2.2. Mandating by Policy 2.2. Mandating by Policy
Another easy way to solve this problem is to mandate the use of ESP- Another easy way to solve this problem is to mandate the use of ESP-
NULL with common parameters within an entire organization. This NULL with common parameters within an entire organization. This
either removes the need for heuristics (if no ESP encrypted traffic either removes the need for heuristics (if no ESP encrypted traffic
is allowed at all) or simplifies them considerably (only one set of is allowed at all) or simplifies them considerably (only one set of
parameters needs to be inspected, e.g. everybody in the organization 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 who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity
algorithm). This does not work unless one of a pair of communicating algorithm). This does not work unless one of a pair of communicating
skipping to change at page 7, line 21 skipping to change at page 7, line 20
encryption. The following methods have been discussed: adding an IP- encryption. The following methods have been discussed: adding an IP-
option, adding a new IP-protocol number plus an extra header option, adding a new IP-protocol number plus an extra header
[I-D.ietf-ipsecme-traffic-visibility], adding new IP-protocol numbers [I-D.ietf-ipsecme-traffic-visibility], adding new IP-protocol numbers
which tell the ESP-NULL parameters [I-D.hoffman-esp-null-protocol], 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], reserving an SPI range for ESP-NULL [I-D.bhatia-ipsecme-esp-null],
and using UDP encapsulation with a different format and ports. and using UDP encapsulation with a different format and ports.
All of the aforementioned drafts require modification to ESP, which All of the aforementioned drafts require modification to ESP, which
requires that all end nodes need to be modified before intermediate requires that all end nodes need to be modified before intermediate
devices can assume that this new ESP format is in use. Updating end 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 nodes will require lots of time. An example of slow end-node
endpoint migration vs. intermediate migration can be seen from the deployment is IKEv2. Considering an implementation that requires
deployment of both IPv6 and NAT. IPv6 required updating all of the both IKEv2 and a new ESP format, it would take several years,
end nodes (and routers too) before it could be effectively used. possibly as long as a decade, before widespread deployment.
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 3. Description of Heuristics
The heuristics to detect ESP-NULL packets will only require changes The heuristics to detect ESP-NULL packets will only require changes
to 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 operations which require detecting ESP-NULL. As those nodes require
changes regardless of any ESP-NULL method, updating intermediate changes regardless of any ESP-NULL method, updating intermediate
nodes is unavoidable. Heuristics do not require updating or nodes is unavoidable. Heuristics do not require updating or
modifying any other devices on the rest of the network, including modifying any other devices on the rest of the network, including
(especially) end-nodes. (especially) end-nodes.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
the heuristics, then detecting the IV length is impossible, thus the the heuristics, then detecting the IV length is impossible, thus the
heuristics cannot finish. In that case, the heuristics return heuristics cannot finish. In that case, the heuristics return
"unsure" and requires further packets. "unsure" and requires further packets.
This document does not cover RSA authentication in ESP ([RFC4359]), This document does not cover RSA authentication in ESP ([RFC4359]),
as it is considered being beyond the scope of this document. as it is considered being beyond the scope of this document.
8.2. Self Describing Padding Check 8.2. Self Describing Padding Check
Before obtaining the next header field, the ICV length must be Before obtaining the next header field, the ICV length must be
measured. Five different ICV lengths lead to five possible places measured. Four different ICV lengths lead to four possible places
for the pad length and padding. Implementations must be careful when for the pad length and padding. Implementations must be careful when
trying larger sizes of ICV such that the inspected bytes do not 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 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 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 256-bit ICVs will inspect sequence number or SPI data if the packet
actually contains a 96-bit or 128-bit ICV. actually contains a 96-bit or 128-bit ICV.
ICV lengths should always be checked from shortest to longest. It is ICV lengths should always be checked from shortest to longest. It is
much more likely to obtain valid-looking padding bytes in the 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 cleartext part of the payload than from the ICV field of a longer ICV
skipping to change at page 16, line 38 skipping to change at page 16, line 38
payload, pad length, and next header are always right aligned within payload, pad length, and next header are always right aligned within
a 4-byte boundary. Normally implementations use minimal amount of a 4-byte boundary. Normally implementations use minimal amount of
padding, but the heuristics method would be even more reliable if padding, but the heuristics method would be even more reliable if
some extra padding is added. The actual padding data has bytes 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 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. 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 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 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 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 test -- a sequence of N N in any of those four locations. Given four
two-byte locations (assuming the packet size allows all five possible two-byte locations (assuming the packet size allows all four possible
ICV lengths), the upper-bound probability of finding a random ICV lengths), the upper-bound probability of finding a random
encrypted packet that exhibits non-zero length ESP-NULL properties encrypted packet that exhibits non-zero length ESP-NULL properties
is: is:
1 - (1 - 255 / 65536) ^ 5 == 0.019 == 1.9% 1 - (1 - 255 / 65536) ^ 4 == 0.015 == 1.5%
In the cases where there is 0 bytes of padding, a random encrypted In the cases where there is 0 bytes of padding, a random encrypted
ESP packet has: ESP packet has:
1 - (1 - 1 / 256) ^ 5 == 0.019 == 1.9%. 1 - (1 - 1 / 256) ^ 4 == 0.016 == 1.6%.
Together, both cases yields a 3.8% upper-bound chance of Together, both cases yields a 3.1% upper-bound chance of
misclassifying an encrypted packet as an ESP-NULL packet. misclassifying an encrypted packet as an ESP-NULL packet.
In the matched bytes case, further inspection (counting the pad bytes In the matched bytes case, further inspection (counting the pad bytes
backward and downward from the pad-length match) can reduce the backward and downward from the pad-length match) can reduce the
number of misclassified packets further. A padding length of 255 number of misclassified packets further. A padding length of 255
means a specific 256^254 sequence of bytes must occur. This means a specific 256^254 sequence of bytes must occur. This
virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding. virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding.
Every one of the 255 pairs for padding length N has only a 1 / 256^N Every one of the 255 pairs for padding length N has only a 1 / 256^N
probability of being correct ESP-NULL padding. This shrinks the probability of being correct ESP-NULL padding. This shrinks the
aforementioned 1.9% of matched-pairs to virtually nothing. aforementioned 1.5% of matched-pairs to virtually nothing.
At this point a maximum of 2% of packets remain, so the next header At this point a maximum of 1.6% of packets remain, so the next header
number is inspected. If the next header number is known (and number is inspected. If the next header number is known (and
supported) then the packet can be inspected based on the next header 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 number. If the next header number is unknown (i.e. not any of those
with protocol checking support) the packet is marked "unsure", with protocol checking support) the packet is marked "unsure",
because there is no way to detect the IV length without inspecting because there is no way to detect the IV length without inspecting
the inner protocol payload. the inner protocol payload.
There are six different next header fields which are in common use 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)), (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 and if IPv6 is in heavy use, that number increases to nine (Fragment
skipping to change at page 18, line 47 skipping to change at page 18, line 47
bit count stays the same. A local policy might include reaching a 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 bit count that is over a threshold (for example 96 bits), causing a
packet to be marked as valid. packet to be marked as valid.
8.3.1. TCP checks 8.3.1. TCP checks
When the first TCP packet is fed to the heuristics, it is most likely 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 going to be the SYN packet of the new connection, thus it will have
less useful information than other later packets might have. The less useful information than other later packets might have. The
best valid packet checks include: checking that header length and best valid packet checks include: checking that header length and
reserved and other bits have valid values; checking source and flags have valid values; checking source and destination port
destination port numbers, which in some cases can be used for numbers, which in some cases can be used for heuristics (but in
heuristics (but in general they cannot be reliably distinguished from general they cannot be reliably distinguished from random numbers
random numbers apart from some well-known ports like 25/80/110/143). apart from some well-known ports like 25/80/110/143).
The most obvious field, TCP checksum, might not be usable, as it is The most obvious field, TCP checksum, might not be usable, as it is
possible that the packet has already transited a NAT box, thus the IP 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. 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 If the checksum is correct that can again be used to increase the
valid bit count, but verifying checksums is a costly operation, thus valid bit count, but verifying checksums is a costly operation, thus
skipping that check might be best unless there is hardware to help skipping that check might be best unless there is hardware to help
the calculation. Window size, urgent pointer, sequence number, and the calculation. Window size, urgent pointer, sequence number, and
acknowledgement numbers can be used, but there is not one specific acknowledgement numbers can be used, but there is not one specific
known value for them. known value for them.
skipping to change at page 34, line 39 skipping to change at page 34, line 39
// protocols as deep inspection does // protocols as deep inspection does
// Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for
// IPv6) is also left out from here to make the document shorter. // IPv6) is also left out from here to make the document shorter.
* Return Failure * Return Failure
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Verify TCP protocol headers // Verify TCP protocol headers
// //
Verify TCP: Verify TCP:
// First we check things that must be set correctly. // First we check things that must be set correctly.
* Check TCP.reserved_bits are non-zero
* Return Failure
* If TCP.Data_Offset field < 5 * If TCP.Data_Offset field < 5
// TCP head length too small // TCP head length too small
* Return Failure * Return Failure
// After that we start to check things that does not // After that we start to check things that does not
// have one definitive value, but can have multiple possible // have one definitive value, but can have multiple possible
// valid values // valid values
* If TCP.ACK bit is not set, then check * If TCP.ACK bit is not set, then check
that TCP.Acknowledgment_number field contains 0 that TCP.Acknowledgment_number field contains 0
// If ACK bit is not set then the acknowledgment // If ACK bit is not set then the acknowledgment
// field usually contains 0, but I do not think // field usually contains 0, but I do not think
 End of changes. 14 change blocks. 
31 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/