IKE's Job

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.

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.

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.

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.

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.

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.

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.

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.

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.

Pluto

pluto implements a large subset of IKEv1 and IKEv2.

The policy for acceptable characteristics for Security Associations is mostly hardwired into the code of pluto (spdb.c). Eventually this will be moved into a security policy database with reasonable expressive power and more convenience.

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

pluto initiates negotiation of a Security Association when it is manually prodded: the program whack is run to trigger this. It will also initiate a negotiation when IPsec traps an outbound packet for Opportunistic Encryption.

pluto implements ISAKMP SAs itself. After it has negotiated the characteristics of an IPsec SA, it directs the kernel to implement it. If necessary, it also invokes a script to adjust any firewall and issue route(8) commands to direct IP packets.

When pluto shuts down, it closes all Security Associations.

Before Running Pluto

pluto requires a working IPsec stack.

pluto 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 --interface option can be used to limit the interfaces considered). It does this only when whack tells it to --listen, so the interfaces must be configured by then. The --listen can be used to limit listening on only 1 IP address of a certain interface. ifconfig(8) or ip(8) with the -a flag will show the name and status of each network interface.

pluto requires a database of preshared secrets and RSA private keys. This is described in the ipsec.secrets(5). pluto is told of RSA public keys via whack commands. If the connection is Opportunistic, and no RSA public key is known, pluto will attempt to fetch RSA keys using the Domain Name System.

Setting up XFRM for pluto

ipsec.secrets file

The file /usr/local/etc/ipsec.secrets is used to keep preshared secret keys and XAUTH passwords. RSA private keys, X.509 certificates, CRLs, OCSP and smartcards are handled via NSS. For debugging, there is an argument to the pluto command to use a different file. This file is described in ipsec.secrets(5).

Running Pluto

Pluto supports different IPstacks on different operating systems. This can be configured using one of the options --use-netkey (Linux), --use-bsdkame (BSD). On startup, pluto might also read the protostack= option to select the IPsec stack to use if --config /etc/ipsec.conf is given as argument to pluto. If both --use-XXX and --config /etc/ipsec.conf are specified, the last command line argument specified takes precedence.

Pluto supports RFC 3947 NAT-Traversal. The allowed range behind the NAT routers is submitted using the --virtual-private option. See ipsec.conf(5) for the syntax. The option --force-keepalive forces the sending of the keep-alive packets, which are send to prevent the NAT router from closing its port when there is not enough traffic on the IPsec connection. The --keep-alive sets the delay (in seconds) of these keep-alive packets. The newer NAT-T standards support port floating, and Libreswan enables this per default.

Pluto supports the use of X.509 certificates and sends certificates when needed. Pluto uses NSS for all X.509 related data, including CAcerts, certs, CRLs and private keys. The Certificate Revocation Lists can also be retrieved from an URL. The option --crlcheckinterval sets the time between checking for CRL expiration and issuing new fetch commands. The first attempt to update a CRL is started at 2*crlcheckinterval before the next update time. Pluto logs a warning if no valid CRL was loaded or obtained for a connection. If --crl-strict is given, the connection will be rejected until a valid CRL has been loaded.

Pluto can also use helper children to off-load cryptographic operations. This behavior can be fine tuned using the --nhelpers. Pluto will start (n-1) of them, where n is the number of CPU's you have (including hypherthreaded CPU's). A value of 0 forces pluto to do all operations in the main process. A value of -1 tells pluto to perform the above calculation. Any other value forces the number to that amount.

Pluto uses the NSS crypto library as its random source. Some government Three Letter Agency requires that pluto reads 440 bits from /dev/random and feed this into the NSS RNG before drawing random from the NSS library, despite the NSS library itself already seeding its internal state. As this process can block pluto for an extended time, the default is to not perform this redundant seeding. The --seedbits option can be used to specify the number of bits that will be pulled from /dev/random and seeded into the NSS RNG. This can also be accomplished by specifying seedbits in the "config setup" section of ipsec.conf. This option should not be used by most people.

pluto attempts to create a lockfile with the name /var/run/pluto/pluto.pid. If the lockfile cannot be created, pluto exits - this prevents multiple plutos from competing Any "leftover" lockfile must be removed before pluto will run. pluto 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).

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

All logging, including diagnostics, is sent to syslog(3) with facility=authpriv; it decides where to put these messages (possibly in /var/log/secure or /var/log/auth.log). Since this too can make debugging awkward, the option --stderrlog is used to steer logging to stderr.

Alternatively, --logfile can be used to send all logging information to a specific file.

Once pluto is started, it waits for requests from whack.

Pluto's Internal State

Pluto supports food groups for Opportunistic IPsec. The policies for these are located in /etc/ipsec.d/policies, or another directory as specified by --ipsecdir.

Pluto supports X.509 Certificates. All certificate handling is done using the NSS library and all certificate material is stored in an NSS database in /usr/local/etc/ipsec.d or another directory as specified by --nssdir.

Pluto may core dump. It will normally do so into the current working directory. You can specify the --coredir option for pluto, or specify the dumpdir= option in ipsec.conf.

If you are investigating a potential memory leak in pluto, start pluto with the --leak-detective option. Before the leak causes the system or pluto to die, shut down pluto in the regular way. pluto will display a list of leaks it has detected.

If you are investigating a potential use-after-free or double-free in pluto, first build pluto with USE_EFENCE=true and then start pluto with --efence-protect. See efence(2) and EF_PROTECT_BELOW and EF_PROTECT_FREE.

The (potential) connection database describes attributes of a connection. These include the IP addresses of the hosts and client subnets and the security characteristics desired. pluto 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.

During the IKE exchange to build an SA, the information about the negotiation is represented in a state object. 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.

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.

XFRM requires no special routing.

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 (pluto's logic does not reflect any advanced routing capabilities).

When pluto 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.

There is an exception. If pluto, 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).

When pluto 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.

Using whack

whack 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 pluto a description of a potential connection. The public key form informs pluto 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 pluto to start or stop listening on the public interfaces for IKE requests from peers. The route form tells pluto to set up routing for a connection; the unroute form undoes this. The initiate form tells pluto to negotiate an SA corresponding to a connection. The terminate form tells pluto to remove all SAs corresponding to a connection, including those being negotiated. The status form displays the pluto's internal state. The debug form tells pluto to change the selection of debugging output "on the fly". The shutdown form tells pluto to shut down, deleting all SAs.

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.

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.

--ctlsocket path/file

--rundir path

--label string

The help form of whack is self-explanatory.

--help

--version

The connection form describes a potential connection to pluto. pluto needs to know what connections can and should be negotiated. When pluto is the initiator, it needs to know what to propose. When pluto is the responder, it needs to know enough to decide whether is is willing to set up the proposed connection.

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.

--name connection-name

The topology of a connection is symmetric, so to save space here is half a picture:

   client_subnet<-->host:ikeport<-->nexthop<---

A similar trick is used in the flags. The same flag names are used for both ends. Those before the --to flag describe the left side and those afterwards describe the right side. When pluto 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.

--id id

--host ip-address, --host %any, --host %opportunistic

--cert friendly_name

--ckaid CKAID

--ca distinguished name

--groups access control groups

--sendcert yes|forced|always|ifasked|no|never

--sendca none|issuer|all

--certtype number

--ikeport port-number

--nexthop ip-address

--client subnet

--clientprotoport protocol/port

--srcip ip-address

--xauthserver

--xauthclient

--xauthuser

--xauthpass

--modecfgserver

--modecfgclient

--modecfgdns

--modecfgdomains

--dnskeyondemand

--updown updown

--to

The potential connection description also specifies characteristics of rekeying and security.

--psk

--rsasig

--encrypt

--authenticate

--compress

--tunnel

--ipv4

--ipv6

--tunnelipv4

--tunnelipv6

--pfs

--pfsgroup modp-group

--esp esp-algos

--aggrmode

--modecfgpull

--dpddelay seconds

--timeout seconds

--dpdaction action

--forceencaps

If none of the --encrypt, --authenticate, --compress, or --pfs 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.

Apart from initiating directly using the --initiate option, a tunnel can be loaded with a different policy

--initiateontraffic

--pass

--drop

--reject

These options need to be documented

--failnone

--failpass

--faildrop

--failreject

pluto supports various X.509 Certificate related options.

--utc

--listall

--listpubkeys

--listcerts

--checkpubkeys

--listcacerts

--listcrls

The corresponding options --rereadsecrets, --rereadall, and --rereadcrls options reread this information from their respective sources, and purge all the online obtained information. The option --listevents lists all pending events, and the --ddns triggers the Dynamic DNS update event that is normally scheduled to run once every minute.

--ikelifetime seconds

--ipseclifetime seconds

--rekeymargin seconds

--rekeyfuzz percentage

--keyingtries count

--dontrekey

--delete

--delete, --name connection-name

--deletestate state-number

The route form of the whack command tells pluto 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 whack route is not always needed: if it hasn't been done when an IPsec SA is being installed, one will be automatically attempted.

--route, --name connection-name

--unroute, --name connection-name

The initiate form tells pluto to initiate a negotiation with another pluto (or other IKE daemon) according to the named connection. Initiation requires a route that --route would provide; if none is in place at the time an IPsec SA is being installed, pluto attempts to set one up.

--initiate, --name connection-name, --asynchronous

The opportunistic initiate form is mainly used for debugging.

--tunnelipv4, --tunnelipv6, --oppohere  ip-address, --oppothere  ip-address, --opposport  port, --oppodport  port, --oppoproto  protocol

Rekeying a connection

--rekey-ipsec, --name connection-name

--rekey-ike, --name connection-name

Ending a connection

--terminate, --name connection-name

--crash ip-address

ip-address

Redirecting clients can be done using IKEv2 redirect mechanism.

--global-redirect yes|no|auto

--global-redirect-to ip-address(es)

--name connection_name, --redirect-to ip-address(es)

The public key for informs pluto of the RSA public key for a potential peer. Private keys must be kept secret, so they are kept in ipsec.secrets(5).

--keyid id

--addkey

--pubkeyrsa key

The listen form tells pluto to start listening for IKE requests on its public interfaces. To avoid race conditions, it is normal to load the appropriate connections into pluto before allowing it to listen. If pluto isn't listening, it is pointless to initiate negotiations, so it will refuse requests to do so. Whenever the listen form is used, pluto 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 pluto to read the ipsec.secrets file. So listen may useful more than once.

--listen

--unlisten

The --ddos-auto, --ddos-busy and --ddos-unlimited options tells pluto to update the DDoS protection state. Normally, these measures are automatically activated or deactivated based on the number of states inside pluto. The busy and unlimited option tells pluto to activate or deactivate the DDoS protection mode manually. One of these DDoS protection methods is to activate IKEv2 DCOOKIEs to defend against spoofed IKE packets.

--ddos-busy

--ddos-unlimited

--ddos-auto

The status form will display information about the internal state of pluto: information about each potential connection, about each state object, and about each shunt that pluto is managing without an associated connection.

Statistics can be seen using ipsec whack --globalstats and reset using ipsec whack --clearstats. This can be used with the munin software to monitor VPN services.

--status

The trafficstatus form will display the xauth username, add_time and the total in and out bytes of the IPsec SA's.

--trafficstatus

The shutdown form is the proper way to shut down pluto. It will tear down the SAs on this machine that pluto has negotiated. If the --leave-state option is given, it does not delete any connections, and leaves the kernel state in the kernel. Note that the init system used might clean up the kernel state regardless.

--shutdown

Examples

   ipsec pluto

The command will immediately return, but a pluto process will be left running, waiting for requests from whack or a peer.

Using whack, several potential connections would be described:

   ipsec whack --name silly --host 127.0.0.1 --to --host 127.0.0.2 --ikelifetime 900 --ipseclifetime 800 --keyingtries 3

Since this silly connection description specifies neither encryption, authentication, nor tunneling, it could only be used to establish an ISAKMP SA.

   ipsec whack --name conn_name --host 10.0.0.1 --client 10.0.1.0/24 --to --host 10.0.0.2 --client 10.0.2.0/24 --encrypt

This is something that must be done on both sides. If the other side is pluto, the same whack command could be used on it (the command syntax is designed to not distinguish which end is ours).

Now that the connections are specified, pluto 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:

   ipsec whack --listen

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 pluto 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:

   ipsec whack --route conn_name

Finally, we are ready to get pluto to initiate negotiation for an IPsec SA (and implicitly, an ISAKMP SA):

   ipsec whack --initiate --name conn_name

A small log of interesting events will appear on standard output (other logging is sent to syslog).

whack can also be used to terminate pluto cleanly, tearing down all SAs that it has negotiated.

   ipsec whack --shutdown

Notification of any IPSEC SA deletion, but not ISAKMP SA deletion is sent to the peer. Unfortunately, such Notification is not reliable. Furthermore, pluto itself ignores Notifications.

XAUTH

For testing purposes, the options --xauthuser user --xauthpass pass may be be given prior to the --initiate  to provide responses to the username and password prompts.

The updown command

The updown is invoked for five different operations. Each of these operations can be for our client subnet or for our host itself.

prepare-host or prepare-client

route-host or route-client

unroute-host or unroute-client

up-host or up-client

down-host or down-client

The script is passed a large number of environment variables to specify what needs to be done.

PLUTO_VERB

PLUTO_CONNECTION

PLUTO_NEXT_HOP

PLUTO_INTERFACE

PLUTO_ME

PLUTO_MY_CLIENT

PLUTO_MY_CLIENT_NET

PLUTO_MY_CLIENT_MASK

PLUTO_PEER

PLUTO_PEER_CLIENT

PLUTO_PEER_CLIENT_NET

PLUTO_PEER_CLIENT_MASK

PLUTO_MY_PROTOCOL

PLUTO_PEER_PROTOCOL

PLUTO_MY_PORT

PLUTO_PEER_PORT

PLUTO_MY_ID

PLUTO_PEER_ID

PLUTO_PEER_CA

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.

Pluto waits for the script to finish and will not do any other processing while it is waiting. The script may assume that pluto 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 pluto. Either of these activities could be performed by a background subprocess of the script.

Rekeying

Similarly, when an SA that was initiated by the peer has only a bit of lifetime left, pluto 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.

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.

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

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.

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.

Once a new set of SAs has been negotiated, pluto will never send traffic on a superseded one. Traffic will be accepted on an old SA until it expires.

Selecting a Connection When Responding: Road Warrior Support

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.

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.

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 %any 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 %any 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.

When pluto is using one of these temporary connections and needs to find the preshared secret or RSA private key in ipsec.secrets, and the connection specified no identity for the peer, %any 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.

Part way into the Phase 1 (Main Mode) negotiation using one of these temporary connection descriptions, pluto will receive an Identity Payload. At this point, pluto checks for a more appropriate connection, one with an identity for the peer that matches the payload and would use the same keys as so far used for authentication. If it finds one, it will switch to using this better connection (or a temporary one derived from this, if it has %any 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, pluto terminates negotiation.

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 authentication does not require that the responder knows 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).

When pluto 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 %any 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, pluto terminates negotiation.

Be sure to specify an appropriate nexthop for the responder to send a message to the initiator: pluto has no way of guessing it (if forwarding isn't required, use an explicit %direct as the nexthop and the IP address of the initiator will be filled in; the obsolete notation 0.0.0.0 is still accepted).

pluto 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. pluto has no mechanism to do this automatically.

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.

If any Road Warrior connections are supported, pluto 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.

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

Debugging

--interface interfacename

--ikeport port-number

--ctlbase path

--secretsfile file

--nofork

--uniqueids

--force-busy

--stderrlog

pluto is willing to produce a prodigious amount of debugging information. There are several classes of debugging output, and pluto may be directed to produce a selection of them. All lines of debugging output are prefixed with "| " to distinguish them from normal diagnostic messages.

When pluto is invoked, it may be given arguments to specify which debug classes to output. The current options are:

--debug help (whack only)

--debug none

--debug base

--debug cpu-usage

--debug class, --no-debug class, --debug no-class

The debug form of the whack command will change the selection in a running pluto. If a connection name is specified, the flags are added whenever pluto has identified that it is dealing with that connection. Unfortunately, this is often part way into the operation being observed.

For example, to start pluto with both base and cpu-usage debug-logging enabled:

	pluto --debug base --debug cpu-usage
      

To later change this pluto to disable base debug-logging use either:

	whack --no-debug base
      

or:

	whack --debug none --debug cpu-usage
      

Impairing

These options are solely intended for use by developers when testing pluto.

--impair help (whack only)

--impair list (whack only)

--impair none

--impair behaviour, --impair behaviour:how, --no-impair behaviour

Pluto's Behaviour When Things Go Wrong

When pluto 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.

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.

Combine these three rules, and you can explain many apparently mysterious behaviours. In a pluto log, retrying isn't usually the interesting event. The critical thing is either earlier (pluto got a message that it didn't like and so ignored, so it was still awaiting an acceptable message and got impatient) or on the other system (pluto didn't send a reply because it wasn't happy with the previous message).

Notes

Policies

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.

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.

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

•

•

•

•

•

•

•

•

•

•