Re: Draft of new ipsec.conf text.

-----BEGIN PGP SIGNED MESSAGE-----


| From: Claudia Schmeing <[email protected]>

Here are my too-rushed reactions.

| POLICY GROUP FILES
| 
| 
| The optional files under /etc/ipsec.d/policy are text files. 
| Each consists of a list of CIDR blocks, one per line.
| White space followed by # followed by anything to the end of the line 
| is a comment and is ignored, as are empty lines.
| 
| Policy groups are loaded at system start or with
|     ipsec setup --rereadgroups

Somehow the point should be made that the existence of the policy
group conn is what causes the particular file to be used, not the
other way around.

| When a policy group is loaded, the system instantiates a connection
| of the same name, once for each listed CIDR block. 
| That connection must have _right=%group_ or _right=%opportunisticgroup_,
| and the system substitutes one of the listed CIDR blocks for _right_.
| The system treats the resulting instances as normal connections.
| 
| For example, given a suitable connection definition _private_,
| and the file /etc/ipsec.d/policy/private with an entry 192.0.2.3,
| the system creates a connection instance private#192.0.2.3.
| This connection inherits all details from _private_, except that its
| right client is 192.0.2.3.
| 
| 
| Choosing a connection
| 
| 
| When choosing a connection instance,

For what purpose?

When choosing the connection to apply to an outbound packet caught by
a %trap.

and

When choosing a connection to use to respond to a negotiation which
doesn't match an ordinary conn.  A suitable opportunistic connection
will be instantiate.  Eventually, the instance will be /32 -> 32, but
for earlier stages of the negotiation, there will not be enough
information about the client subnets to complete the instantiation.

<aside, not appropriate here in man page; somewhere else?>
- - other (outbound) initiation is by connection name, so guessing is not
  needed
- - currently no inbound trapping.
- - (inbound) responding involves more information from the other side:
  Phase 1 ID payload, Phase 2 ID payloads (client subnets, if any).
- - sometimes responding ends up requiring the instantion of an
  opportunistic connection
<end of aside>

The connection chosen is that with the most specific eroute that
includes the packet's source and destination IP addresses.

Of all the eroutes that cover the packet, pick from the ones with the
most specific subnet (CIDR block) on our side.
Of those, pick the one with the most specific subnet on our side.

| the system prefers the one with
| the most specific eroute. It first examines eroute sources, 
| and if two or more sources are identical, it compares the eroutes' destinations.


|     (Is there a bug here that needs documenting? General vs. instantiated?)

Probably not serious since

(1) all opportunistic instantiation involves
/32 -> /32.  If it once was appropriate, it probably remains so.
Problem does arise during transition (i.e. when original policy is
removed).

(2) R/W instantiation does not change client subnets UNLESS the RW is
just acting for itself, a /32.

A property of a /32 is that there is nothing smaller.

| The system therefore only uses a connection instance derived from a policy
| group file, if that instance is most specific for the endpoints in question.
| 
| If a more specific connection is found, the system attempts to use that 
| connection. If that connection is up, the system will use it. If it is routed, 
| the system will bring it up. If it is added to the internal database but not 
| routed, the system will not use it, but will log a warning.

For initiating, only routed connections are considered.  That is
essentially the meaning or "routed" to Pluto -- an eroute and route
are in place.

For responding, unrouted (but --added) connections are considered.

| 
| 
| Implicit Policy Groups
| 
| The standard FreeS/WAN install includes several policy groups 
| which provide a way of classifying possible clients into security classes. 
| These implicit policies apply to the FreeS/WAN host only.
| 
| Private is for those the local host talks with encrypted only.

Case matters, and it must be all lower case.

I think that this part (to the end) could be made much more concise and hence
easier to absorb.

| Private-or-clear is for those the local host attempts to talk with 
| encrypted, but is willing to talk with in the clear. Clear-or-private
| allows talk in the clear, but also allows the remote host to initiate 
| encrypted communication. Clear allows only clear communication, while
| block allows no communication.
| 
| These are implemented by the following implicit connections.
| 
| 
| private
| 
| The system allows only IPsec secured communication to the listed 
| CIDR blocks.
| 
| For outbound traffic, the system implements this as follows.
| 
| [note to self: I am concerned about the ambiguity in "For outbound/inbound
| traffic. May have to explain trigger mechanism for OE to get around this.
| May have to explain that anyway.]
| 
| If no other connection takes precedence, the system attempts to create an 
| IPsec connection opportunistically, by instantiating an instance of the
| the _private_ implicit connection for relevant hosts within the listed CIDR
| blocks.
| 
| For example, if the private file contains the CIDR block 192.0.2.3,
| and system has created the instance private#192.0.2.3 where
| right=192.0.2.3, the system will again instantiate this instance.
| The result is a new connection between the two /32 endpoints which triggered
| the opportunistic connection.
| 
| If the opportunistic attempt fails, the system blocks traffic.
| Outbound blocking is done using eroutes. Inbound blocking is assumed to 
| be handled by the firewall, for which we give you no assistance yet.
| 
| If no other connection takes precedence, the system accepts requests to 
| establish IPsec connections opportunistically for hosts within the listed 
| CIDR blocks. 
| 
| If no such request occurs, or if the connection attempt
| fails, the system blocks traffic as described above.
| 
| 
| 
| 
| private-or-clear
| 
| The system attempts IPsec secured communication from the host to the 
| listed CIDR blocks. On failure, it allows communication without IPsec.
| 
| For outbound traffic, the system implements this as follows.
| 
| If no other connection takes precedence, the system attempts to create an
| IPsec connection opportunistically, by instantiating an instance of the
| the _private_ IMPLICIT conn for relevant hosts within the listed
| CIDR blocks.
| 
| If the opportunistic attempt fails, the system sends traffic without 
| IPsec protection.
| 
| For inbound traffic, if no other connection takes precedence, the system 
| accepts requests to establish IPsec connections opportunistically
| for hosts within the listed CIDR blocks. 
| If the system has not begun to negotiate such a connection, it accepts 
| traffic in the clear.
| 
| 
| clear-or-private
| 
| The system allows communication without IPsec to the listed CIDR blocks. 
| If the peer requests IPsec communication, the system will allow it.
|  
| 
| If no other connection takes precedence, the system accepts inbound requests 
| to establish opportunistic connections for hosts within the listed CIDR blocks.
| 
| If no other connection takes precedence, and no suitable connection is up, 
| the system sends and accepts traffic in the clear.
| 
| 
| clear
| 
| The system allows communication to the listed CIDR blocks, but
| only without IPsec.
| 
| If no other connection takes precedence, the system makes no attempt to 
| establish IPsec connections for hosts within these CIDR blocks,
| and rejects requests for such connections.
| 
| 
| block
| 
| The system blocks traffic to and from the listed CIDR blocks.
| 
| Outbound blocking is done using eroutes. Inbound blocking is assumed to be 
| handled by the firewall, for which we give you no assistance yet.

"we" -> FreeS/WAN.

We give a hook (updown script), but no out-of-box suggested serving.

Hugh Redelmeier
[email protected]  voice: +1 416 482-8253

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPlVpNMFAuQPManGZAQFUxAP/VV5kIZXW5WaDLI2BjWvGRWaDsX1MtZGY
vZiR4NBqPLt/6twL49wlC8UzMpu2Xlm2Ov5s9Bx0AAhqDfuILG1aav1jWmKxNuao
Y4JJYwOb9j/EogkwwqWvspTdNvtGd+RWSBGMbtNOUnzJ/nNzmG6sIYocNG+WXMOS
s9Vs8O2nB/E=
=vOdA
-----END PGP SIGNATURE-----