Re: IPsec xfrm resolution

[Patrick McHardy <kaber@trash.net>]

Herbert Xu wrote:

>On Fri, Feb 18, 2005 at 12:26:57AM +0100, Patrick McHardy wrote:
>  
>
>>I'm not sure yet how to deal with optional SAs. We shouldn't add
>>incomplete optional tunnel mode SAs to the bundle because then we
>>can't determine the output device, but if we don't nothing will
>>trigger resolving of optional SAs following a non-optional SA that
>>needs to be resolved.
>>    
>>
>
>I don't get it.  Can't you just add it into the bundle but ignore it
>for dst->output and other calculations until it's either realised or
>removed?
>  
>
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
- netfilter LOCAL_OUT hook sees incorrect output device
- strict source routing check done with incorrect rt_gateway

Simply ignoring these SAs if they are not available when the bundle is
created looks like the easiest solution to me.

>>I thought about adding the queue to the xfrm_dst and adding a dummy
>>xfrm_state with a selector that matches only the current flow. This
>>    
>>
>
>The inner flow is probably not the best key for this.  How about
>keying it using the outer remote address on the template? The SAs
>have a bydst hash which makes this easy to look up.
>
>So we would attach each packet to a queue shared by all SAs to a
>specific (outer) remote address.
>  
>
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.

Regards
Patrick