[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comment regarding draft-mcdonald-pf-key-v2-00.txt
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