User-space daemons have easy access to mass storage containing configuration information, such as the IPsec endpoint addresses, keys and certificates, as required.
For instance, this could be an AES key, information identifying the IP endpoints and ports that are to be protected, as well as what type of IPsec tunnel has been created.
[10] Originally, IKE had numerous configuration options but lacked a general facility for automatic negotiation of a well-known default case that is universally implemented.
The IKE specifications were open to a significant degree of interpretation, bordering on design faults (Dead Peer Detection being a case in point[citation needed]), giving rise to different IKE implementations not being able to create an agreed-upon security association at all for many combinations of options, however correctly configured they might appear at either end.
The following issues were addressed: The IETF ipsecme working group has standardized a number of extensions, with the goal of modernizing the IKEv2 protocol and adapting it better to high volume, production environments.
On Linux, Libreswan, Openswan and strongSwan implementations provide an IKE daemon which can configure (i.e., establish SAs) to the KLIPS or XFRM/NETKEY kernel-based IPsec stacks.
A number of network equipment vendors have created their own IKE daemons (and IPsec implementations), or license a stack from one another.
The following open source implementations of IKEv2 are available: Leaked NSA presentations released in 2014 by Der Spiegel indicate that IKE is being exploited in an unknown manner to decrypt IPsec traffic, as is ISAKMP.
[20] This claim was refuted in 2015 by both Eyal Ronen and Adi Shamir in their paper "Critical Review of Imperfect Forward Secrecy"[21] and by Paul Wouters of Libreswan in a 2015 article "66% of VPN's [sic] are not in fact broken".
[23] This can be avoided by careful segregation of client systems onto multiple service access points with stricter configurations.