[Design] pluto: prioritizing connections and bare shunts

-----BEGIN PGP SIGNED MESSAGE-----
[Warning: subtle and boring stuff follows.]

When Pluto is searching for a policy to apply, i.e. a connection to use, it used to choose:

	Among the connections that apply to the traffic,
	consider only those with of the most specific source subnet.
	Among those, choose the one with the most specific
	destination subnet.

This isn't a bad logic. It specifies how to choose between policies (for "policy", read "connection").

After a bit of experience with policy groups, it seems as if connection instances should have the same "priority" as the connection templates from which they were derived.

I've changed Pluto so that each connection (and each bare shunt) gets a priority. These priorities are used to select the connection to use when a packet is intercepted for OE.

The priority of a policy is related strongly to the previous policy. For a non-instance connection, the priority is the length of the source subnet mask << 16 + the length of the destination subnet mask << 8 + 1. (The +1 is so that 0 can be a distinct lowest priority.)

The connection==policy that applies to traffic and has the highest priority is exactly the same as the one chosen by the former logic.

But there is a twist. When instantiating a connection (for OE or Road Warrior), the priority is inherited from the connection template. This is a difference. I think that it is better. But where is it different?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

The fact is that unless the set of policies changes after an instantiation, the result should in fact be the same. Why? Because the instance reflects the result of a previous policy choice. If the set of policies hasn't changed, the result should not change.

The use of priorities makes policy transitions easier to get "right". Pluto has problems with transitions in policy groups. It trips over itself. The priorities are a tool that will be used to address this problem.

More to come.

Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253

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

iQCVAwUBPoKg98FAuQPManGZAQGpgwQAg9pZcs0/rfZ2yiK3VFSXt8VAUnvdVzt8 7eeGh2U021iadEBTy7lR0EEywDULsGjCN3ZQ6MDUjCASiuz1adwbv8wvyhGFGZcH gfih754nU06BpdGhD4DTaSs+VhnwBuRgSXVj7LcqUPq9m3sF+5NF2BH1BYmIDGD9 fF4ojpOxLrw=
=R+Yh
-----END PGP SIGNATURE-----