From owner-ipsec-policy@mail.vpnc.org Tue Apr 3 14:19:35 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11605 for ; Tue, 3 Apr 2001 14:19:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA18256 for ipsec-policy-bks; Tue, 3 Apr 2001 10:06:40 -0700 (PDT) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA18251 for ; Tue, 3 Apr 2001 10:06:38 -0700 (PDT) Received: from localhost (itesec.hsc.fr [192.70.106.33]) by itesec.hsc.fr (Postfix) with SMTP id CDC2810EE3; Tue, 3 Apr 2001 19:05:25 +0200 (CEST) From: Ghislaine Labouret To: Eric Vyncke Cc: ipsec-policy@vpnc.org Subject: Re: granularity property in Common Information Model Date: Tue, 03 Apr 2001 19:04:17 +0200 Organization: HSC (Herve Schauer Consultants) References: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> <3AB78753.1E346DAE@redcreek.com> <4.3.2.7.2.20010327161340.01d40fe8@brussels.cisco.com> In-Reply-To: <4.3.2.7.2.20010327161340.01d40fe8@brussels.cisco.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <20010403170525.CDC2810EE3@itesec.hsc.fr> Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id KAA18256 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA11605 On Tue, 27 Mar 2001 16:31:27 +0100, Eric Vyncke wrote: > Let's do it with an example, the 'triggering' packet is from 192.168.1.1 > TCP/1024 to 10.1.1.1 TCP/80, the SACondition filter is any source IP from > 192.168.1.* to 10.*.*.*, then depending on the granularity, IKE should > negotiate phase 2 SA for the following phase 2 ID: > - subnet -> <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0> > for all protocols using ID_IPV4_ADDR_SUBNET format; > - host -> <192.168.1.1,protocol=0,port=0> & <10.1.1.1,,protocol=0,port=0> > for all protocols using ID_IPV4_ADDR format; > - protocol -> <192.168.1.1,protocol=6,port=0> & > <10.1.1.1,protocol=6,port=0> for all TCP ports using ID_IPV4_ADDR format; > - port -> <192.168.1.1,protocol=6,port=1024> & > <10.1.1.1,protocol=6,port=80) only for the triggering TCP flow using > ID_IPV4_ADDR format; What about an example situation where the SACondition filter still has source = 192.168.1.*, but destination = 10.*.*.* / TCP / 80: which of the following proxy IDs would be used for a subnet granularity? 1/ <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=6,port=80> ^ ^^ Approach in which the IPsec device negotiates a SA bundle per protocol/port (approach used by Cisco routers for example) 2/ <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0> ^ ^ Approach in which the IPsec device negotiates only one "large tunnel" for all protocols (and subsequently uses filtering to limit traffic allowed to use this tunnel) (approach used by Check Point VPN-1 for example) I personally believe that it would be nice to have a model that can accommodate both approaches, as it would enable wider devices support. Sincerely, -- Ghislaine Labouret, Network security consultant Hervé Schauer Consultants (HSC) - http://www.hsc.fr/ Phone (+33)-141-409-700 - Fax (+33)-141-409-709 From owner-ipsec-policy@mail.vpnc.org Thu Apr 5 07:45:22 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28310 for ; Thu, 5 Apr 2001 07:45:21 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id DAA02898 for ipsec-policy-bks; Thu, 5 Apr 2001 03:40:58 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA02884 for ; Thu, 5 Apr 2001 03:40:57 -0700 (PDT) Message-Id: <200104051040.DAA02884@above.proper.com> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:02:19 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:59:50 +0200 Content-Transfer-Encoding: 8bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From owner-ipsec-policy@mail.vpnc.org Thu Apr 5 14:00:55 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09839 for ; Thu, 5 Apr 2001 14:00:55 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA00135 for ipsec-policy-bks; Thu, 5 Apr 2001 09:43:57 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA00131 for ; Thu, 5 Apr 2001 09:43:55 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Apr 2001 09:43:35 -0700 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.2653.13) id H30M34NB; Thu, 5 Apr 2001 09:36:34 -0700 From: Ricky Charlet Cc: ".ipsec-policy" Message-ID: <3ACC9272.BEB1CEDB@redcreek.com> Date: Thu, 05 Apr 2001 09:42:42 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: granularity property in Common Information Model References: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> <4.3.2.7.2.20010327161340.01d40fe8@brussels.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 Howdy, OK, I appologize for the delay in my reply. Thanks Eric for your expanded explimation of specifying Phase II client IDs and offer to include Linear Ranges in the granularity property of the model. I have also had a read through the newer draft-ietf-ipsp-config-policy-model-02.txt as it relates to filtering. I see that in the new draft, port and protocol filtering capabilities are now present. This satisfies my original concern (about the absence of port and protocol filtering and the reliance on only the granularity property). So, about where to derive the phase II IDs... I find your explimation to be sound and supportable. However, I think we can also (and I would rather) pick up the Phase II IDs from the traffic filters. Or to put it another way, As an implementor, I hope that I have the option of not supporting the granularity property and having the peopel who configure our implementation know that they will be specifiying the phaseII client IDs with the filters they set up. Now about those linear address ranges... I guess these are not a priority for me although I would like them. It seems to me that we should support them just for the principle of conforming to the standard architecture. I do believe that someday, I'll have a customer that just demands them. However, If we are to support linier address ranges, I would like to see us develop filters for them. I will not oppose the the filtering oriented granularity poperty in the action branch of the model, I just need to advocate for the presence of rich filtering capabilites to be supported in the actual filtering branch of the model. Eric Vyncke wrote: > > Rick, > > Obviously both the I-D and my previous email messages are not crystal clear :-( > > (I share your comment between parenthesis about the applicable phase 2 ID, > for me this could possibly be IPV[46] address, subnet or range of addresses). > > Section 4.6.2 of RFC 2407 specifies the possible formats for an ID payload. > While it clearly says that IP protocol type and port is to be set to 0 or > to UDP port 500 for phase 1 ID, it also says that protocol type and port > can be set to 0 (with 0 meaning wild card) or to a specific value for phase > 2 ID. > > Let's do it with an example, the 'triggering' packet is from 192.168.1.1 > TCP/1024 to 10.1.1.1 TCP/80, the SACondition filter is any source IP from > 192.168.1.* to 10.*.*.*, then depending on the granularity, IKE should > negotiate phase 2 SA for the following phase 2 ID: > - subnet -> <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0> > for all protocols using ID_IPV4_ADDR_SUBNET format; > - host -> <192.168.1.1,protocol=0,port=0> & <10.1.1.1,,protocol=0,port=0> > for all protocols using ID_IPV4_ADDR format; > - protocol -> <192.168.1.1,protocol=6,port=0> & > <10.1.1.1,protocol=6,port=0> for all TCP ports using ID_IPV4_ADDR format; > - port -> <192.168.1.1,protocol=6,port=1024> & > <10.1.1.1,protocol=6,port=80) only for the triggering TCP flow using > ID_IPV4_ADDR format; > > On purpose, we simplified the information model by removing some possible > variations (like subnet on one side and address on the other side) because > we feel that no implementation are using those variations. Of course, we > can be wrong and the model could always be improved. > > NB: there is currently no provision in the IM to model a phase 2 of > ID_IPV4_ADDR_RANGE which may be a concern if some implementations are using > this kind of ID (and some recent troubleshooting between Cisco and Redcreek > concentrators make believe that you are using address ranges ;-) ). If > needed, we could also extend the IM to represent an address range as a > phase 2 ID. > > Anyway, if you believe that the above explanation is clearer, I would be > glad to augment the I-D with it. > > Hope this helps > > -eric > > At 09:37 20/03/2001 -0700, Ricky Charlet wrote: > >Thanks Eric, > > > > I see your point that the phase 2 ID needs to be specified as to > > type. > >I had not thought of that before. > > > > But, the granularity property in the IPsecAction (what do we call it, > >object, group, table, thingie?) seems to me to be mismatched with the > >set of possible 2 ID types. Specifically, we do not need ports and > >protocols in phase 2 IDs but on the other hand, we do need specific > >addresses, subnets, and ranges of addresses in IPv4 and IPv6. (I don't > >know if FQDN, user@FQDN, DN, GN, and keyID are supportable as phase 2 > >IDs, could someone else inform our disussion here. I don't see any thing > >saying they can not be used at phase 2, but I also don't see how data, > >not verifiable in a packet, could be used as a phase 2 ID.) In the case > >of subnets and ranges of addresses, these cannot be inferred from a > >packet-on-hand and a granularity property. > > > > So now I am left with my original request and a new question. Can we > >please provide filtering control for ports and protocols? And now, how > >should we know what client ID to use in (and the type of) the phase 2 > >Identification payload? > > Eric Vyncke > Distinguished Engineer Cisco Systems EMEA > Phone: +32-2-778-4677 Fax: +32-2-778-4300 > E-mail: evyncke@cisco.com Mobile: +32-475-312-458 (CHANGED) > PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141 -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Fri Apr 6 15:38:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18464 for ; Fri, 6 Apr 2001 15:38:49 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA17997 for ipsec-policy-bks; Fri, 6 Apr 2001 11:20:30 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17993 for ; Fri, 6 Apr 2001 11:20:28 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA27094 for ; Fri, 6 Apr 2001 14:19:56 -0400 Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA36942 for ; Fri, 6 Apr 2001 14:20:00 -0400 Message-ID: <006801c0bec5$b16cb4a0$11312509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <4.3.2.7.2.20010329161113.01c8a210@brussels.cisco.com> Subject: Re: nested SAs Date: Fri, 6 Apr 2001 14:16:24 -0400 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 Here's an outline of the solution we worked out after the meeting in Minneapolis. There's an aggregation called SAActionInRule that specifies the order in which actions are performed. The -02 model says that these are fallback actions. The proposal for the -03 draft is that we change the semantic of SAActionInRule.ActionOrder to be the order in which multiple actions are to be executed and add a new property, SAActionInRule.FallbackOrder, that specifies the fallback actions. So, for example, an SARule has 5 aggregated actions. (ao: actionorder, fo: fallbackorder) ao=1,fo=0 : first action to execute, e.g., establish SA to gateway ao=1,fo=1 : if the first action fails, try this one, e.g., try a different gateway ao=1,fo=2 : if that doesn't work, try this next one, e.g., deny ao=2,fo=0 : second action to execute, e.g., establish tunneled SA thru gateway ao=2,fo=1 : if the second action fails, try this one, e.g., deny This does not address complicated cases where the second action is dependent on the result of the first action. For that you need multiple rules. Nor does it address if or when the SA that resulted from the first pair of actions should be torn down if the second action ends up failing (e.g., deny), i.e., there's no commit/rollback semantic. Does this meet the requirements? Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com From owner-ipsec-policy@mail.vpnc.org Fri Apr 6 16:34:00 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19698 for ; Fri, 6 Apr 2001 16:33:59 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA22044 for ipsec-policy-bks; Fri, 6 Apr 2001 12:32:34 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22040 for ; Fri, 6 Apr 2001 12:32:32 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA24674 for ; Fri, 6 Apr 2001 15:32:04 -0400 Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA25432 for ; Fri, 6 Apr 2001 15:32:04 -0400 Message-ID: <008601c0becf$bccf8c00$11312509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> <4.3.2.7.2.20010327161340.01d40fe8@brussels.cisco.com> <3ACC9272.BEB1CEDB@redcreek.com> Subject: Re: granularity property in Common Information Model Date: Fri, 6 Apr 2001 15:28:18 -0400 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 > So, about where to derive the phase II IDs... I find your explimation > to be sound and supportable. However, I think we can also (and I would > rather) pick up the Phase II IDs from the traffic filters. Or to put it > another way, As an implementor, I hope that I have the option of not > supporting the granularity property and having the peopel who configure > our implementation know that they will be specifiying the phaseII client > IDs with the filters they set up. Ricky, From a system-wide configuration perspective, I'd rather we keep the functions of filtering and granularity separate. Filters are intended to be used to identify the rule that applies to a given packet and situation. If we add an optional semantic that granularity is specified by the filter as well, we fracture the standard so that we lose both device-independent policy specification and interoperability. As for granularity being optional, I believe it should be. But I don't think there should be another way of configuring it if you choose to support it. My 2 cents. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com > > Now about those linear address ranges... I guess these are not a > priority for me although I would like them. It seems to me that we > should support them just for the principle of conforming to the standard > architecture. I do believe that someday, I'll have a customer that just > demands them. However, If we are to support linier address ranges, I > would like to see us develop filters for them. I will not oppose the the > filtering oriented granularity poperty in the action branch of the > model, I just need to advocate for the presence of rich filtering > capabilites to be supported in the actual filtering branch of the model. > > > > > Eric Vyncke wrote: > > > > Rick, > > > > Obviously both the I-D and my previous email messages are not crystal clear :-( > > > > (I share your comment between parenthesis about the applicable phase 2 ID, > > for me this could possibly be IPV[46] address, subnet or range of addresses). > > > > Section 4.6.2 of RFC 2407 specifies the possible formats for an ID payload. > > While it clearly says that IP protocol type and port is to be set to 0 or > > to UDP port 500 for phase 1 ID, it also says that protocol type and port > > can be set to 0 (with 0 meaning wild card) or to a specific value for phase > > 2 ID. > > > > Let's do it with an example, the 'triggering' packet is from 192.168.1.1 > > TCP/1024 to 10.1.1.1 TCP/80, the SACondition filter is any source IP from > > 192.168.1.* to 10.*.*.*, then depending on the granularity, IKE should > > negotiate phase 2 SA for the following phase 2 ID: > > - subnet -> <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0> > > for all protocols using ID_IPV4_ADDR_SUBNET format; > > - host -> <192.168.1.1,protocol=0,port=0> & <10.1.1.1,,protocol=0,port=0> > > for all protocols using ID_IPV4_ADDR format; > > - protocol -> <192.168.1.1,protocol=6,port=0> & > > <10.1.1.1,protocol=6,port=0> for all TCP ports using ID_IPV4_ADDR format; > > - port -> <192.168.1.1,protocol=6,port=1024> & > > <10.1.1.1,protocol=6,port=80) only for the triggering TCP flow using > > ID_IPV4_ADDR format; > > > > On purpose, we simplified the information model by removing some possible > > variations (like subnet on one side and address on the other side) because > > we feel that no implementation are using those variations. Of course, we > > can be wrong and the model could always be improved. > > > > NB: there is currently no provision in the IM to model a phase 2 of > > ID_IPV4_ADDR_RANGE which may be a concern if some implementations are using > > this kind of ID (and some recent troubleshooting between Cisco and Redcreek > > concentrators make believe that you are using address ranges ;-) ). If > > needed, we could also extend the IM to represent an address range as a > > phase 2 ID. > > > > Anyway, if you believe that the above explanation is clearer, I would be > > glad to augment the I-D with it. > > > > Hope this helps > > > > -eric > > > > At 09:37 20/03/2001 -0700, Ricky Charlet wrote: > > >Thanks Eric, > > > > > > I see your point that the phase 2 ID needs to be specified as to > > > type. > > >I had not thought of that before. > > > > > > But, the granularity property in the IPsecAction (what do we call it, > > >object, group, table, thingie?) seems to me to be mismatched with the > > >set of possible 2 ID types. Specifically, we do not need ports and > > >protocols in phase 2 IDs but on the other hand, we do need specific > > >addresses, subnets, and ranges of addresses in IPv4 and IPv6. (I don't > > >know if FQDN, user@FQDN, DN, GN, and keyID are supportable as phase 2 > > >IDs, could someone else inform our disussion here. I don't see any thing > > >saying they can not be used at phase 2, but I also don't see how data, > > >not verifiable in a packet, could be used as a phase 2 ID.) In the case > > >of subnets and ranges of addresses, these cannot be inferred from a > > >packet-on-hand and a granularity property. > > > > > > So now I am left with my original request and a new question. Can we > > >please provide filtering control for ports and protocols? And now, how > > >should we know what client ID to use in (and the type of) the phase 2 > > >Identification payload? > > > > Eric Vyncke > > Distinguished Engineer Cisco Systems EMEA > > Phone: +32-2-778-4677 Fax: +32-2-778-4300 > > E-mail: evyncke@cisco.com Mobile: +32-475-312-458 (CHANGED) > > PGP fingerprint: D35F BEF9 643F 656F 90F5 76C5 9CA1 C289 D398 B141 > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Fri Apr 6 17:33:44 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20913 for ; Fri, 6 Apr 2001 17:33:44 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA26101 for ipsec-policy-bks; Fri, 6 Apr 2001 13:24:59 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA26094 for ; Fri, 6 Apr 2001 13:24:58 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 13:24:38 -0700 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.2653.13) id H30M3WYB; Fri, 6 Apr 2001 13:20:24 -0700 From: Ricky Charlet To: Lee Rafalow Cc: ipsec-policy@vpnc.org Message-ID: <3ACE1864.8066BE13@redcreek.com> Date: Fri, 06 Apr 2001 13:26:28 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: granularity property in Common Information Model References: <4.3.2.7.2.20010319210605.00b9f6e8@brussels.cisco.com> <4.3.2.7.2.20010327161340.01d40fe8@brussels.cisco.com> <3ACC9272.BEB1CEDB@redcreek.com> <008601c0becf$bccf8c00$11312509@raleigh.ibm.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 Lee Rafalow wrote: > > > So, about where to derive the phase II IDs... I find your explimation > > to be sound and supportable. However, I think we can also (and I would > > rather) pick up the Phase II IDs from the traffic filters. Or to put it > > another way, As an implementor, I hope that I have the option of not > > supporting the granularity property and having the peopel who configure > > our implementation know that they will be specifiying the phaseII client > > IDs with the filters they set up. > > Ricky, From a system-wide configuration perspective, I'd rather we keep the > functions of filtering and granularity separate. Filters are intended to be > used to identify the rule that applies to a given packet and situation. If > we add an optional semantic that granularity is specified by the filter as > well, we fracture the standard so that we lose both device-independent > policy specification and interoperability. > > As for granularity being optional, I believe it should be. But I don't > think there should be another way of configuring it if you choose to support > it. > > My 2 cents. > Howdy, How is granularity different than filtering? What functions are you trying to keep seperate. The best that I have been able to comprehend so far, ganularity is filtering, it's just hidden over in the action branch of the model rather than the condition branch. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Fri Apr 6 17:39:26 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20981 for ; Fri, 6 Apr 2001 17:39:25 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA26833 for ipsec-policy-bks; Fri, 6 Apr 2001 13:34:58 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA26829 for ; Fri, 6 Apr 2001 13:34:57 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 13:34:38 -0700 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.2653.13) id H30M3WYM; Fri, 6 Apr 2001 13:29:17 -0700 From: Ricky Charlet To: Lee Rafalow Cc: ipsec-policy@vpnc.org Message-ID: <3ACE1A7F.4896ADF@redcreek.com> Date: Fri, 06 Apr 2001 13:35:27 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: nested SAs References: <4.3.2.7.2.20010329161113.01c8a210@brussels.cisco.com> <006801c0bec5$b16cb4a0$11312509@raleigh.ibm.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 Lee Rafalow wrote: > > Here's an outline of the solution we worked out after the meeting in > Minneapolis. > > There's an aggregation called SAActionInRule that specifies the order in > which actions are performed. The -02 model says that these are fallback > actions. > > The proposal for the -03 draft is that we change the semantic of > SAActionInRule.ActionOrder to be the order in which multiple actions are to > be executed and add a new property, SAActionInRule.FallbackOrder, that > specifies the fallback actions. > > So, for example, an SARule has 5 aggregated actions. > (ao: actionorder, fo: fallbackorder) > > ao=1,fo=0 : first action to execute, e.g., establish SA to gateway > ao=1,fo=1 : if the first action fails, try this one, e.g., try a different > gateway > ao=1,fo=2 : if that doesn't work, try this next one, e.g., deny > ao=2,fo=0 : second action to execute, e.g., establish tunneled SA thru > gateway > ao=2,fo=1 : if the second action fails, try this one, e.g., deny > > This does not address complicated cases where the second action is dependent > on the result of the first action. For that you need multiple rules. Nor > does it address if or when the SA that resulted from the first pair of > actions should be torn down if the second action ends up failing (e.g., > deny), i.e., there's no commit/rollback semantic. > > Does this meet the requirements? > Howdy, Our implementation will require action chaining as well as a fallback action chain. Of the actions we chain, only one will be IPsec, others would be things like NAT, QOS, ... It sound to me like your model (-03 proposal) can satisfy our requirements. Except that I don't like the name SAActionInRule. Could we add a layer ActionInRule that has the properties you describe and can have SAActions attached and if people so develop, other actions attached as well? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Tue Apr 10 21:06:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29509 for ; Tue, 10 Apr 2001 21:06:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id RAA12106 for ipsec-policy-bks; Tue, 10 Apr 2001 17:05:13 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA12102 for ; Tue, 10 Apr 2001 17:05:11 -0700 (PDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA08648 for ; Wed, 11 Apr 2001 00:04:34 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 11 Apr 2001 00:04:34 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2VQJ9PS3>; Tue, 10 Apr 2001 17:04:32 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7C79@FMSMSX38> From: "Jason, Jamie" To: ipsec-policy@vpnc.org Subject: Mistakes in IPSP Config Policy Model Draft Date: Tue, 10 Apr 2001 17:04:26 -0700 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: I wanted to draw attention to a couple of mistakes that we discovered in the policy model draft (draft-ietf-ipsp-config-policy-model-02.txt). On page 29 in the diagram for the action classes: - the association TransformOfPreconfiguredAction should actually be between PreconfiguredSAAction and SATransform. The cardinalities remain the same and the verbage in the TransformOfPreconfiguredAction section (6.18) is correct. - there are two PreconfiguredTransportAction classes. That was a cut-and-paste error. One should be named PreconfiguredTunnelAction and it corresponds to section 6.8 These changes, as well as some things that came out the WG meeting in Minneapolis will be in the next revision of the draft. Jamie ---------------------------------------------------------------- Jamie Jason email: jamie.jason@intel.com Intel Architecture Labs phone: 503-264-9531 2111 NE 25th Avenue fax: 503-264-9428 Hillsboro, OR 97124 "A lot of people run a race to see who is fastest. I run to see who has the most guts..." - Steve Prefontaine All opinions expressed are: 1. Entirely my own. 2. Not necessarily shared by my employer. 3. Unencumbered by the thought process. ---------------------------------------------------------------- From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 11:44:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13351 for ; Fri, 20 Apr 2001 11:44:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA10912 for ipsec-policy-bks; Fri, 20 Apr 2001 07:45:53 -0700 (PDT) Received: from mail9.wlv.netzero.net (mail9.wlv.netzero.net [209.247.163.66]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA10907 for ; Fri, 20 Apr 2001 07:45:51 -0700 (PDT) Received: (qmail 12718 invoked from network); 20 Apr 2001 14:44:53 -0000 Received: from pppa86-resaleraleigh2-5r7149.dialinx.net (HELO casey) (4.54.43.243) by mail9.wlv.netzero.net with SMTP; 20 Apr 2001 14:44:53 -0000 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: FW: TDomain in IPSEC-POLICY-MIB Date: Fri, 20 Apr 2001 10:47:55 -0400 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) Importance: Normal 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 Sorry, sent this to the wrong address the first time. Casey -----Original Message----- From: Casey Carr [mailto:caseycarr@usa.com] Sent: Thursday, April 19, 2001 8:53 AM To: owner-ipsec-policy@mail.vpnc.org Subject: TDomain in IPSEC-POLICY-MIB Can someone tell me what are valid values for the "peEndpointDomain" in the "policyEndpointToGroupTable"? I conceptually understand why it is included but I'm not sure which MIB defines valid Tdomain objects that relate to transport services for IPSec. Also, how does this MIB object map to the IPSec policy model. I could not find an equivalent object in either the DMTF or IETF specifications. Casey NetZero Platinum No Banner Ads and Unlimited Access Sign Up Today - Only $9.95 per month! http://www.netzero.net From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 11:46:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13377 for ; Fri, 20 Apr 2001 11:46:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA10932 for ipsec-policy-bks; Fri, 20 Apr 2001 07:46:45 -0700 (PDT) Received: from mail8.wlv.netzero.net (mail8.wlv.netzero.net [209.247.163.58]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA10928 for ; Fri, 20 Apr 2001 07:46:44 -0700 (PDT) Received: (qmail 4821 invoked from network); 20 Apr 2001 14:46:45 -0000 Received: from pppa86-resaleraleigh2-5r7149.dialinx.net (HELO casey) (4.54.43.243) by mail8.wlv.netzero.net with SMTP; 20 Apr 2001 14:46:45 -0000 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: CONFIG MIB Date: Fri, 20 Apr 2001 10:48:53 -0400 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) Importance: Normal 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 have a couple of more comments on the IPSEC-POLICY-MIB: 1) Nit pick - shouldn't DFHandleing be DFHandling? 2) The ipsecAhTransformSet, ipsecEspTransformSet and ipsecIpcompTransformSet objects in the IpsecProposalEntry are commented to indicate that they are list of names for entries into the corresponding transform tables. a. What are the lists of names separated with? (comma, space, semi-colon...) b. Since the transform set objects are all defined with SnmpAdminString syntax, and the transform names in the transform tables are also SnmpAdminString syntax, then the list of names in the transform set could conceivably contain more characters than the object can hold. c. Why did you not use the same technique as FiltersInCondition to define TransformsInProposals? Thanks, Casey Principal Software Engineer CipherOptics, Inc. (919) 865-7304 NetZero Platinum No Banner Ads and Unlimited Access Sign Up Today - Only $9.95 per month! http://www.netzero.net From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 12:58:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14479 for ; Fri, 20 Apr 2001 12:58:11 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA21262 for ipsec-policy-bks; Fri, 20 Apr 2001 09:06:39 -0700 (PDT) Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA21258 for ; Fri, 20 Apr 2001 09:06:38 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id JAA01211; Fri, 20 Apr 2001 09:06:30 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "IPSec Policy WG" Subject: Re: CONFIG MIB References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 20 Apr 2001 09:06:30 -0700 In-Reply-To: ("Casey Carr"'s message of "Fri, 20 Apr 2001 10:48:53 -0400") Message-ID: Lines: 29 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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: >>>>> On Fri, 20 Apr 2001 10:48:53 -0400, "Casey Carr" said: Casey> 1) Nit pick - shouldn't DFHandleing be DFHandling? Yes. Thanks. Casey> 2) The ipsecAhTransformSet, ipsecEspTransformSet and Casey> ipsecIpcompTransformSet objects in the IpsecProposalEntry are Casey> commented to indicate that they are list of names for entries Casey> into the corresponding transform tables. We'll try and clarify that. Most likely, we'll change how this actually works. Casey> c. Why did you not use the same technique as FiltersInCondition Casey> to define TransformsInProposals? Thats probably the better way to go, you're right. I'll be (hopefully) working a lot on this MIB (again) in the next few weeks. The MIB was written in sections by a few different people, so there are inconsistencies in how things are done in some places. There are also other serious issues that need to be solved as well... Any further comments you have would be greatly appreciated, of course. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 13:18:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14831 for ; Fri, 20 Apr 2001 13:18:45 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA22438 for ipsec-policy-bks; Fri, 20 Apr 2001 09:18:15 -0700 (PDT) Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA22434 for ; Fri, 20 Apr 2001 09:18:13 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id JAA01252; Fri, 20 Apr 2001 09:17:01 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "IPSec Policy WG" Subject: Re: FW: TDomain in IPSEC-POLICY-MIB References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 20 Apr 2001 09:17:01 -0700 In-Reply-To: ("Casey Carr"'s message of "Fri, 20 Apr 2001 10:47:55 -0400") Message-ID: Lines: 34 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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: >>>>> On Fri, 20 Apr 2001 10:47:55 -0400, "Casey Carr" said: Casey> Can someone tell me what are valid values for the Casey> "peEndpointDomain" in the "policyEndpointToGroupTable"? I Casey> conceptually understand why it is included but I'm not sure Casey> which MIB defines valid Tdomain objects that relate to Casey> transport services for IPSec. This certainly needs to be better described. Only the address of the transport domain is actually used for the endpoint. Such that if the snmpUDPDomain is used, the value of the peEndpointAddress should be an appropriately specified according to the snmpUDPDomain definition, but the port number portion of it will be ignored. More likely, we need to define our own transport domains that are address only to some extent. The network address manipulation in the MIB is certainly not trivial to understand as is and needs to be cleaned up. Casey> Also, how does this MIB object map to the IPSec policy model. Casey> I could not find an equivalent object in either the DMTF or Casey> IETF specifications. The config-policy-model doesn't have an equivelent object. It's purpose is solely to take a given policy definition(s) and apply them to "something". That "something" in this case is fundamentally an interface on a device. We decided to use addresses to reference that device instead of something like the ifIndex to better enable the use of virtual interfaces. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 15:35:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16899 for ; Fri, 20 Apr 2001 15:35:34 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA01276 for ipsec-policy-bks; Fri, 20 Apr 2001 11:22:08 -0700 (PDT) Received: from wlv.interdyn.com ([205.147.53.144]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA01272 for ; Fri, 20 Apr 2001 11:22:06 -0700 (PDT) Received: by WLV with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 11:19:44 -0700 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.2653.13) id JHZ8ADHN; Fri, 20 Apr 2001 11:21:47 -0700 From: Ricky Charlet To: caseycarr@usa.com Cc: IPSec Policy WG Message-ID: <3AE071BE.70D3C0A5@redcreek.com> Date: Fri, 20 Apr 2001 11:28:30 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: FW: TDomain in IPSEC-POLICY-MIB References: 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 Casey Carr wrote: > > Sorry, sent this to the wrong address the first time. > > Casey > > -----Original Message----- > From: Casey Carr [mailto:caseycarr@usa.com] > Sent: Thursday, April 19, 2001 8:53 AM > To: owner-ipsec-policy@mail.vpnc.org > Subject: TDomain in IPSEC-POLICY-MIB > > Can someone tell me what are valid values for the "peEndpointDomain" in the > "policyEndpointToGroupTable"? I conceptually understand why it is included > but I'm not sure which MIB defines valid Tdomain objects that relate to > transport services for IPSec. > > Also, how does this MIB object map to the IPSec policy model. I could not > find an equivalent object in either the DMTF or IETF specifications. > > Casey Howdy, TDomain is defined in rfc1903 SNMPv2-TC which refers the reader to rfc1906 SNMPv2-TM. The possible values are: snmpUDPDomain, snmpCLNSDomain, snmpCONSDomain, snmpDDPDomain, snmpIPXDomain. This choice is really a mismatch for our purposes but was just part of us rushing to get the first draft out. Thank you for pointing to it and getting the real discussion started. The question arises, what things should we support as endpoints. This table holds enpoints for both IPsec and IKE policies. The Isakmp/IKE/doi docs require the possible identities which may be protected are identified by the triplit of a single port, a protocol and one of: ID Type Value ------- ----- RESERVED 0 ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 draft-ietf-ipsec-doi-tc-mib-04.txt suggests IpsecDoiIdentType ::= TEXTUAL-CONVENTION. We would have to back it up with specific definitions for each type (perhaps borrowing other textual conventions for the specifics. How would that seem to folks? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 16:15:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17476 for ; Fri, 20 Apr 2001 16:15:28 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA02591 for ipsec-policy-bks; Fri, 20 Apr 2001 12:10:04 -0700 (PDT) Received: from mail9.wlv.netzero.net (mail9.wlv.netzero.net [209.247.163.66]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA02587 for ; Fri, 20 Apr 2001 12:10:02 -0700 (PDT) Received: (qmail 4663 invoked from network); 20 Apr 2001 19:09:07 -0000 Received: from pppa31-resaleraleigh3-2r7136.dialinx.net (HELO casey) (4.54.16.188) by mail9.wlv.netzero.net with SMTP; 20 Apr 2001 19:09:07 -0000 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: More on IPSEC-POLICY-MIB Date: Fri, 20 Apr 2001 15:12:06 -0400 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) Importance: Normal 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 Is this the correct forum for this stuff or should I be going directly to the MIB authors? I don't want to bore those not interested but is it considered bad practice to do and end run around this mailing list? 1. "pgIKEConditionListType DEFVAL( true )" should be either "pgIKEConditionListType DEFVAL( or )" or "pgIKEConditionListType DEFVAL( and )" 2. "ficFilterIsNegated" is defined but not include in the "FiltersInConditionEntry" 2. The AntiReplay objects are defined inconsistently. Should they all be TruthValue syntax? 3. ipsecGroupId object in the IpsecActionEntry - should the syntax be "IpsecGroupId" instead of INTEGER? My personal opinion is that the IpsecGroupId ::= TEXTUAL-CONVENTION would be more appropriately named "DhGroupId". Casey NetZero Platinum No Banner Ads and Unlimited Access Sign Up Today - Only $9.95 per month! http://www.netzero.net From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 17:05:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18051 for ; Fri, 20 Apr 2001 17:05:26 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA05484 for ipsec-policy-bks; Fri, 20 Apr 2001 13:07:47 -0700 (PDT) Received: from mail7.wlv.netzero.net (mail7.wlv.netzero.net [209.247.163.57]) by above.proper.com (8.9.3/8.9.3) with SMTP id NAA05480 for ; Fri, 20 Apr 2001 13:07:46 -0700 (PDT) Received: (qmail 8061 invoked from network); 20 Apr 2001 20:07:46 -0000 Received: from pppa31-resaleraleigh3-2r7136.dialinx.net (HELO casey) (4.54.16.188) by mail7.wlv.netzero.net with SMTP; 20 Apr 2001 20:07:46 -0000 Reply-To: From: "Casey Carr" To: "IPSec Policy WG" Subject: RE: FW: TDomain in IPSEC-POLICY-MIB Date: Fri, 20 Apr 2001 16:09:55 -0400 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) In-Reply-To: <3AE071BE.70D3C0A5@redcreek.com> Importance: Normal 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 That seems reasonable to me. The list you suggest is what I expected as choices. -----Original Message----- From: owner-ipsec-policy@mail.vpnc.org [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Ricky Charlet Sent: Friday, April 20, 2001 1:29 PM To: caseycarr@usa.com Cc: IPSec Policy WG Subject: Re: FW: TDomain in IPSEC-POLICY-MIB Casey Carr wrote: > > Sorry, sent this to the wrong address the first time. > > Casey > > -----Original Message----- > From: Casey Carr [mailto:caseycarr@usa.com] > Sent: Thursday, April 19, 2001 8:53 AM > To: owner-ipsec-policy@mail.vpnc.org > Subject: TDomain in IPSEC-POLICY-MIB > > Can someone tell me what are valid values for the "peEndpointDomain" in the > "policyEndpointToGroupTable"? I conceptually understand why it is included > but I'm not sure which MIB defines valid Tdomain objects that relate to > transport services for IPSec. > > Also, how does this MIB object map to the IPSec policy model. I could not > find an equivalent object in either the DMTF or IETF specifications. > > Casey Howdy, TDomain is defined in rfc1903 SNMPv2-TC which refers the reader to rfc1906 SNMPv2-TM. The possible values are: snmpUDPDomain, snmpCLNSDomain, snmpCONSDomain, snmpDDPDomain, snmpIPXDomain. This choice is really a mismatch for our purposes but was just part of us rushing to get the first draft out. Thank you for pointing to it and getting the real discussion started. The question arises, what things should we support as endpoints. This table holds enpoints for both IPsec and IKE policies. The Isakmp/IKE/doi docs require the possible identities which may be protected are identified by the triplit of a single port, a protocol and one of: ID Type Value ------- ----- RESERVED 0 ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 draft-ietf-ipsec-doi-tc-mib-04.txt suggests IpsecDoiIdentType ::= TEXTUAL-CONVENTION. We would have to back it up with specific definitions for each type (perhaps borrowing other textual conventions for the specifics. How would that seem to folks? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 NetZero Platinum No Banner Ads and Unlimited Access Sign Up Today - Only $9.95 per month! http://www.netzero.net From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 17:55:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18567 for ; Fri, 20 Apr 2001 17:55:18 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA08746 for ipsec-policy-bks; Fri, 20 Apr 2001 13:59:41 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA08742 for ; Fri, 20 Apr 2001 13:59:39 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Apr 2001 14:59:07 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 20 Apr 2001 14:59:01 -0600 From: "Hilarie Orman" To: , Subject: Re: More on IPSEC-POLICY-MIB 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 above.proper.com id NAA08743 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit At the last IETF we invited this sort of discussion on the mailing list. Hilarie >>> "Casey Carr" 04/20/01 01:12PM >>> Is this the correct forum for this stuff or should I be going directly to the MIB authors? I don't want to bore those not interested but is it considered bad practice to do and end run around this mailing list? 1. "pgIKEConditionListType DEFVAL( true )" should be either "pgIKEConditionListType DEFVAL( or )" or "pgIKEConditionListType DEFVAL( and )" 2. "ficFilterIsNegated" is defined but not include in the "FiltersInConditionEntry" 2. The AntiReplay objects are defined inconsistently. Should they all be TruthValue syntax? 3. ipsecGroupId object in the IpsecActionEntry - should the syntax be "IpsecGroupId" instead of INTEGER? My personal opinion is that the IpsecGroupId ::= TEXTUAL-CONVENTION would be more appropriately named "DhGroupId". Casey NetZero Platinum No Banner Ads and Unlimited Access Sign Up Today - Only $9.95 per month! http://www.netzero.net From owner-ipsec-policy@mail.vpnc.org Fri Apr 20 19:01:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19595 for ; Fri, 20 Apr 2001 19:01:54 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA14433 for ipsec-policy-bks; Fri, 20 Apr 2001 15:04:17 -0700 (PDT) Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA14426 for ; Fri, 20 Apr 2001 15:04:15 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id PAA02260; Fri, 20 Apr 2001 15:04:04 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Cc: "IPSec Policy WG" Subject: Re: More on IPSEC-POLICY-MIB References: From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 20 Apr 2001 15:04:04 -0700 In-Reply-To: ("Casey Carr"'s message of "Fri, 20 Apr 2001 15:12:06 -0400") Message-ID: Lines: 49 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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: >>>>> On Fri, 20 Apr 2001 15:12:06 -0400, "Casey Carr" said: Casey> Is this the correct forum for this stuff or should I be going Casey> directly to the MIB authors? This is the correct forum. We warned the WG that it may be a lot of traffic at the last meeting and they said it actually would be a good thing. We'll see if they agree after the onslaught I intend to post next week about it. Casey> 1. "pgIKEConditionListType DEFVAL( true )" should be either Casey> "pgIKEConditionListType DEFVAL( or )" or "pgIKEConditionListType Casey> DEFVAL( and )" Thanks. Changed to "and". (we were originally using a boolean TC there). Casey> 2. "ficFilterIsNegated" is defined but not include in the Casey> "FiltersInConditionEntry" fixed. Casey> 2. The AntiReplay objects are defined inconsistently. Should they all be Casey> TruthValue syntax? Changed them all to TruthValue. Casey> 3. ipsecGroupId object in the IpsecActionEntry - should the syntax be Casey> "IpsecGroupId" instead of INTEGER? Yep. Fixed. Casey> My personal opinion is that the IpsecGroupId ::= Casey> TEXTUAL-CONVENTION would be more appropriately named Casey> "DhGroupId". Good point. Changed to "DHGroupId". Thanks again for the comments! (by the way, you may wish to check out http://www.hardakers.net/ipsec/presentation/ which is a presentation I gave at the last meeting on the MIB if you missed it [warning: slow ISDN link]). -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Mon Apr 23 15:28:19 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11089 for ; Mon, 23 Apr 2001 15:28:17 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA13750 for ipsec-policy-bks; Mon, 23 Apr 2001 11:11:20 -0700 (PDT) Received: from web13107.mail.yahoo.com (web13107.mail.yahoo.com [216.136.174.152]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA13745 for ; Mon, 23 Apr 2001 11:11:19 -0700 (PDT) Message-ID: <20010423181121.29483.qmail@web13107.mail.yahoo.com> Received: from [38.186.47.9] by web13107.mail.yahoo.com; Mon, 23 Apr 2001 11:11:21 PDT Date: Mon, 23 Apr 2001 11:11:21 -0700 (PDT) From: Elwin Eliazer Subject: a question on SPP draft ... To: ipsec-policy@vpnc.org In-Reply-To: <3AE04641.F5557337@megisto.com> 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: Hi, I am referring to the SPP defined in draft-ietf-ipsp-spp-00.txt. SPP relies heavily on the capability to merge policy rules from different places. I think this merge is not *always* feasible. Take for example a host H1, configured with policies: SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 150.1.0.0/16 A1 0.0.0.0/0 0.0.0.0/0 A2 And policy server PS2, having the following policies for H1: SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 150.1.2.0/24 A3 0.0.0.0/0 150.0.0.0/8 A4 0.0.0.0/0 0.0.0.0/0 A5 When the SPP fetches the policies for H1, how are these merged into H1, since there are different merged outcome possible, two of which are listed below. Merged-outcome-1-at-H1: SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 150.1.2.0/24 A3 0.0.0.0/0 150.1.0.0/16 A1 0.0.0.0/0 150.0.0.0/8 A4 0.0.0.0/0 0.0.0.0/0 A5 Merged-outcome-2-at-H1: SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 150.1.2.0/24 A3 0.0.0.0/0 150.0.0.0/8 A4 0.0.0.0/0 150.1.0.0/16 A1 /* may be deleted */ 0.0.0.0/0 0.0.0.0/0 A2 How is this ambiguity resolved? The above examples are very simple cases. More complex cases can be arrived at, that are practically possible. The fundamental problem in merging arises from the inherent ordering of policy rules, and it is difficult to merge (or not possible to correctly merge) when there are ambiguious cases, and i believe these ambiguity are very likely cases. Would like to hear others opinion on this. regards, Elwin. ===== ------- Elwin Stelzer Eliazer Corona Networks San Jose, CA 408-519-3832 ------- __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Mon Apr 23 16:09:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11857 for ; Mon, 23 Apr 2001 16:09:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA17313 for ipsec-policy-bks; Mon, 23 Apr 2001 12:17:08 -0700 (PDT) Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA17306 for ; Mon, 23 Apr 2001 12:17:07 -0700 (PDT) Received: (qmail 6009 invoked by uid 20813); 23 Apr 2001 19:17:08 -0000 Date: 23 Apr 2001 19:17:08 -0000 Message-ID: <20010423191708.6008.qmail@squatch.ir.bbn.com> From: Matthew Condell To: ipsec-policy@vpnc.org Subject: Re: a question on SPP draft ... Reply-to: mcondell@bbn.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Elwin, > I am referring to the SPP defined in > draft-ietf-ipsp-spp-00.txt. > SPP relies heavily on the capability to merge > policy rules from different places. I think > this merge is not *always* feasible. SPP avoids the problem you describe by requiring that all the policies that are exchanged be decorrelated -- that they do not have overlapping conditions so there is no inherent ordering constraint. (There was more information about decorrelation in an earlier draft submitted to the IPsec WG that was pulled out of this version of the draft in anticipation of it going into a different draft which never materialized). I'll work through your example to illustrate: > Take for example a host H1, configured with > policies: > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 150.1.0.0/16 A1 > 0.0.0.0/0 0.0.0.0/0 A2 SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 150.1.0.0/16 A1 0.0.0.0/0 not 150.1.0.0/16 A2 > And policy server PS2, having the following > policies for H1: > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 150.1.2.0/24 A3 > 0.0.0.0/0 150.0.0.0/8 A4 > 0.0.0.0/0 0.0.0.0/0 A5 SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 150.1.2.0/24 A3 0.0.0.0/0 150.0.0.0/8 which is not also in 150.1.2.0/24 A4 0.0.0.0/0 not 150.0.0.0/8 A5 > When the SPP fetches the policies for H1, how > are these merged into H1, since there are > different merged outcome possible, two of which > are listed below. SPP will only fetch 1 policy rule at a time -- the one relevent to the requested communication. So, for example, if the request was for policy between 10.0.0.1 and 150.0.0.1 the two relevent rules would be exchanged: SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 not 150.1.0.0/16 A2 and 0.0.0.0/0 150.0.0.0/8 which is not also in 150.1.2.0/24 A4 The resulting merged policy rule would be (asuming I had merged these correctly...): SRC-IP DestIP Action ------ ------ ------ 0.0.0.0/0 150.0.0.0 - 150.0.255.255 and 150.2.0.0 - 150.255.255.255 A2 ^ A4 > Merged-outcome-1-at-H1: > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 150.1.2.0/24 A3 > 0.0.0.0/0 150.1.0.0/16 A1 > 0.0.0.0/0 150.0.0.0/8 A4 > 0.0.0.0/0 0.0.0.0/0 A5 > > Merged-outcome-2-at-H1: > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 150.1.2.0/24 A3 > 0.0.0.0/0 150.0.0.0/8 A4 > 0.0.0.0/0 150.1.0.0/16 A1 /* may be deleted */ > 0.0.0.0/0 0.0.0.0/0 A2 Since we are not merging sets of policy, we don't need to do these, but with the decorrelated policy, the merge could be done. Hope this clarifies things, Matt Condell BBN Technologies From owner-ipsec-policy@mail.vpnc.org Wed Apr 25 00:52:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24199 for ; Wed, 25 Apr 2001 00:52:49 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id UAA13472 for ipsec-policy-bks; Tue, 24 Apr 2001 20:45:35 -0700 (PDT) Received: from web13105.mail.yahoo.com (web13105.mail.yahoo.com [216.136.174.150]) by above.proper.com (8.9.3/8.9.3) with SMTP id UAA13468 for ; Tue, 24 Apr 2001 20:45:33 -0700 (PDT) Message-ID: <20010425034538.51194.qmail@web13105.mail.yahoo.com> Received: from [38.186.47.9] by web13105.mail.yahoo.com; Tue, 24 Apr 2001 20:45:38 PDT Date: Tue, 24 Apr 2001 20:45:38 -0700 (PDT) From: Elwin Eliazer Subject: Re: a question on SPP draft ... To: mcondell@bbn.com, ipsec-policy@vpnc.org In-Reply-To: <20010423191708.6008.qmail@squatch.ir.bbn.com> 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: Matthew, Do you expect policy server to run the decorrelation algorithm? And represent policies in decorrelated form? The decorrelated representation can result in a big exclusion list. The implementations i have seen all use only ordered policy lists. Thanks, Elwin. --- Matthew Condell wrote: > Elwin, > > > I am referring to the SPP defined in > > draft-ietf-ipsp-spp-00.txt. > > SPP relies heavily on the capability to merge > > policy rules from different places. I think > > this merge is not *always* feasible. > > SPP avoids the problem you describe by requiring > that all the > policies that are exchanged be decorrelated -- that > they do > not have overlapping conditions so there is no > inherent ordering > constraint. (There was more information about > decorrelation > in an earlier draft submitted to the IPsec WG that > was pulled out > of this version of the draft in anticipation of it > going into > a different draft which never materialized). > > I'll work through your example to illustrate: > > > Take for example a host H1, configured with > > policies: > > > > SRC-IP DestIP Action > > ------ ------ ------ > > 0.0.0.0/0 150.1.0.0/16 A1 > > 0.0.0.0/0 0.0.0.0/0 A2 > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 150.1.0.0/16 A1 > 0.0.0.0/0 not 150.1.0.0/16 A2 > > > And policy server PS2, having the following > > policies for H1: > > > > SRC-IP DestIP Action > > ------ ------ ------ > > 0.0.0.0/0 150.1.2.0/24 A3 > > 0.0.0.0/0 150.0.0.0/8 A4 > > 0.0.0.0/0 0.0.0.0/0 A5 > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 150.1.2.0/24 A3 > 0.0.0.0/0 150.0.0.0/8 > which is not also > in 150.1.2.0/24 A4 > 0.0.0.0/0 not 150.0.0.0/8 A5 > > > When the SPP fetches the policies for H1, how > > are these merged into H1, since there are > > different merged outcome possible, two of which > > are listed below. > > SPP will only fetch 1 policy rule at a time -- the > one relevent to the > requested communication. So, for example, if the > request was for policy > between 10.0.0.1 and 150.0.0.1 the two relevent > rules would be exchanged: > > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 not 150.1.0.0/16 A2 > and > 0.0.0.0/0 150.0.0.0/8 > which is not also > in 150.1.2.0/24 A4 > > The resulting merged policy rule would be (asuming I > had merged > these correctly...): > > SRC-IP DestIP Action > ------ ------ ------ > 0.0.0.0/0 150.0.0.0 - 150.0.255.255 > and 150.2.0.0 - 150.255.255.255 A2 ^ A4 > > > Merged-outcome-1-at-H1: > > > > SRC-IP DestIP Action > > ------ ------ ------ > > 0.0.0.0/0 150.1.2.0/24 A3 > > 0.0.0.0/0 150.1.0.0/16 A1 > > 0.0.0.0/0 150.0.0.0/8 A4 > > 0.0.0.0/0 0.0.0.0/0 A5 > > > > Merged-outcome-2-at-H1: > > > > SRC-IP DestIP Action > > ------ ------ ------ > > 0.0.0.0/0 150.1.2.0/24 A3 > > 0.0.0.0/0 150.0.0.0/8 A4 > > 0.0.0.0/0 150.1.0.0/16 A1 /* may be deleted > */ > > 0.0.0.0/0 0.0.0.0/0 A2 > > Since we are not merging sets of policy, we don't > need to > do these, but with the decorrelated policy, the > merge > could be done. > > Hope this clarifies things, > > Matt Condell > BBN Technologies ===== ------- Elwin Stelzer Eliazer Corona Networks San Jose, CA 408-519-3832 ------- __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-ipsec-policy@mail.vpnc.org Wed Apr 25 10:09:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16488 for ; Wed, 25 Apr 2001 10:09:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA26195 for ipsec-policy-bks; Wed, 25 Apr 2001 05:48:52 -0700 (PDT) Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA26190 for ; Wed, 25 Apr 2001 05:48:50 -0700 (PDT) Received: (qmail 13419 invoked by uid 20813); 25 Apr 2001 12:48:40 -0000 Date: 25 Apr 2001 12:48:40 -0000 Message-ID: <20010425124840.13418.qmail@squatch.ir.bbn.com> From: Matthew Condell To: ipsec-policy@vpnc.org Subject: Re: a question on SPP draft ... Reply-to: mcondell@bbn.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Elwin, --- Elwin Eliazer wrote: > Do you expect policy server to run the > decorrelation algorithm? And represent > policies in decorrelated form? Yes, the SPP draft requires policy servers to exchange decorrelated policies. This is required to allow policies to be cached. > The decorrelated representation can > result in a big exclusion list. > The implementations i have seen all use > only ordered policy lists. The decorrelated representation of a set of policies can be a bit cumbersome, however, it can relatively easily be generated from a list of ordered policies. Earlier drafts that included more details on decorrelation, also included one algorithm for decorrelating an ordered list of policies. I can send out the relevent text about decorrelation, if you'd find that useful. Matt From owner-ipsec-policy@mail.vpnc.org Wed Apr 25 20:11:08 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04440 for ; Wed, 25 Apr 2001 20:11:07 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id QAA18600 for ipsec-policy-bks; Wed, 25 Apr 2001 16:16:41 -0700 (PDT) Received: from wanderer.hardakers.net (adsl-63-195-146-66.dsl.scrm01.pacbell.net [63.195.146.66]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA18596 for ; Wed, 25 Apr 2001 16:16:39 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id QAA01564; Wed, 25 Apr 2001 16:16:54 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: ipsec-policy@vpnc.org Subject: group in group in MIB From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 25 Apr 2001 16:16:53 -0700 Message-ID: Lines: 51 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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: Currently the IPSEC-POLICY-MIB doesn't support group-in-group. The original definitions of the tables that Mike Baer and I came up with (sitting in a coffee shop) had more tables than the current MIB has and implemented group-in-group semantics. We then dropped the support for it when writing the draft as it was decided it was too complex. Then, in the Minneapolis meeting it was discussed again (in a wider audience) and decided that it should be supported. So, now I'm bringing it to the widest of the audiences (the mailing list) and we need to decide what to do and whether or not to support group-in-group semantics. Choices: 1) Leave it as is, where only rules can be inside groups. This would deviate from the data model. 2) Add a new table defining what a group is supposed to contain (1=groups, 2=rules). And another table containing the groups in a group if the type = 1. 3) merge the rules-in-groups/groups-in-groups table to be all one table containing merely a list of "names" in side a group, and then add one table like the first in #2 above that defined what a group was supposed to contain. I'm not really happy with how the data model currently works, and it makes this whole decision hard. As defined a group can contain *only* a set of groups *or* a set of rules. This makes it impossible to define a groupA that contains groupB, ruleC, groupD. ruleC, in this case, would have to be put into a group of its own (which is just silly). Also, what is the difference between GroupComponent and PartComponent in the current IPsecPolicyGroupInPolicyGroup object? It also makes no sense to me that the data model is defined such that groups and rules can even exist with the same priority level. I don't think "two ContainedGroups with the same precedence is undefined" is correct. I think it should be simply illegal. To do this properly though, the priority shouldn't be associated with the group itself, but with whatever contains it. IE, I'd like groupA (above) to contain 1=groupB, 5=ruleC, 1000=groupD and still have a second group optionally reorder them such that groupX contained 1=groupB, 20=groupD, 800=ruleC (last two swapped in precedence). -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Wed Apr 25 20:20:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04561 for ; Wed, 25 Apr 2001 20:20:23 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA18116 for ipsec-policy-bks; Wed, 25 Apr 2001 15:40:04 -0700 (PDT) Received: from wanderer.hardakers.net (adsl-63-195-146-66.dsl.scrm01.pacbell.net [63.195.146.66]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA18112 for ; Wed, 25 Apr 2001 15:40:03 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id PAA01494; Wed, 25 Apr 2001 15:40:10 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Ricky Charlet Cc: caseycarr@usa.com, IPSec Policy WG Subject: Re: FW: TDomain in IPSEC-POLICY-MIB References: <3AE071BE.70D3C0A5@redcreek.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 25 Apr 2001 15:40:08 -0700 In-Reply-To: <3AE071BE.70D3C0A5@redcreek.com> (Ricky Charlet's message of "Fri, 20 Apr 2001 11:28:30 -0600") Message-ID: Lines: 59 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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: >>>>> On Fri, 20 Apr 2001 11:28:30 -0600, Ricky Charlet said: Ricky> The question arises, what things should we support as Ricky> endpoints. This table holds enpoints for both IPsec and IKE Ricky> policies. The Isakmp/IKE/doi docs require the possible Ricky> identities which may be protected are identified by the triplit Ricky> of a single port, a protocol and one of: ID Type Value Ricky> ------- ----- Ricky> RESERVED 0 Ricky> ID_IPV4_ADDR 1 Ricky> ID_FQDN 2 Ricky> ID_USER_FQDN 3 Ricky> ID_IPV4_ADDR_SUBNET 4 Ricky> ID_IPV6_ADDR 5 Ricky> ID_IPV6_ADDR_SUBNET 6 Ricky> ID_IPV4_ADDR_RANGE 7 Ricky> ID_IPV6_ADDR_RANGE 8 Ricky> ID_DER_ASN1_DN 9 Ricky> ID_DER_ASN1_GN 10 Ricky> ID_KEY_ID 11 Ricky> draft-ietf-ipsec-doi-tc-mib-04.txt suggests IpsecDoiIdentType Ricky> ::= TEXTUAL-CONVENTION. We would have to back it up with Ricky> specific definitions for each type (perhaps borrowing other Ricky> textual conventions for the specifics. How would that seem to Ricky> folks? Well, this still leaves choices in my mind. We can: 1) use current existing TDomain style definitions, which (as pointed out) don't really fit our needs. 2) Use the above IpsecDoiIdentType definition, and then define how the value half of that is specified, um, somewhere? Should we then make a IpsecDoiIdentValue TC that has an extremely long description clause spelling out the value formating of the OCTETSTRING that its made of? 3) Define our own set of 11 or so TDomains to match the above and continue to use TAddress as the value specifier. There are also issues revolving around how they should be used. In the case of specifying an endpoint that is supposed to be singular (open a connection to "here"), should the description clause of every object dictate which is legal for that column and which isn't? Or should that definition be defined in the TC (I'd vote for the TC, but common MIB practice is to cut-n-paste it everywhere to make sure its visible and not missed because they didn't follow the TC reference). I've started converting the other pieces of the MIB to use the other TCs defined in the previously mentioned draft, but this is the case that truly needs more thoughts. Opinions? I'm leaning towards #2 above I guess. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Thu Apr 26 03:39:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25500 for ; Thu, 26 Apr 2001 03:39:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA01957 for ipsec-policy-bks; Wed, 25 Apr 2001 23:35:04 -0700 (PDT) Received: from ns2.iaf.fi (root@ns2.iaf.fi [195.94.103.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA01948 for ; Wed, 25 Apr 2001 23:35:01 -0700 (PDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f3Q6WpC08442; Thu, 26 Apr 2001 09:32:51 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id IAA27052; Thu, 26 Apr 2001 08:36:55 +0300] Message-ID: <004d01c0ce1b$2bb58890$3f02a8c0@garibaldi> From: "Sami Vaarala" To: , References: <20010425124840.13418.qmail@squatch.ir.bbn.com> Subject: Re: a question on SPP draft ... Date: Thu, 26 Apr 2001 09:36:03 +0300 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 Matthew, > > The decorrelated representation can > > result in a big exclusion list. > > The implementations i have seen all use > > only ordered policy lists. > > The decorrelated representation of a set of policies > can be a bit cumbersome, however, it can relatively easily > be generated from a list of ordered policies. Earlier drafts > that included more details on decorrelation, also included > one algorithm for decorrelating an ordered list of policies. > I can send out the relevent text about decorrelation, if you'd > find that useful. Most IPsec/IKE implementations rely on an ordered list of IPsec policies for policy matching. Is there an efficient method of converting the decorrelated representation into an (efficient) ordered list, that only requires 'standard' selectors (ie no exclusion lists or such)? I think this is very important when considering deployment. (I haven't read the draft in question, though, so if I am asking something that is obvious, just let me know.) -Sami From owner-ipsec-policy@mail.vpnc.org Thu Apr 26 09:20:52 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02691 for ; Thu, 26 Apr 2001 09:20:51 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA04529 for ipsec-policy-bks; Thu, 26 Apr 2001 05:05:17 -0700 (PDT) Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA04520 for ; Thu, 26 Apr 2001 05:05:15 -0700 (PDT) Received: (qmail 19764 invoked by uid 20813); 26 Apr 2001 12:05:15 -0000 Date: 26 Apr 2001 12:05:15 -0000 Message-ID: <20010426120515.19763.qmail@squatch.ir.bbn.com> From: Matthew Condell To: ipsec-policy@vpnc.org Subject: Decorrelation Reply-to: mcondell@bbn.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here's text from previous drafts describing the need for decorrelation and an algorithm for decorrelating a set of ordered policies. Matt ------------------------------------ Decorrelation It is not possible for a Policy Server to use policies as they are written in the SPS master file, since those policies are likely to be correlated. Two policies are correlated if there is a non-nil intersection between the values of each of their selectors. Caching correlated policies can lead to incorrect policy implementation based on those cached policies, as the following example shows. H1 --- SG1 --------- SG2 --- H2 | | \__ H3 | | PS1 PS2 PS2 contains the following policies in its master file: src dst proto direction action 1) * H2 * inbound permit 2) * * * inbound deny These two policies are correlated since all the selectors (src, dst, proto, and direction) overlap. The following SPP exchanges occur: 1) PS1 requests policy for H3. 2) PS2 returns policy #2 to PS1 which then caches policy #2. 3) PS1 now looks up the policy for H2 and discovers that it already has a matching policy (policy #2) and uses that. This is clearly wrong, since policy #2 indicates that the communication to H2 should be denied, though PS2's policy actually indicates that it should be allowed. The solution is to remove the ambiguities that may exist in the master file. The policies of the master file MUST be decorrelated before they are entered into the Local Policy Database. That is, the policies must be rewritten so that for every pair of policies there exists a selector for which there is a nil intersection between the values in both of the policies. The policies in the above example could be decorrelated as follows: src dst proto direction action 1') * H2 * inbound permit 2') * not H2 * inbound deny Now the exchange is a bit different: 1) PS1 requests policy for H3. 2) PS2 returns policy #2' to PS1 which then caches policy #2'. 3) PS1 now looks up the policy for H2, doesn't have a matching policy, so it requests a policy for H2. 4) PS2 returns policy #1' to PS1 which then caches policy #1', which is the correct policy for H2. All SPAs and SPRs, therefore, MUST decorrelate their master files before using those policies for SPP. Once the policies are decorrelated, there is no longer any ordering requirement on the policies, since only one policy will match any requested communication. The next section describes decorrelation in more detail and presents an algorithm that may be used to implement decorrelation. C.1 Decorrelation Algorithm The basic decorrelation algorithm takes each policy in a correlated set of policies and divides it up into a set of policies using a tree structure. Those of the resulting policies that are decorrelated with the decorrelated set of policies are then added to that decorrelated set. The basic algorithm does not guarantee an optimal set of decorrelated policies. That is, the policies may be broken up into smaller sets than is necessary, though they will still provide all the necessary policy information. Some extensions to the basic algorithm are described later to improve this and improve the performance of the algorithm. C A set of ordered, correlated policies Ci The ith policy in C. U The set of decorrelated policies being built from C Ui The ith policy in U. A policy P may be expressed as a mapping of selector values to actions: Pi = Si1 x Si2 x ... x Sik -> Ai 1) Put C1 in set U as U1 For each policy Cj (j > 1) in C 2) If Cj is decorrelated with every policy in U, then add it to U. 3) If Cj is correlated with one or more policies in U, create a tree rooted at the policy Cj that partitions Cj into a set of decorrelated policies. The algorithm starts with a root node where no selectors have yet been chosen. A) Choose a selector in Cj, Scjn, that has not yet been chosen when traversing the tree from the root to this node. If there are no selectors not yet used, continue to the next unfinished branch until all branches have been completed. When the tree is completed, go to step D. T is the set of policies in U that are correlated with the policy to this node. The policy at this node is the policy formed by the selector values of each of the branches between the root and this node. Any selector values that are not yet represented by branches assume the corresponding selector value in Cj, since the values in Cj represent the maximum value for each selector. B) Add a branch to the tree for each value of the selector Scjn that appears in any of the policies in T. (If the value is a superset of the value of Scjn in Cj, then use the value in Cj, since that value represents the universal set.) Also add a branch for the compliment of the union of all the values of the selector Scjn in T. When taking the compliment, remember that the universal set is the value of Scjn in Cj. A branch need not be created for the nil set. C) Repeat A and B until the tree is completed. D) The policy to each leaf now represents a policy that is a subset of Cj. The policies at the leaves completely partition Cj in such a way that each policy is either completely overridden by a policy in U, or is decorrelated with the policies in U. Add all the decorrelated policies at the leaves of the tree to U. 5) Get next Cj and goto 2. 6) When all policies in C have been processed, then U will contain an decorrelated version of C. There are several optimizations that can be made to this algorithm. A few of them are presented here. It is possible to optimize, or at least improve, the amount of branching that occurs by carefully choosing the order of the selectors used for the next branch. For example, if a selector Scjn can be chosen so that all the values for that selector in T are equal to or a superset of the value of Scjn in Cj, then only a single branch need to be created (since the compliment will be nil). Branches of the tree do not have to proceed with the entire decorrelation algorithm. For example, if a node represents a policy that is decorrelated with all the policies in U, then there is no reason to continue decorrelating that branch. Also, if a branch is completely overridden by a policy in U, then there is no reason to continue decorrelating the branch. An additional optimization is to check to see if a branch is overridden by one of the CORRELATED policies in set C that has already been decorrelated. That is, if the branch is part of decorrelating Cj, then check to see if it was overridden by a policy Cm, m < j. This is a valid check, since all the policies Cm are already expressed in U. Along with checking if a policy is already decorrelated in step 2, check if Cj is overridden by any policy in U. If it is, skip it since it is not relevant. A policy x is overridden by another policy y if every selector in x is equal to or a subset of the corresponding selector in policy y. Appendix A shows an example of applying the algorithm to a set of correlated policies. C.2 Decorrelation Example This appendix section demonstrates the decorrelation algorithm and the optimizations presented on a sample set of policies. We start with the following set of correlated policies, set C: src dst prot sport dport user sec level C1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec C2 199.93/16 199.100.2/24 TCP * * lsanchez conf C3 199.93/16 199.100.2/24 UDP * * lsanchez * C4 199.93/16 199.100.2/24 UDP * 52 * * C5 199.93/16 199.100.2/24 * * * * * C6 * * * * * * * C.2.1 policy C1 We start with policy C1: src dst prot sport dport user sec level C1: 199.93/16 199.100.2/24 TCP * 22 lsanchez sec By step 1 of the algorithm, C1 is put directly into set U as policy U1. The current decorrelated policy set U is: U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec C.2.2 policy C2 Next, we look at policy C2: src dst prot sport dport user sec level C2: 199.93/16 199.100.2/24 TCP * * lsanchez conf C2 is decorrelated with the policies already in U (U1) because the security levels do not overlap. By step 2, C2 is added to U as U2. The current decorrelated policy set U is: U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec U2 199.93/16 199.100.2/24 TCP * * lsanchez conf C.2.3 policy C3 Next, we look at policy C3: src dst prot sport dport user sec level C3: 199.93/16 199.100.2/24 UDP * * lsanchez * C3 is decorrelated with the policies already in U (U1 and U2) because it uses UDP while both policies in U use TCP. By step 2, C3 is added to U as U3. The current decorrelated policy set U is: U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec U2 199.93/16 199.100.2/24 TCP * * lsanchez conf U3 199.93/16 199.100.2/24 UDP * * lsanchez * C.2.4 policy C4 Next, we look at policy C4: src dst prot sport dport user sec level C4: 199.93/16 199.100.2/24 UDP * 52 * * T = {U3} o / \ ~lsanchez / \ (user) lsanchez Policy C4 is correlated with policy U3 in U, so T = {U3}. First we choose to decorrelate the user selector. The policy in T as the value "lsanchez" for this selector, so we create a branch for "lsanchez" and its compliment. The lsanchez branch: 199.93/16 199.100.2/24 UDP * 52 lsanchez * is overriden by the policy U3. The compliment branch: 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * is decorrelated with T since ~lsanchez does not overlap any policies in T. Since this branch is decorrelated, it is added to set U. The current decorrelated policy set U is: U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec U2 199.93/16 199.100.2/24 TCP * * lsanchez conf U3 199.93/16 199.100.2/24 UDP * * lsanchez * U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * C.2.5 policy C5 Next, we look at policy C5: src dst prot sport dport user sec level C5: 199.93/16 199.100.2/24 * * * * * T = U o _______/|\_______ ~UDP,~TCP / | \ (prot) UDP | o T=U3,U4 | TCP |\_________ | | \ | | lsanchez | (user) ~lsanchez T=U1,U2 o o T = U4 / \ (user) / \ ~lsanchez / \ lsanchez ~52 / \ (dport) 52 | T=U1,U2 o _________/|\_________ ~sec,~conf / | \ (sec label) conf | sec | T = U1 o / \ ~22 / \ (dport) 22 Policy C5 is correlated with all the policies currently in U, so T = U. First we choose to decorrelate the protocol selector. The policies in $T$ have the values ``UDP'' and ``TCP'' for this selector, so we create a branch for each of them and a branch for the complement of their union. We can stop processing the complement branch: 199.93/16 199.100.2/24 ~UDP,~TCP * * * * since it is decorrelated with T. This policy will be added to the decorrelated set. The "UDP" and "TCP" branches still require more processing since they are both still correlated with policies in U. We will start by processing the "UDP" branch. The policy through this branch is correlated with policies U3 and U4, so T = {U3, U4}. We choose to decorrelate on the user selector. The policies in T have "lsanchez" and "~lsanchez" as their values for this selector so we create branches for "lsanchez" and "~lsanchez." The compliment branch is redundant to these branches. We can stop processing the "lsanchez" branch: 199.93/16 199.100.2/24 UDP * * lsanchez * since it is overridden by policy U3. The "~lsanchez" branch, however, requires more processing since it is correlated with policy U4 (T = {U4}). We choose to decorrelate on the dport selector. The policy in T has "52" as its value for this selector so we create a "52" branch and a branch for its compliment "~52". We can stop processing the complement branch: 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * since it is decorrelated with T. This policy will be added to the decorrelated set. We can also stop processing the "52" branch: 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * since it is overridden by U4. Now we need to go back and process the "TCP" branch. The policy through this branch is correlated with policies U1 and U2, so T = {U1, U2}. We choose to decorrelate on the user selector. The policies in T have "lsanchez" as their values for this selector so we create branches for "lsanchez" and its compliment, "~lsanchez." We can stop processing the complement branch: 199.93/16 199.100.2/24 TCP * * ~lsanchez * since it is decorrelated with T. This policy will be added to the decorrelated set. The "~lsanchez" branch, however, requires more processing since it is correlated with both policies in T. We choose to decorrelate on the sec label selector. The policies in T have "sec" and "conf" as their values for this selector so we create branches "sec", "conf", and the complement of their union, "~sec,~conf" We can stop processing the complement branch: 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf since it is decorrelated with T. This policy will be added to the decorrelated set. We can stop processing the "conf" branch: 199.93/16 199.100.2/24 TCP * * lsanchez conf since it is overridden by policy U2. The "sec" branch, however, requires more processing since it is correlated with policy U1 (T = U1). We choose to decorrelate on the dport selector. The policy in T has "22" as its value for this selector so we create a "22" branch and a "~22" branch for its compliment. We can stop processing the complement branch: 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec since it is decorrelated with T. This policy will be added to the decorrelated set. We can stop processing the "22" branch: 199.93/16 199.100.2/24 TCP * 22 lsanchez sec since it is overridden by policy U1. The decorrelated policy set after decorrelating C5 is: U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec U2 199.93/16 199.100.2/24 TCP * * lsanchez conf U3 199.93/16 199.100.2/24 UDP * * lsanchez * U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * * U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * U7 199.93/16 199.100.2/24 TCP * * ~lsanchez * U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec C.2.6 policy C6 Finally, we look at policy C6: src dst prot sport dport user sec level C6: * * * * * * * T = U o /| ~199.93/16 / | (src) 199.93/16 T = U o /| ~199.100.2/24 / | (dst) 199.100.2/24 Policy C6 is correlated with all the policies currently in U, so T = U. First we choose to decorrelate the src selector. The policies in $T$ have the value "199.93/16" for this selector, so we create a branch for "199.93/16" and one for its compliment, "~199.93/16". We can stop processing the complement branch: ~199.93/16 * * * * * * since it is decorrelated with all the policies in T. This policy will be added to the decorrelated set. The "199.93/16" branch, however, requires more processing since it is correlated with all the policies in T. We choose to decorrelate on the dst selector. The policies in T have "199.100.2/24" as their value for this selector so we create a "199.100.2/24" branch and a "~199.100.2/24" branch for its compliment. We can stop processing the complement branch: 199.93/16 ~199.100.2/24 * * * * * since it is decorrelated with all the policies in T. This policy will be added to the decorrelated set. We can stop processing the "199.100.2/24" branch: 199.93/16 199.100.2/24 * * * * * since it is overridden by policy C5. The full decorrelated version of C is: U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec U2 199.93/16 199.100.2/24 TCP * * lsanchez conf U3 199.93/16 199.100.2/24 UDP * * lsanchez * U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * * U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * U7 199.93/16 199.100.2/24 TCP * * ~lsanchez * U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec U10 199.93/16 ~199.100.2/24 * * * * * U11 ~199.93/16 * * * * * * From owner-ipsec-policy@mail.vpnc.org Thu Apr 26 09:43:33 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03514 for ; Thu, 26 Apr 2001 09:43:32 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA07163 for ipsec-policy-bks; Thu, 26 Apr 2001 05:41:04 -0700 (PDT) Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA07156 for ; Thu, 26 Apr 2001 05:41:02 -0700 (PDT) Received: (qmail 20024 invoked by uid 20813); 26 Apr 2001 12:41:02 -0000 Date: 26 Apr 2001 12:41:02 -0000 Message-ID: <20010426124102.20023.qmail@squatch.ir.bbn.com> From: Matthew Condell To: ipsec-policy@vpnc.org Subject: Re: a question on SPP draft ... Reply-to: mcondell@bbn.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sami, > Most IPsec/IKE implementations rely on an ordered list of > IPsec policies for policy matching. Is there an efficient > method of converting the decorrelated representation into > an (efficient) ordered list, that only requires 'standard' > selectors (ie no exclusion lists or such)? We don't have an algorithm for converting the decorrelated representation into a correlated version, however, I don't understand why that is necessary. Decorrelated policy rules do not have to be represented using an exclusion list, it's just easier to write it that way when doing it by hand. For example, !10.0.0.0/8 is equivalent to the inclusive list of ranges: 0.0.0.0 - 9.255.255.255, 11.0.0.0 - 255.255.255.255 In terms of searching, a set of decorrelated policies _can_ be used as an ordered list for SPD lookups. It's just a list of policy rules that have the same meaning no matter what order they are in. Does this address your concerns? Matt From owner-ipsec-policy@mail.vpnc.org Thu Apr 26 17:20:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22820 for ; Thu, 26 Apr 2001 17:20:31 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA09595 for ipsec-policy-bks; Thu, 26 Apr 2001 13:08:54 -0700 (PDT) Received: from mailsrv.coronanetworks.com ([38.186.47.7]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA09590 for ; Thu, 26 Apr 2001 13:08:51 -0700 (PDT) Received: by newmail.coronanetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 13:08:42 -0700 Message-ID: From: Murali Narasimha To: ipsec-policy@vpnc.org Cc: Elwin Eliazer Subject: Gateway discovery Date: Thu, 26 Apr 2001 13:08:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CE8C.AC6B7280" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0CE8C.AC6B7280 Content-Type: text/plain; charset="ISO-8859-1" Hi, Can someone please explain me who will discover which gateway in the following scenario and why? (This case is taken from Appendix B of draft-ietf-ipsp-spp-00.txt) admin. boundary admin. boundary ----------------- --------------------------- | | | admin. boundary| | | | ---------------| | Q1 | Q2 | Q3 | || | H1 ---- SG1 ---- (Internet) --- SG2 ---- | SG3 --- H2 || | R3 | | R2 | | R1 | | || | PS1 | | PS2 | PS3 || | | | ---------------| ----------------- --------------------------- ESP Tunnel |=======================| ESP Tunnel |========================================| ESP Transport |================================================| |==| = security association required by policy ---- = connectivity (or if so labeled, administrative boundary) Hx = host x SGx = security gateway x PSx = policy server x Qx = query x Rx = reply x The following entities have these policies for a communication between H1 and H2 for UDP port 79: H1: requires an ESP Transport SA with H2 PS1: requires an ESP Tunnel SA between SG1 and SG2 PS2: requires an ESP Tunnel SA between SG1 and SG2 PS3: requires an ESP Tunnel SA between H1 and SG3 H2: requires an ESP Transport SA with H1 PS1, PS2, PS3 also have policies allowing ESP to pass through their respective Security Gateways. Thanks and regards, Murali ------_=_NextPart_001_01C0CE8C.AC6B7280 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Gateway discovery

Hi,
Can someone please explain me who = will discover which gateway in the following scenario and why?

(This case is taken from Appendix B = of draft-ietf-ipsp-spp-00.txt)

  admin. = boundary          &nbs= p;            = admin. boundary
 -----------------     &= nbsp;          = ---------------------------
 |        = ;       = |            = ;    = |          admin. = boundary|
 |        = ;       = |            = ;    = |          = ---------------|
 |      = Q1       = |       = Q2       |      = Q3  = |            = ; ||
 |  H1 ---- SG1 ---- = (Internet) --- SG2 ---- | SG3 --- H2  ||
 |      R3   = |   |       = R2       |  |   R1  = |  |          = ||
 |        = ;  PS1  = |            = ;    | PS2      | = PS3         ||
 |        = ;       = |            = ;    = |          = ---------------|
 -----------------     &= nbsp;          = ---------------------------
         =             ESP = Tunnel
         =     = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<= /FONT>
         =             ESP = Tunnel
     = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
         =            ESP = Transport
     = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= |

     |=3D=3D| = =3D security association required by policy
     ---- =3D = connectivity (or if so labeled, administrative boundary)
     = Hx   =3D host x
     SGx  = =3D security gateway x
     PSx  = =3D policy server x
     = Qx   =3D query x
     = Rx   =3D reply x

     The = following entities have these policies for a communication
     between = H1 and H2 for UDP port 79:

     H1:  = requires an ESP Transport SA with H2
     PS1: = requires an ESP Tunnel SA between SG1 and SG2
     PS2: = requires an ESP Tunnel SA between SG1 and SG2
     PS3: = requires an ESP Tunnel SA between H1 and SG3
     H2:  = requires an ESP Transport SA with H1

     PS1, PS2, = PS3 also have policies allowing ESP to pass through
     their = respective Security Gateways.

Thanks and regards,
Murali

------_=_NextPart_001_01C0CE8C.AC6B7280-- From owner-ipsec-policy@mail.vpnc.org Thu Apr 26 19:29:56 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24721 for ; Thu, 26 Apr 2001 19:29:55 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA19214 for ipsec-policy-bks; Thu, 26 Apr 2001 15:21:44 -0700 (PDT) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA19209 for ; Thu, 26 Apr 2001 15:21:43 -0700 (PDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id WAA03137; Thu, 26 Apr 2001 22:21:43 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 26 Apr 2001 22:21:43 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 15:21:40 -0700 Message-ID: <794826DE8867D411BAB8009027AE9EB90AD0E64B@FMSMSX38> From: "Jason, Jamie" To: "IPsec Policy (E-mail)" Cc: "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'wes@hardakers.net'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" , "Eric Vyncke (E-mail)" Subject: Conference Call Date: Thu, 26 Apr 2001 15:21:38 -0700 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: The authors of the IPsec Policy Configuration Model would like to have a conference call to work out issues that were brought up during the IPSP WG meeting in Minneapolis. The conference call will be on Thursday, May 2 at 8:00 PDT. It is expected that the people in the cc: list will be the ones most interested in participating, but it is open to the entire WG. If you would like to participate, please email me directly so I can get a count for when I shedule the conference call through our local IT group. I'll post details about the call when I get them...unfortunately, I don't think that our conference calls are toll-free. Jamie ---------------------------------------------------------------- Jamie Jason email: jamie.jason@intel.com Intel Architecture Labs phone: 503-264-9531 2111 NE 25th Avenue fax: 503-264-9428 Hillsboro, OR 97124 "To give anything less than your best is to sacrifice the gift." - Steve Prefontaine All opinions expressed are: 1. Entirely my own. 2. Not necessarily shared by my employer. 3. Unencumbered by the thought process. ---------------------------------------------------------------- From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 03:53:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18374 for ; Fri, 27 Apr 2001 03:53:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA14108 for ipsec-policy-bks; Thu, 26 Apr 2001 23:35:42 -0700 (PDT) Received: from ns2.iaf.fi (root@ns2.iaf.fi [195.94.103.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA14098 for ; Thu, 26 Apr 2001 23:35:39 -0700 (PDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f3R6WuC08175; Fri, 27 Apr 2001 09:33:27 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id IAA30739; Fri, 27 Apr 2001 08:37:02 +0300] Message-ID: <000b01c0cee4$5bb35a80$3f02a8c0@garibaldi> From: "Sami Vaarala" To: , References: <20010426124102.20023.qmail@squatch.ir.bbn.com> Subject: Re: a question on SPP draft ... Date: Fri, 27 Apr 2001 09:36:13 +0300 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 Matthew, > > Most IPsec/IKE implementations rely on an ordered list of > > IPsec policies for policy matching. Is there an efficient > > method of converting the decorrelated representation into > > an (efficient) ordered list, that only requires 'standard' > > selectors (ie no exclusion lists or such)? > > We don't have an algorithm for converting the decorrelated > representation into a correlated version, however, I don't understand > why that is necessary. Decorrelated policy rules do not have to be > represented using an exclusion list, it's just easier to write it that > way when doing it by hand. For example, !10.0.0.0/8 is equivalent to > the inclusive list of ranges: > 0.0.0.0 - 9.255.255.255, 11.0.0.0 - 255.255.255.255 > > In terms of searching, a set of decorrelated policies _can_ be used as > an ordered list for SPD lookups. It's just a list of policy rules that > have the same meaning no matter what order they are in. I realize this, but this would seem to be less efficient than checking against an ordered list. Or am I mistaken? Eg. the correlated, ordered list: 1. 10.0.0.0/8 -> 10.0.0.0/8 2. 0.0.0.0/0 (catch all) turns into the decorrelated 1. 10.0.0.0/8 -> 10.0.0.0/8 2. 0.0.0.0-9.255.255.255 OR 11.0.0.0-255.255.255.255 If I am using the decorrelated version and I have already checked step 1, the range checking is redundant. I would like to optimize this redundancy from the policy checking that is actually used. In addition, when doing an IKE negotiation to establish SAs that these policies require, the correlated (2) is negotiable whereas the decorrelated (2) is not (IKE does not, currently, support unions of ranges for instance). IKE will be undergoing changes in the near future, but from what I understood from the WG charter, the work should be in line with the current IPsec RFCs. -S From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 10:15:40 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00617 for ; Fri, 27 Apr 2001 10:15:37 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA17118 for ipsec-policy-bks; Fri, 27 Apr 2001 05:25:58 -0700 (PDT) Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA17114 for ; Fri, 27 Apr 2001 05:25:56 -0700 (PDT) Received: (qmail 3223 invoked by uid 20813); 27 Apr 2001 12:25:37 -0000 Date: 27 Apr 2001 12:25:37 -0000 Message-ID: <20010427122537.3222.qmail@squatch.ir.bbn.com> From: Matthew Condell To: ipsec-policy@vpnc.org Subject: Re: a question on SPP draft ... Reply-to: mcondell@bbn.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sami, > I realize this, but this would seem to be less efficient than checking > against an ordered list. Or am I mistaken? Well, yes and no. If you linearly search a decorrelated list of policy rules, on average it will be less efficient since there will be a larger list of more complex policies to search. No argument there. However, there are at least two things you need to also consider when looking at efficiency here. 1) Searching no longer has to be linear. You can attempt to optimize your searches. For example, you can keep a cache of the most recently used policies, or move the most often used policies to the top of the list. Since they are decorrelated, these (and I'm sure other) techniques can be utilized to speed up searching. 2) The process of setting up an end-to-end communication is much more than just looking up SPD entries. Decorrelation was introduced into SPP to enable caching of policies from other policy servers, since the policy exchange and resolution process is fairly expensive. I don't have numbers to show that decorrelation is worthwhile system-wide from an efficiency standpoint, but the benefit of being able to cache policies for resolution seem to intuitively make a big difference. > Eg. the correlated, ordered list: > 1. 10.0.0.0/8 -> 10.0.0.0/8 > 2. 0.0.0.0/0 (catch all) > > turns into the decorrelated > 1. 10.0.0.0/8 -> 10.0.0.0/8 > 2. 0.0.0.0-9.255.255.255 OR 11.0.0.0-255.255.255.255 > > If I am using the decorrelated version and I have already checked step > 1, the range checking is redundant. I would like to optimize this > redundancy from the policy checking that is actually used. > > In addition, when doing an IKE negotiation to establish SAs that > these policies require, the correlated (2) is negotiable whereas > the decorrelated (2) is not (IKE does not, currently, support > unions of ranges for instance). The decorrelated rule (2) can be broken into two rules that can be negotiated: 2. 0.0.0.0-9.255.255.255 3. 11.0.0.0-255.255.255.255 Besides, negotiating ranges with correlated policy rules in IKE can encounter the same dangers as caching correlated policies in SPP, so it's much safer to negotiate decorrelated policies in IKE. Matt From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 10:26:02 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01234 for ; Fri, 27 Apr 2001 10:26:01 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA19147 for ipsec-policy-bks; Fri, 27 Apr 2001 06:10:13 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA19141 for ; Fri, 27 Apr 2001 06:10:11 -0700 (PDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id JAA04985; Fri, 27 Apr 2001 09:09:36 -0400 Received: from rftzy232.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 27 Apr 2001 09:09:21 -0400 Received: from nortelnetworks.com (acart12f.ca.nortel.com [47.129.8.125]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHXCMXL9; Fri, 27 Apr 2001 09:05:55 -0400 Message-ID: <3AE96FA6.3B5B2695@nortelnetworks.com> Date: Fri, 27 Apr 2001 09:09:58 -0400 From: "Marcus Leech" Organization: Nortel Networks: Information Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Jason, Jamie" CC: ipsec-policy@vpnc.org Subject: Re: Conference Call References: <794826DE8867D411BAB8009027AE9EB90AD0E64B@FMSMSX38> 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 "Jason, Jamie" wrote: > > The authors of the IPsec Policy Configuration Model would like to have a > conference call to work out issues that were brought up during the IPSP WG > meeting in Minneapolis. The conference call will be on Thursday, May 2 at > 8:00 PDT. It is expected that the people in the cc: list will be the ones > most interested in participating, but it is open to the entire WG. If you > would like to participate, please email me directly so I can get a count for > when I shedule the conference call through our local IT group. I'll post > details about the call when I get them...unfortunately, I don't think that > our conference calls are toll-free. > > Jamie > Jamie: This counts as an offical "interim meeting", and as such is subject to some IETF procedural things--including more notice, I believe. I'll have to check and get back to you. From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 10:31:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01736 for ; Fri, 27 Apr 2001 10:31:50 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA20499 for ipsec-policy-bks; Fri, 27 Apr 2001 06:24:31 -0700 (PDT) Received: from fnord.ir.bbn.com (FNORD.IR.BBN.COM [192.1.100.210]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA20492 for ; Fri, 27 Apr 2001 06:24:30 -0700 (PDT) Received: (qmail 80750 invoked by uid 10853); 27 Apr 2001 13:24:31 -0000 To: "Sami Vaarala" Cc: , Subject: Re: a question on SPP draft ... References: <20010426124102.20023.qmail@squatch.ir.bbn.com> <000b01c0cee4$5bb35a80$3f02a8c0@garibaldi> From: Greg Troxel Date: 27 Apr 2001 09:24:30 -0400 In-Reply-To: "Sami Vaarala"'s message of "Fri, 27 Apr 2001 09:36:13 +0300" Message-ID: Lines: 39 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I realize this, but this would seem to be less efficient than checking against an ordered list. Or am I mistaken? Eg. the correlated, ordered list: 1. 10.0.0.0/8 -> 10.0.0.0/8 2. 0.0.0.0/0 (catch all) turns into the decorrelated 1. 10.0.0.0/8 -> 10.0.0.0/8 2. 0.0.0.0-9.255.255.255 OR 11.0.0.0-255.255.255.255 For a list of size two, you are arguably correct, but the CPU time for such a small list is unlikely to matter. For an ordered list with n entries, the search time is \theta(n). With a decorrelated SPD, one can use tree search algorithms, which should operate in log time. Note that a given ordered SPD may result in more decorrelated entries (2 to 3, above), so this broad linear-vs-log claim is somehat unfair and I don't claim to have fully substantiated the point I'm making. That said, if one has hardware that searches ordered SPDs efficiently, it might be useful to have a "recorrelation" algorithm. The decorrelated example above has many possible recorrelated examples, including the original, but also (dropping the RHS): 1. 0.0.0.0/5 2. 8.0.0.0/7 3. 10.0.0.0/8 4. 11.0.0.0/8 5. 12.0.0.0/6 6. 16.0.0.0/4 7. 32.0.0.0/3 8. 64.0.0.0/2 9. 128.0.0.0/1 This recorrelation doesn't appear useful; the needed approach is probably to identify ranges that if pulled out allow coalescing of larger blocks. Greg Troxel From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 11:05:30 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03734 for ; Fri, 27 Apr 2001 11:05:29 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA23742 for ipsec-policy-bks; Fri, 27 Apr 2001 07:02:06 -0700 (PDT) Received: from ns2.iaf.fi (root@ns2.iaf.fi [195.94.103.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA23733 for ; Fri, 27 Apr 2001 07:02:04 -0700 (PDT) Received: from proxyfw.netseal.com (gw.netseal.com [195.94.100.110]) by ns2.iaf.fi (8.11.2/8.11.2) with ESMTP id f3RDxrC15591; Fri, 27 Apr 2001 16:59:53 +0300 Received: from (Undisclosed Firewall protected host) by Baudia Firewall with SMTP id QAA31888; Fri, 27 Apr 2001 16:04:00 +0300] Message-ID: <000f01c0cf22$cc57aeb0$3f02a8c0@garibaldi> From: "Sami Vaarala" To: "Greg Troxel" Cc: , References: <20010426124102.20023.qmail@squatch.ir.bbn.com> <000b01c0cee4$5bb35a80$3f02a8c0@garibaldi> Subject: Re: a question on SPP draft ... Date: Fri, 27 Apr 2001 17:03:12 +0300 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 Greg, > I realize this, but this would seem to be less efficient than checking > against an ordered list. Or am I mistaken? > > Eg. the correlated, ordered list: > 1. 10.0.0.0/8 -> 10.0.0.0/8 > 2. 0.0.0.0/0 (catch all) > > turns into the decorrelated > 1. 10.0.0.0/8 -> 10.0.0.0/8 > 2. 0.0.0.0-9.255.255.255 OR 11.0.0.0-255.255.255.255 > > For a list of size two, you are arguably correct, but the CPU time for > such a small list is unlikely to matter. For an ordered list with n > entries, the search time is \theta(n). With a decorrelated SPD, one > can use tree search algorithms, which should operate in log time. > Note that a given ordered SPD may result in more decorrelated entries > (2 to 3, above), so this broad linear-vs-log claim is somehat unfair > and I don't claim to have fully substantiated the point I'm making. You are right, the decorrelated representation does have several advantages, and I think it is a valuable concept in many ways. > That said, if one has hardware that searches ordered SPDs efficiently, > it might be useful to have a "recorrelation" algorithm. The > decorrelated example above has many possible recorrelated examples, > including the original, but also (dropping the RHS): [snip] This is actually the point I am more concerned about. For IPsec without IKE, the fact that there are several recorrelated ordered policies is not a problem. However, with IKE in the picture things get more complicated, since IKE also negotiates traffic selectors, and does not only compare the selectors of a single packet. For instance, an offer for protecting 0.0.0.0/0 using a tunnel mode is accepted by the ordered policy (supposing the action is to use tunnel mode, etc). For the decorrelated (and differently recorrelated) examples this is not so simple. How should this work? -Sami From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 11:27:59 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05034 for ; Fri, 27 Apr 2001 11:27:59 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA25387 for ipsec-policy-bks; Fri, 27 Apr 2001 07:33:17 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA25378 for ; Fri, 27 Apr 2001 07:33:11 -0700 (PDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA16344; Fri, 27 Apr 2001 10:32:38 -0400 Received: from rftzy232.ca.nortel.com by zcars04e.nortelnetworks.com; Fri, 27 Apr 2001 10:32:34 -0400 Received: from nortelnetworks.com (47.129.9.115 [47.129.9.115]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHXCMXV1; Fri, 27 Apr 2001 10:29:08 -0400 Message-ID: <3AE9833B.D46234D7@nortelnetworks.com> Date: Fri, 27 Apr 2001 10:33:31 -0400 From: "Marcus Leech" Organization: Nortel Networks: Information Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy@vpnc.org Subject: Conference call 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 Please refer to: http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 13:08:37 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08764 for ; Fri, 27 Apr 2001 13:08:34 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA04930 for ipsec-policy-bks; Fri, 27 Apr 2001 08:57:25 -0700 (PDT) Received: from h0001027441c5.ne.mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA04925 for ; Fri, 27 Apr 2001 08:57:22 -0700 (PDT) Received: from europa-h0001027441c5.ne.mediaone.net ([192.168.20.40]) by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id MAA23418; Fri, 27 Apr 2001 12:01:06 -0400 Received: from jdscons.com (localhost [127.0.0.1]) by europa-h0001027441c5.ne.mediaone.net (8.9.3+Sun/8.9.3) with ESMTP id LAA28914; Fri, 27 Apr 2001 11:56:17 -0400 (EDT) Message-Id: <200104271556.LAA28914@europa-h0001027441c5.ne.mediaone.net> To: "Marcus Leech" cc: "Jason, Jamie" , ipsec-policy@vpnc.org Subject: Re: Conference Call From: Jon Saperia In-reply-to: Your message of Fri, 27 Apr 2001 09:09:58 -0400. <3AE96FA6.3B5B2695@nortelnetworks.com> Date: Fri, 27 Apr 2001 11:56:17 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My take is that this is far from an IETF Interim Meeting. This is an editors meeting. These and design team meetings are accepted and permitted - at least on my past experience and reading 2418. Of course what comes out needs to be on the WG list, etc. /jon > "Jason, Jamie" wrote: > > > > The authors of the IPsec Policy Configuration Model would like to have a > > conference call to work out issues that were brought up during the IPSP WG > > meeting in Minneapolis. The conference call will be on Thursday, May 2 at > > 8:00 PDT. It is expected that the people in the cc: list will be the ones > > most interested in participating, but it is open to the entire WG. If you > > would like to participate, please email me directly so I can get a count for > > when I shedule the conference call through our local IT group. I'll post > > details about the call when I get them...unfortunately, I don't think that > > our conference calls are toll-free. > > > > Jamie > > > Jamie: > > This counts as an offical "interim meeting", and as such is subject to > some > IETF procedural things--including more notice, I believe. I'll have > to check > and get back to you. Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 15:08:13 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11526 for ; Fri, 27 Apr 2001 15:08:12 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA10446 for ipsec-policy-bks; Fri, 27 Apr 2001 10:40:34 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA10441 for ; Fri, 27 Apr 2001 10:40:32 -0700 (PDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 27 Apr 2001 11:40:09 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 27 Apr 2001 11:40:00 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: Conference Call 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 above.proper.com id KAA10443 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks for the announcement of the design team meeting; you are cleared for takeoff. If you get a large group signing up, let the chairs know and we'll consider scheduling on interim WG meeting in June. Hilarie >>> Jon Saperia 04/27/01 09:56AM >>> My take is that this is far from an IETF Interim Meeting. This is an editors meeting. These and design team meetings are accepted and permitted - at least on my past experience and reading 2418. Of course what comes out needs to be on the WG list, etc. /jon > "Jason, Jamie" wrote: > > > > The authors of the IPsec Policy Configuration Model would like to have a > > conference call to work out issues that were brought up during the IPSP WG > > meeting in Minneapolis. The conference call will be on Thursday, May 2 at > > 8:00 PDT. It is expected that the people in the cc: list will be the ones > > most interested in participating, but it is open to the entire WG. If you > > would like to participate, please email me directly so I can get a count for > > when I shedule the conference call through our local IT group. I'll post > > details about the call when I get them...unfortunately, I don't think that > > our conference calls are toll-free. > > > > Jamie > > > Jamie: > > This counts as an offical "interim meeting", and as such is subject to > some > IETF procedural things--including more notice, I believe. I'll have > to check > and get back to you. Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-ipsec-policy@mail.vpnc.org Fri Apr 27 19:52:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20072 for ; Fri, 27 Apr 2001 19:52:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA26346 for ipsec-policy-bks; Fri, 27 Apr 2001 15:17:15 -0700 (PDT) Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA26342 for ; Fri, 27 Apr 2001 15:17:13 -0700 (PDT) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id PAA01394; Fri, 27 Apr 2001 15:16:59 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: "Jason, Jamie" Cc: "IPsec Policy (E-mail)" , "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" , "Eric Vyncke (E-mail)" Subject: Re: Conference Call References: <794826DE8867D411BAB8009027AE9EB90AD0E64B@FMSMSX38> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 27 Apr 2001 15:16:59 -0700 In-Reply-To: <794826DE8867D411BAB8009027AE9EB90AD0E64B@FMSMSX38> ("Jason, Jamie"'s message of "Thu, 26 Apr 2001 15:21:38 -0700") Message-ID: Lines: 20 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) 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: >>>>> On Thu, 26 Apr 2001 15:21:38 -0700, "Jason, Jamie" said: Jamie> The authors of the IPsec Policy Configuration Model would like Jamie> to have a conference call to work out issues that were brought Jamie> up during the IPSP WG meeting in Minneapolis. The conference Jamie> call will be on Thursday, May 2 at 8:00 PDT. It is expected Jamie> that the people in the cc: list will be the ones most Jamie> interested in participating, but it is open to the entire WG. Jamie> If you would like to participate, please email me directly so I Jamie> can get a count for when I shedule the conference call through Jamie> our local IT group. I'll post details about the call when I Jamie> get them...unfortunately, I don't think that our conference Jamie> calls are toll-free. I think that it would be good to have an agenda to help decide whether this was a good thing to call in for or not. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec-policy@mail.vpnc.org Sun Apr 29 09:14:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09254 for ; Sun, 29 Apr 2001 09:14:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA28999 for ipsec-policy-bks; Sun, 29 Apr 2001 05:15:40 -0700 (PDT) Received: from h0001027441c5.ne.mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA28995 for ; Sun, 29 Apr 2001 05:15:33 -0700 (PDT) Received: from europa-h0001027441c5.ne.mediaone.net ([192.168.20.40]) by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id IAA32102 for ; Sun, 29 Apr 2001 08:19:30 -0400 Received: from jdscons.com (localhost [127.0.0.1]) by europa-h0001027441c5.ne.mediaone.net (8.9.3+Sun/8.9.3) with ESMTP id IAA03138; Sun, 29 Apr 2001 08:13:32 -0400 (EDT) Message-Id: <200104291213.IAA03138@europa-h0001027441c5.ne.mediaone.net> To: Wes Hardaker cc: "Jason, Jamie" , "IPsec Policy (E-mail)" , "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" , "Eric Vyncke (E-mail)" Subject: Re: Conference Call From: Jon Saperia In-reply-to: Your message of 27 Apr 2001 15:16:59 -0700. Date: Sun, 29 Apr 2001 08:13:32 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think that it would be good to have an agenda to help decide whether > this was a good thing to call in for or not. > -- > Wes Hardaker > NAI Labs > Network Associates Always a good idea. Given that I have not done (yet) at least on of the things I was assigned, one suggestion for an agenda topic would be a discussion of the open issues and how we are proposing to resolve them. My example is NOTIFICATIONS. They are obviously tied to the rest of the Module structure. Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-ipsec-policy@mail.vpnc.org Sun Apr 29 18:56:12 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12201 for ; Sun, 29 Apr 2001 18:56:11 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA06375 for ipsec-policy-bks; Sun, 29 Apr 2001 15:04:05 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA06370 for ; Sun, 29 Apr 2001 15:04:03 -0700 (PDT) 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 AAA22609; Mon, 30 Apr 2001 00:03:30 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010429235528.03f1bc00@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Apr 2001 00:04:05 +0200 To: "Jason, Jamie" From: Eric Vyncke Subject: Re: Conference Call Cc: "IPsec Policy (E-mail)" , "'rcharlet@redcreek.com'" , "'HORMAN@volera.com'" , "'wes@hardakers.net'" , "'Man.M.Li@nokia.com'" , "'lsanchez@megisto.com'" , "Lee Rafalow (E-mail)" In-Reply-To: <794826DE8867D411BAB8009027AE9EB90AD0E64B@FMSMSX38> 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: Jamie, Is it Wednesday May 2nd (then I cannot attend) or Thursday May 3rd (then I can attend) ? I do appreciate the timing which is convenient for Europe ;-) Regarding the agenda, I guess it will be for the open points: - use of granularity (the authors want to keep it like it is in -02 for simplicity sake) - multiple actions: is it needed ? is it useful ? how to implement it ? (the authors have a current proposal that should be checked by the WG) - use of filters for dynamic ports negotiation (the authorq want to keep it like it is in -02 for simplicity sake and for RFC 2401 & Co compliance) - ... Regards -eric At 15:21 26/04/2001 -0700, Jason, Jamie wrote: >The authors of the IPsec Policy Configuration Model would like to have a >conference call to work out issues that were brought up during the IPSP WG >meeting in Minneapolis. The conference call will be on Thursday, May 2 at >8:00 PDT. It is expected that the people in the cc: list will be the ones >most interested in participating, but it is open to the entire WG. If you >would like to participate, please email me directly so I can get a count for >when I shedule the conference call through our local IT group. I'll post >details about the call when I get them...unfortunately, I don't think that >our conference calls are toll-free. > >Jamie > >---------------------------------------------------------------- >Jamie Jason email: jamie.jason@intel.com >Intel Architecture Labs phone: 503-264-9531 >2111 NE 25th Avenue fax: 503-264-9428 >Hillsboro, OR 97124 > >"To give anything less than your best is to sacrifice the gift." > - Steve Prefontaine > >All opinions expressed are: >1. Entirely my own. >2. Not necessarily shared by my employer. >3. Unencumbered by the thought process. >----------------------------------------------------------------