doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc5879.txt b/doc/rfc/rfc5879.txt
new file mode 100644
index 0000000..4616386
--- /dev/null
+++ b/doc/rfc/rfc5879.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Kivinen
+Request for Comments: 5879                               AuthenTec, Inc.
+Category: Informational                                      D. McDonald
+ISSN: 2070-1721                                       Oracle Corporation
+                                                                May 2010
+
+
+               Heuristics for Detecting ESP-NULL Packets
+
+Abstract
+
+   This document describes a set of heuristics for distinguishing IPsec
+   ESP-NULL (Encapsulating Security Payload without encryption) packets
+   from encrypted ESP packets.  These heuristics can be used on
+   intermediate devices, like traffic analyzers, and deep-inspection
+   engines, to quickly decide whether or not a given packet flow is
+   encrypted, i.e., whether or not it can be inspected.  Use of these
+   heuristics does not require any changes made on existing IPsec hosts
+   that are compliant with RFC 4303.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5879.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & McDonald            Informational                     [Page 1]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Applicability: Heuristic Traffic Inspection and
+           Wrapped ESP ................................................4
+      1.2. Terminology ................................................4
+   2. Other Options ...................................................5
+      2.1. AH .........................................................5
+      2.2. Mandating by Policy ........................................6
+      2.3. Modifying ESP ..............................................6
+   3. Description of Heuristics .......................................6
+   4. IPsec Flows .....................................................7
+   5. Deep-Inspection Engine ..........................................9
+   6. Special and Error Cases .........................................9
+   7. UDP Encapsulation ..............................................10
+   8. Heuristic Checks ...............................................10
+      8.1. ESP-NULL Format ...........................................11
+      8.2. Self Describing Padding Check .............................12
+      8.3. Protocol Checks ...........................................14
+           8.3.1. TCP Checks .........................................15
+           8.3.2. UDP Checks .........................................16
+           8.3.3. ICMP Checks ........................................16
+           8.3.4. SCTP Checks ........................................17
+           8.3.5. IPv4 and IPv6 Tunnel Checks ........................17
+   9. Security Considerations ........................................17
+   10. References ....................................................18
+      10.1. Normative References .....................................18
+      10.2. Informative References ...................................18
+   Appendix A.  Example Pseudocode ...................................20
+     A.1.  Fastpath ..................................................20
+     A.2.  Slowpath ..................................................23
+
+
+
+
+
+Kivinen & McDonald            Informational                     [Page 2]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+1.  Introduction
+
+   The ESP (Encapsulating Security Payload [RFC4303]) protocol can be
+   used with NULL encryption [RFC2410] to provide authentication,
+   integrity protection, and optionally replay detection, but without
+   confidentiality.  ESP without encryption (referred to as ESP-NULL)
+   offers similar properties to IPsec's AH (Authentication Header
+   [RFC4302]).  One reason to use ESP-NULL instead of AH is that AH
+   cannot be used if there are NAT (Network Address Translation) devices
+   on the path.  With AH, it would be easy to detect packets that have
+   only authentication and integrity protection, as AH has its own
+   protocol number and deterministic packet length.  With ESP-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
+   packets so they could perform deep inspection or enforce access
+   control.  This kind of deep inspection includes virus detection, spam
+   filtering, and intrusion detection.  As end nodes might be able to
+   bypass those checks by using encrypted ESP instead of ESP-NULL, these
+   kinds of scenarios also require very specific policies to forbid such
+   circumvention.
+
+   These sorts of policy requirements usually mean that the whole
+   network needs to be controlled, i.e., under the same administrative
+   domain.  Such setups are usually limited to inside the network of one
+   enterprise or organization, and encryption is not used as the network
+   is considered safe enough from eavesdroppers.
+
+   Because the traffic inspected is usually host-to-host traffic inside
+   one organization, that usually means transport mode IPsec is used.
+   Note, that most of the current uses of 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, the 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
+   ESP support easier detection of ESP-NULL in the future, this document
+   will aid in the transition of older end-systems.  That way, a
+   solution can be implemented immediately, and not after 5-10 years of
+   upgrade and deployment.  Even with protocol modification for end
+   nodes, the intermediate devices will need heuristics until they can
+   assume that those protocol modifications can be found from all 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.,
+
+
+
+
+
+Kivinen & McDonald            Informational                     [Page 3]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   publishing an RFC for what to do now, even though there might be a
+   new protocol coming in the future that will solve the same problem in
+   a better way.
+
+1.1.  Applicability: Heuristic Traffic Inspection and Wrapped ESP
+
+   There are two ways to enable intermediate security devices to
+   distinguish between encrypted and unencrypted ESP traffic:
+
+   o  The heuristics approach has the intermediate node inspect the
+      unchanged ESP traffic, to determine with extremely high
+      probability whether or not the traffic stream is encrypted.
+
+   o  The Wrapped ESP (WESP) approach [RFC5840], in contrast, requires
+      the ESP endpoints to be modified to support the new protocol.
+      WESP allows the intermediate node to distinguish encrypted and
+      unencrypted traffic deterministically, using a simpler
+      implementation for the intermediate node.
+
+   Both approaches are being documented simultaneously by the IPsecME
+   Working Group, with WESP being put on Standards Track while the
+   heuristics approach is being published as an Informational RFC.
+   While endpoints are being modified to adopt WESP, both approaches
+   will likely coexist for years, because the heuristic approach is
+   needed to inspect traffic where at least one of the endpoints has not
+   been modified.  In other words, intermediate nodes are expected to
+   support both approaches in order to achieve good security and
+   performance during the transition period.
+
+1.2.  Terminology
+
+   This document uses following terminology:
+
+   Flow
+
+      A TCP/UDP or IPsec flow is a stream of packets that are part of
+      the same TCP/UDP or IPsec stream, i.e., TCP or UDP flow is a
+      stream of packets having same 5 tuple (source and destination IP
+      and port, and TCP/UDP protocol).  Note, that this kind of flow is
+      also called microflow in some documents.
+
+   Flow Cache
+
+      deep-inspection engines and similar devices use a cache of flows
+      going through the device, and that cache keeps state of all flows
+      going through the device.
+
+
+
+
+
+Kivinen & McDonald            Informational                     [Page 4]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   IPsec Flow
+
+      An IPsec flow is a stream of packets sharing the same source IP,
+      destination IP, protocol (ESP/AH), and Security Parameter Index
+      (SPI).  Strictly speaking, the source IP does not need to be a
+      part of the flow identification, but it can be.  For this reason,
+      it is safer to assume that the source IP is always part of the
+      flow identification.
+
+2.  Other Options
+
+   This document will discuss the heuristic approach of detecting ESP-
+   NULL packets.  There are some other options that can be used, and
+   this section will briefly discuss them.
+
+2.1.  AH
+
+   The most logical approach would use the already defined protocol that
+   offers authentication and integrity protection, but not
+   confidentiality, namely AH.  AH traffic is clearly marked as not
+   encrypted, and can always be inspected by intermediate devices.
+
+   Using AH has two problems.  First, as it also protects the IP
+   headers, it will also protect against NATs on the path; thus, it will
+   not work if there is a NAT on the path between end nodes.  In some
+   environments this might not be a problem, but some environments,
+   include heavy use of NATs even inside the internal network of the
+   enterprise or organization.  NAT-Traversal (NAT-T, [RFC3948]) could
+   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
+   necessary.
+
+   Another problem is that in the new IPsec Architecture [RFC4301] the
+   support for AH is now optional, meaning not all implementations
+   support it.  ESP-NULL has been defined to be mandatory to implement
+   by "Cryptographic Algorithm Implementation Requirements for
+   Encapsulating Security Payload (ESP) and Authentication Header (AH)"
+   [RFC4835].
+
+   AH also has quite complex processing rules compared to ESP when
+   calculating the Integrity Check Value (ICV), including things like
+   zeroing out mutable fields.  Also, as AH is not as widely used as
+   ESP, the AH support is not as well tested in the interoperability
+   events.
+
+
+
+
+
+
+
+Kivinen & McDonald            Informational                     [Page 5]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+2.2.  Mandating by Policy
+
+   Another easy way to solve this problem is to mandate the use of ESP-
+   NULL with common parameters within an entire organization.  This
+   either removes the need for heuristics (if no ESP-encrypted traffic
+   is allowed at all) or simplifies them considerably (only one set of
+   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
+   algorithm).  This does work unless one of a pair of communicating
+   machines is not under the same administrative domain as the deep-
+   inspection engine.  (IPsec Security Associations (SAs) must be
+   satisfactory 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,
+   and that changes to that single policy can be coordinated throughout
+   the administrative domain.
+
+2.3.  Modifying ESP
+
+   Several documents discuss ways of modifying ESP to offer intermediate
+   devices information about an ESP packet's use of NULL encryption.
+   The following methods have been discussed: adding an IP-option,
+   adding a new IP-protocol number plus an extra header [RFC5840],
+   adding new IP-protocol numbers that tell the ESP-NULL parameters
+   [AUTH-ONLY-ESP], reserving an SPI range for ESP-NULL [ESP-NULL], and
+   using UDP encapsulation with a different format and ports.
+
+   All of the aforementioned documents require modification to ESP,
+   which requires that all end nodes be modified before intermediate
+   devices can assume that this new ESP format is in use.  Updating end
+   nodes will require a lot of time.  An example of slow end-node
+   deployment is Internet Key Exchange Protocol version 2 (IKEv2).
+   Considering an implementation that requires both IKEv2 and a new ESP
+   format, it would take several years, possibly as long as a decade,
+   before widespread deployment.
+
+3.  Description of Heuristics
+
+   The heuristics to detect ESP-NULL packets will only require changes
+   to those intermediate devices that do deep inspection or other
+   operations that require the detection of ESP-NULL.  As those nodes
+   require changes regardless of any ESP-NULL method, updating
+   intermediate nodes is unavoidable.  Heuristics do not require updates
+   or modifications to any other devices on the rest of the network,
+   including (especially) end nodes.
+
+
+
+
+
+Kivinen & McDonald            Informational                     [Page 6]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   In this document, it is assumed that an affected intermediate node
+   will act as a stateful interception device, meaning it will keep
+   state of the IPsec flows -- where flows are defined by the ESP SPI
+   and IP addresses forming an IPsec SA -- going through it.  The
+   heuristics can also be used without storing any state, but
+   performance will be worse in that case, as heuristic checks will need
+   to be done for each packet, not only once per flow.  This will also
+   affect the reliability of the heuristics.
+
+   Generally, an intermediate node runs heuristics only for the first
+   few packets of the new flow (i.e., the new IPsec SA).  After those
+   few packets, the node detects parameters of the IPsec flow, it skips
+   detection heuristics, and it can perform direct packet-inspecting
+   action based on its own policy.  Once detected, ESP-NULL packets will
+   never be detected as encrypted ESP packets, meaning that valid ESP-
+   NULL packets will never bypass the deep inspection.
+
+   The only failure mode of these heuristics is to assume encrypted ESP
+   packets are ESP-NULL packets, thus causing completely random packet
+   data to be deeply inspected.  An attacker can easily send random-
+   looking ESP-NULL packets that will cause heuristics to detect packets
+   as encrypted ESP, but that is no worse than sending non-ESP fuzz
+   through an intermediate node.  The only way an ESP-NULL flow can be
+   mistaken for an encrypted ESP flow is if the ESP-NULL flow uses an
+   authentication algorithm of which the packet inspector has no
+   knowledge.
+
+   For hardware implementations, all the flow lookup based on the ESP
+   next header number (50), source address, destination address, and SPI
+   can be done by the hardware (there is usually already similar
+   functionality there, for TCP/UDP flows).  The heuristics can be
+   implemented by the hardware, but using software will allow faster
+   updates when new protocol modifications come out or new protocols
+   need support.
+
+   As described in Section 7, UDP-encapsulated ESP traffic may also have
+   Network Address Port Translation (NAPT) applied to it, and so there
+   is already a 5-tuple state in the stateful inspection gateway.
+
+4.  IPsec Flows
+
+   ESP is a stateful protocol, meaning there is state stored in both end
+   nodes of the ESP IPsec SA, and the state is identified by the pair of
+   destination IP and SPI.  Also, end nodes often fix the source IP
+   address in an SA unless the destination is a multicast group.
+   Typically, most (if not all) flows of interest to an intermediate
+   device are unicast, so it is safer to assume the receiving node also
+   uses a source address, and the intermediate device should therefore
+
+
+
+Kivinen & McDonald            Informational                     [Page 7]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   do the same.  In some cases, this might cause extraneous cached ESP
+   IPsec SA flows, but by using the source address, two distinct flows
+   will never be mixed.  For sites that 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
+   flow of ESP packets where the source address, destination address,
+   and SPI number form a triplet that has not been cached, it will start
+   the heuristics to detect whether or not this flow is ESP-NULL.  These
+   heuristics appear in Section 8.
+
+   When the heuristics finish, they will label the flow as either
+   encrypted (which tells that packets in this flow are encrypted, and
+   cannot be ESP-NULL packets) or as ESP-NULL.  This information, along
+   with the ESP-NULL parameters detected by the heuristics, is stored to
+   a flow cache, which will be used in the future when processing
+   packets of the same flow.
+
+   Both encrypted ESP and ESP-NULL flows are processed based on the
+   local policy.  In normal operation, encrypted ESP flows are passed
+   through or dropped per local policy, and ESP-NULL flows are passed to
+   the deep-inspection engine.  Local policy will also be used to
+   determine other packet-processing parameters.  Local policy issues
+   will be clearly marked in this document to ease implementation.
+
+   In some cases, the heuristics cannot determine the type of flow from
+   a single packet; and in that case, it might need multiple packets
+   before it can finish the process.  In those cases, the heuristics
+   return "unsure" status.  In that case, the packet processed based on
+   the local policy and flow cache is updated with "unsure" status.
+   Local policy for "unsure" packets could range from dropping (which
+   encourages end-node retransmission) to queuing (which may preserve
+   delivery, at the cost of artificially inflating round-trip times if
+   they are measured).  When the next packet to the flow arrives, it is
+   heuristically processed again, and the cached flow may continue to be
+   "unsure", marked as ESP, or marked as an ESP-NULL flow.
+
+   There are several reasons why a single packet might not be enough to
+   detect the type of flow.  One of them is that the next header number
+   was unknown, i.e., if heuristics do not know about the protocol for
+   the packet, they cannot verify it has properly detected ESP-NULL
+   parameters, even when the packet otherwise looks like ESP-NULL.  If
+   the packet does not look like ESP-NULL at all, then the encrypted ESP
+
+
+
+
+
+Kivinen & McDonald            Informational                     [Page 8]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   status can be returned quickly.  As ESP-NULL heuristics need to know
+   the same protocols as a deep-inspection device, an ESP-NULL instance
+   of an unknown protocol can be handled the same way as a cleartext
+   instance of the same unknown protocol.
+
+5.  Deep-Inspection Engine
+
+   A deep-inspection engine running on an intermediate node usually
+   checks deeply into the packet and performs policy decisions based on
+   the contents of the packet.  The deep-inspection engine should be
+   able to tell the difference between success, failure, and garbage.
+   Success means that a packet was successfully checked with the deep-
+   inspection engine, and it passed the checks and is allowed to be
+   forwarded.  Failure means that a packet was successfully checked, but
+   the actual checks done indicated that packets should be dropped,
+   i.e., the packet contained a virus, was a known attack, or something
+   similar.
+
+   Garbage means that the packet's protocol headers or other portions
+   were unparseable.  For the heuristics, it would be useful if the
+   deep-inspection engine could differentiate the garbage and failure
+   cases, as garbage cases can be used to detect certain error cases
+   (e.g., where the ESP-NULL parameters are incorrect, or the flow is
+   really an encrypted ESP flow, not an ESP-NULL flow).
+
+   If the deep-inspection engine only returns failure for all garbage
+   packets in addition to real failure cases, then a system implementing
+   the ESP-NULL heuristics cannot recover from error situations quickly.
+
+6.  Special and Error Cases
+
+   There is a small probability that an encrypted ESP packet (which
+   looks like it contains completely random bytes) will have plausible
+   bytes in expected locations, such that heuristics will detect the
+   packet as an ESP-NULL packet instead of detecting that it is
+   encrypted ESP packet.  The actual probabilities will be computed
+   later in this document.  Such a packet will not cause problems, as
+   the deep-inspection engine will most likely reject the packet and
+   return that it is garbage.  If the deep-inspection engine is
+   rejecting a high number of packets as garbage, it might indicate an
+   original ESP-NULL detection for the flow was wrong (i.e., an
+   encrypted ESP flow was improperly detected as ESP-NULL).  In that
+   case, the cached flow should be invalidated and discovery should
+   happen again.
+
+   Each ESP-NULL flow should also keep statistics about how many packets
+   have been detected as garbage by deep inspection, how many have
+   passed checks, or how many have failed checks with policy violations
+
+
+
+Kivinen & McDonald            Informational                     [Page 9]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   (i.e., failed because of actual inspection policy failures, not
+   because the packet looked like garbage).  If the number of garbage
+   packets suddenly increases (e.g., most of the packets start to look
+   like garbage according to the deep-inspection engine), it is possible
+   the old ESP-NULL SA was replaced by an encrypted ESP SA with an
+   identical SPI.  If both ends use random SPI generation, this is a
+   very unlikely situation (1 in 2^32), but it is possible that some
+   nodes reuse SPI numbers (e.g., a 32-bit memory address of the SA
+   descriptor); thus, this situation needs to be handled.
+
+   Actual limits for cache invalidation are local policy decisions.
+   Sample invalidation policies include: 50% of packets marked as
+   garbage within a second, or if a deep-inspection engine cannot
+   differentiate between garbage and failure, failing more than 95% of
+   packets in last 10 seconds.  For implementations that do not
+   distinguish between garbage and failure, failures should not be
+   treated too quickly as an indication of SA reuse.  Often, single
+   packets cause state-related errors that block otherwise normal
+   packets from passing.
+
+7.  UDP Encapsulation
+
+   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
+   them after skipping the UDP header.  Port-translation by NAT often
+   rewrites what was originally 4500 into a different value, which means
+   each unique port pair constitutes a separate IPsec flow.  That is,
+   UDP-encapsulated IPsec flows are identified by the source and
+   destination IP, source and destination port number, and SPI number.
+   As devices might be using IKEv2 Mobility and Multihoming (MOBIKE)
+   ([RFC4555]), that also means that the flow cache should be shared
+   between the UDP encapsulated IPsec flows and non-encapsulated IPsec
+   flows.  As previously mentioned, differentiating between garbage and
+   actual policy failures will help in proper detection immensely.
+
+   Because the checks are run for packets having just source port 4500
+   or packets having just destination port 4500, this might cause checks
+   to be run for non-ESP traffic too.  Some traffic may randomly use
+   port 4500 for other reasons, especially if a port-translating NAT is
+   involved.  The UDP encapsulation processing should also be aware of
+   that possibility.
+
+8.  Heuristic Checks
+
+   Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability
+   that a random packet will pass the Hashed Message Authentication Code
+   (HMAC) test.  This yields a 99.999999999999999999999999998%
+   probability that an end node will correctly detect a random packet as
+
+
+
+Kivinen & McDonald            Informational                    [Page 10]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   being invalid.  This means that it should be enough for an
+   intermediate device to check around 96 bits from the input packet.
+   By comparing them against known values for the packet, a deep-
+   inspection engine gains more or less the same probability as that
+   which an end node is using.  This gives an upper limit of how many
+   bits heuristics need to check -- there is no point of checking much
+   more than that many bits (since that same probability is acceptable
+   for the end node).  In most of the cases, the intermediate device
+   does not need probability that is that high, perhaps something around
+   32-64 bits is enough.
+
+   IPsec's ESP has a well-understood packet layout, but its variable-
+   length fields reduce the ability of pure algorithmic matching to one
+   requiring heuristics and assigning probabilities.
+
+8.1.  ESP-NULL Format
+
+   The ESP-NULL format is as follows:
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                Security Parameter Index (SPI)                 |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                      Sequence Number                          |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                    IV (optional)                              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                    Payload Data (variable)                    |
+       ~                                                               ~
+       |                                                               |
+       +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |               |     Padding (0-255 bytes)                     |
+       +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                               |  Pad Length   | Next Header   |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             Integrity Check Value (variable)                  |
+       ~                                                               ~
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                 Figure 1
+
+   The output of the heuristics should provide information about whether
+   the packet is encrypted ESP or ESP-NULL.  In case it is ESP-NULL, the
+   heuristics should also provide the Integrity Check Value (ICV) field
+   length and the Initialization Vector (IV) length.
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 11]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   The currently defined ESP authentication algorithms have 4 different
+   lengths for the ICV field.
+
+   Different ICV lengths for different algorithm:
+
+       Algorithm                           ICV Length
+       -------------------------------     ----------
+       AUTH_HMAC_MD5_96                    96
+       AUTH_HMAC_SHA1_96                   96
+       AUTH_AES_XCBC_96                    96
+       AUTH_AES_CMAC_96                    96
+       AUTH_HMAC_SHA2_256_128              128
+       AUTH_HMAC_SHA2_384_192              192
+       AUTH_HMAC_SHA2_512_256              256
+
+                                 Figure 2
+
+   In addition to the ESP authentication algorithms listed above, there
+   is also the encryption algorithm ENCR_NULL_AUTH_AES_GMAC, which does
+   not provide confidentiality but provides authentication, just like
+   ESP-NULL.  This algorithm has an ICV Length of 128 bits, and it also
+   requires 8 bytes of IV.
+
+   In addition to the ICV length, there are also two possible values for
+   IV lengths: 0 bytes (default) and 8 bytes (for
+   ENCR_NULL_AUTH_AES_GMAC).  Detecting the IV length requires
+   understanding the payload, i.e., the actual protocol data (meaning
+   TCP, UDP, etc.).  This is required to distinguish the optional IV
+   from the actual protocol data.  How well the IV can be distinguished
+   from the actual protocol data depends on how the IV is generated.  If
+   the IV is generated using a method that generates random-looking data
+   (i.e., encrypted counter, etc.) then distinguishing protocol data
+   from the IV is quite easy.  If an IV is a counter or similar non-
+   random value, then there are more possibilities for error.  If the
+   protocol (also known as the, "next header") of the packet is one that
+   is not supported by the heuristics, then detecting the IV length is
+   impossible; thus, the heuristics cannot finish.  In that case, the
+   heuristics return "unsure" and require further packets.
+
+   This document does not cover RSA authentication in ESP ([RFC4359]),
+   as it is considered beyond the scope of this document.
+
+8.2.  Self Describing Padding Check
+
+   Before obtaining the next header field, the ICV length must be
+   measured.  Four different ICV lengths lead to four possible places
+   for the pad length and padding.  Implementations must be careful when
+   trying larger sizes of the ICV such that the inspected bytes do not
+
+
+
+Kivinen & McDonald            Informational                    [Page 12]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   belong to data that is not payload data.  For example, a 10-byte ICMP
+   echo request will have zero-length padding, but any checks for
+   256-bit ICVs will inspect sequence number or SPI data if the packet
+   actually contains a 96-bit or 128-bit ICV.
+
+   ICV lengths should always be checked from shortest to longest.  It is
+   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
+   than what is currently inspected.  For example, if a packet has a
+   96-bit ICV and the implementation starts checking for a 256-bit ICV
+   first, it is possible that the cleartext part of the payload contains
+   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
+   first, the inspected bytes are part of the longer ICV field, and
+   should be indistinguishable from random noise.
+
+   Each ESP packet always has between 0-255 bytes of padding, and
+   payload, pad length, and next header are always right aligned within
+   a 4-byte boundary.  Normally, implementations use a minimal amount of
+   padding, but the heuristics method would be even more reliable if
+   some extra padding is added.  The actual padding data has bytes
+   starting from 01 and ending at the pad length, i.e., exact padding
+   and 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
+   above), or the 0-byte padding case.  In cases where there is one or
+   more bytes of padding, a node can perform a very simple and fast test
+   -- a sequence of N N in any of those four locations.  Given four
+   2-byte locations (assuming the packet size allows all four possible
+   ICV lengths), the upper-bound probability of finding a random
+   encrypted packet that exhibits non-zero length ESP-NULL properties
+   is:
+
+   1 - (1 - 255 / 65536) ^ 4 == 0.015 == 1.5%
+
+   In the cases where there are 0 bytes of padding, a random encrypted
+   ESP packet has:
+
+   1 - (1 - 1 / 256) ^ 4 == 0.016 == 1.6%.
+
+   Together, both cases yield a 3.1% upper-bound chance of
+   misclassifying an encrypted packet as an ESP-NULL packet.
+
+   In the matched bytes case, further inspection (counting the pad bytes
+   backward and downward from the pad-length match) can reduce the
+   number of misclassified packets further.  A padding length of 255
+   means a specific 256^254 sequence of bytes must occur.  This
+   virtually eliminates pairs of 'FF FF' as viable ESP-NULL padding.
+
+
+
+Kivinen & McDonald            Informational                    [Page 13]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   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
+   aforementioned 1.5% of matched pairs to virtually nothing.
+
+   At this point, a maximum of 1.6% of possible byte values remain, so
+   the next header number is inspected.  If the next header number is
+   known (and 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 with protocol checking support) the packet is marked
+   "unsure", because there is no way to detect the IV length without
+   inspecting the inner protocol payload.
+
+   There are six different next header fields that are in common use
+   (TCP (6), UDP (17), ICMP (1), Stream Control Transmission Protocol
+   (SCTP) (132), IPv4 (4), and IPv6 (41)), 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 is misinterpreted as an
+   encrypted ESP packet even when it is an ESP-NULL packet, a packet
+   cannot be marked as a failure even when the next header number is one
+   of those that is not known and supported.  In those cases, the
+   packets are marked as "unsure".
+
+   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
+   counting how many "unsure" returns obtained via heuristics, and after
+   the receipt of a consistent, but unknown, next header number in same
+   location (i.e., likely with the same ICV length), the node can
+   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
+   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.  If the protocol is unknown to the heuristics, it will most
+   likely be unknown by the deep-inspection engine also.  It is
+   therefore important that heuristics should support at least those
+   same protocols as the deep-inspection engine.  Upon receipt of any
+   inner next header number that is known by the heuristics (and deep-
+   inspection engine), the heuristics can detect the IV length properly.
+
+8.3.  Protocol Checks
+
+   Generic protocol checking is much easier with preexisting state.  For
+   example, when many TCP/UDP flows are established over one IPsec SA, a
+   rekey produces a new SA that needs heuristics to detect its
+   parameters, and those heuristics benefit from the existing TCP/UDP
+   flows that were present in the previous IPsec SA.  In that case, it
+
+
+
+Kivinen & McDonald            Informational                    [Page 14]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   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 indication that the new SA is really ESP-NULL.
+
+   The worst case scenario is when an end node starts up communication,
+   i.e., it does not have any previous flows through the device.
+   Heuristics will run on the first few packets received from the end
+   node.  The later subsections mainly cover these start-up cases, as
+   they are the most difficult.
+
+   In the protocol checks, there are two different types of checks.  The
+   first check is for packet validity, i.e., certain locations must
+   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
+   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,
+   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.
+
+   The second type of check is for variable, but easy-to-parse values.
+   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.
+   If the header-length has that specific value, the number of known
+   "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 that is over a threshold (for example, 96 bits), causing a
+   packet to be marked as valid.
+
+8.3.1.  TCP Checks
+
+   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
+   less useful information than other later packets might have.  The
+   best valid packet checks include checking that header length and
+   flags have valid values and checking source and destination port
+   numbers, which in some cases can be used for heuristics (but in
+   general they cannot be reliably distinguished from 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
+   possible that the packet has already transited a NAT box that changed
+   the IP addresses but assumed any ESP payload was encrypted and did
+   not fix the transport checksums with the new IP addresses.  Thus, the
+   IP numbers used in the checksum are wrong; thus, the checksum is
+   wrong.  If the checksum is correct, it can again be used to increase
+   the valid bit count, but verifying checksums is a costly operation,
+   thus skipping that check might be best unless there is hardware to
+
+
+
+Kivinen & McDonald            Informational                    [Page 15]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   help the calculation.  Window size, urgent pointer, sequence number,
+   and acknowledgment numbers can be used, but there is not one specific
+   known value for them.
+
+   One good method of detection is that if a packet is dropped, then the
+   next packet will most likely be a retransmission of the previous
+   packet.  Thus, if two packets are received with the same source and
+   destination port numbers, and where sequence numbers are either the
+   same or right after each other, then it's likely a TCP packet has
+   been correctly detected.  This heuristic is most helpful when only
+   one packet is outstanding.  For example, if a TCP SYN packet is lost
+   (or dropped because of policy), the next packet would always be a
+   retransmission of the same TCP SYN packet.
+
+   Existing deep-inspection engines usually do very good TCP flow
+   checking already, including flow tracking, verification of sequence
+   numbers, and reconstruction of the whole TCP flow.  Similar methods
+   can be used here, but they are implementation dependent and not
+   described here.
+
+8.3.2.  UDP Checks
+
+   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
+   checksum, due to NATs.  The UDP length field might not match the
+   overall packet length, as the sender is allowed to include TFC
+   (traffic flow confidentiality; see Section 2.7 of "IP Encapsulating
+   Security Payload" [RFC4303]) padding.
+
+   With UDP packets similar multiple packet methods can be used as with
+   TCP, as UDP protocols usually include several packets using same port
+   numbers going from one end node to another, thus receiving multiple
+   packets having a known pair of UDP port numbers is good indication
+   that the heuristics have passed.
+
+   Some UDP protocols also use identical source and destination port
+   numbers; thus, that is also a good check.
+
+8.3.3.  ICMP Checks
+
+   As ICMP messages are usually sent as return packets for other
+   packets, they are not very common packets to get as first packets for
+   the SA, the ICMP ECHO_REQUEST message being a noteworthy exception.
+   ICMP ECHO_REQUEST has a known type, code, identifier, and sequence
+   number.  The checksum, however, might be incorrect again because of
+   NATs.
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 16]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   For ICMP error messages, the ICMP message contains part of the
+   original IP packet inside.  Then, the same rules that are used to
+   detect IPv4/IPv6 tunnel checks can be used.
+
+8.3.4.  SCTP Checks
+
+   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-
+   aware.  Even more than the TCP and UDP checksums, the SCTP checksum
+   is expensive, and may be prohibitive even for deep packet
+   inspections.
+
+   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
+   not present.
+
+8.3.5.  IPv4 and IPv6 Tunnel Checks
+
+   In cases of tunneled traffic, the packet inside contains a full IPv4
+   or IPv6 packet.  Many fields are usable.  For IPv4, those fields
+   include version, header length, total length (again TFC padding might
+   confuse things there), protocol number, and 16-bit header checksum.
+   In those cases, the intermediate device should give the decapsulated
+   IP packet to the deep-inspection engine.  IPv6 has fewer usable
+   fields, but the version number, packet length (modulo TFC confusion),
+   and next header all can be used by deep packet inspection.
+
+   If all traffic going through the intermediate device is either from
+   or to certain address blocks (for example, either to or from the
+   company intranet prefix), this can also be checked by the heuristics.
+
+9.  Security Considerations
+
+   Attackers can always bypass ESP-NULL deep packet inspection by using
+   encrypted ESP (or some other encryption or tunneling method) instead,
+   unless the intermediate node's policy requires dropping of packets
+   that it cannot inspect.  Ultimately, the responsibility for
+   performing deep inspection, or allowing intermediate nodes to perform
+   deep inspection, must rest on the end nodes.  That is, if a server
+   allows encrypted connections also, then an attacker who wants to
+   attack the server and wants to bypass a deep-inspection device in the
+   middle, will use encrypted traffic.  This means that the protection
+   of the whole 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 to forbid encrypted ESP completely, in which case
+   ESP-NULL detection is easier, as all packets must be ESP-NULL based
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 17]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   on the policy (heuristics may still be needed to find out the IV and
+   ICV lengths, unless further policy restrictions eliminate the
+   ambiguities).
+
+   Section 3 discusses failure modes of the heuristics.  An attacker can
+   poison flows, tricking inspectors into ignoring legitimate ESP-NULL
+   flows, but that is no worse than injecting fuzz.
+
+   Forcing the use of ESP-NULL everywhere inside the enterprise, so that
+   accounting, logging, network monitoring, and intrusion detection all
+   work, increases the risk of sending confidential information where
+   eavesdroppers can see it.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2410]    Glenn, R. and S. Kent, "The NULL Encryption Algorithm
+                and Its Use With IPsec", RFC 2410, November 1998.
+
+   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4302]    Kent, S., "IP Authentication Header", RFC 4302,
+                December 2005.
+
+   [RFC4303]    Kent, S., "IP Encapsulating Security Payload (ESP)",
+                RFC 4303, December 2005.
+
+10.2.  Informative References
+
+   [AUTH-ONLY-ESP]
+                Hoffman, P. and D. McGrew, "An Authentication-only
+                Profile for ESP with an IP Protocol Identifier", Work
+                in Progress, August 2007.
+
+   [ESP-NULL] Bhatia, M., "Identifying ESP-NULL Packets", Work
+                in Progress, December 2008.
+
+   [RFC3948]    Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
+                M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
+                RFC 3948, January 2005.
+
+   [RFC4359]    Weis, B., "The Use of RSA/SHA-1 Signatures within
+                Encapsulating Security Payload (ESP) and Authentication
+                Header (AH)", RFC 4359, January 2006.
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 18]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   [RFC4555]    Eronen, P., "IKEv2 Mobility and Multihoming Protocol
+                (MOBIKE)", RFC 4555, June 2006.
+
+   [RFC4835]    Manral, V., "Cryptographic Algorithm Implementation
+                Requirements for Encapsulating Security Payload (ESP)
+                and Authentication Header (AH)", RFC 4835, April 2007.
+
+   [RFC4960]    Stewart, R., "Stream Control Transmission Protocol",
+                RFC 4960, September 2007.
+
+   [RFC5840]    Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped
+                Encapsulating Security Payload (ESP) for Traffic
+                Visibility", RFC 5840, April 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 19]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+Appendix A.  Example Pseudocode
+
+   This appendix is meant for the implementors.  It does not include all
+   the required checks, and this is just example pseudocode, so final
+   implementation can be very different.  It mostly lists things that
+   need to be done, but implementations can optimize steps depending on
+   their other parts.  For example, implementation might combine
+   heuristics and deep inspection tightly together.
+
+A.1.  Fastpath
+
+   The following example pseudocode show the fastpath part of the packet
+   processing engine.  This part is usually implemented in hardware.
+
+   ////////////////////////////////////////////////////////////
+   // This pseudocode uses following variables:
+   //
+   // SPI_offset:    Number of bytes between start of protocol
+   //                data and SPI.  This is 0 for ESP and
+   //                8 for UDP-encapsulated ESP (i.e, skipping
+   //                UDP header).
+   //
+   // IV_len:        Length of the IV of the ESP-NULL packet.
+   //
+   // ICV_len:       Length of the ICV of the ESP-NULL packet.
+   //
+   // State:         State of the packet, i.e., ESP-NULL, ESP, or
+   //                unsure.
+   //
+   // Also following data is taken from the packet:
+   //
+   // IP_total_len:  Total IP packet length.
+   // IP_hdr_len:    Header length of IP packet in bytes.
+   // IP_Src_IP:     Source address of IP packet.
+   // IP_Dst_IP:     Destination address of IP packet.
+   //
+   // UDP_len:       Length of the UDP packet taken from UDP header.
+   // UDP_src_port:  Source port of UDP packet.
+   // UDP_dst_port:  Destination port of UDP packet.
+   //
+   // SPI:           SPI number from ESP packet.
+   //
+   // Protocol:      Actual protocol number of the protocol inside
+   //                ESP-NULL packet.
+   // Protocol_off:  Calculated offset to the protocol payload data
+   //                inside ESP-NULL packet.
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 20]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   ////////////////////////////////////////////////////////////
+   // This is the main processing code for the packet
+   // This will check if the packet requires ESP processing,
+   //
+   Process packet:
+     * If IP protocol is ESP
+          * Set SPI_offset to 0 bytes
+          * Goto Process ESP
+     * If IP protocol is UDP
+          * Goto Process UDP
+     * If IP protocol is WESP
+          // For information about WESP processing, see WESP
+          // specification.
+          * Continue WESP processing
+     * Continue Non-ESP processing
+
+   ////////////////////////////////////////////////////////////
+   // This code is run for UDP packets, and it checks if the
+   // packet is UDP encapsulated UDP packet, or UDP
+   // encapsulated IKE packet, or keepalive packet.
+   //
+   Process UDP:
+     // Reassembly is not mandatory here, we could
+     // do reassembly also only after detecting the
+     // packet being UDP encapsulated ESP packet, but
+     // that would complicate the pseudocode here
+     // a lot, as then we would need to add code
+     // for checking whether or not the UDP header is in this
+     // packet.
+     // Reassembly is to simplify things
+     * If packet is fragment
+          * Do full reassembly before processing
+     * If UDP_src_port != 4500 and UDP_dst_port != 4500
+          * Continue Non-ESP processing
+     * Set SPI_offset to 8 bytes
+     * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000
+          * Continue Non-ESP processing (pass IKE-packet)
+     * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000002
+          * Continue WESP processing
+     * If UDP_len == 1 and first byte is 0xff
+          * Continue Non-ESP processing (pass NAT-Keepalive Packet)
+     * Goto Process ESP
+
+
+
+
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 21]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+   ////////////////////////////////////////////////////////////
+   // This code is run for ESP packets (or UDP-encapsulated ESP
+   // packets).  This checks if IPsec flow is known, and
+   // if not calls heuristics.  If the IPsec flow is known
+   // then it continues processing based on the policy.
+   //
+   Process ESP:
+     * If packet is fragment
+          * Do full reassembly before processing
+     * If IP_total_len < IP_hdr_len + SPI_offset + 4
+          // If this packet was UDP encapsulated ESP packet then
+          // this might be valid UDP packet that might
+          // be passed or dropped depending on policy.
+          * Continue normal packet processing
+     * Load SPI from IP_hdr_len + SPI_offset
+     * Initialize State to ESP
+     // In case this was UDP encapsulated ESP, use UDP_src_port and
+     // UDP_dst_port also when finding data from SPI cache.
+     * Find IP_Src_IP + IP_Dst_IP + SPI from SPI cache
+     * If SPI found
+          * Load State, IV_len, ICV_len from cache
+     * If SPI not found or State is unsure
+          * Call Autodetect ESP parameters (drop to slowpath)
+     * If State is ESP
+          * Continue Non-ESP-NULL processing
+     * Goto Check ESP-NULL packet
+
+   ////////////////////////////////////////////////////////////
+   // This code is run for ESP-NULL packets, and this
+   // finds out the data required for deep-inspection
+   // engine (protocol number, and offset to data)
+   // and calls the deep-inspection engine.
+   //
+   Check ESP-NULL packet:
+     * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len
+                    + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
+          // This packet was detected earlier as being part of
+          // ESP-NULL flow, so this means that either ESP-NULL
+          // was replaced with other flow or this is an invalid packet.
+          // Either drop or pass the packet, or restart
+          // heuristics based on the policy
+          * Continue packet processing
+     * Load Protocol from IP_total_len - ICV_len - 1
+     * Set Protocol_off to
+           IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no)
+     * Do normal deep inspection on packet.
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 22]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+                                 Figure 3
+
+A.2.  Slowpath
+
+   The following example pseudocode shows the actual heuristics part of
+   the packet processing engine.  This part is usually implemented in
+   software.
+
+  ////////////////////////////////////////////////////////////
+  // This pseudocode uses following variables:
+  //
+  // SPI_offset, IV_len, ICV_len, State, SPI,
+  // IP_total_len, IP_hdr_len, IP_Src_IP, IP_Dst_IP
+  // as defined in fastpath pseudocode.
+  //
+  // Stored_Check_Bits:Number of bits we have successfully
+  //                   checked to contain acceptable values
+  //                   in the actual payload data.  This value
+  //                   is stored/retrieved from SPI cache.
+  //
+  // Check_Bits:       Number of bits we have successfully
+  //                   checked to contain acceptable values
+  //                   in the actual payload data.  This value
+  //                   is updated during the packet
+  //                   verification.
+  //
+  // Last_Packet_Data: Contains selected pieces from the
+  //                   last packet.  This is used to compare
+  //                   certain fields of this packet to
+  //                   same fields in previous packet.
+  //
+  // Packet_Data:      Selected pieces of this packet, same
+  //                   fields as Last_Packet_Data, and this
+  //                   is stored as new Last_Packet_Data to
+  //                   SPI cache after this packet is processed.
+  //
+  // Test_ICV_len:     Temporary ICV length used during tests.
+  //                   This is stored to ICV_len when
+  //                   padding checks for the packet succeed
+  //                   and the packet didn't yet have unsure
+  //                   status.
+  //
+  // Test_IV_len:      Temporary IV length used during tests.
+  //
+  // Pad_len:          Padding length from the ESP packet.
+  //
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 23]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+  // Protocol:         Protocol number of the packet inside ESP
+  //                   packet.
+  //
+  // TCP.*:            Fields from TCP header (from inside ESP)
+  // UDP.*:            Fields from UDP header (from inside ESP)
+
+  ////////////////////////////////////////////////////////////
+  // This code starts the actual heuristics.
+  // During this the fastpath has already loaded
+  // State, ICV_len, and IV_len in case they were
+  // found from the SPI cache (i.e., in case the flow
+  // had unsure status).
+  //
+  Autodetect ESP parameters:
+    // First, we check if this is unsure flow, and
+    // if so, we check next packet against the
+    // already set IV/ICV_len combination.
+    * If State is unsure
+         * Call Verify next packet
+         * If State is ESP-NULL
+              * Goto Store ESP-NULL SPI cache info
+         * If State is unsure
+              * Goto Verify unsure
+         // If we failed the test, i.e., State
+         // was changed to ESP, we check other
+         // ICV/IV_len values, i.e., fall through
+    // ICV lengths are tested in order of ICV lengths,
+    // from shortest to longest.
+    * Call Try standard algorithms
+    * If State is ESP-NULL
+         * Goto Store ESP-NULL SPI cache info
+    * Call Try 128bit algorithms
+    * If State is ESP-NULL
+         * Goto Store ESP-NULL SPI cache info
+    * Call Try 192bit algorithms
+    * If State is ESP-NULL
+         * Goto Store ESP-NULL SPI cache info
+    * Call Try 256bit algorithms
+    * If State is ESP-NULL
+         * Goto Store ESP-NULL SPI cache info
+    // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from
+    // this document.
+    // If any of those test above set state to unsure
+    // we mark IPsec flow as unsure.
+    * If State is unsure
+         * Goto Store unsure SPI cache info
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 24]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+    // All of the test failed, meaning the packet cannot
+    // be ESP-NULL packet, thus we mark IPsec flow as ESP
+    * Goto Store ESP SPI cache info
+  ////////////////////////////////////////////////////////////
+  // Store ESP-NULL status to the IPsec flow cache.
+  //
+  Store ESP-NULL SPI cache info:
+    * Store State, IV_len, ICV_len to SPI cache
+            using IP_Src_IP + IP_Dst_IP + SPI as key
+    * Continue Check ESP-NULL packet
+
+  ////////////////////////////////////////////////////////////
+  // Store encrypted ESP status to the IPsec flow cache.
+  //
+  Store ESP SPI cache info:
+    * Store State, IV_len, ICV_len to SPI cache
+            using IP_Src_IP + IP_Dst_IP + SPI as key
+    * Continue Check non-ESP-NULL packet
+
+  ////////////////////////////////////////////////////////////
+  // Store unsure flow status to IPsec flow cache.
+  // Here we also store the Check_Bits.
+  //
+  Store unsure SPI cache info:
+    * Store State, IV_len, ICV_len,
+            Stored_Check_Bits to SPI cache
+            using IP_Src_IP + IP_Dst_IP + SPI as key
+    * Continue Check unknown packet
+
+  ////////////////////////////////////////////////////////////
+  // Verify this packet against the previously selected
+  // ICV_len and IV_len values.  This will either
+  // fail (and set state to ESP to mark we do not yet
+  // know what type of flow this is) or will
+  // increment Check_Bits.
+  //
+  Verify next packet:
+    // We already have IV_len, ICV_len, and State loaded
+    * Load Stored_Check_Bits, Last_Packet_Data from SPI Cache
+    * Set Test_ICV_len to ICV_len, Test_IV_len to IV_len
+    * Initialize Check_Bits to 0
+    * Call Verify padding
+    * If verify padding returned Failure
+         // Initial guess was wrong, restart
+         * Set State to ESP
+         * Clear IV_len, ICV_len, State,
+                 Stored_Check_Bits, Last_Packet_Data
+                 from SPI Cache
+
+
+
+Kivinen & McDonald            Informational                    [Page 25]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+         * Return
+    // Ok, padding check succeeded again
+    * Call Verify packet
+    * If verify packet returned Failure
+         // Guess was wrong, restart
+         * Set State to ESP
+         * Clear IV_len, ICV_len, State,
+                 Stored_Check_Bits, Last_Packet_Data
+                 from SPI Cache
+         * Return
+    // It succeeded and updated Check_Bits and Last_Packet_Data store
+    // them to SPI cache.
+    * Increment Stored_Check_Bits by Check_Bits
+    * Store Stored_Check_Bits to SPI Cache
+    * Store Packet_Data as Last_Packet_Data to SPI cache
+    * Return
+
+  ////////////////////////////////////////////////////////////
+  // This will check if we have already seen enough bits
+  // acceptable from the payload data, so we can decide
+  // that this IPsec flow is ESP-NULL flow.
+  //
+  Verify unsure:
+    // Check if we have enough check bits.
+    * If Stored_Check_Bits > configured limit
+         // We have checked enough bits, return ESP-NULL
+         * Set State ESP-NULL
+         * Goto Store ESP-NULL SPI cache info
+    // Not yet enough bits, continue
+    * Continue Check unknown packet
+
+  ////////////////////////////////////////////////////////////
+  // Check for standard 96-bit algorithms.
+  //
+  Try standard algorithms:
+    // AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96,
+    // AUTH_AES_CMAC_96
+    * Set Test_ICV_len to 12, Test_IV_len to 0
+    * Goto Check packet
+
+  ////////////////////////////////////////////////////////////
+  // Check for 128-bit algorithms, this is only one that
+  // can have IV, so we need to check different IV_len values
+  // here too.
+  //
+  Try 128bit algorithms:
+    // AUTH_HMAC_SHA2_256_128, ENCR_NULL_AUTH_AES_GMAC
+    * Set Test_ICV_len to 16, Test_IV_len to 0
+
+
+
+Kivinen & McDonald            Informational                    [Page 26]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+    * If IP_total_len < IP_hdr_len + SPI_offset
+         + Test_IV_len + Test_ICV_len
+         + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
+         * Return
+    * Call Verify padding
+    * If verify padding returned Failure
+         * Return
+    * Initialize Check_Bits to 0
+    * Call Verify packet
+    * If verify packet returned Failure
+         * Goto Try GMAC
+    // Ok, packet seemed ok, but go now and check if we have enough
+    // data bits so we can assume it is ESP-NULL
+    * Goto Check if done for unsure
+
+  ////////////////////////////////////////////////////////////
+  // Check for GMAC MACs, i.e., MACs that have an 8-byte IV.
+  //
+  Try GMAC:
+    // ENCR_NULL_AUTH_AES_GMAC
+    * Set Test_IV_len to 8
+    * If IP_total_len < IP_hdr_len + SPI_offset
+         + Test_IV_len + Test_ICV_len
+         + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
+         * Return
+    * Initialize Check_Bits to 0
+    * Call Verify packet
+    * If verify packet returned Failure
+         // Guess was wrong, continue
+         * Return
+    // Ok, packet seemed ok, but go now and check if we have enough
+    // data bits so we can assume it is ESP-NULL
+    * Goto Check if done for unsure
+
+  ////////////////////////////////////////////////////////////
+  // Check for 192-bit algorithms.
+  //
+  Try 192bit algorithms:
+    // AUTH_HMAC_SHA2_384_192
+    * Set Test_ICV_len to 24, Test_IV_len to 0
+    * Goto Check packet
+
+  ////////////////////////////////////////////////////////////
+  // Check for 256-bit algorithms.
+  //
+  Try 256bit algorithms:
+    // AUTH_HMAC_SHA2_512_256
+    * Set Test_ICV_len to 32, Test_IV_len to 0
+
+
+
+Kivinen & McDonald            Informational                    [Page 27]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+    * Goto Check packet
+
+  ////////////////////////////////////////////////////////////
+  // This actually does the checking for the packet, by
+  // first verifying the length, and then self describing
+  // padding, and if that succeeds, then checks the actual
+  // payload content.
+  //
+  Check packet:
+    * If IP_total_len < IP_hdr_len + SPI_offset
+         + Test_IV_len + Test_ICV_len
+         + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
+         * Return
+    * Call Verify padding
+    * If verify padding returned Failure
+         * Return
+    * Initialize Check_Bits to 0
+    * Call Verify packet
+    * If verify packet returned Failure
+         // Guess was wrong, continue
+         * Return
+    // Ok, packet seemed ok, but go now and check if we have enough
+    // data bits so we can assume it is ESP-NULL
+    * Goto Check if done for unsure
+
+  ////////////////////////////////////////////////////////////
+  // This code checks if we have seen enough acceptable
+  // values in the payload data, so we can decide that this
+  // IPsec flow is ESP-NULL flow.
+  //
+  Check if done for unsure:
+    * If Stored_Check_Bits > configured limit
+         // We have checked enough bits, return ESP-NULL
+         * Set State ESP-NULL
+         * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len
+         * Clear Stored_Check_Bits, Last_Packet_Data from SPI Cache
+         * Return
+    // Not yet enough bits, check if this is first unsure, if so
+    // store information.  In case there are multiple
+    // tests succeeding, we always assume the first one
+    // (the one using shortest MAC) is the one we want to
+    // check in the future.
+    * If State is not unsure
+         * Set State unsure
+
+
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 28]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+         // These values will be stored to SPI cache if
+         // the final state will be unsure
+         * Set IV_len to Test_IV_len, ICV_len to Test_ICV_len
+         * Set Stored_Check_Bits as Check_Bits
+    * Return
+
+  ////////////////////////////////////////////////////////////
+  // Verify self describing padding
+  //
+  Verify padding:
+    * Load Pad_len from IP_total_len - Test_ICV_len - 2
+    * Verify padding bytes at
+                 IP_total_len - Test_ICV_len - 1 - Pad_len ..
+                 IP_total_len - Test_ICV_len - 2 are
+                 1, 2, ..., Pad_len
+    * If Verify of padding bytes succeeded
+         * Return Success
+    * Return Failure
+
+  ////////////////////////////////////////////////////////////
+  // This will verify the actual protocol content inside ESP
+  // packet.
+  //
+  Verify packet:
+    // We need to first check things that cannot be set, i.e., if any of
+    // those are incorrect, then we return Failure.  For any
+    / fields that might be correct, we increment the Check_Bits
+    // for a suitable amount of bits.  If all checks pass, then
+    // we just return Success, and the upper layer will then
+    // later check if we have enough bits checked already.
+    * Load Protocol From IP_total_len - Test_ICV_len - 1
+    * If Protocol TCP
+         * Goto Verify TCP
+    * If Protocol UDP
+         * Goto Verify UDP
+    // Other protocols can be added here as needed, most likely same
+    // protocols as deep inspection does.
+    // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for
+    // IPv6) is also left out from here to make the document shorter.
+    * Return Failure
+
+  ////////////////////////////////////////////////////////////
+  // Verify TCP protocol headers
+  //
+  Verify TCP:
+    // First we check things that must be set correctly.
+    * If TCP.Data_Offset field < 5
+        // TCP head length too small
+
+
+
+Kivinen & McDonald            Informational                    [Page 29]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+        * Return Failure
+    // After that, we start to check things that do not
+    // have one definitive value, but can have multiple possible
+    // valid values.
+    * If TCP.ACK bit is not set, then check
+         that TCP.Acknowledgment_number field contains 0
+         // If the ACK bit is not set, then the acknowledgment
+         // field usually contains 0, but I do not think
+         // RFCs mandate it being zero, so we cannot make
+         // this a failure if it is not so.
+         * Increment Check_Bits by 32
+    * If TCP.URG bit is not set, then check
+         that TCP.Urgent_Pointer field contains 0
+         // If the URG bit is not set, then urgent pointer
+         // field usually contains 0, but I do not think
+         // RFCs mandate it being zero, so we cannot make
+         // this failure if it is not so.
+         * Increment Check_Bits by 16
+    * If TCP.Data_Offset field == 5
+        * Increment Check_Bits by 4
+    * If TCP.Data_Offset field > 5
+        * If TCP options format is valid and it is padded correctly
+             * Increment Check_Bits accordingly
+        * If TCP options format was garbage
+             * Return Failure
+    * If TCP.checksum is correct
+        // This might be wrong because packet passed NAT, so
+        // we cannot make this failure case.
+        * Increment Check_Bits by 16
+    // We can also do normal deeper TCP inspection here, i.e.,
+    // check that the SYN/ACK/FIN/RST bits are correct and state
+    // matches the state of existing flow if this is packet
+    // to existing flow, etc.
+    // If there is anything clearly wrong in the packet (i.e.,
+    // some data is set to something that it cannot be), then
+    // this can return Failure; otherwise, it should just
+    // increment Check_Bits matching the number of bits checked.
+    //
+    // We can also check things here compared to the last packet
+    * If Last_Packet_Data.TCP.source port =
+         Packet_Data.TCP.source_port and
+         Last_Packet_Data.TCP.destination port =
+         Packet_Data.TCP.destination port
+         * Increment Check_Bits by 32
+    * If Last_Packet_Data.TCP.Acknowledgement_number =
+         Packet_Data.TCP.Acknowledgement_number
+         * Increment Check_Bits by 32
+    * If Last_Packet_Data.TCP.sequence_number =
+
+
+
+Kivinen & McDonald            Informational                    [Page 30]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+         Packet_Data.TCP.sequence_number
+         * Increment Check_Bits by 32
+    // We can do other similar checks here
+    * Return Success
+
+  ////////////////////////////////////////////////////////////
+  // Verify UDP protocol headers
+  //
+  Verify UDP:
+    // First we check things that must be set correctly.
+    * If UDP.UDP_length > IP_total_len - IP_hdr_len - SPI_offset
+        - Test_IV_len - Test_ICV_len - 4 (spi)
+        - 4 (seq no) - 1 (protocol)
+        - Pad_len - 1 (Pad_len)
+        * Return Failure
+    * If UDP.UDP_length < 8
+        * Return Failure
+    // After that, we start to check things that do not
+    // have one definitive value, but can have multiple possible
+    // valid values.
+    * If UDP.UDP_checksum is correct
+        // This might be wrong because packet passed NAT, so
+        // we cannot make this failure case.
+        * Increment Check_Bits by 16
+    * If UDP.UDP_length = IP_total_len - IP_hdr_len - SPI_offset
+         - Test_IV_len - Test_ICV_len - 4 (spi)
+         - 4 (seq no) - 1 (protocol)
+         - Pad_len - 1 (Pad_len)
+         // If there is no TFC padding then UDP_length
+         // will be matching the full packet length
+         * Increment Check_Bits by 16
+    // We can also do normal deeper UDP inspection here.
+    // If there is anything clearly wrong in the packet (i.e.,
+    // some data is set to something that it cannot be), then
+    // this can return Failure; otherwise, it should just
+    // increment Check_Bits matching the number of bits checked.
+    //
+    // We can also check things here compared to the last packet
+    * If Last_Packet_Data.UDP.source_port =
+         Packet_Data.UDP.source_port and
+         Last_Packet_Data.destination_port =
+         Packet_Data.UDP.destination_port
+         * Increment Check_Bits by 32
+    * Return Success
+
+                                 Figure 4
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 31]
+
+RFC 5879            Heuristics for Detecting ESP-NULL           May 2010
+
+
+Authors' Addresses
+
+   Tero Kivinen
+   AuthenTec, Inc.
+   Fredrikinkatu 47
+   Helsinki  FIN-00100
+   FI
+
+   EMail: kivinen@iki.fi
+
+
+   Daniel L. McDonald
+   Oracle Corporation
+   35 Network Drive
+   MS UBUR02-212
+   Burlington, MA  01803
+   USA
+
+   EMail: danmcd@opensolaris.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & McDonald            Informational                    [Page 32]
+