A Cryptographic Evaluation of IPsec

TLDR: An evaluation of IPsec based on the November 1998 RFCs for IPsec found that it is probably the best IP security protocol available at the moment, but its main criticism is its complexity.

Abstract: In February 1999, we performed an evaluation of IPsec based on the November 1998 RFCs for IPsec [KA98c, KA98a, MG98a, MG98b, MD98, KA98b, Pip98, MSST98, HC98, GK98, TDG98, PA98]. Our evaluation focused primarily on the cryptographic properties of IPsec. We concentrated less on the integration aspects of IPsec, as neither of us is intimately familiar with typical IP implementations, IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. We are not alone in this opinion; from various discussions with the people involved, we learned that virtually nobody is satisfied with the process or the result. The development of IPsec seems to have been burdened by the committee process that it was forced to use, and it shows in the results. Even with all the serious critisisms that we have on IPsec, it is probably the best IP security protocol available at the moment. We have looked at other, functionally similar, protocols in the past (including PPTP [SM98, SM99]) in much the same manner as we have looked at IPsec. None of these protocols come anywhere near their target, but the others manage to miss the mark by a wider margin than IPsec. This difference is less significant from a security point of view; there are no points for getting security nearly right. From a marketing point of view, this is important. IPsec is the current “best practice,” no matter how badly that reflects on our ability to create a good security standard. Our main criticism of IPsec is its complexity. IPsec contains too many options and too much flexibility; there are often several ways of doing the same or similar things. This is a typical committee effect. Committees are notorious for adding features, options, and additional flexibility to satisfy various factions within the committee. As we all know, this additional complexity and bloat is seriously detrimental to a normal (functional) standard. However, it has a devastating effect on a security standard. It is instructive to compare this to the approach taken by NIST for the development of AES [NIST97a, NIST97b]. Instead of a committee, NIST organized a contest. Several small groups each created their own proposal, and the process is