On Sun, Mar 20, 2005 at 06:49:43PM +0100, Patrick McHardy wrote:

quoted

- I have no idea beforehand what address ranges are going to be routed
 over this vlan.  (Customers might send traffic with source addresses
 in address ranges that they don't announce to us (asymmetric routing),
 and I don't want those packets to remain unencrypted just because they
 don't match the SPD rule.)  A 0.0.0.0/0 0.0.0.0/0 rule would not be
 appropriate either since that'd suck _all_ traffic into this tunnel

You can specify an ifindex for oif in the selector, but you need
to use the xfrm_user interface.

Unfortunately that doesn't work currently because we don't fill in
the oif field in the flow.  More importantly, having an interface
specific outbound policy isn't very useful when you can't have an
interface specific inbound/forward policy to match.

This actually leads to another issue.  The xfrm_selector structure
only contains one iface field.  So we can't specify both iif and oif
for forwarded packets.

Extending xfrm_selector is not trivial.  Ludo Stellingwerff also
wanted to do that in order use fwmark in the selector.

Here is one possible solution that allows xfrm_selector to be
extended.

We store new selector fields in a separate netlink payload.  This
works because all the current messages that carry xfrm_selector carry
exactly one selector.

When the kernel receives a message containing an xfrm_selector it'll
initialise the kernel xfrm_selector to contain that plus whatever
is in the correspond netlink payload.  If the payload is absent the
kernel should fill in sane default values for compatibility.

For messages sent by the kernel we also attach a netlink payload to
cover the new values.  This should be backwards compatible as appliations
should ignore unknown payloads.

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