On Sun, Jul 31, 2005 at 10:03:05PM -0700, David S. Miller wrote: > > We can avoid the flushing damage to DSTs of the effected policy. > At least I think we can do that cleanly. Do you think that is > a middle ground that might be acceptable to you?
It's acceptable with some blanks filled in :) > My mind is fuzzy on this, is there a many to one relationship > from SAs to policies? If so, my idea is dead in the water. > If not, read on :-) It is theoretically many to one. However, in practice the number is usually one with the popular KMs. > When an SA changes, we walk that assosciated policies DST list > marking them ->obsolete Yes this should work but it's missing one important detail. The question is how do we actually find the SA that changed. When the user adds the replacement SA, there is no direct information as to which existing SA it is supposed to replace. So we'll need to figure this out if we're to implement this in the kernel. The reason I was suggesting that we let the KMs handle it is because they already know which existing SA the new one is meant to replace. One workable heuristic would be to flush all SAs going to the same destination address. The only drawback of course is that when NAT is involved this could degenerate into flushing all SAs. So I suggest that we control this with a global toggle. We might also be able to use the reqid to narrow down on SA but it isn't always set by all KMs. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
