Re: nested SAs

[Ricky Charlet <rcharlet@xxxxxxxxxxxx>]

Lee Rafalow wrote:
> 
> Here's an outline of the solution we worked out after the meeting in
> Minneapolis.
> 
> There's an aggregation called SAActionInRule that specifies the order in
> which actions are performed.  The -02 model says that these are fallback
> actions.
> 
> 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
> gateway
> 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
> gateway
> 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?
> 


Howdy,
	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