[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nested SAs
Lee Rafalow wrote:
> Here's an outline of the solution we worked out after the meeting in
> There's an aggregation called SAActionInRule that specifies the order in
> which actions are performed. The -02 model says that these are fallback
> The proposal for the -03 draft is that we change the semantic of
> SAActionInRule.ActionOrder to be the order in which multiple actions are to
> be executed and add a new property, SAActionInRule.FallbackOrder, that
> specifies the fallback actions.
> So, for example, an SARule has 5 aggregated actions.
> (ao: actionorder, fo: fallbackorder)
> ao=1,fo=0 : first action to execute, e.g., establish SA to gateway
> ao=1,fo=1 : if the first action fails, try this one, e.g., try a different
> ao=1,fo=2 : if that doesn't work, try this next one, e.g., deny
> ao=2,fo=0 : second action to execute, e.g., establish tunneled SA thru
> ao=2,fo=1 : if the second action fails, try this one, e.g., deny
> This does not address complicated cases where the second action is dependent
> on the result of the first action. For that you need multiple rules. Nor
> does it address if or when the SA that resulted from the first pair of
> actions should be torn down if the second action ends up failing (e.g.,
> deny), i.e., there's no commit/rollback semantic.
> Does this meet the requirements?
Our implementation will require action chaining as well as a fallback
action chain. Of the actions we chain, only one will be IPsec, others
would be things like NAT, QOS, ... It sound to me like your model (-03
proposal) can satisfy our requirements. Except that I don't like the
name SAActionInRule. Could we add a layer ActionInRule that has the
properties you describe and can have SAActions attached and if people so
develop, other actions attached as well?
Ricky Charlet : Redcreek Communications : usa (510) 795-6903