>Number:         9674
>Category:       security
>Synopsis:       Bugs and documentation errors in racoon(8)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    security-officer (NetBSD Security Officer)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 26 02:24:00 2000
>Last-Modified:
>Originator:     Charles M. Hannum
>Organization:
	Internetwork Hacker
>Release:        -current as of 20000321
>Environment:
	n/a

>Description:
	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
	  parser.

	* 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
	  entries.

	* 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 rekeying.

	* 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.

>How-To-Repeat:
	Try to use racoon(8).

>Fix:
	None provided.
>Audit-Trail:
>Unformatted: