Subject: granularity property in Common Information Model

From: Ricky Charlet <[email-masked]>
Date: Mon, 19 Mar 2001 10:05:51 -0700

Howdy,

	I can't be at the IETF this week. But I would like to bring up an old
argument about the granularity property in
draft-ietf-ipsp-config-policy-model-02.txt. I hope that someone will
persue this topic in the meeting today.

	The granluarity property is associated with an IPsecAction. It defines
whether or not the SA will use port/protocol filtering. If granularity
is "ON". then the ports/protocols are sucked out of the passing packet
(which has already matched an ipaddress subnet filter) and the SA is
built to filter on those ports/protocols. (WARNING: this has been a
simplification of how granularity is really defined for the sake of
clarity... granularity is reall just a bit more flexible than this.)

	I want to see port and protocol filtering moved away from the 'action'
branch of the model and into the 'condition' branch. I strongly believe
that Administrators should have control over the construction of
port/protocol filters in just the same was as address filters. My
reading of the architecture documets would require this admistrative
control capability. My sence of the customer problem I am trying to
solve requires this adminstrative control capability. And generalized
view of modeling would suggest that granularity is a 'filtering' related
property belonging with the other filtering properties in a model.

-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903

---

From: Eric Vyncke <[email-masked]>
Date: Mon, 19 Mar 2001 21:13:01 +0100

Ricky,

I do believe that granularity belongs to the action, when a packet
matches your filter, you start a negotiation using some phase 2 ID
based on the original packet and the granularity property. So, it really
belongs to the action side.

But, you raise a good point for the DMTF information model which
also models the state of the SA. When a fine granularity is applied and
an SA is eventually created, a filter object will need to be created
and associated through FilterOfSecurityAssociation with SecurityAssociation.

Hope this helps,

Regards

-eric

>property belonging with the other filtering properties in a model.

Eric Vyncke
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: [email-masked]          Mobile: +32-475-312.458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Mon, 19 Mar 2001 22:30:54 -0600

Eric,

The granularity you described seems associated with actions but are based on
parameters  used for creating/evaluate conditions. RFC2401 says "The following
selector parameters MUST be supported for SA management to facilitate control of SA
granularity." THe model supports this already from a condition point of view. Can
you further explain this?

---

From: Ricky Charlet <[email-masked]>
Date: Tue, 20 Mar 2001 09:37:39 -0700

Thanks Eric,

	I see your point that the phase 2 ID needs to be specified as to type.
I had not thought of that before. 

	But, the granularity property in the IPsecAction (what do we call it,
object, group, table, thingie?) seems to me to be mismatched with the
set of possible 2 ID types. Specifically, we do not need ports and
protocols in phase 2 IDs but on the other hand, we do need specific
addresses, subnets, and ranges of addresses in IPv4 and IPv6. (I don't
know if FQDN, user@FQDN, DN, GN, and keyID are supportable as phase 2
IDs, could someone else inform our disussion here. I don't see any thing
saying they can not be used at phase 2, but I also don't see how data,
not verifiable in a packet, could be used as a phase 2 ID.) In the case
of subnets and ranges of addresses, these cannot be inferred from a
packet-on-hand and a granularity property. 

	So now I am left with my original request and a new question. Can we
please provide filtering control for ports and protocols? And now, how
should we know what client ID to use in (and the type of) the phase 2
Identification payload?

---

From: Eric Vyncke <[email-masked]>
Date: Tue, 27 Mar 2001 16:31:27 +0100

Rick,

Obviously both the I-D and my previous email messages are not crystal clear :-(

(I share your comment between parenthesis about the applicable phase 2 ID, 
for me this could possibly be IPV[46] address, subnet or range of addresses).

Section 4.6.2 of RFC 2407 specifies the possible formats for an ID payload. 
While it clearly says that IP protocol type and port is to be set to 0 or 
to UDP port 500 for phase 1 ID, it also says that protocol type and port 
can be set to 0 (with 0 meaning wild card) or to a specific value for phase 
2 ID.

Let's do it with an example, the 'triggering' packet is from 192.168.1.1 
TCP/1024 to 10.1.1.1 TCP/80, the SACondition filter is any source IP from 
192.168.1.* to 10.*.*.*, then depending on the granularity, IKE should 
negotiate phase 2 SA for the following phase 2 ID:
- subnet -> <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0> 
for all protocols using ID_IPV4_ADDR_SUBNET format;
- host -> <192.168.1.1,protocol=0,port=0> & <10.1.1.1,,protocol=0,port=0> 
for all protocols using ID_IPV4_ADDR format;
- protocol -> <192.168.1.1,protocol=6,port=0> & 
<10.1.1.1,protocol=6,port=0> for all TCP ports using ID_IPV4_ADDR format;
- port -> <192.168.1.1,protocol=6,port=1024> & 
<10.1.1.1,protocol=6,port=80) only for the triggering TCP flow using 
ID_IPV4_ADDR format;

On purpose, we simplified the information model by removing some possible 
variations (like subnet on one side and address on the other side) because 
we feel that no implementation are using those variations. Of course, we 
can be wrong and the model could always be improved.

NB: there is currently no provision in the IM to model a phase 2 of 
ID_IPV4_ADDR_RANGE which may be a concern if some implementations are using 
this kind of ID (and some recent troubleshooting between Cisco and Redcreek 
concentrators make believe that you are using address ranges ;-) ). If 
needed, we could also extend the IM to represent an address range as a 
phase 2 ID.

Anyway, if you believe that the above explanation is clearer, I would be 
glad to augment the I-D with it.

Hope this helps

-eric

Eric Vyncke
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778-4677             Fax:    +32-2-778-4300
E-mail: [email-masked]          Mobile: +32-475-312-458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141