Subject: [secdir] Review of draft-ietf-ipsecme-esp-null-heuristics-06.txt

From: Rob Austein <[email-masked]>
Date: Tue, 02 Mar 2010 14:48:22 -0500

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This draft documents a set of heuristics to allow a packet inspection
engine (stateful firewall, protocol analyzer, ...) to spot IPsec ESP
streams that use NULL encryption as efficiently as possible, without
modifications to the IPsec protocols.  While I have reservations about
some of the scenarios in which such a mechanism might be useful, this
is clearly a chartered work item for the IPSECME WG, this is happening
at a deep enough level that any a priori correlation between role and
hat color is quite weak, it seems likely to be deployed whether I like
it or not, and, in any case, as this draft makes no changes to IPsec
itself (thus placing the workload on the packet inspection engine),
this draft is less troubling than other approaches in this space.

The Security Considerations section is OK as far as it goes, but could
benefit from some additional text or references to other parts of the
document.  Specifically:

- The discussion of failure modes for the heuristics is in section 3,
  with no reference from the Security Considerations section.

- The discussion of failure modes for the heuristics in section 3 is
  also incomplete: while it (correctly, I think) concludes that
  misclassifying traffic as ESP-NULL is no worse than a DoS attack
  which an attacker could have launched anyway, it does not discuss
  the other failure mode: what happens if a stream is misclassified as
  non-NULL ESP, thus (depending on policy) allowing it through without
  inspection, or dropping it on the floor?

The above suggestions notwithstanding, I have no serious security
concerns with this document.  It doesn't modify IPsec, so from the
IPsec point of view this is at worst a public analysis of some
techniques for detecting a set of configuration choices that an IPsec
user presumably made intentionally.  From the packet inspection point
of view, the heuristics are probably both harmless and useful, subject
to the caveats above and in the document; packet inspection is an
error-prone activity in any case, and following the advice in this
document (which is targeted for Informational status) seems unlikely
to make things worse.

I did not attempt to review the pseudo-code in Appendix A.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Mar 2010 13:45:54 +0200

>   with no reference from the Security Considerations section.

Do you have any concrete proposal what text to add to security
considerations section?

>   inspection, or dropping it on the floor?

It does say that valid ESP-NULL stream cannot be misclassified as
non-ESP-NULL stream. The only way for valid ESP-NULL stream to be
classified as non-ESP-NULL is that the packet does not look valid
ESP-NULL packet (i.e. for example has garbage in the ESP padding), but
then it is not valid ESP-NULL packet anymore.

I.e. valid EPS-NULL packets cannot be misclassified, but of course
attacker can easily send packets which cause those packets to be
misclassified as encrypted ESP, but on the other hand attacker can
most likely also use encrypted ESP instead (as is listed in the
security considerations section) if encrypted ESP packets are to be
allowed to that host.

All of those depends very much about what kind of the policy is used
in the intermediate devices. If the policy says drop all packets which
cannot be inspected, then attacker does not gain anything by getting
flow misclassified. If policy is allow those through, then attacker
can use encrypted ESP to bypass the deep inspection device anyways,
which means the other end should have its own ways of inspecting the
packets anyways, as middle box cannot inspect them.
-- 
[email-masked]

---

From: Dan McDonald <[email-masked]>
Date: Wed, 3 Mar 2010 10:29:08 -0500

> Do you have any concrete proposal what text to add to security

Tero -- I will add some of your text below to both Section 3 and the Security
Considerations.

> then it is not valid ESP-NULL packet anymore.

Actually, it's possible that using an authentication algorithm of which the
inspector is not aware can cause ESP-NULL to be misclassified.  Other than
that, we catch everything else.

> security considerations section) if encrypted ESP packets are to be

Rob -- are you also worried about flow-poisoning?  If an attacker manages (by
chance?) to trick an inspecting node into considering a flow encrypted, and
then the inspecting node *caches* that flow as poison (a bad implementation
choice, to be sure, but possible given how much crap is out there), then
legitimate ESP-NULL packets could be dropped.

> flow misclassified.

The attacker gains denial-of-service, which may be all he/she wants.

Dan