[Openswan dev] Re: per-X controls

[Herbert Xu]

On Fri, Oct 28, 2005 at 12:39:46PM -0400, Michael Richardson wrote:
> 
> A number of people have problems with pluto where it creates policies 
> from templates with the wrong granularity. A lot of this has to do with
> lack of controls added when protocol and port selectors were added, and
> this is compounded by transport-mode SAs and NAT.

The Linux modus operandi is to forget about selectors and simply use the
reqid to tie larval states to policies.  So the larval state is always
at the same width as the policy/policies that generated it.

> For instance, it is now difficult to create a template that says to create
> a transport-mode SA where the origin port does not matter, but the
> destination port does.  I think that an example is of an L2TP transport
> mode SA behind a NAT.  

I'm not sure that I understand your example correctly.

1) For the L2TP server case you should already know what the full selector
is since you're receiving a new connection from the client.  In fact, if
you don't know what the client's source port is you can't create a policy
at all.

2) For the L2TP client case you already know the server address which
allows you to specify a selector even using today's pluto configuration
language:

leftsubnet=
rightsubnet=
leftprotoport=udp/0
rightprotoport=udp/1701

In the Linux stack case, the policy will receive exactly that as the
selector which when combined with a unique reqid produces the desired
behaviour.

> The problem is that the templates may get instantiated with various
> fields filled in or not. 
> 
> I'm about to introduce new keywords:
> 	  perhost
> 	  pertransport	(or "perprotocol")
> 	  leftperport
> 	  rightperport

So I'm afraid I don't understand the need for these yet.  Perhaps
they're more useful in an opportunistic encryption setup?
 
> I would like to express these values to the kernel, such that
> appropriate %hold eroutes can be made.  This may require some revision
> to the policy interface and to the ACQUIRE interface, so should occur
> later. (I would like the ACQUIRE interface to provide ~96 bytes of the
> header of the packet that caused the ACQUIRE, as well as cooked
> values. This should let us do more intelligent things later on. 96 gets
> IPv6 + transport header)

Currently Linux sets the larval state's selector to the narrowest possible
value which lets you identify the session uniquely.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt