From owner-ipsec-policy@mail.vpnc.org Fri Feb 1 09:26:55 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23468 for ; Fri, 1 Feb 2002 09:26:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11DlOX02443 for ipsec-policy-bks; Fri, 1 Feb 2002 05:47:24 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11DlJ302435 for ; Fri, 1 Feb 2002 05:47:19 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA77786; Fri, 1 Feb 2002 07:42:44 -0600 Received: from lrafalow (dyn9-27-16-134.raleigh.ibm.com [9.27.16.134]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with SMTP id g11DlIb213948; Fri, 1 Feb 2002 08:47:18 -0500 Message-ID: <002301c1ab26$e5678c00$86101b09@lrafalow> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: , , , References: <4.3.2.7.2.20020131183702.02832b18@brussels.cisco.com> <3C59CBAB.D8995CE3@sonicwall.com> Subject: IpHeadersFilter (Re: Address ranges) Date: Fri, 1 Feb 2002 08:46:48 -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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes, this is an oversight. We need to fix IpHeadersFilter to support ranges. Good catch Casey! The current class definition is: NAME IpHeadersFilter DESCRIPTION A class representing an entire IP header filter, or any subset of one. DERIVED FROM FilterEntryBase TYPE Concrete PROPERTIES HdrIpVersion, HdrSrcAddress, HdrSrcMask, HdrDestAddress, HdrDestMask, HdrProtocolID, HdrSrcPortStart, HdrSrcPortEnd, HdrDestPortStart, HdrDestPortEnd, HdrDSCP, HdrFlowLabel I suggest the following changes. Add HdrSrcAddressEndOfRange and HdrDestAddressEndOfRange. When non-null, the start of range value is in the corresponding HdrXxxxAddress property. When null, the corresponding HdrXxxxAddress property is interpreted as today as a single address filter that may have a mask. And the HdrXxxxAddressEndOfRange properties MUST be null when their corresponding HdrXxxxMask property is non-null and vice-versa (i.e., no mask on ranges). For consistency, I'd also have us rename the HdrXxxxPortStart properties to drop the "Start" and rename the HdrXxxxPortEnd properties to "EndOfRange" and change the semantics so that the EndOfRange properties are null when the filter is not specifying a port range instead of the current both values are the same definition. Comments? ----- Original Message ----- From: "Scott G. Kelly" To: "Eric Vyncke" Cc: "Casey Carr" ; "IPSec Policy WG" Sent: Thursday, January 31, 2002 5:56 PM Subject: Re: Address ranges > > Eric Vyncke wrote: > > > > At 11:15 30/01/2002 -0500, Casey Carr wrote: > > > > >Could someone please give me some guidance on how the IPSec policy model > > >addresses (no pun intended) filtering on a range of IPv4 addresses? > > > > > >The IPSec library we are using supports defining filters based on address > > >ranges but it doesn't appear to me that the model supports this. I've > > > > This is correct as ICPM tried to re-use as much as possible of PCIM/PCIMe > > which does not understand IP address ranges > > > > -eric > > Since RFC2401 mandates support for address ranges, shouldn't the policy > model support them? > > Scott > From owner-ipsec-policy@mail.vpnc.org Fri Feb 1 10:18:31 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26470 for ; Fri, 1 Feb 2002 10:18:30 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11EfZq06152 for ipsec-policy-bks; Fri, 1 Feb 2002 06:41:35 -0800 (PST) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11EfY306148 for ; Fri, 1 Feb 2002 06:41:34 -0800 (PST) Received: from casey ([66.26.63.121]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Fri, 1 Feb 2002 09:40:06 -0500 From: "Casey Carr" To: "Lee Rafalow" , , , , Subject: RE: IpHeadersFilter (Re: Address ranges) Date: Fri, 1 Feb 2002 09:39:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <002301c1ab26$e5678c00$86101b09@lrafalow> Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Works for me. Casey -----Original Message----- From: owner-ipsec-policy@mail.vpnc.org [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Lee Rafalow Sent: Friday, February 01, 2002 8:47 AM To: policy@ietf.org; wg-network@dmtf.org; wg-policy@dmtf.org; ipsec-policy@vpnc.org Subject: IpHeadersFilter (Re: Address ranges) Yes, this is an oversight. We need to fix IpHeadersFilter to support ranges. Good catch Casey! The current class definition is: NAME IpHeadersFilter DESCRIPTION A class representing an entire IP header filter, or any subset of one. DERIVED FROM FilterEntryBase TYPE Concrete PROPERTIES HdrIpVersion, HdrSrcAddress, HdrSrcMask, HdrDestAddress, HdrDestMask, HdrProtocolID, HdrSrcPortStart, HdrSrcPortEnd, HdrDestPortStart, HdrDestPortEnd, HdrDSCP, HdrFlowLabel I suggest the following changes. Add HdrSrcAddressEndOfRange and HdrDestAddressEndOfRange. When non-null, the start of range value is in the corresponding HdrXxxxAddress property. When null, the corresponding HdrXxxxAddress property is interpreted as today as a single address filter that may have a mask. And the HdrXxxxAddressEndOfRange properties MUST be null when their corresponding HdrXxxxMask property is non-null and vice-versa (i.e., no mask on ranges). For consistency, I'd also have us rename the HdrXxxxPortStart properties to drop the "Start" and rename the HdrXxxxPortEnd properties to "EndOfRange" and change the semantics so that the EndOfRange properties are null when the filter is not specifying a port range instead of the current both values are the same definition. Comments? ----- Original Message ----- From: "Scott G. Kelly" To: "Eric Vyncke" Cc: "Casey Carr" ; "IPSec Policy WG" Sent: Thursday, January 31, 2002 5:56 PM Subject: Re: Address ranges > > Eric Vyncke wrote: > > > > At 11:15 30/01/2002 -0500, Casey Carr wrote: > > > > >Could someone please give me some guidance on how the IPSec policy model > > >addresses (no pun intended) filtering on a range of IPv4 addresses? > > > > > >The IPSec library we are using supports defining filters based on address > > >ranges but it doesn't appear to me that the model supports this. I've > > > > This is correct as ICPM tried to re-use as much as possible of PCIM/PCIMe > > which does not understand IP address ranges > > > > -eric > > Since RFC2401 mandates support for address ranges, shouldn't the policy > model support them? > > Scott > From owner-ipsec-policy@mail.vpnc.org Fri Feb 1 15:04:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10606 for ; Fri, 1 Feb 2002 15:04:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g11JWj514384 for ipsec-policy-bks; Fri, 1 Feb 2002 11:32:45 -0800 (PST) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11JWi314380 for ; Fri, 1 Feb 2002 11:32:44 -0800 (PST) Received: from casey ([66.26.63.121]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Fri, 1 Feb 2002 14:32:40 -0500 From: "Casey Carr" To: "IPSec Policy WG" Subject: SA Rules Date: Fri, 1 Feb 2002 14:32:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit After implementing the IPSec policy model I have some a small gripe. First I would like to thank those who put the time and effort into this model. It has proved very useful for our IPSec gateway policy manager implementation. The issue I have is with RuleForIPSecNegotiation and RuleForIKENegotiation. Can someone explain to why there is not a direct association between an SARule and IPSecPolicyGroup? This association would probably have the name SARuleInPolicyGroup. Wouldn't it be cleaner to be able to prioritize a single collection of rules instead of having to prioritize on set of IKERule objects and one set of IPSecRule objects? Since these associations each have their own priorities, I have to deal with the possibility that an IKERule and an IPSecRule in the same policy group can have the same priority. This complexity seems to been eliminated from the rest of the model. For instance there is not an association IKEActionInIKERule or IPSecProposalInIPSecAction. If there is not a definitive reason for this (IMHO) inconsistency, I would argue that the model should be changed to replace the RuleForIPSecNegotiation and RuleForIKENegotiation with a single association SARuleInPolicyGroup. BTW, despite my concerns our implementation remains true to the current model as defined in draft-ietf-ipsp-config-policy-model-04.txt. Casey From owner-ipsec-policy@mail.vpnc.org Tue Feb 5 17:16:54 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21410 for ; Tue, 5 Feb 2002 17:16:53 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15LLFB08949 for ipsec-policy-bks; Tue, 5 Feb 2002 13:21:15 -0800 (PST) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15LLE308943 for ; Tue, 5 Feb 2002 13:21:14 -0800 (PST) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id VAA00756 for ; Tue, 5 Feb 2002 21:21:16 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002020513234829980 ; Tue, 05 Feb 2002 13:23:48 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1116F9XV>; Tue, 5 Feb 2002 13:21:16 -0800 Message-ID: <86DB568235A8D511ABAC0002A5072CA501E9236D@orsmsx120.jf.intel.com> From: "Jason, Jamie" To: "'Casey Carr'" , IPSec Policy WG Subject: RE: SA Rules Date: Tue, 5 Feb 2002 13:21:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Casey, I think that the aggregations you point out are vestiges of the original model. There is no reason why these two cannot be combined into one aggregation. Good catch. Jamie > -----Original Message----- > From: Casey Carr [mailto:kcarr@nc.rr.com] > Sent: Friday, February 01, 2002 11:32 AM > To: IPSec Policy WG > Subject: SA Rules > > > > After implementing the IPSec policy model I have some a small > gripe. First I would like to thank those who put the time > and effort into this model. It has proved very useful for > our IPSec gateway policy manager implementation. > > The issue I have is with RuleForIPSecNegotiation and > RuleForIKENegotiation. Can someone explain to why there is > not a direct association between an SARule and > IPSecPolicyGroup? This association would probably have the > name SARuleInPolicyGroup. > > Wouldn't it be cleaner to be able to prioritize a single > collection of rules instead of having to prioritize on set of > IKERule objects and one set of IPSecRule objects? Since > these associations each have their own priorities, I have to > deal with the possibility that an IKERule and an IPSecRule in > the same policy group can have the same priority. > > This complexity seems to been eliminated from the rest of the > model. For instance there is not an association > IKEActionInIKERule or IPSecProposalInIPSecAction. > > If there is not a definitive reason for this (IMHO) > inconsistency, I would argue that the model should be changed > to replace the RuleForIPSecNegotiation and > RuleForIKENegotiation with a single association SARuleInPolicyGroup. > > BTW, despite my concerns our implementation remains true to > the current model as defined in > draft-ietf-ipsp-config-policy-model-04.txt. > > Casey > From owner-ipsec-policy@mail.vpnc.org Wed Feb 6 09:05:06 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20194 for ; Wed, 6 Feb 2002 09:05:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16D5XW25647 for ipsec-policy-bks; Wed, 6 Feb 2002 05:05:33 -0800 (PST) Received: from mail7.nc.rr.com ([24.93.67.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16D5V325643 for ; Wed, 6 Feb 2002 05:05:32 -0800 (PST) Received: from casey ([66.26.63.121]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 6 Feb 2002 08:03:43 -0500 From: "Casey Carr" To: "Jason, Jamie" , "IPSec Policy WG" Subject: RE: SA Rules Date: Wed, 6 Feb 2002 08:02:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <86DB568235A8D511ABAC0002A5072CA501E9236D@orsmsx120.jf.intel.com> Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Will there be another rev to the document prior to last call? -----Original Message----- From: owner-ipsec-policy@mail.vpnc.org [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Jason, Jamie Sent: Tuesday, February 05, 2002 4:21 PM To: 'Casey Carr'; IPSec Policy WG Subject: RE: SA Rules Casey, I think that the aggregations you point out are vestiges of the original model. There is no reason why these two cannot be combined into one aggregation. Good catch. Jamie > -----Original Message----- > From: Casey Carr [mailto:kcarr@nc.rr.com] > Sent: Friday, February 01, 2002 11:32 AM > To: IPSec Policy WG > Subject: SA Rules > > > > After implementing the IPSec policy model I have some a small > gripe. First I would like to thank those who put the time > and effort into this model. It has proved very useful for > our IPSec gateway policy manager implementation. > > The issue I have is with RuleForIPSecNegotiation and > RuleForIKENegotiation. Can someone explain to why there is > not a direct association between an SARule and > IPSecPolicyGroup? This association would probably have the > name SARuleInPolicyGroup. > > Wouldn't it be cleaner to be able to prioritize a single > collection of rules instead of having to prioritize on set of > IKERule objects and one set of IPSecRule objects? Since > these associations each have their own priorities, I have to > deal with the possibility that an IKERule and an IPSecRule in > the same policy group can have the same priority. > > This complexity seems to been eliminated from the rest of the > model. For instance there is not an association > IKEActionInIKERule or IPSecProposalInIPSecAction. > > If there is not a definitive reason for this (IMHO) > inconsistency, I would argue that the model should be changed > to replace the RuleForIPSecNegotiation and > RuleForIKENegotiation with a single association SARuleInPolicyGroup. > > BTW, despite my concerns our implementation remains true to > the current model as defined in > draft-ietf-ipsp-config-policy-model-04.txt. > > Casey > From owner-ipsec-policy@mail.vpnc.org Wed Feb 6 16:14:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02257 for ; Wed, 6 Feb 2002 16:14:02 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g16KQLY24410 for ipsec-policy-bks; Wed, 6 Feb 2002 12:26:21 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16KQK324405 for ; Wed, 6 Feb 2002 12:26:20 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA28559; Wed, 6 Feb 2002 21:26:03 +0100 (MET) Message-Id: <4.3.2.7.2.20020206212531.00ba6d90@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Feb 2002 21:26:00 +0100 To: "Casey Carr" From: Eric Vyncke Subject: RE: SA Rules Cc: "Jason, Jamie" , "IPSec Policy WG" In-Reply-To: References: <86DB568235A8D511ABAC0002A5072CA501E9236D@orsmsx120.jf.intel.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: Yes, the -05 is mostly complete (basically nothing completely new, just minor fixed + clarifications) -eric At 08:02 6/02/2002 -0500, Casey Carr wrote: >Will there be another rev to the document prior to last call? > >-----Original Message----- >From: owner-ipsec-policy@mail.vpnc.org >[mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Jason, Jamie >Sent: Tuesday, February 05, 2002 4:21 PM >To: 'Casey Carr'; IPSec Policy WG >Subject: RE: SA Rules > > > >Casey, > >I think that the aggregations you point out are vestiges of the original >model. There is no reason why these two cannot be combined into one >aggregation. > >Good catch. > >Jamie > > > -----Original Message----- > > From: Casey Carr [mailto:kcarr@nc.rr.com] > > Sent: Friday, February 01, 2002 11:32 AM > > To: IPSec Policy WG > > Subject: SA Rules > > > > > > > > After implementing the IPSec policy model I have some a small > > gripe. First I would like to thank those who put the time > > and effort into this model. It has proved very useful for > > our IPSec gateway policy manager implementation. > > > > The issue I have is with RuleForIPSecNegotiation and > > RuleForIKENegotiation. Can someone explain to why there is > > not a direct association between an SARule and > > IPSecPolicyGroup? This association would probably have the > > name SARuleInPolicyGroup. > > > > Wouldn't it be cleaner to be able to prioritize a single > > collection of rules instead of having to prioritize on set of > > IKERule objects and one set of IPSecRule objects? Since > > these associations each have their own priorities, I have to > > deal with the possibility that an IKERule and an IPSecRule in > > the same policy group can have the same priority. > > > > This complexity seems to been eliminated from the rest of the > > model. For instance there is not an association > > IKEActionInIKERule or IPSecProposalInIPSecAction. > > > > If there is not a definitive reason for this (IMHO) > > inconsistency, I would argue that the model should be changed > > to replace the RuleForIPSecNegotiation and > > RuleForIKENegotiation with a single association SARuleInPolicyGroup. > > > > BTW, despite my concerns our implementation remains true to > > the current model as defined in > > draft-ietf-ipsp-config-policy-model-04.txt. > > > > Casey > > From owner-ipsec-policy@mail.vpnc.org Wed Feb 6 16:22:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02542 for ; Wed, 6 Feb 2002 16:22:07 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16KtsE27303 for ipsec-policy-bks; Wed, 6 Feb 2002 12:55:54 -0800 (PST) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Ktr327299 for ; Wed, 6 Feb 2002 12:55:53 -0800 (PST) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 6 Feb 2002 15:55:13 -0500 From: "Casey Carr" To: "Eric Vyncke" Cc: "Jason, Jamie" , "IPSec Policy WG" Subject: RE: SA Rules Date: Wed, 6 Feb 2002 15:54:28 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <4.3.2.7.2.20020206214316.027b5788@brussels.cisco.com> Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thank you. -----Original Message----- From: Eric Vyncke [mailto:evyncke@cisco.com] Sent: Wednesday, February 06, 2002 3:44 PM To: Casey Carr Cc: Jason, Jamie; IPSec Policy WG Subject: RE: SA Rules At 15:35 6/02/2002 -0500, Casey Carr wrote: >Eric, > >1) Do you agree with the Jamie's response to the changes I've requested >concerning the associations between policy group and SA rule? Will this >change be incorporated in the -05 document? Yes, all authors agreed on your proposal (thanks for catching it) >2) There was agreement last week that the IPSec policy model does not >support address ranges in for filter entries. Will there be a fix to the >model to support this feature? Actually, the IPHeadersFilter class is coming from PCIMe and as far as I know PCIMe is currently extending this class. -eric >Casey > >-----Original Message----- >From: Eric Vyncke [mailto:evyncke@cisco.com] >Sent: Wednesday, February 06, 2002 3:26 PM >To: Casey Carr >Cc: Jason, Jamie; IPSec Policy WG >Subject: RE: SA Rules > > >Yes, the -05 is mostly complete (basically nothing completely new, just >minor fixed + clarifications) > >-eric > >At 08:02 6/02/2002 -0500, Casey Carr wrote: > > >Will there be another rev to the document prior to last call? > > > >-----Original Message----- > >From: owner-ipsec-policy@mail.vpnc.org > >[mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Jason, Jamie > >Sent: Tuesday, February 05, 2002 4:21 PM > >To: 'Casey Carr'; IPSec Policy WG > >Subject: RE: SA Rules > > > > > > > >Casey, > > > >I think that the aggregations you point out are vestiges of the original > >model. There is no reason why these two cannot be combined into one > >aggregation. > > > >Good catch. > > > >Jamie > > > > > -----Original Message----- > > > From: Casey Carr [mailto:kcarr@nc.rr.com] > > > Sent: Friday, February 01, 2002 11:32 AM > > > To: IPSec Policy WG > > > Subject: SA Rules > > > > > > > > > > > > After implementing the IPSec policy model I have some a small > > > gripe. First I would like to thank those who put the time > > > and effort into this model. It has proved very useful for > > > our IPSec gateway policy manager implementation. > > > > > > The issue I have is with RuleForIPSecNegotiation and > > > RuleForIKENegotiation. Can someone explain to why there is > > > not a direct association between an SARule and > > > IPSecPolicyGroup? This association would probably have the > > > name SARuleInPolicyGroup. > > > > > > Wouldn't it be cleaner to be able to prioritize a single > > > collection of rules instead of having to prioritize on set of > > > IKERule objects and one set of IPSecRule objects? Since > > > these associations each have their own priorities, I have to > > > deal with the possibility that an IKERule and an IPSecRule in > > > the same policy group can have the same priority. > > > > > > This complexity seems to been eliminated from the rest of the > > > model. For instance there is not an association > > > IKEActionInIKERule or IPSecProposalInIPSecAction. > > > > > > If there is not a definitive reason for this (IMHO) > > > inconsistency, I would argue that the model should be changed > > > to replace the RuleForIPSecNegotiation and > > > RuleForIKENegotiation with a single association SARuleInPolicyGroup. > > > > > > BTW, despite my concerns our implementation remains true to > > > the current model as defined in > > > draft-ietf-ipsp-config-policy-model-04.txt. > > > > > > Casey > > > From owner-ipsec-policy@mail.vpnc.org Wed Feb 6 16:24:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02622 for ; Wed, 6 Feb 2002 16:24:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16KaOY25736 for ipsec-policy-bks; Wed, 6 Feb 2002 12:36:24 -0800 (PST) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16KaM325724 for ; Wed, 6 Feb 2002 12:36:22 -0800 (PST) Received: from casey ([66.26.63.121]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 6 Feb 2002 15:35:42 -0500 From: "Casey Carr" To: "Eric Vyncke" Cc: "Jason, Jamie" , "IPSec Policy WG" Subject: RE: SA Rules Date: Wed, 6 Feb 2002 15:35:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <4.3.2.7.2.20020206212531.00ba6d90@brussels.cisco.com> Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric, 1) Do you agree with the Jamie's response to the changes I've requested concerning the associations between policy group and SA rule? Will this change be incorporated in the -05 document? 2) There was agreement last week that the IPSec policy model does not support address ranges in for filter entries. Will there be a fix to the model to support this feature? Casey -----Original Message----- From: Eric Vyncke [mailto:evyncke@cisco.com] Sent: Wednesday, February 06, 2002 3:26 PM To: Casey Carr Cc: Jason, Jamie; IPSec Policy WG Subject: RE: SA Rules Yes, the -05 is mostly complete (basically nothing completely new, just minor fixed + clarifications) -eric At 08:02 6/02/2002 -0500, Casey Carr wrote: >Will there be another rev to the document prior to last call? > >-----Original Message----- >From: owner-ipsec-policy@mail.vpnc.org >[mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Jason, Jamie >Sent: Tuesday, February 05, 2002 4:21 PM >To: 'Casey Carr'; IPSec Policy WG >Subject: RE: SA Rules > > > >Casey, > >I think that the aggregations you point out are vestiges of the original >model. There is no reason why these two cannot be combined into one >aggregation. > >Good catch. > >Jamie > > > -----Original Message----- > > From: Casey Carr [mailto:kcarr@nc.rr.com] > > Sent: Friday, February 01, 2002 11:32 AM > > To: IPSec Policy WG > > Subject: SA Rules > > > > > > > > After implementing the IPSec policy model I have some a small > > gripe. First I would like to thank those who put the time > > and effort into this model. It has proved very useful for > > our IPSec gateway policy manager implementation. > > > > The issue I have is with RuleForIPSecNegotiation and > > RuleForIKENegotiation. Can someone explain to why there is > > not a direct association between an SARule and > > IPSecPolicyGroup? This association would probably have the > > name SARuleInPolicyGroup. > > > > Wouldn't it be cleaner to be able to prioritize a single > > collection of rules instead of having to prioritize on set of > > IKERule objects and one set of IPSecRule objects? Since > > these associations each have their own priorities, I have to > > deal with the possibility that an IKERule and an IPSecRule in > > the same policy group can have the same priority. > > > > This complexity seems to been eliminated from the rest of the > > model. For instance there is not an association > > IKEActionInIKERule or IPSecProposalInIPSecAction. > > > > If there is not a definitive reason for this (IMHO) > > inconsistency, I would argue that the model should be changed > > to replace the RuleForIPSecNegotiation and > > RuleForIKENegotiation with a single association SARuleInPolicyGroup. > > > > BTW, despite my concerns our implementation remains true to > > the current model as defined in > > draft-ietf-ipsp-config-policy-model-04.txt. > > > > Casey > > From owner-ipsec-policy@mail.vpnc.org Wed Feb 6 16:35:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03018 for ; Wed, 6 Feb 2002 16:35:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g16KigP26866 for ipsec-policy-bks; Wed, 6 Feb 2002 12:44:42 -0800 (PST) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g16Kie326862 for ; Wed, 6 Feb 2002 12:44:40 -0800 (PST) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA00400; Wed, 6 Feb 2002 21:44:28 +0100 (MET) Message-Id: <4.3.2.7.2.20020206214316.027b5788@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Feb 2002 21:44:12 +0100 To: "Casey Carr" From: Eric Vyncke Subject: RE: SA Rules Cc: "Jason, Jamie" , "IPSec Policy WG" In-Reply-To: References: <4.3.2.7.2.20020206212531.00ba6d90@brussels.cisco.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: At 15:35 6/02/2002 -0500, Casey Carr wrote: >Eric, > >1) Do you agree with the Jamie's response to the changes I've requested >concerning the associations between policy group and SA rule? Will this >change be incorporated in the -05 document? Yes, all authors agreed on your proposal (thanks for catching it) >2) There was agreement last week that the IPSec policy model does not >support address ranges in for filter entries. Will there be a fix to the >model to support this feature? Actually, the IPHeadersFilter class is coming from PCIMe and as far as I know PCIMe is currently extending this class. -eric >Casey > >-----Original Message----- >From: Eric Vyncke [mailto:evyncke@cisco.com] >Sent: Wednesday, February 06, 2002 3:26 PM >To: Casey Carr >Cc: Jason, Jamie; IPSec Policy WG >Subject: RE: SA Rules > > >Yes, the -05 is mostly complete (basically nothing completely new, just >minor fixed + clarifications) > >-eric > >At 08:02 6/02/2002 -0500, Casey Carr wrote: > > >Will there be another rev to the document prior to last call? > > > >-----Original Message----- > >From: owner-ipsec-policy@mail.vpnc.org > >[mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Jason, Jamie > >Sent: Tuesday, February 05, 2002 4:21 PM > >To: 'Casey Carr'; IPSec Policy WG > >Subject: RE: SA Rules > > > > > > > >Casey, > > > >I think that the aggregations you point out are vestiges of the original > >model. There is no reason why these two cannot be combined into one > >aggregation. > > > >Good catch. > > > >Jamie > > > > > -----Original Message----- > > > From: Casey Carr [mailto:kcarr@nc.rr.com] > > > Sent: Friday, February 01, 2002 11:32 AM > > > To: IPSec Policy WG > > > Subject: SA Rules > > > > > > > > > > > > After implementing the IPSec policy model I have some a small > > > gripe. First I would like to thank those who put the time > > > and effort into this model. It has proved very useful for > > > our IPSec gateway policy manager implementation. > > > > > > The issue I have is with RuleForIPSecNegotiation and > > > RuleForIKENegotiation. Can someone explain to why there is > > > not a direct association between an SARule and > > > IPSecPolicyGroup? This association would probably have the > > > name SARuleInPolicyGroup. > > > > > > Wouldn't it be cleaner to be able to prioritize a single > > > collection of rules instead of having to prioritize on set of > > > IKERule objects and one set of IPSecRule objects? Since > > > these associations each have their own priorities, I have to > > > deal with the possibility that an IKERule and an IPSecRule in > > > the same policy group can have the same priority. > > > > > > This complexity seems to been eliminated from the rest of the > > > model. For instance there is not an association > > > IKEActionInIKERule or IPSecProposalInIPSecAction. > > > > > > If there is not a definitive reason for this (IMHO) > > > inconsistency, I would argue that the model should be changed > > > to replace the RuleForIPSecNegotiation and > > > RuleForIKENegotiation with a single association SARuleInPolicyGroup. > > > > > > BTW, despite my concerns our implementation remains true to > > > the current model as defined in > > > draft-ietf-ipsp-config-policy-model-04.txt. > > > > > > Casey > > > From owner-ipsec-policy@mail.vpnc.org Fri Feb 8 09:31:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07905 for ; Fri, 8 Feb 2002 09:31:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18E6am06059 for ipsec-policy-bks; Fri, 8 Feb 2002 06:06:36 -0800 (PST) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18E6Y306055 for ; Fri, 8 Feb 2002 06:06:35 -0800 (PST) Received: from casey ([66.26.63.121]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Fri, 8 Feb 2002 09:06:22 -0500 From: "Casey Carr" To: "IPSec Policy WG" Subject: Type-o Date: Fri, 8 Feb 2002 09:05:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Since there is going to being another version of the draft it seems appropriate to point out a type-o. draft-ietf-ipsp-config-policy-model-04.txt defines IPHeaderFilter and draft-ietf-policy-pcim-ext-06.txt defines it as IpHeadersFilter. It would be good if we can could change the ipsp definition to IpHeadersFilter. Casey From owner-ipsec-policy@mail.vpnc.org Fri Feb 8 13:36:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18834 for ; Fri, 8 Feb 2002 13:36:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g18IDjk15038 for ipsec-policy-bks; Fri, 8 Feb 2002 10:13:45 -0800 (PST) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18IDi315034 for ; Fri, 8 Feb 2002 10:13:44 -0800 (PST) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id SAA03378 for ; Fri, 8 Feb 2002 18:13:45 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002020810143519565 ; Fri, 08 Feb 2002 10:14:35 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id <13HSBVNW>; Fri, 8 Feb 2002 10:13:45 -0800 Message-ID: <86DB568235A8D511ABAC0002A5072CA501E92388@orsmsx120.jf.intel.com> From: "Jason, Jamie" To: "'Casey Carr'" , IPSec Policy WG Subject: RE: Type-o Date: Fri, 8 Feb 2002 10:13:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That will be taken care of. Thanks. Jamie > -----Original Message----- > From: Casey Carr [mailto:kcarr@nc.rr.com] > Sent: Friday, February 08, 2002 6:06 AM > To: IPSec Policy WG > Subject: Type-o > > > > Since there is going to being another version of the draft it seems > appropriate to point out a type-o. > > draft-ietf-ipsp-config-policy-model-04.txt defines IPHeaderFilter and > draft-ietf-policy-pcim-ext-06.txt defines it as IpHeadersFilter. > > It would be good if we can could change the ipsp definition to > IpHeadersFilter. > > Casey >