draft-ietf-ipsecme-esp-null-heuristics-00.txt   draft-ietf-ipsecme-esp-null-heuristics-01.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: October 18, 2009 April 16, 2009 Expires: March 7, 2010 September 3, 2009
Heuristics for Detecting ESP-NULL packets Heuristics for Detecting ESP-NULL packets
draft-ietf-ipsecme-esp-null-heuristics-00.txt draft-ietf-ipsecme-esp-null-heuristics-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 18, 2009. This Internet-Draft will expire on March 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 18 skipping to change at page 2, line 18
NULL (Encapsulating Security Payload without encryption) packets from NULL (Encapsulating Security Payload without encryption) packets from
encrypted ESP packets. The reason for using heuristics instead of encrypted ESP packets. The reason for using heuristics instead of
modifying ESP is to provide a solution that can be used now without modifying ESP is to provide a solution that can be used now without
updating all end nodes. With heuristic methods, only the updating all end nodes. With heuristic methods, only the
intermediate devices wanting to find ESP-NULL packets need to be intermediate devices wanting to find ESP-NULL packets need to be
updated. updated.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1.1. Applicability: Heuristic Traffic Inspection and
3. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 5 Wrapped ESP . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4
3.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 5 2. Other Options . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 6 2.1. AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Description of Heuristics . . . . . . . . . . . . . . . . . . 7 2.2. Mandating by Policy . . . . . . . . . . . . . . . . . . . 5
5. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Modifying ESP . . . . . . . . . . . . . . . . . . . . . . 6
6. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 10 3. Description of Heuristics . . . . . . . . . . . . . . . . . . 7
7. Special and Error Cases . . . . . . . . . . . . . . . . . . . 11 4. IPsec flows . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 12 5. Deep Inspection Engine . . . . . . . . . . . . . . . . . . . . 10
9. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 13 6. Special and Error Cases . . . . . . . . . . . . . . . . . . . 11
9.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 13 7. UDP encapsulation . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Self Describing Padding Check . . . . . . . . . . . . . . 14 8. Heuristic Checks . . . . . . . . . . . . . . . . . . . . . . . 13
9.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 16 8.1. ESP-NULL format . . . . . . . . . . . . . . . . . . . . . 13
9.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Self Describing Padding Check . . . . . . . . . . . . . . 14
9.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 17 8.3. Protocol Checks . . . . . . . . . . . . . . . . . . . . . 16
9.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 18 8.3.1. TCP checks . . . . . . . . . . . . . . . . . . . . . . 17
9.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 18 8.3.2. UDP checks . . . . . . . . . . . . . . . . . . . . . . 17
9.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 18 8.3.3. ICMP checks . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8.3.4. SCTP checks . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.3.5. IPv4 and IPv6 Tunnel checks . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 21 Appendix A. Example Pseudocode . . . . . . . . . . . . . . . . . 21
A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Fastpath . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2. Slowpath . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The ESP (Encapsulated Security Payload [RFC4303]) protocol can be The ESP (Encapsulated Security Payload [RFC4303]) protocol can be
used with NULL encryption [RFC2410] to provide authentication and used with NULL encryption [RFC2410] to provide authentication and
integrity protection, but not confidentiality. This offers similar integrity protection, but not confidentiality. This offers similar
skipping to change at page 4, line 5 skipping to change at page 3, line 49
can be implemented immediately, and not after a 5-10 year upgrade- can be implemented immediately, and not after a 5-10 year upgrade-
and-deployment time frame. Even with protocol modification for end and-deployment time frame. Even with protocol modification for end
nodes, the intermediate devices will need heuristics until they can nodes, the intermediate devices will need heuristics until they can
assume that those protocol modifications can be found from all the assume that those protocol modifications can be found from all the
end devices. To make sure that any solution does not break in the end devices. To make sure that any solution does not break in the
future it would be best if such heuristics are documented, i.e. we future it would be best if such heuristics are documented, i.e. we
need to publish an RFC for what to do now even when there might be a need to publish an RFC for what to do now even when there might be a
new protocol coming in the future that will solve the same problem new protocol coming in the future that will solve the same problem
better. better.
2. Requirements notation 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:
- 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.
- The Wrapped ESP approach [I-D.ietf-ipsecme-traffic-visibility],
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, we expect both
approaches to 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. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Other Options 2. Other Options
This document will discuss the heuristic approach of detecting ESP- This document will discuss the heuristic approach of detecting ESP-
NULL packets. There are some other options which can be used, and NULL packets. There are some other options which can be used, and
this section will briefly discuss those. this section will briefly discuss those.
3.1. AH 2.1. AH
The most logical approach would use the already defined protocol The most logical approach would use the already defined protocol
which offers authentication and integrity protection, but not which offers authentication and integrity protection, but not
confidentiality, namely AH. AH traffic is clearly marked as not confidentiality, namely AH. AH traffic is clearly marked as not
encrypted, and can always be inspected by intermediate devices. encrypted, and can always be inspected by intermediate devices.
Using AH has two problems. First is that, as it also protects the IP Using AH has two problems. First is that, as it also protects the IP
headers, it will also protect against NATs on the path, thus it will headers, it will also protect against NATs on the path, thus it will
not work if there is NAT on the path between end nodes. In some not work if there is NAT on the path between end nodes. In some
environments this might not be a problem, but some environments environments this might not be a problem, but some environments
skipping to change at page 5, line 40 skipping to change at page 5, line 40
support it. ESP-NULL has been defined to be mandatory to implement support it. ESP-NULL has been defined to be mandatory to implement
by Cryptographic Algorithm Implementation Requirements for by Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) [RFC4835]. Encapsulating Security Payload (ESP) [RFC4835].
AH has also quite complex processing rules compared to ESP when AH has also quite complex processing rules compared to ESP when
calculating the ICV, including things like zeroing out mutable calculating the ICV, including things like zeroing out mutable
fields. As AH is not as widely used than ESP, the AH support is not fields. As AH is not as widely used than ESP, the AH support is not
as well tested in the interoperability events, meaning it might have as well tested in the interoperability events, meaning it might have
more bugs than ESP implementations. more bugs than ESP implementations.
3.2. Mandating by Policy 2.2. Mandating by Policy
Another easy way to solve this problem is to mandate the use of ESP- Another easy way to solve this problem is to mandate the use of ESP-
NULL with common parameters within an entire organization. This NULL with common parameters within an entire organization. This
either removes the need for heuristics (if no ESP encrypted traffic either removes the need for heuristics (if no ESP encrypted traffic
is allowed at all) or simplifies them considerably (only one set of is allowed at all) or simplifies them considerably (only one set of
parameters needs to be inspected, e.g. everybody in the organization parameters needs to be inspected, e.g. everybody in the organization
who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity who is using ESP-NULL must use HMAC-SHA-1-96 as their integrity
algorithm). This does not work if the machines are not under the algorithm). This does not work if the machines are not under the
same administrative domain. Also, such a solution might require some same administrative domain. Also, such a solution might require some
kind of centralized policy management to make sure everybody uses the kind of centralized policy management to make sure everybody uses the
same policy. same policy.
3.3. Modifying ESP 2.3. Modifying ESP
Several internet drafts discuss ways of modifying ESP to offer Several internet drafts discuss ways of modifying ESP to offer
intermediate devices information about an ESP packet's use of NULL intermediate devices information about an ESP packet's use of NULL
encryption. The following methods have been discussed: adding an IP- encryption. The following methods have been discussed: adding an IP-
option, adding a new IP-protocol number plus an extra header option, adding a new IP-protocol number plus an extra header
[I-D.ietf-ipsecme-traffic-visibility], adding a new IP-protocol [I-D.ietf-ipsecme-traffic-visibility], adding a new IP-protocol
numbers which tell the ESP-NULL parameters numbers which tell the ESP-NULL parameters
[I-D.hoffman-esp-null-protocol], reserving an SPI range for ESP-NULL [I-D.hoffman-esp-null-protocol], reserving an SPI range for ESP-NULL
[I-D.bhatia-ipsecme-esp-null], and using UDP encapsulation with a [I-D.bhatia-ipsecme-esp-null], and using UDP encapsulation with a
different format and ports. different format and ports.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
IPv6 vs NAT case. IPv6 required updating all of the end nodes (and IPv6 vs NAT case. IPv6 required updating all of the end nodes (and
routers too) before it could be effectively used. This has taken a routers too) before it could be effectively used. This has taken a
very long time, and IPv6 deployment is not yet widespread. NAT, on very long time, and IPv6 deployment is not yet widespread. NAT, on
the other hand, only required modifying an existing intermediate the other hand, only required modifying an existing intermediate
device or adding a new one, and has spread out much faster. Another device or adding a new one, and has spread out much faster. Another
example of slow end-node deployment is IKEv2. Considering an example of slow end-node deployment is IKEv2. Considering an
implementation that requires both IKEv2 and a new ESP format, it implementation that requires both IKEv2 and a new ESP format, it
would take several years, possibly as long as a decade, before would take several years, possibly as long as a decade, before
widespread deployment. widespread deployment.
4. Description of Heuristics 3. Description of Heuristics
The heuristics to detect ESP-NULL packets will only require changes The heuristics to detect ESP-NULL packets will only require changes
to the those intermediate devices which do deep inspection or other to the those intermediate devices which do deep inspection or other
operations which require detecting ESP-NULL. As those nodes require operations which require detecting ESP-NULL. As those nodes require
changes regardless of any ESP-NULL method, updating intermediate changes regardless of any ESP-NULL method, updating intermediate
nodes is unavoidable. Heuristics do not require updating or nodes is unavoidable. Heuristics do not require updating or
modifying any other devices on the rest of the network, including modifying any other devices on the rest of the network, including
(and especially) end-nodes. (and 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
skipping to change at page 8, line 5 skipping to change at page 8, line 5
intermediate node. intermediate node.
For hardware implementations all the flow lookup based on the ESP For hardware implementations all the flow lookup based on the ESP
next header number (50), source address, destination address, and SPI next header number (50), source address, destination address, and SPI
can be done by the hardware (there is usually already similar can be done by the hardware (there is usually already similar
functionality there, for TCP/UDP flows). The heuristics can be functionality there, for TCP/UDP flows). The heuristics can be
implemented by the hardware, but using software will allow faster implemented by the hardware, but using software will allow faster
updates when new protocol modifications come out or new protocols updates when new protocol modifications come out or new protocols
need support. need support.
5. IPsec flows 4. IPsec flows
ESP is a stateful protocol, meaning there is state stored in the both ESP is a stateful protocol, meaning there is state stored in the both
end nodes of the ESP IPsec SA, and the state is identified by the end nodes of the ESP IPsec SA, and the state is identified by the
pair of destination IP and SPI. End nodes also often fix the source pair of destination IP and SPI. End nodes also often fix the source
IP address in an SA unless the destination is a multicast group. As IP address in an SA unless the destination is a multicast group. As
most (if not all) flows of interest to an intermediate device are most (if not all) flows of interest to an intermediate device are
unicast, it is safer to assume the receiving node also uses a source unicast, it is safer to assume the receiving node also uses a source
address, and the intermediate device should do the same. In some address, and the intermediate device should do the same. In some
cases this might cause extraneous cached ESP IPsec SA flows, but by cases this might cause extraneous cached ESP IPsec SA flows, but by
using the source address two distinct flows will never be mixed. using the source address two distinct flows will never be mixed.
When the intermediate device sees an new ESP IPsec flow, i.e. a flow When the intermediate device sees an new ESP IPsec flow, i.e. a flow
of ESP packets where the source address, destination address, and SPI of ESP packets where the source address, destination address, and SPI
number forms a triplet which has not been cached, it will start the number forms a triplet which has not been cached, it will start the
heuristics to detect whether this flow is ESP-NULL or not. These heuristics to detect whether this flow is ESP-NULL or not. These
heuristics appear in the Section 9. heuristics appear in the Section 8.
When the heuristics finish, they will label the flow as either When the heuristics finish, they will label the flow as either
encrypted (which tells that packets in this flow are encrypted, and encrypted (which tells that packets in this flow are encrypted, and
cannot be ESP-NULL packets) or as ESP-NULL. This information, along cannot be ESP-NULL packets) or as ESP-NULL. This information, along
with the ESP-NULL parameters detected by the heuristics, is stored to with the ESP-NULL parameters detected by the heuristics, is stored to
a flow cache, which will be used in the future when processing a flow cache, which will be used in the future when processing
packets of the same flow. packets of the same flow.
Both encrypted ESP and ESP-NULL flows are processed based on the Both encrypted ESP and ESP-NULL flows are processed based on the
local policy. In normal operation encrypted ESP flows are passed local policy. In normal operation encrypted ESP flows are passed
skipping to change at page 10, line 5 skipping to change at page 10, line 5
detect type of flow. One of them is that the next header number was detect 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 unknown, i.e. if heuristics do not know about the protocol for the
packet, it cannot verify it has properly detected ESP-NULL packet, it cannot verify it has properly detected ESP-NULL
parameters, even when the packet otherwise looks like ESP-NULL. If parameters, even when the packet otherwise looks like ESP-NULL. If
the packet does not look like ESP-NULL at all, then encrypted ESP the packet does not look like ESP-NULL at all, then encrypted ESP
status can be returned quickly. As ESP-NULL heuristics should know status can be returned quickly. As ESP-NULL heuristics should know
the same protocols as a deep inspection device, an unknown protocol the same protocols as a deep inspection device, an unknown protocol
should not be handled any differently than a cleartext instance of an should not be handled any differently than a cleartext instance of an
unknown protocol if possible. unknown protocol if possible.
6. Deep Inspection Engine 5. Deep Inspection Engine
A deep inspection engine running on an intermediate node usually A deep inspection engine running on an intermediate node usually
checks deeply in to the packet and performs policy decisions based on checks deeply in to the packet and performs policy decisions based on
the contents of the packet. The deep inspection engine should be the contents of the packet. The deep inspection engine should be
able to tell the difference between success, failure, and garbage. able to tell the difference between success, failure, and garbage.
Success means that a packet was successfully checked with the deep Success means that a packet was successfully checked with the deep
inspection engine, and it passed the checks and is allowed to be inspection engine, and it passed the checks and is allowed to be
forwarded. Failure means that a packet was successfully checked but forwarded. Failure means that a packet was successfully checked but
the actual checks done indicated that packets should be dropped, i.e. the actual checks done indicated that packets should be dropped, i.e.
the packet contained a virus, was a known attack, or something the packet contained a virus, was a known attack, or something
skipping to change at page 11, line 5 skipping to change at page 11, line 5
inspection engine can differentiate the garbage and failure cases, as inspection engine can differentiate the garbage and failure cases, as
garbage cases can be used to detect certain error cases (e.g. where 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 the ESP-NULL parameters are incorrect, or the flow is really an
encrypted ESP flow, not an ESP-NULL flow). encrypted ESP flow, not an ESP-NULL flow).
If the deep inspection engine will only return failure for all If the deep inspection engine will only return failure for all
garbage packets in addition to real failure cases, then a system garbage packets in addition to real failure cases, then a system
implementing the ESP-NULL heuristics cannot recover from error implementing the ESP-NULL heuristics cannot recover from error
situations quickly. situations quickly.
7. Special and Error Cases 6. Special and Error Cases
There is a small probability that an encrypted ESP packet (which There is a small probability that an encrypted ESP packet (which
looks like contain completely random bytes) will have correct bytes looks like contain completely random bytes) will have correct bytes
in correct locations, such that heuristics will detect the packet as in correct locations, such that heuristics will detect the packet as
an ESP-NULL packet instead of detecting that it is encrypted ESP an ESP-NULL packet instead of detecting that it is encrypted ESP
packet. The actual probabilities will be computed later in this packet. The actual probabilities will be computed later in this
document. Such a packet will not cause problems, as the deep document. Such a packet will not cause problems, as the deep
inspection engine will most likely reject the packet and return that inspection engine will most likely reject the packet and return that
it is garbage. If the deep inspection engine is rejecting a high it is garbage. If the deep inspection engine is rejecting a high
number of packets as garbage, it might indicate an original ESP-NULL number of packets as garbage, it might indicate an original ESP-NULL
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Actual limits for cache invalidation are local policy decisions. Actual limits for cache invalidation are local policy decisions.
Sample invalidation policies include: 50% of packets marked as Sample invalidation policies include: 50% of packets marked as
garbage within a second; or if a deep inspection engine cannot garbage within a second; or if a deep inspection engine cannot
differentiate between garbage and failure, failing more than 95% of differentiate between garbage and failure, failing more than 95% of
packets in last 10 seconds. For implementations that do not packets in last 10 seconds. For implementations that do not
distinguish between garbage and failure, failures should not be distinguish between garbage and failure, failures should not be
treated too quickly as indication of SA reuse. Often, single packets treated too quickly as indication of SA reuse. Often, single packets
cause state-related errors that block otherwise normal packets from cause state-related errors that block otherwise normal packets from
passing. passing.
8. UDP encapsulation 7. UDP encapsulation
The flow lookup code needs to detect UDP packets to or from port 4500 The flow lookup code needs to detect UDP packets to or from port 4500
in addition to the ESP packets, and perform similar processing to in addition to the ESP packets, and perform similar processing to
them after skipping the UDP header. As devices might be using them after skipping the UDP header. Each unique port pair makes
MOBIKE, that means that the flow cache should be shared between the separate IPsec flow, i.e. UDP encapsulated IPsec flows are
UDP encapsulated IPsec flows and non encapsulated IPsec flows. As identified by the source and destination IP, source and destination
port number and SPI number. As devices might be using MOBIKE, that
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 previously mentioned, differentiating between garbage and actual
policy failures will help in proper detection immensely. policy failures will help in proper detection immensely.
Because the checks are also run for packets having source port 4500 Because the checks are also run for packets having source port 4500
in addition to those having destination port 4500, this might cause in addition to those having destination port 4500, this might cause
the checks to be run for non-ESP traffic too. The UDP encapsulation the checks to be run for non-ESP traffic too. The UDP encapsulation
processing should also be avare of that. We cannot limit the checks processing should also be avare of that. We cannot limit the checks
for only UDP packets having destination port 4500, as return packets for only UDP packets having destination port 4500, as return packets
from the SGW going towards the NAT box do have source port 4500, and from the SGW going towards the NAT box do have source port 4500, and
some other port as destination port. some other port as destination port.
9. Heuristic Checks 8. Heuristic Checks
Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability Normally, HMAC-SHA1-96 or HMAC-MD5-96 gives 1 out of 2^96 probability
that a random packet will pass the HMAC test. This yields a that a random packet will pass the HMAC test. This yields a
99.999999999999999999999999998% probability that an end node will 99.999999999999999999999999998% probability that an end node will
correctly detect a random packet as being invalid. This means that correctly detect a random packet as being invalid. This means that
it should be enough for an intermediate device to check around 96 it should be enough for an intermediate device to check around 96
bits from the input packet. By comparing them against known values bits from the input packet. By comparing them against known values
for the packet we get more or less same probability as an end node is for the packet we get more or less same probability as an end node is
using. This gives an upper limit of how many bits heuristics need to 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 check - there is no point of checking much more than that many bits
(since that same probability is acceptable for the end node). In (since that same probability is acceptable for the end node). In
most of the cases the intermediate device does not need that high most of the cases the intermediate device does not need that high
probability, perhaps something around 32-64 bits is enough. probability, perhaps something around 32-64 bits is enough.
IPsec's ESP has a well-understood packet layout, but its variable- IPsec's ESP has a well-understood packet layout, but its variable-
length fields reduce the ability of pure algorithmic matching to one length fields reduce the ability of pure algorithmic matching to one
requiring heuristics and assigning probabilities. requiring heuristics and assigning probabilities.
9.1. ESP-NULL format 8.1. ESP-NULL format
The ESP-NULL format is as follows: The ESP-NULL format is as follows:
0 1 2 3 0 1 2 3
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 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 Parameters Index (SPI) | | Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV (optional) | | IV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data* (variable) | | Payload Data (variable) |
~ ~ ~ ~
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) | | | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header | | | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) | | Integrity Check Value-ICV (variable) |
~ ~ ~ ~
| | | |
skipping to change at page 14, line 14 skipping to change at page 14, line 14
the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL we the packet is encrypted ESP or ESP-NULL. In case it is ESP-NULL we
also need to know the Integrity Check Value (ICV) field length and also need to know the Integrity Check Value (ICV) field length and
the Initialization Vector (IV) length. the Initialization Vector (IV) length.
The currently defined ESP authentication algorithms have 5 different The currently defined ESP authentication algorithms have 5 different
lengths for the ICV field. Most commonly used is 96 bits for lengths for the ICV field. Most commonly used is 96 bits for
AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, and AUTH_HMAC_MD5_96, AUTH_HMAC_SHA1_96, AUTH_AES_XCBC_96, and
AUTH_AES_CMAC_96 algorithms. After that comes 128 bit ICV lengths AUTH_AES_CMAC_96 algorithms. After that comes 128 bit ICV lengths
for AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 AUTH_AES_128_GMAC, for AUTH_HMAC_MD5_128, AUTH_HMAC_SHA2_256_128 AUTH_AES_128_GMAC,
AUTH_AES_192_GMAC, AUTH_AES_256_GMAC algorithms. 160, 192, and 256 AUTH_AES_192_GMAC, AUTH_AES_256_GMAC algorithms. 160, 192, and 256
bit algorithms are used by AUTH_HMAC_SHA1_160, bit field lengths are used by AUTH_HMAC_SHA1_160,
AUTH_HMAC_SHA2_384_192, and AUTH_HMAC_SHA2_512_256 algorithms, AUTH_HMAC_SHA2_384_192, and AUTH_HMAC_SHA2_512_256 algorithms,
respectively. respectively.
In addition to the ICV length, there are also two possible values for In addition to the ICV length, there are also two possible values for
IV lengths: zero bytes (default) and eight bytes (for IV lengths: zero bytes (default) and eight bytes (for
AUTH_AES_*_GMAC). Detecting the IV length requires understanding the AUTH_AES_*_GMAC). Detecting the IV length requires understanding the
payload, i.e. the actual protocol data (meaning TCP, UDP, etc). This payload, i.e. the actual protocol data (meaning TCP, UDP, etc). This
is required to distinguish the optional random IV from the actual is required to distinguish the optional IV from the actual protocol
protocol data. If the protocol (also known as the, "next header") of data. How well IV can be distinguished from the actual protocol data
the packet is something that heuristics doesn't have protocol depends how the IV is generated. If IV is generated using method
checking support, then detecting the IV length is impossible, thus that generates random looking data (i.e. encrypted counter etc) then
the heuristics cannot finish. In that case heuristics returns disginguishing protocol data from IV is quite easy. If IV is counter
"unsure" and requires further packets. or similar non-random value, then there are bit more possibilities
for error. If the protocol (also known as the, "next header") of the
packet is something that heuristics doesn't have protocol checking
support, then detecting the IV length is impossible, thus the
heuristics cannot finish. In that case heuristics returns "unsure"
and requires further packets.
9.2. Self Describing Padding Check 8.2. Self Describing Padding Check
Before obtaining the next header field, the ICV length must be Before obtaining the next header field, the ICV length must be
measured. Five different ICV lengths leads to five possible places measured. Five different ICV lengths leads to five possible places
for the pad length and padding. Implementations must be careful when for the pad length and padding. Implementations must be careful when
trying larger sizes of ICV such that the inspected bytes do not trying larger sizes of ICV such that the inspected bytes do not
belong to data that is not payload data. For example, a ten-byte belong to data that is not payload data. For example, a ten-byte
ICMP echo request will have zero-length padding, but any checks for ICMP echo request will have zero-length padding, but any checks for
256-bit ICVs will inspect sequence number or SPI data if the packet 256-bit ICVs will inspect sequence number or SPI data if the packet
actually contains a 96-bit or 128-bit ICV. actually contains a 96-bit or 128-bit ICV.
skipping to change at page 15, line 5 skipping to change at page 15, line 10
than what is currently inspected. For example, if a packet has a 96- than what is currently inspected. For example, if a packet has a 96-
bit ICV and implementation starts first checking for a 256-bit ICV, bit ICV and implementation starts first checking for a 256-bit ICV,
it is possible that the cleartext part of the payload contains valid 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 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 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 inspected bytes are part of the longer ICV field, and should be
indistinguishable from random noise. indistinguishable from random noise.
Each ESP packet always has between 0-255 bytes of padding, and Each ESP packet always has between 0-255 bytes of padding, and
payload, pad length, and next header are always right aligned within payload, pad length, and next header are always right aligned within
a 4-byte boundary. The actual padding data has bytes starting from a 4-byte boundary. Normally implementations use minimal amount of
01 and ending to the pad length, i.e. exact padding and pad length padding, but heuristics method would be even more reliable if some
bytes for 4 bytes of padding would be 01 02 03 04 04. extra padding is added. The actual padding data has bytes starting
from 01 and ending to the pad length, i.e. exact padding and pad
length bytes for 4 bytes of padding would be 01 02 03 04 04.
Two cases of ESP-NULL padding are matched bytes (like the 04 04 shown Two cases of ESP-NULL padding are matched bytes (like the 04 04 shown
above), or the zero-byte padding case. In cases where there is one above), or the zero-byte padding case. In cases where there is one
or more bytes of padding, a node can perform a very simple and fast or more bytes of padding, a node can perform a very simple and fast
test -- a sequence of N N in any of those five locations. Given five test -- a sequence of N N in any of those five locations. Given five
two-byte locations (assuming the packet size allows all five possible two-byte locations (assuming the packet size allows all five possible
ICV lengths), the upper-bound probability of finding a random ICV lengths), the upper-bound probability of finding a random
encrypted packet that exhibits non-zero length ESP-NULL properties is encrypted packet that exhibits non-zero length ESP-NULL properties is
1-(1-255/65536)^5 == 0.019 == 1.9%. In the cases where there is 0 1-(1-255/65536)^5 == 0.019 == 1.9%. In the cases where there is 0
bytes of padding, a random encrypted ESP packet has 1-(1-1/256)^5 == bytes of padding, a random encrypted ESP packet has 1-(1-1/256)^5 ==
skipping to change at page 16, line 16 skipping to change at page 16, line 23
NULL with a known ICV length, but an unknown IV length. NULL with a known ICV length, but an unknown IV length.
Fortunately, in unknown protocol cases the IV length does not matter, Fortunately, in unknown protocol cases the IV length does not matter,
as the protocol is unknown to the heuristics, it will most likely be as the protocol is unknown to the heuristics, it will most likely be
unknown by the deep inspection engine also. It is therefore unknown by the deep inspection engine also. It is therefore
important that heuristics should support at least those same important that heuristics should support at least those same
protocols as the deep inspection engine does. Upon receipt of any protocols as the deep inspection engine does. Upon receipt of any
inner next header number that is known by the heuristics (and deep inner next header number that is known by the heuristics (and deep
inspection engine), the heuristics can detect the IV length properly. inspection engine), the heuristics can detect the IV length properly.
9.3. Protocol Checks 8.3. Protocol Checks
Generic protocol checking is much easier with pre-existing state. Generic protocol checking is much easier with pre-existing state.
For example, when many TCP / UDP flows are established over one SA, a For example, when many TCP / UDP flows are established over one SA, a
rekey with a new SA which needs heuristics. Then it is enough to rekey with a new SA which needs heuristics. Then it is enough to
just check that if the flow is already known by the deep inspection just check that if the flow is already known by the deep inspection
engine, it will give a strong leaning that the new SA is really ESP- engine, it will give a strong leaning that the new SA is really ESP-
NULL. NULL.
The worst case scenario is when an end node starts up communcation, The worst case scenario is when an end node starts up communcation,
i.e. it does not have any previous flows through the device. i.e. it does not have any previous flows through the device.
skipping to change at page 17, line 5 skipping to change at page 17, line 8
The second type of check is for variable, but easy-to-parse values. 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. For example, the 4-bit header length field of an inner IPv4 packet.
It has a fixed value (5) as long as there are no inner IPv4 options. It has a fixed value (5) as long as there are no inner IPv4 options.
If the header-length has that specific value, the number of known If the header-length has that specific value, the number of known
"good" bits increases. If it has some other value, the known "good" "good" bits increases. If it has some other value, the known "good"
bit count stays the same. A local policy might include reaching a bit count stays the same. A local policy might include reaching a
bit count that is over a threshold (for example 96 bits), causing a bit count that is over a threshold (for example 96 bits), causing a
packet to be marked as valid. packet to be marked as valid.
9.3.1. TCP checks 8.3.1. TCP checks
When the first TCP packet is feed to the heuristics, it is most When the first TCP packet is feed to the heuristics, it is most
likely going to be the SYN packet of the new connection, thus it will likely going to be the SYN packet of the new connection, thus it will
have less useful information than what other later packets might have less useful information than what other later packets might
have. Best valid packet checks include: checking that header length have. Best valid packet checks include: checking that header length
and reserved and other bits have valid values; checking source and and reserved and other bits have valid values; checking source and
destination port numbers, which in some cases can be used for destination port numbers, which in some cases can be used for
heuristics (but in general they cannot be used to reliably heuristics (but in general they cannot be used to reliably
distinguished from random numbers apart from some well-known ports distinguished from random numbers apart from some well-known ports
like 25/80/110/143). like 25/80/110/143).
skipping to change at page 17, line 40 skipping to change at page 17, line 43
destination port numbers, and where sequence numbers are either same destination port numbers, and where sequence numbers are either same
or right after each other, then it's likely a TCP packet has been or right after each other, then it's likely a TCP packet has been
correctly detected. correctly detected.
The deep inspection engines usually do very good TCP flow checking The deep inspection engines usually do very good TCP flow checking
already, including flow tracking, verification of sequence numbers, already, including flow tracking, verification of sequence numbers,
and reconstruction of the whole TCP flow. Similar methods can be and reconstruction of the whole TCP flow. Similar methods can be
used here, but they are implementation-dependent and not described used here, but they are implementation-dependent and not described
here. here.
9.3.2. UDP checks 8.3.2. UDP checks
UDP header has even more problems than the TCP header, as UDP has UDP header has even more problems than the TCP header, as UDP has
even less known data. The checksum has the same problem as the TCP even less known data. The checksum has the same problem as the TCP
checksum, due to NATs. The UDP length field might not match the checksum, due to NATs. The UDP length field might not match the
overall packet length, as the sender is allowed to include TFC overall packet length, as the sender is allowed to include TFC
(traffic flow confidentiality, see section 2.7 of IP Encapsulating (traffic flow confidentiality, see section 2.7 of IP Encapsulating
Security Payload document [RFC4303]) padding. Security Payload document [RFC4303]) padding.
With UDP packets similar multiple packet methods can be used as with With UDP packets similar multiple packet methods can be used as with
TCP, as UDP protocols usually include several packets using same port TCP, as UDP protocols usually include several packets using same port
numbers going from one end node to another, thus receiving multiple numbers going from one end node to another, thus receiving multiple
packets having a known pair of UDP port numbers is good indication packets having a known pair of UDP port numbers is good indication
that the heuristics have passed. that the heuristics have passed.
Some UDP protocols also use identical source and destination port Some UDP protocols also use identical source and destination port
numbers, thus that is also a good check. numbers, thus that is also a good check.
9.3.3. ICMP checks 8.3.3. ICMP checks
As ICMP messages are usually sent as return packets for other As ICMP messages are usually sent as return packets for other
packets, they are not very common packets to get as first packets for packets, they are not very common packets to get as first packets for
the SA, the ICMP Echo message being a noteworthy exception. ICMP the SA, the ICMP Echo message being a noteworthy exception. ICMP
ECHO has known type and code, identifier, and sequence number. The ECHO has known type and code, identifier, and sequence number. The
checksum, however, might be incorrect again because of NATs. checksum, however, might be incorrect again because of NATs.
For error ICMP messages the ICMP message contains part of the For error ICMP messages the ICMP message contains part of the
original IP packet inside, and then same rules which are used to original IP packet inside, and then same rules which are used to
detect IPv4/IPv6 tunnel checks can be used. detect IPv4/IPv6 tunnel checks can be used.
9.3.4. SCTP checks 8.3.4. SCTP checks
SCTP [RFC4960] has a self-contained checksum, which is computed over SCTP [RFC4960] has a self-contained checksum, which is computed over
the SCTP payload and is not affected by NATs unless the NAT is SCTP- the SCTP payload and is not affected by NATs unless the NAT is SCTP-
aware. Even more than the TCP and UDP checksums, the SCTP checksum aware. Even more than the TCP and UDP checksums, the SCTP checksum
is expensive, and may be prohibitive even for deep-packet is expensive, and may be prohibitive even for deep-packet
inspections. inspections.
SCTP chunks can be inspected to see if their lengths are consistent SCTP chunks can be inspected to see if their lengths are consistent
across the total length of the IP datagram, so long as TFC padding is across the total length of the IP datagram, so long as TFC padding is
not present. not present.
XXX TBA -- including possible chunk-specific checking. 8.3.5. IPv4 and IPv6 Tunnel checks
9.3.5. IPv4 and IPv6 Tunnel checks
In cases of tunneled traffic the packet inside contains a full IPv4 In cases of tunneled traffic the packet inside contains a full IPv4
or IPv6 packet. Many fields are useable. For IPv4 those fields or IPv6 packet. Many fields are useable. For IPv4 those fields
include version, header length, total length (again TFC padding might include version, header length, total length (again TFC padding might
confuse things there), protocol number, and 16-bit header checksum. confuse things there), protocol number, and 16-bit header checksum.
In those cases the intermediate device should give the decapsulated In those cases the intermediate device should give the decapsulated
IP packet to the deep inspection engine. IPv6 has less usable IP packet to the deep inspection engine. IPv6 has less usable
fields, but the version number, packet length (modulo TFC confusion) fields, but the version number, packet length (modulo TFC confusion)
and next-header all can be used by deep-packet inspection. and next-header all can be used by deep-packet inspection.
10. Security Considerations 9. Security Considerations
The whole deep inspection for ESP-NULL flows only has the problem The whole deep inspection for ESP-NULL flows only has the problem
that attacker can always bypass it by using encrypted ESP instead of that attacker can always bypass it by using encrypted ESP (or some
ESP-NULL unless that is not forbidden by policy. This means that in other encryption or tunneling method) instead of ESP-NULL unless that
the end the responsibility whether end node can bypass deep is not forbidden by policy. This means that in the end the
inspection is for the policy enforcement of the both end nodes, i.e. responsibility whether end node can bypass deep inspection is for the
if a server allows encrypted connections also, then attacker who policy enforcement of the both end nodes, i.e. if a server allows
wants to attack the server and wants to bypass deep inspection device encrypted connections also, then attacker who wants to attack the
in the middle, will use encrypted traffic. This means that the server and wants to bypass deep inspection device in the middle, will
protection of the whole network is only as good as the policy use encrypted traffic. This means that the protection of the whole
enforcement and protection of the end node. One way to enforce deep network is only as good as the policy enforcement and protection of
inspection for all traffic, is to forbid encrypted ESP completely, the end node. One way to enforce deep inspection for all traffic, is
but in that case ESP-NULL detection is easier, as all packets must be to forbid encrypted ESP completely, but in that case ESP-NULL
ESP-NULL based on the policy, and further restriction can eliminate detection is easier, as all packets must be ESP-NULL based on the
ambiguities in ICV and IV sizes. policy, and further restriction can eliminate ambiguities in ICV and
IV sizes.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
11.2. Informative References 10.2. Informative References
[I-D.bhatia-ipsecme-esp-null] [I-D.bhatia-ipsecme-esp-null]
Bhatia, M., "Identifying ESP-NULL Packets", Bhatia, M., "Identifying ESP-NULL Packets",
draft-bhatia-ipsecme-esp-null-00 (work in progress), draft-bhatia-ipsecme-esp-null-00 (work in progress),
December 2008. December 2008.
[I-D.hoffman-esp-null-protocol] [I-D.hoffman-esp-null-protocol]
Hoffman, P. and D. McGrew, "An Authentication-only Profile Hoffman, P. and D. McGrew, "An Authentication-only Profile
for ESP with an IP Protocol Identifier", for ESP with an IP Protocol Identifier",
draft-hoffman-esp-null-protocol-00 (work in progress), draft-hoffman-esp-null-protocol-00 (work in progress),
August 2007. August 2007.
[I-D.ietf-ipsecme-traffic-visibility] [I-D.ietf-ipsecme-traffic-visibility]
Grewal, K. and G. Montenegro, "Wrapped ESP for Traffic Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped ESP
Visibility", draft-ietf-ipsecme-traffic-visibility-01 for Traffic Visibility",
(work in progress), March 2009. draft-ietf-ipsecme-traffic-visibility-08 (work in
progress), September 2009.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[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",
skipping to change at page 23, line 6 skipping to change at page 23, line 6
// 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 * Drop invalid packet
* 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
// 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
* Continue Non-ESP-NULL processing * Continue Non-ESP-NULL processing
* Goto Check ESP-NULL packet * Goto Check ESP-NULL packet
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
skipping to change at page 23, line 48 skipping to change at page 24, line 4
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// This pseudocode uses following variables: // This pseudocode uses following variables:
// //
// SPI_offset, IV_len, ICV_len, State, SPI, // SPI_offset, IV_len, ICV_len, State, SPI,
// IP_total_len, IP_hdr_len, IP_Src_IP, IP_Dst_IP // IP_total_len, IP_hdr_len, IP_Src_IP, IP_Dst_IP
// as defined in fastpath pseudocode. // as defined in fastpath pseudocode.
// //
// Stored_Check_Bits:Number of bits we have successfully // Stored_Check_Bits:Number of bits we have successfully
// checked to contain acceptable values // checked to contain acceptable values
// in the actual payload data. This value // in the actual payload data. This value
// is stored / retreaved from SPI cache. // is stored / retrieved from SPI cache.
// //
// Check_Bits: Number of bits we have successfully // Check_Bits: Number of bits we have successfully
// checked to contain acceptable values // checked to contain acceptable values
// in the actual payload data. This value // in the actual payload data. This value
// is updated during the packet // is updated during the packet
// verification. // verification.
// //
// Last_Packet_Data: Contains selected pieces from the // Last_Packet_Data: Contains selected pieces from the
// last packet. This is used to compare // last packet. This is used to compare
// certain fields of this packet to // certain fields of this packet to
skipping to change at page 30, line 26 skipping to change at page 30, line 27
// for a suitable amount of bits. If all checks pass, then // for a suitable amount of bits. If all checks pass, then
// we just return Success, and the upper layer will then // we just return Success, and the upper layer will then
// later check if we have enough bits checked already. // later check if we have enough bits checked already.
* Load Protocol From IP_total_len - Test_ICV_len - 1 * Load Protocol From IP_total_len - Test_ICV_len - 1
* If Protocol TCP * If Protocol TCP
* Goto Verify TCP * Goto Verify TCP
* If Protocol UDP * If Protocol UDP
* Goto Verify UDP * Goto Verify UDP
// Other protocols can be added here as needed, most likely same // Other protocols can be added here as needed, most likely same
// protocols as deep inspection does // protocols as deep inspection does
// Tunnel mode checks is also left out from here to make the
// document shorter.
* Return Failure
//////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////
// Verify TCP protocol headers // Verify TCP protocol headers
// //
Verify TCP: Verify TCP:
// First we check things that must be set correctly. // First we check things that must be set correctly.
* Check TCP.reserved_bits are non-zero * Check TCP.reserved_bits are non-zero
* Return Failure * Return Failure
* If TCP.Data_Offset field < 5 * If TCP.Data_Offset field < 5
// TCP head length too small // TCP head length too small
 End of changes. 38 change blocks. 
83 lines changed or deleted 125 lines changed or added

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