Subject: Re: granularity property in Common Information Model

From: Ghislaine Labouret <[email-masked]>
Date: Tue, 03 Apr 2001 19:04:17 +0200

On Tue, 27 Mar 2001 16:31:27 +0100, Eric Vyncke wrote:

> 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;

What about an example situation where the SACondition filter still has
source = 192.168.1.*, but destination = 10.*.*.* / TCP / 80: which of
the following proxy IDs would be used for a subnet granularity?

1/ <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=6,port=80>
                                                        ^      ^^
Approach in which the IPsec device negotiates a SA bundle per
protocol/port (approach used by Cisco routers for example)

2/ <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0>
                                                        ^      ^
Approach in which the IPsec device negotiates only one "large tunnel"
for all protocols (and subsequently uses filtering to limit traffic
allowed to use this tunnel) (approach used by Check Point VPN-1 for
example)

I personally believe that it would be nice to have a model that can
accommodate both approaches, as it would enable wider devices support.

Sincerely,

--
Ghislaine Labouret, Network security consultant
Hervé Schauer Consultants (HSC) - http://www.hsc.fr/
Phone (+33)-141-409-700 - Fax (+33)-141-409-709

---

From: Ricky Charlet <[email-masked]>
Date: Thu, 05 Apr 2001 09:42:42 -0600

Howdy,

	OK, I appologize for the delay in my reply.

	Thanks Eric for your expanded explimation of specifying Phase II client
IDs and offer to include Linear Ranges in the granularity property of
the model.  

	I have also had a read through the newer
draft-ietf-ipsp-config-policy-model-02.txt as it relates to filtering. I
see that in the new draft, port and protocol filtering capabilities are
now present. This satisfies my original concern (about the absence of
port and protocol filtering and the reliance on only the granularity
property).

	So, about where to derive the phase II IDs... I find your explimation
to be sound and supportable. However, I think we can also (and I would
rather) pick up the Phase II IDs from the traffic filters. Or to put it
another way, As an implementor, I hope that I have the option of not
supporting the granularity property and having the peopel who configure
our implementation know that they will be specifiying the phaseII client
IDs with the filters they set up.

	Now about those linear address ranges... I guess these are not a
priority for me although I would like them. It seems to me that we
should support them just for the principle of conforming to the standard
architecture. I do believe that someday, I'll have a customer that just
demands them. However, If we are to support linier address ranges, I
would like to see us develop filters for them. I will not oppose the the
filtering oriented granularity poperty in the action branch of the
model, I just need to advocate for the presence of rich filtering
capabilites to be supported in the actual filtering branch of the model.

Eric Vyncke wrote:
> 
> 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.
> 
> 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
> 
> At 09:37 20/03/2001 -0700, Ricky Charlet wrote:
> >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?
> 
> 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

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

---

From: "Lee Rafalow" <[email-masked]>
Date: Fri, 6 Apr 2001 15:28:18 -0400

> IDs with the filters they set up.

Ricky, From a system-wide configuration perspective, I'd rather we keep the
functions of filtering and granularity separate.  Filters are intended to be
used to identify the rule that applies to a given packet and situation. If
we add an optional semantic that granularity is specified by the filter as
well, we fracture the standard so that we lose both device-independent
policy specification and interoperability.

As for granularity being optional, I believe it should be.  But I don't
think there should be another way of configuring it if you choose to support
it.

My 2 cents.

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Home email: [email-masked]

---

From: Ricky Charlet <[email-masked]>
Date: Fri, 06 Apr 2001 13:26:28 -0600

> think there should be another way of configuring it if you choose to support

Howdy,
	How is granularity different than filtering? What functions are you
trying to keep seperate. The best that I have been able to comprehend so
far, ganularity is filtering, it's just hidden over in the action branch
of the model rather than the condition branch.