Subject: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 6 Feb 2001 09:18:12 -0500

Mahadevan, There has been some discussion on this list and, of course, on
the IPSP list but there's no conclusive answer as yet.  Jamie and I have
discussed this and we'll leave the IPsec Config Policy Model (ICPM, aka
ICIM) as it is for now.  The reason is primarily one of timing: the PCIMe
draft is being written right now and ICPM needs to be updated in time for
the March meeting.  We need stability in the technical content and these
kind of representation details are really secondary right now.

That said, in the long run whether we use FilterEntry or
PolicyVariable/PolicyValue pairs is tbd, but the answer will lie in how the
IPSP WG sees the trade-offs between common policy representation vs. a model
that's close to its device-level implementation.

Lee

----- Original Message -----
From: "Mahadevan Iyer" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 06, 2001 4:09 AM
Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 -
1/26/01

> --- John Strassner <[email-masked]> wrote:
> > This last sentence is misleading. One can easily
> > define
> > equivalences between the
> > FilterEntry.MatchConditionType and
> > the PolicyVariable classes and also between the
> > FilterEntry.MatchConditionValue and the PolicyValue
> > classes.
> > The perception that PolicyVariables and PolicyValues
> > somehow
> > break FilterEntries is just plain wrong.
>
> Can someone summarize the reasons why we will continue
> to have the notion of FilterEntry in IPSP drafts. If
> the reasons have been summarized in a thread, a
> pointer to the thread would be sufficient.
>
> Thanks
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>

---

From: Mahadevan Iyer <[email-masked]>
Date: Tue, 6 Feb 2001 21:37:22 -0800 (PST)

> that's close to its device-level implementation.

What is the device-level implementation aspect that
points to FilterEntries. As far as I know IKE itself
has a notion of proxy id's(not filterentries) which at
this point are specified as IP subnets. 

Thanks

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 7 Feb 2001 09:32:34 -0500

Mahadevan,

First, let's make sure everyone understands that the IPSP model is for a PEP
not for a PDP.  It's a device-level configuration model of an IKE service
and related stack components in a security client or security gateway; it's
not a domain policy.

Implementations vary, of course, but the notion that filter entries are
closer to a device-level policy implementation has to do with the fact that
parsing a general grammar (Variable, Operator, Value) is not the most
efficient implementation of a filter.  One of our implementations, for
example, uses the stack's 5-tuple filters to not only find the outbound SAs
but to also test the address-based conditions for the rules...it's pretty
efficient.  A parser for the VOV syntax wouldn't be implemented in that
product.

But that doesn't mean we shouldn't express the conditions in a VOV syntax in
the information model just that there are trade-offs.  It's very tempting to
try to find an algorithmic mapping from an information model to an
implementable data model.  Such a mapping for VOV won't even be close for
some implementations whereas it'll be close for Filters.  But as long as the
PIB, MIB, LDAP, et al mapping activities aren't tempted to do that, then
this concern is diminished.

Another thing to consider here is that a general grammar can specify
conditions that a PEP might not be able to parse into its limited set of
filter options.  A PDP can take a general specification of a domain-level
policy and map it to a set of device-level policies that match the
capabilities of a given PEP.  A PEP cannot be expected to handle any policy,
just the ones appropriate for it.  This concern doesn't disappear if we use
filters, but it's easier to spot the conditions that can be specified that
may not be supported.

Just a few things to consider.  Cheers, Lee

----- Original Message -----
From: "Mahadevan Iyer" <[email-masked]>
To: "Lee Rafalow" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 07, 2001 12:37 AM
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe
technical meeting, 1/24/01 - 1/26/01)