draft-ietf-ipsecme-esp-null-heuristics-01.txt   draft-ietf-ipsecme-esp-null-heuristics-02.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: March 7, 2010 September 3, 2009 Expires: May 27, 2010 November 23, 2009
Heuristics for Detecting ESP-NULL packets Heuristics for Detecting ESP-NULL packets
draft-ietf-ipsecme-esp-null-heuristics-01.txt draft-ietf-ipsecme-esp-null-heuristics-02.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 March 7, 2010. This Internet-Draft will expire on May 27, 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 a heuristic approach for distinguishing ESP- This document describes an algorithm for distinguishing IPsec ESP-
NULL (Encapsulating Security Payload without encryption) packets from NULL (Encapsulating Security Payload without encryption) packets from
encrypted ESP packets. The reason for using heuristics instead of encrypted ESP packets. The algorithm can be used on intermediate
modifying ESP is to provide a solution that can be used now without devices, like traffic analyzers, and deep inspection engines, to
updating all end nodes. With heuristic methods, only the quickly decide whether given packet flow is interesting or not. Use
intermediate devices wanting to find ESP-NULL packets need to be of this algorithm does not require any changes made on existing
updated. 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 . . . . . . . . . . . . . . . . . . . . . . . 3 Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 5 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 6
2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 7
3. Description of Heuristics . . . . . . . . . . . . . . . . . . 7 3. Description of Heuristics . . . . . . . . . . . . . . . . . . 8
4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 10 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11
6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 11 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12
7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 12 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13
8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 13 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 13 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14
8.2. Self Describing Padding Check . . . . . . . . . . . . . . 14 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 15
8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 16 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 17
8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 17 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18
8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 17 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19
8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 18 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 19
8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 18 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 19
8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 18 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 21 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 23
A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The ESP (Encapsulated 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 and
integrity protection, but not confidentiality. This offers similar integrity protection, but not confidentiality and optionally replay
properties to IPsec's AH (Authentication Header [RFC4302]). The detection. This offers similar properties to IPsec's AH
reason to use ESP-NULL instead of AH is that AH cannot be used if (Authentication Header [RFC4302]). One reason to use ESP-NULL
there are NATs (Network Address Translation devices) on the path. instead of AH is that AH cannot be used if there are NATs (Network
With AH it would be easy to detect packets which have only Address Translation devices) on the path. With AH it would be easy
authentication and integrity protection, as AH has its own protocol to detect packets which have only authentication and integrity
number and deterministic packet length. With ESP-NULL such detection protection, as AH has its own protocol number and deterministic
is nondeterministic, in spite of the base ESP packet format being packet length. With ESP-NULL such detection is nondeterministic, in
fixed. 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 adminstrative
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
traffic inside one organization, but for the intended use cases for
the heuristics this will most likely be the case. Also tunnel mode
case is much easier to solve than transport mode as it is much easier
to detect the IP header inside the ESP-NULL packet.
It should also be noted that even if new protocol modifications for 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. we
need to publish an RFC for what to do now even when there might be a need to publish an RFC for what to do now even when there might be a
new protocol coming in the future that will solve the same problem new 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:
- 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.
- The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility], o The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility], in
in contrast, requires the ESP endpoints to be modified to support contrast, requires the ESP endpoints to be modified to support the
the new protocol. WESP allows the intermediate node to new protocol. WESP allows the intermediate node to distinguish
distinguish encrypted and unencrypted traffic deterministically, encrypted and unencrypted traffic deterministically, using a
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, we expect both
approaches to coexist for years, because the heuristic approach is approaches to 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. Requirements notation 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document uses following terminology:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. Flow
TCP/UDP or IPsec flow is a stream of packets part of the same TCP/
UDP or IPsec stream, i.e. TCP flow is a stream of packets having
same 5 tuple (source and destination ip and port, and TCP
protocol).
Flow Cache
Deep inspection engines and similar use cache of flows going
through the device, and that cache keeps state of all flows going
through the device.
IPsec Flow
IPsec flow stream of packets having same source IP, destination
IP, protocol (ESP/AH) and SPI. Strictly speaking source IP does
not need to be as part of the flow identification, but as it can
be there depending on the receiving implementation it is safer to
assume it is always part of the flow identification.
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 those.
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 18 skipping to change at page 7, line 18
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 a new IP-protocol
numbers which tell the ESP-NULL parameters numbers which tell the ESP-NULL parameters
[I-D.hoffman-esp-null-protocol], reserving an SPI range for ESP-NULL [I-D.hoffman-esp-null-protocol], reserving an SPI range for ESP-NULL
[I-D.bhatia-ipsecme-esp-null], and using UDP encapsulation with a [I-D.bhatia-ipsecme-esp-null], 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 needs 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 IPv6 vs NAT case. IPv6 required updating all of the end nodes (and
routers too) before it could be effectively used. This has taken a routers too) before it could be effectively used. This has taken a
very long time, and IPv6 deployment is not yet widespread. NAT, on very long time, and IPv6 deployment is not yet widespread. NAT, on
the other hand, only required modifying an existing intermediate the other hand, only required modifying an existing intermediate
device or adding a new one, and has spread out much faster. Another device or adding a new one, and has spread out much faster. Another
example of slow end-node deployment is IKEv2. Considering an example of slow end-node deployment is IKEv2. Considering an
implementation that requires both IKEv2 and a new ESP format, it implementation that requires both IKEv2 and a new ESP format, it
skipping to change at page 7, line 13 skipping to change at page 8, line 13
widespread deployment. 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 the 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
(and 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
also be used without storing any state, but performance will be worse also be used without storing any state, but performance will be worse
in that case, as heuristic checks will need to be done for each in that case, as heuristic checks will need to be done for each
packet, not only once per flow. This will also affect the packet, not only once per flow. This will also affect the
reliability of the heuristics. reliability of the heuristics.
skipping to change at page 8, line 17 skipping to change at page 9, line 17
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. As
most (if not all) flows of interest to an intermediate device are most (if not all) flows of interest to an intermediate device are
unicast, it is safer to assume the receiving node also uses a source unicast, it is safer to assume the receiving node also uses a source
address, and the intermediate device should do the same. In some address, and the intermediate device should do the same. In some
cases this might cause extraneous cached ESP IPsec SA flows, but by cases this might cause extraneous cached ESP IPsec SA flows, but by
using the source address two distinct flows will never be mixed. using the source address two distinct flows will never be mixed.
When the intermediate device sees an new ESP IPsec flow, i.e. a flow When the intermediate device sees a new ESP IPsec flow, i.e. a new
of ESP packets where the source address, destination address, and SPI flow of ESP packets where the source address, destination address,
number forms a triplet which has not been cached, it will start the and SPI number forms a triplet which has not been cached, it will
heuristics to detect whether this flow is ESP-NULL or not. These start the heuristics to detect whether this flow is ESP-NULL or not.
heuristics appear in the 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
with the ESP-NULL parameters detected by the heuristics, is stored to with the ESP-NULL parameters detected by the heuristics, is stored to
a flow cache, which will be used in the future when processing a flow cache, which will be used in the future when processing
packets of the same flow. packets of the same flow.
Both encrypted ESP and ESP-NULL flows are processed based on the Both encrypted ESP and ESP-NULL flows are processed based on the
local policy. In normal operation encrypted ESP flows are passed local policy. In normal operation encrypted ESP flows are passed
skipping to change at page 11, 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 correct bytes looks like contain completely random bytes) will have plausible bytes
in correct locations, such that heuristics will detect the packet as in expected locations, such that heuristics will detect the packet as
an ESP-NULL packet instead of detecting that it is encrypted ESP an ESP-NULL packet instead of detecting that it is encrypted ESP
packet. The actual probabilities will be computed later in this packet. The actual probabilities will be computed later in this
document. Such a packet will not cause problems, as the deep document. Such a packet will not cause problems, as the deep
inspection engine will most likely reject the packet and return that inspection engine will most likely reject the packet and return that
it is garbage. If the deep inspection engine is rejecting a high it is garbage. If the deep inspection engine is rejecting a high
number of packets as garbage, it might indicate an original ESP-NULL number of packets as garbage, it might indicate an original ESP-NULL
detection for the flow was wrong (i.e. an encrypted ESP flow was detection for the flow was wrong (i.e. an encrypted ESP flow was
improperly detected as ESP-NULL). In that case, the cached flow improperly detected as ESP-NULL). In that case, the cached flow
should be invalidated and discovery should happen again. should be invalidated and discovery should happen again.
skipping to change at page 12, 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 makes them after skipping the UDP header. Each unique port pair
separate IPsec flow, i.e. UDP encapsulated IPsec flows are constitutes a separate IPsec flow, i.e. UDP encapsulated IPsec flows
identified by the source and destination IP, source and destination are identified by the source and destination IP, source and
port number and SPI number. As devices might be using MOBIKE, that destination port number and SPI number. As devices might be using
means that the flow cache should be shared between the UDP MOBIKE ([RFC4555]), that means that the flow cache should be shared
encapsulated IPsec flows and non encapsulated IPsec flows. As between the UDP encapsulated IPsec flows and non encapsulated IPsec
previously mentioned, differentiating between garbage and actual flows. As previously mentioned, differentiating between garbage and
policy failures will help in proper detection immensely. 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 also run for packets having source port 4500
in addition to those having destination port 4500, this might cause in addition to those having destination port 4500, this might cause
the checks to be run for non-ESP traffic too. The UDP encapsulation the checks to be run for non-ESP traffic too. The UDP encapsulation
processing should also be avare of that. We cannot limit the checks processing should also be aware of that. We cannot limit the checks
for only UDP packets having destination port 4500, as return packets for only UDP packets having destination port 4500, as return packets
from the SGW going towards the NAT box do have source port 4500, and from the SGW going towards the NAT box do have source port 4500, and
some other port as destination port. 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 same probability as an end node is for the packet we get more or less the same probability as an end
using. This gives an upper limit of how many bits heuristics need to node is using. This gives an upper limit of how many bits heuristics
check - there is no point of checking much more than that many bits need to check - there is no point of checking much more than that
(since that same probability is acceptable for the end node). In many bits (since that same probability is acceptable for the end
most of the cases the intermediate device does not need that high node). In most of the cases the intermediate device does not need
probability, perhaps something around 32-64 bits is enough. 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 9 skipping to change at page 15, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
The output of the heuristics should provide us information whether The output of the heuristics should provide us information whether
the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL we the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL we
also need to know the Integrity Check Value (ICV) field length and also need to know the Integrity Check Value (ICV) field length and
the Initialization Vector (IV) length. 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 for lengths for the ICV field. Most commonly used is 96 bits, and after
AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, and that comes 128 bit ICV lengths.
AUTH_AES_CMAC_96 algorithms. After that comes 128 bit ICV lengths
for AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 AUTH_AES_128_GMAC, Different ICV lengths for different algorithsm:
AUTH_AES_192_GMAC, AUTH_AES_256_GMAC algorithms. 160, 192, and 256
bit field lengths are used by AUTH_HMAC_SHA1_160, Algorithm ICV Length
AUTH_HMAC_SHA2_384_192, and AUTH_HMAC_SHA2_512_256 algorithms, ------------------------------- ----------
respectively. AUTH_HMAC_MD5_96 96
AUTH_HMAC_SHA1_96 96
AUTH_AES_XCBC_96 96
AUTH_AES_CMAC_96 96
AUTH_HMAC_MD5_128 128
AUTH_HMAC_SHA2_256_128 128
AUTH_AES_128_GMAC 128
AUTH_AES_192_GMAC 128
AUTH_AES_256_GMAC 128
AUTH_HMAC_SHA1_160 160
AUTH_HMAC_SHA2_384_192 192
AUTH_HMAC_SHA2_512_256 256
Figure 2
In addition to the 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 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 disginguishing protocol data from IV is quite easy. If IV is counter
or similar non-random value, then there are bit more possibilities or similar non-random value, then there are bit more possibilities
for error. If the protocol (also known as the, "next header") of the for error. If the protocol (also known as the, "next header") of the
packet is something that heuristics doesn't have protocol checking packet is one that is not supported by the heuristics, then detecting
support, then detecting the IV length is impossible, thus the the IV length is impossible, thus the heuristics cannot finish. In
heuristics cannot finish. In that case heuristics returns "unsure" that case heuristics returns "unsure" and requires further packets.
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 leads 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 shorted 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
than what is currently inspected. For example, if a packet has a 96- than what is currently inspected. For example, if a packet has a 96-
bit ICV and implementation starts first checking for a 256-bit ICV, bit ICV and the implementation starts first checking for a 256-bit
it is possible that the cleartext part of the payload contains valid ICV, it is possible that the cleartext part of the payload contains
looking bytes. If done in the other order, i.e. a packet having a valid-looking bytes. If done in the other order, i.e. a packet
256-bit ICV and the implementation checks for a 96-bit ICV first, the having a 256-bit ICV and the implementation checks for a 96-bit ICV
inspected bytes are part of the longer ICV field, and should be first, the inspected bytes are part of the longer ICV field, and
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 heuristics method would be even more reliable if some
extra padding is added. The actual padding data has bytes starting extra padding is added. The actual padding data has bytes starting
from 01 and ending to the pad length, i.e. exact padding and pad from 01 and ending to the pad length, i.e. exact padding and pad
length bytes for 4 bytes of padding would be 01 02 03 04 04. 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 is encrypted packet that exhibits non-zero length ESP-NULL properties
1-(1-255/65536)^5 == 0.019 == 1.9%. In the cases where there is 0 is:
bytes of padding, a random encrypted ESP packet has 1-(1-1/256)^5 ==
0.019 == 1.9%. Together, both cases yields a 3.8% upper-bound chance 1 - (1 - 255 / 65536) ^ 5 == 0.019 == 1.9%
of misclassifying an encrypted packet as an ESP-NULL packet.
In the cases where there is 0 bytes of padding, a random encrypted
ESP packet has:
1 - (1 - 1 / 256) ^ 5 == 0.019 == 1.9%.
Together, both cases yields a 3.8% upper-bound chance of
misclassifying an encrypted packet as an ESP-NULL packet.
In the matched bytes case, further inspection (counting the pad bytes In the matched bytes case, further inspection (counting the pad bytes
backward and downward from the pad-length match) can reduce the backward and downward from the pad-length match) can reduce the
number of misclassified packets further. A padding length of 255 number of misclassified packets further. A padding length of 255
means a specific 256^254 sequence of bytes must occur. This means a specific 256^254 sequence of bytes must occur. This
virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding. virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding.
Every one of the 255 pairs for padding length N has only a 1 / 256^N Every one of the 255 pairs for padding length N has only a 1 / 256^N
probability of being correct ESP-NULL padding. This shrinks the probability of being correct ESP-NULL padding. This shrinks the
aforementioned 1.9% of matched-pairs to virtually nothing. aforementioned 1.9% of matched-pairs to virtually nothing.
At this point a maximum of 2% of packets remain, so the next header At this point a maximum of 2% of packets remain, so the next header
number is inspected. If the next header number is known (and number is inspected. If the next header number is known (and
supported) then the packet can be inspected based on the next header supported) then the packet can be inspected based on the next header
number. If the next header number is unknown (i.e. not any of those number. If the next header number is unknown (i.e. not any of those
with protocol checking support) the packet is marked "unsure", with protocol checking support) the packet is marked "unsure",
because there is no way to detect the IV length without inspecting because there is no way to detect the IV length without inspecting
skipping to change at page 15, line 48 skipping to change at page 17, line 20
number is inspected. If the next header number is known (and number is inspected. If the next header number is known (and
supported) then the packet can be inspected based on the next header supported) then the packet can be inspected based on the next header
number. If the next header number is unknown (i.e. not any of those number. If the next header number is unknown (i.e. not any of those
with protocol checking support) the packet is marked "unsure", with protocol checking support) the packet is marked "unsure",
because there is no way to detect the IV length without inspecting because there is no way to detect the IV length without inspecting
the inner protocol payload. the inner protocol payload.
There are six different next header fields which are in common use There are six different next header fields which are in common use
(TCP (6), UDP (17), ICMP (1), SCTP (132), IPv4 (4) and IPv6 (41)), (TCP (6), UDP (17), ICMP (1), SCTP (132), IPv4 (4) and IPv6 (41)),
and if IPv6 is in heavy use, that number increases to nine (Fragment and if IPv6 is in heavy use, that number increases to nine (Fragment
(44), ICMPv6 (58), and IPv6 options (60)). To insure 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 ESP-NULL
packet, a packet cannot be marked as a failure even when the next packet, a packet cannot be marked as a failure even when the next
header number is one of those which is not known and supported. In header number is one of those which is not known and supported. In
those cases the packet must be marked "unsure". 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 of those the receipt of a consistent, but unknown, next-header number in same
with same ICV length (i.e. in same location) that means that flow is location (i.e. likely with the same ICV length), the node can
ESP-NULL with more probability than what it is to fool a given hash conclude that the flow has high probability of being ESP-NULL (since
algorithm with a random packet. The flow can be classified as ESP- it is unlikely that so many packets would pass the integrity check at
NULL with a known ICV length, but an unknown IV length. the destination unless they are legitimate). The flow can be
classified as ESP-NULL with a known ICV length, but an unknown IV
length.
Fortunately, in unknown protocol cases the IV length does not matter, Fortunately, in unknown protocol cases the IV length does not matter,
as the protocol is unknown to the heuristics, it will most likely be as 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 SA, a For example, when many TCP / UDP flows are established over one IPsec
rekey with a new SA which needs heuristics. Then it is enough to SA, a rekey produces a new SA which needs heuristics to detect its
just check that if the flow is already known by the deep inspection parameters, and those heuristics benefit from the existing TCP / UDP
engine, it will give a strong leaning that the new SA is really ESP- flows which were present in the previous IPsec SA. In that case it
NULL. is just enough to check that if a new IPsec SA has packets belonging
to the flows of some other IPsec SA (previous IPsec SA before rekey),
and if those flows are already known by the deep inspection engine,
it will give a strong leaning that the new SA is really ESP-NULL.
The worst case scenario is when an end node starts up communcation, The worst case scenario is when an end node starts up communcation,
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 bringup 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
skipping to change at page 17, line 10 skipping to change at page 18, line 34
For example, the 4-bit header length field of an inner IPv4 packet. For example, the 4-bit header length field of an inner IPv4 packet.
It has a fixed value (5) as long as there are no inner IPv4 options. It has a fixed value (5) as long as there are no inner IPv4 options.
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 feed to the heuristics, it is most When the first TCP packet is fed to the heuristics, it is most likely
likely going to be the SYN packet of the new connection, thus it will going to be the SYN packet of the new connection, thus it will have
have less useful information than what other later packets might less useful information than other later packets might have. Best
have. Best valid packet checks include: checking that header length valid packet checks include: checking that header length and reserved
and reserved and other bits have valid values; checking source and and other bits have valid values; checking source and destination
destination port numbers, which in some cases can be used for port numbers, which in some cases can be used for heuristics (but in
heuristics (but in general they cannot be used to reliably general they cannot be reliably distinguished from random numbers
distinguished from random numbers apart from some well-known ports apart from some well-known ports like 25/80/110/143).
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 transitted a NAT box, thus the
IP numbers used in the checksum are wrong, thus the checksum is IP numbers used in the checksum are wrong, thus the checksum is
wrong. If the checksum is correct that can again be used to increase wrong. If the checksum is correct that can again be used to increase
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 the a packet is dropped then the One good method of detection is if a packet is dropped then the next
next packet will most likely be a retransmission of the previous packet will most likely be a retransmission of the previous packet.
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 The deep inspection engines usually do very good TCP flow checking
already, including flow tracking, verification of sequence numbers, already, including flow tracking, verification of sequence numbers,
and reconstruction of the whole TCP flow. Similar methods can be and reconstruction of the whole TCP flow. Similar methods can be
used here, but they are implementation-dependent and not described used here, but they are implementation-dependent and not described
here. here.
skipping to change at page 18, line 23 skipping to change at page 19, line 45
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 message being a noteworthy exception. ICMP
ECHO has known type and code, identifier, and sequence number. The ECHO has known type and code, identifier, and sequence number. The
checksum, however, might be incorrect again because of NATs. checksum, however, might be incorrect again because of NATs.
For error ICMP messages the ICMP message contains part of the For error ICMP messages the ICMP message contains part of the
original IP packet inside, and then same rules which are used to original IP packet inside, and 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.
skipping to change at page 18, line 45 skipping to change at page 20, line 18
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 useable. 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 less 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
either to be in the known range (for example check that both IPv6
source and destination have same prefix etc), or checking addresses
across more than one packet.
9. Security Considerations 9. Security Considerations
The whole deep inspection for ESP-NULL flows only has the problem Attackers can always bypass ESP-NULL deep packet inspection by using
that attacker can always bypass it by using encrypted ESP (or some encrypted ESP (or some other encryption or tunneling method) instead,
other encryption or tunneling method) instead of ESP-NULL unless that unless the intermediate node's policy requires dropping of packets
is not forbidden by policy. This means that in the end the that it cannot inspect. Ultimately the responsibility for performing
responsibility whether end node can bypass deep inspection is for the deep inspection, or allowing intermediate nodes to perform deep
policy enforcement of the both 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 attacker who wants to attack the
server and wants to bypass deep inspection device in the middle, will server and wants to bypass deep inspection device in the middle, will
use encrypted traffic. This means that the protection of the whole use encrypted traffic. This means that the protection of the whole
network is only as good as the policy enforcement and protection of network is only as good as the policy enforcement and protection of
the end node. One way to enforce deep inspection for all traffic, is the end node. One way to enforce deep inspection for all traffic, is
to forbid encrypted ESP completely, but in that case ESP-NULL to forbid encrypted ESP completely, in which case ESP-NULL detection
detection is easier, as all packets must be ESP-NULL based on the is easier, as all packets must be ESP-NULL based on the policy, and
policy, and further restriction can eliminate ambiguities in ICV and further restrictions can eliminate ambiguities in ICV and IV sizes.
IV sizes.
Using ESP-NULL or especially forcing using of it everywhere inside
the enterprice can have increased risk of sending confidential
information where eavesdroppers can see it.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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)",
skipping to change at page 20, line 40 skipping to change at page 22, line 37
[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),
August 2007. August 2007.
[I-D.ietf-ipsecme-traffic-visibility] [I-D.ietf-ipsecme-traffic-visibility]
Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP
for Traffic Visibility", for Traffic Visibility",
draft-ietf-ipsecme-traffic-visibility-08 (work in draft-ietf-ipsecme-traffic-visibility-10 (work in
progress), September 2009. progress), November 2009.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007. Authentication Header (AH)", RFC 4835, April 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
Appendix A. Example Pseudocode Appendix A. Example Pseudocode
This appendix is meant for the implementors. It does not include all This appendix is meant for the implementors. It does not include all
the required checks, and this is just example pseudocode, so final the required checks, and this is just example pseudocode, so final
implementation can be very different. It mostly lists things what implementation can be very different. It mostly lists things that
needs to be done, but implementations can optimize things depending need to be done, but implementations can optimize steps depending on
on their other parts. For example implementation might combine their other parts. For example, implementation might combine
heuristics and deep inspection tightly together. heuristics and deep inspection tightly together.
A.1. Fastpath A.1. Fastpath
The following example pseudocode show the fastpath part of the packet The following example pseudocode show the fastpath part of the packet
processing engine. This part is usually implemented in hardware. processing engine. This part is usually implemented in hardware.
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// This pseudocode uses following variables: // This pseudocode uses following variables:
// //
skipping to change at page 23, line 33 skipping to change at page 25, line 33
// //
Check ESP-NULL packet: Check ESP-NULL packet:
* If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len
+ 4 (spi) + 4 (seq no) + 4 (protocol + padding) + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
* Drop invalid packet * Drop invalid packet
* Load Protocol from IP_total_len - ICV_len - 1 * Load Protocol from IP_total_len - ICV_len - 1
* Set Protocol_off to * Set Protocol_off to
IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no) IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no)
* Do normal deep inspection on packet. * Do normal deep inspection on packet.
Figure 2 Figure 3
A.2. Slowpath A.2. Slowpath
The following example pseudocode show the actual heuristics part of The following example pseudocode show the actual heuristics part of
the packet processing engine. This part is usually implemented in the packet processing engine. This part is usually implemented in
software. software.
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// This pseudocode uses following variables: // This pseudocode uses following variables:
// //
skipping to change at page 25, line 27 skipping to change at page 27, line 27
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
* Call Try 160bit algorithms * Call Try 160bit algorithms
* If State is ESP-NULL * If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
* Call Try 192bit algorithms * Call Try 192bit algorithms
* If State is ESP-NULL * If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
* Call Try 256bit algorithms * Call Try 256bit algorithms
* If State is ESP-NULL * If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
// No idea how to test AUTH_DES_MAC and AUTH_KPDK_MD5 as they are // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from
// not defined anywhere // this document.
// If any of those test above set state to unsure // If any of those test above set state to unsure
// we mark IPsec flow as unsure. // we mark IPsec flow as unsure.
* If State is unsure * If State is unsure
* Goto Store unsure SPI cache info * Goto Store unsure SPI cache info
// All of the test failed, meaning the packet cannot // All of the test failed, meaning the packet cannot
// be ESP-NULL packet, thus we mark IPsec flow as ESP // be ESP-NULL packet, thus we mark IPsec flow as ESP
* Goto Store ESP SPI cache info * Goto Store ESP SPI cache info
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Store ESP-NULL status to the IPsec flow cache. // Store ESP-NULL status to the IPsec flow cache.
skipping to change at page 30, line 27 skipping to change at page 32, line 27
// for a suitable amount of bits. If all checks pass, then // for a suitable amount of bits. If all checks pass, then
// we just return Success, and the upper layer will then // we just return Success, and the upper layer will then
// later check if we have enough bits checked already. // later check if we have enough bits checked already.
* Load Protocol From IP_total_len - Test_ICV_len - 1 * Load Protocol From IP_total_len - Test_ICV_len - 1
* If Protocol TCP * If Protocol TCP
* Goto Verify TCP * Goto Verify TCP
* If Protocol UDP * If Protocol UDP
* Goto Verify UDP * Goto Verify UDP
// Other protocols can be added here as needed, most likely same // Other protocols can be added here as needed, most likely same
// protocols as deep inspection does // protocols as deep inspection does
// Tunnel mode checks is also left out from here to make the // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for
// document shorter. // IPv6) is also left out from here to make the document shorter.
* Return Failure * Return Failure
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Verify TCP protocol headers // Verify TCP protocol headers
// //
Verify TCP: Verify TCP:
// First we check things that must be set correctly. // First we check things that must be set correctly.
* Check TCP.reserved_bits are non-zero * Check TCP.reserved_bits are non-zero
* Return Failure * Return Failure
* If TCP.Data_Offset field < 5 * If TCP.Data_Offset field < 5
skipping to change at page 32, line 37 skipping to change at page 34, line 37
// increment Check_Bits matching the number of bits checked. // increment Check_Bits matching the number of bits checked.
// //
// We can also check things here compared to the last packet // We can also check things here compared to the last packet
* If Last_Packet_Data.UDP.source_port = * If Last_Packet_Data.UDP.source_port =
Packet_Data.UDP.source_port and Packet_Data.UDP.source_port and
Last_Packet_Data.destination_port = Last_Packet_Data.destination_port =
Packet_Data.UDP.destination_port Packet_Data.UDP.destination_port
* Increment Check_Bits by 32 * Increment Check_Bits by 32
* Return Success * Return Success
Figure 3 Figure 4
Authors' Addresses Authors' Addresses
Tero Kivinen Tero Kivinen
Safenet, Inc. Safenet, Inc.
Fredrikinkatu 47 Fredrikinkatu 47
HELSINKI FIN-00100 HELSINKI FIN-00100
FI FI
Email: kivinen@iki.fi Email: kivinen@iki.fi
 End of changes. 45 change blocks. 
155 lines changed or deleted 211 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/