IPsec APIs
Currently IPsec lacks a notion of APIs. By and large the world of IPsec functions on fairly static system configuration: an authentication and authorization database for the key exchange protocol(s) and a packet filtering type of policy.
Because networks aren’t static and because static configurations are difficult to manage we end up with, in practice, the use of rules that use wildcards (or moral equivalents) that reduce the security of the overall system somewhat, such as “all systems with a certificate that can be validated to this trust anchor can claim any IP address from the following blocks of addresses” — add wireless networking, note that IPsec protects packets rather than packet flows and such rules get weaker as the set of applicable peers grows larger.
Worse, application protocols that could benefit from IPsec that cannot simply say “use IPsec” (that is, most application protocols whose authors would like to rely on IPsec) cannot rely on IPsec at all, since IPsec is as a black box to them.
IPsec APIs could help drive the use of IPsec.
Solaris has some IPsec APIs (see previous post) and supports “connection latching” to protect packet flows, not just individual packets. It needs more. Specifically it needs to include support for specifying the desired name of a peer and support for discovering the actual phase 1 peer IDs for a given latched connection.
And we need a standard abstract IPsec API so that more standard Internet protocols can make use of IPsec.
Fortunately the IETF has a working group chartered to work on such an API: the BTNS (Better Than Nothing Security) WG. The name of that WG is a bit unfortunate: it reflects but one intended use of just one of its core work items (unauthenticated IPsec), but it has other work items that are needed to make that core item particularly useful, and those other work items happen to be applicable to IPsec in general: connection latching (protecting entire packet flows, not just individual packets) and IPsec APIs.