specifies where to find \fBpluto\fP's helper program for asynchronous DNS lookup.By default, this program will be called \fB_pluto_adns\fP and be in\fB$IPSEC_DIR\fP (if that environment variable is defined) or, failing that,in the same directory as \fBpluto\fP..TP\fB\-\-nofork\fPdisable ``daemon fork'' (default is to fork).  In addition, after thelock file and control socket are created, print the line ``Plutoinitialized'' to standard out..TP\fB\-\-noklips\fPdon't actually implement negotiated IPsec SAs.TP\fB\-\-uniqueids\fPif this option has been selected, whenever a new ISAKMP SA isestablished, any connection with the same Peer ID but a differentPeer IP address is unoriented (causing all its SAs to be deleted).This helps clean up dangling SAs when a connection is lost andthen regained at another IP address..TP\fB\-\-stderrlog\fPlog goes to standard out {default is to use \fIsyslogd\fP(8)).LPFor example.TPpluto \-\-secretsfile\ ipsec.secrets \-\-ctlbase\ pluto.base \-\-ikeport\ 8500 \-\-nofork \-\-noklips \-\-stderrlog.LPlets one test \fBpluto\fP without using the superuser account..LP\fBpluto\fP is willing to produce a prodigious amount of debugginginformation.  To do so, it must be compiled with \-DDEBUG.  There areseveral classes of debugging output, and \fBpluto\fP may be directed toproduce a selection of them.  All lines ofdebugging output are prefixed with ``|\ '' to distinguish them from errormessages..LPWhen \fBpluto\fP is invoked, it may be given arguments to specifywhich classes to output.  The current options are:.TP\fB\-\-debug-raw\fPshow the raw bytes of messages.TP\fB\-\-debug-crypt\fPshow the encryption and decryption of messages.TP\fB\-\-debug-parsing\fPshow the structure of input messages.TP\fB\-\-debug-emitting\fPshow the structure of output messages.TP\fB\-\-debug-control\fPshow \fBpluto\fP's decision making.TP\fB\-\-debug-lifecycle\fP[this option is temporary] log more detail of lifecycle of SAs.TP\fB\-\-debug-klips\fPshow \fBpluto\fP's interaction with \fBKLIPS\fP.TP\fB\-\-debug-dns\fPshow \fBpluto\fP's interaction with \fBDNS\fP for KEY and TXT records..TP\fB\-\-debug-all\fPall of the above.TP\fB\-\-debug-private\fPallow debugging output with private keys..TP\fB\-\-debug-none\fPnone of the above.LPThe debug form of the\fBwhack\fP command will change the selection in a running\fBpluto\fP.If a connection name is specified, the flags are added whenever\fBpluto\fP has identified that it is dealing with that connection.Unfortunately, this is often part way into the operation being observed..LPFor example, to start a \fBpluto\fP with a display of the structure of inputand output:.IPpluto \-\-debug-emitting \-\-debug-parsing.LPTo later change this \fBpluto\fP to only display raw bytes:.IPwhack \-\-debug-raw.LPFor testing, SSH's IKE test page is quite useful:.IP\fIhttp://isakmp-test.ssh.fi/\fP.LPHint: ISAKMP SAs are often kept alive by IKEs even after the IPsec SAis established.  This allows future IPsec SA's to be negotiateddirectly.  If one of the IKEs is restarted, the other may try to usethe ISAKMP SA but the new IKE won't know about it.  This can lead tomuch confusion.  \fBpluto\fP is not yet smart enough to get out of such amess..SS Pluto's Behaviour When Things Go Wrong.LPWhen \fBpluto\fP doesn't understand or accept a message, it justignores the message.  It is not yet capable of communicating theproblem to the other IKE daemon (in the future it might useNotifications to accomplish this in many cases).  It does log a diagnostic..LPWhen \fBpluto\fP gets no response from a message, it resends the samemessage (a message will be sent at most three times).  This isappropriate: UDP is unreliable..LPWhen pluto gets a message that it has already seen, there are manycases when it notices and discards it.  This too is appropriate for UDP..LPCombine these three rules, and you can explain many apparentlymysterious behaviours.  In a \fBpluto\fP log, retrying isn't usually theinteresting event.  The critical thing is either earlier (\fBpluto\fPgot a message which it didn't like and so ignored, so it was stillawaiting an acceptable message and got impatient) or on the othersystem (\fBpluto\fP didn't send a reply because it wasn't happy withthe previous message)..SS Notes.LPIf \fBpluto\fP is compiled without \-DKLIPS, it negotiates SecurityAssociations but never ask the kernel to put them in place and nevermakes routing changes.  This allows \fBpluto\fP to be tested on systemswithout \fBKLIPS\fP, but makes it rather useless..LPEach 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.\fBPluto\fP also avoids choosing an SPI in the range 0x100 to 0xFFF,leaving these SPIs free for manual keying.Remember that the peer, if not \fBpluto\fP, may well choseSPIs in this range..SS Policies.LPThis catalogue of policies may be of use when trying to configure\fBPluto\fP and another IKE implementation to interoperate..LPIn Phase 1, only Main Mode is supported.  We are not sure thatAggressive Mode is secure.  For one thing, it does not supportidentity protection.  It may allow more severe Denial Of Serviceattacks..LPNo Informational Exchanges are supported.  These are optional andsince their delivery is not assured, they must not matter.It is the case that some IKE implementations won't interoperatewithout Informational Exchanges, but we feel they are broken..LPNo Informational Payloads are supported.  These are optional, butuseful.  It is of concern that these payloads are not authenticated inPhase 1, nor in those Phase 2 messages authenticated with HASH(3)..IP \(bu \w'\(bu\ 'uDiffie Hellman Groups MODP 1024 and MODP 1536 (2 and 5)are supported.Group MODP768 (1) is not supported because it is too weak..IP \(buHost authetication can be done by RSA Signatures or Pre-SharedSecrets..IP \(bu3DES CBC (Cypher Block Chaining mode) is the only encryptionsupported, both for ISAKMP SAs and IPSEC SAs..IP \(buMD5 and SHA1 hashing are supported for packet authentication in bothkinds of SAs..IP \(buThe ESP, AH, or AH plus ESP are supported.  If, and only if, AH andESP are combined, the ESP need not have its own authenticationcomponent.  The selection is controlled by the \-\-encrypt and\-\-authenticate flags..IP \(buEach of these may be combined with IPCOMP Deflate compression,but only if the potential connection specifies compression and onlyif KLIPS is configured with IPCOMP support..IP \(buThe IPSEC SAs may be tunnel or transport mode, where appropriate.The \-\-tunnel flag controls this when \fBpluto\fP is initiating..IP \(buWhen responding to an ISAKMP SA proposal, the maximum acceptablelifetime is eight hours.  The default is one hour.  There is nominimum.  The \-\-ikelifetime flag controls this when \fBpluto\fPis initiating..IP \(buWhen responding to an IPSEC SA proposal, the maximum acceptablelifetime is one day.  The default is eight hours.  There is nominimum.  The \-\-ipseclifetime flag controls this when \fBpluto\fPis initiating..IP \(buPFS is acceptable, and will be proposed if the \-\-pfs flag wasspecified.  The DH group proposed will be the same as negotiated forPhase 1..SH SIGNALS.LP\fBPluto\fP responds to \fBSIGHUP\fP by issuing a suggestion that ``\fBwhack\fP\-\-listen'' might have been intended..LP\fBPluto\fP exits when it recieves \fBSIGTERM\fP..SH EXIT STATUS.LP\fBpluto\fP normally forks a daemon process, so the exit status isnormally a very preliminary result..TP0means that all is OK so far..TP1means that something was wrong..TP10means that the lock file already exists..LPIf \fBwhack\fP detects a problem, it will return an exit status of 1.If it received progress messages from \fBpluto\fP, it returns as statusthe value of the numeric prefix from the last such messagethat 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..SH FILES\fI/var/run/pluto/pluto.pid\fP.br\fI/var/run/pluto/pluto.ctl\fP.br\fI/etc/ipsec.secrets\fP.br\fI$IPSEC_DIR/_pluto_adns\fP.br\fI/dev/urandom\fP.SH SEE ALSO.LPThe rest of the FreeS/WAN distribution, in particular \fIipsec\fP(8)..LP\fIipsec_auto\fP(8) is designed to make using \fBpluto\fP more pleasant.Use it!.LP.IR ipsec.secrets (5)describes the format of the secrets file..LP\fIipsec_atoaddr\fP(3), part of the FreeS/WAN distribution, describes theforms that IP addresses may take.\fIipsec_atosubnet\fP(3), part of the FreeS/WAN distribution, describes theforms that subnet specifications..LPFor more information on IPsec, the mailing list, and the relevantdocuments, see:.IP.nh\fIhttp://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html\fP.hy.LPAt the time of writing, the most relevant IETF RFCs are:.IPRFC2409 The Internet Key Exchange (IKE).IPRFC2408 Internet Security Association and Key Management Protocol (ISAKMP).IPRFC2407 The Internet IP Security Domain of Interpretation for ISAKMP.LPThe FreeS/WAN web site <htp://www.freeswan.org>and the mailing lists described there..SH HISTORYThis code is released under the GPL terms.See the accompanying file COPYING-2.0 for more details.The GPL does NOT apply to those pieces of code written by otherswhich are included in this distribution, except as noted by theindividual authors..LPThis software was originally writtenfor the FreeS/WAN project<http://www.freeswan.org>by Angelos D. Keromytis(angelos@dsl.cis.upenn.edu), in May/June 1997, in Athens, Greece.Thanks go to John Ioannidis for his help..LPIt is currently (2000)being developed and maintained by D. Hugh Redelmeier(hugh@mimosa.com), in Canada.  The regulations of Greece and Canadaallow us to make the code freely redistributable..LPKai Martius (admin@imib.med.tu-dresden.de) contributed the initialversion of the code supporting PFS..LPRichard Guy Briggs <rgb@conscoop.ottawa.on.ca> and Peter Onion<ponion@srd.bt.co.uk> added the PFKEY2 support..LPWe gratefully acknowledge that we use parts of Eric Young's \fIlibdes\fPpackage; see \fI../libdes/COPYRIGHT\fP..SH BUGS.BR plutois a work-in-progress.  It currently has many limitations.For example, it ignores notification messages that it receives, andit generates only Delete Notifications and those only for IPSEC SAs..LP\fBpluto\fP 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 withimplementations that insist on it, with minor damage..LP\fBpluto\fP does not check that the SA returned by the Responderis actually one that was proposed.  It only checks that the SA isacceptable.  The difference is not large, but can show up in attributessuch as SA lifetime..LPThere is no good way for a connection to be automatically terminated.This is a problem for Road Warrior and Opportunistic connections.The \fB\-\-dontrekey\fP option does prevent the SAs frombeing rekeyed on expiry.Additonally, if a Road Warrior connection has a client subnet with a fixed IPaddress, a negotiation with that subnet will cause any otherconnection instantiations with that same subnet to be unoriented(deleted, in effect).See also the \-\-uniqueids option for an extension of this..LPWhen \fBpluto\fP sends a message to a peer that has disappeared,\fBpluto\fP receives incomplete information from the kernel, so itlogs the unsatisfactory message ``some IKE message we sent has beenrejected with ECONNREFUSED (kernel supplied no details)''.  JohnDenker suggests that this command is useful for tracking down thesource of these problems:.br	tcpdump -i eth0 icmp[0] != 8 and icmp[0] != 0.brSubstitute your public interface for eth0 if it is different..LPThe word ``authenticate'' is used for two different features.  We mustauthenticate each IKE peer to the other.  This is an important task ofPhase 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 2identities..LPBugs should be reported to the <users@lists.freeswan.org> mailing list.Caution: we cannot acceptactual code from US residents, or even US citizens living outside theUS, because that would bring FreeS/WAN under US export law.  Someother countries cause similar problems.  In general, we would preferthat you send detailed problem reports rather than code:  we wantFreeS/WAN to be unquestionably freely exportable, which means beingvery careful about where the code comes from, and for a small bug fix,that is often more time-consuming than just reinventing the fixourselves.