Subject: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-00

From: Yaron Sheffer <[email-masked]>
Date: Tue, 18 Aug 2009 12:14:50 +0300

Hi everyone,

As a general comment, this document got me thinking whether pseudo-code can
be made amenable to some minimal level of validation. For example, there is
so much code here that I could never be sure that all "goto"s are
referencing valid labels. If any member of this list is a aware of such a
solution, I would be interested to know.

- Sec. 5. In the definition of IPsec flows, how is this done for (typically
tunnel mode) UDP-encapsulated ESP? Are port numbers part of the flow
definition? This text belongs either here or in Sec. 8.

- 5. "Unsure" - if we choose the option of dropping such packets, are there
cases when retransmitted packets do not add any information and we will
remain forever "unsure"?

- 6, first paragraph. in to -> into

- 6. This section seems to discuss the construction of an ESP-null detection
engine out of an off-the-shelf DPI engine. If this is the case, please say
so.

- 9.1. 160, 192, and 256 bit algorithms are used -> 160, 192, and 256 field
lengths are used

- 9.1. "Payload Data" is starred for some reason, probably cut-and-paste.

- 10. The Security Considerations needs to have an explanation of what this
is good for, i.e. what security policy is enforced, what kind of DPI is
done. Also, (malicious) traffic can be encrypted in multiple ways, e.g.
simply by using TLS on top of TCP. In addition, we need to note the DOS
potential of the ESP-null detection process.

- Pseudocode: are we assuming one protocol per SPI? At a higher level,
shouldn't we have processing for tunnel mode ESP as well?

- Pseudocode: retreaved -> retrieved

Thanks,

            Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Aug 2009 16:47:16 +0300

> definition? This text belongs either here or in Sec. 8.

Adding port numbers as part of the flow table might make some extra
flows in case the NAT box is rebooted and port numbers change, but it
is also safer assumption to do, as in case there is multiple clients
behind the same NAT box talking to the same SGW, the port numbers
is the only thing that differentiates those clients from each other.

I added text to section 8 saying "Each unique port pair makes separate
IPsec flow, i.e. UDP encapsulated IPsec flows are identified by the
source and destination IP, source and destination port number and SPI
number". 

> cases when retransmitted packets do not add any information and we will

It depends. If the packet is really encrypted ESP, then no, as each
retransmission will have different IV, which means every packet will
completely different, and that will make the heuristics to find out
that flow is not ESP-NULL (i.e. Self describing padding checks will
fail).

If packet is ESP-NULL packet and is about known protocol (TCP/UDP)
then simple checks given in the pseudocode work, i.e. we check that
the source and destination port numbers are same for the retransmitted
packet, and each of those will add some bits to the "Check_Bits"
value, and when it reaches the threshold set in the policy the flow is
recognized as ESP-NULL with given parameters.

The problem case is that if only packets sent by the flow are of some
unknown protocol, then heuristics cannot determine whether any of the
fields in the protocol data are correct, thus it cannot determine the
IV length. Even in this case the flow can be recognized as ESP-NULL
packet with known ICV length, but unknow IV length if we get
consistent next header fields in retrasmitted packets (as described at
the end of section 9.2). 

> - 6, first paragraph. in to -> into

Fixed. 

> engine out of an off-the-shelf DPI engine. If this is the case, please say

The section describes relationship between the deep inspection engine
and the heuristics, it is not necessarely related to the existing or
off-the-shelf DPI engines. 

> - 9.1. 160, 192, and 256 bit algorithms are used -> 160, 192, and 256 field

Fixed.

> - 9.1. "Payload Data" is starred for some reason, probably cut-and-paste.

Fixed.

> simply by using TLS on top of TCP.

One of the problems with using ESP-NULL is that I myself do not think
there is really any good uses for it. The attackers can bypass it so
easily by using encryption that I do not really know what kind of
security policies can be enforced with it (unless you use disallow
encrypted ESP compeltely, in which case heuristics come trivial).

This is the main reason I do not see that WESP or heuristics will ever
really get widely used anywhere.

My reason for heuristics is that for those who want this kind of thing
and who can explain themselves why they want it can implement them
without messing up the IPsec implementations :-)

The security considerations section already says that "The whole deep
inspection for ESP-NULL flows only has the problem that attacker can
always bypass it by using encrypted ESP instead of ESP-NULL unless
that is not forbidden by policy."

Changed that now to be:

"The whole deep inspection for ESP-NULL flows only has the problem
that attacker can always bypass it by using encrypted ESP (or some
other encryption or tunneling method) instead of ESP-NULL unless that
is not forbidden by policy."

so that should cover TLS over TCP, or IP over DNS etc style bypassing
methods... 

> In addition, we need to note the DOS potential of the ESP-null
> detection process.

Do we really? I think it is clear that any protocol can have bugs and
implementation issues, but we do not list that in every single
security considerations section (i.e. IKEv2 or AH or ESP). The DoS
potential of the ESP-null detection is not any different than DoS
potential of the IKEv2 implementation or ESP itself.

> - Pseudocode: are we assuming one protocol per SPI?

No. There can be multiple protocols going through the same SA. In some
cases it is more efficient if multiple TCP packets are sent during
detection process, but it works even if they come mixed in any way
(i.e. when it checks if the last packet received had same TCP/UDP
source/destination ports etc that is more efficient if the last packet
really was part of same TCP/UDP flow than this current packet, but
that is not required for correct operation). 

> At a higher level, shouldn't we have processing for tunnel mode ESP
> as well?

Yes, but to make pseudocode bit shorter, I left those out. As the
description of "Example Pseudocode" says "It does not include all the
required checks, and this is just example pseudocode".

Section 9.3.5. describe what kind of checks can/should be done for the
IPv4/IPv6 tunnel mode.

As the introduction section says that "Because the traffic inspected
is usually host to host traffic inside one organization, that
usually means transport mode IPsec is used." and because of this I
left those tunnel mode checks out from the pseudocode.

Also firewall / deep inspection engine implementors usually have very
good set of IPv4 and IPv6 header checks already in their products, so
they can reuse those.

Added comment about that to the pseudocode.

> - Pseudocode: retreaved -> retrieved

Fixed.
-- 
[email-masked]