Comment regarding draft-mcdonald-pf-key-v2-00.txt

[Dennis Glatting <dennis.glatting@xxxxxxxxxxxxxxxxxxxxxxxx>]

The following text is from section 2.1, BASE MESSAGE HEADER
FORMAT of draft-mcdonald-pf-key-v2-00.txt:

> sadb_sa_ivlen   Contains the length of the initialization
>                 vector (IV) for the security association,
>                 expressed in bits.  The IV is the random
>                 data used by the cryptographic transform
>                 to process a packet.  The PF_KEY interface
>                 does not communicate or generate the IV
>                 data, but it does communicate the length
>                 of data needed.  A value of zero indicates
>                 that no IV is needed.
>

If the PF_KEY interface does not communicate the IV, does that
mean the kernel generates the IV?

Assuming the kernel is supposed to generate the IV, why not
allow the PF_KEY interface transfer an IV? It seems to me, if an
external hardware were available, random data would be best
obtained by a user level application rather than the kernel.
Why not generalize and have a function where the kernel MAY
request random data from a user level application for use as IV,
Cookies, ...


The document discusses the field "sadb_sa_dpd_domain" (Data
Protection Domain of Interpretation (DOI)) of the structure
sadb_msg_hdr but there is no such entry.  Perhaps it is
discussing "sadb_sa_sens_domain"?  Similarly,
"sadb_sa_sens_level" and "sadb_sa_integ_level" are
described however "sadb_sa_sens_label" and
"sadb_sa_integ_label" are sadb_msg_hdr's content.


Regarding Section 2.3, ADDITIONAL MESSAGE FIELDS, since the
daemons must always run locally, I disagree a sockaddr
structure must be defined to include sa_len if the native one
does not. Such a structure would be alien to the environment,
and, as mentioned in draft-mcdonald-pf-key-v2-00.txt,
redundant. Why is the inclusion of sa_len declared MUST?


The data gram depicted in Section 2.4, ILLUSTRATION OF MESSAGE
LAYOUT, does not match the definition of sadb_msg_hdr.


Values for LIFETYPE_SEC, LIFETYPE_KB, and LIFETYPE_PACKETS
are not defined.


In section 3.2, SECURITY ASSOCIATION STATE, the description
of SA_FORWARD does not follow the same format as the other state
flags.


-dpg