Subject: Re: granularity property in Common Information Model

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 23 Mar 2001 13:43:30 -0700

It sounds to me as though the ID's are indeed mismatched.

I don't know if anyone is using the larger set of ID types in
Phase II, but the original idea had been that some ID's would
be trusted to assert other ID's in phase 2.

Hilarie

>>> Ricky Charlet <[email-masked]> 03/20/01 09:37AM >>>
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?

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

Eric Vyncke wrote:
> 
> 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
> 
> At 10:05 19/03/2001 -0700, Ricky Charlet wrote:
> >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
> 
> 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