draft-ietf-ipsecme-esp-null-heuristics-03.txt   draft-ietf-ipsecme-esp-null-heuristics-04.txt 
IP Security Maintenance and T. Kivinen IP Security Maintenance and T. Kivinen
Extensions (ipsecme) Safenet, Inc. Extensions (ipsecme) Safenet, Inc.
Internet-Draft D. McDonald Internet-Draft D. McDonald
Intended status: Informational Sun Microsystems, Inc. Intended status: Informational Sun Microsystems, Inc.
Expires: June 3, 2010 November 30, 2009 Expires: July 31, 2010 January 27, 2010
Heuristics for Detecting ESP-NULL packets Heuristics for Detecting ESP-NULL packets
draft-ietf-ipsecme-esp-null-heuristics-03.txt draft-ietf-ipsecme-esp-null-heuristics-04.txt
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 given packet flow is interesting
or not. Use of these heuristics does not require any changes made on
existing RFC4303 compliant IPsec hosts.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 3, 2010. This Internet-Draft will expire on July 31, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes a set of heuristics for distinguishing IPsec described in the BSD License.
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 given packet flow is interesting
or not. Use of these heuristics does not require any changes made on
existing RFC4303 compliant IPsec hosts.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability: Heuristic Traffic Inspection and 1.1. Applicability: Heuristic Traffic Inspection and
Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 4 Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 6 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 6
2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 7
3. Description of Heuristics . . . . . . . . . . . . . . . . . . 8 3. Description of Heuristics . . . . . . . . . . . . . . . . . . 8
4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 11
6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 12
7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 13
8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 14
8.2. Self Describing Padding Check . . . . . . . . . . . . . . 15 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 16
8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 17 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 18
8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 18
8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 19
8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 19 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 19
8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 20
8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 24 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 25
A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The ESP (Encapsulating Security Payload [RFC4303]) protocol can be The ESP (Encapsulating Security Payload [RFC4303]) protocol can be
used with NULL encryption [RFC2410] to provide authentication, used with NULL encryption [RFC2410] to provide authentication,
integrity protection, and optionally replay detection; but not integrity protection, and optionally replay detection; but not
confidentiality. NULL encryption with ESP (referred to as ESP-NULL) confidentiality. NULL encryption with ESP (referred to as ESP-NULL)
offers similar properties to IPsec's AH (Authentication Header offers similar properties to IPsec's AH (Authentication Header
[RFC4302]). One reason to use ESP-NULL instead of AH is that AH [RFC4302]). One reason to use ESP-NULL instead of AH is that AH
cannot be used if there are NATs (Network Address Translation cannot be used if there are NATs (Network Address Translation
skipping to change at page 8, line 17 skipping to change at page 8, line 17
The heuristics to detect ESP-NULL packets will only require changes The heuristics to detect ESP-NULL packets will only require changes
to those intermediate devices which do deep inspection or other to those intermediate devices which do deep inspection or other
operations which require detecting ESP-NULL. As those nodes require operations which require detecting ESP-NULL. As those nodes require
changes regardless of any ESP-NULL method, updating intermediate changes regardless of any ESP-NULL method, updating intermediate
nodes is unavoidable. Heuristics do not require updating or nodes is unavoidable. Heuristics do not require updating or
modifying any other devices on the rest of the network, including modifying any other devices on the rest of the network, including
(especially) end-nodes. (especially) end-nodes.
In this document it is assumed that an affected intermediate node In this document it is assumed that an affected intermediate node
will act as a stateful interception device, meaning it will keep will act as a stateful interception device, meaning it will keep
state of the flows - where flows are defined by the ESP SPI and IP state of the IPsec flows - where flows are defined by the ESP SPI and
addresses forming an IPsec SA - going through it. The heuristics can IP addresses forming an IPsec SA - going through it. The heuristics
also be used without storing any state, but performance will be worse can also be used without storing any state, but performance will be
in that case, as heuristic checks will need to be done for each 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 packet, not only once per flow. This will also affect the
reliability of the heuristics. reliability of the heuristics.
Generally, an intermediate node runs heuristics only for the first Generally, an intermediate node runs heuristics only for the first
few packets of the new flow (i.e. the new IPsec SA). After those few few packets of the new flow (i.e. the new IPsec SA). After those few
packets, the node detects parameters of the IPsec flow, it skips packets, the node detects parameters of the IPsec flow, it skips
detection heuristics, and it can perform direct packet-inspecting detection heuristics, and it can perform direct packet-inspecting
action based on its own policy. Once detected, ESP-NULL packets will action based on its own policy. Once detected, ESP-NULL packets will
never be detected as encrypted ESP packets, meaning that valid ESP- never be detected as encrypted ESP packets, meaning that valid ESP-
NULL packets will never bypass the deep inspection. The only failure NULL packets will never bypass the deep inspection. The only failure
skipping to change at page 15, line 10 skipping to change at page 15, line 10
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
The output of the heuristics should provide information about whether The output of the heuristics should provide information about whether
the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL the the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL the
heuristics should also provide the Integrity Check Value (ICV) field heuristics should also provide the Integrity Check Value (ICV) field
length and the Initialization Vector (IV) length. length and the Initialization Vector (IV) length.
The currently defined ESP authentication algorithms have 5 different The currently defined ESP authentication algorithms have 4 different
lengths for the ICV field. Most commonly used is 96 bits, and after lengths for the ICV field. Most commonly used is 96 bits, and after
that comes 128 bit ICV lengths. that comes 128 bit ICV lengths.
Different ICV lengths for different algorithm: Different ICV lengths for different algorithm:
Algorithm ICV Length Algorithm ICV Length
------------------------------- ---------- ------------------------------- ----------
AUTH_HMAC_MD5_96 96 AUTH_HMAC_MD5_96 96
AUTH_HMAC_SHA1_96 96 AUTH_HMAC_SHA1_96 96
AUTH_AES_XCBC_96 96 AUTH_AES_XCBC_96 96
AUTH_AES_CMAC_96 96 AUTH_AES_CMAC_96 96
AUTH_HMAC_MD5_128 128
AUTH_HMAC_SHA2_256_128 128 AUTH_HMAC_SHA2_256_128 128
AUTH_AES_128_GMAC 128
AUTH_AES_192_GMAC 128
AUTH_AES_256_GMAC 128
AUTH_HMAC_SHA1_160 160
AUTH_HMAC_SHA2_384_192 192 AUTH_HMAC_SHA2_384_192 192
AUTH_HMAC_SHA2_512_256 256 AUTH_HMAC_SHA2_512_256 256
Figure 2 Figure 2
In addition to the ESP authentication algorithms listed above, there
is also encryption algorithm ENCR_NULL_AUTH_AES_GMAC which does not
provide confidentiality but provides authentication, just like ESP-
NULL does. This algorithm has ICV Length of 128 bits, and it also
requires eight bytes of IV.
In addition to the ICV length, there are also two possible values for In addition to the ICV length, there are also two possible values for
IV lengths: zero bytes (default) and eight bytes (for IV lengths: zero bytes (default) and eight bytes (for
AUTH_AES_*_GMAC). Detecting the IV length requires understanding the ENCR_NULL_AUTH_AES_GMAC). Detecting the IV length requires
payload, i.e. the actual protocol data (meaning TCP, UDP, etc). This understanding the payload, i.e. the actual protocol data (meaning
is required to distinguish the optional IV from the actual protocol TCP, UDP, etc). This is required to distinguish the optional IV from
data. How well IV can be distinguished from the actual protocol data the actual protocol data. How well IV can be distinguished from the
depends how the IV is generated. If IV is generated using a method actual protocol data depends how the IV is generated. If IV is
that generates random looking data (i.e. encrypted counter etc) then generated using a method that generates random looking data (i.e.
distinguishing protocol data from IV is quite easy. If an IV is a encrypted counter etc) then distinguishing protocol data from IV is
counter or similar non-random value, then there are more quite easy. If an IV is a counter or similar non-random value, then
possibilities for error. If the protocol (also known as the, "next there are more possibilities for error. If the protocol (also known
header") of the packet is one that is not supported by the as the, "next header") of the packet is one that is not supported by
heuristics, then detecting the IV length is impossible, thus the the heuristics, then detecting the IV length is impossible, thus the
heuristics cannot finish. In that case, the heuristics return heuristics cannot finish. In that case, the heuristics return
"unsure" and requires further packets. "unsure" and requires further packets.
This document does not cover RSA authentication in ESP ([RFC4359]),
as it is considered being beyond the scope of this document.
8.2. Self Describing Padding Check 8.2. Self Describing Padding Check
Before obtaining the next header field, the ICV length must be Before obtaining the next header field, the ICV length must be
measured. Five different ICV lengths lead to five possible places measured. Five different ICV lengths lead to five possible places
for the pad length and padding. Implementations must be careful when for the pad length and padding. Implementations must be careful when
trying larger sizes of ICV such that the inspected bytes do not trying larger sizes of ICV such that the inspected bytes do not
belong to data that is not payload data. For example, a ten-byte belong to data that is not payload data. For example, a ten-byte
ICMP echo request will have zero-length padding, but any checks for ICMP echo request will have zero-length padding, but any checks for
256-bit ICVs will inspect sequence number or SPI data if the packet 256-bit ICVs will inspect sequence number or SPI data if the packet
actually contains a 96-bit or 128-bit ICV. actually contains a 96-bit or 128-bit ICV.
skipping to change at page 23, line 37 skipping to change at page 23, line 37
[I-D.hoffman-esp-null-protocol] [I-D.hoffman-esp-null-protocol]
Hoffman, P. and D. McGrew, "An Authentication-only Profile Hoffman, P. and D. McGrew, "An Authentication-only Profile
for ESP with an IP Protocol Identifier", for ESP with an IP Protocol Identifier",
draft-hoffman-esp-null-protocol-00 (work in progress), draft-hoffman-esp-null-protocol-00 (work in progress),
August 2007. August 2007.
[I-D.ietf-ipsecme-traffic-visibility] [I-D.ietf-ipsecme-traffic-visibility]
Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP
for Traffic Visibility", for Traffic Visibility",
draft-ietf-ipsecme-traffic-visibility-10 (work in draft-ietf-ipsecme-traffic-visibility-12 (work in
progress), November 2009. progress), January 2010.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007. Authentication Header (AH)", RFC 4835, April 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
skipping to change at page 25, line 15 skipping to change at page 26, line 15
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// This is the main processing code for the packet // This is the main processing code for the packet
// This will check if the packet requires ESP processing, // This will check if the packet requires ESP processing,
// //
Process packet: Process packet:
* If IP protocol is ESP * If IP protocol is ESP
* Set SPI_offset to 0 bytes * Set SPI_offset to 0 bytes
* Goto Process ESP * Goto Process ESP
* If IP protocol is UDP * If IP protocol is UDP
* Goto Process UDP * Goto Process UDP
* If IP protocol is WESP
// For information about WESP processing see WESP
// specification.
* Continue WESP processing
* Continue Non-ESP processing * Continue Non-ESP processing
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// This code is run for UDP packets, and it checks if the // This code is run for UDP packets, and it checks if the
// packet is UDP encapsulated UDP packet, or UDP // packet is UDP encapsulated UDP packet, or UDP
// encapsulated IKE packet, or keepalive packet. // encapsulated IKE packet, or keepalive packet.
// //
Process UDP: Process UDP:
// Reassembly is not mandatory here, we could // Reassembly is not mandatory here, we could
// do reassembly also only after detecting the // do reassembly also only after detecting the
skipping to change at page 25, line 38 skipping to change at page 26, line 42
// for checking if the UDP header is in this // for checking if the UDP header is in this
// packet or not. // packet or not.
// Reassembly is to simplify things // Reassembly is to simplify things
* If packet is fragment * If packet is fragment
* Do full reassembly before processing * Do full reassembly before processing
* If UDP_src_port != 4500 and UDP_dst_port != 4500 * If UDP_src_port != 4500 and UDP_dst_port != 4500
* Continue Non-ESP processing * Continue Non-ESP processing
* Set SPI_offset to 8 bytes * Set SPI_offset to 8 bytes
* If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000 * If UDP_len > 4 and first 4 bytes of UDP packet are 0x000000
* Continue Non-ESP processing (pass IKE-packet) * 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 * If UDP_len == 1 and first byte is 0xff
* Continue Non-ESP processing (pass NAT-Keepalive Packet) * Continue Non-ESP processing (pass NAT-Keepalive Packet)
* Goto Process ESP * Goto Process ESP
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// This code is run for ESP packets (or UDP encapsulated ESP // This code is run for ESP packets (or UDP encapsulated ESP
// packets). This checks if IPsec flow is known, and // packets). This checks if IPsec flow is known, and
// if not calls heuristics. If IPsec flow is known // if not calls heuristics. If IPsec flow is known
// then it continues processing based on the policy. // then it continues processing based on the policy.
// //
Process ESP: Process ESP:
* If packet is fragment * If packet is fragment
* Do full reassembly before processing * Do full reassembly before processing
* If IP_total_len < IP_hdr_len + SPI_offset + 4 * If IP_total_len < IP_hdr_len + SPI_offset + 4
* Drop invalid packet // If this packet was UDP encapsulated ESP packet then
// this might be valid UDP packet which might
// be passed or dropped depending on policy
* Continue normal packet processing
* Load SPI from IP_hdr_len + SPI_offset * Load SPI from IP_hdr_len + SPI_offset
* Initialize State to ESP * Initialize State to ESP
// In case this was UDP encapsulated ESP then use UDP_src_port and // In case this was UDP encapsulated ESP then use UDP_src_port and
// UDP_dst_port also when finding data from SPI cache. // UDP_dst_port also when finding data from SPI cache.
* Find IP_Src_IP + IP_Dst_IP + SPI from SPI cache * Find IP_Src_IP + IP_Dst_IP + SPI from SPI cache
* If SPI found * If SPI found
* Load State, IV_len, ICV_len from cache * Load State, IV_len, ICV_len from cache
* If SPI not found or State is unsure * If SPI not found or State is unsure
* Call Autodetect ESP parameters (drop to slowpath) * Call Autodetect ESP parameters (drop to slowpath)
* If State is ESP * If State is ESP
skipping to change at page 26, line 27 skipping to change at page 27, line 36
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// This code is run for ESP-NULL packets, and this // This code is run for ESP-NULL packets, and this
// finds out the data required for deep inspection // finds out the data required for deep inspection
// engine (protocol number, and offset to data) // engine (protocol number, and offset to data)
// and calls the deep inspection engine. // and calls the deep inspection engine.
// //
Check ESP-NULL packet: Check ESP-NULL packet:
* If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len * If IP_total_len < IP_hdr_len + SPI_offset + IV_len + ICV_len
+ 4 (spi) + 4 (seq no) + 4 (protocol + padding) + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
* Drop invalid packet // 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 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 * Load Protocol from IP_total_len - ICV_len - 1
* Set Protocol_off to * Set Protocol_off to
IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no) IP_hdr_len + SPI_offset + IV_len + 4 (spi) + 4 (seq no)
* Do normal deep inspection on packet. * Do normal deep inspection on packet.
Figure 3 Figure 3
A.2. Slowpath A.2. Slowpath
The following example pseudocode show the actual heuristics part of The following example pseudocode show the actual heuristics part of
skipping to change at page 28, line 18 skipping to change at page 29, line 32
// was changed to ESP, we check other // was changed to ESP, we check other
// ICV/IV_len values, i.e. fall through // ICV/IV_len values, i.e. fall through
// ICV lengths are tested in order of ICV lengths, // ICV lengths are tested in order of ICV lengths,
// from shortest to longest. // from shortest to longest.
* Call Try standard algorithms * Call Try standard algorithms
* If State is ESP-NULL * If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
* Call Try 128bit algorithms * Call Try 128bit algorithms
* If State is ESP-NULL * If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
* Call Try 160bit algorithms
* If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info
* Call Try 192bit algorithms * Call Try 192bit algorithms
* If State is ESP-NULL * If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
* Call Try 256bit algorithms * Call Try 256bit algorithms
* If State is ESP-NULL * If State is ESP-NULL
* Goto Store ESP-NULL SPI cache info * Goto Store ESP-NULL SPI cache info
// AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from
// this document. // this document.
// If any of those test above set state to unsure // If any of those test above set state to unsure
// we mark IPsec flow as unsure. // we mark IPsec flow as unsure.
skipping to change at page 30, line 31 skipping to change at page 31, line 43
// AUTH_AES_CMAC_96 // AUTH_AES_CMAC_96
* Set Test_ICV_len to 12, Test_IV_len to 0 * Set Test_ICV_len to 12, Test_IV_len to 0
* Goto Check packet * Goto Check packet
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Check for 128-bit algorithms, this is only one that // Check for 128-bit algorithms, this is only one that
// can have IV, so we need to check different IV_len values // can have IV, so we need to check different IV_len values
// here too. // here too.
// //
Try 128bit algorithms: Try 128bit algorithms:
// AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 // AUTH_HMAC_SHA2_256_128, ENCR_NULL_AUTH_AES_GMAC
// AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC
* Set Test_ICV_len to 16, Test_IV_len to 0 * Set Test_ICV_len to 16, Test_IV_len to 0
* If IP_total_len < IP_hdr_len + SPI_offset * If IP_total_len < IP_hdr_len + SPI_offset
+ Test_IV_len + Test_ICV_len + Test_IV_len + Test_ICV_len
+ 4 (spi) + 4 (seq no) + 4 (protocol + padding) + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
* Return * Return
* Call Verify padding * Call Verify padding
* If verify padding returned Failure * If verify padding returned Failure
* Return * Return
* Initialize Check_Bits to 0 * Initialize Check_Bits to 0
* Call Verify packet * Call Verify packet
* If verify packet returned Failure * If verify packet returned Failure
* Goto Try GMAC * Goto Try GMAC
// Ok, packet seemed ok, but go now and check if we have enough // Ok, packet seemed ok, but go now and check if we have enough
// data bits so we can assume it is ESP-NULL // data bits so we can assume it is ESP-NULL
* Goto Check if done for unsure * Goto Check if done for unsure
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Check for GMAC macs, i.e. macs having 8 byte IV. // Check for GMAC macs, i.e. macs having 8 byte IV.
skipping to change at page 31, line 5 skipping to change at page 32, line 17
* If verify packet returned Failure * If verify packet returned Failure
* Goto Try GMAC * Goto Try GMAC
// Ok, packet seemed ok, but go now and check if we have enough // Ok, packet seemed ok, but go now and check if we have enough
// data bits so we can assume it is ESP-NULL // data bits so we can assume it is ESP-NULL
* Goto Check if done for unsure * Goto Check if done for unsure
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Check for GMAC macs, i.e. macs having 8 byte IV. // Check for GMAC macs, i.e. macs having 8 byte IV.
// //
Try GMAC: Try GMAC:
// AUTH_AES_128_GMAC, AUTH_AES_192_GMAC, AUTH_AES_256_GMAC // ENCR_NULL_AUTH_AES_GMAC
* Set Test_IV_len to 8 * Set Test_IV_len to 8
* If IP_total_len < IP_hdr_len + SPI_offset * If IP_total_len < IP_hdr_len + SPI_offset
+ Test_IV_len + Test_ICV_len + Test_IV_len + Test_ICV_len
+ 4 (spi) + 4 (seq no) + 4 (protocol + padding) + 4 (spi) + 4 (seq no) + 4 (protocol + padding)
* Return * Return
* Initialize Check_Bits to 0 * Initialize Check_Bits to 0
* Call Verify packet * Call Verify packet
* If verify packet returned Failure * If verify packet returned Failure
// Guess was wrong, continue // Guess was wrong, continue
* Return * Return
// Ok, packet seemed ok, but go now and check if we have enough // Ok, packet seemed ok, but go now and check if we have enough
// data bits so we can assume it is ESP-NULL // data bits so we can assume it is ESP-NULL
* Goto Check if done for unsure * Goto Check if done for unsure
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Check for 160-bit algorithms.
//
Try 160bit algorithms:
// AUTH_HMAC_SHA1_160
* Set Test_ICV_len to 20, Test_IV_len to 0
* Goto Check packet
////////////////////////////////////////////////////////////
// Check for 192-bit algorithms. // Check for 192-bit algorithms.
// //
Try 192bit algorithms: Try 192bit algorithms:
// AUTH_HMAC_SHA2_384_192 // AUTH_HMAC_SHA2_384_192
* Set Test_ICV_len to 24, Test_IV_len to 0 * Set Test_ICV_len to 24, Test_IV_len to 0
* Goto Check packet * Goto Check packet
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Check for 256-bit algorithms. // Check for 256-bit algorithms.
// //
 End of changes. 26 change blocks. 
64 lines changed or deleted 79 lines changed or added

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