draft-ietf-ipsecme-esp-null-heuristics-05.txt   draft-ietf-ipsecme-esp-null-heuristics-06.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: August 1, 2010 January 28, 2010 Expires: August 30, 2010 February 26, 2010
Heuristics for Detecting ESP-NULL packets Heuristics for Detecting ESP-NULL packets
draft-ietf-ipsecme-esp-null-heuristics-05.txt draft-ietf-ipsecme-esp-null-heuristics-06.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 August 1, 2010. This Internet-Draft will expire on August 30, 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 2, line 36 skipping to change at page 2, line 36
4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11
6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12
7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13
8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14
8.2. Self Describing Padding Check . . . . . . . . . . . . . . 16 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 16
8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 18 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 18
8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18
8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19
8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 19 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 20
8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20
8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25
A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 5, line 10 skipping to change at page 5, line 10
Deep inspection engines and similar devices use a cache of flows 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, and that cache keeps state of all flows
going through the device. going through the device.
IPsec Flow IPsec Flow
An IPsec flow is a stream of packets sharing the same source IP, An IPsec flow is a stream of packets sharing the same source IP,
destination IP, protocol (ESP/AH) and SPI. Strictly speaking, the destination IP, protocol (ESP/AH) and SPI. Strictly speaking, the
source IP does not need to be as part of the flow identification, source IP does not need to be as part of the flow identification,
but as it can be there depending on the receiving implementation but it can be. For this reason, it is safer to assume that the
it is safer to assume it is always part of the flow source IP is always part of the flow identification.
identification.
2. Other Options 2. Other Options
This document will discuss the heuristic approach of detecting ESP- This document will discuss the heuristic approach of detecting ESP-
NULL packets. There are some other options which can be used, and NULL packets. There are some other options which can be used, and
this section will briefly discuss them. this section will briefly discuss them.
2.1. AH 2.1. AH
The most logical approach would use the already defined protocol The most logical approach would use the already defined protocol
skipping to change at page 6, line 28 skipping to change at page 6, line 28
Using AH has two problems. First is that, as it also protects the IP 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 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 not work if there is NAT on the path between end nodes. In some
environments this might not be a problem, but some environments environments this might not be a problem, but some environments
include heavy use of NATs even inside the internal network of the include heavy use of NATs even inside the internal network of the
enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could enterprise or organization. NAT-Traversal (NAT-T, [RFC3948]) could
be extended to support AH also, and the early versions of the NAT-T 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 proposals did include that, but it was left out as it was not seen as
necessary. necessary.
The another problem is that in the new IPsec Architecture [RFC4301] Another problem is that in the new IPsec Architecture [RFC4301] the
the support for AH is now optional, meaning not all implementations 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, also as AH is not as widely used than ESP, the AH support is fields. Also as AH is not as widely used than ESP, the AH support is
not as well tested in the interoperability events. not as well tested in the interoperability events.
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 work unless one of a pair of communicating
machines is not under the same administrative domain as the deep machines is not under the same administrative domain as the deep
inspection engine. (IPsec Security Associations must be satisfactory inspection engine. (IPsec Security Associations must be satisfactory
to all communicating parties, so only one communicating peer needs to to all communicating parties, so only one communicating peer needs to
have a sufficiently narrow policy.) Also, such a solution might have a sufficiently narrow policy.) Also, such a solution might
require some kind of centralized policy management to make sure require some kind of centralized policy management to make sure
everybody in an administrative domain uses the same policy. everybody in an administrative domain uses the same policy, and that
changes to that single policy can be coordinated throughout the
administrative domain.
2.3. Modifying ESP 2.3. Modifying ESP
Several internet drafts discuss ways of modifying ESP to offer Several internet drafts discuss ways of modifying ESP to offer
intermediate devices information about an ESP packet's use of NULL intermediate devices information about an ESP packet's use of NULL
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],
skipping to change at page 8, line 46 skipping to change at page 8, line 46
intermediate node. intermediate node.
For hardware implementations all the flow lookup based on the ESP For hardware implementations all the flow lookup based on the ESP
next header number (50), source address, destination address, and SPI next header number (50), source address, destination address, and SPI
can be done by the hardware (there is usually already similar can be done by the hardware (there is usually already similar
functionality there, for TCP/UDP flows). The heuristics can be functionality there, for TCP/UDP flows). The heuristics can be
implemented by the hardware, but using software will allow faster implemented by the hardware, but using software will allow faster
updates when new protocol modifications come out or new protocols updates when new protocol modifications come out or new protocols
need support. need support.
As described in section 7, UDP encapsulated ESP traffic may also have As described in Section 7, UDP encapsulated ESP traffic may also have
have NAPT applied to it, and so there is already a 5-tuple state in have NAPT applied to it, and so there is already a 5-tuple state in
the stateful inspection gateway the stateful inspection gateway.
4. IPsec flows 4. IPsec flows
ESP is a stateful protocol, meaning there is state stored in the both ESP is a stateful protocol, meaning there is state stored in both end
end nodes of the ESP IPsec SA, and the state is identified by the nodes of the ESP IPsec SA, and the state is identified by the pair of
pair of destination IP and SPI. End nodes also often fix the source destination IP and SPI. End nodes also often fix the source IP
IP address in an SA unless the destination is a multicast group. address in an SA unless the destination is a multicast group.
Typically most (if not all) flows of interest to an intermediate Typically most (if not all) flows of interest to an intermediate
device are unicast, so it is safer to assume the receiving node also device are unicast, so it is safer to assume the receiving node also
uses a source address, and the intermediate device should therefore uses a source address, and the intermediate device should therefore
do the same. In some cases this might cause extraneous cached ESP do the same. In some cases this might cause extraneous cached ESP
IPsec SA flows, but by using the source address two distinct flows IPsec SA flows, but by using the source address two distinct flows
will never be mixed. For sites which heavily use multicast, such will never be mixed. For sites which heavily use multicast, such
traffic is deterministically identifiable (224.0.0.0/4 for IPv4 and 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 ff00::0/8 for IPv6), and an implementation can save the space of
multiple cache entries for a multicast flow by checking the multiple cache entries for a multicast flow by checking the
destination address first. destination address first.
skipping to change at page 10, line 11 skipping to change at page 10, line 11
they are measured). When the next packet to the flow arrives, it is they are measured). When the next packet to the flow arrives, it is
heuristically processed again, and the cached flow may continue to be heuristically processed again, and the cached flow may continue to be
"unsure", marked as ESP, or marked as an ESP-NULL flow. "unsure", marked as ESP, or marked as an ESP-NULL flow.
There are several reasons why a single packet might not be enough to There are several reasons why a single packet might not be enough to
detect type of flow. One of them is that the next header number was 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 unknown, i.e. if heuristics do not know about the protocol for the
packet, it cannot verify it has properly detected ESP-NULL packet, it cannot verify it has properly detected ESP-NULL
parameters, even when the packet otherwise looks like ESP-NULL. If parameters, even when the packet otherwise looks like ESP-NULL. If
the packet does not look like ESP-NULL at all, then encrypted ESP the packet does not look like ESP-NULL at all, then encrypted ESP
status can be returned quickly. As ESP-NULL heuristics should know status can be returned quickly. As ESP-NULL heuristics need to know
the same protocols as a deep inspection device, an unknown protocol the same protocols as a deep inspection device, an ESP-NULL instance
should not be handled any differently than a cleartext instance of an of an unknown protocol can be handled the same way as a cleartext
unknown protocol if possible. instance of the same unknown protocol.
5. Deep Inspection Engine 5. Deep Inspection Engine
A deep inspection engine running on an intermediate node usually A deep inspection engine running on an intermediate node usually
checks deeply into the packet and performs policy decisions based on checks deeply into the packet and performs policy decisions based on
the contents of the packet. The deep inspection engine should be the contents of the packet. The deep inspection engine should be
able to tell the difference between success, failure, and garbage. able to tell the difference between success, failure, and garbage.
Success means that a packet was successfully checked with the deep Success means that a packet was successfully checked with the deep
inspection engine, and it passed the checks and is allowed to be inspection engine, and it passed the checks and is allowed to be
forwarded. Failure means that a packet was successfully checked but forwarded. Failure means that a packet was successfully checked but
skipping to change at page 12, line 23 skipping to change at page 12, line 23
the deep inspection engine will most likely reject the packet and the deep inspection engine will most likely reject the packet and
return that it is garbage. If the deep inspection engine is return that it is garbage. If the deep inspection engine is
rejecting a high number of packets as garbage, it might indicate an 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 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 ESP flow was improperly detected as ESP-NULL). In that case, the
cached flow should be invalidated and discovery should happen again. cached flow should be invalidated and discovery should happen again.
Each ESP-NULL flow should also keep statistics about how many packets Each ESP-NULL flow should also keep statistics about how many packets
have been detected as garbage by deep inspection, how many have have been detected as garbage by deep inspection, how many have
passed checks, or how many have failed checks with policy violations passed checks, or how many have failed checks with policy violations
(i.e. failed because actual inspection policy failures, not because (i.e. failed because of actual inspection policy failures, not
the packet looked like garbage). If the number of garbage packets because the packet looked like garbage). If the number of garbage
suddenly increases (e.g. most of the packets start to be look like packets suddenly increases (e.g. most of the packets start to be look
garbage according to the deep inspection engine), it is possible the like garbage according to the deep inspection engine), it is possible
old ESP-NULL SA was replaced by an identical-SPI encrypting ESP SA. the old ESP-NULL SA was replaced by an identical-SPI encrypting ESP
If both ends use random SPI generation, this is a very unlikely SA. If both ends use random SPI generation, this is a very unlikely
situation (1 in 2^32), but it is possible that some nodes reuse SPI situation (1 in 2^32), but it is possible that some nodes reuse SPI
numbers (e.g. a 32-bit memory address of the SA descriptor), thus numbers (e.g. a 32-bit memory address of the SA descriptor), thus
this situation needs to be handled. this situation needs to be handled.
Actual limits for cache invalidation are local policy decisions. Actual limits for cache invalidation are local policy decisions.
Sample invalidation policies include: 50% of packets marked as Sample invalidation policies include: 50% of packets marked as
garbage within a second; or if a deep inspection engine cannot garbage within a second; or if a deep inspection engine cannot
differentiate between garbage and failure, failing more than 95% of differentiate between garbage and failure, failing more than 95% of
packets in last 10 seconds. For implementations that do not packets in last 10 seconds. For implementations that do not
distinguish between garbage and failure, failures should not be distinguish between garbage and failure, failures should not be
skipping to change at page 15, line 11 skipping to change at page 15, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
The output of the heuristics should provide information about whether 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 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 heuristics should also provide the Integrity Check Value (ICV) field
length and the Initialization Vector (IV) length. length and the Initialization Vector (IV) length.
The currently defined ESP authentication algorithms have 4 different The currently defined ESP authentication algorithms have 4 different
lengths for the ICV field. Most commonly used is 96 bits, and after lengths for the ICV field.
that comes 128 bit ICV lengths.
Different ICV lengths for different algorithm: Different ICV lengths for different algorithm:
Algorithm ICV Length Algorithm ICV Length
------------------------------- ---------- ------------------------------- ----------
AUTH_HMAC_MD5_96 96 AUTH_HMAC_MD5_96 96
AUTH_HMAC_SHA1_96 96 AUTH_HMAC_SHA1_96 96
AUTH_AES_XCBC_96 96 AUTH_AES_XCBC_96 96
AUTH_AES_CMAC_96 96 AUTH_AES_CMAC_96 96
AUTH_HMAC_SHA2_256_128 128 AUTH_HMAC_SHA2_256_128 128
skipping to change at page 17, line 14 skipping to change at page 17, line 14
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.5% of matched-pairs to virtually nothing. aforementioned 1.5% of matched-pairs to virtually nothing.
At this point a maximum of 1.6% of packets remain, so the next header At this point a maximum of 1.6% of possible byte values remain, so
number is inspected. If the next header number is known (and the next header number is inspected. If the next header number is
supported) then the packet can be inspected based on the next header known (and supported) then the packet can be inspected based on the
number. If the next header number is unknown (i.e. not any of those next header number. If the next header number is unknown (i.e. not
with protocol checking support) the packet is marked "unsure", any of those with protocol checking support) the packet is marked
because there is no way to detect the IV length without inspecting "unsure", because there is no way to detect the IV length without
the inner protocol payload. inspecting 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
(44), ICMPv6 (58), and IPv6 options (60)). To ensure that no packet (44), ICMPv6 (58), and IPv6 options (60)). To ensure that no packet
is misinterpreted as an encrypted ESP packet even when it is an ESP- 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 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. next header number is one of those which is not known and supported.
In those cases the packets are marked as "unsure". In those cases the packets are marked as "unsure".
skipping to change at page 18, line 20 skipping to change at page 18, line 20
parameters, and those heuristics benefit from the existing TCP / UDP parameters, and those heuristics benefit from the existing TCP / UDP
flows which were present in the previous IPsec SA. In that case it 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 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), 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, and if those flows are already known by the deep inspection engine,
it will give a strong indication that the new SA is really ESP-NULL. it will give a strong indication that the new SA is really ESP-NULL.
The worst case scenario is when an end node starts up communication, The worst case scenario is when an end node starts up communication,
i.e. it does not have any previous flows through the device. i.e. it does not have any previous flows through the device.
Heuristics will run on the first few packets received from the end Heuristics will run on the first few packets received from the end
node. The later subsections mainly cover these bring up cases, as node. The later subsections mainly cover these start-up cases, as
they are the most difficult. they are the most difficult.
In the protocol checks there are two different types of checks. The In the protocol checks there are two different types of checks. The
first check is for packet validity, i.e. certain locations must first check is for packet validity, i.e. certain locations must
contain specific values. For example, an inner IPv4 header of an 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 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. it does not, the packet is not valid, and can be marked as a failure.
Other positions depending on ICV and IV lengths must also be checked, Other positions depending on ICV and IV lengths must also be checked,
and if all of them are failures, then the packet is a failure. If and if all of them are failures, then the packet is a failure. If
any of the checks are "unsure" the packet is marked as such. any of the checks are "unsure" the packet is marked as such.
skipping to change at page 19, line 4 skipping to change at page 19, line 4
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
flags have valid values; checking source and destination port flags have valid values; checking source and destination port
numbers, which in some cases can be used for heuristics (but in numbers, which in some cases can be used for heuristics (but in
general they cannot be reliably distinguished from random numbers general they cannot be reliably distinguished from 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 which
numbers used in the checksum are wrong, thus the checksum is wrong. changed the IP addresses but assumed any ESP payload was encrypted
If the checksum is correct that can again be used to increase the and did not fix the transport checksums with the new IP addresses.
valid bit count, but verifying checksums is a costly operation, thus Thus the IP numbers used in the checksum are wrong, thus the checksum
skipping that check might be best unless there is hardware to help is wrong. If the checksum is correct that can again be used to
the calculation. Window size, urgent pointer, sequence number, and increase the valid bit count, but verifying checksums is a costly
acknowledgement numbers can be used, but there is not one specific operation, thus skipping that check might be best unless there is
known value for them. 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 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. packet will most likely be a retransmission of the previous packet.
Thus if two packets are received with the same source, and Thus if two packets are received with the same source, and
destination port numbers, and where sequence numbers are either same destination port numbers, and where sequence numbers are either same
or right after each other, then it's likely a TCP packet has been or right after each other, then it's likely a TCP packet has been
correctly detected. correctly detected. This heuristics is most helpful when only one
packet is outstanding. For example, if a TCP SYN packet is lost (or
dropped because of policy), the next packet would always be a
retransmission of the same TCP SYN packet.
Existing deep inspection engines usually do very good TCP flow Existing deep inspection engines usually do very good TCP flow
checking already, including flow tracking, verification of sequence checking already, including flow tracking, verification of sequence
numbers, and reconstruction of the whole TCP flow. Similar methods numbers, and reconstruction of the whole TCP flow. Similar methods
can be used here, but they are implementation-dependent and not can be used here, but they are implementation-dependent and not
described here. described here.
8.3.2. UDP checks 8.3.2. UDP checks
UDP header has even more problems than the TCP header, as UDP has UDP header has even more problems than the TCP header, as UDP has
skipping to change at page 21, line 23 skipping to change at page 21, line 23
encrypted connections also, then an attacker who wants to attack the encrypted connections also, then an attacker who wants to attack the
server and wants to bypass a deep inspection device in the middle, server and wants to bypass a deep inspection device in the middle,
will use encrypted traffic. This means that the protection of the will use encrypted traffic. This means that the protection of the
whole network is only as good as the policy enforcement and whole network is only as good as the policy enforcement and
protection of the end node. One way to enforce deep inspection for protection of the end node. One way to enforce deep inspection for
all traffic, is to forbid encrypted ESP completely, in which case all traffic, is to forbid encrypted ESP completely, in which case
ESP-NULL detection is easier, as all packets must be ESP-NULL based ESP-NULL detection is easier, as all packets must be ESP-NULL based
on the policy, and further restrictions can eliminate ambiguities in on the policy, and further restrictions can eliminate ambiguities in
ICV and IV sizes. ICV and IV sizes.
Using ESP-NULL or especially forcing using of it everywhere inside Forcing use of ESP-NULL everywhere inside the enterprise, so that
the enterprise can have increased risk of sending confidential accounting, logging, network monitoring, and intrusion detection all
information where eavesdroppers can see it. work, increases the risk of sending confidential information where
eavesdroppers can see it.
10. IANA Considerations 10. IANA Considerations
No IANA assignments are needed. No IANA assignments are needed.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
 End of changes. 20 change blocks. 
50 lines changed or deleted 56 lines changed or added

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