1 .TH IPSEC_PLUTO 8 "28 March 1999"
3 ipsec pluto \- IPsec IKE keying daemon
5 ipsec whack \- control interface for IPSEC keying daemon
20 [\fB\-\-interface\fP \fIinterfacename\fP]
26 \fIsecrets\(hyfile\fP]
27 [\-\-adns \fIpathname\fP]
32 [\-\-debug\(hyparsing]
33 [\-\-debug\(hyemitting]
34 [\-\-debug\(hycontrol]
35 [\-\-debug\(hylifecycle]
38 [\-\-debug\(hyprivate]
85 [\-\-disablearrivalcheck]
92 [\-\-ipseclifetime\ \c
125 \-\-listen|\-\-unlisten
135 \-\-route|\-\-unroute
137 \fIconnection-name\fP
147 \-\-initiate|\-\-terminate
149 \fIconnection-name\fP
162 \fIconnection-name\fP
184 \fIconnection-name\fP]
189 [\-\-debug\(hyparsing]
190 [\-\-debug\(hyemitting]
191 [\-\-debug\(hycontrol]
192 [\-\-debug\(hylifecycle]
195 [\-\-debug\(hyprivate]
227 is an IKE (``IPsec Key Exchange'') daemon.
229 is an auxiliary program to allow requests to be made to a running
233 is used to automatically build shared ``security associations'' on a
234 system that has IPsec, the secure IP protocol.
237 can eliminate much of the work of manual keying.
239 secure transmission of packets is the responsibility of other parts of
242 the companion implementation of IPsec).
243 \fIipsec_auto\fP(8) provides a more convenient interface to
244 \fBpluto\fP and \fBwhack\fP.
247 A \fISecurity Association\fP (\fISA\fP) is an agreement between two network nodes on
248 how to process certain traffic between them. This processing involves
249 encapsulation, authentication, encryption, or compression.
251 IKE can be deployed on a network node to negotiate Security
252 Associations for that node. These IKE implementations can only
253 negotiate with other IKE implementations, so IKE must be on each node
254 that is to be an endpoint of an IKE-negotiated Security Association.
255 No other nodes need to be running IKE.
257 An IKE instance (i.e. an IKE implementation on a particular network
258 node) communicates with another IKE instance using UDP IP packets, so
259 there must be a route between the nodes in each direction.
261 The negotiation of Security Associations requires a number of choices
262 that involve tradeoffs between security, convenience, trust, and
263 efficiency. These are policy issues and are normally specified to the
264 IKE instance by the system administrator.
266 IKE deals with two kinds of Security Associations. The first part of
267 a negotiation between IKE instances is to build an ISAKMP SA. An
268 ISAKMP SA is used to protect communication between the two IKEs.
269 IPsec SAs can then be built by the IKEs \- these are used to carry
270 protected IP traffic between the systems.
272 The negotiation of the ISAKMP SA is known as Phase 1. In theory,
273 Phase 1 can be accomplished by a couple of different exchange types,
274 but we only implement one called Main Mode (we don't implement
277 Any negotiation under the protection of an ISAKMP SA, including the
278 negotiation of IPsec SAs, is part of Phase 2. The exchange type
279 that we use to negotiate an IPsec SA is called Quick Mode.
281 IKE instances must be able to authenticate each other as part of their
282 negotiation of an ISAKMP SA. This can be done by several mechanisms
283 described in the draft standards.
285 IKE negotiation can be initiated by any instance with any other. If
286 both can find an agreeable set of characteristics for a Security
287 Association, and both recognize each others authenticity, they can set
288 up a Security Association. The standards do not specify what causes
289 an IKE instance to initiate a negotiation.
291 In summary, an IKE instance is prepared to automate the management of
292 Security Associations in an IPsec environment, but a number of issues
293 are considered policy and are left in the system administrator's hands.
296 \fBpluto\fP is an implementation of IKE. It runs as a daemon on a network
297 node. Currently, this network node must be a LINUX system running the
298 \fBKLIPS\fP implementation of IPsec.
300 \fBpluto\fP only implements a subset of IKE. This is enough for it to
301 interoperate with other instances of \fBpluto\fP, and many other IKE
302 implementations. We are working on implementing more of IKE.
304 The policy for acceptable characteristics for Security Associations is
305 mostly hardwired into the code of \fBpluto\fP (spdb.c). Eventually
306 this will be moved into a security policy database with reasonable
307 expressive power and more convenience.
309 \fBpluto\fP uses shared secrets or RSA signatures to authenticate
310 peers with whom it is negotiating.
312 \fBpluto\fP initiates negotiation of a Security Association when it is
313 manually prodded: the program \fBwhack\fP is run to trigger this.
314 It will also initiate a negotiation when \fBKLIPS\fP traps an outbound packet
315 for Opportunistic Encryption.
317 \fBpluto\fP implements ISAKMP SAs itself. After it has negotiated the
318 characteristics of an IPsec SA, it directs \fBKLIPS\fP to implement it.
319 It also invokes a script to adjust any firewall and issue \fIroute\fP(8)
320 commands to direct IP packets through \fBKLIPS\fP.
322 When \fBpluto\fP shuts down, it closes all Security Associations.
323 .SS Before Running Pluto
325 \fBpluto\fP runs as a daemon with userid root. Before running it, a few
326 things must be set up.
328 \fBpluto\fP requires \fBKLIPS\fP, the FreeS/WAN implementation of IPsec.
329 All of the components of \fBKLIPS\fP and \fBpluto\fP should be installed.
331 \fBpluto\fP supports multiple public networks (that is, networks
332 that are considered insecure and thus need to have their traffic
333 encrypted or authenticated). It discovers the
334 public interfaces to use by looking at all interfaces that are
335 configured (the \fB\-\-interface\fP option can be used to limit
336 the interfaces considered).
337 It does this only when \fBwhack\fP tells it to \-\-listen,
338 so the interfaces must be configured by then. Each interface with a name of the form
339 \fBipsec\fP[\fB0\fP-\fB9\fP] is taken as a \fBKLIPS\fP virtual public interface.
340 Another network interface with the same IP address (there should be only
341 one) is taken as the corresponding real public
342 interface. \fIifconfig\fP(8) with the \fB\-a\fP flag will show
343 the name and status of each network interface.
345 \fBpluto\fP requires a database of preshared secrets and RSA private keys.
346 This is described in the
347 .IR ipsec.secrets (5).
348 \fBpluto\fP is told of RSA public keys via \fBwhack\fP commands.
349 If the connection is Opportunistic, and no RSA public key is known,
350 \fBpluto\fP will attempt to fetch RSA keys using the Domain Name System.
351 .SS Setting up \fBKLIPS\fP for \fBpluto\fP
353 The most basic network topology that \fBpluto\fP supports has two security
354 gateways negotiating on behalf of client subnets. The diagram of RGB's
355 testbed is a good example (see \fIklips/doc/rgb_setup.txt\fP).
357 The file \fIINSTALL\fP in the base directory of this distribution
358 explains how to start setting up the whole system, including \fBKLIPS\fP.
360 Make sure that the security gateways have routes to each other. This
361 is usually covered by the default route, but may require issuing
363 commands. The route must go through a particular IP
364 interface (we will assume it is \fIeth0\fP, but it need not be). The
365 interface that connects the security gateway to its client must be a
368 It is necessary to issue a
370 command on each gateway. The required command is:
372 \ \ \ ipsec tncfg \-\-attach\ \-\-virtual\ ipsec0 \-\-physical\ eth0
374 A command to set up the ipsec0 virtual interface will also need to be
375 run. It will have the same parameters as the command used to set up
376 the physical interface to which it has just been connected using
378 .SS ipsec.secrets file
380 A \fBpluto\fP daemon and another IKE daemon (for example, another instance
381 of \fBpluto\fP) must convince each other that they are who they are supposed
382 to be before any negotiation can succeed. This authentication is
383 accomplished by using either secrets that have been shared beforehand
384 (manually) or by using RSA signatures. There are other techniques,
385 but they have not been implemented in \fBpluto\fP.
387 The file \fI/etc/ipsec.secrets\fP is used to keep preshared secret keys
388 and RSA private keys for
389 authentication with other IKE daemons. For debugging, there is an
390 argument to the \fBpluto\fP command to use a different file.
391 This file is described in
392 .IR ipsec.secrets (5).
395 To fire up the daemon, just type \fBpluto\fP (be sure to be running as
397 The default IKE port number is 500, the UDP port assigned by IANA for IKE Daemons.
398 \fBpluto\fP must be run by the superuser to be able to use the UDP 500 port.
400 \fBpluto\fP attempts to create a lockfile with the name
401 \fI/var/run/pluto.pid\fP. If the lockfile cannot be created,
402 \fBpluto\fP exits \- this prevents multiple \fBpluto\fPs from
403 competing Any ``leftover'' lockfile must be removed before
404 \fBpluto\fP will run. \fBpluto\fP writes its pid into this file so
405 that scripts can find it. This lock will not function properly if it
406 is on an NFS volume (but sharing locks on multiple machines doesn't
409 \fBpluto\fP then forks and the parent exits. This is the conventional
410 ``daemon fork''. It can make debugging awkward, so there is an option
411 to suppress this fork.
413 All logging, including diagnostics, is sent to
415 with facility=authpriv;
416 it decides where to put these messages (possibly in /var/log/secure).
417 Since this too can make debugging awkward, there is an option to
418 steer logging to stderr.
420 Once \fBpluto\fP is started, it waits for requests from \fBwhack\fP.
421 .SS Pluto's Internal State
423 To understand how to use \fBpluto\fP, it is helpful to understand a little
424 about its internal state. Furthermore, the terminology is needed to decipher
425 some of the diagnostic messages.
427 The \fI(potential) connection\fP database describes attributes of a
428 connection. These include the IP addresses of the hosts and client
429 subnets and the security characteristics desired. \fBpluto\fP
430 requires this information (simply called a connection) before it can
431 respond to a request to build an SA. Each connection is given a name
432 when it is created, and all references are made using this name.
434 During the IKE exchange to build an SA, the information about the
435 negotiation is represented in a \fIstate object\fP. Each state object
436 reflects how far the negotiation has reached. Once the negotiation is
437 complete and the SA established, the state object remains to represent
438 the SA. When the SA is terminated, the state object is discarded.
439 Each State object is given a serial number and this is used to refer
440 to the state objects in logged messages.
442 Each state object corresponds to a connection and can be thought of
443 as an instantiation of that connection.
444 At any particular time, there may be any number of state objects
445 corresponding to a particular connection.
446 Often there is one representing an ISAKMP SA and another representing
449 \fBKLIPS\fP hooks into the routing code in a LINUX kernel.
450 Traffic to be processed by an IPsec SA must be directed through
451 \fBKLIPS\fP by routing commands. Furthermore, the processing to be
452 done is specified by \fIipsec eroute(8)\fP commands.
453 \fBpluto\fP takes the responsibility of managing both of these special
456 Each connection may be routed, and must be while it has an IPsec SA.
457 The connection specifies the characteristics of the route: the
458 interface on this machine, the ``gateway'' (the nexthop),
459 and the peer's client subnet. Two
460 connections may not be simultaneously routed if they are for the same
461 peer's client subnet but use different interfaces or gateways
462 (\fBpluto\fP's logic does not reflect any advanced routing capabilities).
464 Each eroute is associated with the state object for an IPsec SA
465 because it has the particular characteristics of the SA.
466 Two eroutes conflict if they specify the identical local
467 and remote clients (unlike for routes, the local clients are
470 When \fBpluto\fP needs to install a route for a connection,
471 it must make sure that no conflicting route is in use. If another
472 connection has a conflicting route, that route will be taken down, as long
473 as there is no IPsec SA instantiating that connection.
474 If there is such an IPsec SA, the attempt to install a route will fail.
476 There is an exception. If \fBpluto\fP, as Responder, needs to install
477 a route to a fixed client subnet for a connection, and there is
478 already a conflicting route, then the SAs using the route are deleted
479 to make room for the new SAs. The rationale is that the new
480 connection is probably more current. The need for this usually is a
481 product of Road Warrior connections (these are explained later; they
482 cannot be used to initiate).
484 When \fBpluto\fP needs to install an eroute for an IPsec SA (for a
485 state object), first the state object's connection must be routed (if
486 this cannot be done, the eroute and SA will not be installed).
487 If a conflicting eroute is already in place for another connection,
488 the eroute and SA will not be installed (but note that the routing
489 exception mentioned above may have already deleted potentially conflicting SAs).
491 SA for the same connection already has an eroute, all its outgoing traffic
492 is taken over by the new eroute. The incoming traffic will still be
493 processed. This characteristic is exploited during rekeying.
495 All of these routing characteristics are expected change when
496 \fBKLIPS\fP is modified to use the firewall hooks in the LINUX 2.4.x
500 \fBwhack\fP is used to command a running \fBpluto\fP.
501 \fBwhack\fP uses a UNIX domain socket to speak to \fBpluto\fP
502 (by default, \fI/var/pluto.ctl\fP).
504 \fBwhack\fP has an intricate argument syntax.
505 This syntax allows many different functions to be specified.
506 The help form shows the usage or version information.
507 The connection form gives \fBpluto\fP a description of a potential connection.
508 The public key form informs \fBpluto\fP of the RSA public key for a potential peer.
509 The delete form deletes a connection description and all SAs corresponding
511 The listen form tells \fBpluto\fP to start or stop listening on the public interfaces
512 for IKE requests from peers.
513 The route form tells \fBpluto\fP to set up routing for a connection;
514 the unroute form undoes this.
515 The initiate form tells \fBpluto\fP to negotiate an SA corresponding to a connection.
516 The terminate form tells \fBpluto\fP to remove all SAs corresponding to a connection,
517 including those being negotiated.
518 The status form displays the \fBpluto\fP's internal state.
519 The debug form tells \fBpluto\fP to change the selection of debugging output
520 ``on the fly''. The shutdown form tells
521 \fBpluto\fP to shut down, deleting all SAs.
523 Most options are specific to one of the forms, and will be described
524 with that form. There are three options that apply to all forms.
526 \fB\-\-ctlbase\fP\ \fIpath\fP
527 \fIpath\fP.ctl is used as the UNIX domain socket for talking
529 This option facilitates debugging.
531 \fB\-\-optionsfrom\fP\ \fIfilename\fP
532 adds the contents of the file to the argument list.
534 \fB\-\-label\fP\ \fIstring\fP
535 adds the string to all error messages generated by \fBwhack\fP.
537 The help form of \fBwhack\fP is self-explanatory.
540 display the usage message.
543 display the version of \fBwhack\fP.
545 The connection form describes a potential connection to \fBpluto\fP.
546 \fBpluto\fP needs to know what connections can and should be negotiated.
547 When \fBpluto\fP is the initiator, it needs to know what to propose.
548 When \fBpluto\fP is the responder, it needs to know enough to decide whether
549 is is willing to set up the proposed connection.
551 The description of a potential connection can specify a large number
552 of details. Each connection has a unique name. This name will appear
553 in a updown shell command, so it should not contain punctuation
554 that would make the command ill-formed.
556 \fB\-\-name\fP\ \fIconnection-name\fP
559 circuit is symmetric, so to save space here is half a picture:
561 \ \ \ client_subnet<\-\->host:ikeport<\-\->nexthop<\-\-\-
563 A similar trick is used in the flags. The same flag names are used for
564 both ends. Those before the \fB\-\-to\fP flag describe the left side
565 and those afterwards describe the right side. When \fBpluto\fP attempts
566 to use the connection, it decides whether it is the left side or the right
567 side of the connection, based on the IP numbers of its interfaces.
569 \fB\-\-id\fP\ \fIid\fP
570 the identity of the end. Currently, this can be an IP address (specified
571 as dotted quad or as a Fully Qualified Domain Name, which will be resolved
572 immediately) or as a Fully Qualified Domain Name itself (prefixed by ``@''
573 to signify that it should not be resolved), or as user@FQDN.
574 \fBpluto\fP only authenticates the identity, and does not use it for
575 addressing, so, for example, an IP address need not be the one to which
576 packets are to be sent. If the option is absent, the
577 identity defaults to the IP address specified by \fB\-\-host\fP.
578 .\" The identity is transmitted in the IKE protocol, and is what is authenticated.
580 \fB\-\-host\fP\ \fIip\(hyaddress\fP
582 \fB\-\-host\fP\ \fB%any\fP
584 \fB\-\-host\fP\ \fB%opportunistic\fP
585 the IP address of the end (generally the public interface).
586 If \fBpluto\fP is to act as a responder
587 for IKE negotiations initiated from unknown IP addresses (the
588 ``Road Warrior'' case), the
589 IP address should be specified as \fB%any\fP (currently,
590 the obsolete notation \fB0.0.0.0\fP is also accepted for this).
591 If \fBpluto\fP is to opportunistically initiate the connection,
592 use \fB%opportunistic\fP
594 \fB\-\-ikeport\fP\ \fIport\(hynumber\fP
595 the UDP port that IKE listens to on that host. The default is 500.
596 (\fBpluto\fP on this machine uses the port specified by its own command
597 line argument, so this only affects where \fBpluto\fP sends messages.)
599 \fB\-\-nexthop\fP\ \fIip\(hyaddress\fP
600 where to route packets for the peer's client (presumably for the peer too,
601 but it will not be used for this).
602 When \fBpluto\fP installs an IPsec SA, it issues a route command.
603 It uses the nexthop as the gateway.
604 The default is the peer's IP address (this can be explicitly written as
605 \fB%direct\fP; the obsolete notation \fB0.0.0.0\fP is accepted).
606 This option is necessary if \fBpluto\fP's host's interface used for sending
607 packets to the peer is neither point-to-point nor directly connected to the
610 \fB\-\-client\fP\ \fIsubnet\fP
611 the subnet for which the IPsec traffic will be destined. If not specified,
612 the host will be the client.
613 The subnet can be specified in any of the forms supported by \fIipsec_atosubnet\fP(3).
614 The general form is \fIaddress\fP/\fImask\fP. The \fIaddress\fP can be either
615 a domain name or four decimal numbers (specifying octets) separated by dots.
616 The most convenient form of the \fImask\fP is a decimal integer, specifying
617 the number of leading one bits in the mask. So, for example, 10.0.0.0/8
618 would specify the class A network ``Net 10''.
620 \fB\-\-updown\fP\ \fIupdown\fP
621 specifies an external shell command to be run whenever \fBpluto\fP
622 brings up or down a connection.
623 The script is used to build a shell command, so it may contain positional
624 parameters, but ought not to have punctuation that would cause the
625 resulting command to be ill-formed.
626 The default is \fIipsec _updown\fP.
629 separates the specification of the left and right ends of the connection.
631 The potential connection description also specifies characteristics of
632 rekeying and security.
635 Propose and allow preshared secret authentication for IKE peers. This authentication
636 requires that each side use the same secret. May be combined with \fB\-\-rsasig\fP;
637 at least one must be specified.
640 Propose and allow RSA signatures for authentication of IKE peers. This authentication
641 requires that each side have have a private key of its own and know the
642 public key of its peer. May be combined with \fB\-\-psk\fP;
643 at least one must be specified.
646 All proposed or accepted IPsec SAs will include non-null ESP.
647 The actual choices of transforms are wired into \fBpluto\fP.
649 \fB\-\-authenticate\fP
650 All proposed IPsec SAs will include AH.
651 All accepted IPsec SAs will include AH or ESP with authentication.
652 The actual choices of transforms are wired into \fBpluto\fP.
653 Note that this has nothing to do with IKE authentication.
656 All proposed IPsec SAs will include IPCOMP (compression).
657 This will be ignored if KLIPS is not configured with IPCOMP support.
660 the IPsec SA should use tunneling. Implicit if the SA is for clients.
661 Must only be used with \fB\-\-authenticate\fP or \fB\-\-encrypt\fP.
664 The host addresses will be interpreted as IPv4 addresses. This is the
665 default. Note that for a connection, all host addresses must be of
666 the same Address Family (IPv4 and IPv6 use different Address Families).
669 The host addresses (including nexthop) will be interpreted as IPv6 addresses.
670 Note that for a connection, all host addresses must be of
671 the same Address Family (IPv4 and IPv6 use different Address Families).
674 The client addresses will be interpreted as IPv4 addresses. The default is
675 to match what the host will be. This does not imply \fB\-\-tunnel\fP so the
676 flag can be safely used when no tunnel is actually specified.
677 Note that for a connection, all tunnel addresses must be of the same
681 The client addresses will be interpreted as IPv6 addresses. The default is
682 to match what the host will be. This does not imply \fB\-\-tunnel\fP so the
683 flag can be safely used when no tunnel is actually specified.
684 Note that for a connection, all tunnel addresses must be of the same
688 There should be Perfect Forward Secrecy \- new keying material will
689 be generated for each IPsec SA rather than being derived from the ISAKMP
691 Since the group to be used cannot be negotiated (a dubious feature of the
692 standard), \fBpluto\fP will propose the same group that was used during Phase 1.
693 We don't implement a stronger form of PFS which would require that the
694 ISAKMP SA be deleted after the IPSEC SA is negotiated.
696 \fB\-\-disablearrivalcheck\fP
697 If the connection is a tunnel, allow packets arriving through the tunnel
698 to have any source and destination addresses.
700 If none of the \fB\-\-encrypt\fP, \fB\-\-authenticate\fP, \fB\-\-compress\fP,
701 or \fB\-\-pfs\fP flags is given, the initiating the connection will
702 only build an ISAKMP SA. For such a connection, client subnets have
703 no meaning and must not be specified.
705 More work is needed to allow for flexible policies. Currently
706 policy is hardwired in the source file spdb.c. The ISAKMP SAs may use
707 Oakley groups MODP1024 and MODP1536; 3DES encryption; SHA1-96
708 and MD5-96 authentication. The IPsec SAs may use 3DES and
709 MD5-96 or SHA1-96 for ESP, or just MD5-96 or SHA1-96 for AH.
710 IPCOMP Compression is always Deflate.
712 \fB\-\-ikelifetime\fP\ \fIseconds\fP
713 how long \fBpluto\fP will propose that an ISAKMP SA be allowed to live.
714 The default is 3600 (one hour) and the maximum is 28800 (8 hours).
715 This option will not affect what is accepted.
716 \fBpluto\fP will reject proposals that exceed the maximum.
718 \fB\-\-ipseclifetime\fP\ \fIseconds\fP
719 how long \fBpluto\fP will propose that an IPsec SA be allowed to live.
720 The default is 28800 (eight hours) and the maximum is 86400 (one day).
721 This option will not affect what is accepted.
722 \fBpluto\fP will reject proposals that exceed the maximum.
724 \fB\-\-rekeymargin\fP\ \fIseconds\fP
725 how long before an SA's expiration should \fBpluto\fP try to negotiate
726 a replacement SA. This will only happen if \fBpluto\fP was the initiator.
727 The default is 540 (nine minutes).
729 \fB\-\-rekeyfuzz\fP\ \fIpercentage\fP
730 maximum size of random component to add to rekeymargin, expressed as
731 a percentage of rekeymargin. \fBpluto\fP will select a delay uniformly
732 distributed within this range. By default, the percentage will be 100.
733 If greater determinism is desired, specify 0. It may be appropriate
734 for the percentage to be much larger than 100.
736 \fB\-\-keyingtries\fP\ \fIcount\fP
737 how many times \fBpluto\fP should try to negotiate an SA,
738 either for the first time or for rekeying.
739 A value of 0 is interpreted as a very large number: never give up.
740 The default is three.
743 Do not initiate rekeying. This applies to Phase 1 and Phase 2.
744 This is currently the only automatic way for a connection to terminate.
745 It may be useful with Road Warrior or Opportunistic connections.
748 when used in the connection form, it causes any previous connection
749 with this name to be deleted before this one is added. Unlike a
750 normal delete, no diagnostic is produced if there was no previous
751 connection to delete. Any routing in place for the connection is undone.
753 The delete form deletes a named connection description and any
754 SAs established or negotiations initiated using this connection.
755 Any routing in place for the connection is undone.
759 \fB\-\-name\fP\ \fIconnection-name\fP
761 The deletestate form deletes the state object with the specified serial number.
762 This is useful for selectively deleting instances of connections.
764 \fB\-\-deletestate\fP\ \fIstate-number\fP
766 The route form of the \fBwhack\fP command tells \fBpluto\fP to set up
767 routing for a connection.
768 Although like a traditional route, it uses an ipsec device as a
770 Once routing is set up, no packets will be
771 sent ``in the clear'' to the peer's client specified in the connection.
772 A TRAP shunt eroute will be installed; if outbound traffic is caught,
773 Pluto will initiate the connection.
774 An explicit \fBwhack\fP route is not always needed: if it hasn't been
775 done when an IPsec SA is being installed, one will be automatically attempted.
777 When a routing is attempted for a connection, there must not already
778 be a routing for a different connection with the same subnet but different
779 interface or destination, or if
780 there is, it must not be being used by an IPsec SA. Otherwise the
785 \fB\-\-name\fP\ \fIconnection-name\fP
787 The unroute form of the \fBwhack\fP command tells \fBpluto\fP to undo
788 a routing. \fBpluto\fP will refuse if an IPsec SA is using the connection.
789 If another connection is sharing the same routing, it will be left in place.
790 Without a routing, packets will be sent without encryption or authentication.
794 \fB\-\-name\fP\ \fIconnection-name\fP
796 The initiate form tells \fBpluto\fP to initiate a negotiation with another
797 \fBpluto\fP (or other IKE daemon) according to the named connection.
798 Initiation requires a route that \fB\-\-route\fP would provide;
799 if none is in place at the time an IPsec SA is being installed,
800 \fBpluto\fP attempts to set one up.
804 \fB\-\-name\fP\ \fIconnection-name\fP
808 The initiate form of the \fBwhack\fP command will relay back from
809 \fBpluto\fP status information via the UNIX domain socket (unless
810 \-\-asynchronous is specified). The status information is meant to
811 look a bit like that from \fBFTP\fP. Currently \fBwhack\fP simply
812 copies this to stderr. When the request is finished (eg. the SAs are
813 established or \fBpluto\fP gives up), \fBpluto\fP closes the channel,
814 causing \fBwhack\fP to terminate.
816 The terminate form tells \fBpluto\fP to delete any SAs that use the specified
817 connection and to stop any negotiations in process.
818 It does not prevent new negotiations from starting (the delete form
823 \fB\-\-name\fP\ \fIconnection-name\fP
825 The public key for informs \fBpluto\fP of the RSA public key for a potential peer.
826 Private keys must be kept secret, so they are kept in
827 .IR ipsec.secrets (5).
829 \fB\-\-keyid\ \fP\fIid\fP
830 specififies the identity of the peer for which a public key should be used.
831 Its form is identical to the identity in the connection.
832 If no public key is specified, \fBpluto\fP attempts to find KEY records
833 from DNS for the id (if a FQDN) or through reverse lookup (if an IP address).
834 Note that there several interesting ways in which this is not secure.
837 specifies that the new key is added to the collection; otherwise the
838 new key replaces any old ones.
840 \fB\-\-pubkeyrsa\ \fP\fIkey\fP
841 specifies the value of the RSA public key. It is a sequence of bytes
842 as described in RFC 2537 ``RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)''.
843 It is denoted in a way suitable for \fIipsec_atodata\fP(3).
844 For example, a base 64 numeral starts with 0s.
846 The listen form tells \fBpluto\fP to start listening for IKE requests
847 on its public interfaces. To avoid race conditions, it is normal to
848 load the appropriate connections into \fBpluto\fP before allowing it
849 to listen. If \fBpluto\fP isn't listening, it is pointless to
850 initiate negotiations, so it will refuse requests to do so. Whenever
851 the listen form is used, \fBpluto\fP looks for public interfaces and
852 will notice when new ones have been added and when old ones have been
853 removed. This is also the trigger for \fBpluto\fP to read the
854 \fIipsec.secrets\fP file. So listen may useful more than once.
857 start listening for IKE traffic on public interfaces.
860 stop listening for IKE traffic on public interfaces.
862 The status form will display information about the internal state of
863 \fBpluto\fP: information about each potential connection and about
868 The shutdown form is the proper way to shut down \fBpluto\fP.
869 It will tear down the SAs on this machine that \fBpluto\fP has negotiated.
870 It does not inform its peers, so the SAs on their machines remain.
875 It would be normal to start \fBpluto\fP in one of the system initialization
876 scripts. It needs to be run by the superuser. Generally, no arguments are needed.
877 To run in manually, the superuser can simply type
881 The command will immediately return, but a \fBpluto\fP process will be left
882 running, waiting for requests from \fBwhack\fP or a peer.
884 Using \fBwhack\fP, several potential connections would be described:
887 \ \ \ ipsec whack \-\-name\ silly
888 \-\-host\ 127.0.0.1 \-\-to \-\-host\ 127.0.0.2
889 \-\-ikelifetime\ 900 \-\-ipseclifetime\ 800 \-\-keyingtries\ 3
892 Since this silly connection description specifies neither encryption,
893 authentication, nor tunneling, it could only be used to establish
897 \ \ \ ipsec whack \-\-name\ secret \-\-host\ 10.0.0.1 \-\-client\ 10.0.1.0/24
898 \-\-to \-\-host\ 10.0.0.2 \-\-client\ 10.0.2.0/24
902 This is something that must be done on both sides. If the other
903 side is \fBpluto\fP, the same \fBwhack\fP command could be used on it
904 (the command syntax is designed to not distinguish which end is ours).
906 Now that the connections are specified, \fBpluto\fP is ready to handle
907 requests and replies via the public interfaces. We must tell it to discover
908 those interfaces and start accepting messages from peers:
910 \ \ \ ipsec whack \-\-listen
912 If we don't immediately wish to bring up a secure connection between
913 the two clients, we might wish to prevent insecure traffic.
914 The routing form asks \fBpluto\fP to cause the packets sent from
915 our client to the peer's client to be routed through the ipsec0
916 device; if there is no SA, they will be discarded:
918 \ \ \ ipsec whack \-\-route secret
920 Finally, we are ready to get \fBpluto\fP to initiate negotiation
921 for an IPsec SA (and implicitly, an ISAKMP SA):
923 \ \ \ ipsec whack \-\-initiate\ \-\-name\ secret
925 A small log of interesting events will appear on standard output
926 (other logging is sent to syslog).
928 \fBwhack\fP can also be used to terminate \fBpluto\fP cleanly, tearing down
929 all SAs that it has negotiated.
931 \ \ \ ipsec whack \-\-shutdown
933 Notification of any IPSEC SA deletion, but not ISAKMP SA deletion
934 is sent to the peer. Unfortunately, such Notification is not reliable.
935 Furthermore, \fBpluto\fP itself ignores Notifications.
936 .SS The updown command
938 Whenever \fBpluto\fP brings a connection up or down, it invokes
939 the updown command. This command is specified using the \fB\-\-updown\fP
940 option. This allows for customized control over routing and firewall manipulation.
942 The updown is invoked for five different operations. Each of
943 these operations can be for our client subnet or for our host itself.
945 \fBprepare-host\fP or \fBprepare-client\fP
946 is run before bringing up a new connection if no other connection
947 with the same clients is up. Generally, this is useful for deleting a
948 route that might have been set up before \fBpluto\fP was run or
949 perhaps by some agent not known to \fBpluto\fP.
951 \fBroute-host\fP or \fBroute-client\fP
952 is run when bringing up a connection for a new peer client subnet
953 (even if \fBprepare-host\fP or \fBprepare-client\fP was run). The
954 command should install a suitable route. Routing decisions are based
955 only on the destination (peer's client) subnet address, unlike eroutes
956 which discriminate based on source too.
958 \fBunroute-host\fP or \fBunroute-client\fP
959 is run when bringing down the last connection for a particular peer
960 client subnet. It should undo what the \fBroute-host\fP or \fBroute-client\fP
963 \fBup-host\fP or \fBup-client\fP
964 is run when bringing up a tunnel eroute with a pair of client subnets
965 that does not already have a tunnel eroute.
966 This command should install firewall rules as appropriate.
967 It is generally a good idea to allow IKE messages (UDP port 500)
968 travel between the hosts.
970 \fBdown-host\fP or \fBdown-client\fP
971 is run when bringing down the eroute for a pair of client subnets.
972 This command should delete firewall rules as appropriate. Note that
973 there may remain some inbound IPsec SAs with these client subnets.
975 The script is passed a large number of environment variables to specify
976 what needs to be done.
979 indicates what version of this interface is being used. This document
980 describes version 1.1. This is upwardly compatible with version 1.0.
983 specifies the name of the operation to be performed
984 (\fBprepare-host\fP,r \fBprepare-client\fP,
985 \fBup-host\fP, \fBup-client\fP,
986 \fBdown-host\fP, or \fBdown-client\fP). If the address family for
987 security gateway to security gateway communications is IPv6, then
988 a suffix of -v6 is added to the verb.
990 \fBPLUTO_CONNECTION\fP
991 is the name of the connection for which we are routing.
994 is the next hop to which packets bound for the peer must be sent.
996 \fBPLUTO_INTERFACE\fP
997 is the name of the ipsec interface to be used.
1000 is the IP address of our host.
1002 \fBPLUTO_MY_CLIENT\fP
1003 is the IP address / count of our client subnet.
1004 If the client is just the host, this will be the host's own IP address / max
1005 (where max is 32 for IPv4 and 128 for IPv6).
1007 \fBPLUTO_MY_CLIENT_NET\fP
1008 is the IP address of our client net.
1009 If the client is just the host, this will be the host's own IP address.
1011 \fBPLUTO_MY_CLIENT_MASK\fP
1012 is the mask for our client net.
1013 If the client is just the host, this will be 255.255.255.255.
1016 is the IP address of our peer.
1018 \fBPLUTO_PEER_CLIENT\fP
1019 is the IP address / count of the peer's client subnet.
1020 If the client is just the peer, this will be the peer's own IP address / max
1021 (where max is 32 for IPv4 and 128 for IPv6).
1023 \fBPLUTO_PEER_CLIENT_NET\fP
1024 is the IP address of the peer's client net.
1025 If the client is just the peer, this will be the peer's own IP address.
1027 \fBPLUTO_PEER_CLIENT_MASK\fP
1028 is the mask for the peer's client net.
1029 If the client is just the peer, this will be 255.255.255.255.
1031 All output sent by the script to stderr or stdout is logged. The
1032 script should return an exit status of 0 if and only if it succeeds.
1035 When an SA that was initiated by \fBpluto\fP has only a bit of
1037 \fBpluto\fP will initiate the creation of a new SA. This applies to
1038 ISAKMP and IPsec SAs.
1039 The rekeying will be initiated when the SA's remaining lifetime is
1040 less than the rekeymargin plus a random percentage, between 0 and
1041 rekeyfuzz, of the rekeymargin.
1043 Similarly, when an SA that was initiated by the peer has only a bit of
1044 lifetime left, \fBpluto\fP will try to initiate the creation of a
1046 To give preference to the initiator, this rekeying will only be initiated
1047 when the SA's remaining lifetime is half of rekeymargin.
1048 If rekeying is done by the responder, the roles will be reversed: the
1049 responder for the old SA will be the initiator for the replacement.
1050 The former initiator might also initiate rekeying, so there may
1051 be redundant SAs created.
1052 To avoid these complications, make sure that rekeymargin is generous.
1054 One risk of having the former responder initiate is that perhaps
1055 none of its proposals is acceptable to the former initiator
1056 (they have not been used in a successful negotiation).
1057 To reduce the chances of this happening, and to prevent loss of security,
1058 the policy settings are taken from the old SA (this is the case even if
1059 the former initiator is initiating).
1060 These may be stricter than those of the connection.
1062 \fBpluto\fP will not rekey an SA if that SA is not the most recent of its
1063 type (IPsec or ISAKMP) for its potential connection.
1064 This avoids creating redundant SAs.
1066 The random component in the rekeying time (rekeyfuzz) is intended to
1067 make certain pathological patterns of rekeying unstable. If both
1068 sides decide to rekey at the same time, twice as many SAs as necessary
1069 are created. This could become a stable pattern without the
1072 Another more important case occurs when a security gateway has SAs
1073 with many other security gateways. Each of these connections might
1074 need to be rekeyed at the same time. This would cause a high peek
1075 requirement for resources (network bandwidth, CPU time, entropy for
1076 random numbers). The rekeyfuzz can be used to stagger the rekeying
1079 Once a new set of SAs has been negotiated, \fBpluto\fP will never send
1080 traffic on a superseded one. Traffic will be accepted on an old SA
1082 .SS Selecting a Connection When Responding: Road Warrior Support
1084 When \fBpluto\fP receives an initial Main Mode message, it needs to
1085 decide which connection this message is for. It picks based solely on
1086 the source and destination IP addresses of the message. There might
1087 be several connections with suitable IP addresses, in which case one
1088 of them is arbitrarily chosen. (The ISAKMP SA proposal contained in
1089 the message could be taken into account, but it is not.)
1091 The ISAKMP SA is negotiated before the parties pass further
1092 identifying information, so all ISAKMP SA characteristics specified in
1093 the connection description should be the same for every connection
1094 with the same two host IP addresses. At the moment, the only
1095 characteristic that might differ is authentication method.
1098 all configuring has presumed that the IP addresses
1099 are known to all parties ahead of time. This will not work
1100 when either end is mobile (or assigned a dynamic IP address for other
1101 reasons). We call this situation ``Road Warrior''. It is fairly tricky
1102 and has some important limitations, most of which are features of
1105 Only the initiator may be mobile:
1106 the initiator may have an IP number unknown to the responder. When
1107 the responder doesn't recognize the IP address on the first Main Mode
1108 packet, it looks for a connection with itself as one end and \fB%any\fP
1110 If it cannot find one, it refuses to negotiate. If it
1111 does find one, it creates a temporary connection that is a duplicate
1112 except with the \fB%any\fP replaced by the source IP address from the
1113 packet; if there was no identity specified for the peer, the new IP
1114 address will be used.
1116 When \fBpluto\fP is using one of these temporary connections and
1117 needs to find the preshared secret or RSA private key in \fIipsec.secrets\fP,
1118 and and the connection specified no identity for the peer, \fB%any\fP
1119 is used as its identity. After all, the real IP address was apparently
1120 unknown to the configuration, so it is unreasonable to require that
1121 it be used in this table.
1123 Part way into the Phase 1 (Main Mode) negotiation using one of these
1124 temporary connection descriptions, \fBpluto\fP will be receive an
1125 Identity Payload. At this point, \fBpluto\fP checks for a more
1126 appropriate connection, one with an identity for the peer that matches
1127 the payload but which would use the same keys so-far used for
1128 authentication. If it finds one, it will switch to using this better
1129 connection (or a temporary derived from this, if it has \fB%any\fP
1130 for the peer's IP address). It may even turn out that no connection
1131 matches the newly discovered identity, including the current connection;
1132 if so, \fBpluto\fP terminates negotiation.
1134 Unfortunately, if preshared secret authentication is being used, the
1135 Identity Payload is encrypted using this secret, so the secret must be
1136 selected by the responder without knowing this payload. This
1137 limits there to being at most one preshared secret for all Road Warrior
1138 systems connecting to a host. RSA Signature authentications does not
1139 require that the responder know how to select the initiator's public key
1140 until after the initiator's Identity Payload is decoded (using the
1141 responder's private key, so that must be preselected).
1143 When \fBpluto\fP is responding to a Quick Mode negotiation via one of these
1144 temporary connection descriptions, it may well find that the subnets
1145 specified by the initiator don't match those in the temporary
1146 connection description. If so, it will look for a connection with
1147 matching subnets, its own host address, a peer address of \fB%any\fP
1148 and matching identities.
1149 If it finds one, a new temporary connection is derived from this one
1150 and used for the Quick Mode negotiation of IPsec SAs. If it does not
1151 find one, \fBpluto\fP terminates negotiation.
1153 Be sure to specify an appropriate nexthop for the responder
1154 to send a message to the initiator: \fBpluto\fP has no way of guessing
1155 it (if forwarding isn't required, use an explicit \fB%direct\fP as the nexthop
1156 and the IP address of the initiator will be filled in; the obsolete
1157 notation \fB0.0.0.0\fP is still accepted).
1159 \fBpluto\fP has no special provision for the initiator side. The current
1160 (possibly dynamic) IP address and nexthop must be used in defining
1161 connections. These must be
1162 properly configured each time the initiator's IP address changes.
1163 \fBpluto\fP has no mechanism to do this automatically.
1165 Although we call this Road Warrior Support, it could also be used to
1166 support encrypted connections with anonymous initiators. The
1167 responder's organization could announce the preshared secret that would be used
1168 with unrecognized initiators and let anyone connect. Of course the initiator's
1169 identity would not be authenticated.
1171 If any Road Warrior connections are supported, \fBpluto\fP cannot
1172 reject an exchange initiated by an unknown host until it has
1173 determined that the secret is not shared or the signature is invalid.
1175 third Main Mode message from the initiator. If no Road Warrior
1176 connection is supported, the first message from an unknown source
1177 would be rejected. This has implications for ease of debugging
1178 configurations and for denial of service attacks.
1180 Although a Road Warrior connection must be initiated by the mobile
1181 side, the other side can and will rekey using the temporary connection
1182 it has created. If the Road Warrior wishes to be able to disconnect,
1183 it is probably wise to set \fB\-\-keyingtries\fP to 1 in the
1184 connection on the non-mobile side to prevent it trying to rekey the
1185 connection. Unfortunately, there is no mechanism to unroute the
1186 connection automatically.
1189 \fBpluto\fP accepts several optional arguments, useful mostly for debugging.
1190 Except for \fB\-\-interface\fP, each should appear at most once.
1192 \fB\-\-interface\fP \fIinterfacename\fP
1193 specifies that the named real public network interface should be considered.
1194 The interface name specified should not be \fBipsec\fP\fIN\fP.
1195 If the option doesn't appear, all interfaces are considered.
1196 To specify several interfaces, use the option once for each.
1197 One use of this option is to specify which interface should be used
1198 when two or more share the same IP address.
1200 \fB\-\-ikeport\fP \fIport-number\fP
1201 changes the UDP port that \fBpluto\fP will use
1202 (default, specified by IANA: 500)
1204 \fB\-\-ctlbase\fP \fIpath\fP
1205 basename for control files.
1206 \fIpath\fP.ctl is the socket through which \fBwhack\fP communicates with
1208 \fIpath\fP.pid is the lockfile to prevent multiple \fBpluto\fP instances.
1209 The default is \fI/var/run/pluto\fP).
1211 \fB\-\-secretsfile\fP \fIfile\fP
1212 specifies the file for authentication secrets
1213 (default: \fI/etc/ipsec.secrets\fP).
1214 This name is subject to ``globbing'' as in \fIsh\fP(1),
1215 so every file with a matching name is processed.
1216 Quoting is generally needed to prevent the shell from doing the globbing.
1218 \fB\-\-adns\fP \fIpathname\fP
1219 specifies where to find \fBpluto\fP's helper program for asynchronous DNS lookup.
1220 By default, this program will be called \fB_pluto_adns\fP and be in
1221 \fB$IPSEC_DIR\fP (if that environment variable is defined) or, failing that,
1222 in the same directory as \fBpluto\fP.
1225 disable ``daemon fork'' (default is to fork). In addition, after the
1226 lock file and control socket are created, print the line ``Pluto
1227 initialized'' to standard out.
1230 don't actually implement negotiated IPsec SAs
1233 if this option has been selected, whenever a new ISAKMP SA is
1234 established, any connection with the same Peer ID but a different
1235 Peer IP address is unoriented (causing all its SAs to be deleted).
1236 This helps clean up dangling SAs when a connection is lost and
1237 then regained at another IP address.
1240 log goes to standard out {default is to use \fIsyslogd\fP(8))
1244 pluto \-\-secretsfile\ ipsec.secrets \-\-ctlbase\ pluto.base \-\-ikeport\ 8500 \-\-nofork \-\-noklips \-\-stderrlog
1246 lets one test \fBpluto\fP without using the superuser account.
1248 \fBpluto\fP is willing to produce a prodigious amount of debugging
1249 information. To do so, it must be compiled with \-DDEBUG. There are
1250 several classes of debugging output, and \fBpluto\fP may be directed to
1251 produce a selection of them. All lines of
1252 debugging output are prefixed with ``|\ '' to distinguish them from error
1255 When \fBpluto\fP is invoked, it may be given arguments to specify
1256 which classes to output. The current options are:
1259 show the raw bytes of messages
1261 \fB\-\-debug-crypt\fP
1262 show the encryption and decryption of messages
1264 \fB\-\-debug-parsing\fP
1265 show the structure of input messages
1267 \fB\-\-debug-emitting\fP
1268 show the structure of output messages
1270 \fB\-\-debug-control\fP
1271 show \fBpluto\fP's decision making
1273 \fB\-\-debug-lifecycle\fP
1274 [this option is temporary] log more detail of lifecycle of SAs
1276 \fB\-\-debug-klips\fP
1277 show \fBpluto\fP's interaction with \fBKLIPS\fP
1280 show \fBpluto\fP's interaction with \fBDNS\fP for KEY and TXT records.
1285 \fB\-\-debug-private\fP
1286 allow debugging output with private keys.
1288 \fB\-\-debug-none\fP
1291 The debug form of the
1292 \fBwhack\fP command will change the selection in a running
1294 If a connection name is specified, the flags are added whenever
1295 \fBpluto\fP has identified that it is dealing with that connection.
1296 Unfortunately, this is often part way into the operation being observed.
1298 For example, to start a \fBpluto\fP with a display of the structure of input
1301 pluto \-\-debug-emitting \-\-debug-parsing
1303 To later change this \fBpluto\fP to only display raw bytes:
1307 For testing, SSH's IKE test page is quite useful:
1309 \fIhttp://isakmp-test.ssh.fi/\fP
1311 Hint: ISAKMP SAs are often kept alive by IKEs even after the IPsec SA
1312 is established. This allows future IPsec SA's to be negotiated
1313 directly. If one of the IKEs is restarted, the other may try to use
1314 the ISAKMP SA but the new IKE won't know about it. This can lead to
1315 much confusion. \fBpluto\fP is not yet smart enough to get out of such a
1317 .SS Pluto's Behaviour When Things Go Wrong
1319 When \fBpluto\fP doesn't understand or accept a message, it just
1320 ignores the message. It is not yet capable of communicating the
1321 problem to the other IKE daemon (in the future it might use
1322 Notifications to accomplish this in many cases). It does log a diagnostic.
1324 When \fBpluto\fP gets no response from a message, it resends the same
1325 message (a message will be sent at most three times). This is
1326 appropriate: UDP is unreliable.
1328 When pluto gets a message that it has already seen, there are many
1329 cases when it notices and discards it. This too is appropriate for UDP.
1331 Combine these three rules, and you can explain many apparently
1332 mysterious behaviours. In a \fBpluto\fP log, retrying isn't usually the
1333 interesting event. The critical thing is either earlier (\fBpluto\fP
1334 got a message which it didn't like and so ignored, so it was still
1335 awaiting an acceptable message and got impatient) or on the other
1336 system (\fBpluto\fP didn't send a reply because it wasn't happy with
1337 the previous message).
1340 If \fBpluto\fP is compiled without \-DKLIPS, it negotiates Security
1341 Associations but never ask the kernel to put them in place and never
1342 makes routing changes. This allows \fBpluto\fP to be tested on systems
1343 without \fBKLIPS\fP, but makes it rather useless.
1345 Each IPsec SA is assigned an SPI, a 32-bit number used to refer to the SA.
1346 The IKE protocol lets the destination of the SA choose the SPI.
1347 The range 0 to 0xFF is reserved for IANA.
1348 \fBPluto\fP also avoids choosing an SPI in the range 0x100 to 0xFFF,
1349 leaving these SPIs free for manual keying.
1350 Remember that the peer, if not \fBpluto\fP, may well chose
1354 This catalogue of policies may be of use when trying to configure
1355 \fBPluto\fP and another IKE implementation to interoperate.
1357 In Phase 1, only Main Mode is supported. We are not sure that
1358 Aggressive Mode is secure. For one thing, it does not support
1359 identity protection. It may allow more severe Denial Of Service
1362 No Informational Exchanges are supported. These are optional and
1363 since their delivery is not assured, they must not matter.
1364 It is the case that some IKE implementations won't interoperate
1365 without Informational Exchanges, but we feel they are broken.
1367 No Informational Payloads are supported. These are optional, but
1368 useful. It is of concern that these payloads are not authenticated in
1369 Phase 1, nor in those Phase 2 messages authenticated with HASH(3).
1370 .IP \(bu \w'\(bu\ 'u
1371 Diffie Hellman Groups MODP 1024 and MODP 1536 (2 and 5)
1373 Group MODP768 (1) is not supported because it is too weak.
1375 Host authetication can be done by RSA Signatures or Pre-Shared
1378 3DES CBC (Cypher Block Chaining mode) is the only encryption
1379 supported, both for ISAKMP SAs and IPSEC SAs.
1381 MD5 and SHA1 hashing are supported for packet authentication in both
1384 The ESP, AH, or AH plus ESP are supported. If, and only if, AH and
1385 ESP are combined, the ESP need not have its own authentication
1386 component. The selection is controlled by the \-\-encrypt and
1387 \-\-authenticate flags.
1389 Each of these may be combined with IPCOMP Deflate compression,
1390 but only if the potential connection specifies compression and only
1391 if KLIPS is configured with IPCOMP support.
1393 The IPSEC SAs may be tunnel or transport mode, where appropriate.
1394 The \-\-tunnel flag controls this when \fBpluto\fP is initiating.
1396 When responding to an ISAKMP SA proposal, the maximum acceptable
1397 lifetime is eight hours. The default is one hour. There is no
1398 minimum. The \-\-ikelifetime flag controls this when \fBpluto\fP
1401 When responding to an IPSEC SA proposal, the maximum acceptable
1402 lifetime is one day. The default is eight hours. There is no
1403 minimum. The \-\-ipseclifetime flag controls this when \fBpluto\fP
1406 PFS is acceptable, and will be proposed if the \-\-pfs flag was
1407 specified. The DH group proposed will be the same as negotiated for
1411 \fBPluto\fP responds to \fBSIGHUP\fP by issuing a suggestion that ``\fBwhack\fP
1412 \-\-listen'' might have been intended.
1414 \fBPluto\fP exits when it recieves \fBSIGTERM\fP.
1417 \fBpluto\fP normally forks a daemon process, so the exit status is
1418 normally a very preliminary result.
1421 means that all is OK so far.
1424 means that something was wrong.
1427 means that the lock file already exists.
1429 If \fBwhack\fP detects a problem, it will return an exit status of 1.
1430 If it received progress messages from \fBpluto\fP, it returns as status
1431 the value of the numeric prefix from the last such message
1432 that was not a message sent to syslog or a comment
1433 (but the prefix for success is treated as 0).
1434 Otherwise, the exit status is 0.
1436 \fI/var/run/pluto.pid\fP
1438 \fI/var/run/pluto.ctl\fP
1440 \fI/etc/ipsec.secrets\fP
1442 \fI$IPSEC_DIR/_pluto_adns\fP
1447 The rest of the FreeS/WAN distribution, in particular \fIipsec\fP(8).
1449 \fIipsec_auto\fP(8) is designed to make using \fBpluto\fP more pleasant.
1452 .IR ipsec.secrets (5)
1453 describes the format of the secrets file.
1455 \fIipsec_atoaddr\fP(3), part of the FreeS/WAN distribution, describes the
1456 forms that IP addresses may take.
1457 \fIipsec_atosubnet\fP(3), part of the FreeS/WAN distribution, describes the
1458 forms that subnet specifications.
1460 For more information on IPsec, the mailing list, and the relevant
1464 \fIhttp://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html\fP
1467 At the time of writing, the most relevant IETF RFCs are:
1469 RFC2409 The Internet Key Exchange (IKE)
1471 RFC2408 Internet Security Association and Key Management Protocol (ISAKMP)
1473 RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP
1475 The FreeS/WAN web site <htp://www.freeswan.org>
1476 and the mailing lists described there.
1478 This code is released under the GPL terms.
1479 See the accompanying file COPYING-2.0 for more details.
1480 The GPL does NOT apply to those pieces of code written by others
1481 which are included in this distribution, except as noted by the
1484 This software was originally written
1485 for the FreeS/WAN project
1486 <http://www.freeswan.org>
1487 by Angelos D. Keromytis
1488 (angelos@dsl.cis.upenn.edu), in May/June 1997, in Athens, Greece.
1489 Thanks go to John Ioannidis for his help.
1491 It is currently (2000)
1492 being developed and maintained by D. Hugh Redelmeier
1493 (hugh@mimosa.com), in Canada. The regulations of Greece and Canada
1494 allow us to make the code freely redistributable.
1496 Kai Martius (admin@imib.med.tu-dresden.de) contributed the initial
1497 version of the code supporting PFS.
1499 Richard Guy Briggs <rgb@conscoop.ottawa.on.ca> and Peter Onion
1500 <ponion@srd.bt.co.uk> added the PFKEY2 support.
1502 We gratefully acknowledge that we use parts of Eric Young's \fIlibdes\fP
1503 package; see \fI../libdes/COPYRIGHT\fP.
1506 is a work-in-progress. It currently has many limitations.
1507 For example, it ignores notification messages that it receives, and
1508 it generates only Delete Notifications and those only for IPSEC SAs.
1510 \fBpluto\fP does not support the Commit Flag.
1511 The Commit Flag is a bad feature of the IKE protocol.
1512 It isn't protected -- neither encrypted nor authenticated.
1513 A man in the middle could turn it on, leading to DoS.
1514 We just ignore it, with a warning.
1515 This should let us interoperate with
1516 implementations that insist on it, with minor damage.
1518 \fBpluto\fP does not check that the SA returned by the Responder
1519 is actually one that was proposed. It only checks that the SA is
1520 acceptable. The difference is not large, but can show up in attributes
1521 such as SA lifetime.
1523 There is no good way for a connection to be automatically terminated.
1524 This is a problem for Road Warrior and Opportunistic connections.
1525 The \fB\-\-dontrekey\fP option does prevent the SAs from
1526 being rekeyed on expiry.
1527 Additonally, if a Road Warrior connection has a client subnet with a fixed IP
1528 address, a negotiation with that subnet will cause any other
1529 connection instantiations with that same subnet to be unoriented
1530 (deleted, in effect).
1531 See also the \-\-uniqueids option for an extension of this.
1533 When \fBpluto\fP sends a message to a peer that has disappeared,
1534 \fBpluto\fP receives incomplete information from the kernel, so it
1535 logs the unsatisfactory message ``some IKE message we sent has been
1536 rejected with ECONNREFUSED (kernel supplied no details)''. John
1537 Denker suggests that this command is useful for tracking down the
1538 source of these problems:
1540 tcpdump -i eth0 icmp[0] != 8 and icmp[0] != 0
1542 Substitute your public interface for eth0 if it is different.
1544 The word ``authenticate'' is used for two different features. We must
1545 authenticate each IKE peer to the other. This is an important task of
1546 Phase 1. Each packet must be authenticated, both in IKE and in IPsec,
1547 and the method for IPsec is negotiated as an AH SA or part of an ESP SA.
1548 Unfortunately, the protocol has no mechanism for authenticating the Phase 2
1551 Bugs should be reported to the <users@lists.freeswan.org> mailing list.
1552 Caution: we cannot accept
1553 actual code from US residents, or even US citizens living outside the
1554 US, because that would bring FreeS/WAN under US export law. Some
1555 other countries cause similar problems. In general, we would prefer
1556 that you send detailed problem reports rather than code: we want
1557 FreeS/WAN to be unquestionably freely exportable, which means being
1558 very careful about where the code comes from, and for a small bug fix,
1559 that is often more time-consuming than just reinventing the fix
OSDN Git Service
