On Sat, Feb 19, 2005 at 07:03:32AM +0100, Patrick McHardy wrote:
>
> An optional tunnel mode SA might change peer/dev/rt_gateway/rt_type if
> successfully resolved. This introduces a couple of problems:
>
> - MTU estimatation impossible
This is OK for two reasons:
1) The application must be able to react to MTU changes anyway.
2) The most common use for optional SAs is IPCOMP which has zero overhead.
Actually, 2) gives us the real reason why we must include optional SAs.
Even though we can skip the compression of a tunnel mode IPCOMP SA, we
must perform the IPIP encapsulation.
> - netfilter LOCAL_OUT hook sees incorrect output device
> - strict source routing check done with incorrect rt_gateway
Once you take the above into account these turn out to be non-issues.
If the optional SA is transport mode, then the route is identical with
or without it. If it's tunnel mode, then we must perform the IPIP
encapsulation regardless.
> That sounds reasonable. The selector initialized to the inner flow is
> meant for cacheing the incomplete bundle at the policy. We can have
> multiple SAs with equal family/reqid/saddr/daddr/mode/proto differing
> only be SPI and selector. If we use a selector selecting more than the
> inner flow we could create a conflict with an already existing cached
> bundle.
Agreed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
|