head	1.3;
access;
symbols
	RELEASE_6_0_0:1.2
	RELEASE_5_4_0:1.2
	RELEASE_4_11_0:1.2
	RELEASE_5_3_0:1.2
	RELEASE_4_10_0:1.2
	RELEASE_5_2_1:1.2
	RELEASE_5_2_0:1.2
	RELEASE_4_9_0:1.2
	RELEASE_5_1_0:1.2
	RELEASE_4_8_0:1.2
	RELEASE_5_0_0:1.2
	RELEASE_4_7_0:1.2
	RELEASE_4_6_2:1.2
	RELEASE_4_6_1:1.2
	RELEASE_4_6_0:1.2
	RELEASE_5_0_DP1:1.2
	RELEASE_4_5_0:1.2
	RELEASE_4_4_0:1.2
	RELEASE_4_3_0:1.2
	RELEASE_4_2_0:1.1.1.1
	RELEASE_4_1_1:1.1.1.1
	RELEASE_4_1_0:1.1.1.1
	v20000705a:1.1.1.1
	KAME:1.1.1;
locks; strict;
comment	@# @;


1.3
date	2005.11.18.14.20.17;	author sumikawa;	state dead;
branches;
next	1.2;

1.2
date	2001.01.07.15.40.11;	author will;	state Exp;
branches;
next	1.1;

1.1
date	2000.07.05.09.19.28;	author sumikawa;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	2000.07.05.09.19.28;	author sumikawa;	state Exp;
branches;
next	;


desc
@@


1.3
log
@Racoon is now maintained in security/ipsec-tools.
@
text
@racoon speaks IKE (ISAKMP/Oakley) key management protocol, to
establish security association with other hosts.

Known issues:
- Too many use of dynamic memory allocation, which leads to memory leak.
- Non-threaded implementation.  Simultaneous key negotiation performance
  should be improved.
- Cannot negotiate keys for per-socket policy.
- Cryptic configuration syntax - blame IPsec specification too...
- Needs more documentation.

Design choice, not a bug:
- racoon negotiate IPsec keys only.  It does not negotiate policy.  Policy must
  be configured into the kernel separately from racoon.  If you want to
  support roaming clients, you may need to have a mechanism to put policy
  for the roaming client after phase 1 finishes.

WWW: http://www.kame.net/
@


1.2
log
@Fix typo.

PR:		24127
Submitted by:	Alex D. Chen <dhchen@@dns.ktvs.org>
@
text
@@


1.1
log
@Initial revision
@
text
@d16 1
a16 1
  for the roaming client after phase 1 finhises.
@


1.1.1.1
log
@racoon: KAME IKE daemon
@
text
@@
