GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5879

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5879.txt · Last modified: 2010/05/27 18:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki