Subject: model, granularity and ranges

From: Wes Hardaker <[email-masked]>
Date: Thu, 09 May 2002 15:05:38 -0700

Currently, the model has decided to use the IPHeadersFilter from PCIMe
(which is a good thing I think), but the IPHeadersFilter object allows
for filtering one:

1) an adddress
2) a subnet
3) a range of address (eg: 10.0.0.5 - 11.1.2.3)

#3 supports the ability to filter on a range of addresses that does
not necessarily lie directly across a normal subnet definition.

The question is what to do when the filter is a range of addresses but
the Granularity property of the IPsecAction object is set to
"subnet".  What is the selector supposed to look like for an SA in
this case?  I'd suggest that it should be a singe address.  I think
the full list of choices are:

1) a single address (my recommendation).
2) a subnet that most widely selects the matched address but still
   falls entirely within the range (ick, but doable).
3) multiple #2s such that multiple SAs are developed to completely
   cover the range in question (even more ick, but still doable).

Thoughts?

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Eric Vyncke <[email-masked]>
Date: Tue, 14 May 2002 15:38:22 +0200

Wes

This is a good point and I would follow your recommendation but rephrased 
it like 'when the IPHeadersFilter specifies an IP address range then the 
Granularity property cannot be set to 1 (= subnet).

What do you think ?

I would amend the -06 with this

-eric

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 May 2002 07:42:36 -0700

>>>>> On Tue, 14 May 2002 15:38:22 +0200, Eric Vyncke <[email-masked]> said:

Eric> This is a good point and I would follow your recommendation but
Eric> rephrased it like 'when the IPHeadersFilter specifies an IP
Eric> address range then the Granularity property cannot be set to 1
Eric> (= subnet).

That's fine too.  It moves the error checking to configuration time,
rather than run time so that makes perfect sense.

The problem is that dynamic changes to policy will cause a problem.
Consider the case when rules are being modified dynamically and a
filter is changed from a singe address to a range.  The actions then
need to be consulted for all rules which contain the particular filter
to ensure they're still appropriate.  IE, is the reverse case also
true?  Can you change a filter to a range if it is currently
associated with an action which has a granularity of subnet?

(While writing this, I'm realizing there are other problems with
granularity being tied to the actions...  What happens when multiple
IPHeaderFilters are evaluated under a rule and have different narrower
and wider filtering properties?  Like two filters with different
subnet checks that both match the address.  What does a "subnet"
granularity mean then?  Take the wider of the 2?)

-- 
Wes Hardaker
NAI Labs
Network Associates