Tero, Dan and others, I've read your informational draft.
Overall comments: The draft contains quite a lot of background information (what you are trying to achieve on technical point of view, what were the alternative solutions considered). Part of this background is also available on WESP draft. Making this draft an information disclosure on "algorithm to determine if IPsec ESP packet stream has been encrypted or not", without too much explanation or hand waving would increase its usability. The background could be find by-reference on the WESP RFC. Please consider adding definitions/glossary entries for the following concepts: flow, flow-cache. I know they are relevant on certain implementations, but not necessarily well defined on that sense, or at least introducing these terms properly before using them. About the abstract: Consider changing abstract in a way that really points out the good on this approach. Something like: -8<--- This document describes an algorithm for distinguishing IPSEC ESP- NULL packets from encrypted ESP packets. The algorithm can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of this algorithm does not require any changes made on existing RFC4303 compliant IPSEC hosts. -8<--- About the algorithm: Pseudo-code seems sane, and was understandable after reading the specification part. However I did not try to implement it, nor really proof its correctness. P.S. Please ignore the following meaningless whining: About Security Considerations: Raises a question, why is this all needed? What is the use case? Neither this, nor WESP draft can give a simple answer for the question. If encrypted traffic is allowed to pass traffic analyzer/intrusion detector/intrusion prevention/firewall/whatever, the malicious end nodes will use encryption. If encrypted traffic is dropped by intermediate, then there is an end node policy issue. Detection whether an ESP packet payload is encrypted or not should already be fast on deep inspection packet matching hardware. -- Tero Mononen <[email protected]> _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
