diff options
author | Jamal Hadi Salim <hadi@cyberus.ca> | 2006-03-20 19:16:40 -0800 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2006-03-20 19:16:40 -0800 |
commit | 980ebd25794f0f87ac32844e2c73e9e81f0a72ba (patch) | |
tree | da52df6e31bd4b2527c223ca2585e0d792bf3ea2 /include/asm-frv/emergency-restart.h | |
parent | d51d081d65048a7a6f9956a7809c3bb504f3b95d (diff) | |
download | linux-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-frv/emergency-restart.h')
0 files changed, 0 insertions, 0 deletions