summaryrefslogtreecommitdiffstats
path: root/include/asm-arm26
diff options
context:
space:
mode:
authorJamal Hadi Salim <hadi@cyberus.ca>2006-03-20 19:16:40 -0800
committerDavid S. Miller <davem@davemloft.net>2006-03-20 19:16:40 -0800
commit980ebd25794f0f87ac32844e2c73e9e81f0a72ba (patch)
treeda52df6e31bd4b2527c223ca2585e0d792bf3ea2 /include/asm-arm26
parentd51d081d65048a7a6f9956a7809c3bb504f3b95d (diff)
downloadlinux-980ebd25794f0f87ac32844e2c73e9e81f0a72ba.tar.gz
linux-980ebd25794f0f87ac32844e2c73e9e81f0a72ba.tar.bz2
linux-980ebd25794f0f87ac32844e2c73e9e81f0a72ba.zip
[IPSEC]: Sync series - acquire insert
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>
Diffstat (limited to 'include/asm-arm26')
0 files changed, 0 insertions, 0 deletions