Last Call Review of draft-ietf-ipsecme-esp-null-heuristics-
review-ietf-ipsecme-esp-null-heuristics-secdir-lc-austein-2010-03-03-00

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.