Subject: security/9674: Bugs and documentation errors in racoon(8)
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 03/26/2000 02:24:16
>Synopsis: Bugs and documentation errors in racoon(8)
>Responsible: security-officer (NetBSD Security Officer)
>Arrival-Date: Sun Mar 26 02:24:00 2000
>Originator: Charles M. Hannum
>Release: -current as of 20000321
There are many bugs in both the implementation and the
documentation of racoon(8). Namely:
* The example does not show any `encryption_algorithm' or
`authentication_algorithm' in the `proposal esp' stanza, but
the former is required. If it is not present, the proposal
is not linked into the policy structure, and the IPsec-SA
fails by failing to send any packets and timing out (a very
difficult problem to analyze).
* I have not been able to get the IPsec-SA negotiation to work
when a pfs_group is specified (as in the example).
* The syntax description lists `nonce_size' as a valid
statement in a protocol stanza, but it is not accepted by the
* The documentation does not mention that a SPD entry must be
added separately (i.e. with setkey(8)) for IPsec-SA
negotiation to work at all. (This is also lame. racoon(8)
should be able to generate the SPD entries itself.)
* In cases where we are unable to communicate after a SAD entry
is created (e.g. because of a mismatch between the manually
added SPD entries and racoon.conf(5), or because of a
configuration error), we keep adding more and more SAD
* The byte count soft limit does not appear to do anything.
* When the byte count hard limit is exceeded, the SAD entry is
deleted. However, this leaves the SAD entry in the other
direction around. When a packet is sent in the one direction
again, a new IPsec-SA is negotiated, resulting in a new pair
of SAD entries. The unpaired SAD entry is still retained.
It eventually hits its soft limit and causes a second complete
pair to be negotiated, leaving two pairs of SAD entries for
the same two hosts. There should only be one pair, except
* When using NFS with IPsec (between an i386 and a hpcmips),
with a key lifetime of 10m, between the soft limit (8m) and
the hard limit -- while rekeying is happening -- NFS traffic
is completely stalled.
* No useful diagnostics are produced when a key is missing from
the pre-shared-key file.
Try to use racoon(8).