draft-ietf-ipsecme-esp-null-heuristics-02.txt   draft-ietf-ipsecme-esp-null-heuristics-03.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: May 27, 2010 November 23, 2009 Expires: June 3, 2010 November 30, 2009
Heuristics for Detecting ESP-NULL packets 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 May 27, 2010. This Internet-Draft will expire on June 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes an algorithm for distinguishing IPsec ESP- This document describes a set of heuristics for distinguishing IPsec
NULL (Encapsulating Security Payload without encryption) packets from ESP-NULL (Encapsulating Security Payload without encryption) packets
encrypted ESP packets. The algorithm can be used on intermediate from encrypted ESP packets. These heuristics can be used on
devices, like traffic analyzers, and deep inspection engines, to intermediate devices, like traffic analyzers, and deep inspection
quickly decide whether given packet flow is interesting or not. Use engines, to quickly decide whether given packet flow is interesting
of this algorithm does not require any changes made on existing or not. Use of these heuristics does not require any changes made on
RFC4303 compliant IPsec hosts. existing RFC4303 compliant IPsec hosts.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability: Heuristic Traffic Inspection and 1.1. Applicability: Heuristic Traffic Inspection and
Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 4 Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 6 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . 15 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 15
8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 17 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . 19
8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 19 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 24
A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The ESP (Encapsulating Security Payload [RFC4303]) protocol can be The ESP (Encapsulating Security Payload [RFC4303]) protocol can be
used with NULL encryption [RFC2410] to provide authentication and used with NULL encryption [RFC2410] to provide authentication,
integrity protection, but not confidentiality and optionally replay integrity protection, and optionally replay detection; but not
detection. This offers similar properties to IPsec's AH confidentiality. NULL encryption with ESP (referred to as ESP-NULL)
(Authentication Header [RFC4302]). One reason to use ESP-NULL offers similar properties to IPsec's AH (Authentication Header
instead of AH is that AH cannot be used if there are NATs (Network [RFC4302]). One reason to use ESP-NULL instead of AH is that AH
Address Translation devices) on the path. With AH it would be easy cannot be used if there are NATs (Network Address Translation
to detect packets which have only authentication and integrity devices) on the path. With AH it would be easy to detect packets
protection, as AH has its own protocol number and deterministic which have only authentication and integrity protection, as AH has
packet length. With ESP-NULL such detection is nondeterministic, in its own protocol number and deterministic packet length. With ESP-
spite of the base ESP packet format being fixed. 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 In some cases intermediate devices would like to detect ESP-NULL
packets so they could perform deep inspection or enforce access packets so they could perform deep inspection or enforce access
control. This kind of deep inspection includes virus detection, spam control. This kind of deep inspection includes virus detection, spam
filtering, and intrusion detection. As end nodes might be able to filtering, and intrusion detection. As end nodes might be able to
bypass those checks by using encrypted ESP instead of ESP-NULL, these bypass those checks by using encrypted ESP instead of ESP-NULL, these
kinds of scenarios also require very specific policies to forbid such kinds of scenarios also require very specific policies to forbid such
circumvention. circumvention.
These sorts of policy requirements usually mean that the whole 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 domain. Such setups are usually limited to inside the network of one
enterprise or organization, and encryption is not used as the network enterprise or organization, and encryption is not used as the network
is considered safe enough from eavesdroppers. is considered safe enough from eavesdroppers.
Because the traffic inspected is usually host to host traffic inside Because the traffic inspected is usually host to host traffic inside
one organization, that usually means transport mode IPsec is used. 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 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 traffic inside one organization, but for the intended use cases for
the heuristics this will most likely be the case. Also tunnel mode 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 case is much easier to solve than transport mode as it is much easier
to detect the IP header inside the ESP-NULL packet. to detect the IP header inside the ESP-NULL packet.
It should also be noted that even if new protocol modifications for It should also be noted that even if new protocol modifications for
ESP support easier detection of ESP-NULL in the future, this document ESP support easier detection of ESP-NULL in the future, this document
will aid in transition of older end-systems. That way, a solution will aid in transition of older end-systems. That way, a solution
can be implemented immediately, and not after a 5-10 year upgrade- can be implemented immediately, and not after a 5-10 year upgrade-
and-deployment time frame. Even with protocol modification for end and-deployment time frame. Even with protocol modification for end
nodes, the intermediate devices will need heuristics until they can nodes, the intermediate devices will need heuristics until they can
assume that those protocol modifications can be found from all the assume that those protocol modifications can be found from all the
end devices. To make sure that any solution does not break in 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 future it would be best if such heuristics are documented - i.e.
need to publish an RFC for what to do now even when there might be a publishing an RFC for what to do now, even when there might be a new
new protocol coming in the future that will solve the same problem protocol coming in the future that will solve the same problem
better. better.
1.1. Applicability: Heuristic Traffic Inspection and Wrapped ESP 1.1. Applicability: Heuristic Traffic Inspection and Wrapped ESP
There are two ways to enable intermediate security devices to There are two ways to enable intermediate security devices to
distinguish between encrypted and unencrypted ESP traffic: distinguish between encrypted and unencrypted ESP traffic:
o The heuristics approach has the intermediate node inspect the o The heuristics approach has the intermediate node inspect the
unchanged ESP traffic, to determine with extremely high unchanged ESP traffic, to determine with extremely high
probability whether or not the traffic stream is encrypted. probability whether or not the traffic stream is encrypted.
o The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility], in o The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility], in
contrast, requires the ESP endpoints to be modified to support the contrast, requires the ESP endpoints to be modified to support the
new protocol. WESP allows the intermediate node to distinguish new protocol. WESP allows the intermediate node to distinguish
encrypted and unencrypted traffic deterministically, using a encrypted and unencrypted traffic deterministically, using a
simpler implementation for the intermediate node. simpler implementation for the intermediate node.
Both approaches are being documented simultaneously by the IPsecME Both approaches are being documented simultaneously by the IPsecME
Working Group, with WESP being put on Standards Track while the Working Group, with WESP being put on Standards Track while the
heuristics approach is being published as an Informational RFC. heuristics approach is being published as an Informational RFC.
While endpoints are being modified to adopt WESP, we expect both While endpoints are being modified to adopt WESP, both approaches
approaches to coexist for years, because the heuristic approach is will likely coexist for years, because the heuristic approach is
needed to inspect traffic where at least one of the endpoints has not needed to inspect traffic where at least one of the endpoints has not
been modified. In other words, intermediate nodes are expected to been modified. In other words, intermediate nodes are expected to
support both approaches in order to achieve good security and support both approaches in order to achieve good security and
performance during the transition period. performance during the transition period.
1.2. Terminology 1.2. Terminology
This document uses following terminology: This document uses following terminology:
Flow Flow
TCP/UDP or IPsec flow is a stream of packets part of the same TCP/ A TCP/UDP or IPsec flow is a stream of packets part of the same
UDP or IPsec stream, i.e. TCP flow is a stream of packets having TCP/UDP or IPsec stream, i.e. TCP or UDP flow is a stream of
same 5 tuple (source and destination ip and port, and TCP packets having same 5 tuple (source and destination IP and port,
protocol). and TCP/UDP protocol). Note, that this kind of flow is also
called microflow in some documents.
Flow Cache Flow Cache
Deep inspection engines and similar use cache of flows going Deep inspection engines and similar devices use a cache of flows
through the device, and that cache keeps state of all flows going going through the device, and that cache keeps state of all flows
through the device. going through the device.
IPsec Flow IPsec Flow
IPsec flow stream of packets having same source IP, destination An IPsec flow is a stream of packets sharing the same source IP,
IP, protocol (ESP/AH) and SPI. Strictly speaking source IP does destination IP, protocol (ESP/AH) and SPI. Strictly speaking, the
not need to be as part of the flow identification, but as it can source IP does not need to be as part of the flow identification,
be there depending on the receiving implementation it is safer to but as it can be there depending on the receiving implementation
assume it is always part of the flow identification. it is safer to assume it is always part of the flow
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 those. 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
which offers authentication and integrity protection, but not which offers authentication and integrity protection, but not
confidentiality, namely AH. AH traffic is clearly marked as not confidentiality, namely AH. AH traffic is clearly marked as not
encrypted, and can always be inspected by intermediate devices. encrypted, and can always be inspected by intermediate devices.
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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
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] 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 Cryptographic Algorithm Implementation Requirements for by the Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) [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. 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 as well tested in the interoperability events, meaning it might have
more bugs than ESP implementations. 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 if the machines are not under the algorithm). This does not work unless one of a pair of communicating
same administrative domain. Also, such a solution might require some machines is not under the same administrative domain as the deep
kind of centralized policy management to make sure everybody uses the inspection engine. (IPsec Security Associations must be satisfactory
same policy. 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 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 a new IP-protocol [I-D.ietf-ipsecme-traffic-visibility], adding new IP-protocol numbers
numbers which tell the ESP-NULL parameters which tell the ESP-NULL parameters [I-D.hoffman-esp-null-protocol],
[I-D.hoffman-esp-null-protocol], reserving an SPI range for ESP-NULL reserving an SPI range for ESP-NULL [I-D.bhatia-ipsecme-esp-null],
[I-D.bhatia-ipsecme-esp-null], and using UDP encapsulation with a and using UDP encapsulation with a different format and ports.
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 the slowness of
endpoint migration vs. intermediate migration can be seen from the endpoint migration vs. intermediate migration can be seen from the
IPv6 vs NAT case. IPv6 required updating all of the end nodes (and deployment of both IPv6 and NAT. IPv6 required updating all of the
routers too) before it could be effectively used. This has taken a end nodes (and routers too) before it could be effectively used.
very long time, and IPv6 deployment is not yet widespread. NAT, on This has taken a very long time, and IPv6 deployment is not yet
the other hand, only required modifying an existing intermediate widespread. NAT, on the other hand, only required modifying an
device or adding a new one, and has spread out much faster. Another existing intermediate device or adding a new one, and has spread out
example of slow end-node deployment is IKEv2. Considering an much faster. Another example of slow end-node deployment is IKEv2.
implementation that requires both IKEv2 and a new ESP format, it Considering an implementation that requires both IKEv2 and a new ESP
would take several years, possibly as long as a decade, before format, it would take several years, possibly as long as a decade,
widespread deployment. 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 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 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.
In this document it is assumed that an affected intermediate node In this document it is assumed that an affected intermediate node
will act as a stateful interception device, meaning it will keep 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 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 addresses forming an IPsec SA - going through it. The heuristics can
skipping to change at page 8, line 32 skipping to change at page 8, line 32
reliability of the heuristics. reliability of the heuristics.
Generally, an intermediate node runs heuristics only for the first 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 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 packets, the node detects parameters of the IPsec flow, it skips
detection heuristics, and it can perform direct packet-inspecting detection heuristics, and it can perform direct packet-inspecting
action based on its own policy. Once detected, ESP-NULL packets will action based on its own policy. Once detected, ESP-NULL packets will
never be detected as encrypted ESP packets, meaning that valid ESP- never be detected as encrypted ESP packets, meaning that valid ESP-
NULL packets will never bypass the deep inspection. The only failure NULL packets will never bypass the deep inspection. The only failure
mode of these heuristics is to assume encrypted ESP packets are ESP- 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 inspected. An attacker can easily send random-looking ESP-NULL
packets which will cause heuristics to detect packets as encrypted packets which will cause heuristics to detect packets as encrypted
ESP, but that is no worse than sending non-ESP fuzz through an ESP, but that is no worse than sending non-ESP fuzz through an
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
have NAPT applied to it, and so there is already a 5-tuple state in
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 the both
end nodes of the ESP IPsec SA, and the state is identified by the 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 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 IP address in an SA unless the destination is a multicast group.
most (if not all) flows of interest to an intermediate device are Typically most (if not all) flows of interest to an intermediate
unicast, it is safer to assume the receiving node also uses a source device are unicast, so it is safer to assume the receiving node also
address, and the intermediate device should do the same. In some uses a source address, and the intermediate device should therefore
cases this might cause extraneous cached ESP IPsec SA flows, but by do the same. In some cases this might cause extraneous cached ESP
using the source address two distinct flows will never be mixed. 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 When the intermediate device sees a new ESP IPsec flow, i.e. a new
flow of ESP packets where the source address, destination address, flow of ESP packets where the source address, destination address,
and SPI number forms a triplet which has not been cached, it will 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. start the heuristics to detect whether this flow is ESP-NULL or not.
These heuristics appear in Section 8. These heuristics appear in Section 8.
When the heuristics finish, they will label the flow as either When the heuristics finish, they will label the flow as either
encrypted (which tells that packets in this flow are encrypted, and encrypted (which tells that packets in this flow are encrypted, and
cannot be ESP-NULL packets) or as ESP-NULL. This information, along cannot be ESP-NULL packets) or as ESP-NULL. This information, along
skipping to change at page 12, line 8 skipping to change at page 12, line 8
encrypted ESP flow, not an ESP-NULL flow). encrypted ESP flow, not an ESP-NULL flow).
If the deep inspection engine will only return failure for all If the deep inspection engine will only return failure for all
garbage packets in addition to real failure cases, then a system garbage packets in addition to real failure cases, then a system
implementing the ESP-NULL heuristics cannot recover from error implementing the ESP-NULL heuristics cannot recover from error
situations quickly. situations quickly.
6. Special and Error Cases 6. Special and Error Cases
There is a small probability that an encrypted ESP packet (which There is a small probability that an encrypted ESP packet (which
looks like contain completely random bytes) will have plausible bytes looks like it contains completely random bytes) will have plausible
in expected locations, such that heuristics will detect the packet as bytes in expected locations, such that heuristics will detect the
an ESP-NULL packet instead of detecting that it is encrypted ESP packet as an ESP-NULL packet instead of detecting that it is
packet. The actual probabilities will be computed later in this encrypted ESP packet. The actual probabilities will be computed
document. Such a packet will not cause problems, as the deep later in this document. Such a packet will not cause problems, as
inspection engine will most likely reject the packet and return that the deep inspection engine will most likely reject the packet and
it is garbage. If the deep inspection engine is rejecting a high return that it is garbage. If the deep inspection engine is
number of packets as garbage, it might indicate an original ESP-NULL rejecting a high number of packets as garbage, it might indicate an
detection for the flow was wrong (i.e. an encrypted ESP flow was original ESP-NULL detection for the flow was wrong (i.e. an encrypted
improperly detected as ESP-NULL). In that case, the cached flow ESP flow was improperly detected as ESP-NULL). In that case, the
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 actual inspection policy failures, not because
the packet looked like garbage). If the number of garbage packets the packet looked like garbage). If the number of garbage packets
suddenly increases (e.g. most of the packets start to be look like suddenly increases (e.g. most of the packets start to be look like
garbage according to the deep inspection engine), it is possible the garbage according to the deep inspection engine), it is possible the
old ESP-NULL SA was replaced by an identical-SPI encrypting ESP SA. 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 If both ends use random SPI generation, this is a very unlikely
skipping to change at page 13, line 9 skipping to change at page 13, line 9
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
treated too quickly as indication of SA reuse. Often, single packets treated too quickly as indication of SA reuse. Often, single packets
cause state-related errors that block otherwise normal packets from cause state-related errors that block otherwise normal packets from
passing. passing.
7. UDP encapsulation 7. UDP encapsulation
The flow lookup code needs to detect UDP packets to or from port 4500 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 in addition to the ESP packets, and perform similar processing to
them after skipping the UDP header. Each unique port pair them after skipping the UDP header. Port-translation by NAT often
constitutes a separate IPsec flow, i.e. UDP encapsulated IPsec flows rewrites what was originally 4500 into a different value, which means
are identified by the source and destination IP, source and each unique port pair constitutes a separate IPsec flow. I.e. UDP
destination port number and SPI number. As devices might be using encapsulated IPsec flows are identified by the source and destination
MOBIKE ([RFC4555]), that means that the flow cache should be shared IP, source and destination port number and SPI number. As devices
between the UDP encapsulated IPsec flows and non encapsulated IPsec might be using MOBIKE ([RFC4555]), that also means that the flow
flows. As previously mentioned, differentiating between garbage and cache should be shared between the UDP encapsulated IPsec flows and
actual policy failures will help in proper detection immensely. 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 Because the checks are run for packets having just source port 4500
in addition to those having destination port 4500, this might cause or packets having just destination port 4500, this might cause checks
the checks to be run for non-ESP traffic too. The UDP encapsulation to be run for non-ESP traffic too. Some traffic may randomly use
processing should also be aware of that. We cannot limit the checks port 4500 for other reasons, especially if a port-translating NAT is
for only UDP packets having destination port 4500, as return packets involved. The UDP encapsulation processing should also be aware of
from the SGW going towards the NAT box do have source port 4500, and that possibility.
some other port as destination port.
8. Heuristic Checks 8. Heuristic Checks
Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability 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 that a random packet will pass the HMAC test. This yields a
99.999999999999999999999999998% probability that an end node will 99.999999999999999999999999998% probability that an end node will
correctly detect a random packet as being invalid. This means that correctly detect a random packet as being invalid. This means that
it should be enough for an intermediate device to check around 96 it should be enough for an intermediate device to check around 96
bits from the input packet. By comparing them against known values 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 for the packet, a deep inspection engine gains more or less the same
node is using. This gives an upper limit of how many bits heuristics probability as an end node is using. This gives an upper limit of
need to check - there is no point of checking much more than that how many bits heuristics need to check - there is no point of
many bits (since that same probability is acceptable for the end checking much more than that many bits (since that same probability
node). In most of the cases the intermediate device does not need is acceptable for the end node). In most of the cases the
that high probability, perhaps something around 32-64 bits is enough. 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- IPsec's ESP has a well-understood packet layout, but its variable-
length fields reduce the ability of pure algorithmic matching to one length fields reduce the ability of pure algorithmic matching to one
requiring heuristics and assigning probabilities. requiring heuristics and assigning probabilities.
8.1. ESP-NULL format 8.1. ESP-NULL format
The ESP-NULL format is as follows: The ESP-NULL format is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 14, line 52 skipping to change at page 15, line 5
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header | | | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) | | Integrity Check Value-ICV (variable) |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
The output of the heuristics should provide us information 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 we the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL the
also need to know the Integrity Check Value (ICV) field length and heuristics should also provide the Integrity Check Value (ICV) field
the Initialization Vector (IV) length. length and the Initialization Vector (IV) length.
The currently defined ESP authentication algorithms have 5 different The currently defined ESP authentication algorithms have 5 different
lengths for the ICV field. Most commonly used is 96 bits, and after lengths for the ICV field. Most commonly used is 96 bits, and after
that comes 128 bit ICV lengths. that comes 128 bit ICV lengths.
Different ICV lengths for different algorithsm: 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_MD5_128 128 AUTH_HMAC_MD5_128 128
AUTH_HMAC_SHA2_256_128 128 AUTH_HMAC_SHA2_256_128 128
AUTH_AES_128_GMAC 128 AUTH_AES_128_GMAC 128
skipping to change at page 15, line 37 skipping to change at page 15, line 39
AUTH_HMAC_SHA2_512_256 256 AUTH_HMAC_SHA2_512_256 256
Figure 2 Figure 2
In addition to the ICV length, there are also two possible values for In addition to the ICV length, there are also two possible values for
IV lengths: zero bytes (default) and eight bytes (for IV lengths: zero bytes (default) and eight bytes (for
AUTH_AES_*_GMAC). Detecting the IV length requires understanding the AUTH_AES_*_GMAC). Detecting the IV length requires understanding the
payload, i.e. the actual protocol data (meaning TCP, UDP, etc). This payload, i.e. the actual protocol data (meaning TCP, UDP, etc). This
is required to distinguish the optional IV from the actual protocol is required to distinguish the optional IV from the actual protocol
data. How well IV can be distinguished from the actual protocol data 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 that generates random looking data (i.e. encrypted counter etc) then
disginguishing protocol data from IV is quite easy. If IV is counter distinguishing protocol data from IV is quite easy. If an IV is a
or similar non-random value, then there are bit more possibilities counter or similar non-random value, then there are more
for error. If the protocol (also known as the, "next header") of the possibilities for error. If the protocol (also known as the, "next
packet is one that is not supported by the heuristics, then detecting header") of the packet is one that is not supported by the
the IV length is impossible, thus the heuristics cannot finish. In heuristics, then detecting the IV length is impossible, thus the
that case heuristics returns "unsure" and requires further packets. heuristics cannot finish. In that case, the heuristics return
"unsure" and requires further packets.
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 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 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 23 skipping to change at page 16, line 25
bit ICV and the implementation starts first checking for a 256-bit bit ICV and the implementation starts first checking for a 256-bit
ICV, it is possible that the cleartext part of the payload contains 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 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 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 first, the inspected bytes are part of the longer ICV field, and
should be indistinguishable from random noise. should be indistinguishable from random noise.
Each ESP packet always has between 0-255 bytes of padding, and Each ESP packet always has between 0-255 bytes of padding, and
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 heuristics method would be even more reliable if some padding, but the heuristics method would be even more reliable if
extra padding is added. The actual padding data has bytes starting some extra padding is added. The actual padding data has bytes
from 01 and ending to the pad length, i.e. exact padding and pad starting from 01 and ending to the pad length, i.e. exact padding and
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 five locations. Given five
two-byte locations (assuming the packet size allows all five possible two-byte locations (assuming the packet size allows all five 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:
skipping to change at page 17, line 21 skipping to change at page 17, line 22
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
(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 ESP-NULL is misinterpreted as an encrypted ESP packet even when it is an ESP-
packet, a packet cannot be marked as a failure even when the next NULL packet, a packet cannot be marked as a failure even when the
header number is one of those which is not known and supported. In next header number is one of those which is not known and supported.
those cases the packets are marked as "unsure". In those cases the packets are marked as "unsure".
An intermediate node's policy, however, can aid in detecting an ESP- 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 NULL flow even when the protocol is not a common-case one. By
counting how many "unsure" returns obtained via heuristics, and after counting how many "unsure" returns obtained via heuristics, and after
the receipt of a consistent, but unknown, next-header number in same the receipt of a consistent, but unknown, next-header number in same
location (i.e. likely with the same ICV length), the node can location (i.e. likely with the same ICV length), the node can
conclude that the flow has high probability of being ESP-NULL (since 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 it is unlikely that so many packets would pass the integrity check at
the destination unless they are legitimate). The flow can be the destination unless they are legitimate). The flow can be
classified as ESP-NULL with a known ICV length, but an unknown IV classified as ESP-NULL with a known ICV length, but an unknown IV
length. length.
Fortunately, in unknown protocol cases the IV length does not matter, Fortunately, in unknown protocol cases the IV length does not matter.
as the protocol is unknown to the heuristics, it will most likely be If the protocol is unknown to the heuristics, it will most likely be
unknown by the deep inspection engine also. It is therefore unknown by the deep inspection engine also. It is therefore
important that heuristics should support at least those same important that heuristics should support at least those same
protocols as the deep inspection engine does. Upon receipt of any protocols as the deep inspection engine does. Upon receipt of any
inner next header number that is known by the heuristics (and deep inner next header number that is known by the heuristics (and deep
inspection engine), the heuristics can detect the IV length properly. inspection engine), the heuristics can detect the IV length properly.
8.3. Protocol Checks 8.3. Protocol Checks
Generic protocol checking is much easier with pre-existing state. Generic protocol checking is much easier with pre-existing state.
For example, when many TCP / UDP flows are established over one IPsec 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 SA, a rekey produces a new SA which needs heuristics to detect its
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 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. 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 bringup cases, as node. The later subsections mainly cover these bring 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 18, line 36 skipping to change at page 18, line 38
If the header-length has that specific value, the number of known If the header-length has that specific value, the number of known
"good" bits increases. If it has some other value, the known "good" "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 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. Best less useful information than other later packets might have. The
valid packet checks include: checking that header length and reserved best valid packet checks include: checking that header length and
and other bits have valid values; checking source and destination reserved and other bits have valid values; checking source and
port numbers, which in some cases can be used for heuristics (but in destination port numbers, which in some cases can be used for
general they cannot be reliably distinguished from random numbers heuristics (but in general they cannot be reliably distinguished from
apart from some well-known ports like 25/80/110/143). 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 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 possible that the packet has already transited a NAT box, thus the IP
IP numbers used in the checksum are wrong, thus the checksum is numbers used in the checksum are wrong, thus the checksum is wrong.
wrong. If the checksum is correct that can again be used to increase 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.
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.
The deep inspection engines usually do very good TCP flow checking Existing deep inspection engines usually do very good TCP flow
already, including flow tracking, verification of sequence numbers, checking already, including flow tracking, verification of sequence
and reconstruction of the whole TCP flow. Similar methods can be numbers, and reconstruction of the whole TCP flow. Similar methods
used here, but they are implementation-dependent and not described can be used here, but they are implementation-dependent and not
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
even less known data. The checksum has the same problem as the TCP 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 checksum, due to NATs. The UDP length field might not match the
overall packet length, as the sender is allowed to include TFC overall packet length, as the sender is allowed to include TFC
(traffic flow confidentiality, see section 2.7 of IP Encapsulating (traffic flow confidentiality, see section 2.7 of IP Encapsulating
Security Payload document [RFC4303]) padding. Security Payload document [RFC4303]) padding.
skipping to change at page 19, line 40 skipping to change at page 19, line 42
packets having a known pair of UDP port numbers is good indication packets having a known pair of UDP port numbers is good indication
that the heuristics have passed. that the heuristics have passed.
Some UDP protocols also use identical source and destination port Some UDP protocols also use identical source and destination port
numbers, thus that is also a good check. numbers, thus that is also a good check.
8.3.3. ICMP checks 8.3.3. ICMP checks
As ICMP messages are usually sent as return packets for other As ICMP messages are usually sent as return packets for other
packets, they are not very common packets to get as first packets for packets, they are not very common packets to get as first packets for
the SA, the ICMP Echo message being a noteworthy exception. ICMP the SA, the ICMP ECHO_REQUEST message being a noteworthy exception.
ECHO has known type and code, identifier, and sequence number. The ICMP ECHO_REQUEST has a known type and code, identifier, and sequence
checksum, however, might be incorrect again because of NATs. number. The checksum, however, might be incorrect again because of
NATs.
For error ICMP messages the ICMP message contains part of the For ICMP error messages, the ICMP message contains part of the
original IP packet inside, and then the same rules which are used to original IP packet inside. Then the same rules which are used to
detect IPv4/IPv6 tunnel checks can be used. detect IPv4/IPv6 tunnel checks can be used.
8.3.4. SCTP checks 8.3.4. SCTP checks
SCTP [RFC4960] has a self-contained checksum, which is computed over 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- 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 aware. Even more than the TCP and UDP checksums, the SCTP checksum
is expensive, and may be prohibitive even for deep-packet is expensive, and may be prohibitive even for deep-packet
inspections. inspections.
SCTP chunks can be inspected to see if their lengths are consistent 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 across the total length of the IP datagram, so long as TFC padding is
not present. not present.
8.3.5. IPv4 and IPv6 Tunnel checks 8.3.5. IPv4 and IPv6 Tunnel checks
In cases of tunneled traffic the packet inside contains a full IPv4 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 include version, header length, total length (again TFC padding might
confuse things there), protocol number, and 16-bit header checksum. confuse things there), protocol number, and 16-bit header checksum.
In those cases the intermediate device should give the decapsulated In those cases the intermediate device should give the decapsulated
IP packet to the deep inspection engine. IPv6 has fewer usable IP packet to the deep inspection engine. IPv6 has fewer usable
fields, but the version number, packet length (modulo TFC confusion) fields, but the version number, packet length (modulo TFC confusion)
and next-header all can be used by deep-packet inspection. and next-header all can be used by deep-packet inspection.
In both IPv4 and IPv6 the heuristics can also check the IP addresses 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 either to be in the known range (for example check that both IPv6
source and destination have same prefix etc), or checking addresses source and destination have same prefix etc), or checking addresses
across more than one packet. across more than one packet.
9. Security Considerations 9. Security Considerations
Attackers can always bypass ESP-NULL deep packet inspection by using Attackers can always bypass ESP-NULL deep packet inspection by using
encrypted ESP (or some other encryption or tunneling method) instead, encrypted ESP (or some other encryption or tunneling method) instead,
unless the intermediate node's policy requires dropping of packets unless the intermediate node's policy requires dropping of packets
that it cannot inspect. Ultimately the responsibility for performing that it cannot inspect. Ultimately the responsibility for performing
deep inspection, or allowing intermediate nodes to perform deep deep inspection, or allowing intermediate nodes to perform deep
inspection, must rest on the end nodes. I.e. if a server allows inspection, must rest on the end nodes. I.e. if a server allows
encrypted connections also, then attacker who wants to attack the encrypted connections also, then an attacker who wants to attack the
server and wants to bypass deep inspection device in the middle, will server and wants to bypass a deep inspection device in the middle,
use encrypted traffic. This means that the protection of the whole will use encrypted traffic. This means that the protection of the
network is only as good as the policy enforcement and protection of whole network is only as good as the policy enforcement and
the end node. One way to enforce deep inspection for all traffic, is protection of the end node. One way to enforce deep inspection for
to forbid encrypted ESP completely, in which case ESP-NULL detection all traffic, is to forbid encrypted ESP completely, in which case
is easier, as all packets must be ESP-NULL based on the policy, and ESP-NULL detection is easier, as all packets must be ESP-NULL based
further restrictions can eliminate ambiguities in ICV and IV sizes. 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 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. 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 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
10.2. Informative References 11.2. Informative References
[I-D.bhatia-ipsecme-esp-null] [I-D.bhatia-ipsecme-esp-null]
Bhatia, M., "Identifying ESP-NULL Packets", Bhatia, M., "Identifying ESP-NULL Packets",
draft-bhatia-ipsecme-esp-null-00 (work in progress), draft-bhatia-ipsecme-esp-null-00 (work in progress),
December 2008. December 2008.
[I-D.hoffman-esp-null-protocol] [I-D.hoffman-esp-null-protocol]
Hoffman, P. and D. McGrew, "An Authentication-only Profile Hoffman, P. and D. McGrew, "An Authentication-only Profile
for ESP with an IP Protocol Identifier", for ESP with an IP Protocol Identifier",
draft-hoffman-esp-null-protocol-00 (work in progress), draft-hoffman-esp-null-protocol-00 (work in progress),
skipping to change at page 28, line 13 skipping to change at page 29, line 13
* Continue Check non-ESP-NULL packet * Continue Check non-ESP-NULL packet
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Store unsure flow status to IPsec flow cache. // Store unsure flow status to IPsec flow cache.
// Here we also store the Check_Bits. // Here we also store the Check_Bits.
// //
Store unsure SPI cache info: Store unsure SPI cache info:
* Store State, IV_len, ICV_len, * Store State, IV_len, ICV_len,
Stored_Check_Bits to SPI cache Stored_Check_Bits to SPI cache
using IP_Src_IP + IP_Dst_IP + SPI as key 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 // Verify this packet against the previously selected
// ICV_len and IV_len values. This will either // ICV_len and IV_len values. This will either
// fail (and set state to ESP to mark we do not yet // fail (and set state to ESP to mark we do not yet
// know what type of flow this is), or it will // know what type of flow this is), or it will
// increment Check_Bits. // increment Check_Bits.
// //
Verify next packet: Verify next packet:
// We already have IV_len, ICV_len and State loaded // We already have IV_len, ICV_len and State loaded
 End of changes. 49 change blocks. 
166 lines changed or deleted 190 lines changed or added

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