[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: requirement



I think anything related to Policy Database should be kept out of
PF_KEY as much as possible. Limit the PFEKY api to be a management API
for the SADB only.

Only the ACQUIRE message could have some additional information that
identifies the triggering policy database entery. PFKEY could just
define a field or extension for some identifier, without specifying
any other semantics for it. Mapping this to real policy would be local
impelementation issue.

Thus, the following comments only on issues related to the SADB
maintenance.

> From: Shoichi Sakane <sakane@xxxxxxxx>

>    - it might need to improve the REGISTER message.
>      if an application could tell the kernel which packets are interesting,
>      it would be better for both an application and the kernel.
>      in the version 2, an application can tell only security protocols.

I'm not too happy about adding too many new features. We never get
this done, if there are too many changes. But, I do admit that a more
fine grained register might be useful. The example that comes to mind:
IKEv2 handles only unicast cases, multicast IPsec needs is probably an
alternate key manager, and it might be useful to be able direct
multicast related events only to the multicast key manager.

Thus, more fine grained register is possible new feature, but I would
keep it as low priority. Do it, if easy to do and if all implementors
can easily agree on the solution.

>    - new API must not impact on any current PF_KEY version 2
>      implementation when it will be employed.  the version number
>      has to increment, and implementations must handle the version
>      number properly.

Yup.

>    - new API may have the capability to dump data in the kernel.
>      the databases may be:
>            SAD

Dumping SAD already exists in form of "SADB_DUMP" (at least I have
this implemented). Just raise it from "debugging only" into valid
operation?

>            SPD

No. This is policy issue.

>            PAD

No. This is PAD issue, not SADB and thus not PFKEY.

> 
>            A                           B
>              \    === SA1,SA2 ===    /
>               SGa                 SGb
>              /    === SA3,SA4 ===    \
>            A'                          B'
> 
>      new API needs to specify a SA for a certain pair of the
>      identifiers applyed to the SA.

SA's already have a unique identifier: (SPI, prot, dst). Thus, as far
as I can see, SA1-SA4 can all uniquely identified already. A new
identifier would basicly replicate the triplet, and require additional
headaches: you need to define what does it mean to have two SA's with
different identifiers, but with exactly same triplet?

>    - capability to active or to inactivate a SA.

What does inactive SA mean?