[svn-upgrade] Integrating new upstream version, strongswan (4.1.4)

1 files changed, 487 insertions, 473 deletions

diff --git a/src/starter/ipsec.conf.5 b/src/starter/ipsec.conf.5
index c80c5166b..2dbcfcfd7 100644
--- a/src/starter/ipsec.conf.5
+++ b/src/starter/ipsec.conf.5
@@ -1,4 +1,4 @@
-.TH IPSEC.CONF 5 "20 Jan 2006"
+.TH IPSEC.CONF 5 "27 Jun 2007"
 .\" RCSID $Id: ipsec.conf.5,v 1.2 2006/01/22 15:33:46 as Exp $
 .SH NAME
 ipsec.conf \- IPsec configuration and connections
@@ -143,7 +143,7 @@ section specifies general configuration information for IPsec, a
 .B conn
 section specifies an IPsec connection, while a
 .B ca
-section specifies special properties a certification authority.
+section specifies special properties of a certification authority.
 .SH "CONN SECTIONS"
 A
 .B conn
@@ -158,13 +158,12 @@ Here's a simple example:
 .ft B
 .ta 1c
 conn snt
-	left=10.11.11.1
-	leftsubnet=10.0.1.0/24
-	leftnexthop=172.16.55.66
-	right=192.168.22.1
-	rightsubnet=10.0.2.0/24
-	rightnexthop=172.16.88.99
+	left=192.168.0.1
+	leftsubnet=10.1.0.0/16
+	right=192.168.0.2
+	rightsubnet=10.1.0.0/16
 	keyingtries=%forever
+	auto=add
 .ft
 .fi
 .PP
@@ -172,7 +171,7 @@ A note on terminology: There are two kinds of communications going on:
 transmission of user IP packets, and gateway-to-gateway negotiations for
 keying, rekeying, and general control.
 The path to control the connection is called 'ISAKMP SA' in IKEv1 and
-'IKE SA' in the IKEv2 protocol. That what is beeing negotiated, the kernel
+'IKE SA' in the IKEv2 protocol. That what is being negotiated, the kernel
 level data path, is called 'IPsec SA'.
 strongSwan currently uses two separate keying daemons. Pluto handles
 all IKEv1 connections, Charon is the new daemon supporting the IKEv2 protocol.
@@ -220,151 +219,47 @@ Unless otherwise noted, for a connection to work,
 in general it is necessary for the two ends to agree exactly
 on the values of these parameters.
 .TP 14
-.B type
-the type of the connection; currently the accepted values
-are
-.B tunnel
-(the default)
-signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel;
-.BR transport ,
-signifying host-to-host transport mode;
-.BR passthrough ,
-signifying that no IPsec processing should be done at all;
-.BR drop ,
-signifying that packets should be discarded; and
-.BR reject ,
-signifying that packets should be discarded and a diagnostic ICMP returned.
-Charon currently supports only 
-.BR tunnel
-and
-.BR transport
-connection types.
-.TP
-.B left
-(required)
-the IP address of the left participant's public-network interface,
-in any form accepted by
-.IR ipsec_ttoaddr (3)
-or one of several magic values.
-If it is
-.BR %defaultroute ,
-and
-the
-.B config
-.B setup
-section's,
-.B interfaces
-specification contains
-.BR %defaultroute,
-.B left
-will be filled in automatically with the local address
-of the default-route interface (as determined at IPsec startup time);
-this also overrides any value supplied for
-.BR leftnexthop .
-(Either
-.B left
-or
-.B right
-may be
-.BR %defaultroute ,
-but not both.)
-The value
-.B %any
-signifies an address to be filled in (by automatic keying) during
-negotiation.
-.TP
-.B leftsubnet
-private subnet behind the left participant, expressed as
-\fInetwork\fB/\fInetmask\fR
-(actually, any form acceptable to
-.IR ipsec_ttosubnet (3));
-if omitted, essentially assumed to be \fIleft\fB/32\fR,
-signifying that the left end of the connection goes to the left participant
-only. When using IKEv2, the configured subnet of the peers may differ, the
-protocol narrows it to the greates common subnet.
-.TP
-.B leftnexthop
-next-hop gateway IP address for the left participant's connection
-to the public network;
-defaults to
-.B %direct
-(meaning
-.IR right ).
-If the value is to be overridden by the
-.B left=%defaultroute
-method (see above),
-an explicit value must
-.I not
-be given.
-If that method is not being used,
-but
-.B leftnexthop
-is
-.BR %defaultroute ,
-and
-.B interfaces=%defaultroute
-is used in the
-.B config
-.B setup
-section,
-the next-hop gateway address of the default-route interface
-will be used.
-The magic value
-.B %direct
-signifies a value to be filled in (by automatic keying)
-with the peer's address.
-Relevant only locally, other end need not agree on it. Currently not supported
-in IKEv2.
+.B ah
+AH authentication algorithm to be used
+for the connection, e.g.
+.B hmac-md5.
 .TP
-.B leftupdown
-what ``updown'' script to run to adjust routing and/or firewalling
-when the status of the connection
-changes (default
-.BR "ipsec _updown" ).
-May include positional parameters separated by white space
-(although this requires enclosing the whole string in quotes);
-including shell metacharacters is unwise.
-See
-.IR ipsec_pluto (8)
-for details.
-Relevant only locally, other end need not agree on it. IKEv2 uses the updown
-script to insert firewall rules only. Routing is not support and will be
-implemented directly into Charon.
+.B auth
+whether authentication should be done as part of
+ESP encryption, or separately using the AH protocol;
+acceptable values are
+.B esp
+(the default) and
+.BR ah .
+The IKEv2 daemon currently supports only ESP.
 .TP
-.B leftfirewall
-whether the left participant is doing forwarding-firewalling
-(including masquerading) for traffic from \fIleftsubnet\fR,
-which should be turned off (for traffic to the other subnet)
-once the connection is established;
+.B authby
+how the two security gateways should authenticate each other;
 acceptable values are
-.B yes
-and (the default)
-.BR no .
-May not be used in the same connection description with
-.BR leftupdown .
-Implemented as a parameter to the default
-.I updown
-script.
-See notes below.
-Relevant only locally, other end need not agree on it.
-
-If one or both security gateways are doing forwarding firewalling
-(possibly including masquerading),
-and this is specified using the firewall parameters,
-tunnels established with IPsec are exempted from it
-so that packets can flow unchanged through the tunnels.
-(This means that all subnets connected in this manner must have
-distinct, non-overlapping subnet address blocks.)
-This is done by the default
-.I updown
-script (see
-.IR ipsec_pluto (8)).
-
-In situations calling for more control,
-it may be preferable for the user to supply his own
-.I updown
-script,
-which makes the appropriate adjustments for his system.
+.B secret
+or
+.B psk
+for shared secrets,
+.B rsasig
+for RSA digital signatures (the default),
+.B secret|rsasig
+for either, and
+.B never
+if negotiation is never to be attempted or accepted (useful for shunt-only conns).
+Digital signatures are superior in every way to shared secrets. In IKEv2, the
+two ends must not agree on this parameter, it is relevant for the
+outbound authentication method only.
+IKEv1 additionally supports the values
+.B xauthpsk
+and
+.B xauthrsasig
+that will enable eXtended AUTHentication (XAUTH) in addition to IKEv1 main mode
+based on shared secrets  or digital RSA signatures, respectively.
+IKEv2 additionally supports the value
+.B eap,
+which indicates an initiator to request EAP authentication. The EAP method to 
+use is selected by the server (see
+.B eap).
 .TP
 .B auto
 what operation, if any, should be done automatically at IPsec startup;
@@ -375,8 +270,7 @@ currently-accepted values are
 ,
 .B start
 and
-.B ignore
-.
+.BR ignore .
 .B add
 loads a connection without starting it.
 .B route
@@ -396,34 +290,6 @@ both ends should use
 .B auto=start
 to ensure that any reboot causes immediate renegotiation).
 .TP
-.B auth
-whether authentication should be done as part of
-ESP encryption, or separately using the AH protocol;
-acceptable values are
-.B esp
-(the default) and
-.BR ah .
-The IKEv2 daemon currently supports only ESP.
-.TP
-.B authby
-how the two security gateways should authenticate each other;
-acceptable values are
-.B secret
-for shared secrets,
-.B rsasig
-for RSA digital signatures (the default),
-.B secret|rsasig
-for either, and
-.B never
-if negotiation is never to be attempted or accepted (useful for shunt-only conns).
-Digital signatures are superior in every way to shared secrets. In IKEv2, the
-two ends must not agree on this parameter, it is relevant for the own
-authentication method only. IKEv2 additionally supports the value
-.B eap,
-which indicates an initiator to request EAP authentication. The EAP method to 
-use is selected by the server (see
-.B eap).
-.TP
 .B compress
 whether IPComp compression of content is proposed on the connection
 (link-level compression does not work on encrypted data,
@@ -447,24 +313,26 @@ controls the use of the Dead Peer Detection protocol (DPD, RFC 3706) where
 R_U_THERE notification messages (IKEv1) or empty INFORMATIONAL messages (IKEv2)
 are periodically sent in order to check the
 liveliness of the IPsec peer. The values
-.B clear
-and
-.B hold
-both activate DPD. If no activity is detected, all connections with a dead peer
+.BR clear ,
+.BR hold ,
+and 
+.B restart
+all activate DPD. If no activity is detected, all connections with a dead peer
 are stopped and unrouted (
 .B clear
-) or put in the hold state (
+), put in the hold state (
 .B hold
-). For
-.B IKEv1
-, the default is
+) or restarted (
+.B restart
+).
+For IKEv1, the default is
 .B none
 which disables the active sending of R_U_THERE notifications.
 Nevertheless pluto will always send the DPD Vendor ID during connection set up
 in order to signal the readiness to act passively as a responder if the peer
-wants to use DPD. For
-.B IKEv2, none
-does't make sense, as all messages are used to detect dead peers. If specified,
+wants to use DPD. For IKEv2,
+.B none
+does't make sense, since all messages are used to detect dead peers. If specified,
 it has the same meaning as the default (
 .B clear
 ).
@@ -481,16 +349,28 @@ defines the timeout interval, after which all connections to a peer are deleted
 in case of inactivity. This only applies to IKEv1, in IKEv2 the default
 retransmission timeout applies, as every exchange is used to detect dead peers.
 .TP
-.B failureshunt
-what to do with packets when negotiation fails.
-The default is
-.BR none :
-no shunt;
-.BR passthrough ,
-.BR drop ,
-and
-.B reject
-have the obvious meanings. Has no effect in IKEv2 yet.
+.B eap
+defines the EAP type to be used if 
+.B authby=eap
+is selected. Acceptable values are
+.B aka
+for EAP-AKA and
+.B sim
+for EAP-SIM.
+.TP
+.B esp
+ESP encryption/authentication algorithm to be used
+for the connection, e.g.
+.B 3des-md5
+(encryption-integrity-[dh-group]). If dh-group is specified, CHILD_SA setup
+and rekeying include a separate diffe hellman exchange (IKEv2 only).
+.TP
+.B ike
+IKE/ISAKMP SA encryption/authentication algorithm to be used, e.g.
+.B aes128-sha1-modp2048
+(encryption-integrity-dhgroup). In IKEv2, multiple algorithms and proposals
+may be included, such as
+.B aes128-aes256-sha1-modp1536-modp2048,3des-sha1-md5-modp1024.
 .TP
 .B ikelifetime
 how long the keying channel of a connection ('ISAKMP/IKE SA')
@@ -545,6 +425,52 @@ although if they do not,
 there will be some clutter of superseded connections on the end
 which thinks the lifetime is longer.
 .TP
+.B left
+(required)
+the IP address of the left participant's public-network interface,
+in any form accepted by
+.IR ttoaddr (3)
+or one of several magic values.
+If it is
+.BR %defaultroute ,
+.B left
+will be filled in automatically with the local address
+of the default-route interface (as determined at IPsec startup time).
+(Either
+.B left
+or
+.B right
+may be
+.BR %defaultroute ,
+but not both.)
+The value
+.B %any
+signifies an address to be filled in (by automatic keying) during
+negotiation. The prefix
+.B  %
+in front of a fully-qualified domain name or an IP address will implicitly set
+.B leftallowany=yes.
+If the domain name cannot be resolved into an IP address at IPsec startup or update time
+then
+.B left=%any
+and
+.B leftallowany=no
+will be assumed.
+.TP
+.B leftallowany
+a modifier for
+.B left
+, making it behave as
+.B %any
+although a concrete IP address has been assigned.
+Recommended for dynamic IP addresses that can be resolved by DynDNS at IPsec startup or
+update time.
+Acceptable values are
+.B yes
+and
+.B no
+(the default).
+.TP
 .B leftca
 the distinguished name of a certificate authority which is required to
 lie in the trust path going from the left participant's certificate up
@@ -553,8 +479,7 @@ to the root certification authority.
 .B leftcert
 the path to the left participant's X.509 certificate. The file can be coded either in
 PEM or DER format. OpenPGP certificates are supported as well.
-Both absolute paths or paths relative to
-.B /etc/ipsec.d/certs
+Both absolute paths or paths relative to \fI/etc/ipsec.d/certs\fP
 are accepted. By default
 .B leftcert
 sets 
@@ -566,14 +491,57 @@ The left participant's ID can be overriden by specifying a
 .B leftid
 value which must be certified by the certificate, though.
 .TP
+.B leftfirewall
+whether the left participant is doing forwarding-firewalling
+(including masquerading) using iptables for traffic from \fIleftsubnet\fR,
+which should be turned off (for traffic to the other subnet)
+once the connection is established;
+acceptable values are
+.B yes
+and
+.B no
+(the default).
+May not be used in the same connection description with
+.BR leftupdown .
+Implemented as a parameter to the default \fBipsec _updown\fR script.
+See notes below.
+Relevant only locally, other end need not agree on it.
+
+If one or both security gateways are doing forwarding firewalling
+(possibly including masquerading),
+and this is specified using the firewall parameters,
+tunnels established with IPsec are exempted from it
+so that packets can flow unchanged through the tunnels.
+(This means that all subnets connected in this manner must have
+distinct, non-overlapping subnet address blocks.)
+This is done by the default \fBipsec _updown\fR script (see
+.IR pluto (8)).
+
+In situations calling for more control,
+it may be preferable for the user to supply his own
+.I updown
+script,
+which makes the appropriate adjustments for his system.
+.TP
 .B leftgroups
 a comma separated list of group names. If the
 .B leftgroups
 parameter is present then the peer must be a member of at least one
 of the groups defined by the parameter. Group membership must be certified
-by a valid attribute certificate stored in \fI/etc/ipsec.d/acerts\fP thas has been
+by a valid attribute certificate stored in \fI/etc/ipsec.d/acerts/\fP thas has been
 issued to the peer by a trusted Authorization Authority stored in
-\fI/etc/ipsec.d/aacerts\fP. Attribute certificates are not supported in IKEv2 yet.
+\fI/etc/ipsec.d/aacerts/\fP. Attribute certificates are not supported in IKEv2 yet.
+.TP
+.B lefthostaccess
+inserts a pair of INPUT and OUTPUT iptables rules using the default
+\fBipsec _updown\fR script, thus allowing access to the host itself
+in the case where the host's internal interface is part of the
+negotiated client subnet.
+Acceptable values are
+.B yes
+and
+.B no
+(the default).
 .TP
 .B leftid
 how
@@ -582,24 +550,67 @@ should be identified for authentication;
 defaults to
 .BR left .
 Can be an IP address (in any
-.IR ipsec_ttoaddr (3)
+.IR ttoaddr (3)
 syntax)
 or a fully-qualified domain name preceded by
 .B @
 (which is used as a literal string and not resolved).
+.TP
+.B leftnexthop
+this parameter is not needed any more because the NETKEY IPsec stack does
+not require explicit routing entries for the traffic to be tunneled.
+.TP
+.B leftprotoport
+restrict the traffic selector to a single protocol and/or port.
+Examples:
+.B leftprotoport=tcp/http
+or
+.B leftprotoport=6/80
+or
+.B leftprotoport=udp
+.TP
+.B leftrsasigkey
+the left participant's
+public key for RSA signature authentication,
+in RFC 2537 format using
+.IR ttodata (3)
+encoding.
 The magic value
-.B %myid
-stands for the current setting of \fImyid\fP.
-This is set in \fBconfig setup\fP or by \fIipsec_whack\fP(8)), or, if not set,
-it is the IP address in \fB%defaultroute\fP (if that is supported by a TXT record in its reverse domain), or otherwise
-it is the system's hostname (if that is supported by a TXT record in its forward domain), or otherwise it is undefined.
+.B %none
+means the same as not specifying a value (useful to override a default).
+The value
+.B %cert
+(the default)
+means that the key is extracted from a certificate.
+The identity used for the left participant
+must be a specific host, not
+.B %any
+or another magic value.
+.B Caution:
+if two connection descriptions
+specify different public keys for the same
+.BR leftid ,
+confusion and madness will ensue.
+.TP
+.B leftsendcert
+Accepted values are
+.B never
+or
+.BR no ,
+.B always
+or
+.BR yes ,
+and
+.BR ifasked .
 .TP
 .B leftsourceip
 The internal source IP to use in a tunnel, also known as virtual IP. If the
 value is
-.B %modeconfig
+.BR %modeconfig ,
+.BR %modecfg ,
+.BR %config ,
 or
-.B %config,
+.B %cfg,
 an address is requested from the peer. In IKEv2, a defined address is requested,
 but the server may change it. If the server does not support it, the address
 is enforced. 
@@ -611,9 +622,47 @@ value is
 on the responder side, the initiator must propose a address which is then echoed
 back.
 .TP
+.B leftsubnet
+private subnet behind the left participant, expressed as
+\fInetwork\fB/\fInetmask\fR
+(actually, any form acceptable to
+.IR ttosubnet (3));
+if omitted, essentially assumed to be \fIleft\fB/32\fR,
+signifying that the left end of the connection goes to the left participant
+only. When using IKEv2, the configured subnet of the peers may differ, the
+protocol narrows it to the greates common subnet.
+.TP
 .B leftsubnetwithin
+the peer can propose any subnet or single IP address that fits within the
+range defined by
+.BR leftsubnetwithin.
 Not relevant for IKEv2, as subnets are narrowed.
 .TP
+.B leftupdown
+what ``updown'' script to run to adjust routing and/or firewalling
+when the status of the connection
+changes (default
+.BR "ipsec _updown" ).
+May include positional parameters separated by white space
+(although this requires enclosing the whole string in quotes);
+including shell metacharacters is unwise.
+See
+.IR pluto (8)
+for details.
+Relevant only locally, other end need not agree on it. IKEv2 uses the updown
+script to insert firewall rules only. Routing is not support and will be
+implemented directly into Charon.
+.TP
+.B modeconfig
+defines which mode is used to assign a virtual IP.
+Accepted values are
+.B push
+and
+.B pull
+(the default).
+Currently relevant for IKEv1 only since IKEv2 always uses the configuration
+payload in pull mode.
+.TP
 .B pfs
 whether Perfect Forward Secrecy of keys is desired on the connection's
 keying channel
@@ -623,9 +672,20 @@ acceptable values are
 .B yes
 (the default)
 and
-.BR no
-. IKEv2 always uses PFS for IKE_SA rekeying. PFS for rekeying IPsec SAs is
-currently not supported.
+.BR no.
+IKEv2 always uses PFS for IKE_SA rekeying whereas for CHILD_SA rekeying
+PFS is enforced by defining a Diffie-Hellman modp group in the
+.B esp
+parameter.
+.TP
+.B reauth
+whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1,
+reauthentication is always done. In IKEv2, a value of
+.B no
+rekeys without uninstalling the IPsec SAs, a value of
+.B yes
+(the default) creates a new IKE_SA from scratch and tries to recreate
+all IPsec SAs.
 .TP
 .B rekey
 whether a connection should be renegotiated when it is about to expire;
@@ -634,8 +694,7 @@ acceptable values are
 (the default)
 and
 .BR no .
-The two ends need not agree,
-but while a value of
+The two ends need not agree, but while a value of
 .B no
 prevents Pluto/Charon from requesting renegotiation,
 it does not prevent responding to renegotiation requested from the other end,
@@ -643,15 +702,6 @@ so
 .B no
 will be largely ineffective unless both ends agree on it.
 .TP
-.B reauth
-whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1,
-reauthentication is always done. In IKEv2, a value of
-.B no
-rekeys without uninstalling the IPsec SAs, a value of
-.B yes
-(the default) creates a new IKE_SA from scratch and tries to recreate
-all IPsec SAs.
-.TP
 .B rekeyfuzz
 maximum percentage by which
 .B rekeymargin
@@ -661,7 +711,7 @@ acceptable values are an integer,
 which may exceed 100,
 followed by a `%'
 (default set by
-.IR ipsec_pluto (8),
+.IR pluto (8),
 currently
 .BR 100% ).
 The value of
@@ -684,24 +734,36 @@ begin; acceptable values as for
 .BR 9m ).
 Relevant only locally, other end need not agree on it.
 .TP
-.B ike
-IKE/ISAKMP SA encryption/authentication algorithm to be used, e.g.
-.B aes128-sha1-modp2048
-(encryption-integrity-dhgroup). In IKEv2, multiple algorithms and proposals
-may be included, such as
-.B aes128-aes256-sha1-modp1536-modp2048,3des-sha1-md5-modp1024.
-.TP
-.B esp
-ESP encryption/authentication algorithm to be used
-for the connection, e.g.
-.B 3des-md5
-(encryption-integrity-[dh-group]). If dh-group is specified, CHILD_SA setup
-and rekeying include a separate diffe hellman exchange (IKEv2 only).
+.B type
+the type of the connection; currently the accepted values
+are
+.B tunnel
+(the default)
+signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel;
+.BR transport ,
+signifying host-to-host transport mode;
+.BR passthrough ,
+signifying that no IPsec processing should be done at all;
+.BR drop ,
+signifying that packets should be discarded; and
+.BR reject ,
+signifying that packets should be discarded and a diagnostic ICMP returned.
+Charon currently supports only 
+.BR tunnel
+and
+.BR transport
+connection types.
 .TP
-.B ah
-AH authentication algorithm to be used
-for the connection, e.g.
-.B hmac-md5.
+.B xauth
+specifies the role in the XAUTH protocol if activated by
+.B authby=xauthpsk
+or
+.B authby=xauthrsasig.
+Accepted values are
+.B server
+and
+.B client
+(the default).
 .SH "CA SECTIONS"
 This are optional sections that can be used to assign special
 parameters to a Certification Authority (CA). These parameters are not 
@@ -721,14 +783,25 @@ defines a path to the CA certificate either relative to
 .B crluri
 defines a CRL distribution point (ldap, http, or file URI)
 .TP
+.B crluri1
+synonym for
+.B crluri.
+.TP
 .B crluri2
 defines an alternative CRL distribution point (ldap, http, or file URI)
 .TP
 .B ldaphost
-defines an ldap host.
+defines an ldap host. Currently used by IKEv1 only.
 .TP
 .B ocspuri
 defines an OCSP URI.
+.TP
+.B ocspuri1
+synonym for
+.B ocspuri.
+.TP
+.B ocspuri2
+defines an alternative OCSP URI. Currently used by IKEv2 only.
 .SH "CONFIG SECTIONS"
 At present, the only
 .B config
@@ -736,7 +809,7 @@ section known to the IPsec software is the one named
 .BR setup ,
 which contains information used when the software is being started
 (see
-.IR ipsec_setup (8)).
+.IR starter (8)).
 Here's an example:
 .PP
 .ne 8
@@ -744,10 +817,9 @@ Here's an example:
 .ft B
 .ta 1c
 config setup
-	interfaces="ipsec0=eth1 ipsec1=ppp0"
-	klipsdebug=none
 	plutodebug=all
-	manualstart=
+	crlcheckinterval=10m
+	strictcrlpolicy=yes
 .ft
 .fi
 .PP
@@ -759,78 +831,107 @@ names in a
 .B setup
 section are:
 .TP 14
-.B myid
-the identity to be used for
-.BR %myid .
-.B %myid
-is used in the implicit policy group conns and can be used as
-an identity in explicit conns.
-If unspecified,
-.B %myid
-is set to the IP address in \fB%defaultroute\fP (if that is supported by a TXT record in its reverse domain), or otherwise
-the system's hostname (if that is supported by a TXT record in its forward domain), or otherwise it is undefined.
-An explicit value generally starts with ``\fB@\fP''.
-.TP
-.B interfaces
-virtual and physical interfaces for IPsec to use:
-a single
-\fIvirtual\fB=\fIphysical\fR pair, a (quoted!) list of pairs separated
-by white space, or
-.BR %none .
-One of the pairs may be written as
-.BR %defaultroute ,
-which means: find the interface \fId\fR that the default route points to,
-and then act as if the value was ``\fBipsec0=\fId\fR''.
-.B %defaultroute
-is the default;
-.B %none
-must be used to denote no interfaces.
-If
-.B %defaultroute
-is used (implicitly or explicitly)
-information about the default route and its interface is noted for
-use by
-.IR ipsec_manual (8)
+.B cachecrls
+certificate revocation lists (CRLs) fetched via http or ldap will be cached in
+\fI/etc/ipsec.d/crls/\fR under a unique file name derived from the certification
+authority's public key.
+Accepted values are
+.B yes
 and
-.IR ipsec_auto (8).)
-.TP
-.B forwardcontrol
-whether
-.I setup
-should turn IP forwarding on
-(if it's not already on) as IPsec is started,
-and turn it off again (if it was off) as IPsec is stopped;
-acceptable values are
+.B no
+(the default).
+.TP
+.B charonstart
+whether to start the IKEv2 Charon daemon or not.
+Accepted values are
+.B yes
+(the default)
+or
+.BR no .
+.TP
+.B crlcheckinterval
+interval in seconds. CRL fetching is enabled if the value is greater than zero.
+Asynchronous, periodic checking for fresh CRLs is currently done by the
+IKEv1 Pluto daemon only.
+.TP
+.B dumpdir
+in what directory should things started by \fBipsec starter\fR
+(notably the Pluto and Charon daemons) be allowed to dump core?
+The empty value (the default) means they are not
+allowed to.
+This feature is currently not yet supported by \fBipsec starter\fR.
+.TP
+.B plutostart
+whether to start the IKEv1 Pluto daemon or not.
+Accepted values are
 .B yes
-and (the default)
+(the default)
+or
 .BR no .
-For this to have full effect, forwarding must be
-disabled before the hardware interfaces are brought
-up (e.g.,
-.B "net.ipv4.ip_forward\ =\ 0"
-in Red Hat 6.x
-.IR /etc/sysctl.conf ),
-because IPsec doesn't get control early enough to do that.
-.TP
-.B rp_filter
-whether and how
-.I setup
-should adjust the reverse path filtering mechanism for the
-physical devices to be used.
-Values are \fB%unchanged\fP (to leave it alone)
-or \fB0\fP, \fB1\fP, \fB2\fP (values to set it to).
-\fI/proc/sys/net/ipv4/conf/PHYS/rp_filter\fP
-is badly documented; it must be \fB0\fP in many cases
-for ipsec to function.
-The default value for the parameter is \fB0\fP.
-.TP
-.B syslog
-the
-.IR syslog (2)
-``facility'' name and priority to use for
-startup/shutdown log messages,
-default
-.BR daemon.error .
+.TP
+.B strictcrlpolicy
+defines if a fresh CRL must be available in order for the peer authentication based
+on RSA signatures to succeed.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+IKEv2 additionally recognizes
+.B ifuri
+which reverts to
+.B yes
+if at least one CRL URI is defined and to
+.B no
+if no URI is known.
+.PP
+The following
+.B config section
+parameters are used by the IKEv1 Pluto daemon only:
+.TP
+.B keep_alive
+interval in seconds between NAT keep alive packets, the default being 20 seconds.
+.TP
+.B nat_traversal
+activates NAT traversal by accepting source ISAKMP ports different from udp/500 and
+being able of floating to udp/4500 if a NAT situation is detected.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+.B nocrsend
+no certificate request payloads will be sent.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+Used by IKEv1 only, NAT traversal always being active in IKEv2.
+.TP
+.B pkcs11initargs
+non-standard argument string for PKCS#11 C_Initialize() function;
+required by NSS softoken.
+.TP
+.B pkcs11module
+defines the path to a dynamically loadable PKCS #11 library.
+.TP
+.B pkcs11keepstate
+PKCS #11 login sessions will be kept during the whole lifetime of the keying
+daemon. Useful with pin-pad smart card readers.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.B pkcs11proxy
+Pluto will act as a PKCS #11 proxy accessible via the whack interface.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
 .TP
 .B plutodebug
 how much Pluto debugging output should be logged.
@@ -847,57 +948,11 @@ Otherwise only the specified types of output
 prefix,
 separated by white space) are enabled;
 for details on available debugging types, see
-.IR ipsec_pluto (8).
-.TP
-.B charondebug
-how much Charon debugging output should be logged.
-A comma separated list containing type level/pairs may
-be specified, e.g:
-.B dmn 3, ike 1, net -1.
-Acceptable values for types are
-.B dmn, mgr, ike, chd, job, cfg, knl, net, enc, lib
-and the level is one of
-.B -1, 0, 1, 2, 3, 4
-(for silent, audit, control, controlmore, raw, private)
+.IR pluto (8).
 .TP
-.B plutoopts
-additional options to pass to pluto upon startup. See
-.IR ipsec_pluto (8).
-.TP
-.B plutostderrlog
-do not use syslog, but rather log to stderr, and direct stderr to the
-argument file.
-.TP
-.B dumpdir
-in what directory should things started by
-.I setup
-(notably the Pluto daemon) be allowed to
-dump core?
-The empty value (the default) means they are not
-allowed to.
-.TP
-.B pluto
-whether to start Pluto or not;
-Values are
-.B yes
-(the default)
-or
-.B no
-(useful only in special circumstances).
-.TP
-.B plutowait
-should Pluto wait for each
-negotiation attempt that is part of startup to
-finish before proceeding with the next?
-Values are
-.B yes
-or
-.BR no
-(the default).
-.TP
-.B prepluto
-shell command to run before starting Pluto
-(e.g., to decrypt an encrypted copy of the
+.B postpluto
+shell command to run after starting Pluto
+(e.g., to remove a decrypted copy of the
 .I ipsec.secrets
 file).
 It's run in a very simple way;
@@ -908,9 +963,9 @@ so running interactive commands is difficult unless they use
 or equivalent for their interaction.
 Default is none.
 .TP
-.B postpluto
-shell command to run after starting Pluto
-(e.g., to remove a decrypted copy of the
+.B prepluto
+shell command to run before starting Pluto
+(e.g., to decrypt an encrypted copy of the
 .I ipsec.secrets
 file).
 It's run in a very simple way;
@@ -921,6 +976,43 @@ so running interactive commands is difficult unless they use
 or equivalent for their interaction.
 Default is none.
 .TP
+.B virtual_private
+defines private networks using a wildcard notation.
+.TP
+.B uniqueids
+whether a particular participant ID should be kept unique,
+with any new (automatically keyed)
+connection using an ID from a different IP address
+deemed to replace all old ones using that ID;
+acceptable values are
+.B yes
+(the default)
+and
+.BR no .
+Participant IDs normally \fIare\fR unique,
+so a new (automatically-keyed) connection using the same ID is
+almost invariably intended to replace an old one.
+.PP
+The following
+.B config section
+parameters are used by the IKEv2 Charon daemon only:
+.TP
+.B charondebug
+how much Charon debugging output should be logged.
+A comma separated list containing type level/pairs may
+be specified, e.g:
+.B dmn 3, ike 1, net -1.
+Acceptable values for types are
+.B dmn, mgr, ike, chd, job, cfg, knl, net, enc, lib
+and the level is one of
+.B -1, 0, 1, 2, 3, 4
+(for silent, audit, control, controlmore, raw, private).
+.PP
+The following
+.B config section
+parameters only make sense if the KLIPS IPsec stack
+is used instead of the default NETKEY stack of the Linux 2.6 kernel:
+.TP
 .B fragicmp
 whether a tunnel's need to fragment a packet should be reported
 back with an ICMP message,
@@ -939,37 +1031,26 @@ acceptable values are
 .B yes
 (the default)
 and
-.BR no .
+.BR no
 .TP
-.B uniqueids
-whether a particular participant ID should be kept unique,
-with any new (automatically keyed)
-connection using an ID from a different IP address
-deemed to replace all old ones using that ID;
-acceptable values are
-.B yes
-(the default)
-and
-.BR no .
-Participant IDs normally \fIare\fR unique,
-so a new (automatically-keyed) connection using the same ID is
-almost invariably intended to replace an old one.
+.B interfaces
+virtual and physical interfaces for IPsec to use:
+a single
+\fIvirtual\fB=\fIphysical\fR pair, a (quoted!) list of pairs separated
+by white space, or
+.BR %none .
+One of the pairs may be written as
+.BR %defaultroute ,
+which means: find the interface \fId\fR that the default route points to,
+and then act as if the value was ``\fBipsec0=\fId\fR''.
+.B %defaultroute
+is the default;
+.B %none
+must be used to denote no interfaces.
 .TP
 .B overridemtu
 value that the MTU of the ipsec\fIn\fR interface(s) should be set to,
 overriding IPsec's (large) default.
-This parameter is needed only in special situations.
-.TP
-.B nat_traversal
-.TP
-.B crlcheckinterval
-.TP
-.B strictcrlpolicy
-.TP
-.B pkcs11module
-.TP
-.B pkcs11keepstate
-
 .SH CHOOSING A CONNECTION
 .PP
 When choosing a connection to apply to an outbound packet caught with a 
@@ -988,87 +1069,20 @@ information about the client subnets to complete the instantiation.
 .SH FILES
 .nf
 /etc/ipsec.conf
+/etc/ipsec.d/aacerts
+/etc/ipsec.d/acerts
 /etc/ipsec.d/cacerts
 /etc/ipsec.d/certs
 /etc/ipsec.d/crls
-/etc/ipsec.d/aacerts
-/etc/ipsec.d/acerts
 
 .SH SEE ALSO
-ipsec(8), ipsec_ttoaddr(8), ipsec_auto(8), ipsec_manual(8), ipsec_rsasigkey(8)
+ipsec(8), pluto(8), starter(8), ttoaddr(3), ttodata(3)
 .SH HISTORY
-Written  for  the  FreeS/WAN project
-<http://www.freeswan.org>
-by Henry Spencer.  Extended for the strongSwan project
+Written  for  the  FreeS/WAN project by Henry Spencer.
+Extended for the strongSwan project
 <http://www.strongswan.org>
-by Andreas Steffen. Updated to respect IKEv2 specific configuration
-by Martin Willi.
+by Andreas Steffen. IKEv2-specific features by Martin Willi.
 .SH BUGS
 .PP
-When
-.B type
-or 
-.B failureshunt
-is set to
-.B drop
-or
-.BR reject,
-strongSwan blocks outbound packets using eroutes, but assumes inbound
-blocking is handled by the firewall. strongSwan offers firewall hooks 
-via an ``updown'' script.  However, the default 
-.B ipsec _updown
-provides no help in controlling a modern firewall.
-.PP
-Including attributes of the keying channel
-(authentication methods,
-.BR ikelifetime ,
-etc.)
-as an attribute of a connection,
-rather than of a participant pair, is dubious and incurs limitations.
-.PP
-.IR Ipsec_manual
-is not nearly as generous about the syntax of subnets,
-addresses, etc. as the usual strongSwan user interfaces.
-Four-component dotted-decimal must be used for all addresses.
-It
-.I is
-smart enough to translate bit-count netmasks to dotted-decimal form.
-.PP
-It would be good to have a line-continuation syntax,
-especially for the very long lines involved in
-RSA signature keys.
-.PP
-The ability to specify different identities,
-.BR authby ,
-and public keys for different automatic-keyed connections
-between the same participants is misleading;
-this doesn't work dependably because the identity of the participants
-is not known early enough.
-This is especially awkward for the ``Road Warrior'' case,
-where the remote IP address is specified as
-.BR 0.0.0.0 ,
-and that is considered to be the ``participant'' for such connections.
-.PP
-In principle it might be necessary to control MTU on an
-interface-by-interface basis,
-rather than with the single global override that
-.B overridemtu
-provides.
-.PP
-A number of features which \fIcould\fR be implemented in
-both manual and automatic keying
-actually are not yet implemented for manual keying.
-This is unlikely to be fixed any time soon.
-.PP
-If conns are to be added before DNS is available,
-\fBleft=\fP\fIFQDN\fP,
-\fBleftnextop=\fP\fIFQDN\fP,
-and
-.B leftrsasigkey=%dnsonload
+If conns are to be added before DNS is available, \fBleft=\fP\fIFQDN\fP
 will fail.
-.IR ipsec_pluto (8)
-does not actually use the public key for our side of a conn but it
-isn't generally known at a add-time which side is ours (Road Warrior
-and Opportunistic conns are currently exceptions).
-.PP
-The \fBmyid\fP option does not affect explicit \fB ipsec auto \-\-add\fP or \fBipsec auto \-\-replace\fP commands for implicit conns.