From owner-ipsec-policy@mail.vpnc.org Wed Dec 6 13:04:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02905 for ; Wed, 6 Dec 2000 13:04:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16886 for ipsec-policy-bks; Wed, 6 Dec 2000 08:21:02 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16879 for ; Wed, 6 Dec 2000 08:21:01 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA22462 for ; Wed, 6 Dec 2000 11:22:02 -0500 Received: from lmr (dyn9-37-48-47.raleigh.ibm.com [9.37.48.47]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA26332 for ; Wed, 6 Dec 2000 11:22:03 -0500 Message-ID: <007501c05fa0$5bfd31e0$2f302509@raleigh.ibm.com> From: "Lee Rafalow" To: References: Subject: Re: Slightly higher level policy Date: Wed, 6 Dec 2000 11:19:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The method used in the policy framework working group is to create an information model (using UML) to describe the semantics and then derive implementation from that as needed. This is what we're doing with the device-level model and I'd encourage the WG to do the same for any higher-level models. The Policy Core Information Model has the capability to have a policy rule that's not enabled (perhaps named but not yet defined). The same (or very similar) action, proposal and transform subclasses can be used to define the types of service and we can use higher-level conditions and policy roles to define applicability of the types of service to traffic and endpoints. Lee ----- Original Message ----- From: "Hilarie Orman" To: Sent: Wednesday, November 29, 2000 1:32 PM Subject: Slightly higher level policy > I would like to suggest a language-based approach to the problem > of specifying policy for collections of elements. This is fairly generic, > and I'm curious to know if it duplicates other proposed methods. > > The idea is that when filling in the attributes of a structure, you > can specify that some items are named but not yet bound. > For example, a collection of elements defined with identical > attributes but differing in their specific IP address would > use one data structure, but fill in the address as > "$this_ip_address", which would make it a free variable > of the element definition. > > Each specific element would be defined with a reference > to the data structure and a specific IP address: > > security_gateway(this_ip_address = 192.60.51.3) > > There are well-known formal constructs for the binding rules > and evaluation of such languages. They seem like a simple > extension of policy definitions. Could they be applied usefully > to the IPSec Policy arena? > > Hilarie > > From owner-ipsec-policy@mail.vpnc.org Wed Dec 6 14:19:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22356 for ; Wed, 6 Dec 2000 14:19:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA23891 for ipsec-policy-bks; Wed, 6 Dec 2000 10:03:05 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23882 for ; Wed, 6 Dec 2000 10:03:03 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA29574; Wed, 6 Dec 2000 13:04:10 -0500 Received: from lmr (dyn9-37-48-47.raleigh.ibm.com [9.37.48.47]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA22566; Wed, 6 Dec 2000 13:04:11 -0500 Message-ID: <008301c05fae$7719c660$2f302509@raleigh.ibm.com> From: "Lee Rafalow" To: "Jean Christophe Martin" , , References: <3A1AEFAD.41055193@sun.com> Subject: QoS/IPSEC alignment questions Date: Wed, 6 Dec 2000 13:00:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jean, 1. I think the difference between the condition representations can be justified. The IETF QDDIM and IPSP models (and their corresponding DMTF QoS and IPsec models)are device-level models, i.e., in the PEP. In these device-level models, the intent is to create an object model that is reasonably close to implementation structures and yet independent of any specific implementation. Filters are commonly used to determine packet handling and, therefore, are used in these device-level models. The QPIM model, on the other hand, is a domain-level model (i.e., in the PMT, repository and/or PDP). The approach taken in the current draft is very general in its capability. Without discussing the merits of the "atoms" approach in the QPIM, for a domain-level policy specification this generality might be seen as very beneficial. But it's not likely that a Diffserv PEP or an IKE service are going to have data structures that are going to sacrifice the efficiency of filters in favor of that generality. The question, then, comes down to how closely do we want the model and the application of the model to be to one another. So, this is not to say that we shouldn't explore convergence here, it's just that we haven't to date because of the perceived affinity to implementations at the two different levels. I hope this helps. 2. There's another divergence that you didn't mention that I've noticed and that I'm less comfortable with. It's in the handling of the rule priorities as they're aggregated in policy groups. Specifically, in the soon to be released DMTF IPsec model (and presumably in Jamie's revision of the IPsec Configuration Policy Model when it's posted) the IPsecPolicyGroupInPolicyGroup aggregation of groups has a GroupPriority property that is used to assign absolute priorities to rules within groups of groups. The model uses the PolicyRule.RulePriority for the rule and, for simplicity, we limit a rule to be in a single group. But since groups can be in multiple groups, it is the relationship between the groups that assign the relative priorities of the contained rules to those contained in other groups. In QPIM, however, PolicyGroup subclasses are limited to a single parent in the aggregation hierarchy. With that limitation in mind, the gpPriority property has been placed in the gpsPolicyGroup class instead of in the aggregating relationship. I believe that we should settle on a single way of prioritizing groups within groups and that generality would lead to putting that priority into the PolicyGroupInPolicyGroup subclasses. There may be other alignment concerns but this is what I've spotted so far. Lee ----- Original Message ----- From: "Jean Christophe Martin" To: Sent: Tuesday, November 21, 2000 4:57 PM Subject: QoS/IPSEC alignement questions > > > I'm trying to understand how the QoS drafts are relating to the > IPSEC drafts , and so far, I have little succes. For example : > > > The IPSEC Policy Model is defining : > > PolicyCondition > | > SACondition <----FilterofSACondition--->FilterList > > > > That should map, for the QoS, into : > > PolicyCondition > | > QoSCondition <---FilterofQosCondition-->FilterList > > > The FilterList is a list of FilterEntryBase that can either be > QoS specific Filter Entries or plain FilterEntry as defined in > CIM network model. > > However, in draft-ietf-policy-qos-info-model-01.txt, the Condition > is using a complete different model. > > Is there any plan to update the documents : Policy Framework QoS > Information Model and QoS Policy Schema to use a model like the > IPSEC model that seems closer to the DMTF model ? > > Thanks > > JC. From owner-ipsec-policy@mail.vpnc.org Wed Dec 6 17:01:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07883 for ; Wed, 6 Dec 2000 17:01:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA05418 for ipsec-policy-bks; Wed, 6 Dec 2000 12:38:56 -0800 (PST) Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05411 for ; Wed, 6 Dec 2000 12:38:53 -0800 (PST) Received: from user-53.cisco.com ([144.254.95.35]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id WAA20748; Wed, 6 Dec 2000 22:39:44 +0200 (IST) Message-Id: <4.3.2.7.2.20001206122857.00b37100@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Dec 2000 12:39:00 -0800 To: "Lee Rafalow" , "Jean Christophe Martin" , , From: Ron Cohen Subject: Re: QoS/IPSEC alignment questions In-Reply-To: <008301c05fae$7719c660$2f302509@raleigh.ibm.com> References: <3A1AEFAD.41055193@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lee, I fully agree with point 1. For the second point, in the QPIM 02 draft we explain the reuse of policy groups, i.e. we allow having more than one parent for each policy group. We have a section that discuss how to use priority in this case. The PolicyGroupInPolicyGroup aggregation is defined in PCIM, not in QPIM, without the additional priority property. I think that your proposal to include the priority in the aggregation is much more elegant. We might still do it by defining a new aggregation, or a derived one. Lets talk about this in the IETF and find the right solution. Thanks Ron >Jean, > >1. I think the difference between the condition representations can be >justified. > >The IETF QDDIM and IPSP models (and their corresponding DMTF QoS and IPsec >models)are device-level models, i.e., in the PEP. In these device-level >models, the intent is to create an object model that is reasonably close to >implementation structures and yet independent of any specific >implementation. Filters are commonly used to determine packet handling and, >therefore, are used in these device-level models. > >The QPIM model, on the other hand, is a domain-level model (i.e., in the >PMT, repository and/or PDP). The approach taken in the current draft is >very general in its capability. Without discussing the merits of the >"atoms" approach in the QPIM, for a domain-level policy specification this >generality might be seen as very beneficial. But it's not likely that a >Diffserv PEP or an IKE service are going to have data structures that are >going to sacrifice the efficiency of filters in favor of that generality. > >The question, then, comes down to how closely do we want the model and the >application of the model to be to one another. So, this is not to say that >we shouldn't explore convergence here, it's just that we haven't to date >because of the perceived affinity to implementations at the two different >levels. > >I hope this helps. > >2. There's another divergence that you didn't mention that I've noticed and >that I'm less comfortable with. It's in the handling of the rule priorities >as they're aggregated in policy groups. > >Specifically, in the soon to be released DMTF IPsec model (and presumably in >Jamie's revision of the IPsec Configuration Policy Model when it's posted) >the IPsecPolicyGroupInPolicyGroup aggregation of groups has a GroupPriority >property that is used to assign absolute priorities to rules within groups >of groups. The model uses the PolicyRule.RulePriority for the rule and, for >simplicity, we limit a rule to be in a single group. But since groups can >be in multiple groups, it is the relationship between the groups that assign >the relative priorities of the contained rules to those contained in other >groups. > >In QPIM, however, PolicyGroup subclasses are limited to a single parent in >the aggregation hierarchy. With that limitation in mind, the gpPriority >property has been placed in the gpsPolicyGroup class instead of in the >aggregating relationship. > >I believe that we should settle on a single way of prioritizing groups >within groups and that generality would lead to putting that priority into >the PolicyGroupInPolicyGroup subclasses. > >There may be other alignment concerns but this is what I've spotted so far. > >Lee > >----- Original Message ----- >From: "Jean Christophe Martin" >To: >Sent: Tuesday, November 21, 2000 4:57 PM >Subject: QoS/IPSEC alignement questions > > > > > > > > I'm trying to understand how the QoS drafts are relating to the > > IPSEC drafts , and so far, I have little succes. For example : > > > > > > The IPSEC Policy Model is defining : > > > > PolicyCondition > > | > > SACondition <----FilterofSACondition--->FilterList > > > > > > > > That should map, for the QoS, into : > > > > PolicyCondition > > | > > QoSCondition <---FilterofQosCondition-->FilterList > > > > > > The FilterList is a list of FilterEntryBase that can either be > > QoS specific Filter Entries or plain FilterEntry as defined in > > CIM network model. > > > > However, in draft-ietf-policy-qos-info-model-01.txt, the Condition > > is using a complete different model. > > > > Is there any plan to update the documents : Policy Framework QoS > > Information Model and QoS Policy Schema to use a model like the > > IPSEC model that seems closer to the DMTF model ? > > > > Thanks > > > > JC. From owner-ipsec-policy@mail.vpnc.org Thu Dec 7 02:39:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15324 for ; Thu, 7 Dec 2000 02:39:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA27594 for ipsec-policy-bks; Wed, 6 Dec 2000 22:34:58 -0800 (PST) Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA27590 for ; Wed, 6 Dec 2000 22:34:56 -0800 (PST) Message-ID: <20001207063636.22236.qmail@web10501.mail.yahoo.com> Received: from [198.206.187.100] by web10501.mail.yahoo.com; Wed, 06 Dec 2000 22:36:36 PST Date: Wed, 6 Dec 2000 22:36:36 -0800 (PST) From: Mahadevan Iyer Subject: gpsPolicyGroup class in qos info model To: policy@raleigh.ibm.com, ipsec-policy@vpnc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would like to suggest an update to the gpsPolicyGroup class. This also relates to the PolicyRuleInPolicyRule usage. I need to indicate that a group of policy rules should be checked only if the traffic matches some aggregate conditions. These aggregate conditions summarize the conditions within the policy rules. I would like to specify the aggregate conditions at the level of the gpsPolicyGroup. An alternative is to use the PolicyRule + PolicyRuleInPolicyRule instead of the gpsPolicyGroup. However I prefer to use the gpsPolicyGroup. I would suggest adding an aggregate policy condition to the gpsPolicyGroup. This condition would typically be a gpsPolicyCompoundCondition. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Thu Dec 7 04:45:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16148 for ; Thu, 7 Dec 2000 04:45:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA18522 for ipsec-policy-bks; Thu, 7 Dec 2000 00:33:01 -0800 (PST) Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18502 for ; Thu, 7 Dec 2000 00:32:56 -0800 (PST) Received: from user-53.cisco.com (telaviv3-dhcp153.cisco.com [144.254.93.91]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA05329; Thu, 7 Dec 2000 10:34:00 +0200 (IST) Message-Id: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Dec 2000 00:33:15 -0800 To: Mahadevan Iyer , policy@raleigh.ibm.com, ipsec-policy@vpnc.org From: Ron Cohen Subject: Re: gpsPolicyGroup class in qos info model In-Reply-To: <20001207063636.22236.qmail@web10501.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mahadevan, Can you provide more details why you prefer to change the gpsPolicyGroup than using the current policyRuleInPolicyRule method? Thanks Ron >I would like to suggest an update to the >gpsPolicyGroup class. >This also relates to the PolicyRuleInPolicyRule usage. > >I need to indicate that a group of policy rules should >be checked only if the traffic matches some aggregate >conditions. These aggregate conditions summarize the >conditions within the policy rules. > >I would like to specify the aggregate conditions at >the level of the gpsPolicyGroup. An alternative is to >use the PolicyRule + PolicyRuleInPolicyRule instead of >the gpsPolicyGroup. However I prefer to use the >gpsPolicyGroup. > >I would suggest adding an aggregate policy condition >to the gpsPolicyGroup. This condition would typically >be a gpsPolicyCompoundCondition. > > >Thanks > >__________________________________________________ >Do You Yahoo!? >Yahoo! Shopping - Thousands of Stores. Millions of Products. >http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Fri Dec 8 00:16:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22604 for ; Fri, 8 Dec 2000 00:16:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10689 for ipsec-policy-bks; Thu, 7 Dec 2000 19:28:10 -0800 (PST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10684 for ; Thu, 7 Dec 2000 19:28:06 -0800 (PST) Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eB83V9E73325; Fri, 8 Dec 2000 04:31:09 +0100 (CET) Received: from imap.heidelberg.ccrle.nec.de (postfix@imap.heidelberg.ccrle.nec.de [192.168.102.7]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA22649; Fri, 8 Dec 2000 04:30:12 +0100 Received: by imap.heidelberg.ccrle.nec.de (Postfix, from userid 30) id 6CB587DCF; Fri, 8 Dec 2000 06:29:55 +0100 (CET) From: Marcus Brunner To: Ron Cohen Reply-To: Marcus Brunner Cc: Mahadevan Iyer , policy@raleigh.ibm.com, ipsec-policy@vpnc.org References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> In-Reply-To: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9 Subject: Re: gpsPolicyGroup class in qos info model Message-Id: <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de> Date: Fri, 8 Dec 2000 06:29:55 +0100 (CET) Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ron, I agree with Mahadevan, that I do not like the policyRuleInPolicyRule method, because a) there are now two different grouping models, b) it is unclear what happens to the context when the ruleInrule is executed (full new start of execution engine or reuse the context) c) I do not see the need for rulesInrules, what makes them different compared to the grouping already available However, I do not agree to add a condition to the group. I think what is available is enough. Marcus Quoting Ron Cohen : > Mahadevan, > > Can you provide more details why you prefer to change the gpsPolicyGroup > than using the current policyRuleInPolicyRule method? > > Thanks > Ron > > > >I would like to suggest an update to the > >gpsPolicyGroup class. > >This also relates to the PolicyRuleInPolicyRule usage. > > > >I need to indicate that a group of policy rules should > >be checked only if the traffic matches some aggregate > >conditions. These aggregate conditions summarize the > >conditions within the policy rules. > > > >I would like to specify the aggregate conditions at > >the level of the gpsPolicyGroup. An alternative is to > >use the PolicyRule + PolicyRuleInPolicyRule instead of > >the gpsPolicyGroup. However I prefer to use the > >gpsPolicyGroup. > > > >I would suggest adding an aggregate policy condition > >to the gpsPolicyGroup. This condition would typically > >be a gpsPolicyCompoundCondition. > > > > > >Thanks > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Shopping - Thousands of Stores. Millions of Products. > >http://shopping.yahoo.com/ > > Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From owner-ipsec-policy@mail.vpnc.org Fri Dec 8 00:47:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04969 for ; Fri, 8 Dec 2000 00:47:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11774 for ipsec-policy-bks; Thu, 7 Dec 2000 20:28:25 -0800 (PST) Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11770 for ; Thu, 7 Dec 2000 20:28:24 -0800 (PST) Message-ID: <20001208043008.17348.qmail@web10501.mail.yahoo.com> Received: from [198.206.187.100] by web10501.mail.yahoo.com; Thu, 07 Dec 2000 20:30:08 PST Date: Thu, 7 Dec 2000 20:30:08 -0800 (PST) From: Mahadevan Iyer Subject: Re: gpsPolicyGroup class in qos info model To: Marcus Brunner , Ron Cohen Cc: Mahadevan Iyer , policy@raleigh.ibm.com, ipsec-policy@vpnc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello Marcus, Ron, there are 2 issues mentioned in you responses. 1. Why not use the PolicyRuleInPolicyRule instead of .. I must say that if we had started out saying that any collection of policies can be logically thought of as "a policy"(which I find attractive) I wouldn't have minded using this class. However we seemed to have clearly called out the notion of a "collection of policies" to be a policyGroup. This too has its benefits. This has led me to think of the of the PolicyRule as an "atomic" class to be aggregated using PolicyGroups. 2. Why do we need a condition at the level of a "collection of policies" ... This is an optimization which could be leveraged in almost all applications. A PDP can do this on its own by analysing the conditions in the contained rules. However the administrator can configure far more optimal and powerful aggregation of conditions. It is possible that these aggregations might be a subset or a superset of the aggregation derived by analysing the conditions. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Sat Dec 9 13:27:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04030 for ; Sat, 9 Dec 2000 13:27:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17935 for ipsec-policy-bks; Sat, 9 Dec 2000 09:15:06 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17930; Sat, 9 Dec 2000 09:15:05 -0800 (PST) Message-Id: <200012091715.JAA17930@ns.secondary.com> From: Mail Sender To: ipsec@lists.tislabs.com CC: ipsec-policy@vpnc.org, ipsec-policy-request@vpnc.org, ipsec-request@lists.tislabs.com, ips-request@ece.cmu.edu, iptel@lists.bell-labs.com Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ipsec-policy@mail.vpnc.org Sat Dec 9 22:32:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26710 for ; Sat, 9 Dec 2000 22:32:54 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA28559 for ipsec-policy-bks; Sat, 9 Dec 2000 18:22:21 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28555 for ; Sat, 9 Dec 2000 18:22:20 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15516; Sat, 9 Dec 2000 18:24:14 -0800 (PST) Received: from jstrassnlap (sjck-dial-gw5-24.cisco.com [10.19.238.25]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AEE00875; Sat, 9 Dec 2000 18:23:57 -0800 (PST) Message-ID: <001301c06250$bdf1cca0$19ee130a@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Mahadevan Iyer" , "Marcus Brunner" , "Ron Cohen" Cc: "Mahadevan Iyer" , , References: <20001208043008.17348.qmail@web10501.mail.yahoo.com> Subject: Re: gpsPolicyGroup class in qos info model Date: Sat, 9 Dec 2000 18:03:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Mahadevan, I'm still not quite sure I understand your reasoning for the putting an aggregate condition in the gpsPolicyRule class. I also don't think that this works. Let me explain. As you say, a policyRule is an atomic object. You're asking to "peek inside" a group of policyRules in a policyGroup and copy their aggregate conditions out into a higher-level condition that you can then trap on. At the very minimum, this means that you also have to copy the decision strategies that are applied to each group of conditions. Remember that QPIM defines multiple decision strategies, so you now have to re-create the decision strategies defined at each container and apply them to the conditions at each level of containment. Yuck. In addition, in QPIM, we have nested rules as well as sub-rules. You can't flatten out the condition in these cases, or you lose the hierarchy of the structure of the rules. Finally, putting in such optimizations sets a dangerous standard - where do we stop? Does every relationship and every different case get standardized, or is this better handled in an application-specific way? So in summary, I don't think this can work for QPIM, and doubt that it can work for PCIM in general. Please explain how you solve the above problems. regards, John ----- Original Message ----- From: "Mahadevan Iyer" To: "Marcus Brunner" ; "Ron Cohen" Cc: "Mahadevan Iyer" ; ; Sent: Thursday, December 07, 2000 8:30 PM Subject: Re: gpsPolicyGroup class in qos info model > Hello Marcus, Ron, > > there are 2 issues mentioned in you responses. > > 1. Why not use the PolicyRuleInPolicyRule instead of > .. > > I must say that if we had started out saying that > any collection of policies can be logically thought of > as "a policy"(which I find attractive) I wouldn't have > minded using this class. > However we seemed to have clearly called out the > notion of a "collection of policies" to be a > policyGroup. This too has its benefits. This has led > me to think of the of the PolicyRule as an "atomic" > class to be aggregated using PolicyGroups. > > 2. Why do we need a condition at the level of a > "collection of policies" ... > > This is an optimization which could be leveraged in > almost all applications. A PDP can do this on its own > by analysing the conditions in the contained rules. > However the administrator can configure far more > optimal and powerful aggregation of conditions. It is > possible that these aggregations might be a subset or > a superset of the aggregation derived by analysing the > conditions. > > Thanks > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Sat Dec 9 22:36:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27485 for ; Sat, 9 Dec 2000 22:36:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA28549 for ipsec-policy-bks; Sat, 9 Dec 2000 18:22:04 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28545 for ; Sat, 9 Dec 2000 18:22:02 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15460; Sat, 9 Dec 2000 18:23:56 -0800 (PST) Received: from jstrassnlap (sjck-dial-gw5-24.cisco.com [10.19.238.25]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AEE00871; Sat, 9 Dec 2000 18:23:23 -0800 (PST) Message-ID: <001201c06250$b7a73bf0$19ee130a@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Marcus Brunner" , "Ron Cohen" Cc: "Mahadevan Iyer" , , References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de> Subject: Re: gpsPolicyGroup class in qos info model Date: Sat, 9 Dec 2000 17:56:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit PolicyRuleInPolicyRule is used to build sub-rules. We also allow for PolicyGroupInPolicyRule to build a sub-rule, with a policyGroup as a nested container. This capability is not in PCIM. As far as the context, sub-rules execute before their containing rules, as explained in the draft. I not only don't like conditions in gpsPolicyGroup, I don't think they work. regards, John ----- Original Message ----- From: "Marcus Brunner" To: "Ron Cohen" Cc: "Mahadevan Iyer" ; ; Sent: Thursday, December 07, 2000 9:29 PM Subject: Re: gpsPolicyGroup class in qos info model > Ron, > > I agree with Mahadevan, that I do not like the policyRuleInPolicyRule method, > because > a) there are now two different grouping models, > b) it is unclear what happens to the context when the ruleInrule is executed > (full new start of execution engine or reuse the context) > c) I do not see the need for rulesInrules, what makes them different compared to > the grouping already available > > However, I do not agree to add a condition to the group. I think what is > available is enough. > > Marcus > > Quoting Ron Cohen : > > > Mahadevan, > > > > Can you provide more details why you prefer to change the gpsPolicyGroup > > than using the current policyRuleInPolicyRule method? > > > > Thanks > > Ron > > > > > > >I would like to suggest an update to the > > >gpsPolicyGroup class. > > >This also relates to the PolicyRuleInPolicyRule usage. > > > > > >I need to indicate that a group of policy rules should > > >be checked only if the traffic matches some aggregate > > >conditions. These aggregate conditions summarize the > > >conditions within the policy rules. > > > > > >I would like to specify the aggregate conditions at > > >the level of the gpsPolicyGroup. An alternative is to > > >use the PolicyRule + PolicyRuleInPolicyRule instead of > > >the gpsPolicyGroup. However I prefer to use the > > >gpsPolicyGroup. > > > > > >I would suggest adding an aggregate policy condition > > >to the gpsPolicyGroup. This condition would typically > > >be a gpsPolicyCompoundCondition. > > > > > > > > >Thanks > > > > > >__________________________________________________ > > >Do You Yahoo!? > > >Yahoo! Shopping - Thousands of Stores. Millions of Products. > > >http://shopping.yahoo.com/ > > > > > > > > Dr. Marcus Brunner > C&C Research Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.tik.ee.ethz.ch/~brunner > > Adenauerplatz 6 > D-69115 Heidelberg > Germany > > Phone: +49 (0)6221/ 9051129 > Fax: +49 (0)6221/ 9051155 From owner-ipsec-policy@mail.vpnc.org Mon Dec 11 00:54:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09042 for ; Mon, 11 Dec 2000 00:54:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA07501 for ipsec-policy-bks; Sun, 10 Dec 2000 20:24:54 -0800 (PST) Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA07497 for ; Sun, 10 Dec 2000 20:24:52 -0800 (PST) Message-ID: <20001211042641.30000.qmail@web10501.mail.yahoo.com> Received: from [198.206.187.100] by web10501.mail.yahoo.com; Sun, 10 Dec 2000 20:26:41 PST Date: Sun, 10 Dec 2000 20:26:41 -0800 (PST) From: Mahadevan Iyer Subject: Re: gpsPolicyGroup class in qos info model To: John Strassner , Marcus Brunner , Ron Cohen Cc: policy@raleigh.ibm.com, ipsec-policy@vpnc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --- John Strassner wrote: > Hi Mahadevan, > > I'm still not quite sure I understand your reasoning > for the > putting an aggregate condition in the gpsPolicyRule > class. Hello John, there are 2 parts to this reply : 1. Issues raised in your response, 2. Explanation of the requirement. Issues raised in your response ... 1. There is no "peeking" inside the rules, it is an administrator generated condition. This should answer most of your issues related to aggregating conditions and decisions. 2. The PolicyRuleInPolicyRule can satisfy the requirement. I have explained my reservations regarding using this class in my earlier email. Explanation of the requirement ... 1. The requirements is driven from the practical issues at the PDP. I have a whole tree of policies and nothing but the priority to decide how I traverse the tree(at the group level). This could be a very expensive. I need to have a quick way of narrowing down the possibilities at the top of the tree(where the policyGroups are defined). It is a lot more than an optimization, it would be a requirement when defining policy trees for a carrier network. Do you see this as a problem that needs to be addressed at this level ? Thanks __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Mon Dec 11 12:38:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07024 for ; Mon, 11 Dec 2000 12:38:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27564 for ipsec-policy-bks; Mon, 11 Dec 2000 08:13:43 -0800 (PST) Received: from srv.otkz.pol.pl (srv.otkz.pol.pl [212.106.5.42]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27487 for ; Mon, 11 Dec 2000 08:12:51 -0800 (PST) From: jigga@china-email.com Received: (qmail 6043 invoked from network); 11 Dec 2000 14:48:06 -0000 Received: from 1cust189.tnt4.tampa2.fl.da.uu.net (HELO 212.109.53.147) (63.31.25.189) by srv.otkz.pol.pl with SMTP; 11 Dec 2000 14:48:06 -0000 Message-ID: <0000508b5e05$00004905$00007c00@212.109.53.147> To: Subject: Beautiful golf courses Date: Fri, 08 Dec 2000 00:17:47 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable

#1Christmas Gift for t= he Knowledgeable Golfer

"..I honestly believe it's the most beautiful gol= f book I have seen".
Ian Wooldridge, Golf Editor Daily Mail (London)

3D""border=3D0

"..a stunning collection of photographs that capt= ures the spirit of "gentlemen's golf" in golf's birthland..."Golf Digest
This handsome book= celebrates an extraordinary legacy and a living tradition. It brings the = sights and sounds of gentlemen\rquote s golf to life with some of the most= dramatic golf photos ever printed and with a lively anecdotal text.
Browsing through these pages is= almost as rewarding as a visit to the Clubs.
Legendary Golf Clubs of Scotland England Wales & Ireland
will evoke fond memories for members and a delight to
anyone fortunate enough to receive a copy as a gift.

312 pages, in a generous 9 x 12 hardbound edition with 258 spectac= ular full color illustrations
ISBN: 0-9658904-1-4

$65 (US) plus $9.95 shipping and handling and applicable state = taxes

***
To Place an order
VISA or MASTERCARD

To Place an order
CALL TOLL FREE 1-877-360-GOLF
(1-877-360-4653)

Legendary Golf Clubs o= f Scotland England Wales & Ireland
is also available at special discounts with orders of ten or copie= s,
please fax: 1-561-790-3085

Not Available in Bookstores !!



To be taken off this list please click REMOVE






 From owner-ipsec-policy@mail.vpnc.org Mon Dec 11 14:40:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27163 for ; Mon, 11 Dec 2000 14:40:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02009 for ipsec-policy-bks; Mon, 11 Dec 2000 10:16:25 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA02005 for ; Mon, 11 Dec 2000 10:16:24 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 11 Dec 2000 11:17:42 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 11 Dec 2000 11:16:54 -0700 From: "Hilarie Orman" To: , Cc: , Subject: Re: IKE should not do policy [Re: Query : PF_KEY related] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA02006 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The IPSP WG has several drafts relating to discovery and negotiation of IPSec Policy. In general, IKE cannot always make an offer that will result in establishing an SA, even when the parties involved have mutually acceptable policies. The problem is exacerbated when multiple gateways are involved. IPSP was created to solve this problem. Other IPSP drafts relate to the information model for representing configuration policy and its instantiation for specific repositories, such as COPS. Commentary on the IPSP drafts by hardcore IPSec'ers is welcome. Hilarie IPSP co-chair From owner-ipsec-policy@mail.vpnc.org Mon Dec 11 14:50:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28303 for ; Mon, 11 Dec 2000 14:50:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02615 for ipsec-policy-bks; Mon, 11 Dec 2000 10:33:07 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02610 for ; Mon, 11 Dec 2000 10:33:05 -0800 (PST) Received: by sentry.gw.tislabs.com; id NAA14732; Mon, 11 Dec 2000 13:38:39 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma014709; Mon, 11 Dec 00 13:38:10 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id NAA20217 for ipsec-policy@vpnc.org; Mon, 11 Dec 2000 13:34:27 -0500 (EST) Date: Mon, 11 Dec 2000 13:34:27 -0500 (EST) From: "David M. Balenson" Message-Id: <200012111834.NAA20217@clipper.gw.tislabs.com> To: ipsec-policy@vpnc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ipsec-policy@mail.vpnc.org Mon Dec 11 15:34:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06513 for ; Mon, 11 Dec 2000 15:34:32 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA04168 for ipsec-policy-bks; Mon, 11 Dec 2000 11:20:56 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04163 for ; Mon, 11 Dec 2000 11:20:55 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA21170; Mon, 11 Dec 2000 11:22:54 -0800 (PST) Received: from jstrassnlap (sj-dial-4-55.cisco.com [171.68.181.184]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AEG08828; Mon, 11 Dec 2000 11:22:49 -0800 (PST) Message-ID: <015401c063a8$3dfe5eb0$b8b544ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Mahadevan Iyer" , "John Strassner" , "Marcus Brunner" , "Ron Cohen" Cc: , References: <20001211042641.30000.qmail@web10501.mail.yahoo.com> Subject: Re: gpsPolicyGroup class in qos info model Date: Mon, 11 Dec 2000 11:25:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Mahadevan, I'm still confused. It sounds like you want to copy the conditions inside different rules that are contained in different groups to a higher level of containment in order to trim the tree, right? This is what I meant when I said: "As you say, a policyRule is an atomic object. You're asking to "peek inside" a group of policyRules in a policyGroup and copy their aggregate conditions out into a higher-level condition that you can then trap on." Now, while this may work for PCIM, for QPIM I don't think it can work, because at the very minimum, this means that you also have to copy the decision strategies that are applied to each group of conditions. QPIM provides the ability to CHANGE decision strategies at each containment level. This means that you now have to re-create the decision strategies defined at each container and apply them to the conditions at each level of containment. You haven't addressed how this will be done. In addition, in QPIM, we have nested rules as well as sub-rules. You can't flatten out the condition in these cases, or you lose the hierarchy of the structure of the rules. You also haven't addressed how this will be done. That's why I continue to have questions. regards, John ----- Original Message ----- From: "Mahadevan Iyer" To: "John Strassner" ; "Marcus Brunner" ; "Ron Cohen" Cc: ; Sent: Sunday, December 10, 2000 8:26 PM Subject: Re: gpsPolicyGroup class in qos info model > --- John Strassner wrote: > > Hi Mahadevan, > > > > I'm still not quite sure I understand your reasoning > > for the > > putting an aggregate condition in the gpsPolicyRule > > class. > > Hello John, > > there are 2 parts to this reply : > > 1. Issues raised in your response, > 2. Explanation of the requirement. > > Issues raised in your response ... > > 1. There is no "peeking" inside the rules, it is an > administrator generated condition. This should answer > most of your issues related to aggregating conditions > and decisions. > > 2. The PolicyRuleInPolicyRule can satisfy the > requirement. I have explained my reservations > regarding using this class in my earlier email. > > Explanation of the requirement ... > > 1. The requirements is driven from the practical > issues at the PDP. I have a whole tree of policies and > nothing but the priority to decide how I traverse the > tree(at the group level). This could be a very > expensive. I need to have a quick way of narrowing > down the possibilities at the top of the tree(where > the policyGroups are defined). It is a lot more than > an optimization, it would be a requirement when > defining policy trees for a carrier network. > > Do you see this as a problem that needs to be > addressed at this level ? > > > Thanks > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Mon Dec 11 21:05:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26548 for ; Mon, 11 Dec 2000 21:05:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA10350 for ipsec-policy-bks; Mon, 11 Dec 2000 16:47:07 -0800 (PST) Received: from ns1.49thietf.org (ietf.207.137.80.5.tx.verio.net [207.137.80.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10346 for ; Mon, 11 Dec 2000 16:47:06 -0800 (PST) Received: from bbn.com (ietf.207.137.74.16.tx.verio.net [207.137.74.16]) by ns1.49thietf.org (8.9.3+Sun/8.9.3) with ESMTP id QAA04093 for ; Mon, 11 Dec 2000 16:49:39 -0800 (PST) Message-ID: <3A3557C9.5B85EF63@bbn.com> Date: Mon, 11 Dec 2000 17:40:09 -0500 From: "Luis A. Sanchez" Organization: BBN Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: Tonight's Agenda Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, here is the agenda for tonight's meeting. -L IPsec Policy Agenda Agenda Bashing 5min L. Sanchez Roadmap Document 20min H. Orman Requirements Doc 20min A. Keromytis IPsec Conf Model 15min J. Jason QPIM/IPsec Model Inc 15min L. Rafalow Arch. Issues 20min A. Rayhan SPSL Updates 15min M. Condell IPsec MIB 15min R. Charlet IPsec PIB 20min M. Li Discussions 15min L. Sanchez/H. Orman From owner-ipsec-policy@mail.vpnc.org Tue Dec 12 01:48:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07057 for ; Tue, 12 Dec 2000 01:48:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA15178 for ipsec-policy-bks; Mon, 11 Dec 2000 21:32:26 -0800 (PST) Received: from web10507.mail.yahoo.com (web10507.mail.yahoo.com [216.136.130.157]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA15174 for ; Mon, 11 Dec 2000 21:32:25 -0800 (PST) Message-ID: <20001212053429.7077.qmail@web10507.mail.yahoo.com> Received: from [198.206.187.100] by web10507.mail.yahoo.com; Mon, 11 Dec 2000 21:34:29 PST Date: Mon, 11 Dec 2000 21:34:29 -0800 (PST) From: Mahadevan Iyer Subject: Re: gpsPolicyGroup class in qos info model To: John Strassner , Marcus Brunner , Ron Cohen Cc: policy@raleigh.ibm.com, ipsec-policy@vpnc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --- John Strassner wrote: > I'm still confused. It sounds like you want to copy > the Not copy, let the administrator create higher level condition traps. They might be very coarse and loose. They will provide a coarse level of aggregation. I agree that if we try to directly copy we will run into the problems as you have pointed out. > conditions inside different rules that are contained > in > different groups to a higher level of containment in > order > to trim the tree, right? This is what I meant when I > said: Exactly right: "Trim the tree" for the decision process. > > "As you say, a policyRule is an atomic object. > You're > asking to "peek inside" a group of policyRules in > a > policyGroup and copy their aggregate conditions > out > into a higher-level condition that you can then > trap on." Not copy as stated earlier. > > Now, while this may work for PCIM, for QPIM I don't > think it > can work, because at the very minimum, this means > that you > also have to copy the decision strategies that are > applied > to each group of conditions. QPIM provides the > ability to > CHANGE decision strategies at each containment > level. This > means that you now have to re-create the decision > strategies > defined at each container and apply them to the > conditions > at each level of containment. You haven't addressed > how this > will be done. I agree that it will not be feasable to do this automatically and will not be feasable to do it at every level. It is upto the administrator to decide whether he wants to include an aggregated condition at a certain point or not. It is upto the administrator to manually build the condition. > > In addition, in QPIM, we have nested rules as well > as > sub-rules. You can't flatten out the condition in > these > cases, or you lose the hierarchy of the structure of > the > rules. You also haven't addressed how this will be > done. > > That's why I continue to have questions. I hope I have communicated the problem clearly. At this point I can't think of an alternative solution to the problem. As far as the QPIM if I were to take the example quoted on page 24 (version 02). I am assuming that PDP's within a region would try to trim the policy tree by picking up policies meant for their respective regions.(I have posted some related questions "Policy Target, Policy Domains etc" on the mailing list) If most of the policies have to do with inter-region traffic or inter-group traffic to a hub there isn't much trimming I can do on the basis of "policies required by a region". In such cases source and destination of the traffic can be used to zero in into a policy group which then defines exactly what policies need to be applied to the traffic. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Tue Dec 12 02:05:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19494 for ; Tue, 12 Dec 2000 02:05:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA15545 for ipsec-policy-bks; Mon, 11 Dec 2000 21:58:43 -0800 (PST) Received: from nyarlathotep.cis.upenn.edu (ietf.207.137.75.31.tx.verio.net [207.137.75.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15541 for ; Mon, 11 Dec 2000 21:58:41 -0800 (PST) Received: from dsl.cis.upenn.edu (localhost [127.0.0.1]) by nyarlathotep.cis.upenn.edu (8.10.1/8.9.3) with ESMTP id eBC614l03580 for ; Tue, 12 Dec 2000 01:01:04 -0500 (EST) Message-Id: <200012120601.eBC614l03580@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec-policy@vpnc.org Subject: IETF-49 (San Diego) IPSP WG minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Dec 2000 01:01:04 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Meeting agenda Agenda bashing (L. Sanchez) Roadmap document (H. Orman) Requirements doc. (M. Blaze) IPsec config. model (J. Jason) QPIM/IPsec model (L. Rafalow) Arch. Issues (A. Rayhan) SPSL updates (M. Condell) IPsec Config. MIB (R. Charlet) IPsec MIB (M. Li) Discussion (L. Sanchez) Roadmap items (Hilarie Orman) ------------- Hilarie talked about the intent on producing various documents: Requirements: standards track Data model: standards track Architecture: standards track Policy language: standards track - also parser implementation Provisioning: standards track - implementations Policy exchange and negotiation protocol: standards track IMPLEMENTATIONS! Hilarie talked about the status of documents (see slides for draft names). Comments are sorely needed on the requirements and architecture drafts, to begin with; comments on all the other drafts (policy model, etc.) is also needed. Need for policy MIBs; we also need to make sure the various (numerous) documents are consistent with each other. We need definitions for: - authentication policy (and translation into data items) - definition of "security domain" - policy integrity Requirements Document (Matt Blaze) --------------------- Matt outlined the issues referenced in the requirements document: - policy model - gateway discovery mechanism - policy languages for nodes - means for distributing responsibility - protocol for discovering policy - method for resolving SA parameters - semantics for compliance checking SA parameters & gateways against each node's policy - no changes to anything else (IKE, IPsec, etc) Policy model: defines all the semantics of IPsec policy, and should be independent of specific details (language, protocols, etc.) Gateway discovery: self-explanatory IPSP language: this is for externalizing policy; how policy is expressed internally is not important for this WG Distribute policy: delegation; mus tbe possible to have remote administration of node's policy Policy discovery: protocol used by nodes to determine how to talk to each other; does not need to be full-disclosure. SA parameter resolution: given the results from policy discovery, resolve those in determining what can/should be used for the SAs. Must be computationally efficient enough to be practical (general case is NP complete). Compliance checking: given a set of proposed SA parameters, verify that a node must be able to verify whether they meet its own policy. This is where policy enforcement is implemented (and is safe even if SA resolution gives wrong results). No changes to anything else: self-explanatory -- IPsec too long enough and is complicated enough. Slides on: http://www.crypto.com/talks Question: how much is authorization vs. "what to propose" ? Answer: one input to IPSP as a system is "I want to talk to host foo, tell me what I need to do"; on the other side, the `responder` needs to verify a symmetric operation, in verifying that the proposed attributes (SA parameters, addresses, authentication mode, etc.) meet local node policy. Question: in addition to doing gateway discovery, do we also discover other information like proxy nodes behind the gateway ? Answer: this is probably outside the scope of the IPsec policy. Question: When we're done with the work, do you think we'll be able to be as flexible/easy-to-use/whatever as SSL (talk to anyone in the world with minimal or no setup) ? Or is IPSP more geared towards extranet-like scenarios ? Answer: We certainly want to be able to do the talk-to-anyone scenario. Solving the end-to-end communication case, makes it possible to actually solve the network-to-network (firewall-to-firewall) configuration etc. IPsec Policy Model Updates (Jamie Jason) -------------------------- Numerous changes to DMTF version since last IETF; model has stabilized, and has been submitted for inclusion in CIM v2.5. Those updates will be rolled up into IETF version. Numerous changes in Policy, Condition/Filter, Action, Proposal/Transform classes were described (too many/too fast to write down -- see the slides for details). New draft with those changes will probably be out in January. Location of slides will be posted on the mailing list by Jamie. Question: is the model supposed to capture authorization issues ? Answer: the CredentialFilter entries are supposed to capture the authentication side of authorization; the rest of the model can capture authorization issues like time-of-day considerations (e.g., "users can only login between 9am-5pm") IPSP Configuration Model Framework Feedback (Lee Rafalow) ------------------------------------------- http://rafalow.home.mindspring.com/dmtf.htm Some differences in the models between PCIM/QPIM and IPsec Configuration Information model. Some of them come from layering variations: - PCIM is a general framework - QPIM is a domain-level policy model - IPsec Configuration Information Model is a device-level policy model Condition differences: - IPSP provides discipline-specific condition evaluation information, where as QPIM uses a more generic approach - There are different identities in IPsec, at different times in the protocol sequence. - Condition evaluation is predicated on presence of information (e.g., some rule may begin as true, but eventually turn out to be false -- an example was given with Phase 1 IDs in IKE); this is partly because of authentication (some information in the protocol is authenticated/verified long after it is known/discovered/assumed) Group-related differences: - Priorities are applied to groups vs. individual filters (IPSP vs. QPIM) - Rules in exactly one group (in PCIM they can be in multiple groups) - Unique rule & group priorities (thus, deterministic rule evaluation order) - Different Decision strategies: - IPSP uses MatchFirst - QPIM has a number of different strategies Policy Roles: - IPSP uses explicit association of rules with interfaces; PCIM uses a named relationship. - IdentityContext Other discussion topics: - Sequence actions (like FallBack) between PCIM and IPSP somewhat different semantics ("mandatory" vs. "use first appropriate") Question: what happens if we don't resolve those differences ? Answer: we probably want to keep in sync as much as possible, if only to make it possible to interact. There aren't any specific disasters. Comment from Luis: differences between the IPSP model and models from other WGs will be tolerated if it's necessary to be different. Otherwise, it makes sense to reconcile. Lee: there are a couple of important differences, but most of the changes are details and don't really matter. Architecture Issues (A. Rayhan) ------------------- draft-cuervo-ipsp-arch-02.txt (hasn't made it into the I-D yet) Abdul discussed the issues on the mailing list: - Discovery and resolution: should these be bundled ? Currently, several concepts are merged in one protocol (gateway discovery, policy negotiation, exchange, resolution, distribution). Proposal to separate discovery from resolution: - stable/scalable framework for the development of the architecture - provide stronger security model - allow better extensibility There are two types of policies: distributed and local. Distributed: SGs need to be discovered and tunneling policies should be resolved. Local: access and SA policies are installed only on the two ends of the tunnel and there is no need for collective knowledge. Distributed policies reflect mostly security requirements, whereas local policies reflect security policies. Requirements for distributed policies: - requests can at least be authenticated (can't be encrypted) - piggyback requests in a message can be used to construct a topology matrix - the topology matrix is used to resolve conflicts across SGs - this phase precedes the next phase - Policy Signaling Protocol Requirements for local policies: (too fast to write down, see slides) Summary: separate gateway discovery and policy distribution Slides will be made available through the mailing list. Question: are the end hosts involved in the signaling ? Answer: they can be (they can pretend to be security gateways for themselves) SPSL Updates (M. Condell) ------------ Matt gave a quick update on the status of the SPSL draft; current one has expired but there's been work on the new one (hopefully available in the next month or two). Briefly: some classes were combined, short form of policy class was dropped, added forward action, and some text cleanup. Some more changes to appear (in the new draft): policy file description class (for describing the policy file itself), logging actions, add missing defaults for some selectors and actions, finish incomplete sections (certificate encodings, general SA endpoints, re-think object signing, support for DNS names wherever missing). IPsec Configuration MIB (R. Charlet) ----------------------- Rick talked about the status of this effort; in short, have done about 20% of a MIB so far, but in conflict with the IPsec PCIM at this point. Group of volunteers approach hasn't worked very well so far, will take the effort to the mailing list. Intent to have a -00 draft before next IETF. A high-level group outline of the MIB was shown, feedback requested. Question: is there any work in the Policy Framework WG that allows derivation of MIB from a PCIM ? Answer: not really; there's some experience in the area, but no tools or anything solid at this point. IPsec Policy Information Base (PIB) (M. Li) ----------------------------------- draft-ietf-ipsp-ipsecpib-01.txt PIBs are used by policy servers to distribute IPsec policy to IPsec-enabled devices (gateways, routers, laptops, etc.) using the COPS protocol. COPS is used for QoS configuration, so the goal is to reuse the same mechanism. New items in draft -01: - Separate roles in IPsec and IKE rules, so they can be used independently from each other. - Added start-up conditions for IPsec and IKE rules It used to be there was only "OnDemand" condition (as packets showed up). There are three new types: - OnBoot (when a system boots) - OnTraffic (OnDemand) - OnPolicy (time-based, a rule is fired or becomes valid based on time constraints) - Modified Selector table construction - Added Conformance section Things to add: need to align with IPsec Information Model, and add policy target IPsec capabilities. Question: it seems difficult to keep this synchronized with the Information Model. It looks like it's a moving target trying to keep them consistent with each other. Answer1: one approach is to get the Information Model more or less stable, then try to sync the PIB. Answer2: there's all sorts of problems with policy versioning and migration, that are related to this. Difficult issue. --- End of presentations --- Luis: - We need to send the following documents to Last Call: IPSP RoadMap, IPSP Requirements, IPsec Configuration Policy Model Feedback is needed! Hilarie: What's the status of implementations, especially on the Information Model ? Jamie: there has been some feedback from inside the DMTF process, some people are trying to implement the Information Model. Answer2: one reason we're not seeing implementation feedback is because policy is a large project *and* all-or-nothing. A "first step" approach may be easier to follow. Luis: the information model is trying to capture the complexity of the existing IPsec protocols, thus it has to be pretty big and comprehensive. Marcus: there's a large dependency on humans to interpret policy for firewalls etc. so IPSP should make it easier to automate this process. End of session. From owner-ipsec-policy@mail.vpnc.org Tue Dec 12 15:36:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06745 for ; Tue, 12 Dec 2000 15:36:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA05476 for ipsec-policy-bks; Tue, 12 Dec 2000 10:35:18 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05471 for ; Tue, 12 Dec 2000 10:35:16 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 10:37:23 -0800 Received: from redcreek.com (MAXWELL [209.125.38.89]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YB6JPB7M; Tue, 12 Dec 2000 10:37:05 -0800 From: Ricky Charlet To: ipsec-policy@vpnc.org Message-ID: <3A367043.87707885@redcreek.com> Date: Tue, 12 Dec 2000 10:36:53 -0800 X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: IP Sec Conf MIB so far Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, The status of the IPsec Configuration MIB development is 'in-progress' (about 20% of the way to a -00 draft). This is pretty early to publish such an unfinished document, but I said I would at the IPSP meeting, so I will. Ricky Charlet ========================================= Internet Engineering Task Force Ricky Charlet INTERNET DRAFT (well not yet really) RedCreek Communications 18-November-2000 Long Name of this MIB thing for configuring IPsec devices ShortName Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract Table of Contents 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for configuring IPsec devices. This memo also includes a MIB module. This MIB module extends the list of managed objects specified in the earlier version of this MIB:RFC 2239 [21]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [20]. IPsec devices need to be configured. This MIB provides one way in which to provide configuration information to IPsec devices. This MIB strives to maintain strong compliance with draft-ietf-ipsp-config-policy-model-XX.txt. At the highest level, IPsec configuration must be able to specify parameters sufficient to handle the generic statement, "If this IP packet meets some listed condition, then perform the associated action on the packet." IETF work on representing IP traffic matching conditions is in progress in the Policy Working Group. This MIB seeks to adhere to their general architectural layout in terms of its representation of conditions. This MIB also provides specification for configuring actions. Each condition references an action or a named set of actions. IPsec actions may be cryptographic transforms which require cryptographic keys and trustable identities. To that end, this MIB also provides capability to configure a manual keying system, to configure the Internet Key Exchange protocol, and richly identify entities for which IPsec will provide services. 2. The SNMP Management Framework <> 3. Textual Conventions This section describes any SNMP Textual Conventions we decide to introduce. 4. Discussion This MIB is divided into a Condition Group and an Action Group. The condition group provides capabilities to identify IP packets as they pass an interface on an IP device. The Action Group contains some tables to configure simple actions like pass and block, but also contains a Secure Action Group which is further divided into an Identities Group, Key Management Group, and an IPsec Group. IPsecPolicyConfigMib + Condition Group | + + Action Group | + | + Secure Group | | +Identities Group | | | + | | +KeyMgmtGroup | | | + DH Group | | | | + | | | + | | | + IKE Group | | | | + | | | | + IKE Transform Table | | | +Kerberose Group (?? do we want to go here) | | +IPsec Group | | | + | | | + ESP Transform Table | | | + AH Transform Table 5. Security Concerns This entire document discusses a mechanism used to configure IPsec devices. The mechanism proposed here also provides security services of its own apart from IPsec. 5.1 Bootstrapping configuration <> 5.2 ... 5.3 ... -- MIB SOME-KIND-OF-SHORT-MIB-NAME ::= BEGIN -- Module Identity Section Here camelBackSpellingOfShortName ::= OBJECT-IDENTITY { nodeName number } -- Imports Section Here ConditionGroup OBJECT IDENTIFIER ::= { camelBackSpellingOfShortName 1 } -- ================ -- Condition Group -- Concerned With: representing and identifying IPsec endpoints for use with -- IPsec selectors. -- Holds: ....... -- ================ ActionGroup OBJECT IDENTIFIER ::= { camelBackSpellingOfShortName 2 } -- ================ -- Action Group -- Concerend With: names and specifies actions. Some actions are simple (like -- pass and block) and belong in a table at this level. But -- secure actions are complex and require another group to hold -- them. -- Holds: some tables and SecureGroup -- =============== SecureGroup OBJECT IDENTIFIER ::= { ActionGroup 2 } -- ================ -- Secure Group -- -- Holds: some tables, IdentitiesGroup, KMGroup, IPsecGroup -- ================ IdentitiesGroup OBJECT IDENTIFIER ::= { SecureGroup 1 } -- ================ -- IdentitiesGroup -- Concerned With: Holding the credentials of prospective end points, peers -- and CAs. -- Holds: tables to hold Pre Shared Keys, certificates representing endpoints, -- certificates representing CAs, RSA public keys of peers, -- and certificate filters -- ================ -- ================ -- IkeTransformTable -- holds the parameters to implement a particular IKE SA -- ================ IkeTransformTable OBJECT-TYPE SYNTAX SEQUENCE OF RcV4IkeTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "IkeTransformTable holds all the possible implementation variations (which have been configured on this device) of a Phase I SA. " ::= { KeyMgmtGroup 4 } IkeTransformEntry OBJECT-TYPE SYNTAX RcV4IkeTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "IkeTransformEntry represents the parameters necessary to implement a particular Phase I SA." INDEX { IkeTransformCN } ::= { IkeTransformTable 1 } RcV4IkeTransformEntry ::= SEQUENCE { IkeTransformCN CommonName, IkeAuthMethod INTEGER, IkeIntegrityAlgorithm INTEGER, IkeCipherAlgorithm INTEGER, IkeCipherKeyLength Unsigned32, IkeCipherKeyRounds Unsigned32, IkeDHGroupType INTEGER, IkeDHGroupRef CommonName, IkeLifetimeSec Unsigned32, IkeLifetimeCount Unsigned32, IkeTransformRowStatus RowStatus } IkeTransformCN OBJECT-TYPE SYNTAX CommonName MAX-ACCESS not-accessible STATUS current DESCRIPTION "IkeTransformCN indexes IkeTransformTable. It provides a human readable name for an IKE Transform." ::= { IkeTransformEntry 1 } IkeAuthMethod OBJECT-TYPE SYNTAX INTEGER { preSharedKey (1), dssSignature (2), rsaSignature (3), encryptWithRsa (4), revisedEncryptWithRsa (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "Ike2048AuthMethod selects a methodology to used to authenticate IKE exchanges." ::= { IkeTransformEntry 2 } IkeIntegrityAlgorithm OBJECT-TYPE SYNTAX INTEGER { md5 (1), sha (2) -- tiger (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "IkeIntegrityAlgorithm selects which algorithm will be used for integrity." ::= { IkeTransformEntry 3 } IkeCipherAlgorithm OBJECT-TYPE SYNTAX INTEGER { desCbc (1), -- ideaCbc (2), -- blowfishCbc (3), -- rc5Rc16B64Cbc (4), tripleDesCbc (5) -- castCbs (6) } MAX-ACCESS read-create STATUS current DESCRIPTION "IkeCipherAlgorithm selects which algorithm will be used for encryption/privacy." ::= { IkeTransformEntry 4 } IkeCipherKeyLength OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Since different cipher algorithms require different lengths of keys, IkeCipherKeyLength clarifies how long the required key in bits will be for the cipher algorithm mentioned in this row's IkeCipherAlgorithm field." ::= { IkeTransformEntry 5 } IkeCipherKeyRounds OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "." ::= { IkeTransformEntry 6 } IkeDHGroupType OBJECT-TYPE SYNTAX INTEGER { standard (1) -- manual (2), -- generated (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "IkeDHGroupType specifies if the DH group is to come from the standard 4 groups listed in rc2409 or from a private group. If DH groups are private, then they may either be manually entered or algorithmicly generated." DEFVAL { standard } ::= { IkeTransformEntry 7 } IkeDHGroupRef OBJECT-TYPE SYNTAX CommonName MAX-ACCESS read-create STATUS current DESCRIPTION "If IkeDHGroupType is 'standard', then IkeDHRef should be one of the following strings: 'group1', 'group2', 'group3', 'group4' or 'group5'. These strings indicate which of the five standard groups from rc2409 and the son-of-ike Internet draft is to be used. If IkeDHGroupType is 'manual' then IkeDHRef should be a common name reference to the PrivateDHGroupsTable. If IkeDHGroupType is 'generated' then IkeDHRef should be common name reference to the PrivateDHGroupsGenerationTable." DEFVAL { "group2" } ::= { IkeTransformEntry 8 } IkeLifetimeSec OBJECT-TYPE SYNTAX Unsigned32 (180..4294967296) MAX-ACCESS read-create STATUS current DESCRIPTION "IkeLifetimeSec is the number of seconds which this Phase I SA is allowed to live for before re-keying." DEFVAL { 28800 } -- 8 hrs. ::= { IkeTransformEntry 9 } IkeLifetimeCount OBJECT-TYPE SYNTAX Unsigned32 (2..4294967296) MAX-ACCESS read-create STATUS current DESCRIPTION "IkeLifetimeCount represents the number of Kilo- Bytes this Phase I SA is allowed to carry before re-keying. This object is currently unsupported. And may change in the future to by the number of key-exchanges which have occurred on this SA." ::= { IkeTransformEntry 10 } IkeTransformRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Row Status. See RFC1903 SNMPv2-TC" ::= { IkeTransformEntry 99 } IpsecActionGroup OBJECT IDENTIFIER ::= { SecureGroup 4 } -- ================ -- IpsecActionGroup -- Concerend With: Constructing SA and SA bundle proposals. -- Holds: tables to configure suites of IPsec proposals, and ESP and AH -- transforms. -- ================ -- ================ -- EspTransformTable -- This table sets the parameters of particular ESP transforms. -- ================ EspTransformTable OBJECT-TYPE SYNTAX SEQUENCE OF RcV4EspTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "EspTransformTable holds all the ways that the ESP protocol has been configured on this device." ::= { IpsecActionGroup 3 } EspTransformEntry OBJECT-TYPE SYNTAX RcV4EspTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "EspTransformEntry holds the particular parameters of how to implement an ESP transform." INDEX { EspCN } ::= { EspTransformTable 1 } RcV4EspTransformEntry ::= SEQUENCE { EspCN CommonName, EspCipherAlg INTEGER, EspIntegrityAlg INTEGER, EspCipherKeyLength Unsigned32, EspCipherKeyRounds Unsigned32, EspAntiReplay INTEGER, EspTransformRowStatus RowStatus } EspCN OBJECT-TYPE SYNTAX CommonName MAX-ACCESS not-accessible STATUS current DESCRIPTION "EspCN indexes the EspTransform Table. It provides a human readable name for an ESP Tansform." ::= { EspTransformEntry 1 } EspCipherAlg OBJECT-TYPE SYNTAX INTEGER { -- esp-DES-IV64 (1), esp-DES (2), esp-3DES (3), -- esp-RC5 (4), -- esp-IDEA (5), -- esp-CAST (6), -- esp-BLOWFISH (7), -- esp-3IDEA (8), -- esp-DES-IV32 (9), -- esp-RC4 (10), esp-NULL (11) } MAX-ACCESS read-create STATUS current DESCRIPTION "EspCipherAlg specifies which algorithm will provide encryption / privacy services for this transform. Note, it is an error to attempt setting EspIntegrityAlg to 'no-AUTH' and EspCipherAlg to 'esp-NULL' in the same transform proposal." ::= { EspTransformEntry 2 } EspIntegrityAlg OBJECT-TYPE SYNTAX INTEGER { hmac-MD5 (1), hmac-SHA (2), -- des-MAC (3), -- kpdk (4), no-AUTH (61440) } MAX-ACCESS read-create STATUS current DESCRIPTION "EspIntegrityAlg selects which algorithm will provide integrity services for this transform. Note, it is an error to attempt setting EspIntegrityAlg to 'no-AUTH' and EspCipherAlg to 'esp-NULL' in the same transform proposal." ::= { EspTransformEntry 3 } EspCipherKeyLength OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "EspCipherKeyLength specifies the length of the key in bits required by the cipher algorithm named in EspCipherAlg." ::= { EspTransformEntry 4 } EspCipherKeyRounds OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "." ::= { EspTransformEntry 5 } EspAntiReplay OBJECT-TYPE SYNTAX INTEGER { off (0), standard (32), large (64), huge (128) } MAX-ACCESS read-create STATUS current DESCRIPTION "EspAntiReplay specifies whether or not anti-Replay services are provided by this transform and if so, what the window size is. off - anti replay services are not provided by this transform standard - anti replay is on and window size is 32 packets large - anti replay is on and window size is 64 packets huge - anti replay is on and window size is 128 packet Choosing large or huge window size is a compromize to relax security a bit in order to accomodate very low latency networks. " DEFVAL { standard } ::= { EspTransformEntry 6 } EspTransformRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Row Status. See RFC1903 SNMPv2-TC" ::= { EspTransformEntry 99 } -- ================ -- AhTransformTable -- This table sets the parameters of particular AH transforms. -- ================ AhTransformTable OBJECT-TYPE SYNTAX SEQUENCE OF RcV4AhTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "AhTransformTable holds all the ways that the AH protocol has been configured on this device." ::= { IpsecActionGroup 4 } AhTransformEntry OBJECT-TYPE SYNTAX RcV4AhTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "AhTransformEntry holds the particular parameters needed to implement this AH transform." INDEX { AhEntryCN } ::= { AhTransformTable 1 } RcV4AhTransformEntry ::= SEQUENCE { AhEntryCN CommonName, AhAuthAlg INTEGER, AhAntiReplay INTEGER, AhTransformRowStatus RowStatus } AhEntryCN OBJECT-TYPE SYNTAX CommonName MAX-ACCESS not-accessible STATUS current DESCRIPTION "AhEntryCN indexes AhTransformTable. It provides a human readable name for an AH Transform." ::= { AhTransformEntry 1 } AhAuthAlg OBJECT-TYPE SYNTAX INTEGER { ah-MD5 (2), ah-SHA (3), ah-DES (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "AhAuthAlg selects which algorithm will provide authentication services for this transform." ::= { AhTransformEntry 2 } AhAntiReplay OBJECT-TYPE SYNTAX INTEGER { off (0), standard (32), large (64), huge (128) } MAX-ACCESS read-create STATUS current DESCRIPTION "AhAntiReplay specifies whether or not anti-Replay service From owner-ipsec-policy@mail.vpnc.org Tue Dec 12 18:05:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00920 for ; Tue, 12 Dec 2000 18:05:48 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17387 for ipsec-policy-bks; Tue, 12 Dec 2000 13:50:55 -0800 (PST) Received: from ns1.49thietf.org (ietf.207.137.80.5.tx.verio.net [207.137.80.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17382 for ; Tue, 12 Dec 2000 13:50:54 -0800 (PST) Received: from ccrle.nec.de (ietf.207.137.70.105.tx.verio.net [207.137.70.105]) by ns1.49thietf.org (8.9.3+Sun/8.9.3) with ESMTP id NAA05730; Tue, 12 Dec 2000 13:49:42 -0800 (PST) Message-ID: <3A354A3A.9CA4AA09@ccrle.nec.de> Date: Mon, 11 Dec 2000 22:42:18 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de MIME-Version: 1.0 To: John Strassner CC: Ron Cohen , Mahadevan Iyer , policy@raleigh.ibm.com, ipsec-policy@vpnc.org Subject: Re: gpsPolicyGroup class in qos info model References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de> <001201c06250$b7a73bf0$19ee130a@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, John Strassner wrote: > > PolicyRuleInPolicyRule is used to build sub-rules. We also > allow for PolicyGroupInPolicyRule to build a sub-rule, with > a policyGroup as a nested container. This capability is not > in PCIM. > Do you have an example, motivating why the rule in the rule is useful? Is there a specific application of this modeling for QPIM? I personally do not like having a rule playing so many different role. The containment is dealt with in the policy group, why should a policy rule also be a container for sub-rules? > As far as the context, sub-rules execute before their > containing rules, as explained in the draft. > Thank you, I have not found this in the draft. > I not only don't like conditions in gpsPolicyGroup, I don't > think they work. > I do not like the as well. Marcus > regards, > John > ----- Original Message ----- > From: "Marcus Brunner" > To: "Ron Cohen" > Cc: "Mahadevan Iyer" ; > ; > Sent: Thursday, December 07, 2000 9:29 PM > Subject: Re: gpsPolicyGroup class in qos info model > > > Ron, > > > > I agree with Mahadevan, that I do not like the > policyRuleInPolicyRule method, > > because > > a) there are now two different grouping models, > > b) it is unclear what happens to the context when the > ruleInrule is executed > > (full new start of execution engine or reuse the context) > > c) I do not see the need for rulesInrules, what makes them > different compared to > > the grouping already available > > > > However, I do not agree to add a condition to the group. I > think what is > > available is enough. > > > > Marcus > > > > Quoting Ron Cohen : > > > > > Mahadevan, > > > > > > Can you provide more details why you prefer to change > the gpsPolicyGroup > > > than using the current policyRuleInPolicyRule method? > > > > > > Thanks > > > Ron > > > > > > > > > >I would like to suggest an update to the > > > >gpsPolicyGroup class. > > > >This also relates to the PolicyRuleInPolicyRule usage. > > > > > > > >I need to indicate that a group of policy rules should > > > >be checked only if the traffic matches some aggregate > > > >conditions. These aggregate conditions summarize the > > > >conditions within the policy rules. > > > > > > > >I would like to specify the aggregate conditions at > > > >the level of the gpsPolicyGroup. An alternative is to > > > >use the PolicyRule + PolicyRuleInPolicyRule instead of > > > >the gpsPolicyGroup. However I prefer to use the > > > >gpsPolicyGroup. > > > > > > > >I would suggest adding an aggregate policy condition > > > >to the gpsPolicyGroup. This condition would typically > > > >be a gpsPolicyCompoundCondition. > > > > > > > > > > > >Thanks > > > > > > > >__________________________________________________ > > > >Do You Yahoo!? > > > >Yahoo! Shopping - Thousands of Stores. Millions of > Products. > > > >http://shopping.yahoo.com/ > > > > > > > > > > > > > > Dr. Marcus Brunner > > C&C Research Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.tik.ee.ethz.ch/~brunner > > > > Adenauerplatz 6 > > D-69115 Heidelberg > > Germany > > > > Phone: +49 (0)6221/ 9051129 > > Fax: +49 (0)6221/ 9051155 From owner-ipsec-policy@mail.vpnc.org Tue Dec 12 22:11:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19804 for ; Tue, 12 Dec 2000 22:10:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA23654 for ipsec-policy-bks; Tue, 12 Dec 2000 17:56:14 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA23650 for ; Tue, 12 Dec 2000 17:56:12 -0800 (PST) From: Man.M.Li@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eBD1xM612882 for ; Tue, 12 Dec 2000 19:59:32 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 12 Dec 2000 19:58:40 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 12 Dec 2000 19:58:40 -0600 Message-ID: To: ipsec-policy@vpnc.org Subject: Configuration model vs. DMTF model Date: Tue, 12 Dec 2000 19:50:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We know that the ipsp IPsec configuration model is based on that of DMTF. But to be more specific, is the ipsp model the same, a superset or a subset of that of DMTF? Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 From owner-ipsec-policy@mail.vpnc.org Wed Dec 13 02:12:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03832 for ; Wed, 13 Dec 2000 02:12:35 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA28828 for ipsec-policy-bks; Tue, 12 Dec 2000 22:00:20 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28823 for ; Tue, 12 Dec 2000 22:00:19 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id WAA04610; Tue, 12 Dec 2000 22:02:30 -0800 (PST) Received: from jstrassnlap (sj-dial-4-45.cisco.com [171.68.181.174]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AEJ13417; Tue, 12 Dec 2000 22:02:23 -0800 (PST) Message-ID: <015c01c064ca$c1f47a10$aeb544ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Mahadevan Iyer" , "John Strassner" , "Marcus Brunner" , "Ron Cohen" Cc: , References: <20001212053429.7077.qmail@web10507.mail.yahoo.com> Subject: Re: gpsPolicyGroup class in qos info model Date: Tue, 12 Dec 2000 13:43:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think I understand in principle what you want to do, but just to be clear, is this a fair description: you want to be able to trim a tree of policy information from consideration to be evaluated efficiently; therefore, you want to add a condition clause, defined by the admin, on a high-level container, to do this Assuming that this is correct, you still haven't addressed how you accommodate decision strategy and nested rules. In other words, are you proposing that you construct these new trimming rules INDEPENDENTLY of the actual structure of the rules below that containment point (e.g., taking into account their individual decision strategies, priorities, etc.)? How can you be sure that you are capturing the semantics and maintaining the correct execution order by your newly defined trimming rules? regards, John ----- Original Message ----- From: "Mahadevan Iyer" To: "John Strassner" ; "Marcus Brunner" ; "Ron Cohen" Cc: ; Sent: Monday, December 11, 2000 9:34 PM Subject: Re: gpsPolicyGroup class in qos info model > --- John Strassner wrote: > > I'm still confused. It sounds like you want to copy > > the > > Not copy, let the administrator create higher level > condition traps. They might be very coarse and loose. > They will provide a coarse level of aggregation. > I agree that if we try to directly copy we will run > into the problems as you have pointed out. > > > conditions inside different rules that are contained > > in > > different groups to a higher level of containment in > > order > > to trim the tree, right? This is what I meant when I > > said: > > Exactly right: "Trim the tree" for the decision > process. > > > > > "As you say, a policyRule is an atomic object. > > You're > > asking to "peek inside" a group of policyRules in > > a > > policyGroup and copy their aggregate conditions > > out > > into a higher-level condition that you can then > > trap on." > > Not copy as stated earlier. > > > > > Now, while this may work for PCIM, for QPIM I don't > > think it > > can work, because at the very minimum, this means > > that you > > also have to copy the decision strategies that are > > applied > > to each group of conditions. QPIM provides the > > ability to > > CHANGE decision strategies at each containment > > level. This > > means that you now have to re-create the decision > > strategies > > defined at each container and apply them to the > > conditions > > at each level of containment. You haven't addressed > > how this > > will be done. > > I agree that it will not be feasable to do this > automatically and will not be feasable to do it at > every level. > It is upto the administrator to decide whether he > wants to include an aggregated condition at a certain > point or not. It is upto the administrator to manually > build the condition. > > > > > In addition, in QPIM, we have nested rules as well > > as > > sub-rules. You can't flatten out the condition in > > these > > cases, or you lose the hierarchy of the structure of > > the > > rules. You also haven't addressed how this will be > > done. > > > > That's why I continue to have questions. > > I hope I have communicated the problem clearly. > At this point I can't think of an alternative solution > to the problem. > > As far as the QPIM if I were to take the example > quoted on page 24 (version 02). > > I am assuming that PDP's within a region would try to > trim the policy tree by picking up policies meant for > their respective regions.(I have posted some related > questions "Policy Target, Policy Domains etc" on the > mailing list) > > If most of the policies have to do with inter-region > traffic or inter-group traffic to a hub there isn't > much trimming I can do on the basis of "policies > required by a region". > > In such cases source and destination of the traffic > can be used to zero in into a policy group which then > defines exactly what policies need to be applied to > the traffic. > > Thanks > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Wed Dec 13 02:45:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12961 for ; Wed, 13 Dec 2000 02:45:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA29583 for ipsec-policy-bks; Tue, 12 Dec 2000 22:36:25 -0800 (PST) Received: from web10503.mail.yahoo.com (web10503.mail.yahoo.com [216.136.130.153]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA29579 for ; Tue, 12 Dec 2000 22:36:24 -0800 (PST) Message-ID: <20001213063833.30930.qmail@web10503.mail.yahoo.com> Received: from [198.206.187.100] by web10503.mail.yahoo.com; Tue, 12 Dec 2000 22:38:33 PST Date: Tue, 12 Dec 2000 22:38:33 -0800 (PST) From: Mahadevan Iyer Subject: Re: gpsPolicyGroup class in qos info model To: John Strassner , Marcus Brunner , Ron Cohen Cc: policy@raleigh.ibm.com, ipsec-policy@vpnc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --- John Strassner wrote: > I think I understand in principle what you want to > do, but > just to be clear, is this a fair description: > > you want to be able to trim a tree of policy > information from consideration to be evaluated > efficiently; therefore, you want to add a > condition clause, defined by the admin, on a > high-level container, to do this > This is correct. > Assuming that this is correct, you still haven't > addressed > how you accommodate decision strategy and nested > rules. In > other words, are you proposing that you construct > these new > trimming rules INDEPENDENTLY of the actual structure > of the > rules below that containment point (e.g., taking > into > account their individual decision strategies, > priorities, > etc.)? How can you be sure that you are capturing > the > semantics and maintaining the correct execution > order by > your newly defined trimming rules? This is the responsibility of the policy administrator. The exact same responsibility exists when creating PolicyRuleInPolicyRule trees. Isn't this true ? Regards __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Wed Dec 13 18:26:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13738 for ; Wed, 13 Dec 2000 18:26:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23507 for ipsec-policy-bks; Wed, 13 Dec 2000 14:10:41 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23498 for ; Wed, 13 Dec 2000 14:10:38 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 14:12:51 -0800 Received: from maxwell.redcreek.com (MAXWELL [209.125.38.98]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YB6JPGXF; Wed, 13 Dec 2000 14:12:45 -0800 From: Ricky Charlet To: "\"ipsec-policy@vpnc.org, Ricky Charlet\"" <"ipsec-policy@vpnc.org, Ricky Charlet":@ns.secondary.com;> Message-Id: <5.0.0.25.0.20001213135252.00a14900@mail.redcreek.com> X-Sender: rcharlet@mail.redcreek.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 13 Dec 2000 14:12:34 -0800 Subject: IPSP policy model: contidtions and actions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Howdy, I think that the IPSP policy model puts conditions in the wrong place. SAConditions are contained by SARules which are derived from the Policy Core Information Model's Policy Rule. The problem I see here is that SAConditions are too specific to IPsec. I would rather see a model which sets up generic conditions to classify packets. Once a packet is classify by generalized conditions, then various actions (ie. ipsec, qos, nat,...) could be applied in a list of actions. Now, to do this would require tremendous coordination between all groups who might have an interest in packet classification. We know that right now, the qos and ipsec ways of modeling conditions or filters or are disjoint. So I am making a recommendation which will require a good bit of cross WG work and might perhaps move slowly. So what would be the benefit? If current trends hold, and each group who has an interest in classifying packets develops its own classification method, then we are very close to requiring that unnecessarily repetitive classification operations be done for each action which should be applied to the packet. It should be easy for us to envision examples where several actions (ipsec, qos, nat, firewall, ...) should be applied to the same packet. We should obviously strive to classify the packet once in implementations. Now, I said ' very close to requiring' . I guess that even if different groups do invent different models of how to do classification, that does not necessarily mean that implementations must actually do classifications differently. But it certainly would be a confusion situation. Ricky Charlet rcharlet@redcreek.com From owner-ipsec-policy@mail.vpnc.org Wed Dec 13 20:46:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16643 for ; Wed, 13 Dec 2000 20:46:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA29349 for ipsec-policy-bks; Wed, 13 Dec 2000 16:32:32 -0800 (PST) Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA29345 for ; Wed, 13 Dec 2000 16:32:30 -0800 (PST) Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 00:34:43 -0000 Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199AB68@mailmaestro.smartpipes.com> From: "Wang, Cliff" To: "'ipsec-policy@vpnc.org'" Subject: RE: IPSP policy model: contidtions and actions Date: Thu, 14 Dec 2000 00:34:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One of the working group items of this morning's policy framework meeting is to look into the filter issues to see whether they can be unified. From the implementation point of view, a unified approach is a MUST while at the different modeling levels, people can do what they think the best approaches. But an unified approach should be the goal, if it can be achieved. -----Original Message----- From: Ricky Charlet [mailto:rcharlet@redcreek.com] Sent: Wednesday, December 13, 2000 5:13 PM To: "ipsec-policy@vpnc.org, Ricky Charlet" Subject: IPSP policy model: contidtions and actions Howdy, I think that the IPSP policy model puts conditions in the wrong place. SAConditions are contained by SARules which are derived from the Policy Core Information Model's Policy Rule. The problem I see here is that SAConditions are too specific to IPsec. I would rather see a model which sets up generic conditions to classify packets. Once a packet is classify by generalized conditions, then various actions (ie. ipsec, qos, nat,...) could be applied in a list of actions. Now, to do this would require tremendous coordination between all groups who might have an interest in packet classification. We know that right now, the qos and ipsec ways of modeling conditions or filters or are disjoint. So I am making a recommendation which will require a good bit of cross WG work and might perhaps move slowly. So what would be the benefit? If current trends hold, and each group who has an interest in classifying packets develops its own classification method, then we are very close to requiring that unnecessarily repetitive classification operations be done for each action which should be applied to the packet. It should be easy for us to envision examples where several actions (ipsec, qos, nat, firewall, ...) should be applied to the same packet. We should obviously strive to classify the packet once in implementations. Now, I said ' very close to requiring' . I guess that even if different groups do invent different models of how to do classification, that does not necessarily mean that implementations must actually do classifications differently. But it certainly would be a confusion situation. Ricky Charlet rcharlet@redcreek.com From owner-ipsec-policy@mail.vpnc.org Wed Dec 13 21:16:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23066 for ; Wed, 13 Dec 2000 21:16:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00504 for ipsec-policy-bks; Wed, 13 Dec 2000 16:55:21 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00499 for ; Wed, 13 Dec 2000 16:55:20 -0800 (PST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA16390 for ; Wed, 13 Dec 2000 19:57:30 -0500 Received: from lmr (lig32-227-71-100.us.lig-dial.ibm.com [32.227.71.100]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA45502 for ; Wed, 13 Dec 2000 19:57:31 -0500 Message-ID: <000401c06568$9d1b7380$6447e320@raleigh.ibm.com> From: "Lee Rafalow" To: References: Subject: Re: Configuration model vs. DMTF model Date: Wed, 13 Dec 2000 10:04:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It's a subset. For example, the DMTF model includes security association objects as well as the objects necessary to specify the policies. Lee ----- Original Message ----- From: To: Sent: Tuesday, December 12, 2000 8:50 PM Subject: Configuration model vs. DMTF model > We know that the ipsp IPsec configuration model is based on that of DMTF. > But to be more specific, is the ipsp model the same, a superset or a subset > of that of DMTF? > > > Man Li > Nokia > 5 Wayside Road, Burlington, MA 01803 > man.m.li@nokia.com > phone 1-781-993-3923 > GSM 1-781-492-2850 From owner-ipsec-policy@mail.vpnc.org Wed Dec 13 23:12:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22108 for ; Wed, 13 Dec 2000 23:12:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA04215 for ipsec-policy-bks; Wed, 13 Dec 2000 19:03:21 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04211 for ; Wed, 13 Dec 2000 19:03:20 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id DAA04949 for ; Thu, 14 Dec 2000 03:07:10 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 14 Dec 2000 03:05:50 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 19:05:49 -0800 Message-ID: <794826DE8867D411BAB8009027AE9EB904DD78E1@FMSMSX38> From: "Jason, Jamie" To: ipsec-policy@vpnc.org Subject: RE: Configuration model vs. DMTF model Date: Wed, 13 Dec 2000 19:05:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In addition, it was decided after the WG session on Monday night that in the I-D a clear distinction between what parts of the policy represents settings that are required by the RFCs and what parts should be considered extensions will be made. Jamie > -----Original Message----- > From: Lee Rafalow [mailto:rafalow@raleigh.ibm.com] > Sent: Wednesday, December 13, 2000 7:04 AM > To: ipsec-policy@vpnc.org > Subject: Re: Configuration model vs. DMTF model > > > It's a subset. For example, the DMTF model includes security > association > objects as well as the objects necessary to specify the policies. > > Lee > > ----- Original Message ----- > From: > To: > Sent: Tuesday, December 12, 2000 8:50 PM > Subject: Configuration model vs. DMTF model > > > > We know that the ipsp IPsec configuration model is based on > that of DMTF. > > But to be more specific, is the ipsp model the same, a superset or a > subset > > of that of DMTF? > > > > > > Man Li > > Nokia > > 5 Wayside Road, Burlington, MA 01803 > > man.m.li@nokia.com > > phone 1-781-993-3923 > > GSM 1-781-492-2850 > > From owner-ipsec-policy@mail.vpnc.org Wed Dec 13 23:12:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22220 for ; Wed, 13 Dec 2000 23:12:38 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA04502 for ipsec-policy-bks; Wed, 13 Dec 2000 19:13:37 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04494 for ; Wed, 13 Dec 2000 19:13:36 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id DAA06604 for ; Thu, 14 Dec 2000 03:17:39 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 14 Dec 2000 03:16:19 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 19:16:17 -0800 Message-ID: <794826DE8867D411BAB8009027AE9EB904DD78E4@FMSMSX38> From: "Jason, Jamie" To: "'ipsec-policy@vpnc.org'" Subject: RE: IPSP policy model: contidtions and actions Date: Wed, 13 Dec 2000 19:16:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree that this is of paramount of importance. Since we will all be using at least the "core" filters (like IPs, ports, protocol), it makes sense to define it outside of each respective model. I had hoped that by including filter information in our model it would precipitate a discussion about what is domain specific and what is generic (I believe that in Oslo, I mentioned that we would eventually have to confront the issue of useful classes not already defined by PCIM - and filters would be one of them). Jamie > -----Original Message----- > From: Wang, Cliff [mailto:CWang@smartpipes.com] > Sent: Wednesday, December 13, 2000 4:35 PM > To: 'ipsec-policy@vpnc.org' > Subject: RE: IPSP policy model: contidtions and actions > > > One of the working group items of this morning's policy > framework meeting is > to look into the > filter issues to see whether they can be unified. From the > implementation > point of view, > a unified approach is a MUST while at the different modeling > levels, people > can do what they think > the best approaches. But an unified approach should be the > goal, if it can > be achieved. > > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: Wednesday, December 13, 2000 5:13 PM > To: "ipsec-policy@vpnc.org, Ricky Charlet" > Subject: IPSP policy model: contidtions and actions > > > Howdy, > > I think that the IPSP policy model puts conditions in the wrong > place. > SAConditions are contained by SARules which are derived from > the Policy > Core Information Model's Policy Rule. The problem I see here is that > SAConditions are too specific to IPsec. I would rather see a > model which > sets up generic conditions to classify packets. Once a packet > is classify > by generalized conditions, then various actions (ie. ipsec, > qos, nat,...) > could be applied in a list of actions. > > Now, to do this would require tremendous coordination > between all > groups > who might have an interest in packet classification. We know > that right > now, the qos and ipsec ways of modeling conditions or filters or are > disjoint. So I am making a recommendation which will require > a good bit of > cross WG work and might perhaps move slowly. > > So what would be the benefit? > > If current trends hold, and each group who has an interest in > classifying > packets develops its own classification method, then we are > very close to > requiring that unnecessarily repetitive classification > operations be done > for each action which should be applied to the packet. It > should be easy > for us to envision examples where several actions (ipsec, qos, nat, > firewall, ...) should be applied to the same packet. We > should obviously > strive to classify the packet once in implementations. > > Now, I said ' very close to requiring' . I guess that even if > different > groups do invent different models of how to do > classification, that does > not necessarily mean that implementations must actually do > classifications > differently. But it certainly would be a confusion situation. > > Ricky Charlet > rcharlet@redcreek.com > > From owner-ipsec-policy@mail.vpnc.org Thu Dec 14 02:57:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19241 for ; Thu, 14 Dec 2000 02:57:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA10080 for ipsec-policy-bks; Wed, 13 Dec 2000 22:33:36 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10076 for ; Wed, 13 Dec 2000 22:33:34 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA26696; Wed, 13 Dec 2000 22:35:56 -0800 (PST) Received: from jstrassnlap (sj-dial-4-23.cisco.com [171.68.181.152]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AEL03082; Wed, 13 Dec 2000 22:35:44 -0800 (PST) Message-ID: <026001c06598$96111470$98b544ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Mahadevan Iyer" , "John Strassner" , "Marcus Brunner" , "Ron Cohen" Cc: , References: <20001213063833.30930.qmail@web10503.mail.yahoo.com> Subject: Re: gpsPolicyGroup class in qos info model Date: Wed, 13 Dec 2000 11:34:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit No. The point of QPIM is to use gpsPolicyGroup and qosPolicyGroup to develop specific containers that are used to hold decision strategies, etc. that apply to objects in their scope. Telling the administrator to try and build a condition that captures the complex evaluation strategies that are contained in containers below it and hoping that a single condition can capture these complexities is, imho, not achievable. regards, John ----- Original Message ----- From: "Mahadevan Iyer" To: "John Strassner" ; "Marcus Brunner" ; "Ron Cohen" Cc: ; Sent: Tuesday, December 12, 2000 10:38 PM Subject: Re: gpsPolicyGroup class in qos info model > --- John Strassner wrote: > > I think I understand in principle what you want to > > do, but > > just to be clear, is this a fair description: > > > > you want to be able to trim a tree of policy > > information from consideration to be evaluated > > efficiently; therefore, you want to add a > > condition clause, defined by the admin, on a > > high-level container, to do this > > > > This is correct. > > > Assuming that this is correct, you still haven't > > addressed > > how you accommodate decision strategy and nested > > rules. In > > other words, are you proposing that you construct > > these new > > trimming rules INDEPENDENTLY of the actual structure > > of the > > rules below that containment point (e.g., taking > > into > > account their individual decision strategies, > > priorities, > > etc.)? How can you be sure that you are capturing > > the > > semantics and maintaining the correct execution > > order by > > your newly defined trimming rules? > > This is the responsibility of the policy > administrator. > The exact same responsibility exists when creating > PolicyRuleInPolicyRule trees. > Isn't this true ? > > Regards > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Thu Dec 14 13:24:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11398 for ; Thu, 14 Dec 2000 13:24:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29003 for ipsec-policy-bks; Thu, 14 Dec 2000 08:23:34 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28998 for ; Thu, 14 Dec 2000 08:23:32 -0800 (PST) Received: from bbn.com (TC091.BBN.COM [128.33.238.91]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA19026; Thu, 14 Dec 2000 11:26:01 -0500 (EST) Message-ID: <3A382269.A05B6B77@bbn.com> Date: Wed, 13 Dec 2000 20:29:13 -0500 From: "Luis A. Sanchez" Organization: BBN Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: John Strassner , Ron Cohen , Mahadevan Iyer , policy@raleigh.ibm.com, ipsec-policy@vpnc.org Subject: Re: gpsPolicyGroup class in qos info model References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de> <001201c06250$b7a73bf0$19ee130a@cisco.com> <3A354A3A.9CA4AA09@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, lets keep this discussion to the Policy Framework mailing list only. Luis Marcus Brunner wrote: > John, > > John Strassner wrote: > > > > PolicyRuleInPolicyRule is used to build sub-rules. We also > > allow for PolicyGroupInPolicyRule to build a sub-rule, with > > a policyGroup as a nested container. This capability is not > > in PCIM. > > > > Do you have an example, motivating why the rule in the rule is useful? > Is there a specific application of this modeling for QPIM? > I personally do not like having a rule playing so many different role. > The containment is dealt with in the policy group, why should a policy > rule also be a container for sub-rules? > > > As far as the context, sub-rules execute before their > > containing rules, as explained in the draft. > > > > Thank you, I have not found this in the draft. > > > I not only don't like conditions in gpsPolicyGroup, I don't > > think they work. > > > > I do not like the as well. > > Marcus > > > regards, > > John > > ----- Original Message ----- > > From: "Marcus Brunner" > > To: "Ron Cohen" > > Cc: "Mahadevan Iyer" ; > > ; > > Sent: Thursday, December 07, 2000 9:29 PM > > Subject: Re: gpsPolicyGroup class in qos info model > > > > > Ron, > > > > > > I agree with Mahadevan, that I do not like the > > policyRuleInPolicyRule method, > > > because > > > a) there are now two different grouping models, > > > b) it is unclear what happens to the context when the > > ruleInrule is executed > > > (full new start of execution engine or reuse the context) > > > c) I do not see the need for rulesInrules, what makes them > > different compared to > > > the grouping already available > > > > > > However, I do not agree to add a condition to the group. I > > think what is > > > available is enough. > > > > > > Marcus > > > > > > Quoting Ron Cohen : > > > > > > > Mahadevan, > > > > > > > > Can you provide more details why you prefer to change > > the gpsPolicyGroup > > > > than using the current policyRuleInPolicyRule method? > > > > > > > > Thanks > > > > Ron > > > > > > > > > > > > >I would like to suggest an update to the > > > > >gpsPolicyGroup class. > > > > >This also relates to the PolicyRuleInPolicyRule usage. > > > > > > > > > >I need to indicate that a group of policy rules should > > > > >be checked only if the traffic matches some aggregate > > > > >conditions. These aggregate conditions summarize the > > > > >conditions within the policy rules. > > > > > > > > > >I would like to specify the aggregate conditions at > > > > >the level of the gpsPolicyGroup. An alternative is to > > > > >use the PolicyRule + PolicyRuleInPolicyRule instead of > > > > >the gpsPolicyGroup. However I prefer to use the > > > > >gpsPolicyGroup. > > > > > > > > > >I would suggest adding an aggregate policy condition > > > > >to the gpsPolicyGroup. This condition would typically > > > > >be a gpsPolicyCompoundCondition. > > > > > > > > > > > > > > >Thanks > > > > > > > > > >__________________________________________________ > > > > >Do You Yahoo!? > > > > >Yahoo! Shopping - Thousands of Stores. Millions of > > Products. > > > > >http://shopping.yahoo.com/ > > > > > > > > > > > > > > > > > > > > Dr. Marcus Brunner > > > C&C Research Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.tik.ee.ethz.ch/~brunner > > > > > > Adenauerplatz 6 > > > D-69115 Heidelberg > > > Germany > > > > > > Phone: +49 (0)6221/ 9051129 > > > Fax: +49 (0)6221/ 9051155 From owner-ipsec-policy@mail.vpnc.org Mon Dec 18 02:42:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06204 for ; Mon, 18 Dec 2000 02:42:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA23547 for ipsec-policy-bks; Sun, 17 Dec 2000 22:26:37 -0800 (PST) Received: from mail.network.de (fw.web2cad.de [62.225.10.125]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA23542 for ; Sun, 17 Dec 2000 22:26:35 -0800 (PST) Received: from mailout.genius.de (notes.web2cad.de [10.2.0.3]) by mail.network.de (8.9.3/8.9.3) with SMTP id HAA32117 for ; Mon, 18 Dec 2000 07:29:37 +0100 Received: from web2cad.de ([10.10.11.213]) by mailout.genius.de (Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) with SMTP id 412569B9.0023F21A; Fri, 18 Dec 1970 07:34:37 +0100 Message-ID: <3A3DAECE.9F1C9ED0@web2cad.de> Date: Mon, 18 Dec 2000 07:29:34 +0100 From: vincent X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: [Fwd: unsubscribe] Content-Type: multipart/mixed; boundary="------------9960A55764C4C8C16070366E" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9960A55764C4C8C16070366E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------9960A55764C4C8C16070366E Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3A35CF6C.8357F9F6@web2cad.de> Date: Tue, 12 Dec 2000 08:10:36 +0100 From: vincent X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe ipsec-policy vincent@web2cad.de --------------9960A55764C4C8C16070366E-- From owner-ipsec-policy@mail.vpnc.org Mon Dec 18 09:18:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08849 for ; Mon, 18 Dec 2000 09:18:50 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA19813 for ipsec-policy-bks; Mon, 18 Dec 2000 04:59:32 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19807 for ; Mon, 18 Dec 2000 04:59:29 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA22502 for ; Mon, 18 Dec 2000 08:02:04 -0500 Received: from lmr (lig32-227-160-213.us.lig-dial.ibm.com [32.227.160.213]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA30212; Mon, 18 Dec 2000 08:02:01 -0500 Message-ID: <000401c068f2$7ae0c8a0$d5a0e320@raleigh.ibm.com> From: "Lee Rafalow" To: Cc: References: <5.0.0.25.0.20001213135252.00a14900@mail.redcreek.com> Subject: Re: IPSP policy model: contidtions and actions Date: Fri, 15 Dec 2000 18:24:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ricky, et al, At the Policy Framework meeting on Wednesday, a small team of a subset of the authors of the various drafts was formed to examine the differences between the various drafts and propose a convergence or an explanation for differences. Packet classification is certainly one of the areas and in a couple of ad hoc meetings we have already made some progress toward a common understanding of the some of the differences. First, as I mentioned in my talk, the background on the difference in packet classification has to do with the level of abstraction of the domain-level and device-level models. As I mentioned in my response to Jean last week, we haven't really discussed the relative merits of having the models close to their target implementations vs. having the models close to each other. Right now, the two device-level models both use filters (tho there are some differences there as well, imo, caused by the need for compromises among the QDDIM draft authors). The more general technique of using a grammar (aka "atoms") is appealing even though it can be more verbose than the filters approach. Right now, that grammar has only one operator defined, match, that compares a packet variable with a value or a set of values. In ICIM, we have a term of the condition specified by the AcceptCredentialsFrom association to CredentialManagementService(s) and their trust hierarchies. To do this with the atoms approach is not a simple extension. The typing of the association between the condition and variable would be extended to include objects, similarly for condition and value. Further, the use of an enumeration to specify the operation needs to be examined: perhaps there's a match method that is redefined in subclasses as needed. We're looking at these questions. Of course, a simpler approach to convergence here would be to use atoms as is for those things that can be specified with them and use other techniques (e.g., AcceptCredentialsFrom) as needed. Regardless, for IPsec to use the atoms technique, we would need to define subclasses of variable and value for things like ID payloads and credential fields. Thoughts? Lee ----- Original Message ----- From: "Ricky Charlet" To: ""ipsec-policy@vpnc.org, Ricky Charlet"" <"ipsec-policy@vpnc.org, Ricky Charlet":@ns.secondary.com;@rtpmail02.raleigh.ibm.com;> Sent: Wednesday, December 13, 2000 5:12 PM Subject: IPSP policy model: contidtions and actions > Howdy, > > I think that the IPSP policy model puts conditions in the wrong place. > SAConditions are contained by SARules which are derived from the Policy > Core Information Model's Policy Rule. The problem I see here is that > SAConditions are too specific to IPsec. I would rather see a model which > sets up generic conditions to classify packets. Once a packet is classify > by generalized conditions, then various actions (ie. ipsec, qos, nat,...) > could be applied in a list of actions. > > Now, to do this would require tremendous coordination between all groups > who might have an interest in packet classification. We know that right > now, the qos and ipsec ways of modeling conditions or filters or are > disjoint. So I am making a recommendation which will require a good bit of > cross WG work and might perhaps move slowly. > > So what would be the benefit? > > If current trends hold, and each group who has an interest in classifying > packets develops its own classification method, then we are very close to > requiring that unnecessarily repetitive classification operations be done > for each action which should be applied to the packet. It should be easy > for us to envision examples where several actions (ipsec, qos, nat, > firewall, ...) should be applied to the same packet. We should obviously > strive to classify the packet once in implementations. > > Now, I said ' very close to requiring' . I guess that even if different > groups do invent different models of how to do classification, that does > not necessarily mean that implementations must actually do classifications > differently. But it certainly would be a confusion situation. > > Ricky Charlet > rcharlet@redcreek.com > From owner-ipsec-policy@mail.vpnc.org Wed Dec 20 19:12:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20374 for ; Wed, 20 Dec 2000 19:12:50 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01500 for ipsec-policy-bks; Wed, 20 Dec 2000 14:54:10 -0800 (PST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01496 for ; Wed, 20 Dec 2000 14:54:09 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Wed, 20 Dec 2000 17:56:47 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id ZJM7N9XX; Wed, 20 Dec 2000 17:56:45 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6M1Z2; Wed, 20 Dec 2000 17:56:47 -0500 Message-ID: <3A4139F3.3D2FD1DE@americasm01.nt.com> Date: Wed, 20 Dec 2000 18:00:03 -0500 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy Subject: My presentation @ the WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have uploaded my presentation to: ftp://standards.nortelnetworks.com/IPSP/ipsp-Dec11-2000.ppt.gz regards Abdallah From owner-ipsec-policy@mail.vpnc.org Thu Dec 21 21:58:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09012 for ; Thu, 21 Dec 2000 21:58:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA02572 for ipsec-policy-bks; Thu, 21 Dec 2000 17:43:58 -0800 (PST) Received: from sem_mail.smkb.ac.il (skbb3.skb2.macam.ac.il [192.115.171.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA02566 for ; Thu, 21 Dec 2000 17:43:55 -0800 (PST) From: hj4hj6@yahoo.com Received: from 65kk9F90U (1Cust34.tnt21.lax3.da.uu.net [63.28.123.34]) by sem_mail.smkb.ac.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y4M7R6RF; Thu, 21 Dec 2000 23:37:05 +0200 DATE: 21 Dec 00 1:44:07 PM Message-ID: SUBJECT: Improve your stepfamily life Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf@mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. From owner-ipsec-policy@mail.vpnc.org Thu Dec 28 19:51:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20962 for ; Thu, 28 Dec 2000 19:51:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA05617 for ipsec-policy-bks; Thu, 28 Dec 2000 15:03:38 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05612 for ; Thu, 28 Dec 2000 15:03:36 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 15:07:01 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y97PMRKA; Thu, 28 Dec 2000 15:06:59 -0800 From: Ricky Charlet To: ".MailList - ipsec-policy" Message-ID: <3A4BBAA4.7ABAFBB7@redcreek.com> Date: Thu, 28 Dec 2000 15:11:48 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: comments on ICPM IPProtocolEndpoint Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, I have a question about IPProtocolEndpoints. From reading the DMTF white paper on IPsec Policy Model, it implies that IPProtocolEndpoints serve two roles. They are the interfaes which are IKE enabled, and they are the entities which will ultimatly be protected. I hope I'm just reading the model wrong. Because Secruity Gateways need to (of course) represent endpoints for protection which likely will not be the same as the Secruity Gatway's IKE enabled interface. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Thu Dec 28 20:11:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21042 for ; Thu, 28 Dec 2000 20:11:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA06223 for ipsec-policy-bks; Thu, 28 Dec 2000 15:30:14 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06219 for ; Thu, 28 Dec 2000 15:30:13 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 15:33:42 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y97PMRLH; Thu, 28 Dec 2000 15:33:27 -0800 From: Ricky Charlet To: ".MailList - ipsec-policy" Message-ID: <3A4BC0D9.E144ED3D@redcreek.com> Date: Thu, 28 Dec 2000 15:38:17 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: multi technology packet classification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, I have remarked on this list before that I think a gateway should only do packet classification once and then proceed to do what ever list of actions it needs to (IPsec, Qos/DiffServ, NAT, StatefulFirewall...). I said this because current trends in the IETF have IPsec and QOS developing their own independant packet classification systems for use with matching packets to their own particular actions. Now in thinking further about the problem of building a grand-unified-packet classification model (which would take just too much banter to make it ever happen) I've struk upon a simpler notion. CIM could define (may be they have, I don't read much Policy draft stuff) a generalized PolicyRule contains a packetClassifyingCondition matched to a list of actions. Maybe CIM could provide just a few simple packet classifiers but most importantly should provide the hooks in the model where particular technologies to derive further and more particular packetClassifyingConditions (and please, I don't mean to start any terminology wars. I'm sure there are 'right' words for the concepts I am talking about here, just fill them in). That way, when a packet gets classified, it wont automatically be captured into only an IPsec action only or a QOS action only because the PolicyRule which held the condition where the packet was matched now associates an action list with the condition. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Thu Dec 28 20:37:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21139 for ; Thu, 28 Dec 2000 20:37:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07056 for ipsec-policy-bks; Thu, 28 Dec 2000 16:10:37 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07052 for ; Thu, 28 Dec 2000 16:10:35 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 16:14:04 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y97PMRNA; Thu, 28 Dec 2000 16:13:58 -0800 From: Ricky Charlet To: ".MailList - ipsec-policy" Message-ID: <3A4BCA57.8870F370@redcreek.com> Date: Thu, 28 Dec 2000 16:18:47 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: comments on ICPM IPsecTunnelAction and their peers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, Identifying the peer for an IPsecTunnelAction seems overly complex to me. Why not just configure the IP address of the peer right in the IPsecTunnelAction as a parameter? What are the reasons behind the multiple table references to PeerIdentityTable and IkeIdentity and such? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903