RE: IPSP policy model: contidtions and actions

["Jason, Jamie" <jamie.jason@xxxxxxxxx>]

I agree that this is of paramount of importance.  Since we will all be using
at least the "core" filters (like IPs, ports, protocol), it makes sense to
define it outside of each respective model.  I had hoped that by including
filter information in our model it would precipitate a discussion about what
is domain specific and what is generic (I believe that in Oslo, I mentioned
that we would eventually have to confront the issue of useful classes not
already defined by PCIM - and filters would be one of them).

Jamie

> -----Original Message-----
> From: Wang, Cliff [mailto:CWang@xxxxxxxxxxxxxx]
> Sent: Wednesday, December 13, 2000 4:35 PM
> To: 'ipsec-policy@xxxxxxxx'
> Subject: RE: IPSP policy model: contidtions and actions
> 
> 
> One of the working group items of this morning's policy 
> framework meeting is
> to look into the
> filter issues to see whether they can be unified. From the 
> implementation
> point of view,
> a unified approach is a MUST while at the different modeling 
> levels, people
> can do what they think
> the best approaches. But an unified approach should be the 
> goal, if it can
> be achieved.
> 
> -----Original Message-----
> From: Ricky Charlet [mailto:rcharlet@xxxxxxxxxxxx]
> Sent: Wednesday, December 13, 2000 5:13 PM
> To: "ipsec-policy@xxxxxxxx, Ricky Charlet"
> Subject: IPSP policy model: contidtions and actions
> 
> 
> Howdy,	
> 
> 	I think that the IPSP policy model puts conditions in the wrong
> place. 
> SAConditions are contained by SARules which are derived from 
> the Policy 
> Core Information Model's Policy Rule. The problem I see here is that 
> SAConditions are too specific to IPsec. I would rather see a 
> model which 
> sets up generic conditions to classify packets. Once a packet 
> is classify 
> by generalized conditions, then various actions (ie. ipsec, 
> qos, nat,...) 
> could be applied in a list of actions.
> 
> 	Now, to do this would require tremendous coordination 
> between all
> groups 
> who might have an interest in packet classification. We know 
> that right 
> now, the qos and ipsec ways of modeling conditions or filters or are 
> disjoint. So I am making a recommendation which will require 
> a good bit of 
> cross WG work and might perhaps move slowly.
> 
> 	So what would be the benefit?
> 
> 	If current trends hold, and each group who has an interest in
> classifying 
> packets develops its own classification method, then we are 
> very close to 
> requiring that unnecessarily repetitive classification 
> operations be done 
> for each action which should be applied to the packet. It 
> should be easy 
> for us to envision examples where several actions (ipsec, qos, nat, 
> firewall, ...) should be applied to the same packet. We 
> should obviously 
> strive to classify the packet once in implementations.
> 
> 	Now, I said  ' very close to requiring' . I guess that even if
> different 
> groups do invent different models of how to do 
> classification, that does 
> not necessarily mean that implementations must actually do 
> classifications 
> differently. But it certainly would be a confusion situation.
> 
> Ricky Charlet
> rcharlet@xxxxxxxxxxxx
> 
>