980ebd2579
This introduces a feature similar to the one described in RFC 2367: " ... the application needing an SA sends a PF_KEY SADB_ACQUIRE message down to the Key Engine, which then either returns an error or sends a similar SADB_ACQUIRE message up to one or more key management applications capable of creating such SAs. ... ... The third is where an application-layer consumer of security associations (e.g. an OSPFv2 or RIPv2 daemon) needs a security association. Send an SADB_ACQUIRE message from a user process to the kernel. <base, address(SD), (address(P),) (identity(SD),) (sensitivity,) proposal> The kernel returns an SADB_ACQUIRE message to registered sockets. <base, address(SD), (address(P),) (identity(SD),) (sensitivity,) proposal> The user-level consumer waits for an SADB_UPDATE or SADB_ADD message for its particular type, and then can use that association by using SADB_GET messages. " An app such as OSPF could then use ipsec KM to get keys Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
Kconfig | ||
Makefile | ||
xfrm_algo.c | ||
xfrm_input.c | ||
xfrm_policy.c | ||
xfrm_state.c | ||
xfrm_user.c |