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.