Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 176031 Details for
Bug 237132
net-misc/openswan 2.6.16 ebuild requirement
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
test of the failing XML file
xmltest (text/plain), 344.77 KB, created by
Rolando J. Zappacosta
on 2008-12-21 10:29:48 UTC
(
hide
)
Description:
test of the failing XML file
Filename:
MIME Type:
Creator:
Rolando J. Zappacosta
Created:
2008-12-21 10:29:48 UTC
Size:
344.77 KB
patch
obsolete
>Script started on Sun 21 Dec 2008 11:20:54 AM CET >]0;root@RJZ-LNX:~[?1034h[01;31mRJZ-LNX[01;34m ~ #[00m cd /var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m pwd >/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m ls -trl >total 2892 >-rw-r--r-- 1 root root 2274 2008-11-25 02:24 xauth.h >-rw-r--r-- 1 root root 61267 2008-11-25 02:24 xauth.c >-rw-r--r-- 1 root root 1718 2008-11-25 02:24 x509more.h >-rw-r--r-- 1 root root 10882 2008-11-25 02:24 x509keys.c >-rw-r--r-- 1 root root 22366 2008-11-25 02:24 x509.c >-rw-r--r-- 1 root root 17319 2008-11-25 02:24 whackinit.c >-rw-r--r-- 1 root root 59703 2008-11-25 02:24 whack.c >-rw-r--r-- 1 root root 1271 2008-11-25 02:24 virtual.h >-rw-r--r-- 1 root root 11679 2008-11-25 02:24 virtual.c >-rw-r--r-- 1 root root 5556 2008-11-25 02:24 vendor.h >-rw-r--r-- 1 root root 22681 2008-11-25 02:24 vendor.c >drwxr-xr-x 2 root root 4096 2008-11-25 02:24 [0m[01;34mtpm[0m >-rw-r--r-- 1 root root 5033 2008-11-25 02:24 TODO >-rw-r--r-- 1 root root 1569 2008-11-25 02:24 timer.h >-rw-r--r-- 1 root root 21336 2008-11-25 02:24 timer.c >-rw-r--r-- 1 root root 3187 2008-11-25 02:24 terminate.c >-rw-r--r-- 1 root root 19418 2008-11-25 02:24 sysdep_linux.c >-rw-r--r-- 1 root root 751 2008-11-25 02:24 sysdep_freebsd.c >-rw-r--r-- 1 root root 16650 2008-11-25 02:24 sysdep_darwin.c >-rw-r--r-- 1 root root 3896 2008-11-25 02:24 sysdep_cygwin.c >-rw-r--r-- 1 root root 16490 2008-11-25 02:24 sysdep_bsd.c >-rw-r--r-- 1 root root 2593 2008-11-25 02:24 stubs.c >-rw-r--r-- 1 root root 17785 2008-11-25 02:24 state.h >-rw-r--r-- 1 root root 40685 2008-11-25 02:24 state.c >-rw-r--r-- 1 root root 38223 2008-11-25 02:24 spdb_v2_struct.c >-rw-r--r-- 1 root root 68557 2008-11-25 02:24 spdb_v1_struct.c >-rw-r--r-- 1 root root 6894 2008-11-25 02:24 spdb_struct.c >-rw-r--r-- 1 root root 5178 2008-11-25 02:24 spdb_print.c >-rw-r--r-- 1 root root 6920 2008-11-25 02:24 spdb.h >-rw-r--r-- 1 root root 43556 2008-11-25 02:24 spdb.c >-rw-r--r-- 1 root root 14117 2008-11-25 02:24 smartcard.c >-rw-r--r-- 1 root root 5403 2008-11-25 02:24 smallprime.c >-rw-r--r-- 1 root root 2827 2008-11-25 02:24 server.h >-rw-r--r-- 1 root root 29254 2008-11-25 02:24 server.c >-rw-r--r-- 1 root root 14881 2008-11-25 02:24 [00;32mrouting.txt[0m >-rw-r--r-- 1 root root 919 2008-11-25 02:24 rnd.h >-rw-r--r-- 1 root root 5648 2008-11-25 02:24 rnd.c >-rw-r--r-- 1 root root 2860 2008-11-25 02:24 rndarc4.c >-rw-r--r-- 1 root root 805 2008-11-25 02:24 rcv_whack.h >-rw-r--r-- 1 root root 17788 2008-11-25 02:24 rcv_whack.c >-rw-r--r-- 1 root root 798 2008-11-25 02:24 rcv_info.h >-rw-r--r-- 1 root root 8666 2008-11-25 02:24 rcv_info.c >-rw-r--r-- 1 root root 1222 2008-11-25 02:24 quirks.h >-rw-r--r-- 1 root root 14130 2008-11-25 02:24 primegen.c >-rw-r--r-- 1 root root 117 2008-11-25 02:24 pluto-style.el >-rw-r--r-- 1 root root 23468 2008-11-25 02:24 plutomain.c >-rw-r--r-- 1 root root 1 2008-11-25 02:24 pluto_id.c >-rw-r--r-- 1 root root 7646 2008-11-25 02:24 pluto_crypt.h >-rw-r--r-- 1 root root 22134 2008-11-25 02:24 pluto_crypt.c >-rw-r--r-- 1 root root 4204 2008-11-25 02:24 PLUTO-CONVENTIONS >-rw-r--r-- 1 root root 55 2008-11-25 02:24 plutocerts.h >-rw-r--r-- 1 root root 657 2008-11-25 02:24 plutoalg.h >-rw-r--r-- 1 root root 20793 2008-11-25 02:24 plutoalg.c >-rw-r--r-- 1 root root 151041 2008-11-25 02:24 pluto.8.xml >-rw-r--r-- 1 root root 378 2008-11-25 02:24 pending.h >-rw-r--r-- 1 root root 8700 2008-11-25 02:24 pending.c >-rw-r--r-- 1 root root 2944 2008-11-25 02:24 ocsp.h >-rw-r--r-- 1 root root 46199 2008-11-25 02:24 ocsp.c >-rw-r--r-- 1 root root 1082 2008-11-25 02:24 ocf_pk.h >-rw-r--r-- 1 root root 2939 2008-11-25 02:24 ocf_pk.c >-rw-r--r-- 1 root root 2511 2008-11-25 02:24 ocf_cryptodev.h >-rw-r--r-- 1 root root 9453 2008-11-25 02:24 ocf_cryptodev.c >-rw-r--r-- 1 root root 5120 2008-11-25 02:24 nat_traversal.h >-rw-r--r-- 1 root root 27730 2008-11-25 02:24 nat_traversal.c >-rw-r--r-- 1 root root 4477 2008-11-25 02:24 myid.c >-rw-r--r-- 1 root root 3266 2008-11-25 02:24 msgdigest.c >-rw-r--r-- 1 root root 9778 2008-11-25 02:24 Makefile.options >-rw-r--r-- 1 root root 74648 2008-11-25 02:24 Makefile.depend.linux >-rw-r--r-- 1 root root 59093 2008-11-25 02:24 Makefile.depend.freebsd >-rw-r--r-- 1 root root 8772 2008-11-25 02:24 Makefile >-rw-r--r-- 1 root root 4935 2008-11-25 02:24 log.h >drwxr-xr-x 2 root root 4096 2008-11-25 02:24 [01;34mlinux26[0m >-rw-r--r-- 1 root root 3078 2008-11-25 02:24 keys.h >-rw-r--r-- 1 root root 22067 2008-11-25 02:24 keys.c >-rw-r--r-- 1 root root 4060 2008-11-25 02:24 kernel_win2k.c >-rw-r--r-- 1 root root 2544 2008-11-25 02:24 kernel_pfkey.h >-rw-r--r-- 1 root root 51837 2008-11-25 02:24 kernel_pfkey.c >-rw-r--r-- 1 root root 865 2008-11-25 02:24 kernel_noklips.h >-rw-r--r-- 1 root root 3688 2008-11-25 02:24 kernel_noklips.c >-rw-r--r-- 1 root root 885 2008-11-25 02:24 kernel_netlink.h >-rw-r--r-- 1 root root 46810 2008-11-25 02:24 kernel_netlink.c >-rw-r--r-- 1 root root 13427 2008-11-25 02:24 kernel_mast.c >-rw-r--r-- 1 root root 0 2008-11-25 02:24 kernel_klips.h >-rw-r--r-- 1 root root 9710 2008-11-25 02:24 kernel_klips.c >-rw-r--r-- 1 root root 10681 2008-11-25 02:24 kernel.h >-rw-r--r-- 1 root root 87428 2008-11-25 02:24 kernel.c >-rw-r--r-- 1 root root 28857 2008-11-25 02:24 kernel_bsdkame.c >-rw-r--r-- 1 root root 942 2008-11-25 02:24 kameipsec.h >-rw-r--r-- 1 root root 13819 2008-11-25 02:24 ipsec.secrets.5.xml >-rw-r--r-- 1 root root 4440 2008-11-25 02:24 ipsec.secrets >-rw-r--r-- 1 root root 4618 2008-11-25 02:24 ipsec_doi.h >-rw-r--r-- 1 root root 23827 2008-11-25 02:24 ipsec_doi.c >-rw-r--r-- 1 root root 44589 2008-11-25 02:24 initiate.c >-rw-r--r-- 1 root root 8280 2008-11-25 02:24 ikev2_x509.c >-rw-r--r-- 1 root root 6479 2008-11-25 02:24 ikev2_rsa.c >-rw-r--r-- 1 root root 6250 2008-11-25 02:24 ikev2_psk.c >-rw-r--r-- 1 root root 476 2008-11-25 02:24 ikev2_prfplus.h >-rw-r--r-- 1 root root 2762 2008-11-25 02:24 ikev2_prfplus.c >-rw-r--r-- 1 root root 58447 2008-11-25 02:24 ikev2_parent.c >-rw-r--r-- 1 root root 5387 2008-11-25 02:24 ikev2.h >-rw-r--r-- 1 root root 3976 2008-11-25 02:24 ikev2_crypto.c >-rw-r--r-- 1 root root 12781 2008-11-25 02:24 ikev2_child.c >-rw-r--r-- 1 root root 26542 2008-11-25 02:24 ikev2.c >-rw-r--r-- 1 root root 1037 2008-11-25 02:24 ikev1_quick.h >-rw-r--r-- 1 root root 72111 2008-11-25 02:24 ikev1_quick.c >-rw-r--r-- 1 root root 83998 2008-11-25 02:24 ikev1_main.c >-rw-r--r-- 1 root root 3631 2008-11-25 02:24 ikev1.h >-rw-r--r-- 1 root root 1076 2008-11-25 02:24 ikev1_continuations.h >-rw-r--r-- 1 root root 68913 2008-11-25 02:24 ikev1.c >-rw-r--r-- 1 root root 30988 2008-11-25 02:24 ikev1_aggr.c >-rw-r--r-- 1 root root 2454 2008-11-25 02:24 ikeping.c >-rw-r--r-- 1 root root 1092 2008-11-25 02:24 ike_continuations.h >-rw-r--r-- 1 root root 2310 2008-11-25 02:24 ike_alg_twofish.c >-rw-r--r-- 1 root root 3515 2008-11-25 02:24 ike_alg_status.c >-rw-r--r-- 1 root root 1640 2008-11-25 02:24 ike_alg_sha2.c >-rw-r--r-- 1 root root 1771 2008-11-25 02:24 ike_alg_serpent.c >-rw-r--r-- 1 root root 96 2008-11-25 02:24 ike_alginit.c >-rw-r--r-- 1 root root 3175 2008-11-25 02:24 ike_alg.h >-rw-r--r-- 1 root root 8420 2008-11-25 02:24 ike_alg.c >-rw-r--r-- 1 root root 1275 2008-11-25 02:24 ike_alg_blowfish.c >-rw-r--r-- 1 root root 1601 2008-11-25 02:24 ike_alg_aes.c >-rw-r--r-- 1 root root 1133 2008-11-25 02:24 hostpair.h >-rw-r--r-- 1 root root 8521 2008-11-25 02:24 hostpair.c >-rw-r--r-- 1 root root 2387 2008-11-25 02:24 hmac.c >-rw-r--r-- 1 root root 74 2008-11-25 02:24 HACKERSGUIDE >-rw-r--r-- 1 root root 4845 2008-11-25 02:24 gcryptfix.h >-rw-r--r-- 1 root root 6099 2008-11-25 02:24 gcryptfix.c >-rw-r--r-- 1 root root 1036 2008-11-25 02:24 foodgroups.h >-rw-r--r-- 1 root root 10658 2008-11-25 02:24 foodgroups.c >-rw-r--r-- 1 root root 1650 2008-11-25 02:24 fetch.h >-rw-r--r-- 1 root root 21069 2008-11-25 02:24 fetch.c >-rw-r--r-- 1 root root 1444 2008-11-25 02:24 elgamal.h >-rw-r--r-- 1 root root 15071 2008-11-25 02:24 elgamal.c >-rw-r--r-- 1 root root 1325 2008-11-25 02:24 dsa.h >-rw-r--r-- 1 root root 11408 2008-11-25 02:24 dsa.c >-rw-r--r-- 1 root root 462 2008-11-25 02:24 dpd.h >-rw-r--r-- 1 root root 18548 2008-11-25 02:24 dpd.c >-rw-r--r-- 1 root root 3280 2008-11-25 02:24 dnskey.h >-rw-r--r-- 1 root root 54186 2008-11-25 02:24 dnskey.c >-rw-r--r-- 1 root root 4175 2008-11-25 02:24 demux.h >-rw-r--r-- 1 root root 11470 2008-11-25 02:24 demux.c >-rw-r--r-- 1 root root 1912 2008-11-25 02:24 defs.h >-rw-r--r-- 1 root root 2530 2008-11-25 02:24 defs.c >-rw-r--r-- 1 root root 1500 2008-11-25 02:24 db_ops.h >-rw-r--r-- 1 root root 12504 2008-11-25 02:24 db_ops.c >-rw-r--r-- 1 root root 2074 2008-11-25 02:24 crypt_utils.c >-rw-r--r-- 1 root root 11407 2008-11-25 02:24 crypt_start_dh.c >-rw-r--r-- 1 root root 4430 2008-11-25 02:24 crypto.h >-rw-r--r-- 1 root root 10406 2008-11-25 02:24 crypto.c >-rw-r--r-- 1 root root 5337 2008-11-25 02:24 crypt_ke.c >-rw-r--r-- 1 root root 18081 2008-11-25 02:24 crypt_dh.c >-rw-r--r-- 1 root root 960 2008-11-25 02:24 cookie.h >-rw-r--r-- 1 root root 2044 2008-11-25 02:24 cookie.c >-rw-r--r-- 1 root root 16550 2008-11-25 02:24 connections.h >-rw-r--r-- 1 root root 90536 2008-11-25 02:24 connections.c >-rw-r--r-- 1 root root 40591 2008-11-25 02:24 CHANGES >drwxr-xr-x 2 root root 4096 2008-11-25 02:24 [01;34malg[0m >-rw-r--r-- 1 root root 2591 2008-11-25 02:24 adns.h >-rw-r--r-- 1 root root 13728 2008-11-25 02:24 adns.c >-rw-r--r-- 1 root root 24427 2008-11-25 02:24 ac.c >-rw-r--r-- 1 root root 87092 2008-12-21 11:04 pluto.8 >-rw-r--r-- 1 root root 23585 2008-12-21 11:04 log.c >-rw-r--r-- 1 root root 11346 2008-12-21 11:04 ipsec.secrets.5 >[m]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m [Kxm >xmbind xml2-config xmlcatalog xmlindexer xmlpatterns xmlproc_val xmlto xmodmap >xmessage xml2po xmlif xmllint xmlproc_parse xmlrpc-c-config xmlwf >[01;31mRJZ-LNX[01;34m pluto #[00m xmllint man pluto.8.xml >warning: failed to load external entity "man" >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:947: parser error : Entity 'nbsp' not defined > --physical eth0</para> > ^ >pluto.8.xml:1261: parser error : Entity 'nbsp' not defined > <term><option>--ctlbase</option> <emphasis > ^ >pluto.8.xml:1272: parser error : Entity 'nbsp' not defined > <term><option>--optionsfrom</option> <emphasis > ^ >pluto.8.xml:1281: parser error : Entity 'nbsp' not defined > <term><option>--label</option> <emphasis > ^ >pluto.8.xml:1328: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:1340: parser error : Entity 'nbsp' not defined > <para> client_subnet<-->host:ikeport<-->nexth > ^ >pluto.8.xml:1340: parser error : Entity 'nbsp' not defined > <para> client_subnet<-->host:ikeport<-->nexth > ^ >pluto.8.xml:1340: parser error : Entity 'nbsp' not defined > <para> client_subnet<-->host:ikeport<-->nexth > ^ >pluto.8.xml:1351: parser error : Entity 'nbsp' not defined > <term><option>--id</option> <emphasis > ^ >pluto.8.xml:1386: parser error : Entity 'nbsp' not defined > <term><option>--host</option> <emphasis > ^ >pluto.8.xml:1389: parser error : Entity 'nbsp' not defined > <term><option>--host</option> <emphasis > ^ >pluto.8.xml:1392: parser error : Entity 'nbsp' not defined > <term><option>--host</option> <emphasis > ^ >pluto.8.xml:1409: parser error : Entity 'nbsp' not defined > <term><option>--cert</option> <emphasis > ^ >pluto.8.xml:1425: parser error : Entity 'nbsp' not defined > <term><option>--ca</option> <emphasis remap="I">distinguished > ^ >pluto.8.xml:1437: parser error : Entity 'nbsp' not defined > <term><option>--groups</option> <emphasis remap="I">access > ^ >pluto.8.xml:1446: parser error : Entity 'nbsp' not defined > <term><option>--sendcert</option> <emphasis > ^ >pluto.8.xml:1464: parser error : Entity 'nbsp' not defined > <term><option>--certtype</option> <emphasis > ^ >pluto.8.xml:1473: parser error : Entity 'nbsp' not defined > <term><option>--ikeport</option> <emphasis > ^ >pluto.8.xml:1486: parser error : Entity 'nbsp' not defined > <term><option>--nexthop</option> <emphasis > ^ >pluto.8.xml:1504: parser error : Entity 'nbsp' not defined > <term><option>--client</option> <emphasis > ^ >pluto.8.xml:1526: parser error : Entity 'nbsp' not defined > <term><option>--clientwithin</option> <emphasis > ^ >pluto.8.xml:1536: parser error : Entity 'nbsp' not defined > <term><option>--clientprotoport</option> <emphasis > ^ >pluto.8.xml:1553: parser error : Entity 'nbsp' not defined > <term><option>--srcip</option> <emphasis > ^ >pluto.8.xml:1675: parser error : Entity 'nbsp' not defined > <term><option>--updown</option> <emphasis > ^ >pluto.8.xml:1833: parser error : Entity 'nbsp' not defined > <term><option>--pfsgroup</option> <emphasis > ^ >pluto.8.xml:1862: parser error : Entity 'nbsp' not defined > <term><option>--esp</option> <emphasis > ^ >pluto.8.xml:1904: parser error : Entity 'nbsp' not defined > <term><option>--dpddelay</option> <emphasis > ^ >pluto.8.xml:1915: parser error : Entity 'nbsp' not defined > <term><option>--timeout</option> <emphasis > ^ >pluto.8.xml:1928: parser error : Entity 'nbsp' not defined > <term><option>--dpdaction</option> <emphasis > ^ >pluto.8.xml:2159: parser error : Entity 'nbsp' not defined > <term><option>--ikelifetime</option> <emphasis > ^ >pluto.8.xml:2172: parser error : Entity 'nbsp' not defined > <term><option>--ipseclifetime</option> <emphasis > ^ >pluto.8.xml:2185: parser error : Entity 'nbsp' not defined > <term><option>--rekeymargin</option> <emphasis > ^ >pluto.8.xml:2197: parser error : Entity 'nbsp' not defined > <term><option>--rekeyfuzz</option> <emphasis > ^ >pluto.8.xml:2211: parser error : Entity 'nbsp' not defined > <term><option>--keyingtries</option> <emphasis > ^ >pluto.8.xml:2259: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2273: parser error : Entity 'nbsp' not defined > <term><option>--deletestate</option> <emphasis > ^ >pluto.8.xml:2299: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2316: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2341: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2371: parser error : Entity 'nbsp' not defined > <term><option>--oppohere</option> <emphasis > ^ >pluto.8.xml:2374: parser error : Entity 'nbsp' not defined > <term><option>--oppothere</option> <emphasis > ^ >pluto.8.xml:2392: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2405: parser error : Entity 'nbsp' not defined > <term><option>--crash</option> <emphasis > ^ >pluto.8.xml:2473: parser error : Entity 'nbsp' not defined > <term><option>--keyid </option><replaceable>id</replaceable></ter > ^ >pluto.8.xml:2496: parser error : Entity 'nbsp' not defined > <term><option>--pubkeyrsa </option><replaceable>key</replaceable> > ^ >pluto.8.xml:2587: parser error : Entity 'nbsp' not defined > <para> ipsec pluto</para> > ^ >pluto.8.xml:2587: parser error : Entity 'nbsp' not defined > <para> ipsec pluto</para> > ^ >pluto.8.xml:2587: parser error : Entity 'nbsp' not defined > <para> ipsec pluto</para> > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2599: parser error : Entity 'nbsp' not defined > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > ^ >pluto.8.xml:2599: parser error : Entity 'nbsp' not defined > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > ^ >pluto.8.xml:2599: parser error : Entity 'nbsp' not defined > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > ^ >pluto.8.xml:2600: parser error : Entity 'nbsp' not defined > --ipseclifetime 800 --keyingtries 3</para> > ^ >pluto.8.xml:2600: parser error : Entity 'nbsp' not defined > --ipseclifetime 800 --keyingtries 3</para> > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2611: parser error : Entity 'nbsp' not defined > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > ^ >pluto.8.xml:2611: parser error : Entity 'nbsp' not defined > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > ^ >pluto.8.xml:2611: parser error : Entity 'nbsp' not defined > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > ^ >pluto.8.xml:2612: parser error : Entity 'nbsp' not defined > --client 10.0.2.0/24 --encrypt</para> > ^ >pluto.8.xml:2626: parser error : Entity 'nbsp' not defined > <para> ipsec whack --listen</para> > ^ >pluto.8.xml:2626: parser error : Entity 'nbsp' not defined > <para> ipsec whack --listen</para> > ^ >pluto.8.xml:2626: parser error : Entity 'nbsp' not defined > <para> ipsec whack --listen</para> > ^ >pluto.8.xml:2634: parser error : Entity 'nbsp' not defined > <para> ipsec whack --route secret</para> > ^ >pluto.8.xml:2634: parser error : Entity 'nbsp' not defined > <para> ipsec whack --route secret</para> > ^ >pluto.8.xml:2634: parser error : Entity 'nbsp' not defined > <para> ipsec whack --route secret</para> > ^ >pluto.8.xml:2640: parser error : Entity 'nbsp' not defined > <para> ipsec whack > ^ >pluto.8.xml:2640: parser error : Entity 'nbsp' not defined > <para> ipsec whack > ^ >pluto.8.xml:2640: parser error : Entity 'nbsp' not defined > <para> ipsec whack > ^ >pluto.8.xml:2641: parser error : Entity 'nbsp' not defined > --initiate --name secret</para> > ^ >pluto.8.xml:2641: parser error : Entity 'nbsp' not defined > --initiate --name secret</para> > ^ >pluto.8.xml:2650: parser error : Entity 'nbsp' not defined > <para> ipsec whack --shutdown</para> > ^ >pluto.8.xml:2650: parser error : Entity 'nbsp' not defined > <para> ipsec whack --shutdown</para> > ^ >pluto.8.xml:2650: parser error : Entity 'nbsp' not defined > <para> ipsec whack --shutdown</para> > ^ >pluto.8.xml:2670: parser error : Entity 'nbsp' not defined > <option>--xauthuser </option><replaceable>user</replaceable> > ^ >pluto.8.xml:2671: parser error : Entity 'nbsp' not defined > <option>--xauthpass </option><replaceable>pass</replaceable> may be > ^ >pluto.8.xml:2672: parser error : Entity 'nbsp' not defined > be given prior to the <option>--initiate </option> to provide > ^ >pluto.8.xml:3254: parser error : Entity 'nbsp' not defined > <term>pluto --secretsfile ipsec.secrets > ^ >pluto.8.xml:3255: parser error : Entity 'nbsp' not defined > --ctlbase pluto.base --ikeport 8500 --nofork --use-nostack > ^ >pluto.8.xml:3255: parser error : Entity 'nbsp' not defined > --ctlbase pluto.base --ikeport 8500 --nofork --use-nostack > ^ >pluto.8.xml:3274: parser error : Entity 'nbsp' not defined > â| â to distinguish them from error messages.</para> > ^ ><?xml version="1.0" encoding="UTF-8"?> ><!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> ><!-- lifted from troff+man by doclifter --> ><refentry id="pluto8"> > <refentryinfo> > <date>26 October 2006</date> > </refentryinfo> > > <refmeta> > <refentrytitle>IPSEC_PLUTO</refentrytitle> > > <manvolnum>8</manvolnum> > > <refmiscinfo class="date">25 February 2008</refmiscinfo> > </refmeta> > > <refnamediv id="name"> > <refname>ipsec pluto</refname> > > <refpurpose>ipsec whack : IPsec IKE keying daemon and control > interface</refpurpose> > </refnamediv> > > <!-- body begins here --> > > <refsynopsisdiv id="synopsis"> > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>pluto</replaceable></arg> > > <arg choice="opt">--help</arg> > > <arg choice="opt">--version</arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--nofork</arg> > > <arg choice="opt">--stderrlog</arg> > > <arg choice="opt">--use-auto</arg> > > <arg choice="opt">--use-klips</arg> > > <arg choice="opt">--use-netkey</arg> > > <arg choice="opt">--use-nostack</arg> > > <arg choice="opt">--uniqueids</arg> > > <arg choice="opt">--nat_traversal</arg> > > <arg choice="opt">--virtual_private > <replaceable>network_list</replaceable></arg> > > <arg choice="opt">--keep_alive > <replaceable>delay_sec</replaceable></arg> > > <arg choice="opt">--force_keepalive</arg> > > <arg choice="opt">--force_busy</arg> > > <arg choice="opt">--disable_port_floating</arg> > > <arg choice="opt">--nocrsend</arg> > > <arg choice="opt">--strictcrlpolicy</arg> > > <arg choice="opt">--crlcheckinterval</arg> > > <arg choice="opt">--ocspuri</arg> > > <arg choice="opt">--interface > <replaceable>interfacename</replaceable></arg> > > <arg choice="opt">--ikeport <replaceable>portnumber</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--secretsfile > <replaceable>secrets-file</replaceable></arg> > > <arg choice="opt">--adns <replaceable>pathname</replaceable></arg> > > <arg choice="opt">--nhelpers <replaceable>number</replaceable></arg> > > <arg choice="opt">--lwdnsq <replaceable>pathname</replaceable></arg> > > <arg choice="opt">--perpeerlog</arg> > > <arg choice="opt">--perpeerlogbase > <replaceable>dirname</replaceable></arg> > > <arg choice="opt">--ipsecdir <replaceable>dirname</replaceable></arg> > > <arg choice="opt">--coredir <replaceable>dirname</replaceable></arg> > > <arg choice="opt">--noretransmits</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--help</arg> > > <arg choice="opt">--version</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--debug-none</arg> > > <arg choice="opt">--debug-all</arg> > > <arg choice="opt">--debug-raw</arg> > > <arg choice="opt">--debug-crypt</arg> > > <arg choice="opt">--debug-parsing</arg> > > <arg choice="opt">--debug-emitting</arg> > > <arg choice="opt">--debug-control</arg> > > <arg choice="opt">--debug-lifecycle</arg> > > <arg choice="opt">--debug-klips</arg> > > <arg choice="opt">--debug-pfkey</arg> > > <arg choice="opt">--debug-nat-t</arg> > > <arg choice="opt">--debug-dpd</arg> > > <arg choice="opt">--debug-dns</arg> > > <arg choice="opt">--debug-oppo</arg> > <arg choice="opt">--debug-oppoinfo</arg> > <arg choice="opt">--debug-whackwatch</arg> > > <arg choice="opt">--debug-private</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <group choice="opt"> > <arg choice="opt">--ipv4</arg> > > <arg choice="opt">--ipv6</arg> > </group> > > <group choice="opt"> > <arg choice="opt">--tunnelipv4</arg> > > <arg choice="opt">--tunnelipv6</arg> > </group> > > <sbr/> > > <sbr/> > > <arg choice="opt">--id <replaceable>identity</replaceable></arg> > > <arg choice="opt">--host <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--cert <replaceable>path</replaceable></arg> > > <arg choice="opt">--ca <replaceable>distinguished > name</replaceable></arg> > > <arg choice="opt">--groups <replaceable>access control > groups</replaceable></arg> > > <arg choice="opt">--sendcert <group choice="plain"> > <arg choice="plain">yes</arg> > > <arg choice="plain">forced</arg> > > <arg choice="plain">always</arg> > > <arg choice="plain">ifasked</arg> > > <arg choice="plain">no</arg> > > <arg choice="plain">never</arg> > </group></arg> > > <arg choice="opt">--certtype <replaceable>number</replaceable></arg> > > <arg choice="opt">--ikeport <replaceable>portnumber</replaceable></arg> > > <arg choice="opt">--nexthop <replaceable>ip-address</replaceable></arg> > > <group choice="opt"> > <arg choice="opt">--client <replaceable>subnet</replaceable></arg> > > <arg choice="opt">--clientwithin > <replaceable>subnet</replaceable></arg> > </group> > > <arg choice="opt">--clientprotoport > <replaceable>protocol</replaceable>/<replaceable>port</replaceable></arg> > > <arg choice="opt">--srcip <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--xauthserver</arg> > > <arg choice="opt">--xauthclient</arg> > > <arg choice="opt">--modecfgserver</arg> > > <arg choice="opt">--modecfgclient</arg> > > <arg choice="opt">--modecfgdns1</arg> > > <arg choice="opt">--modecfgdns2</arg> > > <arg choice="opt">--modecfgwins1</arg> > > <arg choice="opt">--modecfgwins2</arg> > > <arg choice="opt">--dnskeyondemand</arg> > > <arg choice="opt">--updown <replaceable>updown</replaceable></arg> > > <sbr/> > > <sbr/> > > <arg choice="plain">--to</arg> > > <sbr/> > > <sbr/> > > <arg choice="opt">--id <replaceable>identity</replaceable></arg> > > <arg choice="opt">--host <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--cert <replaceable>path</replaceable></arg> > > <arg choice="opt">--ca <replaceable>distinguished > name</replaceable></arg> > > <arg choice="opt">--groups <replaceable>access control > groups</replaceable></arg> > > <arg choice="opt">--sendcert <group choice="plain"> > <arg choice="plain">yes</arg> > > <arg choice="plain">always</arg> > > <arg choice="plain">ifasked</arg> > > <arg choice="plain">no</arg> > > <arg choice="plain">never</arg> > </group></arg> > > <arg choice="opt">--certtype <replaceable>number</replaceable></arg> > > <arg choice="opt">--ikeport <replaceable>port-number</replaceable></arg> > > <arg choice="opt">--nexthop <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--client <replaceable>subnet</replaceable></arg> > > <arg choice="opt">--clientwithin <replaceable>subnet</replaceable></arg> > > <arg choice="opt">--clientprotoport > <replaceable>protocol</replaceable>/<replaceable>port</replaceable></arg> > > <arg choice="opt">--srcip <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--xauthserver</arg> > > <arg choice="opt">--xauthclient</arg> > > <arg choice="opt">--modecfgserver</arg> > > <arg choice="opt">--modecfgclient</arg> > > <arg choice="opt">--modecfgdns1 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--modecfgdns2 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--modecfgwins1 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--modecfgwins2 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--dnskeyondemand</arg> > > <arg choice="opt">--updown <replaceable>updown</replaceable></arg> > > <sbr/> > > <sbr/> > > <arg choice="opt">--tunnel</arg> > > <arg choice="opt">--psk</arg> > > <arg choice="opt">--rsasig</arg> > > <arg choice="opt">--encrypt</arg> > > <arg choice="opt">--authenticate</arg> > > <arg choice="opt">--compress</arg> > > <arg choice="opt">--pfs</arg> > > <arg choice="opt">--pfsgroup <group choice="plain"> > <arg choice="opt">modp1024</arg> > > <arg choice="opt">modp1536</arg> > > <arg choice="opt">modp2048</arg> > > <arg choice="opt">modp3072</arg> > > <arg choice="opt">modp4096</arg> > > <arg choice="opt">modp6144</arg> > > <arg choice="opt">modp8192</arg> > </group></arg> > > <arg choice="opt">--disablearrivalcheck</arg> > > <arg choice="opt">--ikelifetime <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--ipseclifetime > <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--rekeymargin <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--rekeyfuzz > <replaceable>percentage</replaceable></arg> > > <arg choice="opt">--keyingtries <replaceable>count</replaceable></arg> > > <arg choice="opt">--esp <replaceable>esp-algos</replaceable></arg> > > <arg choice="opt">--dontrekey</arg> > > <arg choice="opt">--aggrmode</arg> > > <arg choice="opt">--modecfgpull</arg> > > <group choice="opt"> > <arg choice="opt">--dpddelay <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--dpdtimeout > <replaceable>seconds</replaceable></arg> > </group> > > <arg choice="opt">--dpdaction <group choice="plain"> > <arg choice="opt">clear</arg> > > <arg choice="opt">hold</arg> > > <arg choice="opt">restart</arg> > </group></arg> > > <arg choice="opt">--forceencaps</arg> > > <arg choice="opt"><group choice="plain"> > <arg choice="opt">--initiateontraffic</arg> > > <arg choice="opt">--pass</arg> > > <arg choice="opt">--drop</arg> > > <arg choice="opt">--reject</arg> > </group></arg> > > <arg choice="opt"><group choice="plain"> > <arg choice="opt">--failnone</arg> > > <arg choice="opt">--failpass</arg> > > <arg choice="opt">--faildrop</arg> > > <arg choice="opt">--failreject</arg> > </group></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--keyid <replaceable>id</replaceable></arg> > > <arg choice="opt">--addkey</arg> > > <arg choice="opt">--pubkeyrsa <replaceable>key</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--myid <replaceable>id</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="plain"> > <arg choice="plain">--listen</arg> > > <arg choice="plain">--unlisten</arg> > </group> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="plain"> > <arg choice="plain">--route</arg> > > <arg choice="plain">--unroute</arg> > </group> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="plain"> > <arg choice="plain">--initiate</arg> > > <arg choice="plain">--terminate</arg> > </group> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="opt">--xauthuser <replaceable>user</replaceable></arg> > > <arg choice="opt">--xauthpass <replaceable>pass</replaceable></arg> > > <arg choice="opt">--asynchronous</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="opt"> > <arg choice="opt">--tunnelipv4</arg> > > <arg choice="opt">--tunnelipv6</arg> > </group> > > <arg choice="plain">--oppohere > <replaceable>ip-address</replaceable></arg> > > <arg choice="plain">--oppothere > <replaceable>ip-address</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--crash</arg> > > <arg choice="opt">ipaddress</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--whackrecord</arg> > > <arg choice="opt">filename</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--whackstoprecord</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="plain">--delete</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--deletestate > <replaceable>state-number</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="opt">--debug-none</arg> > > <arg choice="opt">--debug-all</arg> > > <arg choice="opt">--debug-raw</arg> > > <arg choice="opt">--debug-crypt</arg> > > <arg choice="opt">--debug-parsing</arg> > > <arg choice="opt">--debug-emitting</arg> > > <arg choice="opt">--debug-control</arg> > > <arg choice="opt">--debug-controlmore</arg> > > <arg choice="opt">--debug-lifecycle</arg> > > <arg choice="opt">--debug-klips</arg> > > <arg choice="opt">--debug-pfkey</arg> > > <arg choice="opt">--debug-dns</arg> > > <arg choice="opt">--debug-dpd</arg> > > <arg choice="opt">--debug-natt</arg> > > <arg choice="opt">--debug-oppo</arg> > > <arg choice="opt">--debug-oppoinfo</arg> > > <arg choice="opt">--debug-whackwatch</arg> > > <arg choice="opt">--debug-private</arg> > > <arg choice="opt">--impair-delay-adns-key-answer</arg> > > <arg choice="opt">--impair-delay-adns-txt-answer</arg> > > <arg choice="opt">--impair-bust-mi2</arg> > > <arg choice="opt">--impair-bust-mr2</arg> > > <arg choice="opt">--impair-sa-fail</arg> > > <arg choice="opt">--impair-die-oninfo</arg> > > <arg choice="opt">--impair-jacob-two-two</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--utc</arg> > > <arg choice="opt">--listall</arg> > > <arg choice="opt">--listpubkeys</arg> > > <arg choice="opt">--listcerts</arg> > > <arg choice="opt">--listcacerts</arg> > > <arg choice="opt">--listacerts</arg> > > <arg choice="opt">--listaacerts</arg> > > <arg choice="opt">--listocspcerts</arg> > > <arg choice="opt">--listgroups</arg> > > <arg choice="opt">--listcrls</arg> > > <arg choice="opt">--listocsp</arg> > > <arg choice="opt">--listcards</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--utc</arg> > > <arg choice="opt">--rereadsecrets</arg> > > <arg choice="opt">--rereadall</arg> > > <arg choice="opt">--rereadcacerts</arg> > > <arg choice="opt">--rereadacerts</arg> > > <arg choice="opt">--rereadaacerts</arg> > > <arg choice="opt">--rereadocspcerts</arg> > > <arg choice="opt">--rereadcrls</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--purgeocsp</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--listevents</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--status</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--shutdown</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > </refsynopsisdiv> > > <refsect1 id="description"> > <title>DESCRIPTION</title> > > <para><emphasis remap="B">pluto</emphasis> is an IKE (âIPsec Key > Exchangeâ) daemon. <emphasis remap="B">whack</emphasis> is an auxiliary > program to allow requests to be made to a running <emphasis remap="B">pluto</emphasis>.</para> > > <para><emphasis remap="B">pluto</emphasis> is used to automatically build > shared âsecurity associationsâ on a system that has IPsec, the secure IP > protocol. In other words, <emphasis remap="B">pluto</emphasis> can > eliminate much of the work of manual keying. The actual secure > transmission of packets is the responsibility of other parts of the system > - the kernel. Pluto can talk to various kernel implementations, such as > <emphasis remap="B">KLIPS</emphasis>, such as <emphasis remap="B">NETKEY</emphasis>, and such as <emphasis remap="B">KAME</emphasis> IPsec stacks. <citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> provides a more convenient interface to <emphasis remap="B">pluto</emphasis> and <emphasis remap="B">whack</emphasis>.</para> > > <refsect2 id="ikes_job"> > <title>IKE's Job</title> > > <para>A <emphasis remap="I">Security Association</emphasis> (<emphasis remap="I">SA</emphasis>) is an agreement between two network nodes on > how to process certain traffic between them. This processing involves > encapsulation, authentication, encryption, or compression.</para> > > <para>IKE can be deployed on a network node to negotiate Security > Associations for that node. These IKE implementations can only negotiate > with other IKE implementations, so IKE must be on each node that is to > be an endpoint of an IKE-negotiated Security Association. No other nodes > need to be running IKE.</para> > > <para>An IKE instance (i.e. an IKE implementation on a particular > network node) communicates with another IKE instance using UDP IP > packets, so there must be a route between the nodes in each > direction.</para> > > <para>The negotiation of Security Associations requires a number of > choices that involve tradeoffs between security, convenience, trust, and > efficiency. These are policy issues and are normally specified to the > IKE instance by the system administrator.</para> > > <para>IKE deals with two kinds of Security Associations. The first part > of a negotiation between IKE instances is to build an ISAKMP SA. An > ISAKMP SA is used to protect communication between the two IKEs. IPsec > SAs can then be built by the IKEs - these are used to carry protected IP > traffic between the systems.</para> > > <para>The negotiation of the ISAKMP SA is known as Phase 1. In theory, > Phase 1 can be accomplished by a couple of different exchange types. > Currently, Main Mode and Aggressive Mode are implemented.</para> > > <para>Any negotiation under the protection of an ISAKMP SA, including > the negotiation of IPsec SAs, is part of Phase 2. The exchange type that > we use to negotiate an IPsec SA is called Quick Mode.</para> > > <para>IKE instances must be able to authenticate each other as part of > their negotiation of an ISAKMP SA. This can be done by several > mechanisms described in the draft standards.</para> > > <para>IKE negotiation can be initiated by any instance with any other. > If both can find an agreeable set of characteristics for a Security > Association, and both recognize each others authenticity, they can set > up a Security Association. The standards do not specify what causes an > IKE instance to initiate a negotiation.</para> > > <para>In summary, an IKE instance is prepared to automate the management > of Security Associations in an IPsec environment, but a number of issues > are considered policy and are left in the system administrator's > hands.</para> > </refsect2> > > <refsect2 id="pluto"> > <title>Pluto</title> > > <para><emphasis remap="B">pluto</emphasis> is an implementation of IKE. > It runs as a daemon on a network node. Currently, this network node must > be a LINUX system running the <emphasis remap="B">KLIPS</emphasis> or > <emphasis remap="B">NETKEY</emphasis> implementation of IPsec, or a > FreeBSD/NetBSD/Mac OSX system running the <emphasis remap="B">KAME</emphasis> implementation of IPsec.</para> > > <para><emphasis remap="B">pluto</emphasis> implements a large subset of > IKE. This is enough for it to interoperate with other instances of > <emphasis remap="B">pluto</emphasis>, and many other IKE > implementations. It currently supports XAUTH, ModeConfig, X.509, Dead > Peer Detection, Opportunistic Encryption and all the NAT Traversal > standards.</para> > > <para>The policy for acceptable characteristics for Security > Associations is mostly hardwired into the code of <emphasis remap="B">pluto</emphasis> (spdb.c). Eventually this will be moved into > a security policy database with reasonable expressive power and more > convenience.</para> > > <para><emphasis remap="B">pluto</emphasis> uses shared secrets or RSA > signatures to authenticate peers with whom it is negotiating. These RSA > signatures can come from DNS(SEC), a configuration file, or from X.509 > and CA certificates.</para> > > <para><emphasis remap="B">pluto</emphasis> initiates negotiation of a > Security Association when it is manually prodded: the program <emphasis remap="B">whack</emphasis> is run to trigger this. It will also initiate > a negotiation when <emphasis remap="B">KLIPS</emphasis> traps an > outbound packet for Opportunistic Encryption.</para> > > <para><emphasis remap="B">pluto</emphasis> implements ISAKMP SAs itself. > After it has negotiated the characteristics of an IPsec SA, it directs > the <emphasis remap="B">kernel</emphasis> to implement it. If necessary, > it also invokes a script to adjust any firewall and issue <citerefentry> > <refentrytitle>route</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> commands to direct IP packets.</para> > > <para>When <emphasis remap="B">pluto</emphasis> shuts down, it closes > all Security Associations.</para> > </refsect2> > > <refsect2 id="before_running_pluto"> > <title>Before Running Pluto</title> > > <para><emphasis remap="B">pluto</emphasis> runs as a daemon with userid > root. Before running it, a few things must be set up.</para> > > <para><emphasis remap="B">pluto</emphasis> requires a working IPsec > stack.</para> > > <para><emphasis remap="B">pluto</emphasis> supports multiple public > networks (that is, networks that are considered insecure and thus need > to have their traffic encrypted or authenticated). It discovers the > public interfaces to use by looking at all interfaces that are > configured (the <option>--interface</option> option can be used to limit > the interfaces considered). It does this only when <emphasis remap="B">whack</emphasis> tells it to --listen, so the interfaces must > be configured by then. Each interface with a name of the form > <command>ipsec</command>[<literal>0</literal>-<literal>9</literal>] is > taken as a <emphasis remap="B">KLIPS</emphasis> virtual public > interface. Another network interface with the same IP address (the first > one found will be used) is taken as the corresponding real public > interface. <citerefentry> > <refentrytitle>ifconfig</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> or <citerefentry> > <refentrytitle>ip</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> with the <option>-a</option> flag will show the name > and status of each network interface.</para> > > <para><emphasis remap="B">pluto</emphasis> requires a database of > preshared secrets and RSA private keys. This is described in the > <citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>. <emphasis remap="B">pluto</emphasis> is told of RSA > public keys via <emphasis remap="B">whack</emphasis> commands. If the > connection is Opportunistic, and no RSA public key is known, <emphasis remap="B">pluto</emphasis> will attempt to fetch RSA keys using the > Domain Name System.</para> > </refsect2> > > <refsect2 id="setting_up_fbklipsfp_for_fbplutofp"> > <title>Setting up <emphasis remap="B">KLIPS</emphasis> for <emphasis remap="B">pluto</emphasis></title> > > <para>The most basic network topology that <emphasis remap="B">pluto</emphasis> supports has two security gateways > negotiating on behalf of client subnets. The diagram of RGB's testbed is > a good example (see <emphasis remap="I">klips/doc/rgb_setup.txt</emphasis>).</para> > > <para>The file <filename>INSTALL</filename> in the base directory of > this distribution explains how to start setting up the whole system, > including <emphasis remap="B">KLIPS</emphasis>.</para> > > <para>Make sure that the security gateways have routes to each other. > This is usually covered by the default route, but may require issuing > <citerefentry> > <refentrytitle>route</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> commands. The route must go through a particular IP > interface (we will assume it is <emphasis remap="I">eth0</emphasis>, but > it need not be). The interface that connects the security gateway to its > client must be a different one.</para> > > <para>It is necessary to issue a <citerefentry> > <refentrytitle>ipsec_tncfg</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> command on each gateway. The required command > is:</para> > > <para> ipsec tncfg --attach --virtual ipsec0 > --physical eth0</para> > > <para>A command to set up the ipsec0 virtual interface will also need to > be run. It will have the same parameters as the command used to set up > the physical interface to which it has just been connected using > <citerefentry> > <refentrytitle>ipsec_tncfg</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>.</para> > </refsect2> > > <refsect2 id="setting_up_fbnetkeyfp_for_fbplutofp"> > <title>Setting up <emphasis remap="B">NETKEY</emphasis> for <emphasis remap="B">pluto</emphasis></title> > > <para>No special requirements are necessary to use NETKEY - it ships > with all modern versions of Linux 2.4 and 2.6. however, note that > certain vendors or older distributions use old versions or backports of > NETKEY which are broken. If possible use a NETKEY version that is at > least based on, or backported from Linux 2.6.11 or newer.</para> > </refsect2> > > <refsect2 id="ipsecsecrets_file"> > <title>ipsec.secrets file</title> > > <para>A <emphasis remap="B">pluto</emphasis> daemon and another IKE > daemon (for example, another instance of <emphasis remap="B">pluto</emphasis>) must convince each other that they are who > they are supposed to be before any negotiation can succeed. This > authentication is accomplished by using either secrets that have been > shared beforehand (manually) or by using RSA signatures. There are other > techniques, but they have not been implemented in <emphasis remap="B">pluto</emphasis>.</para> > > <para>The file <filename>/etc/ipsec.secrets</filename> is used to keep > preshared secret keys, RSA private keys, X.509 encoded keyfiles and > smartcard PIN's for authentication with other IKE daemons. For > debugging, there is an argument to the <emphasis remap="B">pluto</emphasis> command to use a different file. This file is > described in <citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>.</para> > </refsect2> > > <refsect2 id="running_pluto"> > <title>Running Pluto</title> > > <para>To fire up the daemon, just type <emphasis remap="B">pluto</emphasis> (be sure to be running as the superuser). The > default IKE port number is 500, the UDP port assigned by IANA for IKE > Daemons. <emphasis remap="B">pluto</emphasis> must be run by the > superuser to be able to use the UDP 500 port. If pluto is told to enable > NAT-Traversal, then UDP port 4500 is also taken by pluto to listen > on.</para> > > <para>Pluto supports different IPstacks on different operating systems. > The option <option>--use-auto</option>, which is also the default, lets > pluto find a stack automatically. This behaviour can be changed by > explicitely setting the stack using <option>--use-klips</option>, > <option>--use-netkey</option> or <option>--use-nostack</option>. The > latter is meant for testing only - no actual IPsec connections will be > loaded into the kernel.</para> > > <para>Pluto supports the NAT-Traversal drafts and the final standard, > RFC 3947, if the <option>--nat_traversal</option> is specified. The > allowed range behind the NAT routers is submitted using the > <option>--virtual_private</option> option. See <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> for the syntax. The option > <option>--force_keepalive</option> forces the sending of the <emphasis remap="I">keep-alive packets</emphasis>, which are send to prevent the > NAT router from closing its port when there is not enough traffic on the > IPsec connection. The <option>--keep_alive</option> sets the delay (in > seconds) of these keep-alive packets. The newer NAT-T standards support > <emphasis remap="I">port floating</emphasis>, and Openswan enables this > per default. It can be disabled using the > <option>--disable_port_floating</option> option.</para> > > <para>Pluto supports the use of X.509 certificates and sends it > certificate when needed. This can confuse IKE implementations that do > not implement this, such as the old FreeS/WAN implementation. The > <option>--nocrsend</option> prevents pluto from sending these. At > startup, pluto loads all the X.509 related files from the directories > <filename>/etc/ipsec.d/certs</filename>, > <filename>/etc/ipsec.d/cacerts</filename>, > <filename>/etc/ipsec.d/aacerts</filename>, > <filename>/etc/ipsec.d/ocspcerts</filename>, > <filename>/etc/ipsec.d/private</filename> and > <filename>/etc/ipsec.d/crls</filename>. The <emphasis remap="I">Certificate Revocation Lists</emphasis> can also be retrieved > from an URL. The option <option>--crlcheckinterval</option> sets the > time between checking for CRL expiration and issuing new fetch commands. > The first attempt to update a CRL is started at <emphasis remap="I">2*crlcheckinterval</emphasis> before the next update time. > Pluto logs a warning if no valid CRL was loaded or obtained for a > connection. If <option>--strictcrlpolicy</option> is given, the > connection will be rejected until a valid CRL has been loaded. Pluto > also has support for the <emphasis remap="I">Online Certificate Store > Protocol</emphasis> (OSCP) as defined in RFC 2560. The URL to the OSCP > store can be given to pluto via the <option>--ocspuri</option> > option.</para> > > <para>Pluto can use the BIND9 secure resolver, which means it has > support for DNSSEC, using the BIND9 <emphasis remap="I">lwres > {}</emphasis> interface, see <citerefentry> > <refentrytitle>named.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>. Pluto can also use the old <emphasis remap="I">adns</emphasis> interface if there is no BIND9 running with > <emphasis remap="I">lwres {}</emphasis> on the host, but then pluto > cannot do any DNSSEC processing. Pluto forks and starts these DNS > helpers in seperate children. The options <option>--lwdnsq</option> and > <option>--adns</option> invoke these resolvers.</para> > > <para>Pluto can also use helper children to off-load cryptographic > operations. This behavior can be fine tuned using the > <option>--nhelpers</option>. Pluto will start <emphasis remap="I">(n-1)</emphasis> of them, where <emphasis remap="I">n</emphasis> is the number of CPUâs you have (including > hypherthreaded CPUâs). A value of <emphasis remap="I">0</emphasis> > forces pluto to do all operations in the main process. A value of > <emphasis remap="I">-1</emphasis> tells pluto to perform the above > calculation. Any other value forces the number to that amount.</para> > > <para><emphasis remap="B">pluto</emphasis> attempts to create a lockfile > with the name <filename>/var/run/pluto/pluto.pid</filename>. If the > lockfile cannot be created, <emphasis remap="B">pluto</emphasis> exits - > this prevents multiple <emphasis remap="B">pluto</emphasis>s from > competing Any âleftoverâ lockfile must be removed before <emphasis remap="B">pluto</emphasis> will run. <emphasis remap="B">pluto</emphasis> writes its pid into this file so that scripts > can find it. This lock will not function properly if it is on an NFS > volume (but sharing locks on multiple machines doesn't make sense > anyway).</para> > > <para><emphasis remap="B">pluto</emphasis> then forks and the parent > exits. This is the conventional âdaemon forkâ. It can make debugging > awkward, so there is an option to suppress this fork. In certain > configurations, pluto might also launch helper programs to assist with > DNS queries or to offload cryptographic operations.</para> > > <para>All logging, including diagnostics, is sent to <citerefentry> > <refentrytitle>syslog</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry> with facility=authpriv; it decides where to put these > messages (possibly in /var/log/secure). Since this too can make > debugging awkward, the option <option>--stderrlog</option> is used to > steer logging to stderr.</para> > > <para>If the <option>--perpeerlog</option> option is given, then pluto > will open a log file per connection. By default, this is in > /var/log/pluto/peer, in a subdirectory formed by turning all dot (.) > [IPv4} or colon (:) [IPv6] into slashes (/).</para> > > <para>The base directory can be changed with the > <option>--perpeerlogbase</option>.</para> > > <para>Once <emphasis remap="B">pluto</emphasis> is started, it waits for > requests from <emphasis remap="B">whack</emphasis>.</para> > </refsect2> > > <refsect2 id="plutos_internal_state"> > <title>Pluto's Internal State</title> > > <para>To understand how to use <emphasis remap="B">pluto</emphasis>, it > is helpful to understand a little about its internal state. Furthermore, > the terminology is needed to decipher some of the diagnostic > messages.</para> > > <para>Pluto supports <emphasis remap="B">food groups</emphasis>, and > X.509 certificates. These are located in /etc/ipsec.d, or another > directory as specified by <option>--ipsecdir</option>.</para> > > <para>Pluto may core dump. It will normally do so into the current > working directory. The standard scripts have an option dumpdir=, which > can set the current directory to determine where the core dump will go. > In some cases, it may be more convenient to specify it on the command > line using --coredir. A third method is to set the environment variable > PLUTO_CORE_DIR. The command line argument takes precedence over the > environment variable. The option plutorestartoncrash can be set to no to > prevent multiple core files and a looping pluto process. Normally, when > pluto crashes, another pluto process is started.</para> > > <para>At times it may be desireable to turn off all timed events in > <emphasis remap="B">pluto</emphasis>, this can be done with > <option>--noretransmits</option>.</para> > > <para>The <emphasis remap="I">(potential) connection</emphasis> database > describes attributes of a connection. These include the IP addresses of > the hosts and client subnets and the security characteristics desired. > <emphasis remap="B">pluto</emphasis> requires this information (simply > called a connection) before it can respond to a request to build an SA. > Each connection is given a name when it is created, and all references > are made using this name.</para> > > <para>During the IKE exchange to build an SA, the information about the > negotiation is represented in a <emphasis remap="I">state > object</emphasis>. Each state object reflects how far the negotiation > has reached. Once the negotiation is complete and the SA established, > the state object remains to represent the SA. When the SA is terminated, > the state object is discarded. Each State object is given a serial > number and this is used to refer to the state objects in logged > messages.</para> > > <para>Each state object corresponds to a connection and can be thought > of as an instantiation of that connection. At any particular time, there > may be any number of state objects corresponding to a particular > connection. Often there is one representing an ISAKMP SA and another > representing an IPsec SA.</para> > > <para><emphasis remap="B">KLIPS</emphasis> hooks into the routing code > in a LINUX kernel. Traffic to be processed by an IPsec SA must be > directed through <emphasis remap="B">KLIPS</emphasis> by routing > commands. Furthermore, the processing to be done is specified by > <emphasis remap="I">ipsec eroute(8)</emphasis> commands. <emphasis remap="B">pluto</emphasis> takes the responsibility of managing both of > these special kinds of routes.</para> > > <para><emphasis remap="B">NETKEY</emphasis> requires no special > routing.</para> > > <para>Each connection may be routed, and must be while it has an IPsec > SA. The connection specifies the characteristics of the route: the > interface on this machine, the âgatewayâ (the nexthop), and the peer's > client subnet. Two connections may not be simultaneously routed if they > are for the same peer's client subnet but use different interfaces or > gateways (<emphasis remap="B">pluto</emphasis>'s logic does not reflect > any advanced routing capabilities).</para> > > <para>On KLIPS, each eroute is associated with the state object for an > IPsec SA because it has the particular characteristics of the SA. Two > eroutes conflict if they specify the identical local and remote clients > (unlike for routes, the local clients are taken into account).</para> > > <para>When <emphasis remap="B">pluto</emphasis> needs to install a route > for a connection, it must make sure that no conflicting route is in use. > If another connection has a conflicting route, that route will be taken > down, as long as there is no IPsec SA instantiating that connection. If > there is such an IPsec SA, the attempt to install a route will > fail.</para> > > <para>There is an exception. If <emphasis remap="B">pluto</emphasis>, as > Responder, needs to install a route to a fixed client subnet for a > connection, and there is already a conflicting route, then the SAs using > the route are deleted to make room for the new SAs. The rationale is > that the new connection is probably more current. The need for this > usually is a product of Road Warrior connections (these are explained > later; they cannot be used to initiate).</para> > > <para>When <emphasis remap="B">pluto</emphasis> needs to install an > eroute for an IPsec SA (for a state object), first the state object's > connection must be routed (if this cannot be done, the eroute and SA > will not be installed). If a conflicting eroute is already in place for > another connection, the eroute and SA will not be installed (but note > that the routing exception mentioned above may have already deleted > potentially conflicting SAs). If another IPsec SA for the same > connection already has an eroute, all its outgoing traffic is taken over > by the new eroute. The incoming traffic will still be processed. This > characteristic is exploited during rekeying.</para> > > <para>All of these routing characteristics are expected change when > <emphasis remap="B">KLIPS</emphasis> and <emphasis remap="B">NETKEY</emphasis> merge into a single new stack.</para> > </refsect2> > > <refsect2 id="using_whack"> > <title>Using Whack</title> > > <para><emphasis remap="B">whack</emphasis> is used to command a running > <emphasis remap="B">pluto</emphasis>. <emphasis remap="B">whack</emphasis> uses a UNIX domain socket to speak to > <emphasis remap="B">pluto</emphasis> (by default, > <filename>/var/pluto.ctl</filename>).</para> > > <para><emphasis remap="B">whack</emphasis> has an intricate argument > syntax. This syntax allows many different functions to be specified. The > help form shows the usage or version information. The connection form > gives <emphasis remap="B">pluto</emphasis> a description of a potential > connection. The public key form informs <emphasis remap="B">pluto</emphasis> of the RSA public key for a potential peer. > The delete form deletes a connection description and all SAs > corresponding to it. The listen form tells <emphasis remap="B">pluto</emphasis> to start or stop listening on the public > interfaces for IKE requests from peers. The route form tells <emphasis remap="B">pluto</emphasis> to set up routing for a connection; the > unroute form undoes this. The initiate form tells <emphasis remap="B">pluto</emphasis> to negotiate an SA corresponding to a > connection. The terminate form tells <emphasis remap="B">pluto</emphasis> to remove all SAs corresponding to a > connection, including those being negotiated. The status form displays > the <emphasis remap="B">pluto</emphasis>'s internal state. The debug > form tells <emphasis remap="B">pluto</emphasis> to change the selection > of debugging output âon the flyâ. The shutdown form tells <emphasis remap="B">pluto</emphasis> to shut down, deleting all SAs.</para> > > <para>The crash option asks pluto to consider a particularly target IP > to have crashed, and to attempt to restart all connections with that IP > address as a gateway. In general, you should use Dead Peer Detection to > detect this kind of situation automatically, but this is not always > possible.</para> > > <para>Most options are specific to one of the forms, and will be > described with that form. There are three options that apply to all > forms.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--ctlbase</option> <emphasis remap="I">path</emphasis></term> > > <listitem> > <para><emphasis remap="I">path</emphasis>.ctl is used as the UNIX > domain socket for talking to <emphasis remap="B">pluto</emphasis>. > This option facilitates debugging.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--optionsfrom</option> <emphasis remap="I">filename</emphasis></term> > > <listitem> > <para>adds the contents of the file to the argument list.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--label</option> <emphasis remap="I">string</emphasis></term> > > <listitem> > <para>adds the string to all error messages generated by <emphasis remap="B">whack</emphasis>.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The help form of <emphasis remap="B">whack</emphasis> is > self-explanatory.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--help</option></term> > > <listitem> > <para>display the usage message.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--version</option></term> > > <listitem> > <para>display the version of <emphasis remap="B">whack</emphasis>.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The connection form describes a potential connection to <emphasis remap="B">pluto</emphasis>. <emphasis remap="B">pluto</emphasis> needs > to know what connections can and should be negotiated. When <emphasis remap="B">pluto</emphasis> is the initiator, it needs to know what to > propose. When <emphasis remap="B">pluto</emphasis> is the responder, it > needs to know enough to decide whether is is willing to set up the > proposed connection.</para> > > <para>The description of a potential connection can specify a large > number of details. Each connection has a unique name. This name will > appear in a updown shell command, so it should not contain punctuation > that would make the command ill-formed.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>sets the name of the connection</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The topology of a connection is symmetric, so to save space here > is half a picture:</para> > > <para> client_subnet<-->host:ikeport<-->nexthop<---</para> > > <para>A similar trick is used in the flags. The same flag names are used > for both ends. Those before the <option>--to</option> flag describe the > left side and those afterwards describe the right side. When <emphasis remap="B">pluto</emphasis> attempts to use the connection, it decides > whether it is the left side or the right side of the connection, based > on the IP numbers of its interfaces.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--id</option> <emphasis remap="I">id</emphasis></term> > > <listitem> > <para>the identity of the end. Currently, this can be an IP > address (specified as dotted quad or as a Fully Qualified Domain > Name, which will be resolved immediately) or as a Fully Qualified > Domain Name itself (prefixed by â@â to signify that it should not > be resolved), or as user@FQDN, or an X.509 DN, or as the magic > value <emphasis remap="B">%myid</emphasis>. <emphasis remap="B">Pluto</emphasis> only authenticates the identity, and > does not use it for addressing, so, for example, an IP address > need not be the one to which packets are to be sent. If the option > is absent, the identity defaults to the IP address specified by > <option>--host</option>. <emphasis remap="B">%myid</emphasis> > allows the identity to be separately specified (by the <emphasis remap="B">pluto</emphasis> or <emphasis remap="B">whack</emphasis> > option <option>--myid</option> or by the <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> <emphasis remap="B">config setup</emphasis> > parameter <emphasis remap="P->B">myid</emphasis>). Otherwise, > <emphasis remap="B">pluto</emphasis> tries to guess what <emphasis remap="B">%myid</emphasis> should stand for: the IP address of > <emphasis remap="B">%defaultroute</emphasis>, if it is supported > by a suitable TXT record in the reverse domain for that IP > address, or the system's hostname, if it is supported by a > suitable TXT record in its forward domain.</para> > > <!-- The identity is transmitted in the IKE protocol, and is what is authenticated. --> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--host</option> <emphasis remap="I">ip-address</emphasis></term> > > <term><option>--host</option> <emphasis remap="B">%any</emphasis></term> > > <term><option>--host</option> <emphasis remap="B">%opportunistic</emphasis></term> > > <listitem> > <para>the IP address of the end (generally the public interface). > If <emphasis remap="B">pluto</emphasis> is to act as a responder > for IKE negotiations initiated from unknown IP addresses (the > âRoad Warriorâ case), the IP address should be specified as > <emphasis remap="B">%any</emphasis> (currently, the obsolete > notation <literal>0.0.0.0</literal> is also accepted for this). If > <emphasis remap="B">pluto</emphasis> is to opportunistically > initiate the connection, use <emphasis remap="B">%opportunistic</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--cert</option> <emphasis remap="I">filename</emphasis></term> > > <listitem> > <para>The filename of the X.509 certificate. This must be the > public key certificate only, and cannot be the PKCS#12 certificate > file. See <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> on how to extrac this from the PKCS#12 > file.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ca</option> <emphasis remap="I">distinguished > name</emphasis></term> > > <listitem> > <para>the X.509 Certificate Authority's Distinguished Name (DN) > used as trust anchor for this connection. This is the CA > certificate that signed the host certificate, as well as the > certificate of the incoming client.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--groups</option> <emphasis remap="I">access > control groups</emphasis></term> > > <listitem> > <para>the access control groups used.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--sendcert</option> <emphasis remap="I">yes|forced|always|ifasked|no|never</emphasis></term> > > <listitem> > <para>Wether or not to send our X.509 certificate credentials. > This could potentially give an attacker too much information about > which identities are allowed to connect to this host. The default > is to use <emphasis remap="B">ifasked</emphasis> when we are a > Responder, and to use <emphasis remap="B">yes</emphasis> (which is > the same as <emphasis remap="B">forced</emphasis> and <emphasis remap="B">always</emphasis> if we are an Initiator. The values > <emphasis remap="B">no</emphasis> and <emphasis remap="B">never</emphasis> are equivalent. NOTE: "forced" does not > seem to be actually implemented - do not use it.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--certtype</option> <emphasis remap="I">number</emphasis></term> > > <listitem> > <para>The X.509 certificate type number.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ikeport</option> <emphasis remap="I">port-number</emphasis></term> > > <listitem> > <para>the UDP port that IKE listens to on that host. The default > is 500. (<emphasis remap="B">pluto</emphasis> on this machine uses > the port specified by its own command line argument, so this only > affects where <emphasis remap="B">pluto</emphasis> sends > messages.)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--nexthop</option> <emphasis remap="I">ip-address</emphasis></term> > > <listitem> > <para>where to route packets for the peer's client (presumably for > the peer too, but it will not be used for this). When <emphasis remap="B">pluto</emphasis> installs an IPsec SA, it issues a route > command. It uses the nexthop as the gateway. The default is the > peer's IP address (this can be explicitly written as <emphasis remap="B">%direct</emphasis>; the obsolete notation > <literal>0.0.0.0</literal> is accepted). This option is necessary > if <emphasis remap="B">pluto</emphasis>'s host's interface used > for sending packets to the peer is neither point-to-point nor > directly connected to the peer.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--client</option> <emphasis remap="I">subnet</emphasis></term> > > <listitem> > <para>the subnet for which the IPsec traffic will be destined. If > not specified, the host will be the client. The subnet can be > specified in any of the forms supported by <citerefentry> > <refentrytitle>ipsec_atosubnet</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>. The general form is <emphasis remap="I">address</emphasis>/<emphasis remap="I">mask</emphasis>. > The <emphasis remap="I">address</emphasis> can be either a domain > name or four decimal numbers (specifying octets) separated by > dots. The most convenient form of the <emphasis remap="I">mask</emphasis> is a decimal integer, specifying the > number of leading one bits in the mask. So, for example, > 10.0.0.0/8 would specify the class A network âNet 10â.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--clientwithin</option> <emphasis remap="I">subnet</emphasis></term> > > <listitem> > <para>This option is obsolete and will be removed. Do not use this > option anymore.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--clientprotoport</option> <emphasis remap="I">protocol/port</emphasis></term> > > <listitem> > <para>specify the Port Selectors (filters) to be used on this > connection. The general form is <emphasis remap="I">protocol</emphasis>/<emphasis remap="I">port</emphasis>. > This is most commonly used to limit the connection to L2TP traffic > only by specifying a value of <emphasis remap="I">17/1701</emphasis> for UDP (protocol 17) and port 1701. > The notation <emphasis remap="I">17/%any</emphasis> can be used to > allow all UDP traffic and is needed for L2TP connections with > Windows XP machines before Service Pack 2.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--srcip</option> <emphasis remap="I">ip-address</emphasis></term> > > <listitem> > <para>the IP address for this host to use when transmitting a > packet to the remote IPsec gateway itself. This option is used to > make the gateway itself use its internal IP, which is part of the > <option>--client subnet</option>. Otherwise it will use its > nearest IP address, which is its public IP address, which is not > part of the subnet-subnet IPsec tunnel, and would therefor not get > encrypted.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthserver</option></term> > > <listitem> > <para>this end is an xauthserver. It will lookup the xauth user > name and password and verify this before allowing the connection > to get established.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthclient</option></term> > > <listitem> > <para>this end is an xauthclient. To bring this connection up with > the <option>--initiate</option> also requires the client to > specify <option>--xauthuser username</option> and > <option>--xauthpass password </option></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthuser</option></term> > > <listitem> > <para>The username for the xauth authentication.This option is > normally passed along by <citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> when an xauth connection is started using > <emphasis remap="I">ipsec auto --up conn</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthpass</option></term> > > <listitem> > <para>The password for the xauth authentication. This option is > normally passed along by <citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> when an xauth connection is started using > <emphasis remap="I">ipsec auto --up conn</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgserver</option></term> > > <listitem> > <para>this end is an Mode Config server</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgclient</option></term> > > <listitem> > <para>this end is an Mode Config client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgdns1</option></term> > > <listitem> > <para>The IP address of the first DNS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgdns2</option></term> > > <listitem> > <para>The IP address of the second DNS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgwins1</option></term> > > <listitem> > <para>The IP address of the first WINS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgwins2</option></term> > > <listitem> > <para>The IP address of the second WINS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dnskeyondemand</option></term> > > <listitem> > <para>specifies that when an RSA public key is needed to > authenticate this host, and it isn't already known, fetch it from > DNS.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--updown</option> <emphasis remap="I">updown</emphasis></term> > > <listitem> > <para>specifies an external shell command to be run whenever > <emphasis remap="B">pluto</emphasis> brings up or down a > connection. The script is used to build a shell command, so it may > contain positional parameters, but ought not to have punctuation > that would cause the resulting command to be ill-formed. The > default is <emphasis remap="I">ipsec _updown</emphasis>. Pluto > passes a dozen environment variables to the script about the > connection involved.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--to</option></term> > > <listitem> > <para>separates the specification of the left and right ends of > the connection. Pluto tries to decide wether it is <emphasis remap="I">left</emphasis> or <emphasis remap="I">right</emphasis> > based on the information provided on both sides of this > option.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The potential connection description also specifies > characteristics of rekeying and security.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--psk</option></term> > > <listitem> > <para>Propose and allow preshared secret authentication for IKE > peers. This authentication requires that each side use the same > secret. May be combined with <option>--rsasig</option>; at least > one must be specified.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--rsasig</option></term> > > <listitem> > <para>Propose and allow RSA signatures for authentication of IKE > peers. This authentication requires that each side have have a > private key of its own and know the public key of its peer. May be > combined with <option>--psk</option>; at least one must be > specified.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--encrypt</option></term> > > <listitem> > <para>All proposed or accepted IPsec SAs will include non-null > ESP. The actual choices of transforms are wired into <emphasis remap="B">pluto</emphasis>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--authenticate</option></term> > > <listitem> > <para>All proposed IPsec SAs will include AH. All accepted IPsec > SAs will include AH or ESP with authentication. The actual choices > of transforms are wired into <emphasis remap="B">pluto</emphasis>. > Note that this has nothing to do with IKE authentication.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--compress</option></term> > > <listitem> > <para>All proposed IPsec SAs will include IPCOMP (compression). > This will be ignored if KLIPS is not configured with IPCOMP > support.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--tunnel</option></term> > > <listitem> > <para>the IPsec SA should use tunneling. Implicit if the SA is for > clients. Must only be used with <option>--authenticate</option> or > <option>--encrypt</option>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ipv4</option></term> > > <listitem> > <para>The host addresses will be interpreted as IPv4 addresses. > This is the default. Note that for a connection, all host > addresses must be of the same Address Family (IPv4 and IPv6 use > different Address Families).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ipv6</option></term> > > <listitem> > <para>The host addresses (including nexthop) will be interpreted > as IPv6 addresses. Note that for a connection, all host addresses > must be of the same Address Family (IPv4 and IPv6 use different > Address Families).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--tunnelipv4</option></term> > > <listitem> > <para>The client addresses will be interpreted as IPv4 addresses. > The default is to match what the host will be. This does not imply > <option>--tunnel</option> so the flag can be safely used when no > tunnel is actually specified. Note that for a connection, all > tunnel addresses must be of the same Address Family.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--tunnelipv6</option></term> > > <listitem> > <para>The client addresses will be interpreted as IPv6 addresses. > The default is to match what the host will be. This does not imply > <option>--tunnel</option> so the flag can be safely used when no > tunnel is actually specified. Note that for a connection, all > tunnel addresses must be of the same Address Family.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pfs</option></term> > > <listitem> > <para>There should be Perfect Forward Secrecy - new keying > material will be generated for each IPsec SA rather than being > derived from the ISAKMP SA keying material. Since the group to be > used cannot be negotiated (a dubious feature of the standard), > <emphasis remap="B">pluto</emphasis> will propose the same group > that was used during Phase 1. We don't implement a stronger form > of PFS which would require that the ISAKMP SA be deleted after the > IPSEC SA is negotiated.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pfsgroup</option> <emphasis remap="I">modp-group</emphasis></term> > > <listitem> > <para>Sets the Diffie-Hellman group used. Currently the following > values are supported: <emphasis remap="B">modp1024</emphasis> > (DHgroup 2), <emphasis remap="B">modp1536</emphasis> (DHgroup 5), > <emphasis remap="B">modp2048</emphasis> (DHgroup 14), <emphasis remap="B">modp3072</emphasis> (DHgroup 15), <emphasis remap="B">modp4096</emphasis> (DHgroup 16), <emphasis remap="B">modp6144</emphasis> (DHgroup 17), and <emphasis remap="B">modp8192</emphasis> (DHgroup 18). It is possible to > support the weak and broken <emphasis remap="B">modp768</emphasis> > (DHgroup 1), but this requires a manual recompile and is strongly > discouraged.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--disablearrivalcheck</option></term> > > <listitem> > <para>If the connection is a tunnel, allow packets arriving > through the tunnel to have any source and destination > addresses.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--esp</option> <emphasis remap="I">esp-algos</emphasis></term> > > <listitem> > <para>ESP encryption/authentication algorithm to be used for the > connection (phase2 aka IPsec SA). The options must be suitable as > a value of <citerefentry> > <refentrytitle>ipsec_spi</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>. See <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> for a detailed description of the algorithm > format.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--aggrmode</option></term> > > <listitem> > <para>This tunnel is using aggressive mode ISAKMP negotiation. The > default is main mode. Aggressive mode is less secure than main > mode as it reveals your identity to an eavesdropper, but is needed > to support road warriors using PSK keys or to interoperate with > other buggy implementations insisting on using aggressive > mode.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgpull</option></term> > > <listitem> > <para>Pull the Mode Config network information from the > peer.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dpddelay</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>Set the delay (in seconds) between Dead Peer Dectection (RFC > 3706) keepalives (R_U_THERE, R_U_THERE_ACK) that are sent for this > connection (default 30 seconds).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--timeout</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>Set the length of time (in seconds) we will idle without > hearing either an R_U_THERE poll from our peer, or an > R_U_THERE_ACK reply. After this period has elapsed with no > response and no traffic, we will declare the peer dead, and remove > the SA (default 120 seconds).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dpdaction</option> <emphasis remap="I">action</emphasis></term> > > <listitem> > <para>When a DPD enabled peer is declared dead, what action should > be taken. <emphasis remap="B">hold</emphasis>(default) means the > eroute will be put into <emphasis remap="I">%hold</emphasis> > status, while <emphasis remap="B">clear</emphasis>means the eroute > and SA with both be cleared. Clear is really only usefull on the > server of a Road Warrior config. The action <emphasis remap="B">restart</emphasis> is used on tunnels that need to be > permanently up, and have static IP addresses.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--forceencaps</option></term> > > <listitem> > <para>In some cases, for example when ESP packets are filtered or > when a broken IPsec peer does not properly recognise NAT, it can > be useful to force RFC-3948 encapsulation using this option. It > causes pluto lie and tell the remote peer that RFC-3948 > encapsulation (ESP in UDP port 4500 packets) is required. For this > option to have any effect, pluto must have been started with the > <option>--nat_traversal</option> option.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>If none of the <option>--encrypt</option>, > <option>--authenticate</option>, <option>--compress</option>, or > <option>--pfs</option> flags is given, the initiating the connection > will only build an ISAKMP SA. For such a connection, client subnets have > no meaning and must not be specified.</para> > > <para>Apart from initiating directly using the > <option>--initiate</option> option, a tunnel can be loaded with a > different policy</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--initiateontraffic</option></term> > > <listitem> > <para>Only initiate the connection when we have traffic to send > over the connection</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pass</option></term> > > <listitem> > <para>Allow <emphasis remap="B">unencrypted</emphasis> traffic to > flow until the tunnel is initiated.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--drop</option></term> > > <listitem> > <para>Drop unencrypted traffic silently.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--reject</option></term> > > <listitem> > <para>Drop unencrypted traffic silently, but send an ICMP message > notifying the other end.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>These options need to be documented</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--failnone</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--failpass</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--faildrop</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--failreject</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > </variablelist> > > <para><emphasis remap="B">pluto</emphasis> supports various X.509 > Certificate related options.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--utc</option></term> > > <listitem> > <para>display all times in UTC.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listall</option></term> > > <listitem> > <para>lists all of the X.509 information known to pluto.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listpubkeys</option></term> > > <listitem> > <para>list all the public keys that have been successfully > loaded.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcerts</option></term> > > <listitem> > <para>list all the X.509 certificates that are currently > loaded.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcacerts</option></term> > > <listitem> > <para>list all the X.509 Certificate Agency (CA) certificates that > are currently loaded.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listacerts</option></term> > > <listitem> > <para>list all the X.509 Attribute certificates that are currently > loaded</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listaacerts</option></term> > > <listitem> > <para/> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ocspcerts</option></term> > > <listitem> > <para>list all of the X.509 certificates obtained via the > <emphasis remap="I">Online Certificate Store Protocol</emphasis> > (OCSP)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listgroups</option></term> > > <listitem> > <para/> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcrls</option></term> > > <listitem> > <para>list all the loaded <emphasis remap="I">Certificate > Revocation Lists</emphasis> (CRLs)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcards</option></term> > > <listitem> > <para>list all the smartcard and USB token devices.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The corresponding options <option>--rereadsecrets</option>, > <option>--rereadall</option>, <option>--rereadcacerts</option>, > <option>--rereadacerts</option>, <option>--rereadaacerts</option>, > <option>--rereadocspcerts</option> <option>--rereadcrls</option>, and > <option>--purgeocsp</option>, options reread this information from their > respective sources, and purge all the online obtained information. The > option <option>--listevents</option> lists all pending CRL fetch > commands.</para> > > <para>More work is needed to allow for flexible policies. Currently > policy is hardwired in the source file spdb.c. The ISAKMP SAs may use > Oakley groups MODP1024 and MODP1536; AES or 3DES encryption; SHA1-96 and > MD5-96 authentication. The IPsec SAs may use AES or 3DES and MD5-96 or > SHA1-96 for ESP, or just MD5-96 or SHA1-96 for AH. IPCOMP Compression is > always Deflate.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--ikelifetime</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>how long <emphasis remap="B">pluto</emphasis> will propose > that an ISAKMP SA be allowed to live. The default is 3600 (one > hour) and the maximum is 86400 (1 day). This option will not > affect what is accepted. <emphasis remap="B">pluto</emphasis> will > reject proposals that exceed the maximum.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ipseclifetime</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>how long <emphasis remap="B">pluto</emphasis> will propose > that an IPsec SA be allowed to live. The default is 28800 (eight > hours) and the maximum is 86400 (one day). This option will not > affect what is accepted. <emphasis remap="B">pluto</emphasis> will > reject proposals that exceed the maximum.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--rekeymargin</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>how long before an SA's expiration should <emphasis remap="B">pluto</emphasis> try to negotiate a replacement SA. This > will only happen if <emphasis remap="B">pluto</emphasis> was the > initiator. The default is 540 (nine minutes).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--rekeyfuzz</option> <emphasis remap="I">percentage</emphasis></term> > > <listitem> > <para>maximum size of random component to add to rekeymargin, > expressed as a percentage of rekeymargin. <emphasis remap="B">pluto</emphasis> will select a delay uniformly > distributed within this range. By default, the percentage will be > 100. If greater determinism is desired, specify 0. It may be > appropriate for the percentage to be much larger than 100.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--keyingtries</option> <emphasis remap="I">count</emphasis></term> > > <listitem> > <para>how many times <emphasis remap="B">pluto</emphasis> should > try to negotiate an SA, either for the first time or for rekeying. > A value of 0 is interpreted as a very large number: never give up. > The default is three.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dontrekey</option></term> > > <listitem> > <para>A misnomer. Only rekey a connection if we were the Initiator > and there was recent traffic on the existing connection. This > applies to Phase 1 and Phase 2. This is currently the only > automatic way for a connection to terminate. It may be useful with > Road Warrior or Opportunistic connections. <!-- .br --> Since SA > lifetime negotiation is take-it-or-leave it, a Responder normally > uses the shorter of the negotiated or the configured lifetime. > This only works because if the lifetime is shorter than > negotiated, the Responder will rekey in time so that everything > works. This interacts badly with <option>--dontrekey</option>. In > this case, the Responder will end up rekeying to rectify a > shortfall in an IPsec SA lifetime; for an ISAKMP SA, the Responder > will accept the negotiated lifetime.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--delete</option></term> > > <listitem> > <para>when used in the connection form, it causes any previous > connection with this name to be deleted before this one is added. > Unlike a normal delete, no diagnostic is produced if there was no > previous connection to delete. Any routing in place for the > connection is undone.</para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--delete</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>The delete form deletes a named connection description and > any SAs established or negotiations initiated using this > connection. Any routing in place for the connection is > undone.</para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--deletestate</option> <emphasis remap="I">state-number</emphasis></term> > > <listitem> > <para>The deletestate form deletes the state object with the > specified serial number. This is useful for selectively deleting > instances of connections.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The route form of the <emphasis remap="B">whack</emphasis> command > tells <emphasis remap="B">pluto</emphasis> to set up routing for a > connection. Although like a traditional route, it uses an ipsec device > as a virtual interface. Once routing is set up, no packets will be sent > âin the clearâ to the peer's client specified in the connection. A TRAP > shunt eroute will be installed; if outbound traffic is caught, Pluto > will initiate the connection. An explicit <emphasis remap="B">whack</emphasis> route is not always needed: if it hasn't been > done when an IPsec SA is being installed, one will be automatically > attempted.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--route</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>When a routing is attempted for a connection, there must not > already be a routing for a different connection with the same > subnet but different interface or destination, or if there is, it > must not be being used by an IPsec SA. Otherwise the attempt will > fail.</para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--unroute</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>The unroute form of the <emphasis remap="B">whack</emphasis> > command tells <emphasis remap="B">pluto</emphasis> to undo a > routing. <emphasis remap="B">pluto</emphasis> will refuse if an > IPsec SA is using the connection. If another connection is sharing > the same routing, it will be left in place. Without a routing, > packets will be sent without encryption or authentication.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The initiate form tells <emphasis remap="B">pluto</emphasis> to > initiate a negotiation with another <emphasis remap="B">pluto</emphasis> > (or other IKE daemon) according to the named connection. Initiation > requires a route that <option>--route</option> would provide; if none is > in place at the time an IPsec SA is being installed, <emphasis remap="B">pluto</emphasis> attempts to set one up.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--initiate</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <term><option>--asynchronous</option></term> > > <listitem> > <para>The initiate form of the <emphasis remap="B">whack</emphasis> command will relay back from <emphasis remap="B">pluto</emphasis> status information via the UNIX domain > socket (unless --asynchronous is specified). The status > information is meant to look a bit like that from <emphasis remap="B">FTP</emphasis>. Currently <emphasis remap="B">whack</emphasis> simply copies this to stderr. When the > request is finished (eg. the SAs are established or <emphasis remap="B">pluto</emphasis> gives up), <emphasis remap="B">pluto</emphasis> closes the channel, causing <emphasis remap="B">whack</emphasis> to terminate.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The opportunistic initiate form is mainly used for > debugging.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--tunnelipv4</option></term> > > <term><option>--tunnelipv6</option></term> > > <term><option>--oppohere</option> <emphasis remap="I">ip-address</emphasis></term> > > <term><option>--oppothere</option> <emphasis remap="I">ip-address</emphasis></term> > > <listitem> > <para>This will cause <emphasis remap="B">pluto</emphasis> to > attempt to opportunistically initiate a connection from here to > the there, even if a previous attempt had been made. The whack log > will show the progress of this attempt.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>Ending an connection</para> > > <variablelist remap="tp"> > <varlistentry> > <term><option>--terminate</option></term> > > <term><option>--name</option> <emphasis remap="i">connection-name</emphasis></term> > > <listitem> > <para>the terminate form tells <emphasis remap="b">pluto</emphasis> to delete any sas that use the > specified connection and to stop any negotiations in process. it > does not prevent new negotiations from starting (the delete form > has this effect).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--crash</option> <emphasis remap="i">ip-address</emphasis></term> > > <listitem> > <para>If the remote peer has crashed, and therefor did not notify > us, we keep sending encrypted traffic, and rejecting all plaintext > (non-IKE) traffic from that remote peer. The > <option>--crash</option> brings our end down as well for all the > known connections to the specified <emphasis remap="i">ip-address</emphasis></para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="tp"> > <varlistentry> > <term><option>--whackrecord</option><emphasis remap="i">filename</emphasis></term> > > <term><option>--whackstoprecord</option></term> > > <listitem> > <para>this causes <emphasis remap="b">pluto</emphasis>to open the > given filename for write, and record each of the messages received > from whack or addconn. This continues until the whackstoprecord > option is used. This option may not be combined with any other > command. The start/stop commands are not recorded themselves. > These files are usually used to create input files for unit tests, > particularly for complex setups where policies may in fact > overlap. </para> > > <para>The format of the file consists of a line starting with > #!pluto-whack and the date that the file was started, as well as > the hostname, and a linefeed. What follows are binary format > records consisting of a 32-bit record length in bytes, (including > the length record itself), a 64-bit timestamp, and then the > literal contents of the whack message that was received. All > integers are in host format. In order to unambigously determine > the host order, the first record is an empty record that contains > only the current WHACK_MAGIC value. This record is 16 bytes > long.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="i">ip-address</emphasis></term> > > <listitem> > <para>If the remote peer has crashed, and therefor did not notify > us, we keep sending encrypted traffic, and rejecting all plaintext > (non-IKE) traffic from that remote peer. The > <option>--crash</option> brings our end down as well for all the > known connections to the specified <emphasis remap="i">ip-address</emphasis></para> > </listitem> > </varlistentry> > </variablelist> > > <para>The public key for informs <emphasis remap="B">pluto</emphasis> of > the RSA public key for a potential peer. Private keys must be kept > secret, so they are kept in <citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--keyid </option><replaceable>id</replaceable></term> > > <listitem> > <para>specififies the identity of the peer for which a public key > should be used. Its form is identical to the identity in the > connection. If no public key is specified, <emphasis remap="B">pluto</emphasis> attempts to find KEY records from DNS > for the id (if a FQDN) or through reverse lookup (if an IP > address). Note that there several interesting ways in which this > is not secure.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--addkey</option></term> > > <listitem> > <para>specifies that the new key is added to the collection; > otherwise the new key replaces any old ones.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pubkeyrsa </option><replaceable>key</replaceable></term> > > <listitem> > <para>specifies the value of the RSA public key. It is a sequence > of bytes as described in RFC 2537 âRSA/MD5 KEYs and SIGs in the > Domain Name System (DNS)â. It is denoted in a way suitable for > <citerefentry> > <refentrytitle>ipsec_ttodata</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>. For example, a base 64 numeral starts with > 0s.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The listen form tells <emphasis remap="B">pluto</emphasis> to > start listening for IKE requests on its public interfaces. To avoid race > conditions, it is normal to load the appropriate connections into > <emphasis remap="B">pluto</emphasis> before allowing it to listen. If > <emphasis remap="B">pluto</emphasis> isn't listening, it is pointless to > initiate negotiations, so it will refuse requests to do so. Whenever the > listen form is used, <emphasis remap="B">pluto</emphasis> looks for > public interfaces and will notice when new ones have been added and when > old ones have been removed. This is also the trigger for <emphasis remap="B">pluto</emphasis> to read the <emphasis remap="I">ipsec.secrets</emphasis> file. So listen may useful more than > once.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--listen</option></term> > > <listitem> > <para>start listening for IKE traffic on public interfaces.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--unlisten</option></term> > > <listitem> > <para>stop listening for IKE traffic on public interfaces.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The status form will display information about the internal state > of <emphasis remap="B">pluto</emphasis>: information about each > potential connection, about each state object, and about each shunt that > <emphasis remap="B">pluto</emphasis> is managing without an associated > connection.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--status</option></term> > > <listitem> > <para/> > > <!-- FIXME: blank list item --> > </listitem> > </varlistentry> > </variablelist> > > <para>The shutdown form is the proper way to shut down <emphasis remap="B">pluto</emphasis>. It will tear down the SAs on this machine > that <emphasis remap="B">pluto</emphasis> has negotiated. It does not > inform its peers, so the SAs on their machines remain.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--shutdown</option></term> > > <listitem> > <para/> > > <!-- FIXME: blank list item --> > </listitem> > </varlistentry> > </variablelist> > </refsect2> > > <refsect2 id="examples"> > <title>Examples</title> > > <para>It would be normal to start <emphasis remap="B">pluto</emphasis> > in one of the system initialization scripts. It needs to be run by the > superuser. Generally, no arguments are needed. To run in manually, the > superuser can simply type</para> > > <para> ipsec pluto</para> > > <para>The command will immediately return, but a <emphasis remap="B">pluto</emphasis> process will be left running, waiting for > requests from <emphasis remap="B">whack</emphasis> or a peer.</para> > > <para>Using <emphasis remap="B">whack</emphasis>, several potential > connections would be described:</para> > > <!-- .na --> > > <para> ipsec whack --name silly > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > --ipseclifetime 800 --keyingtries 3</para> > > <!-- .ad --> > > <para>Since this silly connection description specifies neither > encryption, authentication, nor tunneling, it could only be used to > establish an ISAKMP SA.</para> > > <!-- .na --> > > <para> ipsec whack --name secret > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > --client 10.0.2.0/24 --encrypt</para> > > <!-- .ad --> > > <para>This is something that must be done on both sides. If the other > side is <emphasis remap="B">pluto</emphasis>, the same <emphasis remap="B">whack</emphasis> command could be used on it (the command > syntax is designed to not distinguish which end is ours).</para> > > <para>Now that the connections are specified, <emphasis remap="B">pluto</emphasis> is ready to handle requests and replies via > the public interfaces. We must tell it to discover those interfaces and > start accepting messages from peers:</para> > > <para> ipsec whack --listen</para> > > <para>If we don't immediately wish to bring up a secure connection > between the two clients, we might wish to prevent insecure traffic. The > routing form asks <emphasis remap="B">pluto</emphasis> to cause the > packets sent from our client to the peer's client to be routed through > the ipsec0 device; if there is no SA, they will be discarded:</para> > > <para> ipsec whack --route secret</para> > > <para>Finally, we are ready to get <emphasis remap="B">pluto</emphasis> > to initiate negotiation for an IPsec SA (and implicitly, an ISAKMP > SA):</para> > > <para> ipsec whack > --initiate --name secret</para> > > <para>A small log of interesting events will appear on standard output > (other logging is sent to syslog).</para> > > <para><emphasis remap="B">whack</emphasis> can also be used to terminate > <emphasis remap="B">pluto</emphasis> cleanly, tearing down all SAs that > it has negotiated.</para> > > <para> ipsec whack --shutdown</para> > > <para>Notification of any IPSEC SA deletion, but not ISAKMP SA deletion > is sent to the peer. Unfortunately, such Notification is not reliable. > Furthermore, <emphasis remap="B">pluto</emphasis> itself ignores > Notifications.</para> > </refsect2> > > <refsect2 id="xauth"> > <title>XAUTH</title> > > <para>If <emphasis remap="B">pluto</emphasis> needs additional > authentication, such as defined by the XAUTH specifications, then it may > ask <emphasis remap="B">whack</emphasis> to prompt the operator for > username or passwords. Typically, these will be entered interactively. A > GUI that wraps around <emphasis remap="B">whack</emphasis> may look for > the 041 (username) or 040 (password) prompts, and display them to the > user.</para> > > <para>For testing purposes, the options > <option>--xauthuser </option><replaceable>user</replaceable> > <option>--xauthpass </option><replaceable>pass</replaceable> may be > be given prior to the <option>--initiate </option> to provide > responses to the username and password prompts.</para> > </refsect2> > > <refsect2 id="the_updown_command"> > <title>The updown command</title> > > <para>Whenever <emphasis remap="B">pluto</emphasis> brings a connection > up or down, it invokes the updown command. This command is specified > using the <option>--updown</option> option. This allows for customized > control over routing and firewall manipulation.</para> > > <para>The updown is invoked for five different operations. Each of these > operations can be for our client subnet or for our host itself.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><emphasis remap="B">prepare-host</emphasis> or <emphasis remap="B">prepare-client</emphasis></term> > > <listitem> > <para>is run before bringing up a new connection if no other > connection with the same clients is up. Generally, this is useful > for deleting a route that might have been set up before <emphasis remap="B">pluto</emphasis> was run or perhaps by some agent not > known to <emphasis remap="B">pluto</emphasis>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">route-host</emphasis> or <emphasis remap="B">route-client</emphasis></term> > > <listitem> > <para>is run when bringing up a connection for a new peer client > subnet (even if <emphasis remap="B">prepare-host</emphasis> or > <emphasis remap="B">prepare-client</emphasis> was run). The > command should install a suitable route. Routing decisions are > based only on the destination (peer's client) subnet address, > unlike eroutes which discriminate based on source too.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">unroute-host</emphasis> or <emphasis remap="B">unroute-client</emphasis></term> > > <listitem> > <para>is run when bringing down the last connection for a > particular peer client subnet. It should undo what the <emphasis remap="B">route-host</emphasis> or <emphasis remap="B">route-client</emphasis> did.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">up-host</emphasis> or <emphasis remap="B">up-client</emphasis></term> > > <listitem> > <para>is run when bringing up a tunnel eroute with a pair of > client subnets that does not already have a tunnel eroute. This > command should install firewall rules as appropriate. It is > generally a good idea to allow IKE messages (UDP port 500) travel > between the hosts.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">down-host</emphasis> or <emphasis remap="B">down-client</emphasis></term> > > <listitem> > <para>is run when bringing down the eroute for a pair of client > subnets. This command should delete firewall rules as appropriate. > Note that there may remain some inbound IPsec SAs with these > client subnets.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The script is passed a large number of environment variables to > specify what needs to be done.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><emphasis remap="B">PLUTO_VERSION</emphasis></term> > > <listitem> > <para>indicates what version of this interface is being used. This > document describes version 1.1. This is upwardly compatible with > version 1.0.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_VERB</emphasis></term> > > <listitem> > <para>specifies the name of the operation to be performed > (<emphasis remap="B">prepare-host</emphasis>,r <emphasis remap="B">prepare-client</emphasis>, <emphasis remap="B">up-host</emphasis>, <emphasis remap="B">up-client</emphasis>, <emphasis remap="B">down-host</emphasis>, or <emphasis remap="B">down-client</emphasis>). If the address family for > security gateway to security gateway communications is IPv6, then > a suffix of -v6 is added to the verb.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_CONNECTION</emphasis></term> > > <listitem> > <para>is the name of the connection for which we are > routing.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_NEXT_HOP</emphasis></term> > > <listitem> > <para>is the next hop to which packets bound for the peer must be > sent.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_INTERFACE</emphasis></term> > > <listitem> > <para>is the name of the ipsec interface to be used.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_ME</emphasis></term> > > <listitem> > <para>is the IP address of our host.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_CLIENT</emphasis></term> > > <listitem> > <para>is the IP address / count of our client subnet. If the > client is just the host, this will be the host's own IP address / > max (where max is 32 for IPv4 and 128 for IPv6).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_CLIENT_NET</emphasis></term> > > <listitem> > <para>is the IP address of our client net. If the client is just > the host, this will be the host's own IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_CLIENT_MASK</emphasis></term> > > <listitem> > <para>is the mask for our client net. If the client is just the > host, this will be 255.255.255.255.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER</emphasis></term> > > <listitem> > <para>is the IP address of our peer.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CLIENT</emphasis></term> > > <listitem> > <para>is the IP address / count of the peer's client subnet. If > the client is just the peer, this will be the peer's own IP > address / max (where max is 32 for IPv4 and 128 for IPv6).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CLIENT_NET</emphasis></term> > > <listitem> > <para>is the IP address of the peer's client net. If the client is > just the peer, this will be the peer's own IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CLIENT_MASK</emphasis></term> > > <listitem> > <para>is the mask for the peer's client net. If the client is just > the peer, this will be 255.255.255.255.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_PROTOCOL</emphasis></term> > > <listitem> > <para>lists the protocols allowed over this IPsec SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_PROTOCOL</emphasis></term> > > <listitem> > <para>lists the protocols the peer allows over this IPsec > SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_PORT</emphasis></term> > > <listitem> > <para>lists the ports allowed over this IPsec SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_PORT</emphasis></term> > > <listitem> > <para>lists the ports the peer allows over this IPsec SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_ID</emphasis></term> > > <listitem> > <para>lists our id.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_ID</emphasis></term> > > <listitem> > <para>Dlists our peer's id.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CA</emphasis></term> > > <listitem> > <para>lists the peer's CA.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>All output sent by the script to stderr or stdout is logged. The > script should return an exit status of 0 if and only if it > succeeds.</para> > > <para><emphasis remap="B">Pluto</emphasis> waits for the script to > finish and will not do any other processing while it is waiting. The > script may assume that <emphasis remap="B">pluto</emphasis> will not > change anything while the script runs. The script should avoid doing > anything that takes much time and it should not issue any command that > requires processing by <emphasis remap="B">pluto</emphasis>. Either of > these activities could be performed by a background subprocess of the > script.</para> > </refsect2> > > <refsect2 id="rekeying"> > <title>Rekeying</title> > > <para>When an SA that was initiated by <emphasis remap="B">pluto</emphasis> has only a bit of lifetime left, <emphasis remap="B">pluto</emphasis> will initiate the creation of a new SA. This > applies to ISAKMP and IPsec SAs. The rekeying will be initiated when the > SA's remaining lifetime is less than the rekeymargin plus a random > percentage, between 0 and rekeyfuzz, of the rekeymargin.</para> > > <para>Similarly, when an SA that was initiated by the peer has only a > bit of lifetime left, <emphasis remap="B">pluto</emphasis> will try to > initiate the creation of a replacement. To give preference to the > initiator, this rekeying will only be initiated when the SA's remaining > lifetime is half of rekeymargin. If rekeying is done by the responder, > the roles will be reversed: the responder for the old SA will be the > initiator for the replacement. The former initiator might also initiate > rekeying, so there may be redundant SAs created. To avoid these > complications, make sure that rekeymargin is generous.</para> > > <para>One risk of having the former responder initiate is that perhaps > none of its proposals is acceptable to the former initiator (they have > not been used in a successful negotiation). To reduce the chances of > this happening, and to prevent loss of security, the policy settings are > taken from the old SA (this is the case even if the former initiator is > initiating). These may be stricter than those of the connection.</para> > > <para><emphasis remap="B">pluto</emphasis> will not rekey an SA if that > SA is not the most recent of its type (IPsec or ISAKMP) for its > potential connection. This avoids creating redundant SAs.</para> > > <para>The random component in the rekeying time (rekeyfuzz) is intended > to make certain pathological patterns of rekeying unstable. If both > sides decide to rekey at the same time, twice as many SAs as necessary > are created. This could become a stable pattern without the > randomness.</para> > > <para>Another more important case occurs when a security gateway has SAs > with many other security gateways. Each of these connections might need > to be rekeyed at the same time. This would cause a high peek requirement > for resources (network bandwidth, CPU time, entropy for random numbers). > The rekeyfuzz can be used to stagger the rekeying times.</para> > > <para>Once a new set of SAs has been negotiated, <emphasis remap="B">pluto</emphasis> will never send traffic on a superseded one. > Traffic will be accepted on an old SA until it expires.</para> > </refsect2> > > <refsect2 id="selecting_a_connection_when_responding_r"> > <title>Selecting a Connection When Responding: Road Warrior > Support</title> > > <para>When <emphasis remap="B">pluto</emphasis> receives an initial Main > Mode message, it needs to decide which connection this message is for. > It picks based solely on the source and destination IP addresses of the > message. There might be several connections with suitable IP addresses, > in which case one of them is arbitrarily chosen. (The ISAKMP SA proposal > contained in the message could be taken into account, but it is > not.)</para> > > <para>The ISAKMP SA is negotiated before the parties pass further > identifying information, so all ISAKMP SA characteristics specified in > the connection description should be the same for every connection with > the same two host IP addresses. At the moment, the only characteristic > that might differ is authentication method.</para> > > <para>Up to this point, all configuring has presumed that the IP > addresses are known to all parties ahead of time. This will not work > when either end is mobile (or assigned a dynamic IP address for other > reasons). We call this situation âRoad Warriorâ. It is fairly tricky and > has some important limitations, most of which are features of the IKE > protocol.</para> > > <para>Only the initiator may be mobile: the initiator may have an IP > number unknown to the responder. When the responder doesn't recognize > the IP address on the first Main Mode packet, it looks for a connection > with itself as one end and <emphasis remap="B">%any</emphasis> as the > other. If it cannot find one, it refuses to negotiate. If it does find > one, it creates a temporary connection that is a duplicate except with > the <emphasis remap="B">%any</emphasis> replaced by the source IP > address from the packet; if there was no identity specified for the > peer, the new IP address will be used.</para> > > <para>When <emphasis remap="B">pluto</emphasis> is using one of these > temporary connections and needs to find the preshared secret or RSA > private key in <emphasis remap="I">ipsec.secrets</emphasis>, and and the > connection specified no identity for the peer, <emphasis remap="B">%any</emphasis> is used as its identity. After all, the real > IP address was apparently unknown to the configuration, so it is > unreasonable to require that it be used in this table.</para> > > <para>Part way into the Phase 1 (Main Mode) negotiation using one of > these temporary connection descriptions, <emphasis remap="B">pluto</emphasis> will be receive an Identity Payload. At this > point, <emphasis remap="B">pluto</emphasis> checks for a more > appropriate connection, one with an identity for the peer that matches > the payload but which would use the same keys so-far used for > authentication. If it finds one, it will switch to using this better > connection (or a temporary derived from this, if it has <emphasis remap="B">%any</emphasis> for the peer's IP address). It may even turn > out that no connection matches the newly discovered identity, including > the current connection; if so, <emphasis remap="B">pluto</emphasis> > terminates negotiation.</para> > > <para>Unfortunately, if preshared secret authentication is being used, > the Identity Payload is encrypted using this secret, so the secret must > be selected by the responder without knowing this payload. This limits > there to being at most one preshared secret for all Road Warrior systems > connecting to a host. RSA Signature authentications does not require > that the responder know how to select the initiator's public key until > after the initiator's Identity Payload is decoded (using the responder's > private key, so that must be preselected).</para> > > <para>When <emphasis remap="B">pluto</emphasis> is responding to a Quick > Mode negotiation via one of these temporary connection descriptions, it > may well find that the subnets specified by the initiator don't match > those in the temporary connection description. If so, it will look for a > connection with matching subnets, its own host address, a peer address > of <emphasis remap="B">%any</emphasis> and matching identities. If it > finds one, a new temporary connection is derived from this one and used > for the Quick Mode negotiation of IPsec SAs. If it does not find one, > <emphasis remap="B">pluto</emphasis> terminates negotiation.</para> > > <para>Be sure to specify an appropriate nexthop for the responder to > send a message to the initiator: <emphasis remap="B">pluto</emphasis> > has no way of guessing it (if forwarding isn't required, use an explicit > <emphasis remap="B">%direct</emphasis> as the nexthop and the IP address > of the initiator will be filled in; the obsolete notation > <literal>0.0.0.0</literal> is still accepted).</para> > > <para><emphasis remap="B">pluto</emphasis> has no special provision for > the initiator side. The current (possibly dynamic) IP address and > nexthop must be used in defining connections. These must be properly > configured each time the initiator's IP address changes. <emphasis remap="B">pluto</emphasis> has no mechanism to do this > automatically.</para> > > <para>Although we call this Road Warrior Support, it could also be used > to support encrypted connections with anonymous initiators. The > responder's organization could announce the preshared secret that would > be used with unrecognized initiators and let anyone connect. Of course > the initiator's identity would not be authenticated.</para> > > <para>If any Road Warrior connections are supported, <emphasis remap="B">pluto</emphasis> cannot reject an exchange initiated by an > unknown host until it has determined that the secret is not shared or > the signature is invalid. This must await the third Main Mode message > from the initiator. If no Road Warrior connection is supported, the > first message from an unknown source would be rejected. This has > implications for ease of debugging configurations and for denial of > service attacks.</para> > > <para>Although a Road Warrior connection must be initiated by the mobile > side, the other side can and will rekey using the temporary connection > it has created. If the Road Warrior wishes to be able to disconnect, it > is probably wise to set <option>--keyingtries</option> to 1 in the > connection on the non-mobile side to prevent it trying to rekey the > connection. Unfortunately, there is no mechanism to unroute the > connection automatically.</para> > </refsect2> > > <refsect2 id="debugging"> > <title>Debugging</title> > > <para><emphasis remap="B">pluto</emphasis> accepts several optional > arguments, useful mostly for debugging. Except for > <option>--interface</option>, each should appear at most once.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--interface</option> > <replaceable>interfacename</replaceable></term> > > <listitem> > <para>specifies that the named real public network interface > should be considered. The interface name specified should not be > <command>ipsec</command><emphasis remap="I">N</emphasis>. If the > option doesn't appear, all interfaces are considered. To specify > several interfaces, use the option once for each. One use of this > option is to specify which interface should be used when two or > more share the same IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ikeport</option> > <replaceable>port-number</replaceable></term> > > <listitem> > <para>changes the UDP port that <emphasis remap="B">pluto</emphasis> will use (default, specified by IANA: > 500)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ctlbase</option> > <replaceable>path</replaceable></term> > > <listitem> > <para>basename for control files. <emphasis remap="I">path</emphasis>.ctl is the socket through which > <emphasis remap="B">whack</emphasis> communicates with <emphasis remap="B">pluto</emphasis>. <emphasis remap="I">path</emphasis>.pid is the lockfile to prevent multiple > <emphasis remap="B">pluto</emphasis> instances. The default is > <filename>/var/run/pluto/pluto</filename>).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--secretsfile</option> > <replaceable>file</replaceable></term> > > <listitem> > <para>specifies the file for authentication secrets (default: > <filename>/etc/ipsec.secrets</filename>). This name is subject to > âglobbingâ as in <citerefentry> > <refentrytitle>sh</refentrytitle> > > <manvolnum>1</manvolnum> > </citerefentry>, so every file with a matching name is > processed. Quoting is generally needed to prevent the shell from > doing the globbing.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--adns</option> <replaceable>path to > adns</replaceable></term> > > <term><option>--lwdnsq</option> <replaceable>path to > lwdnsq</replaceable></term> > > <listitem> > <para>specifies where to find <emphasis remap="B">pluto</emphasis>'s helper program for asynchronous DNS > lookup. <emphasis remap="B">pluto</emphasis> can be built to use > one of two helper programs: <emphasis remap="B">_pluto_adns</emphasis> or <emphasis remap="B">lwdnsq</emphasis>. You must use the program for which it > was built. By default, <emphasis remap="B">pluto</emphasis> will > look for the program in <emphasis remap="B">$IPSEC_DIR</emphasis> > (if that environment variable is defined) or, failing that, in the > same directory as <emphasis remap="B">pluto</emphasis>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--nofork</option></term> > > <listitem> > <para>disable âdaemon forkâ (default is to fork). In addition, > after the lock file and control socket are created, print the line > âPluto initializedâ to standard out.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--uniqueids</option></term> > > <listitem> > <para>if this option has been selected, whenever a new ISAKMP SA > is established, any connection with the same Peer ID but a > different Peer IP address is unoriented (causing all its SAs to be > deleted). This helps clean up dangling SAs when a connection is > lost and then regained at another IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--force_busy</option></term> > > <listitem> > <para>if this option has been selected, pluto will be forced > to be "busy". In this state, which happens when there is a > Denial of Service attack, will force pluto to use cookies > before accepting new incoming IKE packets. Cookies are send > and required in ikev1 Aggressive Mode and in ikev2. > This option is mostly used for testing purposes, but can > be selected by paranoid administrators as well.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--stderrlog</option></term> > > <listitem> > <para>log goes to standard out {default is to use <citerefentry> > <refentrytitle>syslogd</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>)</para> > </listitem> > </varlistentry> > </variablelist> > > <para>For example</para> > > <variablelist remap="TP"> > <varlistentry> > <term>pluto --secretsfile ipsec.secrets > --ctlbase pluto.base --ikeport 8500 --nofork --use-nostack > --stderrlog</term> > > <listitem> > <para/> > > <!-- FIXME: blank list item --> > </listitem> > </varlistentry> > </variablelist> > > <para>lets one test <emphasis remap="B">pluto</emphasis> without using > the superuser account.</para> > > <para><emphasis remap="B">pluto</emphasis> is willing to produce a > prodigious amount of debugging information. To do so, it must be > compiled with -DDEBUG. There are several classes of debugging output, > and <emphasis remap="B">pluto</emphasis> may be directed to produce a > selection of them. All lines of debugging output are prefixed with > â| â to distinguish them from error messages.</para> > > <para>When <emphasis remap="B">pluto</emphasis> is invoked, it may be > given arguments to specify which classes to output. The current options > are:</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--debug-none</option></term> > > <listitem> > <para>disable all debugging</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-all</option></term> > > <listitem> > <para>enable all debugging</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-raw</option></term> > > <listitem> > <para>show the raw bytes of messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-crypt</option></term> > > <listitem> > <para>show the encryption and decryption of messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-parsing</option></term> > > <listitem> > <para>show the structure of input messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-emitting</option></term> > > <listitem> > <para>show the structure of output messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-control</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s decision > making</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-controlmore</option></term> > > <listitem> > <para>show even more detailed <emphasis remap="B">pluto</emphasis> > decision making</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-lifecycle</option></term> > > <listitem> > <para>[this option is temporary] log more detail of lifecycle of > SAs</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-klips</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s interaction with > <emphasis remap="B">KLIPS</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-pfkey</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s <emphasis remap="B">PFKEY</emphasis>interface communication</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-dns</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s interaction with > <emphasis remap="B">DNS</emphasis> for KEY and TXT records</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-dpd</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s <emphasis remap="B">Dead Peer Detection</emphasis> handling</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-natt</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s <emphasis remap="B">NAT Traversal</emphasis> handling</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-oppo</option></term> > > <listitem> > <para>show why <emphasis remap="B">pluto</emphasis> didn't find a > suitable DNS TXT record to authorize opportunistic > initiation</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-oppoinfo</option></term> > > <listitem> > <para>log when connections are initiated due to acquires from the kernel. This is often useful to know, but can be extremely chatty on a busy system. </para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-whackwatch</option></term> > > <listitem> > <para>if set, causes pluto not to release the whack --initiate channel until the SA is completely up. This will cause the requestor to possibly wait forever while pluto unsuccessfully negotiates. Used often in test cases.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-private</option></term> > > <listitem> > <para>allow debugging output with private keys.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The debug form of the <emphasis remap="B">whack</emphasis> command > will change the selection in a running <emphasis remap="B">pluto</emphasis>. If a connection name is specified, the flags > are added whenever <emphasis remap="B">pluto</emphasis> has identified > that it is dealing with that connection. Unfortunately, this is often > part way into the operation being observed.</para> > > <para>For example, to start a <emphasis remap="B">pluto</emphasis> with > a display of the structure of input and output:</para> > > <para>pluto --debug-emitting --debug-parsing</para> > > <para>To later change this <emphasis remap="B">pluto</emphasis> to only > display raw bytes:</para> > > <para>whack --debug-raw</para> > > <para>For testing, SSH's IKE test page is quite useful:</para> > > <para><emphasis remap="I"><ulink url="http://isakmp-test.ssh.fi/">http://isakmp-test.ssh.fi/</ulink></emphasis></para> > > <para>Hint: ISAKMP SAs are often kept alive by IKEs even after the IPsec > SA is established. This allows future IPsec SA's to be negotiated > directly. If one of the IKEs is restarted, the other may try to use the > ISAKMP SA but the new IKE won't know about it. This can lead to much > confusion. <emphasis remap="B">pluto</emphasis> is not yet smart enough > to get out of such a mess.</para> > </refsect2> > > <refsect2 id="plutos_behaviour_when_things_go_wrong"> > <title>Pluto's Behaviour When Things Go Wrong</title> > > <para>When <emphasis remap="B">pluto</emphasis> doesn't understand or > accept a message, it just ignores the message. It is not yet capable of > communicating the problem to the other IKE daemon (in the future it > might use Notifications to accomplish this in many cases). It does log a > diagnostic.</para> > > <para>When <emphasis remap="B">pluto</emphasis> gets no response from a > message, it resends the same message (a message will be sent at most > three times). This is appropriate: UDP is unreliable.</para> > > <para>When pluto gets a message that it has already seen, there are many > cases when it notices and discards it. This too is appropriate for > UDP.</para> > > <para>Combine these three rules, and you can explain many apparently > mysterious behaviours. In a <emphasis remap="B">pluto</emphasis> log, > retrying isn't usually the interesting event. The critical thing is > either earlier (<emphasis remap="B">pluto</emphasis> got a message which > it didn't like and so ignored, so it was still awaiting an acceptable > message and got impatient) or on the other system (<emphasis remap="B">pluto</emphasis> didn't send a reply because it wasn't happy > with the previous message).</para> > </refsect2> > > <refsect2 id="notes"> > <title>Notes</title> > > <para>If <emphasis remap="B">pluto</emphasis> is compiled without > -DKLIPS, it negotiates Security Associations but never ask the kernel to > put them in place and never makes routing changes. This allows <emphasis remap="B">pluto</emphasis> to be tested on systems without <emphasis remap="B">KLIPS</emphasis>, but makes it rather useless.</para> > > <para>Each IPsec SA is assigned an SPI, a 32-bit number used to refer to > the SA. The IKE protocol lets the destination of the SA choose the SPI. > The range 0 to 0xFF is reserved for IANA. <emphasis remap="B">Pluto</emphasis> also avoids choosing an SPI in the range > 0x100 to 0xFFF, leaving these SPIs free for manual keying. Remember that > the peer, if not <emphasis remap="B">pluto</emphasis>, may well chose > SPIs in this range.</para> > </refsect2> > > <refsect2 id="policies"> > <title>Policies</title> > > <para>This catalogue of policies may be of use when trying to configure > <emphasis remap="B">Pluto</emphasis> and another IKE implementation to > interoperate.</para> > > <para>In Phase 1, only Main Mode is supported. We are not sure that > Aggressive Mode is secure. For one thing, it does not support identity > protection. It may allow more severe Denial Of Service attacks.</para> > > <para>No Informational Exchanges are supported. These are optional and > since their delivery is not assured, they must not matter. It is the > case that some IKE implementations won't interoperate without > Informational Exchanges, but we feel they are broken.</para> > > <para>No Informational Payloads are supported. These are optional, but > useful. It is of concern that these payloads are not authenticated in > Phase 1, nor in those Phase 2 messages authenticated with > HASH(3).</para> > > <variablelist remap="IP"> > <varlistentry> > <term>â¢</term> > > <listitem> > <para>Diffie Hellman Groups MODP 1024 and MODP 1536 (2 and 5) are > supported. Group MODP768 (1) is not supported because it is too > weak.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>Host authetication can be done by RSA Signatures or > Pre-Shared Secrets.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>3DES CBC (Cypher Block Chaining mode) is the only encryption > supported, both for ISAKMP SAs and IPSEC SAs.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>MD5 and SHA1 hashing are supported for packet authentication > in both kinds of SAs.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>The ESP, AH, or AH plus ESP are supported. If, and only if, > AH and ESP are combined, the ESP need not have its own > authentication component. The selection is controlled by the > --encrypt and --authenticate flags.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>Each of these may be combined with IPCOMP Deflate > compression, but only if the potential connection specifies > compression and only if KLIPS is configured with IPCOMP > support.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>The IPSEC SAs may be tunnel or transport mode, where > appropriate. The --tunnel flag controls this when <emphasis remap="B">pluto</emphasis> is initiating.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>When responding to an ISAKMP SA proposal, the maximum > acceptable lifetime is eight hours. The default is one hour. There > is no minimum. The --ikelifetime flag controls this when <emphasis remap="B">pluto</emphasis> is initiating.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>When responding to an IPSEC SA proposal, the maximum > acceptable lifetime is one day. The default is eight hours. There > is no minimum. The --ipseclifetime flag controls this when > <emphasis remap="B">pluto</emphasis> is initiating.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>PFS is acceptable, and will be proposed if the --pfs flag > was specified. The DH group proposed will be the same as > negotiated for Phase 1.</para> > </listitem> > </varlistentry> > </variablelist> > </refsect2> > </refsect1> > > <refsect1 id="signals"> > <title>SIGNALS</title> > > <para><emphasis remap="B">Pluto</emphasis> responds to > <constant>SIGHUP</constant> by issuing a suggestion that ``<emphasis remap="B">whack</emphasis> --listen'' might have been intended.</para> > > <para><emphasis remap="B">Pluto</emphasis> exits when it recieves > <constant>SIGTERM</constant>.</para> > </refsect1> > > <refsect1 id="exit_status"> > <title>EXIT STATUS</title> > > <para><emphasis remap="B">pluto</emphasis> normally forks a daemon > process, so the exit status is normally a very preliminary result.</para> > > <variablelist remap="TP"> > <varlistentry> > <term>0</term> > > <listitem> > <para>means that all is OK so far.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>1</term> > > <listitem> > <para>means that something was wrong.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>10</term> > > <listitem> > <para>means that the lock file already exists.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>If <emphasis remap="B">whack</emphasis> detects a problem, it will > return an exit status of 1. If it received progress messages from > <emphasis remap="B">pluto</emphasis>, it returns as status the value of > the numeric prefix from the last such message that was not a message sent > to syslog or a comment (but the prefix for success is treated as 0). > Otherwise, the exit status is 0.</para> > </refsect1> > > <refsect1 id="files"> > <title>FILES</title> > > <para><filename>/var/run/pluto/pluto.pid</filename> <!-- .br --> > <filename>/var/run/pluto/pluto.ctl</filename> <!-- .br --> > <filename>/etc/ipsec.secrets</filename> <!-- .br --> <emphasis remap="I">$IPSEC_LIBDIR/_pluto_adns</emphasis> <!-- .br --> <emphasis remap="I">$IPSEC_EXECDIR/lwdnsq</emphasis> <!-- .br --> > <filename>/dev/urandom</filename></para> > </refsect1> > > <refsect1 id="environment"> > <title>ENVIRONMENT</title> > > <para><emphasis remap="I">IPSEC_LIBDIR</emphasis> <!-- .br --> <emphasis remap="I">IPSEC_EXECDIR</emphasis> <!-- .br --> <emphasis remap="I">IPSECmyid</emphasis> <!-- .br --> <emphasis remap="I">PLUTO_CORE_DIR</emphasis></para> > </refsect1> > > <refsect1 id="see_also"> > <title>SEE ALSO</title> > > <para>The rest of the Openswan distribution, in particular <citerefentry> > <refentrytitle>ipsec</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>.</para> > > <para><citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> is designed to make using <emphasis remap="B">pluto</emphasis> more pleasant. Use it!</para> > > <para><citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> describes the format of the secrets file.</para> > > <para><citerefentry> > <refentrytitle>ipsec_atoaddr</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>, part of the Openswan distribution, describes the forms > that IP addresses may take. <citerefentry> > <refentrytitle>ipsec_atosubnet</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>, part of the Openswan distribution, describes the forms > that subnet specifications.</para> > > <para>For more information on IPsec, the mailing list, and the relevant > documents, see:</para> > > <!-- .nh --> > > <para><emphasis remap="I"><ulink url="http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html">http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html</ulink></emphasis></para> > > <!-- .hy --> > > <para>At the time of writing, the most relevant IETF RFCs are:</para> > > <para>RFC2409 The Internet Key Exchange (IKE)</para> > > <para>RFC2408 Internet Security Association and Key Management Protocol > (ISAKMP)</para> > > <para>RFC2407 The Internet IP Security Domain of Interpretation for > ISAKMP</para> > > <para>The Openswan web site <htp://www.openswan.org> and the mailing > lists described there.</para> > </refsect1> > > <refsect1 id="history"> > <title>HISTORY</title> > > <para>This code is released under the GPL terms. See the accompanying > files COPYING and CREDITS for more details. The GPL does NOT apply to > those pieces of code written by others which are included in this > distribution, except as noted by the individual authors.</para> > > <para>This software was originally written for the FreeS/WAN project > <<ulink url="http://www.freeswan.org">http://www.freeswan.org</ulink>>, founded > by John Gilmore and managed by Hugh Daniel. It was written by Angelos D. > Keromytis (angelos@dsl.cis.upenn.edu), in May/June 1997, in Athens, > Greece. Thanks go to John Ioannidis for his help.</para> > > <para>It is currently maintained and extended by Xelerance Corporation, in > Canada under the Openswan name. See CHANGES for details.</para> > > <para>FreeS/WAN was developed/maintained from 2000-2004 by D. Hugh > Redelmeier (hugh@mimosa.com), in Canada. The regulations of Greece and > Canada allow the code to be freely redistributable.</para> > > <para>Kai Martius (admin@imib.med.tu-dresden.de) contributed the initial > version of the code supporting PFS.</para> > > <para>Richard Guy Briggs <rgb@conscoop.ottawa.on.ca> and Peter Onion > <ponion@srd.bt.co.uk> added the PFKEY2 support.</para> > > <para>We gratefully acknowledge that we use parts of Eric Young's > <emphasis remap="I">libdes</emphasis> package; see <emphasis remap="I">../libdes/COPYRIGHT</emphasis>.</para> > </refsect1> > > <refsect1 id="bugs"> > <title>BUGS</title> > > <para><emphasis remap="B">pluto</emphasis> is a work-in-progress. It > currently has many limitations. For example, it ignores notification > messages that it receives, and it generates only Delete Notifications and > those only for IPSEC SAs.</para> > > <para><emphasis remap="B">pluto</emphasis> does not support the Commit > Flag. The Commit Flag is a bad feature of the IKE protocol. It isn't > protected -- neither encrypted nor authenticated. A man in the middle > could turn it on, leading to DoS. We just ignore it, with a warning. This > should let us interoperate with implementations that insist on it, with > minor damage.</para> > > <para><emphasis remap="B">pluto</emphasis> does not check that the SA > returned by the Responder is actually one that was proposed. It only > checks that the SA is acceptable. The difference is not large, but can > show up in attributes such as SA lifetime.</para> > > <para>There is no good way for a connection to be automatically > terminated. This is a problem for Road Warrior and Opportunistic > connections. The <option>--dontrekey</option> option does prevent the SAs > from being rekeyed on expiry. Additonally, if a Road Warrior connection > has a client subnet with a fixed IP address, a negotiation with that > subnet will cause any other connection instantiations with that same > subnet to be unoriented (deleted, in effect). See also the --uniqueids > option for an extension of this.</para> > > <para>When <emphasis remap="B">pluto</emphasis> sends a message to a peer > that has disappeared, <emphasis remap="B">pluto</emphasis> receives > incomplete information from the kernel, so it logs the unsatisfactory > message âsome IKE message we sent has been rejected with ECONNREFUSED > (kernel supplied no details)â. John Denker suggests that this command is > useful for tracking down the source of these problems: <!-- .br --> > tcpdump -i eth0 icmp[0] != 8 and icmp[0] != 0 <!-- .br --> Substitute your > public interface for eth0 if it is different.</para> > > <para>The word âauthenticateâ is used for two different features. We must > authenticate each IKE peer to the other. This is an important task of > Phase 1. Each packet must be authenticated, both in IKE and in IPsec, and > the method for IPsec is negotiated as an AH SA or part of an ESP SA. > Unfortunately, the protocol has no mechanism for authenticating the Phase > 2 identities.</para> > > <para>Bugs should be reported to the <users@lists.openswan.org> > mailing list.</para> > </refsect1> ></refentry> >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto >[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m xmllint man pluto.8.xml [1P[1P[1P[1P[1P[1@ [C[C[C[C[C[C[C[C[C[C[C[C >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:946: parser error : Entity 'nbsp' not defined > <para> ipsec tncfg --attach --virtual ipsec0 > ^ >pluto.8.xml:947: parser error : Entity 'nbsp' not defined > --physical eth0</para> > ^ >pluto.8.xml:1261: parser error : Entity 'nbsp' not defined > <term><option>--ctlbase</option> <emphasis > ^ >pluto.8.xml:1272: parser error : Entity 'nbsp' not defined > <term><option>--optionsfrom</option> <emphasis > ^ >pluto.8.xml:1281: parser error : Entity 'nbsp' not defined > <term><option>--label</option> <emphasis > ^ >pluto.8.xml:1328: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:1340: parser error : Entity 'nbsp' not defined > <para> client_subnet<-->host:ikeport<-->nexth > ^ >pluto.8.xml:1340: parser error : Entity 'nbsp' not defined > <para> client_subnet<-->host:ikeport<-->nexth > ^ >pluto.8.xml:1340: parser error : Entity 'nbsp' not defined > <para> client_subnet<-->host:ikeport<-->nexth > ^ >pluto.8.xml:1351: parser error : Entity 'nbsp' not defined > <term><option>--id</option> <emphasis > ^ >pluto.8.xml:1386: parser error : Entity 'nbsp' not defined > <term><option>--host</option> <emphasis > ^ >pluto.8.xml:1389: parser error : Entity 'nbsp' not defined > <term><option>--host</option> <emphasis > ^ >pluto.8.xml:1392: parser error : Entity 'nbsp' not defined > <term><option>--host</option> <emphasis > ^ >pluto.8.xml:1409: parser error : Entity 'nbsp' not defined > <term><option>--cert</option> <emphasis > ^ >pluto.8.xml:1425: parser error : Entity 'nbsp' not defined > <term><option>--ca</option> <emphasis remap="I">distinguished > ^ >pluto.8.xml:1437: parser error : Entity 'nbsp' not defined > <term><option>--groups</option> <emphasis remap="I">access > ^ >pluto.8.xml:1446: parser error : Entity 'nbsp' not defined > <term><option>--sendcert</option> <emphasis > ^ >pluto.8.xml:1464: parser error : Entity 'nbsp' not defined > <term><option>--certtype</option> <emphasis > ^ >pluto.8.xml:1473: parser error : Entity 'nbsp' not defined > <term><option>--ikeport</option> <emphasis > ^ >pluto.8.xml:1486: parser error : Entity 'nbsp' not defined > <term><option>--nexthop</option> <emphasis > ^ >pluto.8.xml:1504: parser error : Entity 'nbsp' not defined > <term><option>--client</option> <emphasis > ^ >pluto.8.xml:1526: parser error : Entity 'nbsp' not defined > <term><option>--clientwithin</option> <emphasis > ^ >pluto.8.xml:1536: parser error : Entity 'nbsp' not defined > <term><option>--clientprotoport</option> <emphasis > ^ >pluto.8.xml:1553: parser error : Entity 'nbsp' not defined > <term><option>--srcip</option> <emphasis > ^ >pluto.8.xml:1675: parser error : Entity 'nbsp' not defined > <term><option>--updown</option> <emphasis > ^ >pluto.8.xml:1833: parser error : Entity 'nbsp' not defined > <term><option>--pfsgroup</option> <emphasis > ^ >pluto.8.xml:1862: parser error : Entity 'nbsp' not defined > <term><option>--esp</option> <emphasis > ^ >pluto.8.xml:1904: parser error : Entity 'nbsp' not defined > <term><option>--dpddelay</option> <emphasis > ^ >pluto.8.xml:1915: parser error : Entity 'nbsp' not defined > <term><option>--timeout</option> <emphasis > ^ >pluto.8.xml:1928: parser error : Entity 'nbsp' not defined > <term><option>--dpdaction</option> <emphasis > ^ >pluto.8.xml:2159: parser error : Entity 'nbsp' not defined > <term><option>--ikelifetime</option> <emphasis > ^ >pluto.8.xml:2172: parser error : Entity 'nbsp' not defined > <term><option>--ipseclifetime</option> <emphasis > ^ >pluto.8.xml:2185: parser error : Entity 'nbsp' not defined > <term><option>--rekeymargin</option> <emphasis > ^ >pluto.8.xml:2197: parser error : Entity 'nbsp' not defined > <term><option>--rekeyfuzz</option> <emphasis > ^ >pluto.8.xml:2211: parser error : Entity 'nbsp' not defined > <term><option>--keyingtries</option> <emphasis > ^ >pluto.8.xml:2259: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2273: parser error : Entity 'nbsp' not defined > <term><option>--deletestate</option> <emphasis > ^ >pluto.8.xml:2299: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2316: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2341: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2371: parser error : Entity 'nbsp' not defined > <term><option>--oppohere</option> <emphasis > ^ >pluto.8.xml:2374: parser error : Entity 'nbsp' not defined > <term><option>--oppothere</option> <emphasis > ^ >pluto.8.xml:2392: parser error : Entity 'nbsp' not defined > <term><option>--name</option> <emphasis > ^ >pluto.8.xml:2405: parser error : Entity 'nbsp' not defined > <term><option>--crash</option> <emphasis > ^ >pluto.8.xml:2473: parser error : Entity 'nbsp' not defined > <term><option>--keyid </option><replaceable>id</replaceable></ter > ^ >pluto.8.xml:2496: parser error : Entity 'nbsp' not defined > <term><option>--pubkeyrsa </option><replaceable>key</replaceable> > ^ >pluto.8.xml:2587: parser error : Entity 'nbsp' not defined > <para> ipsec pluto</para> > ^ >pluto.8.xml:2587: parser error : Entity 'nbsp' not defined > <para> ipsec pluto</para> > ^ >pluto.8.xml:2587: parser error : Entity 'nbsp' not defined > <para> ipsec pluto</para> > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2598: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name silly > ^ >pluto.8.xml:2599: parser error : Entity 'nbsp' not defined > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > ^ >pluto.8.xml:2599: parser error : Entity 'nbsp' not defined > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > ^ >pluto.8.xml:2599: parser error : Entity 'nbsp' not defined > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > ^ >pluto.8.xml:2600: parser error : Entity 'nbsp' not defined > --ipseclifetime 800 --keyingtries 3</para> > ^ >pluto.8.xml:2600: parser error : Entity 'nbsp' not defined > --ipseclifetime 800 --keyingtries 3</para> > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2610: parser error : Entity 'nbsp' not defined > <para> ipsec whack --name secret > ^ >pluto.8.xml:2611: parser error : Entity 'nbsp' not defined > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > ^ >pluto.8.xml:2611: parser error : Entity 'nbsp' not defined > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > ^ >pluto.8.xml:2611: parser error : Entity 'nbsp' not defined > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > ^ >pluto.8.xml:2612: parser error : Entity 'nbsp' not defined > --client 10.0.2.0/24 --encrypt</para> > ^ >pluto.8.xml:2626: parser error : Entity 'nbsp' not defined > <para> ipsec whack --listen</para> > ^ >pluto.8.xml:2626: parser error : Entity 'nbsp' not defined > <para> ipsec whack --listen</para> > ^ >pluto.8.xml:2626: parser error : Entity 'nbsp' not defined > <para> ipsec whack --listen</para> > ^ >pluto.8.xml:2634: parser error : Entity 'nbsp' not defined > <para> ipsec whack --route secret</para> > ^ >pluto.8.xml:2634: parser error : Entity 'nbsp' not defined > <para> ipsec whack --route secret</para> > ^ >pluto.8.xml:2634: parser error : Entity 'nbsp' not defined > <para> ipsec whack --route secret</para> > ^ >pluto.8.xml:2640: parser error : Entity 'nbsp' not defined > <para> ipsec whack > ^ >pluto.8.xml:2640: parser error : Entity 'nbsp' not defined > <para> ipsec whack > ^ >pluto.8.xml:2640: parser error : Entity 'nbsp' not defined > <para> ipsec whack > ^ >pluto.8.xml:2641: parser error : Entity 'nbsp' not defined > --initiate --name secret</para> > ^ >pluto.8.xml:2641: parser error : Entity 'nbsp' not defined > --initiate --name secret</para> > ^ >pluto.8.xml:2650: parser error : Entity 'nbsp' not defined > <para> ipsec whack --shutdown</para> > ^ >pluto.8.xml:2650: parser error : Entity 'nbsp' not defined > <para> ipsec whack --shutdown</para> > ^ >pluto.8.xml:2650: parser error : Entity 'nbsp' not defined > <para> ipsec whack --shutdown</para> > ^ >pluto.8.xml:2670: parser error : Entity 'nbsp' not defined > <option>--xauthuser </option><replaceable>user</replaceable> > ^ >pluto.8.xml:2671: parser error : Entity 'nbsp' not defined > <option>--xauthpass </option><replaceable>pass</replaceable> may be > ^ >pluto.8.xml:2672: parser error : Entity 'nbsp' not defined > be given prior to the <option>--initiate </option> to provide > ^ >pluto.8.xml:3254: parser error : Entity 'nbsp' not defined > <term>pluto --secretsfile ipsec.secrets > ^ >pluto.8.xml:3255: parser error : Entity 'nbsp' not defined > --ctlbase pluto.base --ikeport 8500 --nofork --use-nostack > ^ >pluto.8.xml:3255: parser error : Entity 'nbsp' not defined > --ctlbase pluto.base --ikeport 8500 --nofork --use-nostack > ^ >pluto.8.xml:3274: parser error : Entity 'nbsp' not defined > â| â to distinguish them from error messages.</para> > ^ ><?xml version="1.0" encoding="UTF-8"?> ><!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> ><!-- lifted from troff+man by doclifter --> ><refentry id="pluto8"> > <refentryinfo> > <date>26 October 2006</date> > </refentryinfo> > > <refmeta> > <refentrytitle>IPSEC_PLUTO</refentrytitle> > > <manvolnum>8</manvolnum> > > <refmiscinfo class="date">25 February 2008</refmiscinfo> > </refmeta> > > <refnamediv id="name"> > <refname>ipsec pluto</refname> > > <refpurpose>ipsec whack : IPsec IKE keying daemon and control > interface</refpurpose> > </refnamediv> > > <!-- body begins here --> > > <refsynopsisdiv id="synopsis"> > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>pluto</replaceable></arg> > > <arg choice="opt">--help</arg> > > <arg choice="opt">--version</arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--nofork</arg> > > <arg choice="opt">--stderrlog</arg> > > <arg choice="opt">--use-auto</arg> > > <arg choice="opt">--use-klips</arg> > > <arg choice="opt">--use-netkey</arg> > > <arg choice="opt">--use-nostack</arg> > > <arg choice="opt">--uniqueids</arg> > > <arg choice="opt">--nat_traversal</arg> > > <arg choice="opt">--virtual_private > <replaceable>network_list</replaceable></arg> > > <arg choice="opt">--keep_alive > <replaceable>delay_sec</replaceable></arg> > > <arg choice="opt">--force_keepalive</arg> > > <arg choice="opt">--force_busy</arg> > > <arg choice="opt">--disable_port_floating</arg> > > <arg choice="opt">--nocrsend</arg> > > <arg choice="opt">--strictcrlpolicy</arg> > > <arg choice="opt">--crlcheckinterval</arg> > > <arg choice="opt">--ocspuri</arg> > > <arg choice="opt">--interface > <replaceable>interfacename</replaceable></arg> > > <arg choice="opt">--ikeport <replaceable>portnumber</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--secretsfile > <replaceable>secrets-file</replaceable></arg> > > <arg choice="opt">--adns <replaceable>pathname</replaceable></arg> > > <arg choice="opt">--nhelpers <replaceable>number</replaceable></arg> > > <arg choice="opt">--lwdnsq <replaceable>pathname</replaceable></arg> > > <arg choice="opt">--perpeerlog</arg> > > <arg choice="opt">--perpeerlogbase > <replaceable>dirname</replaceable></arg> > > <arg choice="opt">--ipsecdir <replaceable>dirname</replaceable></arg> > > <arg choice="opt">--coredir <replaceable>dirname</replaceable></arg> > > <arg choice="opt">--noretransmits</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--help</arg> > > <arg choice="opt">--version</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--debug-none</arg> > > <arg choice="opt">--debug-all</arg> > > <arg choice="opt">--debug-raw</arg> > > <arg choice="opt">--debug-crypt</arg> > > <arg choice="opt">--debug-parsing</arg> > > <arg choice="opt">--debug-emitting</arg> > > <arg choice="opt">--debug-control</arg> > > <arg choice="opt">--debug-lifecycle</arg> > > <arg choice="opt">--debug-klips</arg> > > <arg choice="opt">--debug-pfkey</arg> > > <arg choice="opt">--debug-nat-t</arg> > > <arg choice="opt">--debug-dpd</arg> > > <arg choice="opt">--debug-dns</arg> > > <arg choice="opt">--debug-oppo</arg> > <arg choice="opt">--debug-oppoinfo</arg> > <arg choice="opt">--debug-whackwatch</arg> > > <arg choice="opt">--debug-private</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <group choice="opt"> > <arg choice="opt">--ipv4</arg> > > <arg choice="opt">--ipv6</arg> > </group> > > <group choice="opt"> > <arg choice="opt">--tunnelipv4</arg> > > <arg choice="opt">--tunnelipv6</arg> > </group> > > <sbr/> > > <sbr/> > > <arg choice="opt">--id <replaceable>identity</replaceable></arg> > > <arg choice="opt">--host <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--cert <replaceable>path</replaceable></arg> > > <arg choice="opt">--ca <replaceable>distinguished > name</replaceable></arg> > > <arg choice="opt">--groups <replaceable>access control > groups</replaceable></arg> > > <arg choice="opt">--sendcert <group choice="plain"> > <arg choice="plain">yes</arg> > > <arg choice="plain">forced</arg> > > <arg choice="plain">always</arg> > > <arg choice="plain">ifasked</arg> > > <arg choice="plain">no</arg> > > <arg choice="plain">never</arg> > </group></arg> > > <arg choice="opt">--certtype <replaceable>number</replaceable></arg> > > <arg choice="opt">--ikeport <replaceable>portnumber</replaceable></arg> > > <arg choice="opt">--nexthop <replaceable>ip-address</replaceable></arg> > > <group choice="opt"> > <arg choice="opt">--client <replaceable>subnet</replaceable></arg> > > <arg choice="opt">--clientwithin > <replaceable>subnet</replaceable></arg> > </group> > > <arg choice="opt">--clientprotoport > <replaceable>protocol</replaceable>/<replaceable>port</replaceable></arg> > > <arg choice="opt">--srcip <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--xauthserver</arg> > > <arg choice="opt">--xauthclient</arg> > > <arg choice="opt">--modecfgserver</arg> > > <arg choice="opt">--modecfgclient</arg> > > <arg choice="opt">--modecfgdns1</arg> > > <arg choice="opt">--modecfgdns2</arg> > > <arg choice="opt">--modecfgwins1</arg> > > <arg choice="opt">--modecfgwins2</arg> > > <arg choice="opt">--dnskeyondemand</arg> > > <arg choice="opt">--updown <replaceable>updown</replaceable></arg> > > <sbr/> > > <sbr/> > > <arg choice="plain">--to</arg> > > <sbr/> > > <sbr/> > > <arg choice="opt">--id <replaceable>identity</replaceable></arg> > > <arg choice="opt">--host <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--cert <replaceable>path</replaceable></arg> > > <arg choice="opt">--ca <replaceable>distinguished > name</replaceable></arg> > > <arg choice="opt">--groups <replaceable>access control > groups</replaceable></arg> > > <arg choice="opt">--sendcert <group choice="plain"> > <arg choice="plain">yes</arg> > > <arg choice="plain">always</arg> > > <arg choice="plain">ifasked</arg> > > <arg choice="plain">no</arg> > > <arg choice="plain">never</arg> > </group></arg> > > <arg choice="opt">--certtype <replaceable>number</replaceable></arg> > > <arg choice="opt">--ikeport <replaceable>port-number</replaceable></arg> > > <arg choice="opt">--nexthop <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--client <replaceable>subnet</replaceable></arg> > > <arg choice="opt">--clientwithin <replaceable>subnet</replaceable></arg> > > <arg choice="opt">--clientprotoport > <replaceable>protocol</replaceable>/<replaceable>port</replaceable></arg> > > <arg choice="opt">--srcip <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--xauthserver</arg> > > <arg choice="opt">--xauthclient</arg> > > <arg choice="opt">--modecfgserver</arg> > > <arg choice="opt">--modecfgclient</arg> > > <arg choice="opt">--modecfgdns1 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--modecfgdns2 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--modecfgwins1 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--modecfgwins2 <replaceable>ip-address</replaceable></arg> > > <arg choice="opt">--dnskeyondemand</arg> > > <arg choice="opt">--updown <replaceable>updown</replaceable></arg> > > <sbr/> > > <sbr/> > > <arg choice="opt">--tunnel</arg> > > <arg choice="opt">--psk</arg> > > <arg choice="opt">--rsasig</arg> > > <arg choice="opt">--encrypt</arg> > > <arg choice="opt">--authenticate</arg> > > <arg choice="opt">--compress</arg> > > <arg choice="opt">--pfs</arg> > > <arg choice="opt">--pfsgroup <group choice="plain"> > <arg choice="opt">modp1024</arg> > > <arg choice="opt">modp1536</arg> > > <arg choice="opt">modp2048</arg> > > <arg choice="opt">modp3072</arg> > > <arg choice="opt">modp4096</arg> > > <arg choice="opt">modp6144</arg> > > <arg choice="opt">modp8192</arg> > </group></arg> > > <arg choice="opt">--disablearrivalcheck</arg> > > <arg choice="opt">--ikelifetime <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--ipseclifetime > <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--rekeymargin <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--rekeyfuzz > <replaceable>percentage</replaceable></arg> > > <arg choice="opt">--keyingtries <replaceable>count</replaceable></arg> > > <arg choice="opt">--esp <replaceable>esp-algos</replaceable></arg> > > <arg choice="opt">--dontrekey</arg> > > <arg choice="opt">--aggrmode</arg> > > <arg choice="opt">--modecfgpull</arg> > > <group choice="opt"> > <arg choice="opt">--dpddelay <replaceable>seconds</replaceable></arg> > > <arg choice="opt">--dpdtimeout > <replaceable>seconds</replaceable></arg> > </group> > > <arg choice="opt">--dpdaction <group choice="plain"> > <arg choice="opt">clear</arg> > > <arg choice="opt">hold</arg> > > <arg choice="opt">restart</arg> > </group></arg> > > <arg choice="opt">--forceencaps</arg> > > <arg choice="opt"><group choice="plain"> > <arg choice="opt">--initiateontraffic</arg> > > <arg choice="opt">--pass</arg> > > <arg choice="opt">--drop</arg> > > <arg choice="opt">--reject</arg> > </group></arg> > > <arg choice="opt"><group choice="plain"> > <arg choice="opt">--failnone</arg> > > <arg choice="opt">--failpass</arg> > > <arg choice="opt">--faildrop</arg> > > <arg choice="opt">--failreject</arg> > </group></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--keyid <replaceable>id</replaceable></arg> > > <arg choice="opt">--addkey</arg> > > <arg choice="opt">--pubkeyrsa <replaceable>key</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--myid <replaceable>id</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="plain"> > <arg choice="plain">--listen</arg> > > <arg choice="plain">--unlisten</arg> > </group> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="plain"> > <arg choice="plain">--route</arg> > > <arg choice="plain">--unroute</arg> > </group> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="plain"> > <arg choice="plain">--initiate</arg> > > <arg choice="plain">--terminate</arg> > </group> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="opt">--xauthuser <replaceable>user</replaceable></arg> > > <arg choice="opt">--xauthpass <replaceable>pass</replaceable></arg> > > <arg choice="opt">--asynchronous</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <group choice="opt"> > <arg choice="opt">--tunnelipv4</arg> > > <arg choice="opt">--tunnelipv6</arg> > </group> > > <arg choice="plain">--oppohere > <replaceable>ip-address</replaceable></arg> > > <arg choice="plain">--oppothere > <replaceable>ip-address</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--crash</arg> > > <arg choice="opt">ipaddress</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--whackrecord</arg> > > <arg choice="opt">filename</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--whackstoprecord</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="plain">--delete</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--deletestate > <replaceable>state-number</replaceable></arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--name > <replaceable>connection-name</replaceable></arg> > > <arg choice="opt">--debug-none</arg> > > <arg choice="opt">--debug-all</arg> > > <arg choice="opt">--debug-raw</arg> > > <arg choice="opt">--debug-crypt</arg> > > <arg choice="opt">--debug-parsing</arg> > > <arg choice="opt">--debug-emitting</arg> > > <arg choice="opt">--debug-control</arg> > > <arg choice="opt">--debug-controlmore</arg> > > <arg choice="opt">--debug-lifecycle</arg> > > <arg choice="opt">--debug-klips</arg> > > <arg choice="opt">--debug-pfkey</arg> > > <arg choice="opt">--debug-dns</arg> > > <arg choice="opt">--debug-dpd</arg> > > <arg choice="opt">--debug-natt</arg> > > <arg choice="opt">--debug-oppo</arg> > > <arg choice="opt">--debug-oppoinfo</arg> > > <arg choice="opt">--debug-whackwatch</arg> > > <arg choice="opt">--debug-private</arg> > > <arg choice="opt">--impair-delay-adns-key-answer</arg> > > <arg choice="opt">--impair-delay-adns-txt-answer</arg> > > <arg choice="opt">--impair-bust-mi2</arg> > > <arg choice="opt">--impair-bust-mr2</arg> > > <arg choice="opt">--impair-sa-fail</arg> > > <arg choice="opt">--impair-die-oninfo</arg> > > <arg choice="opt">--impair-jacob-two-two</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--utc</arg> > > <arg choice="opt">--listall</arg> > > <arg choice="opt">--listpubkeys</arg> > > <arg choice="opt">--listcerts</arg> > > <arg choice="opt">--listcacerts</arg> > > <arg choice="opt">--listacerts</arg> > > <arg choice="opt">--listaacerts</arg> > > <arg choice="opt">--listocspcerts</arg> > > <arg choice="opt">--listgroups</arg> > > <arg choice="opt">--listcrls</arg> > > <arg choice="opt">--listocsp</arg> > > <arg choice="opt">--listcards</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="opt">--utc</arg> > > <arg choice="opt">--rereadsecrets</arg> > > <arg choice="opt">--rereadall</arg> > > <arg choice="opt">--rereadcacerts</arg> > > <arg choice="opt">--rereadacerts</arg> > > <arg choice="opt">--rereadaacerts</arg> > > <arg choice="opt">--rereadocspcerts</arg> > > <arg choice="opt">--rereadcrls</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--purgeocsp</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--listevents</arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--status</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > > <cmdsynopsis> > <command>ipsec</command> > > <arg choice="plain"><replaceable>whack</replaceable></arg> > > <arg choice="plain">--shutdown</arg> > > <arg choice="opt">--ctlbase <replaceable>path</replaceable></arg> > > <arg choice="opt">--optionsfrom > <replaceable>filename</replaceable></arg> > > <arg choice="opt">--label <replaceable>string</replaceable></arg> > </cmdsynopsis> > </refsynopsisdiv> > > <refsect1 id="description"> > <title>DESCRIPTION</title> > > <para><emphasis remap="B">pluto</emphasis> is an IKE (âIPsec Key > Exchangeâ) daemon. <emphasis remap="B">whack</emphasis> is an auxiliary > program to allow requests to be made to a running <emphasis remap="B">pluto</emphasis>.</para> > > <para><emphasis remap="B">pluto</emphasis> is used to automatically build > shared âsecurity associationsâ on a system that has IPsec, the secure IP > protocol. In other words, <emphasis remap="B">pluto</emphasis> can > eliminate much of the work of manual keying. The actual secure > transmission of packets is the responsibility of other parts of the system > - the kernel. Pluto can talk to various kernel implementations, such as > <emphasis remap="B">KLIPS</emphasis>, such as <emphasis remap="B">NETKEY</emphasis>, and such as <emphasis remap="B">KAME</emphasis> IPsec stacks. <citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> provides a more convenient interface to <emphasis remap="B">pluto</emphasis> and <emphasis remap="B">whack</emphasis>.</para> > > <refsect2 id="ikes_job"> > <title>IKE's Job</title> > > <para>A <emphasis remap="I">Security Association</emphasis> (<emphasis remap="I">SA</emphasis>) is an agreement between two network nodes on > how to process certain traffic between them. This processing involves > encapsulation, authentication, encryption, or compression.</para> > > <para>IKE can be deployed on a network node to negotiate Security > Associations for that node. These IKE implementations can only negotiate > with other IKE implementations, so IKE must be on each node that is to > be an endpoint of an IKE-negotiated Security Association. No other nodes > need to be running IKE.</para> > > <para>An IKE instance (i.e. an IKE implementation on a particular > network node) communicates with another IKE instance using UDP IP > packets, so there must be a route between the nodes in each > direction.</para> > > <para>The negotiation of Security Associations requires a number of > choices that involve tradeoffs between security, convenience, trust, and > efficiency. These are policy issues and are normally specified to the > IKE instance by the system administrator.</para> > > <para>IKE deals with two kinds of Security Associations. The first part > of a negotiation between IKE instances is to build an ISAKMP SA. An > ISAKMP SA is used to protect communication between the two IKEs. IPsec > SAs can then be built by the IKEs - these are used to carry protected IP > traffic between the systems.</para> > > <para>The negotiation of the ISAKMP SA is known as Phase 1. In theory, > Phase 1 can be accomplished by a couple of different exchange types. > Currently, Main Mode and Aggressive Mode are implemented.</para> > > <para>Any negotiation under the protection of an ISAKMP SA, including > the negotiation of IPsec SAs, is part of Phase 2. The exchange type that > we use to negotiate an IPsec SA is called Quick Mode.</para> > > <para>IKE instances must be able to authenticate each other as part of > their negotiation of an ISAKMP SA. This can be done by several > mechanisms described in the draft standards.</para> > > <para>IKE negotiation can be initiated by any instance with any other. > If both can find an agreeable set of characteristics for a Security > Association, and both recognize each others authenticity, they can set > up a Security Association. The standards do not specify what causes an > IKE instance to initiate a negotiation.</para> > > <para>In summary, an IKE instance is prepared to automate the management > of Security Associations in an IPsec environment, but a number of issues > are considered policy and are left in the system administrator's > hands.</para> > </refsect2> > > <refsect2 id="pluto"> > <title>Pluto</title> > > <para><emphasis remap="B">pluto</emphasis> is an implementation of IKE. > It runs as a daemon on a network node. Currently, this network node must > be a LINUX system running the <emphasis remap="B">KLIPS</emphasis> or > <emphasis remap="B">NETKEY</emphasis> implementation of IPsec, or a > FreeBSD/NetBSD/Mac OSX system running the <emphasis remap="B">KAME</emphasis> implementation of IPsec.</para> > > <para><emphasis remap="B">pluto</emphasis> implements a large subset of > IKE. This is enough for it to interoperate with other instances of > <emphasis remap="B">pluto</emphasis>, and many other IKE > implementations. It currently supports XAUTH, ModeConfig, X.509, Dead > Peer Detection, Opportunistic Encryption and all the NAT Traversal > standards.</para> > > <para>The policy for acceptable characteristics for Security > Associations is mostly hardwired into the code of <emphasis remap="B">pluto</emphasis> (spdb.c). Eventually this will be moved into > a security policy database with reasonable expressive power and more > convenience.</para> > > <para><emphasis remap="B">pluto</emphasis> uses shared secrets or RSA > signatures to authenticate peers with whom it is negotiating. These RSA > signatures can come from DNS(SEC), a configuration file, or from X.509 > and CA certificates.</para> > > <para><emphasis remap="B">pluto</emphasis> initiates negotiation of a > Security Association when it is manually prodded: the program <emphasis remap="B">whack</emphasis> is run to trigger this. It will also initiate > a negotiation when <emphasis remap="B">KLIPS</emphasis> traps an > outbound packet for Opportunistic Encryption.</para> > > <para><emphasis remap="B">pluto</emphasis> implements ISAKMP SAs itself. > After it has negotiated the characteristics of an IPsec SA, it directs > the <emphasis remap="B">kernel</emphasis> to implement it. If necessary, > it also invokes a script to adjust any firewall and issue <citerefentry> > <refentrytitle>route</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> commands to direct IP packets.</para> > > <para>When <emphasis remap="B">pluto</emphasis> shuts down, it closes > all Security Associations.</para> > </refsect2> > > <refsect2 id="before_running_pluto"> > <title>Before Running Pluto</title> > > <para><emphasis remap="B">pluto</emphasis> runs as a daemon with userid > root. Before running it, a few things must be set up.</para> > > <para><emphasis remap="B">pluto</emphasis> requires a working IPsec > stack.</para> > > <para><emphasis remap="B">pluto</emphasis> supports multiple public > networks (that is, networks that are considered insecure and thus need > to have their traffic encrypted or authenticated). It discovers the > public interfaces to use by looking at all interfaces that are > configured (the <option>--interface</option> option can be used to limit > the interfaces considered). It does this only when <emphasis remap="B">whack</emphasis> tells it to --listen, so the interfaces must > be configured by then. Each interface with a name of the form > <command>ipsec</command>[<literal>0</literal>-<literal>9</literal>] is > taken as a <emphasis remap="B">KLIPS</emphasis> virtual public > interface. Another network interface with the same IP address (the first > one found will be used) is taken as the corresponding real public > interface. <citerefentry> > <refentrytitle>ifconfig</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> or <citerefentry> > <refentrytitle>ip</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> with the <option>-a</option> flag will show the name > and status of each network interface.</para> > > <para><emphasis remap="B">pluto</emphasis> requires a database of > preshared secrets and RSA private keys. This is described in the > <citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>. <emphasis remap="B">pluto</emphasis> is told of RSA > public keys via <emphasis remap="B">whack</emphasis> commands. If the > connection is Opportunistic, and no RSA public key is known, <emphasis remap="B">pluto</emphasis> will attempt to fetch RSA keys using the > Domain Name System.</para> > </refsect2> > > <refsect2 id="setting_up_fbklipsfp_for_fbplutofp"> > <title>Setting up <emphasis remap="B">KLIPS</emphasis> for <emphasis remap="B">pluto</emphasis></title> > > <para>The most basic network topology that <emphasis remap="B">pluto</emphasis> supports has two security gateways > negotiating on behalf of client subnets. The diagram of RGB's testbed is > a good example (see <emphasis remap="I">klips/doc/rgb_setup.txt</emphasis>).</para> > > <para>The file <filename>INSTALL</filename> in the base directory of > this distribution explains how to start setting up the whole system, > including <emphasis remap="B">KLIPS</emphasis>.</para> > > <para>Make sure that the security gateways have routes to each other. > This is usually covered by the default route, but may require issuing > <citerefentry> > <refentrytitle>route</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> commands. The route must go through a particular IP > interface (we will assume it is <emphasis remap="I">eth0</emphasis>, but > it need not be). The interface that connects the security gateway to its > client must be a different one.</para> > > <para>It is necessary to issue a <citerefentry> > <refentrytitle>ipsec_tncfg</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> command on each gateway. The required command > is:</para> > > <para> ipsec tncfg --attach --virtual ipsec0 > --physical eth0</para> > > <para>A command to set up the ipsec0 virtual interface will also need to > be run. It will have the same parameters as the command used to set up > the physical interface to which it has just been connected using > <citerefentry> > <refentrytitle>ipsec_tncfg</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>.</para> > </refsect2> > > <refsect2 id="setting_up_fbnetkeyfp_for_fbplutofp"> > <title>Setting up <emphasis remap="B">NETKEY</emphasis> for <emphasis remap="B">pluto</emphasis></title> > > <para>No special requirements are necessary to use NETKEY - it ships > with all modern versions of Linux 2.4 and 2.6. however, note that > certain vendors or older distributions use old versions or backports of > NETKEY which are broken. If possible use a NETKEY version that is at > least based on, or backported from Linux 2.6.11 or newer.</para> > </refsect2> > > <refsect2 id="ipsecsecrets_file"> > <title>ipsec.secrets file</title> > > <para>A <emphasis remap="B">pluto</emphasis> daemon and another IKE > daemon (for example, another instance of <emphasis remap="B">pluto</emphasis>) must convince each other that they are who > they are supposed to be before any negotiation can succeed. This > authentication is accomplished by using either secrets that have been > shared beforehand (manually) or by using RSA signatures. There are other > techniques, but they have not been implemented in <emphasis remap="B">pluto</emphasis>.</para> > > <para>The file <filename>/etc/ipsec.secrets</filename> is used to keep > preshared secret keys, RSA private keys, X.509 encoded keyfiles and > smartcard PIN's for authentication with other IKE daemons. For > debugging, there is an argument to the <emphasis remap="B">pluto</emphasis> command to use a different file. This file is > described in <citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>.</para> > </refsect2> > > <refsect2 id="running_pluto"> > <title>Running Pluto</title> > > <para>To fire up the daemon, just type <emphasis remap="B">pluto</emphasis> (be sure to be running as the superuser). The > default IKE port number is 500, the UDP port assigned by IANA for IKE > Daemons. <emphasis remap="B">pluto</emphasis> must be run by the > superuser to be able to use the UDP 500 port. If pluto is told to enable > NAT-Traversal, then UDP port 4500 is also taken by pluto to listen > on.</para> > > <para>Pluto supports different IPstacks on different operating systems. > The option <option>--use-auto</option>, which is also the default, lets > pluto find a stack automatically. This behaviour can be changed by > explicitely setting the stack using <option>--use-klips</option>, > <option>--use-netkey</option> or <option>--use-nostack</option>. The > latter is meant for testing only - no actual IPsec connections will be > loaded into the kernel.</para> > > <para>Pluto supports the NAT-Traversal drafts and the final standard, > RFC 3947, if the <option>--nat_traversal</option> is specified. The > allowed range behind the NAT routers is submitted using the > <option>--virtual_private</option> option. See <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> for the syntax. The option > <option>--force_keepalive</option> forces the sending of the <emphasis remap="I">keep-alive packets</emphasis>, which are send to prevent the > NAT router from closing its port when there is not enough traffic on the > IPsec connection. The <option>--keep_alive</option> sets the delay (in > seconds) of these keep-alive packets. The newer NAT-T standards support > <emphasis remap="I">port floating</emphasis>, and Openswan enables this > per default. It can be disabled using the > <option>--disable_port_floating</option> option.</para> > > <para>Pluto supports the use of X.509 certificates and sends it > certificate when needed. This can confuse IKE implementations that do > not implement this, such as the old FreeS/WAN implementation. The > <option>--nocrsend</option> prevents pluto from sending these. At > startup, pluto loads all the X.509 related files from the directories > <filename>/etc/ipsec.d/certs</filename>, > <filename>/etc/ipsec.d/cacerts</filename>, > <filename>/etc/ipsec.d/aacerts</filename>, > <filename>/etc/ipsec.d/ocspcerts</filename>, > <filename>/etc/ipsec.d/private</filename> and > <filename>/etc/ipsec.d/crls</filename>. The <emphasis remap="I">Certificate Revocation Lists</emphasis> can also be retrieved > from an URL. The option <option>--crlcheckinterval</option> sets the > time between checking for CRL expiration and issuing new fetch commands. > The first attempt to update a CRL is started at <emphasis remap="I">2*crlcheckinterval</emphasis> before the next update time. > Pluto logs a warning if no valid CRL was loaded or obtained for a > connection. If <option>--strictcrlpolicy</option> is given, the > connection will be rejected until a valid CRL has been loaded. Pluto > also has support for the <emphasis remap="I">Online Certificate Store > Protocol</emphasis> (OSCP) as defined in RFC 2560. The URL to the OSCP > store can be given to pluto via the <option>--ocspuri</option> > option.</para> > > <para>Pluto can use the BIND9 secure resolver, which means it has > support for DNSSEC, using the BIND9 <emphasis remap="I">lwres > {}</emphasis> interface, see <citerefentry> > <refentrytitle>named.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>. Pluto can also use the old <emphasis remap="I">adns</emphasis> interface if there is no BIND9 running with > <emphasis remap="I">lwres {}</emphasis> on the host, but then pluto > cannot do any DNSSEC processing. Pluto forks and starts these DNS > helpers in seperate children. The options <option>--lwdnsq</option> and > <option>--adns</option> invoke these resolvers.</para> > > <para>Pluto can also use helper children to off-load cryptographic > operations. This behavior can be fine tuned using the > <option>--nhelpers</option>. Pluto will start <emphasis remap="I">(n-1)</emphasis> of them, where <emphasis remap="I">n</emphasis> is the number of CPUâs you have (including > hypherthreaded CPUâs). A value of <emphasis remap="I">0</emphasis> > forces pluto to do all operations in the main process. A value of > <emphasis remap="I">-1</emphasis> tells pluto to perform the above > calculation. Any other value forces the number to that amount.</para> > > <para><emphasis remap="B">pluto</emphasis> attempts to create a lockfile > with the name <filename>/var/run/pluto/pluto.pid</filename>. If the > lockfile cannot be created, <emphasis remap="B">pluto</emphasis> exits - > this prevents multiple <emphasis remap="B">pluto</emphasis>s from > competing Any âleftoverâ lockfile must be removed before <emphasis remap="B">pluto</emphasis> will run. <emphasis remap="B">pluto</emphasis> writes its pid into this file so that scripts > can find it. This lock will not function properly if it is on an NFS > volume (but sharing locks on multiple machines doesn't make sense > anyway).</para> > > <para><emphasis remap="B">pluto</emphasis> then forks and the parent > exits. This is the conventional âdaemon forkâ. It can make debugging > awkward, so there is an option to suppress this fork. In certain > configurations, pluto might also launch helper programs to assist with > DNS queries or to offload cryptographic operations.</para> > > <para>All logging, including diagnostics, is sent to <citerefentry> > <refentrytitle>syslog</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry> with facility=authpriv; it decides where to put these > messages (possibly in /var/log/secure). Since this too can make > debugging awkward, the option <option>--stderrlog</option> is used to > steer logging to stderr.</para> > > <para>If the <option>--perpeerlog</option> option is given, then pluto > will open a log file per connection. By default, this is in > /var/log/pluto/peer, in a subdirectory formed by turning all dot (.) > [IPv4} or colon (:) [IPv6] into slashes (/).</para> > > <para>The base directory can be changed with the > <option>--perpeerlogbase</option>.</para> > > <para>Once <emphasis remap="B">pluto</emphasis> is started, it waits for > requests from <emphasis remap="B">whack</emphasis>.</para> > </refsect2> > > <refsect2 id="plutos_internal_state"> > <title>Pluto's Internal State</title> > > <para>To understand how to use <emphasis remap="B">pluto</emphasis>, it > is helpful to understand a little about its internal state. Furthermore, > the terminology is needed to decipher some of the diagnostic > messages.</para> > > <para>Pluto supports <emphasis remap="B">food groups</emphasis>, and > X.509 certificates. These are located in /etc/ipsec.d, or another > directory as specified by <option>--ipsecdir</option>.</para> > > <para>Pluto may core dump. It will normally do so into the current > working directory. The standard scripts have an option dumpdir=, which > can set the current directory to determine where the core dump will go. > In some cases, it may be more convenient to specify it on the command > line using --coredir. A third method is to set the environment variable > PLUTO_CORE_DIR. The command line argument takes precedence over the > environment variable. The option plutorestartoncrash can be set to no to > prevent multiple core files and a looping pluto process. Normally, when > pluto crashes, another pluto process is started.</para> > > <para>At times it may be desireable to turn off all timed events in > <emphasis remap="B">pluto</emphasis>, this can be done with > <option>--noretransmits</option>.</para> > > <para>The <emphasis remap="I">(potential) connection</emphasis> database > describes attributes of a connection. These include the IP addresses of > the hosts and client subnets and the security characteristics desired. > <emphasis remap="B">pluto</emphasis> requires this information (simply > called a connection) before it can respond to a request to build an SA. > Each connection is given a name when it is created, and all references > are made using this name.</para> > > <para>During the IKE exchange to build an SA, the information about the > negotiation is represented in a <emphasis remap="I">state > object</emphasis>. Each state object reflects how far the negotiation > has reached. Once the negotiation is complete and the SA established, > the state object remains to represent the SA. When the SA is terminated, > the state object is discarded. Each State object is given a serial > number and this is used to refer to the state objects in logged > messages.</para> > > <para>Each state object corresponds to a connection and can be thought > of as an instantiation of that connection. At any particular time, there > may be any number of state objects corresponding to a particular > connection. Often there is one representing an ISAKMP SA and another > representing an IPsec SA.</para> > > <para><emphasis remap="B">KLIPS</emphasis> hooks into the routing code > in a LINUX kernel. Traffic to be processed by an IPsec SA must be > directed through <emphasis remap="B">KLIPS</emphasis> by routing > commands. Furthermore, the processing to be done is specified by > <emphasis remap="I">ipsec eroute(8)</emphasis> commands. <emphasis remap="B">pluto</emphasis> takes the responsibility of managing both of > these special kinds of routes.</para> > > <para><emphasis remap="B">NETKEY</emphasis> requires no special > routing.</para> > > <para>Each connection may be routed, and must be while it has an IPsec > SA. The connection specifies the characteristics of the route: the > interface on this machine, the âgatewayâ (the nexthop), and the peer's > client subnet. Two connections may not be simultaneously routed if they > are for the same peer's client subnet but use different interfaces or > gateways (<emphasis remap="B">pluto</emphasis>'s logic does not reflect > any advanced routing capabilities).</para> > > <para>On KLIPS, each eroute is associated with the state object for an > IPsec SA because it has the particular characteristics of the SA. Two > eroutes conflict if they specify the identical local and remote clients > (unlike for routes, the local clients are taken into account).</para> > > <para>When <emphasis remap="B">pluto</emphasis> needs to install a route > for a connection, it must make sure that no conflicting route is in use. > If another connection has a conflicting route, that route will be taken > down, as long as there is no IPsec SA instantiating that connection. If > there is such an IPsec SA, the attempt to install a route will > fail.</para> > > <para>There is an exception. If <emphasis remap="B">pluto</emphasis>, as > Responder, needs to install a route to a fixed client subnet for a > connection, and there is already a conflicting route, then the SAs using > the route are deleted to make room for the new SAs. The rationale is > that the new connection is probably more current. The need for this > usually is a product of Road Warrior connections (these are explained > later; they cannot be used to initiate).</para> > > <para>When <emphasis remap="B">pluto</emphasis> needs to install an > eroute for an IPsec SA (for a state object), first the state object's > connection must be routed (if this cannot be done, the eroute and SA > will not be installed). If a conflicting eroute is already in place for > another connection, the eroute and SA will not be installed (but note > that the routing exception mentioned above may have already deleted > potentially conflicting SAs). If another IPsec SA for the same > connection already has an eroute, all its outgoing traffic is taken over > by the new eroute. The incoming traffic will still be processed. This > characteristic is exploited during rekeying.</para> > > <para>All of these routing characteristics are expected change when > <emphasis remap="B">KLIPS</emphasis> and <emphasis remap="B">NETKEY</emphasis> merge into a single new stack.</para> > </refsect2> > > <refsect2 id="using_whack"> > <title>Using Whack</title> > > <para><emphasis remap="B">whack</emphasis> is used to command a running > <emphasis remap="B">pluto</emphasis>. <emphasis remap="B">whack</emphasis> uses a UNIX domain socket to speak to > <emphasis remap="B">pluto</emphasis> (by default, > <filename>/var/pluto.ctl</filename>).</para> > > <para><emphasis remap="B">whack</emphasis> has an intricate argument > syntax. This syntax allows many different functions to be specified. The > help form shows the usage or version information. The connection form > gives <emphasis remap="B">pluto</emphasis> a description of a potential > connection. The public key form informs <emphasis remap="B">pluto</emphasis> of the RSA public key for a potential peer. > The delete form deletes a connection description and all SAs > corresponding to it. The listen form tells <emphasis remap="B">pluto</emphasis> to start or stop listening on the public > interfaces for IKE requests from peers. The route form tells <emphasis remap="B">pluto</emphasis> to set up routing for a connection; the > unroute form undoes this. The initiate form tells <emphasis remap="B">pluto</emphasis> to negotiate an SA corresponding to a > connection. The terminate form tells <emphasis remap="B">pluto</emphasis> to remove all SAs corresponding to a > connection, including those being negotiated. The status form displays > the <emphasis remap="B">pluto</emphasis>'s internal state. The debug > form tells <emphasis remap="B">pluto</emphasis> to change the selection > of debugging output âon the flyâ. The shutdown form tells <emphasis remap="B">pluto</emphasis> to shut down, deleting all SAs.</para> > > <para>The crash option asks pluto to consider a particularly target IP > to have crashed, and to attempt to restart all connections with that IP > address as a gateway. In general, you should use Dead Peer Detection to > detect this kind of situation automatically, but this is not always > possible.</para> > > <para>Most options are specific to one of the forms, and will be > described with that form. There are three options that apply to all > forms.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--ctlbase</option> <emphasis remap="I">path</emphasis></term> > > <listitem> > <para><emphasis remap="I">path</emphasis>.ctl is used as the UNIX > domain socket for talking to <emphasis remap="B">pluto</emphasis>. > This option facilitates debugging.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--optionsfrom</option> <emphasis remap="I">filename</emphasis></term> > > <listitem> > <para>adds the contents of the file to the argument list.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--label</option> <emphasis remap="I">string</emphasis></term> > > <listitem> > <para>adds the string to all error messages generated by <emphasis remap="B">whack</emphasis>.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The help form of <emphasis remap="B">whack</emphasis> is > self-explanatory.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--help</option></term> > > <listitem> > <para>display the usage message.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--version</option></term> > > <listitem> > <para>display the version of <emphasis remap="B">whack</emphasis>.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The connection form describes a potential connection to <emphasis remap="B">pluto</emphasis>. <emphasis remap="B">pluto</emphasis> needs > to know what connections can and should be negotiated. When <emphasis remap="B">pluto</emphasis> is the initiator, it needs to know what to > propose. When <emphasis remap="B">pluto</emphasis> is the responder, it > needs to know enough to decide whether is is willing to set up the > proposed connection.</para> > > <para>The description of a potential connection can specify a large > number of details. Each connection has a unique name. This name will > appear in a updown shell command, so it should not contain punctuation > that would make the command ill-formed.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>sets the name of the connection</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The topology of a connection is symmetric, so to save space here > is half a picture:</para> > > <para> client_subnet<-->host:ikeport<-->nexthop<---</para> > > <para>A similar trick is used in the flags. The same flag names are used > for both ends. Those before the <option>--to</option> flag describe the > left side and those afterwards describe the right side. When <emphasis remap="B">pluto</emphasis> attempts to use the connection, it decides > whether it is the left side or the right side of the connection, based > on the IP numbers of its interfaces.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--id</option> <emphasis remap="I">id</emphasis></term> > > <listitem> > <para>the identity of the end. Currently, this can be an IP > address (specified as dotted quad or as a Fully Qualified Domain > Name, which will be resolved immediately) or as a Fully Qualified > Domain Name itself (prefixed by â@â to signify that it should not > be resolved), or as user@FQDN, or an X.509 DN, or as the magic > value <emphasis remap="B">%myid</emphasis>. <emphasis remap="B">Pluto</emphasis> only authenticates the identity, and > does not use it for addressing, so, for example, an IP address > need not be the one to which packets are to be sent. If the option > is absent, the identity defaults to the IP address specified by > <option>--host</option>. <emphasis remap="B">%myid</emphasis> > allows the identity to be separately specified (by the <emphasis remap="B">pluto</emphasis> or <emphasis remap="B">whack</emphasis> > option <option>--myid</option> or by the <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> <emphasis remap="B">config setup</emphasis> > parameter <emphasis remap="P->B">myid</emphasis>). Otherwise, > <emphasis remap="B">pluto</emphasis> tries to guess what <emphasis remap="B">%myid</emphasis> should stand for: the IP address of > <emphasis remap="B">%defaultroute</emphasis>, if it is supported > by a suitable TXT record in the reverse domain for that IP > address, or the system's hostname, if it is supported by a > suitable TXT record in its forward domain.</para> > > <!-- The identity is transmitted in the IKE protocol, and is what is authenticated. --> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--host</option> <emphasis remap="I">ip-address</emphasis></term> > > <term><option>--host</option> <emphasis remap="B">%any</emphasis></term> > > <term><option>--host</option> <emphasis remap="B">%opportunistic</emphasis></term> > > <listitem> > <para>the IP address of the end (generally the public interface). > If <emphasis remap="B">pluto</emphasis> is to act as a responder > for IKE negotiations initiated from unknown IP addresses (the > âRoad Warriorâ case), the IP address should be specified as > <emphasis remap="B">%any</emphasis> (currently, the obsolete > notation <literal>0.0.0.0</literal> is also accepted for this). If > <emphasis remap="B">pluto</emphasis> is to opportunistically > initiate the connection, use <emphasis remap="B">%opportunistic</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--cert</option> <emphasis remap="I">filename</emphasis></term> > > <listitem> > <para>The filename of the X.509 certificate. This must be the > public key certificate only, and cannot be the PKCS#12 certificate > file. See <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> on how to extrac this from the PKCS#12 > file.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ca</option> <emphasis remap="I">distinguished > name</emphasis></term> > > <listitem> > <para>the X.509 Certificate Authority's Distinguished Name (DN) > used as trust anchor for this connection. This is the CA > certificate that signed the host certificate, as well as the > certificate of the incoming client.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--groups</option> <emphasis remap="I">access > control groups</emphasis></term> > > <listitem> > <para>the access control groups used.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--sendcert</option> <emphasis remap="I">yes|forced|always|ifasked|no|never</emphasis></term> > > <listitem> > <para>Wether or not to send our X.509 certificate credentials. > This could potentially give an attacker too much information about > which identities are allowed to connect to this host. The default > is to use <emphasis remap="B">ifasked</emphasis> when we are a > Responder, and to use <emphasis remap="B">yes</emphasis> (which is > the same as <emphasis remap="B">forced</emphasis> and <emphasis remap="B">always</emphasis> if we are an Initiator. The values > <emphasis remap="B">no</emphasis> and <emphasis remap="B">never</emphasis> are equivalent. NOTE: "forced" does not > seem to be actually implemented - do not use it.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--certtype</option> <emphasis remap="I">number</emphasis></term> > > <listitem> > <para>The X.509 certificate type number.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ikeport</option> <emphasis remap="I">port-number</emphasis></term> > > <listitem> > <para>the UDP port that IKE listens to on that host. The default > is 500. (<emphasis remap="B">pluto</emphasis> on this machine uses > the port specified by its own command line argument, so this only > affects where <emphasis remap="B">pluto</emphasis> sends > messages.)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--nexthop</option> <emphasis remap="I">ip-address</emphasis></term> > > <listitem> > <para>where to route packets for the peer's client (presumably for > the peer too, but it will not be used for this). When <emphasis remap="B">pluto</emphasis> installs an IPsec SA, it issues a route > command. It uses the nexthop as the gateway. The default is the > peer's IP address (this can be explicitly written as <emphasis remap="B">%direct</emphasis>; the obsolete notation > <literal>0.0.0.0</literal> is accepted). This option is necessary > if <emphasis remap="B">pluto</emphasis>'s host's interface used > for sending packets to the peer is neither point-to-point nor > directly connected to the peer.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--client</option> <emphasis remap="I">subnet</emphasis></term> > > <listitem> > <para>the subnet for which the IPsec traffic will be destined. If > not specified, the host will be the client. The subnet can be > specified in any of the forms supported by <citerefentry> > <refentrytitle>ipsec_atosubnet</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>. The general form is <emphasis remap="I">address</emphasis>/<emphasis remap="I">mask</emphasis>. > The <emphasis remap="I">address</emphasis> can be either a domain > name or four decimal numbers (specifying octets) separated by > dots. The most convenient form of the <emphasis remap="I">mask</emphasis> is a decimal integer, specifying the > number of leading one bits in the mask. So, for example, > 10.0.0.0/8 would specify the class A network âNet 10â.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--clientwithin</option> <emphasis remap="I">subnet</emphasis></term> > > <listitem> > <para>This option is obsolete and will be removed. Do not use this > option anymore.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--clientprotoport</option> <emphasis remap="I">protocol/port</emphasis></term> > > <listitem> > <para>specify the Port Selectors (filters) to be used on this > connection. The general form is <emphasis remap="I">protocol</emphasis>/<emphasis remap="I">port</emphasis>. > This is most commonly used to limit the connection to L2TP traffic > only by specifying a value of <emphasis remap="I">17/1701</emphasis> for UDP (protocol 17) and port 1701. > The notation <emphasis remap="I">17/%any</emphasis> can be used to > allow all UDP traffic and is needed for L2TP connections with > Windows XP machines before Service Pack 2.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--srcip</option> <emphasis remap="I">ip-address</emphasis></term> > > <listitem> > <para>the IP address for this host to use when transmitting a > packet to the remote IPsec gateway itself. This option is used to > make the gateway itself use its internal IP, which is part of the > <option>--client subnet</option>. Otherwise it will use its > nearest IP address, which is its public IP address, which is not > part of the subnet-subnet IPsec tunnel, and would therefor not get > encrypted.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthserver</option></term> > > <listitem> > <para>this end is an xauthserver. It will lookup the xauth user > name and password and verify this before allowing the connection > to get established.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthclient</option></term> > > <listitem> > <para>this end is an xauthclient. To bring this connection up with > the <option>--initiate</option> also requires the client to > specify <option>--xauthuser username</option> and > <option>--xauthpass password </option></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthuser</option></term> > > <listitem> > <para>The username for the xauth authentication.This option is > normally passed along by <citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> when an xauth connection is started using > <emphasis remap="I">ipsec auto --up conn</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--xauthpass</option></term> > > <listitem> > <para>The password for the xauth authentication. This option is > normally passed along by <citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> when an xauth connection is started using > <emphasis remap="I">ipsec auto --up conn</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgserver</option></term> > > <listitem> > <para>this end is an Mode Config server</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgclient</option></term> > > <listitem> > <para>this end is an Mode Config client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgdns1</option></term> > > <listitem> > <para>The IP address of the first DNS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgdns2</option></term> > > <listitem> > <para>The IP address of the second DNS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgwins1</option></term> > > <listitem> > <para>The IP address of the first WINS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgwins2</option></term> > > <listitem> > <para>The IP address of the second WINS server to pass along to the ModeConfig Client</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dnskeyondemand</option></term> > > <listitem> > <para>specifies that when an RSA public key is needed to > authenticate this host, and it isn't already known, fetch it from > DNS.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--updown</option> <emphasis remap="I">updown</emphasis></term> > > <listitem> > <para>specifies an external shell command to be run whenever > <emphasis remap="B">pluto</emphasis> brings up or down a > connection. The script is used to build a shell command, so it may > contain positional parameters, but ought not to have punctuation > that would cause the resulting command to be ill-formed. The > default is <emphasis remap="I">ipsec _updown</emphasis>. Pluto > passes a dozen environment variables to the script about the > connection involved.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--to</option></term> > > <listitem> > <para>separates the specification of the left and right ends of > the connection. Pluto tries to decide wether it is <emphasis remap="I">left</emphasis> or <emphasis remap="I">right</emphasis> > based on the information provided on both sides of this > option.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The potential connection description also specifies > characteristics of rekeying and security.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--psk</option></term> > > <listitem> > <para>Propose and allow preshared secret authentication for IKE > peers. This authentication requires that each side use the same > secret. May be combined with <option>--rsasig</option>; at least > one must be specified.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--rsasig</option></term> > > <listitem> > <para>Propose and allow RSA signatures for authentication of IKE > peers. This authentication requires that each side have have a > private key of its own and know the public key of its peer. May be > combined with <option>--psk</option>; at least one must be > specified.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--encrypt</option></term> > > <listitem> > <para>All proposed or accepted IPsec SAs will include non-null > ESP. The actual choices of transforms are wired into <emphasis remap="B">pluto</emphasis>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--authenticate</option></term> > > <listitem> > <para>All proposed IPsec SAs will include AH. All accepted IPsec > SAs will include AH or ESP with authentication. The actual choices > of transforms are wired into <emphasis remap="B">pluto</emphasis>. > Note that this has nothing to do with IKE authentication.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--compress</option></term> > > <listitem> > <para>All proposed IPsec SAs will include IPCOMP (compression). > This will be ignored if KLIPS is not configured with IPCOMP > support.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--tunnel</option></term> > > <listitem> > <para>the IPsec SA should use tunneling. Implicit if the SA is for > clients. Must only be used with <option>--authenticate</option> or > <option>--encrypt</option>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ipv4</option></term> > > <listitem> > <para>The host addresses will be interpreted as IPv4 addresses. > This is the default. Note that for a connection, all host > addresses must be of the same Address Family (IPv4 and IPv6 use > different Address Families).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ipv6</option></term> > > <listitem> > <para>The host addresses (including nexthop) will be interpreted > as IPv6 addresses. Note that for a connection, all host addresses > must be of the same Address Family (IPv4 and IPv6 use different > Address Families).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--tunnelipv4</option></term> > > <listitem> > <para>The client addresses will be interpreted as IPv4 addresses. > The default is to match what the host will be. This does not imply > <option>--tunnel</option> so the flag can be safely used when no > tunnel is actually specified. Note that for a connection, all > tunnel addresses must be of the same Address Family.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--tunnelipv6</option></term> > > <listitem> > <para>The client addresses will be interpreted as IPv6 addresses. > The default is to match what the host will be. This does not imply > <option>--tunnel</option> so the flag can be safely used when no > tunnel is actually specified. Note that for a connection, all > tunnel addresses must be of the same Address Family.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pfs</option></term> > > <listitem> > <para>There should be Perfect Forward Secrecy - new keying > material will be generated for each IPsec SA rather than being > derived from the ISAKMP SA keying material. Since the group to be > used cannot be negotiated (a dubious feature of the standard), > <emphasis remap="B">pluto</emphasis> will propose the same group > that was used during Phase 1. We don't implement a stronger form > of PFS which would require that the ISAKMP SA be deleted after the > IPSEC SA is negotiated.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pfsgroup</option> <emphasis remap="I">modp-group</emphasis></term> > > <listitem> > <para>Sets the Diffie-Hellman group used. Currently the following > values are supported: <emphasis remap="B">modp1024</emphasis> > (DHgroup 2), <emphasis remap="B">modp1536</emphasis> (DHgroup 5), > <emphasis remap="B">modp2048</emphasis> (DHgroup 14), <emphasis remap="B">modp3072</emphasis> (DHgroup 15), <emphasis remap="B">modp4096</emphasis> (DHgroup 16), <emphasis remap="B">modp6144</emphasis> (DHgroup 17), and <emphasis remap="B">modp8192</emphasis> (DHgroup 18). It is possible to > support the weak and broken <emphasis remap="B">modp768</emphasis> > (DHgroup 1), but this requires a manual recompile and is strongly > discouraged.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--disablearrivalcheck</option></term> > > <listitem> > <para>If the connection is a tunnel, allow packets arriving > through the tunnel to have any source and destination > addresses.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--esp</option> <emphasis remap="I">esp-algos</emphasis></term> > > <listitem> > <para>ESP encryption/authentication algorithm to be used for the > connection (phase2 aka IPsec SA). The options must be suitable as > a value of <citerefentry> > <refentrytitle>ipsec_spi</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>. See <citerefentry> > <refentrytitle>ipsec.conf</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> for a detailed description of the algorithm > format.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--aggrmode</option></term> > > <listitem> > <para>This tunnel is using aggressive mode ISAKMP negotiation. The > default is main mode. Aggressive mode is less secure than main > mode as it reveals your identity to an eavesdropper, but is needed > to support road warriors using PSK keys or to interoperate with > other buggy implementations insisting on using aggressive > mode.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--modecfgpull</option></term> > > <listitem> > <para>Pull the Mode Config network information from the > peer.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dpddelay</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>Set the delay (in seconds) between Dead Peer Dectection (RFC > 3706) keepalives (R_U_THERE, R_U_THERE_ACK) that are sent for this > connection (default 30 seconds).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--timeout</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>Set the length of time (in seconds) we will idle without > hearing either an R_U_THERE poll from our peer, or an > R_U_THERE_ACK reply. After this period has elapsed with no > response and no traffic, we will declare the peer dead, and remove > the SA (default 120 seconds).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dpdaction</option> <emphasis remap="I">action</emphasis></term> > > <listitem> > <para>When a DPD enabled peer is declared dead, what action should > be taken. <emphasis remap="B">hold</emphasis>(default) means the > eroute will be put into <emphasis remap="I">%hold</emphasis> > status, while <emphasis remap="B">clear</emphasis>means the eroute > and SA with both be cleared. Clear is really only usefull on the > server of a Road Warrior config. The action <emphasis remap="B">restart</emphasis> is used on tunnels that need to be > permanently up, and have static IP addresses.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--forceencaps</option></term> > > <listitem> > <para>In some cases, for example when ESP packets are filtered or > when a broken IPsec peer does not properly recognise NAT, it can > be useful to force RFC-3948 encapsulation using this option. It > causes pluto lie and tell the remote peer that RFC-3948 > encapsulation (ESP in UDP port 4500 packets) is required. For this > option to have any effect, pluto must have been started with the > <option>--nat_traversal</option> option.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>If none of the <option>--encrypt</option>, > <option>--authenticate</option>, <option>--compress</option>, or > <option>--pfs</option> flags is given, the initiating the connection > will only build an ISAKMP SA. For such a connection, client subnets have > no meaning and must not be specified.</para> > > <para>Apart from initiating directly using the > <option>--initiate</option> option, a tunnel can be loaded with a > different policy</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--initiateontraffic</option></term> > > <listitem> > <para>Only initiate the connection when we have traffic to send > over the connection</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pass</option></term> > > <listitem> > <para>Allow <emphasis remap="B">unencrypted</emphasis> traffic to > flow until the tunnel is initiated.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--drop</option></term> > > <listitem> > <para>Drop unencrypted traffic silently.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--reject</option></term> > > <listitem> > <para>Drop unencrypted traffic silently, but send an ICMP message > notifying the other end.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>These options need to be documented</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--failnone</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--failpass</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--faildrop</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--failreject</option></term> > > <listitem> > <para>to be documented</para> > </listitem> > </varlistentry> > </variablelist> > > <para><emphasis remap="B">pluto</emphasis> supports various X.509 > Certificate related options.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--utc</option></term> > > <listitem> > <para>display all times in UTC.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listall</option></term> > > <listitem> > <para>lists all of the X.509 information known to pluto.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listpubkeys</option></term> > > <listitem> > <para>list all the public keys that have been successfully > loaded.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcerts</option></term> > > <listitem> > <para>list all the X.509 certificates that are currently > loaded.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcacerts</option></term> > > <listitem> > <para>list all the X.509 Certificate Agency (CA) certificates that > are currently loaded.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listacerts</option></term> > > <listitem> > <para>list all the X.509 Attribute certificates that are currently > loaded</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listaacerts</option></term> > > <listitem> > <para/> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ocspcerts</option></term> > > <listitem> > <para>list all of the X.509 certificates obtained via the > <emphasis remap="I">Online Certificate Store Protocol</emphasis> > (OCSP)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listgroups</option></term> > > <listitem> > <para/> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcrls</option></term> > > <listitem> > <para>list all the loaded <emphasis remap="I">Certificate > Revocation Lists</emphasis> (CRLs)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--listcards</option></term> > > <listitem> > <para>list all the smartcard and USB token devices.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The corresponding options <option>--rereadsecrets</option>, > <option>--rereadall</option>, <option>--rereadcacerts</option>, > <option>--rereadacerts</option>, <option>--rereadaacerts</option>, > <option>--rereadocspcerts</option> <option>--rereadcrls</option>, and > <option>--purgeocsp</option>, options reread this information from their > respective sources, and purge all the online obtained information. The > option <option>--listevents</option> lists all pending CRL fetch > commands.</para> > > <para>More work is needed to allow for flexible policies. Currently > policy is hardwired in the source file spdb.c. The ISAKMP SAs may use > Oakley groups MODP1024 and MODP1536; AES or 3DES encryption; SHA1-96 and > MD5-96 authentication. The IPsec SAs may use AES or 3DES and MD5-96 or > SHA1-96 for ESP, or just MD5-96 or SHA1-96 for AH. IPCOMP Compression is > always Deflate.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--ikelifetime</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>how long <emphasis remap="B">pluto</emphasis> will propose > that an ISAKMP SA be allowed to live. The default is 3600 (one > hour) and the maximum is 86400 (1 day). This option will not > affect what is accepted. <emphasis remap="B">pluto</emphasis> will > reject proposals that exceed the maximum.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ipseclifetime</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>how long <emphasis remap="B">pluto</emphasis> will propose > that an IPsec SA be allowed to live. The default is 28800 (eight > hours) and the maximum is 86400 (one day). This option will not > affect what is accepted. <emphasis remap="B">pluto</emphasis> will > reject proposals that exceed the maximum.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--rekeymargin</option> <emphasis remap="I">seconds</emphasis></term> > > <listitem> > <para>how long before an SA's expiration should <emphasis remap="B">pluto</emphasis> try to negotiate a replacement SA. This > will only happen if <emphasis remap="B">pluto</emphasis> was the > initiator. The default is 540 (nine minutes).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--rekeyfuzz</option> <emphasis remap="I">percentage</emphasis></term> > > <listitem> > <para>maximum size of random component to add to rekeymargin, > expressed as a percentage of rekeymargin. <emphasis remap="B">pluto</emphasis> will select a delay uniformly > distributed within this range. By default, the percentage will be > 100. If greater determinism is desired, specify 0. It may be > appropriate for the percentage to be much larger than 100.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--keyingtries</option> <emphasis remap="I">count</emphasis></term> > > <listitem> > <para>how many times <emphasis remap="B">pluto</emphasis> should > try to negotiate an SA, either for the first time or for rekeying. > A value of 0 is interpreted as a very large number: never give up. > The default is three.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--dontrekey</option></term> > > <listitem> > <para>A misnomer. Only rekey a connection if we were the Initiator > and there was recent traffic on the existing connection. This > applies to Phase 1 and Phase 2. This is currently the only > automatic way for a connection to terminate. It may be useful with > Road Warrior or Opportunistic connections. <!-- .br --> Since SA > lifetime negotiation is take-it-or-leave it, a Responder normally > uses the shorter of the negotiated or the configured lifetime. > This only works because if the lifetime is shorter than > negotiated, the Responder will rekey in time so that everything > works. This interacts badly with <option>--dontrekey</option>. In > this case, the Responder will end up rekeying to rectify a > shortfall in an IPsec SA lifetime; for an ISAKMP SA, the Responder > will accept the negotiated lifetime.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--delete</option></term> > > <listitem> > <para>when used in the connection form, it causes any previous > connection with this name to be deleted before this one is added. > Unlike a normal delete, no diagnostic is produced if there was no > previous connection to delete. Any routing in place for the > connection is undone.</para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--delete</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>The delete form deletes a named connection description and > any SAs established or negotiations initiated using this > connection. Any routing in place for the connection is > undone.</para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--deletestate</option> <emphasis remap="I">state-number</emphasis></term> > > <listitem> > <para>The deletestate form deletes the state object with the > specified serial number. This is useful for selectively deleting > instances of connections.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The route form of the <emphasis remap="B">whack</emphasis> command > tells <emphasis remap="B">pluto</emphasis> to set up routing for a > connection. Although like a traditional route, it uses an ipsec device > as a virtual interface. Once routing is set up, no packets will be sent > âin the clearâ to the peer's client specified in the connection. A TRAP > shunt eroute will be installed; if outbound traffic is caught, Pluto > will initiate the connection. An explicit <emphasis remap="B">whack</emphasis> route is not always needed: if it hasn't been > done when an IPsec SA is being installed, one will be automatically > attempted.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--route</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>When a routing is attempted for a connection, there must not > already be a routing for a different connection with the same > subnet but different interface or destination, or if there is, it > must not be being used by an IPsec SA. Otherwise the attempt will > fail.</para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--unroute</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <listitem> > <para>The unroute form of the <emphasis remap="B">whack</emphasis> > command tells <emphasis remap="B">pluto</emphasis> to undo a > routing. <emphasis remap="B">pluto</emphasis> will refuse if an > IPsec SA is using the connection. If another connection is sharing > the same routing, it will be left in place. Without a routing, > packets will be sent without encryption or authentication.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The initiate form tells <emphasis remap="B">pluto</emphasis> to > initiate a negotiation with another <emphasis remap="B">pluto</emphasis> > (or other IKE daemon) according to the named connection. Initiation > requires a route that <option>--route</option> would provide; if none is > in place at the time an IPsec SA is being installed, <emphasis remap="B">pluto</emphasis> attempts to set one up.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--initiate</option></term> > > <term><option>--name</option> <emphasis remap="I">connection-name</emphasis></term> > > <term><option>--asynchronous</option></term> > > <listitem> > <para>The initiate form of the <emphasis remap="B">whack</emphasis> command will relay back from <emphasis remap="B">pluto</emphasis> status information via the UNIX domain > socket (unless --asynchronous is specified). The status > information is meant to look a bit like that from <emphasis remap="B">FTP</emphasis>. Currently <emphasis remap="B">whack</emphasis> simply copies this to stderr. When the > request is finished (eg. the SAs are established or <emphasis remap="B">pluto</emphasis> gives up), <emphasis remap="B">pluto</emphasis> closes the channel, causing <emphasis remap="B">whack</emphasis> to terminate.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The opportunistic initiate form is mainly used for > debugging.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--tunnelipv4</option></term> > > <term><option>--tunnelipv6</option></term> > > <term><option>--oppohere</option> <emphasis remap="I">ip-address</emphasis></term> > > <term><option>--oppothere</option> <emphasis remap="I">ip-address</emphasis></term> > > <listitem> > <para>This will cause <emphasis remap="B">pluto</emphasis> to > attempt to opportunistically initiate a connection from here to > the there, even if a previous attempt had been made. The whack log > will show the progress of this attempt.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>Ending an connection</para> > > <variablelist remap="tp"> > <varlistentry> > <term><option>--terminate</option></term> > > <term><option>--name</option> <emphasis remap="i">connection-name</emphasis></term> > > <listitem> > <para>the terminate form tells <emphasis remap="b">pluto</emphasis> to delete any sas that use the > specified connection and to stop any negotiations in process. it > does not prevent new negotiations from starting (the delete form > has this effect).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--crash</option> <emphasis remap="i">ip-address</emphasis></term> > > <listitem> > <para>If the remote peer has crashed, and therefor did not notify > us, we keep sending encrypted traffic, and rejecting all plaintext > (non-IKE) traffic from that remote peer. The > <option>--crash</option> brings our end down as well for all the > known connections to the specified <emphasis remap="i">ip-address</emphasis></para> > </listitem> > </varlistentry> > </variablelist> > > <variablelist remap="tp"> > <varlistentry> > <term><option>--whackrecord</option><emphasis remap="i">filename</emphasis></term> > > <term><option>--whackstoprecord</option></term> > > <listitem> > <para>this causes <emphasis remap="b">pluto</emphasis>to open the > given filename for write, and record each of the messages received > from whack or addconn. This continues until the whackstoprecord > option is used. This option may not be combined with any other > command. The start/stop commands are not recorded themselves. > These files are usually used to create input files for unit tests, > particularly for complex setups where policies may in fact > overlap. </para> > > <para>The format of the file consists of a line starting with > #!pluto-whack and the date that the file was started, as well as > the hostname, and a linefeed. What follows are binary format > records consisting of a 32-bit record length in bytes, (including > the length record itself), a 64-bit timestamp, and then the > literal contents of the whack message that was received. All > integers are in host format. In order to unambigously determine > the host order, the first record is an empty record that contains > only the current WHACK_MAGIC value. This record is 16 bytes > long.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="i">ip-address</emphasis></term> > > <listitem> > <para>If the remote peer has crashed, and therefor did not notify > us, we keep sending encrypted traffic, and rejecting all plaintext > (non-IKE) traffic from that remote peer. The > <option>--crash</option> brings our end down as well for all the > known connections to the specified <emphasis remap="i">ip-address</emphasis></para> > </listitem> > </varlistentry> > </variablelist> > > <para>The public key for informs <emphasis remap="B">pluto</emphasis> of > the RSA public key for a potential peer. Private keys must be kept > secret, so they are kept in <citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry>.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--keyid </option><replaceable>id</replaceable></term> > > <listitem> > <para>specififies the identity of the peer for which a public key > should be used. Its form is identical to the identity in the > connection. If no public key is specified, <emphasis remap="B">pluto</emphasis> attempts to find KEY records from DNS > for the id (if a FQDN) or through reverse lookup (if an IP > address). Note that there several interesting ways in which this > is not secure.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--addkey</option></term> > > <listitem> > <para>specifies that the new key is added to the collection; > otherwise the new key replaces any old ones.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--pubkeyrsa </option><replaceable>key</replaceable></term> > > <listitem> > <para>specifies the value of the RSA public key. It is a sequence > of bytes as described in RFC 2537 âRSA/MD5 KEYs and SIGs in the > Domain Name System (DNS)â. It is denoted in a way suitable for > <citerefentry> > <refentrytitle>ipsec_ttodata</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>. For example, a base 64 numeral starts with > 0s.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The listen form tells <emphasis remap="B">pluto</emphasis> to > start listening for IKE requests on its public interfaces. To avoid race > conditions, it is normal to load the appropriate connections into > <emphasis remap="B">pluto</emphasis> before allowing it to listen. If > <emphasis remap="B">pluto</emphasis> isn't listening, it is pointless to > initiate negotiations, so it will refuse requests to do so. Whenever the > listen form is used, <emphasis remap="B">pluto</emphasis> looks for > public interfaces and will notice when new ones have been added and when > old ones have been removed. This is also the trigger for <emphasis remap="B">pluto</emphasis> to read the <emphasis remap="I">ipsec.secrets</emphasis> file. So listen may useful more than > once.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--listen</option></term> > > <listitem> > <para>start listening for IKE traffic on public interfaces.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--unlisten</option></term> > > <listitem> > <para>stop listening for IKE traffic on public interfaces.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The status form will display information about the internal state > of <emphasis remap="B">pluto</emphasis>: information about each > potential connection, about each state object, and about each shunt that > <emphasis remap="B">pluto</emphasis> is managing without an associated > connection.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--status</option></term> > > <listitem> > <para/> > > <!-- FIXME: blank list item --> > </listitem> > </varlistentry> > </variablelist> > > <para>The shutdown form is the proper way to shut down <emphasis remap="B">pluto</emphasis>. It will tear down the SAs on this machine > that <emphasis remap="B">pluto</emphasis> has negotiated. It does not > inform its peers, so the SAs on their machines remain.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--shutdown</option></term> > > <listitem> > <para/> > > <!-- FIXME: blank list item --> > </listitem> > </varlistentry> > </variablelist> > </refsect2> > > <refsect2 id="examples"> > <title>Examples</title> > > <para>It would be normal to start <emphasis remap="B">pluto</emphasis> > in one of the system initialization scripts. It needs to be run by the > superuser. Generally, no arguments are needed. To run in manually, the > superuser can simply type</para> > > <para> ipsec pluto</para> > > <para>The command will immediately return, but a <emphasis remap="B">pluto</emphasis> process will be left running, waiting for > requests from <emphasis remap="B">whack</emphasis> or a peer.</para> > > <para>Using <emphasis remap="B">whack</emphasis>, several potential > connections would be described:</para> > > <!-- .na --> > > <para> ipsec whack --name silly > --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 > --ipseclifetime 800 --keyingtries 3</para> > > <!-- .ad --> > > <para>Since this silly connection description specifies neither > encryption, authentication, nor tunneling, it could only be used to > establish an ISAKMP SA.</para> > > <!-- .na --> > > <para> ipsec whack --name secret > --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 > --client 10.0.2.0/24 --encrypt</para> > > <!-- .ad --> > > <para>This is something that must be done on both sides. If the other > side is <emphasis remap="B">pluto</emphasis>, the same <emphasis remap="B">whack</emphasis> command could be used on it (the command > syntax is designed to not distinguish which end is ours).</para> > > <para>Now that the connections are specified, <emphasis remap="B">pluto</emphasis> is ready to handle requests and replies via > the public interfaces. We must tell it to discover those interfaces and > start accepting messages from peers:</para> > > <para> ipsec whack --listen</para> > > <para>If we don't immediately wish to bring up a secure connection > between the two clients, we might wish to prevent insecure traffic. The > routing form asks <emphasis remap="B">pluto</emphasis> to cause the > packets sent from our client to the peer's client to be routed through > the ipsec0 device; if there is no SA, they will be discarded:</para> > > <para> ipsec whack --route secret</para> > > <para>Finally, we are ready to get <emphasis remap="B">pluto</emphasis> > to initiate negotiation for an IPsec SA (and implicitly, an ISAKMP > SA):</para> > > <para> ipsec whack > --initiate --name secret</para> > > <para>A small log of interesting events will appear on standard output > (other logging is sent to syslog).</para> > > <para><emphasis remap="B">whack</emphasis> can also be used to terminate > <emphasis remap="B">pluto</emphasis> cleanly, tearing down all SAs that > it has negotiated.</para> > > <para> ipsec whack --shutdown</para> > > <para>Notification of any IPSEC SA deletion, but not ISAKMP SA deletion > is sent to the peer. Unfortunately, such Notification is not reliable. > Furthermore, <emphasis remap="B">pluto</emphasis> itself ignores > Notifications.</para> > </refsect2> > > <refsect2 id="xauth"> > <title>XAUTH</title> > > <para>If <emphasis remap="B">pluto</emphasis> needs additional > authentication, such as defined by the XAUTH specifications, then it may > ask <emphasis remap="B">whack</emphasis> to prompt the operator for > username or passwords. Typically, these will be entered interactively. A > GUI that wraps around <emphasis remap="B">whack</emphasis> may look for > the 041 (username) or 040 (password) prompts, and display them to the > user.</para> > > <para>For testing purposes, the options > <option>--xauthuser </option><replaceable>user</replaceable> > <option>--xauthpass </option><replaceable>pass</replaceable> may be > be given prior to the <option>--initiate </option> to provide > responses to the username and password prompts.</para> > </refsect2> > > <refsect2 id="the_updown_command"> > <title>The updown command</title> > > <para>Whenever <emphasis remap="B">pluto</emphasis> brings a connection > up or down, it invokes the updown command. This command is specified > using the <option>--updown</option> option. This allows for customized > control over routing and firewall manipulation.</para> > > <para>The updown is invoked for five different operations. Each of these > operations can be for our client subnet or for our host itself.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><emphasis remap="B">prepare-host</emphasis> or <emphasis remap="B">prepare-client</emphasis></term> > > <listitem> > <para>is run before bringing up a new connection if no other > connection with the same clients is up. Generally, this is useful > for deleting a route that might have been set up before <emphasis remap="B">pluto</emphasis> was run or perhaps by some agent not > known to <emphasis remap="B">pluto</emphasis>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">route-host</emphasis> or <emphasis remap="B">route-client</emphasis></term> > > <listitem> > <para>is run when bringing up a connection for a new peer client > subnet (even if <emphasis remap="B">prepare-host</emphasis> or > <emphasis remap="B">prepare-client</emphasis> was run). The > command should install a suitable route. Routing decisions are > based only on the destination (peer's client) subnet address, > unlike eroutes which discriminate based on source too.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">unroute-host</emphasis> or <emphasis remap="B">unroute-client</emphasis></term> > > <listitem> > <para>is run when bringing down the last connection for a > particular peer client subnet. It should undo what the <emphasis remap="B">route-host</emphasis> or <emphasis remap="B">route-client</emphasis> did.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">up-host</emphasis> or <emphasis remap="B">up-client</emphasis></term> > > <listitem> > <para>is run when bringing up a tunnel eroute with a pair of > client subnets that does not already have a tunnel eroute. This > command should install firewall rules as appropriate. It is > generally a good idea to allow IKE messages (UDP port 500) travel > between the hosts.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">down-host</emphasis> or <emphasis remap="B">down-client</emphasis></term> > > <listitem> > <para>is run when bringing down the eroute for a pair of client > subnets. This command should delete firewall rules as appropriate. > Note that there may remain some inbound IPsec SAs with these > client subnets.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The script is passed a large number of environment variables to > specify what needs to be done.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><emphasis remap="B">PLUTO_VERSION</emphasis></term> > > <listitem> > <para>indicates what version of this interface is being used. This > document describes version 1.1. This is upwardly compatible with > version 1.0.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_VERB</emphasis></term> > > <listitem> > <para>specifies the name of the operation to be performed > (<emphasis remap="B">prepare-host</emphasis>,r <emphasis remap="B">prepare-client</emphasis>, <emphasis remap="B">up-host</emphasis>, <emphasis remap="B">up-client</emphasis>, <emphasis remap="B">down-host</emphasis>, or <emphasis remap="B">down-client</emphasis>). If the address family for > security gateway to security gateway communications is IPv6, then > a suffix of -v6 is added to the verb.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_CONNECTION</emphasis></term> > > <listitem> > <para>is the name of the connection for which we are > routing.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_NEXT_HOP</emphasis></term> > > <listitem> > <para>is the next hop to which packets bound for the peer must be > sent.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_INTERFACE</emphasis></term> > > <listitem> > <para>is the name of the ipsec interface to be used.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_ME</emphasis></term> > > <listitem> > <para>is the IP address of our host.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_CLIENT</emphasis></term> > > <listitem> > <para>is the IP address / count of our client subnet. If the > client is just the host, this will be the host's own IP address / > max (where max is 32 for IPv4 and 128 for IPv6).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_CLIENT_NET</emphasis></term> > > <listitem> > <para>is the IP address of our client net. If the client is just > the host, this will be the host's own IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_CLIENT_MASK</emphasis></term> > > <listitem> > <para>is the mask for our client net. If the client is just the > host, this will be 255.255.255.255.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER</emphasis></term> > > <listitem> > <para>is the IP address of our peer.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CLIENT</emphasis></term> > > <listitem> > <para>is the IP address / count of the peer's client subnet. If > the client is just the peer, this will be the peer's own IP > address / max (where max is 32 for IPv4 and 128 for IPv6).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CLIENT_NET</emphasis></term> > > <listitem> > <para>is the IP address of the peer's client net. If the client is > just the peer, this will be the peer's own IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CLIENT_MASK</emphasis></term> > > <listitem> > <para>is the mask for the peer's client net. If the client is just > the peer, this will be 255.255.255.255.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_PROTOCOL</emphasis></term> > > <listitem> > <para>lists the protocols allowed over this IPsec SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_PROTOCOL</emphasis></term> > > <listitem> > <para>lists the protocols the peer allows over this IPsec > SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_PORT</emphasis></term> > > <listitem> > <para>lists the ports allowed over this IPsec SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_PORT</emphasis></term> > > <listitem> > <para>lists the ports the peer allows over this IPsec SA.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_MY_ID</emphasis></term> > > <listitem> > <para>lists our id.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_ID</emphasis></term> > > <listitem> > <para>Dlists our peer's id.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><emphasis remap="B">PLUTO_PEER_CA</emphasis></term> > > <listitem> > <para>lists the peer's CA.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>All output sent by the script to stderr or stdout is logged. The > script should return an exit status of 0 if and only if it > succeeds.</para> > > <para><emphasis remap="B">Pluto</emphasis> waits for the script to > finish and will not do any other processing while it is waiting. The > script may assume that <emphasis remap="B">pluto</emphasis> will not > change anything while the script runs. The script should avoid doing > anything that takes much time and it should not issue any command that > requires processing by <emphasis remap="B">pluto</emphasis>. Either of > these activities could be performed by a background subprocess of the > script.</para> > </refsect2> > > <refsect2 id="rekeying"> > <title>Rekeying</title> > > <para>When an SA that was initiated by <emphasis remap="B">pluto</emphasis> has only a bit of lifetime left, <emphasis remap="B">pluto</emphasis> will initiate the creation of a new SA. This > applies to ISAKMP and IPsec SAs. The rekeying will be initiated when the > SA's remaining lifetime is less than the rekeymargin plus a random > percentage, between 0 and rekeyfuzz, of the rekeymargin.</para> > > <para>Similarly, when an SA that was initiated by the peer has only a > bit of lifetime left, <emphasis remap="B">pluto</emphasis> will try to > initiate the creation of a replacement. To give preference to the > initiator, this rekeying will only be initiated when the SA's remaining > lifetime is half of rekeymargin. If rekeying is done by the responder, > the roles will be reversed: the responder for the old SA will be the > initiator for the replacement. The former initiator might also initiate > rekeying, so there may be redundant SAs created. To avoid these > complications, make sure that rekeymargin is generous.</para> > > <para>One risk of having the former responder initiate is that perhaps > none of its proposals is acceptable to the former initiator (they have > not been used in a successful negotiation). To reduce the chances of > this happening, and to prevent loss of security, the policy settings are > taken from the old SA (this is the case even if the former initiator is > initiating). These may be stricter than those of the connection.</para> > > <para><emphasis remap="B">pluto</emphasis> will not rekey an SA if that > SA is not the most recent of its type (IPsec or ISAKMP) for its > potential connection. This avoids creating redundant SAs.</para> > > <para>The random component in the rekeying time (rekeyfuzz) is intended > to make certain pathological patterns of rekeying unstable. If both > sides decide to rekey at the same time, twice as many SAs as necessary > are created. This could become a stable pattern without the > randomness.</para> > > <para>Another more important case occurs when a security gateway has SAs > with many other security gateways. Each of these connections might need > to be rekeyed at the same time. This would cause a high peek requirement > for resources (network bandwidth, CPU time, entropy for random numbers). > The rekeyfuzz can be used to stagger the rekeying times.</para> > > <para>Once a new set of SAs has been negotiated, <emphasis remap="B">pluto</emphasis> will never send traffic on a superseded one. > Traffic will be accepted on an old SA until it expires.</para> > </refsect2> > > <refsect2 id="selecting_a_connection_when_responding_r"> > <title>Selecting a Connection When Responding: Road Warrior > Support</title> > > <para>When <emphasis remap="B">pluto</emphasis> receives an initial Main > Mode message, it needs to decide which connection this message is for. > It picks based solely on the source and destination IP addresses of the > message. There might be several connections with suitable IP addresses, > in which case one of them is arbitrarily chosen. (The ISAKMP SA proposal > contained in the message could be taken into account, but it is > not.)</para> > > <para>The ISAKMP SA is negotiated before the parties pass further > identifying information, so all ISAKMP SA characteristics specified in > the connection description should be the same for every connection with > the same two host IP addresses. At the moment, the only characteristic > that might differ is authentication method.</para> > > <para>Up to this point, all configuring has presumed that the IP > addresses are known to all parties ahead of time. This will not work > when either end is mobile (or assigned a dynamic IP address for other > reasons). We call this situation âRoad Warriorâ. It is fairly tricky and > has some important limitations, most of which are features of the IKE > protocol.</para> > > <para>Only the initiator may be mobile: the initiator may have an IP > number unknown to the responder. When the responder doesn't recognize > the IP address on the first Main Mode packet, it looks for a connection > with itself as one end and <emphasis remap="B">%any</emphasis> as the > other. If it cannot find one, it refuses to negotiate. If it does find > one, it creates a temporary connection that is a duplicate except with > the <emphasis remap="B">%any</emphasis> replaced by the source IP > address from the packet; if there was no identity specified for the > peer, the new IP address will be used.</para> > > <para>When <emphasis remap="B">pluto</emphasis> is using one of these > temporary connections and needs to find the preshared secret or RSA > private key in <emphasis remap="I">ipsec.secrets</emphasis>, and and the > connection specified no identity for the peer, <emphasis remap="B">%any</emphasis> is used as its identity. After all, the real > IP address was apparently unknown to the configuration, so it is > unreasonable to require that it be used in this table.</para> > > <para>Part way into the Phase 1 (Main Mode) negotiation using one of > these temporary connection descriptions, <emphasis remap="B">pluto</emphasis> will be receive an Identity Payload. At this > point, <emphasis remap="B">pluto</emphasis> checks for a more > appropriate connection, one with an identity for the peer that matches > the payload but which would use the same keys so-far used for > authentication. If it finds one, it will switch to using this better > connection (or a temporary derived from this, if it has <emphasis remap="B">%any</emphasis> for the peer's IP address). It may even turn > out that no connection matches the newly discovered identity, including > the current connection; if so, <emphasis remap="B">pluto</emphasis> > terminates negotiation.</para> > > <para>Unfortunately, if preshared secret authentication is being used, > the Identity Payload is encrypted using this secret, so the secret must > be selected by the responder without knowing this payload. This limits > there to being at most one preshared secret for all Road Warrior systems > connecting to a host. RSA Signature authentications does not require > that the responder know how to select the initiator's public key until > after the initiator's Identity Payload is decoded (using the responder's > private key, so that must be preselected).</para> > > <para>When <emphasis remap="B">pluto</emphasis> is responding to a Quick > Mode negotiation via one of these temporary connection descriptions, it > may well find that the subnets specified by the initiator don't match > those in the temporary connection description. If so, it will look for a > connection with matching subnets, its own host address, a peer address > of <emphasis remap="B">%any</emphasis> and matching identities. If it > finds one, a new temporary connection is derived from this one and used > for the Quick Mode negotiation of IPsec SAs. If it does not find one, > <emphasis remap="B">pluto</emphasis> terminates negotiation.</para> > > <para>Be sure to specify an appropriate nexthop for the responder to > send a message to the initiator: <emphasis remap="B">pluto</emphasis> > has no way of guessing it (if forwarding isn't required, use an explicit > <emphasis remap="B">%direct</emphasis> as the nexthop and the IP address > of the initiator will be filled in; the obsolete notation > <literal>0.0.0.0</literal> is still accepted).</para> > > <para><emphasis remap="B">pluto</emphasis> has no special provision for > the initiator side. The current (possibly dynamic) IP address and > nexthop must be used in defining connections. These must be properly > configured each time the initiator's IP address changes. <emphasis remap="B">pluto</emphasis> has no mechanism to do this > automatically.</para> > > <para>Although we call this Road Warrior Support, it could also be used > to support encrypted connections with anonymous initiators. The > responder's organization could announce the preshared secret that would > be used with unrecognized initiators and let anyone connect. Of course > the initiator's identity would not be authenticated.</para> > > <para>If any Road Warrior connections are supported, <emphasis remap="B">pluto</emphasis> cannot reject an exchange initiated by an > unknown host until it has determined that the secret is not shared or > the signature is invalid. This must await the third Main Mode message > from the initiator. If no Road Warrior connection is supported, the > first message from an unknown source would be rejected. This has > implications for ease of debugging configurations and for denial of > service attacks.</para> > > <para>Although a Road Warrior connection must be initiated by the mobile > side, the other side can and will rekey using the temporary connection > it has created. If the Road Warrior wishes to be able to disconnect, it > is probably wise to set <option>--keyingtries</option> to 1 in the > connection on the non-mobile side to prevent it trying to rekey the > connection. Unfortunately, there is no mechanism to unroute the > connection automatically.</para> > </refsect2> > > <refsect2 id="debugging"> > <title>Debugging</title> > > <para><emphasis remap="B">pluto</emphasis> accepts several optional > arguments, useful mostly for debugging. Except for > <option>--interface</option>, each should appear at most once.</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--interface</option> > <replaceable>interfacename</replaceable></term> > > <listitem> > <para>specifies that the named real public network interface > should be considered. The interface name specified should not be > <command>ipsec</command><emphasis remap="I">N</emphasis>. If the > option doesn't appear, all interfaces are considered. To specify > several interfaces, use the option once for each. One use of this > option is to specify which interface should be used when two or > more share the same IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ikeport</option> > <replaceable>port-number</replaceable></term> > > <listitem> > <para>changes the UDP port that <emphasis remap="B">pluto</emphasis> will use (default, specified by IANA: > 500)</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--ctlbase</option> > <replaceable>path</replaceable></term> > > <listitem> > <para>basename for control files. <emphasis remap="I">path</emphasis>.ctl is the socket through which > <emphasis remap="B">whack</emphasis> communicates with <emphasis remap="B">pluto</emphasis>. <emphasis remap="I">path</emphasis>.pid is the lockfile to prevent multiple > <emphasis remap="B">pluto</emphasis> instances. The default is > <filename>/var/run/pluto/pluto</filename>).</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--secretsfile</option> > <replaceable>file</replaceable></term> > > <listitem> > <para>specifies the file for authentication secrets (default: > <filename>/etc/ipsec.secrets</filename>). This name is subject to > âglobbingâ as in <citerefentry> > <refentrytitle>sh</refentrytitle> > > <manvolnum>1</manvolnum> > </citerefentry>, so every file with a matching name is > processed. Quoting is generally needed to prevent the shell from > doing the globbing.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--adns</option> <replaceable>path to > adns</replaceable></term> > > <term><option>--lwdnsq</option> <replaceable>path to > lwdnsq</replaceable></term> > > <listitem> > <para>specifies where to find <emphasis remap="B">pluto</emphasis>'s helper program for asynchronous DNS > lookup. <emphasis remap="B">pluto</emphasis> can be built to use > one of two helper programs: <emphasis remap="B">_pluto_adns</emphasis> or <emphasis remap="B">lwdnsq</emphasis>. You must use the program for which it > was built. By default, <emphasis remap="B">pluto</emphasis> will > look for the program in <emphasis remap="B">$IPSEC_DIR</emphasis> > (if that environment variable is defined) or, failing that, in the > same directory as <emphasis remap="B">pluto</emphasis>.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--nofork</option></term> > > <listitem> > <para>disable âdaemon forkâ (default is to fork). In addition, > after the lock file and control socket are created, print the line > âPluto initializedâ to standard out.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--uniqueids</option></term> > > <listitem> > <para>if this option has been selected, whenever a new ISAKMP SA > is established, any connection with the same Peer ID but a > different Peer IP address is unoriented (causing all its SAs to be > deleted). This helps clean up dangling SAs when a connection is > lost and then regained at another IP address.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--force_busy</option></term> > > <listitem> > <para>if this option has been selected, pluto will be forced > to be "busy". In this state, which happens when there is a > Denial of Service attack, will force pluto to use cookies > before accepting new incoming IKE packets. Cookies are send > and required in ikev1 Aggressive Mode and in ikev2. > This option is mostly used for testing purposes, but can > be selected by paranoid administrators as well.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--stderrlog</option></term> > > <listitem> > <para>log goes to standard out {default is to use <citerefentry> > <refentrytitle>syslogd</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>)</para> > </listitem> > </varlistentry> > </variablelist> > > <para>For example</para> > > <variablelist remap="TP"> > <varlistentry> > <term>pluto --secretsfile ipsec.secrets > --ctlbase pluto.base --ikeport 8500 --nofork --use-nostack > --stderrlog</term> > > <listitem> > <para/> > > <!-- FIXME: blank list item --> > </listitem> > </varlistentry> > </variablelist> > > <para>lets one test <emphasis remap="B">pluto</emphasis> without using > the superuser account.</para> > > <para><emphasis remap="B">pluto</emphasis> is willing to produce a > prodigious amount of debugging information. To do so, it must be > compiled with -DDEBUG. There are several classes of debugging output, > and <emphasis remap="B">pluto</emphasis> may be directed to produce a > selection of them. All lines of debugging output are prefixed with > â| â to distinguish them from error messages.</para> > > <para>When <emphasis remap="B">pluto</emphasis> is invoked, it may be > given arguments to specify which classes to output. The current options > are:</para> > > <variablelist remap="TP"> > <varlistentry> > <term><option>--debug-none</option></term> > > <listitem> > <para>disable all debugging</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-all</option></term> > > <listitem> > <para>enable all debugging</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-raw</option></term> > > <listitem> > <para>show the raw bytes of messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-crypt</option></term> > > <listitem> > <para>show the encryption and decryption of messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-parsing</option></term> > > <listitem> > <para>show the structure of input messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-emitting</option></term> > > <listitem> > <para>show the structure of output messages</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-control</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s decision > making</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-controlmore</option></term> > > <listitem> > <para>show even more detailed <emphasis remap="B">pluto</emphasis> > decision making</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-lifecycle</option></term> > > <listitem> > <para>[this option is temporary] log more detail of lifecycle of > SAs</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-klips</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s interaction with > <emphasis remap="B">KLIPS</emphasis></para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-pfkey</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s <emphasis remap="B">PFKEY</emphasis>interface communication</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-dns</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s interaction with > <emphasis remap="B">DNS</emphasis> for KEY and TXT records</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-dpd</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s <emphasis remap="B">Dead Peer Detection</emphasis> handling</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-natt</option></term> > > <listitem> > <para>show <emphasis remap="B">pluto</emphasis>'s <emphasis remap="B">NAT Traversal</emphasis> handling</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-oppo</option></term> > > <listitem> > <para>show why <emphasis remap="B">pluto</emphasis> didn't find a > suitable DNS TXT record to authorize opportunistic > initiation</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-oppoinfo</option></term> > > <listitem> > <para>log when connections are initiated due to acquires from the kernel. This is often useful to know, but can be extremely chatty on a busy system. </para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-whackwatch</option></term> > > <listitem> > <para>if set, causes pluto not to release the whack --initiate channel until the SA is completely up. This will cause the requestor to possibly wait forever while pluto unsuccessfully negotiates. Used often in test cases.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term><option>--debug-private</option></term> > > <listitem> > <para>allow debugging output with private keys.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>The debug form of the <emphasis remap="B">whack</emphasis> command > will change the selection in a running <emphasis remap="B">pluto</emphasis>. If a connection name is specified, the flags > are added whenever <emphasis remap="B">pluto</emphasis> has identified > that it is dealing with that connection. Unfortunately, this is often > part way into the operation being observed.</para> > > <para>For example, to start a <emphasis remap="B">pluto</emphasis> with > a display of the structure of input and output:</para> > > <para>pluto --debug-emitting --debug-parsing</para> > > <para>To later change this <emphasis remap="B">pluto</emphasis> to only > display raw bytes:</para> > > <para>whack --debug-raw</para> > > <para>For testing, SSH's IKE test page is quite useful:</para> > > <para><emphasis remap="I"><ulink url="http://isakmp-test.ssh.fi/">http://isakmp-test.ssh.fi/</ulink></emphasis></para> > > <para>Hint: ISAKMP SAs are often kept alive by IKEs even after the IPsec > SA is established. This allows future IPsec SA's to be negotiated > directly. If one of the IKEs is restarted, the other may try to use the > ISAKMP SA but the new IKE won't know about it. This can lead to much > confusion. <emphasis remap="B">pluto</emphasis> is not yet smart enough > to get out of such a mess.</para> > </refsect2> > > <refsect2 id="plutos_behaviour_when_things_go_wrong"> > <title>Pluto's Behaviour When Things Go Wrong</title> > > <para>When <emphasis remap="B">pluto</emphasis> doesn't understand or > accept a message, it just ignores the message. It is not yet capable of > communicating the problem to the other IKE daemon (in the future it > might use Notifications to accomplish this in many cases). It does log a > diagnostic.</para> > > <para>When <emphasis remap="B">pluto</emphasis> gets no response from a > message, it resends the same message (a message will be sent at most > three times). This is appropriate: UDP is unreliable.</para> > > <para>When pluto gets a message that it has already seen, there are many > cases when it notices and discards it. This too is appropriate for > UDP.</para> > > <para>Combine these three rules, and you can explain many apparently > mysterious behaviours. In a <emphasis remap="B">pluto</emphasis> log, > retrying isn't usually the interesting event. The critical thing is > either earlier (<emphasis remap="B">pluto</emphasis> got a message which > it didn't like and so ignored, so it was still awaiting an acceptable > message and got impatient) or on the other system (<emphasis remap="B">pluto</emphasis> didn't send a reply because it wasn't happy > with the previous message).</para> > </refsect2> > > <refsect2 id="notes"> > <title>Notes</title> > > <para>If <emphasis remap="B">pluto</emphasis> is compiled without > -DKLIPS, it negotiates Security Associations but never ask the kernel to > put them in place and never makes routing changes. This allows <emphasis remap="B">pluto</emphasis> to be tested on systems without <emphasis remap="B">KLIPS</emphasis>, but makes it rather useless.</para> > > <para>Each IPsec SA is assigned an SPI, a 32-bit number used to refer to > the SA. The IKE protocol lets the destination of the SA choose the SPI. > The range 0 to 0xFF is reserved for IANA. <emphasis remap="B">Pluto</emphasis> also avoids choosing an SPI in the range > 0x100 to 0xFFF, leaving these SPIs free for manual keying. Remember that > the peer, if not <emphasis remap="B">pluto</emphasis>, may well chose > SPIs in this range.</para> > </refsect2> > > <refsect2 id="policies"> > <title>Policies</title> > > <para>This catalogue of policies may be of use when trying to configure > <emphasis remap="B">Pluto</emphasis> and another IKE implementation to > interoperate.</para> > > <para>In Phase 1, only Main Mode is supported. We are not sure that > Aggressive Mode is secure. For one thing, it does not support identity > protection. It may allow more severe Denial Of Service attacks.</para> > > <para>No Informational Exchanges are supported. These are optional and > since their delivery is not assured, they must not matter. It is the > case that some IKE implementations won't interoperate without > Informational Exchanges, but we feel they are broken.</para> > > <para>No Informational Payloads are supported. These are optional, but > useful. It is of concern that these payloads are not authenticated in > Phase 1, nor in those Phase 2 messages authenticated with > HASH(3).</para> > > <variablelist remap="IP"> > <varlistentry> > <term>â¢</term> > > <listitem> > <para>Diffie Hellman Groups MODP 1024 and MODP 1536 (2 and 5) are > supported. Group MODP768 (1) is not supported because it is too > weak.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>Host authetication can be done by RSA Signatures or > Pre-Shared Secrets.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>3DES CBC (Cypher Block Chaining mode) is the only encryption > supported, both for ISAKMP SAs and IPSEC SAs.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>MD5 and SHA1 hashing are supported for packet authentication > in both kinds of SAs.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>The ESP, AH, or AH plus ESP are supported. If, and only if, > AH and ESP are combined, the ESP need not have its own > authentication component. The selection is controlled by the > --encrypt and --authenticate flags.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>Each of these may be combined with IPCOMP Deflate > compression, but only if the potential connection specifies > compression and only if KLIPS is configured with IPCOMP > support.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>The IPSEC SAs may be tunnel or transport mode, where > appropriate. The --tunnel flag controls this when <emphasis remap="B">pluto</emphasis> is initiating.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>When responding to an ISAKMP SA proposal, the maximum > acceptable lifetime is eight hours. The default is one hour. There > is no minimum. The --ikelifetime flag controls this when <emphasis remap="B">pluto</emphasis> is initiating.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>When responding to an IPSEC SA proposal, the maximum > acceptable lifetime is one day. The default is eight hours. There > is no minimum. The --ipseclifetime flag controls this when > <emphasis remap="B">pluto</emphasis> is initiating.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>â¢</term> > > <listitem> > <para>PFS is acceptable, and will be proposed if the --pfs flag > was specified. The DH group proposed will be the same as > negotiated for Phase 1.</para> > </listitem> > </varlistentry> > </variablelist> > </refsect2> > </refsect1> > > <refsect1 id="signals"> > <title>SIGNALS</title> > > <para><emphasis remap="B">Pluto</emphasis> responds to > <constant>SIGHUP</constant> by issuing a suggestion that ``<emphasis remap="B">whack</emphasis> --listen'' might have been intended.</para> > > <para><emphasis remap="B">Pluto</emphasis> exits when it recieves > <constant>SIGTERM</constant>.</para> > </refsect1> > > <refsect1 id="exit_status"> > <title>EXIT STATUS</title> > > <para><emphasis remap="B">pluto</emphasis> normally forks a daemon > process, so the exit status is normally a very preliminary result.</para> > > <variablelist remap="TP"> > <varlistentry> > <term>0</term> > > <listitem> > <para>means that all is OK so far.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>1</term> > > <listitem> > <para>means that something was wrong.</para> > </listitem> > </varlistentry> > > <varlistentry> > <term>10</term> > > <listitem> > <para>means that the lock file already exists.</para> > </listitem> > </varlistentry> > </variablelist> > > <para>If <emphasis remap="B">whack</emphasis> detects a problem, it will > return an exit status of 1. If it received progress messages from > <emphasis remap="B">pluto</emphasis>, it returns as status the value of > the numeric prefix from the last such message that was not a message sent > to syslog or a comment (but the prefix for success is treated as 0). > Otherwise, the exit status is 0.</para> > </refsect1> > > <refsect1 id="files"> > <title>FILES</title> > > <para><filename>/var/run/pluto/pluto.pid</filename> <!-- .br --> > <filename>/var/run/pluto/pluto.ctl</filename> <!-- .br --> > <filename>/etc/ipsec.secrets</filename> <!-- .br --> <emphasis remap="I">$IPSEC_LIBDIR/_pluto_adns</emphasis> <!-- .br --> <emphasis remap="I">$IPSEC_EXECDIR/lwdnsq</emphasis> <!-- .br --> > <filename>/dev/urandom</filename></para> > </refsect1> > > <refsect1 id="environment"> > <title>ENVIRONMENT</title> > > <para><emphasis remap="I">IPSEC_LIBDIR</emphasis> <!-- .br --> <emphasis remap="I">IPSEC_EXECDIR</emphasis> <!-- .br --> <emphasis remap="I">IPSECmyid</emphasis> <!-- .br --> <emphasis remap="I">PLUTO_CORE_DIR</emphasis></para> > </refsect1> > > <refsect1 id="see_also"> > <title>SEE ALSO</title> > > <para>The rest of the Openswan distribution, in particular <citerefentry> > <refentrytitle>ipsec</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry>.</para> > > <para><citerefentry> > <refentrytitle>ipsec_auto</refentrytitle> > > <manvolnum>8</manvolnum> > </citerefentry> is designed to make using <emphasis remap="B">pluto</emphasis> more pleasant. Use it!</para> > > <para><citerefentry> > <refentrytitle>ipsec.secrets</refentrytitle> > > <manvolnum>5</manvolnum> > </citerefentry> describes the format of the secrets file.</para> > > <para><citerefentry> > <refentrytitle>ipsec_atoaddr</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>, part of the Openswan distribution, describes the forms > that IP addresses may take. <citerefentry> > <refentrytitle>ipsec_atosubnet</refentrytitle> > > <manvolnum>3</manvolnum> > </citerefentry>, part of the Openswan distribution, describes the forms > that subnet specifications.</para> > > <para>For more information on IPsec, the mailing list, and the relevant > documents, see:</para> > > <!-- .nh --> > > <para><emphasis remap="I"><ulink url="http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html">http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html</ulink></emphasis></para> > > <!-- .hy --> > > <para>At the time of writing, the most relevant IETF RFCs are:</para> > > <para>RFC2409 The Internet Key Exchange (IKE)</para> > > <para>RFC2408 Internet Security Association and Key Management Protocol > (ISAKMP)</para> > > <para>RFC2407 The Internet IP Security Domain of Interpretation for > ISAKMP</para> > > <para>The Openswan web site <htp://www.openswan.org> and the mailing > lists described there.</para> > </refsect1> > > <refsect1 id="history"> > <title>HISTORY</title> > > <para>This code is released under the GPL terms. See the accompanying > files COPYING and CREDITS for more details. The GPL does NOT apply to > those pieces of code written by others which are included in this > distribution, except as noted by the individual authors.</para> > > <para>This software was originally written for the FreeS/WAN project > <<ulink url="http://www.freeswan.org">http://www.freeswan.org</ulink>>, founded > by John Gilmore and managed by Hugh Daniel. It was written by Angelos D. > Keromytis (angelos@dsl.cis.upenn.edu), in May/June 1997, in Athens, > Greece. Thanks go to John Ioannidis for his help.</para> > > <para>It is currently maintained and extended by Xelerance Corporation, in > Canada under the Openswan name. See CHANGES for details.</para> > > <para>FreeS/WAN was developed/maintained from 2000-2004 by D. Hugh > Redelmeier (hugh@mimosa.com), in Canada. The regulations of Greece and > Canada allow the code to be freely redistributable.</para> > > <para>Kai Martius (admin@imib.med.tu-dresden.de) contributed the initial > version of the code supporting PFS.</para> > > <para>Richard Guy Briggs <rgb@conscoop.ottawa.on.ca> and Peter Onion > <ponion@srd.bt.co.uk> added the PFKEY2 support.</para> > > <para>We gratefully acknowledge that we use parts of Eric Young's > <emphasis remap="I">libdes</emphasis> package; see <emphasis remap="I">../libdes/COPYRIGHT</emphasis>.</para> > </refsect1> > > <refsect1 id="bugs"> > <title>BUGS</title> > > <para><emphasis remap="B">pluto</emphasis> is a work-in-progress. It > currently has many limitations. For example, it ignores notification > messages that it receives, and it generates only Delete Notifications and > those only for IPSEC SAs.</para> > > <para><emphasis remap="B">pluto</emphasis> does not support the Commit > Flag. The Commit Flag is a bad feature of the IKE protocol. It isn't > protected -- neither encrypted nor authenticated. A man in the middle > could turn it on, leading to DoS. We just ignore it, with a warning. This > should let us interoperate with implementations that insist on it, with > minor damage.</para> > > <para><emphasis remap="B">pluto</emphasis> does not check that the SA > returned by the Responder is actually one that was proposed. It only > checks that the SA is acceptable. The difference is not large, but can > show up in attributes such as SA lifetime.</para> > > <para>There is no good way for a connection to be automatically > terminated. This is a problem for Road Warrior and Opportunistic > connections. The <option>--dontrekey</option> option does prevent the SAs > from being rekeyed on expiry. Additonally, if a Road Warrior connection > has a client subnet with a fixed IP address, a negotiation with that > subnet will cause any other connection instantiations with that same > subnet to be unoriented (deleted, in effect). See also the --uniqueids > option for an extension of this.</para> > > <para>When <emphasis remap="B">pluto</emphasis> sends a message to a peer > that has disappeared, <emphasis remap="B">pluto</emphasis> receives > incomplete information from the kernel, so it logs the unsatisfactory > message âsome IKE message we sent has been rejected with ECONNREFUSED > (kernel supplied no details)â. John Denker suggests that this command is > useful for tracking down the source of these problems: <!-- .br --> > tcpdump -i eth0 icmp[0] != 8 and icmp[0] != 0 <!-- .br --> Substitute your > public interface for eth0 if it is different.</para> > > <para>The word âauthenticateâ is used for two different features. We must > authenticate each IKE peer to the other. This is an important task of > Phase 1. Each packet must be authenticated, both in IKE and in IPsec, and > the method for IPsec is negotiated as an AH SA or part of an ESP SA. > Unfortunately, the protocol has no mechanism for authenticating the Phase > 2 identities.</para> > > <para>Bugs should be reported to the <users@lists.openswan.org> > mailing list.</para> > </refsect1> ></refentry> >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m >]0;root@RJZ-LNX:/var/tmp/portage/net-misc/openswan-2.6.19/work/openswan-2.6.19/programs/pluto[01;31mRJZ-LNX[01;34m pluto #[00m exit >exit > >Script done on Sun 21 Dec 2008 11:23:12 AM CET
<b>You cannot view the attachment while viewing its details because your browser does not support IFRAMEs. <a href="attachment.cgi?id=176031">View the attachment on a separate page</a>.</b>
View Attachment As Raw
Actions:
View
Attachments on
bug 237132
:
166664
|
176027
|
176029
| 176031
