From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 09:34:36 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18115 for ; Tue, 2 Jan 2001 09:34:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA22569 for ipsec-policy-bks; Tue, 2 Jan 2001 05:22:56 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22562 for ; Tue, 2 Jan 2001 05:22:54 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA28214; Tue, 2 Jan 2001 08:26:10 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA24824; Tue, 2 Jan 2001 08:26:11 -0500 Message-ID: <000d01c074bf$585f73c0$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: Cc: References: <3A4BBAA4.7ABAFBB7@redcreek.com> Subject: Re: comments on ICPM IPProtocolEndpoint Date: Tue, 2 Jan 2001 08:24:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ricky, I'm not sure I understand the problem so let me try to explain the relationships in the model. The IKEServiceForEndpoint association identifies the IPProtocolEndpoints (local IP addresses, could be real or virtual interfaces) for which an IKE service provides negotiation services. (The IPProtocolEndpoint class only represents local addresses, remote addresses are represented in the conditions/filters of the policy.) Those same local IPProtocolEndpoint instances will have SAs (SecurityAssociationBindsTo) that protect traffic on the endpoints. Does that help or are we missing something? Cheers, Lee ----- Original Message ----- From: "Ricky Charlet" To: ".MailList - ipsec-policy" Sent: Thursday, December 28, 2000 5:11 PM Subject: comments on ICPM IPProtocolEndpoint > Howdy, > > I have a question about IPProtocolEndpoints. From reading the DMTF > white paper on IPsec Policy Model, it implies that IPProtocolEndpoints > serve two roles. They are the interfaes which are IKE enabled, and they > are the entities which will ultimatly be protected. I hope I'm just > reading the model wrong. Because Secruity Gateways need to (of course) > represent endpoints for protection which likely will not be the same as > the Secruity Gatway's IKE enabled interface. > > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 10:30:23 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18812 for ; Tue, 2 Jan 2001 10:30:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA25588 for ipsec-policy-bks; Tue, 2 Jan 2001 06:16:15 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25584 for ; Tue, 2 Jan 2001 06:16:14 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA29214; Tue, 2 Jan 2001 09:19:30 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA31366; Tue, 2 Jan 2001 09:19:32 -0500 Message-ID: <001c01c074c6$cb789d80$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: Cc: References: <3A4BCA57.8870F370@redcreek.com> Subject: Re: comments on ICPM IPsecTunnelAction and their peers Date: Tue, 2 Jan 2001 09:17:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It is a bit convoluted, I admit; our intent was to promote orthogonal class definitions. 1. When the tunnel action is used in a gateway, there may not be an address because the peer may be the same as the destination. In those cases the packet and the condition identify the peer and the configuration burden is reduced by using that information. 2. More generally, the policy action is applicable beyond the specific endpoint for which it is used. That is, the device policy is derived from some more general policy in which the gateway is a free or constrained variable but not specified; the PDP adds the gateway information for use by the PEP (device). 3. The PeerGateway is identified by its identity rather than address because there are several ways to get the address; the PeerIdentityTable provides one mechanism. When we get to implementations of the model, we may want to bias the design more toward efficiency of the representation. I hope this helps. Cheers, Lee ----- Original Message ----- From: "Ricky Charlet" To: ".MailList - ipsec-policy" Sent: Thursday, December 28, 2000 6:18 PM Subject: comments on ICPM IPsecTunnelAction and their peers > Howdy, > > Identifying the peer for an IPsecTunnelAction seems overly complex to > me. Why not just configure the IP address of the peer right in the > IPsecTunnelAction as a parameter? What are the reasons behind the > multiple table references to PeerIdentityTable and IkeIdentity and such? > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 13:07:50 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20723 for ; Tue, 2 Jan 2001 13:07:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09901 for ipsec-policy-bks; Tue, 2 Jan 2001 09:08:21 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09896 for ; Tue, 2 Jan 2001 09:08:20 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 09:12:12 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y97PMV1C; Tue, 2 Jan 2001 09:12:06 -0800 From: Ricky Charlet To: Lee Rafalow Cc: ipsec-policy@vpnc.org, wg-network@dmtf.org Message-ID: <3A51FEFF.B1193E4C@redcreek.com> Date: Tue, 02 Jan 2001 09:17:04 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: comments on ICPM IPProtocolEndpoint References: <3A4BBAA4.7ABAFBB7@redcreek.com> <000d01c074bf$585f73c0$81302509@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: > > Ricky, I'm not sure I understand the problem so let me try to explain the > relationships in the model. > > The IKEServiceForEndpoint association identifies the IPProtocolEndpoints > (local IP addresses, could be real or virtual interfaces) for which an IKE > service provides negotiation services. (The IPProtocolEndpoint class only > represents local addresses, remote addresses are represented in the > conditions/filters of the policy.) Those same local IPProtocolEndpoint > instances will have SAs (SecurityAssociationBindsTo) that protect traffic on > the endpoints. > > Does that help or are we missing something? Cheers, Lee > Howdy, I get the feeling from your answer that you are describing a situation where a host is running its own IPsec service. I am asking a question about the situation where a group of hosts are protected by a security gateway running IPsec. -------- | Host A | | | |---| ------- | -------- | ------- ------- | Host B | |----| SGW 1 |--- INTERNET ----| SGW 2 |--- subnet 2 | |---| ------- ------- ------- | -------- | | Host C | | | |---| ------- | | subnet 1 In this picture, SGW1 is protecting all of subnet1 on its left interface and is runnig IKE (peering with SGW2) on its right interface. My confusion with the DMTF model for representing policy is this: it implies that IPProtocolEndpoints on SGW1 will be the left and right interfaces only AND that these endpoints can be the ONLY endpoints being protected by an IPsec Policy. But here we would wish that the whole of subnet1 be protected by an IPsec Policy. In general, IPsec protected endpoints are defined by the IPsec selectors and do not have to be IP addresses hosted by 'this' system. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 14:22:49 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21756 for ; Tue, 2 Jan 2001 14:22:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11754 for ipsec-policy-bks; Tue, 2 Jan 2001 10:04:27 -0800 (PST) Received: from mail9.wlv.netzero.net (mail9.wlv.netzero.net [209.247.163.66]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA11750 for ; Tue, 2 Jan 2001 10:04:26 -0800 (PST) Received: (qmail 22529 invoked from network); 2 Jan 2001 18:08:27 -0000 Received: from pppa47-resaleraleigh5-1r7079.dialinx.net (HELO casey) (4.4.158.76) by mail9.wlv.netzero.net with SMTP; 2 Jan 2001 18:08:27 -0000 Reply-To: From: "Casey Carr" To: Subject: Intended use of SAStaticAction Class Date: Tue, 2 Jan 2001 13:05:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I would like some guidance on the intended use of SAStaticAction classes. The intended use of these classes does not appear to be as well described in "draft-ietf-ipsp-config-policy-model-01.txt" as the SANegotiatedAction classes. My question is with regard to the SAStaticAction classes associated with SARule classes. The IPSecRule and IKERule are explicitly shown as composited associations contained by the IPSecPolicyGroup. That is to say that instances of the SANegotiatedRule class can be contained in one and only one PolicyGroup. However, there is no equivalent class for static rules (i.e. SAStaticRule). Therefore, to associated a Rule with an SAStaticAction we must rely on the more generic PolicyRule. This association does not explicitly state that a PolicyRule can be with one and only one PolicyGroup. If I we are to implement this model as stated, I believe I am required to allow PolicyRules to be associated with more than one PolicyGroup. I would be required to do this just to support associations of SAStaticAction classes with rules. This seems to be exactly opposite what was intended for the SANegotiatedRules. Is this the intent or am I missing something? I would propose the following relationship be added to the model. This seems to me more in line with the intended associations between SARule classes and IPSecPolicyGroup classes. I added the SAStaticRule class and a composite association with IPSecPolicyGroup. Thanks for your consideration. Casey Shop Safely Online Without a Credit Card http://www.rocketcash.com From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 14:28:10 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21862 for ; Tue, 2 Jan 2001 14:28:09 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA13355 for ipsec-policy-bks; Tue, 2 Jan 2001 10:20:37 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13349 for ; Tue, 2 Jan 2001 10:20:36 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA18964; Tue, 2 Jan 2001 13:23:53 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA07084; Tue, 2 Jan 2001 13:23:55 -0500 Message-ID: <00a101c074e8$e050cbc0$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: Cc: References: <3A4BBAA4.7ABAFBB7@redcreek.com> <000d01c074bf$585f73c0$81302509@raleigh.ibm.com> <3A51FEFF.B1193E4C@redcreek.com> Subject: Re: comments on ICPM IPProtocolEndpoint Date: Tue, 2 Jan 2001 13:21:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ricky, The IPProtocolEndpoint class is only used to represent the local addresses. So, in your picture, yes, the left and right interfaces on SGW1 would be represented in the SGW1 implementation of the model as IPProtocolEndpoint instances. In SGW1, the hosts on subnet 1, are not directly represented; instead they are represented as a part of the packet classification in the conditions (i.e., filters in the current model) as sources and/or destinations for traffic. Regardless of whether the hosts are running their own IKE services or not, the application of the rules in SGW1 is specified in the conditions/filters by subnet addresses, address ranges, specific host address, FQDNs, IDs, credential management authority trust hierarchies, etc. and/or combinations thereof. So, to clear up what I think is a little terminology problem, what we mean when we say "Each SecurityAssociation object instance is scoped by the IPProtocolEndpoint for which it provides protection" is that the SA (in SWG1) is protecting traffic on the local address represented by the IPProtocolEndpoint instance. The fact that the traffic source/sink on subnet 1 is being "protected" by a tunnel between SGW1 and SGW2 is also true but not our use of the term in this context. Sorry for the confusion. If you can suggest some better words, we'll be happy to make updates. Cheers, Lee ----- Original Message ----- From: "Ricky Charlet" To: "Lee Rafalow" Cc: ; Sent: Tuesday, January 02, 2001 11:17 AM Subject: Re: comments on ICPM IPProtocolEndpoint > Lee Rafalow wrote: > > > > Ricky, I'm not sure I understand the problem so let me try to explain the > > relationships in the model. > > > > The IKEServiceForEndpoint association identifies the IPProtocolEndpoints > > (local IP addresses, could be real or virtual interfaces) for which an IKE > > service provides negotiation services. (The IPProtocolEndpoint class only > > represents local addresses, remote addresses are represented in the > > conditions/filters of the policy.) Those same local IPProtocolEndpoint > > instances will have SAs (SecurityAssociationBindsTo) that protect traffic on > > the endpoints. > > > > Does that help or are we missing something? Cheers, Lee > > > > > Howdy, > > I get the feeling from your answer that you are describing a situation > where a host is running its own IPsec service. I am asking a question > about the situation where a group of hosts are protected by a security > gateway running IPsec. > > -------- > | Host A | | > | |---| > ------- | > -------- | ------- ------- > | Host B | |----| SGW 1 |--- INTERNET ----| SGW 2 |--- subnet 2 > | |---| ------- ------- > ------- | > -------- | > | Host C | | > | |---| > ------- | > | > subnet 1 > > In this picture, SGW1 is protecting all of subnet1 on its left > interface and is runnig IKE (peering with SGW2) on its right interface. > > My confusion with the DMTF model for representing policy is this: it > implies that IPProtocolEndpoints on SGW1 will be the left and right > interfaces only AND that these endpoints can be the ONLY endpoints being > protected by an IPsec Policy. But here we would wish that the whole of > subnet1 be protected by an IPsec Policy. > > In general, IPsec protected endpoints are defined by the IPsec > selectors and do not have to be IP addresses hosted by 'this' system. > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 17:24:41 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23391 for ; Tue, 2 Jan 2001 17:24:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA26662 for ipsec-policy-bks; Tue, 2 Jan 2001 13:21:41 -0800 (PST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26658 for ; Tue, 2 Jan 2001 13:21:40 -0800 (PST) Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 2 Jan 2001 16:23:16 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id ZNHK6VX4; Tue, 2 Jan 2001 16:23:24 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MJ1L; Tue, 2 Jan 2001 16:23:20 -0500 Message-ID: <3A52478D.6F6E40A6@americasm01.nt.com> Date: Tue, 02 Jan 2001 16:26:37 -0500 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy Subject: Re: My presentation @ the WG References: <3A4139F3.3D2FD1DE@americasm01.nt.com> 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 The previous link was unreadable to some computers. I uploaded the presentation again using different formats: ftp://standards.nortelnetworks.com/IPSP/ipsp-Dec11-2000.ZIP ftp://standards.nortelnetworks.com/IPSP/ipsp-Dec11-2000.ppt Please let me know if you have a problem reading it. and thanks to those who brought it up. Abdallah "Rayhan, Abdallah [CAR:5N10:EXCH]" wrote: > > I have uploaded my presentation to: > ftp://standards.nortelnetworks.com/IPSP/ipsp-Dec11-2000.ppt.gz > > regards > Abdallah From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 17:59:42 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23812 for ; Tue, 2 Jan 2001 17:59:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA29110 for ipsec-policy-bks; Tue, 2 Jan 2001 13:56:23 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29104 for ; Tue, 2 Jan 2001 13:56:21 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA28584; Tue, 2 Jan 2001 17:00:10 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA12956; Tue, 2 Jan 2001 17:00:13 -0500 Message-ID: <00d601c07506$ee02fa40$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: Cc: References: Subject: Re: Intended use of SAStaticAction Class Date: Tue, 2 Jan 2001 16:56:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Casey, I haven't looked at the 01 draft in a while but I think you're misreading it. Jamie is working on updating it, until then you might want to take a look at http://rafalow.home.mindspring.com/dmtf.htm for the preliminary, pre-publication dmtf standard that is being developed in parallel with the IPSP WG. In it, the aggregation between SARule and SAAction (SAActionInRule) establishes the relationship between a rule and one or more negotiation and/or static actions. The rules are either IKE or IPsec rules (there's no such thing as a static rule, only static actions) and, you're right, a rule can only be in 1 group (but groups can be in multiple groups). +----+ | |* 1 * * 1..n +-<> IPsecPolicyGroup <>--- SARule <>--- SAAction * ^ | +- SANegotiationAction | +- SAStaticAction I hope this helps. Lee ----- Original Message ----- From: "Casey Carr" To: Sent: Tuesday, January 02, 2001 1:05 PM Subject: Intended use of SAStaticAction Class > I would like some guidance on the intended use of SAStaticAction classes. > The intended use of these classes does not appear to be as well described in > "draft-ietf-ipsp-config-policy-model-01.txt" as the SANegotiatedAction > classes. > > My question is with regard to the SAStaticAction classes associated with > SARule classes. The IPSecRule and IKERule are explicitly shown as > composited associations contained by the IPSecPolicyGroup. That is to say > that instances of the SANegotiatedRule class can be contained in one and > only one PolicyGroup. However, there is no equivalent class for static > rules (i.e. SAStaticRule). Therefore, to associated a Rule with an > SAStaticAction we must rely on the more generic PolicyRule. This > association does not explicitly state that a PolicyRule can be with one and > only one PolicyGroup. > > If I we are to implement this model as stated, I believe I am required to > allow PolicyRules to be associated with more than one PolicyGroup. I would > be required to do this just to support associations of SAStaticAction > classes with rules. This seems to be exactly opposite what was intended for > the SANegotiatedRules. Is this the intent or am I missing something? > > I would propose the following relationship be added to the model. This > seems to me more in line with the intended associations between SARule > classes and IPSecPolicyGroup classes. I added the SAStaticRule class and a > composite association with IPSecPolicyGroup. > > Thanks for your consideration. > > Casey > > > > > > Shop Safely Online Without a Credit Card > http://www.rocketcash.com From owner-ipsec-policy@mail.vpnc.org Tue Jan 2 18:37:41 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24026 for ; Tue, 2 Jan 2001 18:37:41 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA00200 for ipsec-policy-bks; Tue, 2 Jan 2001 14:32:19 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00196 for ; Tue, 2 Jan 2001 14:32:17 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 14:36:11 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y97PMV5X; Tue, 2 Jan 2001 14:36:08 -0800 From: Ricky Charlet To: Lee Rafalow Cc: ipsec-policy@vpnc.org, wg-network@dmtf.org Message-ID: <3A524AEF.D5D1656E@redcreek.com> Date: Tue, 02 Jan 2001 14:41:03 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: comments on ICPM IPProtocolEndpoint References: <3A4BBAA4.7ABAFBB7@redcreek.com> <000d01c074bf$585f73c0$81302509@raleigh.ibm.com> <3A51FEFF.B1193E4C@redcreek.com> <00a101c074e8$e050cbc0$81302509@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 Howdy, see my comments at bottom... Lee Rafalow wrote: > > Ricky, The IPProtocolEndpoint class is only used to represent the local > addresses. So, in your picture, yes, the left and right interfaces on SGW1 > would be represented in the SGW1 implementation of the model as > IPProtocolEndpoint instances. In SGW1, the hosts on subnet 1, are not > directly represented; instead they are represented as a part of the packet > classification in the conditions (i.e., filters in the current model) as > sources and/or destinations for traffic. Regardless of whether the hosts > are running their own IKE services or not, the application of the rules in > SGW1 is specified in the conditions/filters by subnet addresses, address > ranges, specific host address, FQDNs, IDs, credential management authority > trust hierarchies, etc. and/or combinations thereof. > > So, to clear up what I think is a little terminology problem, what we mean > when we say "Each SecurityAssociation object instance is scoped by the > IPProtocolEndpoint for which it provides protection" is that the SA (in > SWG1) is protecting traffic on the local address represented by the > IPProtocolEndpoint instance. The fact that the traffic source/sink on > subnet 1 is being "protected" by a tunnel between SGW1 and SGW2 is also true > but not our use of the term in this context. > > Sorry for the confusion. If you can suggest some better words, we'll be > happy to make updates. Cheers, Lee > > ----- Original Message ----- > From: "Ricky Charlet" > To: "Lee Rafalow" > Cc: ; > Sent: Tuesday, January 02, 2001 11:17 AM > Subject: Re: comments on ICPM IPProtocolEndpoint > > > Lee Rafalow wrote: > > > > > > Ricky, I'm not sure I understand the problem so let me try to explain > the > > > relationships in the model. > > > > > > The IKEServiceForEndpoint association identifies the IPProtocolEndpoints > > > (local IP addresses, could be real or virtual interfaces) for which an > IKE > > > service provides negotiation services. (The IPProtocolEndpoint class > only > > > represents local addresses, remote addresses are represented in the > > > conditions/filters of the policy.) Those same local IPProtocolEndpoint > > > instances will have SAs (SecurityAssociationBindsTo) that protect > traffic on > > > the endpoints. > > > > > > Does that help or are we missing something? Cheers, Lee > > > > > > > > > Howdy, > > > > I get the feeling from your answer that you are describing a situation > > where a host is running its own IPsec service. I am asking a question > > about the situation where a group of hosts are protected by a security > > gateway running IPsec. > > > > -------- > > | Host A | | > > | |---| > > ------- | > > -------- | ------- ------- > > | Host B | |----| SGW 1 |--- INTERNET ----| SGW 2 |--- subnet 2 > > | |---| ------- ------- > > ------- | > > -------- | > > | Host C | | > > | |---| > > ------- | > > | > > subnet 1 > > > > In this picture, SGW1 is protecting all of subnet1 on its left > > interface and is runnig IKE (peering with SGW2) on its right interface. > > > > My confusion with the DMTF model for representing policy is this: it > > implies that IPProtocolEndpoints on SGW1 will be the left and right > > interfaces only AND that these endpoints can be the ONLY endpoints being > > protected by an IPsec Policy. But here we would wish that the whole of > > subnet1 be protected by an IPsec Policy. > > > > In general, IPsec protected endpoints are defined by the IPsec > > selectors and do not have to be IP addresses hosted by 'this' system. > > > > -- > > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 OK, First off, I'm glad to discover that packet selectors for IPsec processing can be more than just an IP address on 'this' device. I miss-read the document. The root of my misunderstanding was in pre-concieved notions of what the word endpoint might mean. But now, here is the sentence that tripped me up and my suggestion about how I could have been helped by other language: from DMTF White Paper on IPsec Policy MOdel version 0.82 section 2: "Each IP address hosted by a system is represented by the IPProtocolEndpoint class, and instances of this class can be associated with an IKE service that provides IKE negotiation services for the address, an IPsec policy for use in negotiations for the address, and a set of IKE and/or IPsec security associations that are protecting traffic on that address. The policy for an endpoint is represneted by the class IPsecPolicyGroup, which contains a set of policy rules and/or nested policy groups." I suggest a name change from IPProtocolEndpoint to IPInterface. And then language like: "Each IP address hosted by a system is represented by the IPInterface class. Intances of IPInterface can be associated with an IKE policy, an IPsec Policy, and a set of currently instantiated IKE and/or IPsec security associations. The policy enforeced at an IPInterface is represented by the class IPsecPolicyGroup..." Wether or not you agree with the terminology change (and I don't strongly care) I do strongly urge that you drop the phrase "that are protecting traffic on that address" which was what caused me the most confusion. So if we do not do the terminology change, the sentences would read: "Each IP address hosted by a system is represented by the IPProtocolEndpoint class. Intances of IPProtocolEndpoint can be associated with an IKE policy, an IPsec Policy, and a set of current IKE and/or IPsec security associations. The policy enforced at an IPProtocolEndpoint is represented by the class IPsecPolicyGroup..." -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 3 16:52:36 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05851 for ; Wed, 3 Jan 2001 16:52:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04719 for ipsec-policy-bks; Wed, 3 Jan 2001 12:47:10 -0800 (PST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04714 for ; Wed, 3 Jan 2001 12:47:09 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Wed, 3 Jan 2001 15:46:22 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CH4DFW2G; Wed, 3 Jan 2001 15:46:16 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6MLKC; Wed, 3 Jan 2001 15:46:26 -0500 Message-ID: <3A539068.87FAC008@americasm01.nt.com> Date: Wed, 03 Jan 2001 15:49:44 -0500 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy CC: Hilarie Orman Subject: Design meeting for IPSP architecture 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 Hilarie, All, As per your request I'm bringing to the list the main issues I have compiled so far, following up on the architecture discussions in San Diego and e-mailed feedback on my presentation. I suggest that these items need to be addressed in an interim design meeting. Please feel free to add your concerns or things I missed: 1- separating the policy requirements (e.g., tunneling topology) from policy distribution (e.g., selectors and attributes) 2- confidentiality model for exchanged policy 3- trust model between gateways and/or policy domains 4- nested domains operations of discovery and resolution 5- discovery in a non-global addressing environment (where IPSec tunnels enable use of private addresses) I also would like to have a conference call to have a live discussion on the open architectural issues and finalize the details of the interim meeting. When: Jan, 11, 2000 Time: 11am (GMT-05:00) Eastern Time (US & Canada) Phone Number: 1-613-765-3171 Passcode: 482222# Duration: 3 hours If you intend to be on the call please let me know just to make sure that we have enough ports reserved. regards Abdallah From owner-ipsec-policy@mail.vpnc.org Thu Jan 4 18:27:05 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18210 for ; Thu, 4 Jan 2001 18:27:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13646 for ipsec-policy-bks; Thu, 4 Jan 2001 14:05:04 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13581 for ; Thu, 4 Jan 2001 14:04:43 -0800 (PST) From: Man.M.Li@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f04M98R03302 for ; Thu, 4 Jan 2001 16:09:18 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 4 Jan 2001 16:09:05 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 4 Jan 2001 16:04:19 -0600 Message-ID: To: rafalow@raleigh.ibm.com, ipsec-policy@vpnc.org Subject: AcceptCredentialsFrom Date: Thu, 4 Jan 2001 16:00:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, In the DMTF IPsec model, there is an "AcceptCredentialsFrom" association. One end of the association is CredentialManagementService (from User)class. Where can I find the most recent info about this class and related classes? Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 From owner-ipsec-policy@mail.vpnc.org Thu Jan 4 19:39:33 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18892 for ; Thu, 4 Jan 2001 19:39:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15935 for ipsec-policy-bks; Thu, 4 Jan 2001 15:25:48 -0800 (PST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15931 for ; Thu, 4 Jan 2001 15:25:45 -0800 (PST) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id PAA08717; Thu, 4 Jan 2001 15:30:13 -0800 (PST) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 04 Jan 2001 23:30:13 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Jan 2001 15:30:10 -0800 Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7917@FMSMSX38> From: "Jason, Jamie" To: "'Man.M.Li@nokia.com'" , rafalow@raleigh.ibm.com, ipsec-policy@vpnc.org Subject: RE: Seemingly duplicated attributes in DMTF IPsec model Date: Thu, 4 Jan 2001 15:30:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Whereas the IETF model only models IPsec policy necessary to configure an IPsec device, the DMTF model also models the current state of the IPsec device (i.e., what SAs are established). The classes you mention, SecurityAssocation and IKESecurityAssocation, are used to model the state of the device. That is why you are seeing a duplication. Jamie > -----Original Message----- > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > Sent: Thursday, January 04, 2001 2:38 PM > To: rafalow@raleigh.ibm.com; ipsec-policy@vpnc.org > Subject: Seemingly duplicated attributes in DMTF IPsec model > > > Hi, > > The SANegotiationAction class and the SecurityAssociation > class seem to have > two attributes in common - IdleDurationSeconds and > RefreshThresholdKilobytes. In addition, the LifeTime attributes in > SecurityAssociation look very similar to the Lifetime attributes in > SATransform class. > > Similarly, The IKESecurityAssociation class and IKEProposal > class both have > Cipher, hash algorithms, groupId etc. > > There must be good reasons for these seemingly duplicated > attributes. Can > any one give a hint? > > Man Li > Nokia > 5 Wayside Road, Burlington, MA 01803 > man.m.li@nokia.com > phone 1-781-993-3923 > GSM 1-781-492-2850 > > From owner-ipsec-policy@mail.vpnc.org Thu Jan 4 19:48:15 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18932 for ; Thu, 4 Jan 2001 19:48:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14953 for ipsec-policy-bks; Thu, 4 Jan 2001 14:42:51 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14929 for ; Thu, 4 Jan 2001 14:42:29 -0800 (PST) From: Man.M.Li@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f04Ml5R09434 for ; Thu, 4 Jan 2001 16:47:05 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 4 Jan 2001 16:47:02 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 4 Jan 2001 16:47:02 -0600 Message-ID: To: rafalow@raleigh.ibm.com, ipsec-policy@vpnc.org Subject: Seemingly duplicated attributes in DMTF IPsec model Date: Thu, 4 Jan 2001 16:37:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, The SANegotiationAction class and the SecurityAssociation class seem to have two attributes in common - IdleDurationSeconds and RefreshThresholdKilobytes. In addition, the LifeTime attributes in SecurityAssociation look very similar to the Lifetime attributes in SATransform class. Similarly, The IKESecurityAssociation class and IKEProposal class both have Cipher, hash algorithms, groupId etc. There must be good reasons for these seemingly duplicated attributes. Can any one give a hint? Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 From owner-ipsec-policy@mail.vpnc.org Fri Jan 5 10:07:39 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14398 for ; Fri, 5 Jan 2001 10:07:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA12435 for ipsec-policy-bks; Fri, 5 Jan 2001 05:39:27 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12430 for ; Fri, 5 Jan 2001 05:39:25 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA19744; Fri, 5 Jan 2001 08:43:29 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA06260; Fri, 5 Jan 2001 08:43:31 -0500 Message-ID: <002a01c0771d$40344c20$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: , References: Subject: Re: AcceptCredentialsFrom Date: Fri, 5 Jan 2001 08:41:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The CIM 2.4 schema is available at http://www.dmtf.org/spec/cim_schema_v24.html The user model has been updated for 2.5 (mostly for IPsec model requirements) but it's not quite available yet. Take a look at the 2.4 model and I'll find out how long it'll be before the updates are posted and if it's more than a few days I'll add it to my web site until the DMTF pages are updated. ----- Original Message ----- From: To: ; Sent: Thursday, January 04, 2001 5:00 PM Subject: AcceptCredentialsFrom > Hi, > > In the DMTF IPsec model, there is an "AcceptCredentialsFrom" association. > One end of the association is CredentialManagementService (from User)class. > Where can I find the most recent info about this class and related classes? > > > Man Li > Nokia > 5 Wayside Road, Burlington, MA 01803 > man.m.li@nokia.com > phone 1-781-993-3923 > GSM 1-781-492-2850 From owner-ipsec-policy@mail.vpnc.org Tue Jan 9 21:37:24 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25594 for ; Tue, 9 Jan 2001 21:37:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05697 for ipsec-policy-bks; Tue, 9 Jan 2001 17:21:11 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05693 for ; Tue, 9 Jan 2001 17:21:10 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 17:25:40 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CLT468JN; Tue, 9 Jan 2001 17:25:36 -0800 From: Ricky Charlet To: ".ipsec-policy" Message-ID: <3A5BAD14.8C7EA4E7@redcreek.com> Date: Tue, 09 Jan 2001 17:30:12 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: ICIM: IPsecAction granularity Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, I dislike the granularity property of IPsecActions. It purports to be controlling whether subnet mask, or protocol, or port fields should be wild-carded in SA Proposals. And this makes the granularity property part of a selector. I think any property of a selector should be over on the Filter Entry side and not in an IPsecAction. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Tue Jan 9 21:43:11 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25636 for ; Tue, 9 Jan 2001 21:43:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05805 for ipsec-policy-bks; Tue, 9 Jan 2001 17:29:07 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05801 for ; Tue, 9 Jan 2001 17:29:06 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 17:33:36 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CLT468J0; Tue, 9 Jan 2001 17:33:35 -0800 From: Ricky Charlet To: ".ipsec-policy" Message-ID: <3A5BAEF7.201A1F89@redcreek.com> Date: Tue, 09 Jan 2001 17:38:15 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: ICIM: comment on IPsecPolicyGroup 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, IPsecPolciyGroup binds together an IKERule and and IPsecRule. I'd like to see a layer of abstraction introduced, namely a KeyManagementRule. Then under keyManagementRule, we could use IKE for KM services if we wanted, but we could also use kerberose, or son-of-ike or manually entered keys, or.... -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 10:17:11 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18920 for ; Wed, 10 Jan 2001 10:17:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA03543 for ipsec-policy-bks; Wed, 10 Jan 2001 06:07:12 -0800 (PST) Received: from veronica.tecsec.com ([207.168.215.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03538 for ; Wed, 10 Jan 2001 06:07:11 -0800 (PST) Received: by veronica.tecsec.com with Internet Mail Service (5.5.2448.0) id ; Wed, 10 Jan 2001 09:04:11 -0500 Message-ID: <273E1B54A227D411AF9400B0D022A92918EB2C@veronica.tecsec.com> From: Jay Wack To: "'Ricky Charlet'" , ".ipsec-policy" Subject: RE: ICIM: comment on IPsecPolicyGroup Date: Wed, 10 Jan 2001 09:04:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ANSI has a very broad approach X9.69 called Key Management Extensions...you may want to take a look. Jay Wack: CTO Tecsec 703 506 9069 x112 -----Original Message----- From: Ricky Charlet [mailto:rcharlet@redcreek.com] Sent: Tuesday, January 09, 2001 7:38 PM To: .ipsec-policy Subject: ICIM: comment on IPsecPolicyGroup Howdy, IPsecPolciyGroup binds together an IKERule and and IPsecRule. I'd like to see a layer of abstraction introduced, namely a KeyManagementRule. Then under keyManagementRule, we could use IKE for KM services if we wanted, but we could also use kerberose, or son-of-ike or manually entered keys, or.... -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 12:25:18 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21881 for ; Wed, 10 Jan 2001 12:25:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA11475 for ipsec-policy-bks; Wed, 10 Jan 2001 07:48:53 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11471 for ; Wed, 10 Jan 2001 07:48:51 -0800 (PST) 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 KAA27210; Wed, 10 Jan 2001 10:48:09 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA29372; Wed, 10 Jan 2001 10:48:12 -0500 Message-ID: <001601c07b1c$7d5fb960$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: Cc: "tm-ipsec" References: <3A5BAD14.8C7EA4E7@redcreek.com> Subject: Re: IPsecAction granularity Date: Wed, 10 Jan 2001 10:46:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ricky, Here's the reasoning for its location in the model. The conditions (filters) are used to determine which rule applies to a packet (for which there's currently no SA). As with other action properties, the granularity is used to determine how to negotiate and build the SA. In this case, the granularity is used (in conjunction with the filters) to determine the selector for a given IPsec SA. So, the same rule can be evaluated (i.e., filter) and yield different selectors. IHTH. Lee ----- Original Message ----- From: "Ricky Charlet" To: ".ipsec-policy" Sent: Tuesday, January 09, 2001 7:30 PM Subject: ICIM: IPsecAction granularity > Howdy, > > I dislike the granularity property of IPsecActions. It purports to be > controlling whether subnet mask, or protocol, or port fields should be > wild-carded in SA Proposals. And this makes the granularity property > part of a selector. I think any property of a selector should be over on > the Filter Entry side and not in an IPsecAction. > > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 13:15:39 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23025 for ; Wed, 10 Jan 2001 13:15:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16603 for ipsec-policy-bks; Wed, 10 Jan 2001 08:56:32 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16598 for ; Wed, 10 Jan 2001 08:56:30 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 09:01:03 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CLT469G9; Wed, 10 Jan 2001 09:01:00 -0800 From: Ricky Charlet To: ".ipsec-policy" Message-ID: <3A5C8853.675766A7@redcreek.com> Date: Wed, 10 Jan 2001 09:05:39 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: ICIM: need a way to filter certs from peers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Howdy, In the ICIM I don't see where we could evaluate identities/credentials from peers. For example, while doing IKE with RSA based authentication, we will receive a cert from the peer and need to start using that peer's public key to encrypt stuff that we send to the peer. When we first receive that certificate from the peer, we need a way to filter it through a list of checks. This would be very much like the IdentityContexts attribute of the IKERule for choosing which of our local identitiy/credential sets we would send out to a peer. But the filtering needs to be done on the remote peers id/cert and we should be able to abort IKE if the id/cert presented did not meet our criteria. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 13:40:45 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23875 for ; Wed, 10 Jan 2001 13:40:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17578 for ipsec-policy-bks; Wed, 10 Jan 2001 09:16:54 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17572 for ; Wed, 10 Jan 2001 09:16:53 -0800 (PST) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id RAA03996 for ; Wed, 10 Jan 2001 17:23:07 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 10 Jan 2001 17:21:44 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 09:21:43 -0800 Message-ID: <794826DE8867D411BAB8009027AE9EB904DD793C@FMSMSX38> From: "Jason, Jamie" To: ".ipsec-policy" Subject: RE: ICIM: comment on IPsecPolicyGroup Date: Wed, 10 Jan 2001 09:21:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe we talked about this in San Diego and I agree that it would be prudent that we derive the IKERule class from an intermediate that would be something like you describe. A small correction - IPsecPolicyGroup binds together a set of IKERules and a set of IPsecRules (thus the * cardinality on each). Jamie > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: Tuesday, January 09, 2001 4:38 PM > To: .ipsec-policy > Subject: ICIM: comment on IPsecPolicyGroup > > > Howdy, > > IPsecPolciyGroup binds together an IKERule and and > IPsecRule. I'd like > to see a layer of abstraction introduced, namely a KeyManagementRule. > Then under keyManagementRule, we could use IKE for KM services if we > wanted, but we could also use kerberose, or son-of-ike or manually > entered keys, or.... > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 15:55:50 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26696 for ; Wed, 10 Jan 2001 15:55:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26935 for ipsec-policy-bks; Wed, 10 Jan 2001 11:38:25 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26924 for ; Wed, 10 Jan 2001 11:38:23 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28664 for ; Wed, 10 Jan 2001 14:42:53 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA33188 for ; Wed, 10 Jan 2001 14:42:55 -0500 Message-ID: <018501c07b3d$4494d540$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <3A5C8853.675766A7@redcreek.com> Subject: Re: need a way to filter certs from peers Date: Wed, 10 Jan 2001 14:41:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit See CredentialFilterEntry. ----- Original Message ----- From: "Ricky Charlet" To: ".ipsec-policy" Sent: Wednesday, January 10, 2001 11:05 AM Subject: ICIM: need a way to filter certs from peers > Howdy, > > In the ICIM I don't see where we could evaluate identities/credentials > from peers. For example, while doing IKE with RSA based authentication, > we will receive a cert from the peer and need to start using that peer's > public key to encrypt stuff that we send to the peer. > When we first receive that certificate from the peer, we need a way to > filter it through a list of checks. This would be very much like the > IdentityContexts attribute of the IKERule for choosing which of our > local identitiy/credential sets we would send out to a peer. But the > filtering needs to be done on the remote peers id/cert and we should be > able to abort IKE if the id/cert presented did not meet our criteria. > > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 16:21:28 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27297 for ; Wed, 10 Jan 2001 16:21:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27340 for ipsec-policy-bks; Wed, 10 Jan 2001 11:44:06 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27335 for ; Wed, 10 Jan 2001 11:44:06 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 10 Jan 2001 12:48:14 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 10 Jan 2001 12:48:07 -0700 From: "Hilarie Orman" To: , Subject: Re: ICIM: comment on IPsecPolicyGroup Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA27336 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I see the attraction of the abstraction in theory, but in practice, KM protocols don't operate in a vacuum ("hey, get me 128 bits shared with that guy over there"). IKE is the only KM protocol that understands IPSec. I think that if other protocols are needed for IPSec KM, they should be introduced through ISAKMP, so that the negotiation of SA's is done properly. Also, IPSec supports manually shared keys, so shouldn't be a need to introduce a new rule for specifying it, should there? Hilarie >>> Ricky Charlet 01/09/01 05:38PM >>> Howdy, IPsecPolciyGroup binds together an IKERule and and IPsecRule. I'd like to see a layer of abstraction introduced, namely a KeyManagementRule. Then under keyManagementRule, we could use IKE for KM services if we wanted, but we could also use kerberose, or son-of-ike or manually entered keys, or.... -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 16:55:18 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28120 for ; Wed, 10 Jan 2001 16:55:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29387 for ipsec-policy-bks; Wed, 10 Jan 2001 12:08:51 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29383 for ; Wed, 10 Jan 2001 12:08:49 -0800 (PST) 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 PAA28066 for ; Wed, 10 Jan 2001 15:13:14 -0500 Received: from lmr (dyn9-37-48-129.raleigh.ibm.com [9.37.48.129]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA07112 for ; Wed, 10 Jan 2001 15:12:48 -0500 Message-ID: <019501c07b41$7757b020$81302509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <3A5BAEF7.201A1F89@redcreek.com> Subject: Re: comment on IPsecPolicyGroup Date: Wed, 10 Jan 2001 15:10:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm concerned about building too much future into todays model. The requirements we've been trying to address are for IKE. If we do as you suggest, should we also add superclasses for key management action and proposal? Are there abstractions for key management conditions that may be needed? What properties go in these superclasses and what properties stay in the IKE subclasses? What associations go on the superclasses and what associations stay on the IKE subclasses? The rules for inserting a new class into inheritance trees vary; for example, LDAP doesn't formally permit it (i.e., X.500 doesn't permit it and LDAP is silent), but it's done anyway and there's been discussion in ldapext about fixing the formal rules. But in the information model I think we can insert classes as needed as long as they don't break the subclasses (e.g., introduce a property that has an inconsistent definition). It's certainly permitted in the CIM schemata to insert new superclasses. If, at some point in the future, there's a need for some other key exchange protocol, a new superclass for IKERule can be inserted into the inheritance tree and the additional requirement can be addressed at that time when there's full knowledge of the requirement. On the other hand, if this is for a known function, by all means let's discuss the requirements and see if we agree to add it to the requirements for the current draft. Lee (in my technical advisor capacity) ----- Original Message ----- From: "Ricky Charlet" To: ".ipsec-policy" Sent: Tuesday, January 09, 2001 7:38 PM Subject: ICIM: comment on IPsecPolicyGroup > Howdy, > > IPsecPolciyGroup binds together an IKERule and and IPsecRule. I'd like > to see a layer of abstraction introduced, namely a KeyManagementRule. > Then under keyManagementRule, we could use IKE for KM services if we > wanted, but we could also use kerberose, or son-of-ike or manually > entered keys, or.... > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Wed Jan 10 19:07:18 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05310 for ; Wed, 10 Jan 2001 19:07:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA11241 for ipsec-policy-bks; Wed, 10 Jan 2001 14:36:49 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11235 for ; Wed, 10 Jan 2001 14:36:47 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 14:41:21 -0800 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CLT4601M; Wed, 10 Jan 2001 14:41:20 -0800 From: Ricky Charlet To: Hilarie Orman Cc: ipsec-policy@vpnc.org Message-ID: <3A5CD814.5C4FD6C1@redcreek.com> Date: Wed, 10 Jan 2001 14:45:56 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: ICIM: comment on IPsecPolicyGroup 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 Hilarie Orman wrote: > > I see the attraction of the abstraction in theory, but in practice, > KM protocols don't operate in a vacuum ("hey, get me 128 bits > shared with that guy over there"). > > IKE is the only KM protocol that understands IPSec. I think that > if other protocols are needed for IPSec KM, they should be > introduced through ISAKMP, so that the negotiation of SA's > is done properly. > > Also, IPSec supports manually shared keys, > so shouldn't be a need to introduce a new rule for specifying > it, should there? > > Hilarie > Howdy, Perhaps the details of my suggestion could be improved, but I think that what I'm asking for is very realistic. We do see KINK, GSAKMP, and new version of IKE proposals coming our way. And as far as I have understood, we do want KM/SA management to be architecturally separable from IPsec. All I meant to ask for was that our policy model reflect the philosophy that KeyManagement/SAManagement is separate from IPsec and does not have to be IKE. Perhaps I muddled up some details in the particular remedy I suggested for the model. But because Hilarie Orman is hinting that it is ok to blur the architectural line between keyManagement/SaManagement and IPsec, you give me great pause. Now I'm caught wondering if you really mean that this architectural distinction is not worth modeling or was it that some of the details in my suggested remedy were odd. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec-policy@mail.vpnc.org Thu Jan 11 08:38:26 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00559 for ; Thu, 11 Jan 2001 08:38:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA18040 for ipsec-policy-bks; Thu, 11 Jan 2001 04:08:17 -0800 (PST) Received: from h0001027441c5.ne.mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18035 for ; Thu, 11 Jan 2001 04:08:16 -0800 (PST) Received: from europa-h0001027441c5.ne.mediaone.net (europa [192.168.20.40]) by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id HAA30388; Thu, 11 Jan 2001 07:14:46 -0500 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 HAA15024; Thu, 11 Jan 2001 07:12:37 -0500 (EST) Message-Id: <200101111212.HAA15024@europa-h0001027441c5.ne.mediaone.net> To: Jay Wack cc: "'Ricky Charlet'" , ".ipsec-policy" Subject: Re: ICIM: comment on IPsecPolicyGroup From: Jon Saperia In-reply-to: Your message of Wed, 10 Jan 2001 09:04:04 -0500. <273E1B54A227D411AF9400B0D022A92918EB2C@veronica.tecsec.com> Date: Thu, 11 Jan 2001 07:12:37 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: See below: This is all very good since I see a clear mapping with this approach to the approach we are using in the SNMP Policy (CONF) area. Specifically we can say that a service (keyManagment) might need several technogoies to be realized or could, depending on circumstance use different ones. /jon > ANSI has a very broad approach X9.69 called Key Management Extensions...you > may want to take a look. > > Jay Wack: CTO Tecsec 703 506 9069 x112 > > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: Tuesday, January 09, 2001 7:38 PM > To: .ipsec-policy > Subject: ICIM: comment on IPsecPolicyGroup > > > Howdy, > > IPsecPolciyGroup binds together an IKERule and and IPsecRule. I'd > like > to see a layer of abstraction introduced, namely a KeyManagementRule. > Then under keyManagementRule, we could use IKE for KM services if we > wanted, but we could also use kerberose, or son-of-ike or manually > entered keys, or.... > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 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 Thu Jan 11 08:47:53 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00813 for ; Thu, 11 Jan 2001 08:47:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA18204 for ipsec-policy-bks; Thu, 11 Jan 2001 04:14:45 -0800 (PST) Received: from h0001027441c5.ne.mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18200 for ; Thu, 11 Jan 2001 04:14:43 -0800 (PST) Received: from europa-h0001027441c5.ne.mediaone.net (europa [192.168.20.40]) by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id HAA30401; Thu, 11 Jan 2001 07:21:24 -0500 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 HAA15049; Thu, 11 Jan 2001 07:19:16 -0500 (EST) Message-Id: <200101111219.HAA15049@europa-h0001027441c5.ne.mediaone.net> To: "Lee Rafalow" cc: ipsec-policy@vpnc.org Subject: Re: comment on IPsecPolicyGroup From: Jon Saperia In-reply-to: Your message of Wed, 10 Jan 2001 15:10:03 -0500. <019501c07b41$7757b020$81302509@raleigh.ibm.com> Date: Thu, 11 Jan 2001 07:19:16 -0500 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The rules for inserting a new class into inheritance trees vary; for > example, LDAP doesn't formally permit it (i.e., X.500 doesn't permit it and > LDAP is silent), but it's done anyway and there's been discussion in ldapext > about fixing the formal rules. But in the information model I think we can > insert classes as needed as long as they don't break the subclasses (e.g., > introduce a property that has an inconsistent definition). It's certainly > permitted in the CIM schemata to insert new superclasses. If, at some point > in the future, there's a need for some other key exchange protocol, a new > superclass for IKERule can be inserted into the inheritance tree and the > additional requirement can be addressed at that time when there's full > knowledge of the requirement. > Just checking, I am not asserting that this has been the case in this discussion but. I know that LDAP is talked about a lot and I like it for a lot of things. Please do not limit your thinking here to what LDAP can do. 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 Jan 14 20:57:16 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12012 for ; Sun, 14 Jan 2001 20:57:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA04320 for ipsec-policy-bks; Sun, 14 Jan 2001 16:34:59 -0800 (PST) Received: from commserv.gea.ru ([212.44.145.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA04316 for ; Sun, 14 Jan 2001 16:34:58 -0800 (PST) Received: from sgA9n2VG1 (max1-69.losangeles.corecomm.net [216.214.106.197]) by commserv.gea.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id CZX7C7TZ; Sun, 14 Jan 2001 19:21:48 +0300 DATE: 14 Jan 01 8:13:27 AM FROM: sandywho1212@yahoo.com Message-ID: SUBJECT: www.ImprovingDemocracy.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do you think its time to make some changes in our government? If you do, please take a few moments to read the suggestions at www.ImprovingDemocracy.com. We’ve got the best government in the world, but we voters need to gain a stronger voice in how it’s run – and this article suggests several ways for making that happen. All you’re being asked for is a few minutes of reading, and then a lot of thinking. There will be no request for money. The article is completely non-partisan, there’s no secret agenda, and no one will keep a record of who visits the site or downloads the text. I think you’ll find the subject matter quite interesting. B.D. Foose [author] To Remove Yourself From This Email List: reply to this email with the email address that you would like removed and the word REMOVE in the subject heading. From owner-ipsec-policy@mail.vpnc.org Mon Jan 15 15:48:10 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15466 for ; Mon, 15 Jan 2001 15:48:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19210 for ipsec-policy-bks; Mon, 15 Jan 2001 11:27:58 -0800 (PST) Received: from commserv.gea.ru ([212.44.145.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19181 for ; Mon, 15 Jan 2001 11:27:54 -0800 (PST) Received: from sgA9n2VG1 (max1-69.losangeles.corecomm.net [216.214.106.197]) by commserv.gea.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id CZX7C7TZ; Sun, 14 Jan 2001 19:21:48 +0300 DATE: 14 Jan 01 8:13:27 AM FROM: sandywho1212@yahoo.com Message-ID: SUBJECT: www.ImprovingDemocracy.com Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do you think its time to make some changes in our government? If you do, please take a few moments to read the suggestions at www.ImprovingDemocracy.com. We’ve got the best government in the world, but we voters need to gain a stronger voice in how it’s run – and this article suggests several ways for making that happen. All you’re being asked for is a few minutes of reading, and then a lot of thinking. There will be no request for money. The article is completely non-partisan, there’s no secret agenda, and no one will keep a record of who visits the site or downloads the text. I think you’ll find the subject matter quite interesting. B.D. Foose [author] To Remove Yourself From This Email List: reply to this email with the email address that you would like removed and the word REMOVE in the subject heading. From owner-ipsec-policy@mail.vpnc.org Fri Jan 19 16:54:54 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06981 for ; Fri, 19 Jan 2001 16:54:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA03305 for ipsec-policy-bks; Fri, 19 Jan 2001 12:36:53 -0800 (PST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03301 for ; Fri, 19 Jan 2001 12:36:51 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 19 Jan 2001 15:39:25 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id D2YGHDCL; Fri, 19 Jan 2001 15:39:25 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C6N3JB; Fri, 19 Jan 2001 15:39:26 -0500 Message-ID: <3A68A6CA.2EDDCECD@americasm01.nt.com> Date: Fri, 19 Jan 2001 15:42:50 -0500 From: "Abdallah Rayhan" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-policy CC: Hilarie Orman , "Luis A. Sanchez" Subject: Minutes of the Design Confcall for IPSP architecture 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 Folks, I would like to post to the list the minutes of the conf call we had last week to discuss the issues pertaining to the IPSP architecture. Some of the issues are still to be sorted out this may require another conf call before the Minneapolis and probably a design meeting there as well to progress the work. Feedback from the list on the presented issues is greatly appreciated and thanks to those who participated. Attendees: Matt Condell, Yaron Sheffer, Fernando Cuervo, Abdallah Rayhan When: Jan, 11, 2000 Minutes: 1- Separating the policy requirements (e.g., tunneling topology) from policy distribution (e.g., selectors and attributes) There were some concerns about the difference between tunneling topology and low level policy (selectors and attributes). Tunneling topology refers to policy of a higher level than selectors but eventually mapable to IPSec selectors. Tunneling topology encompasses several tunnels nested or not and each having different endpoints. Tunnels can be layered and cross several gateways and domains. Tunneling topology can be identified by two things: 1- tunnel ends: IP addresses of source and destination 2- security level: encrypted, authenticated, clear text Tunnel ends refer where the start and end are which could be gateway/host. Security level refers to the security requirement of a tunnel or a set of tunnels. This would offer the service of encrypted, authenticated or clear text tunnel which maps to ESP, AH, or clear text, respectively. Note that I have not included ports because they are of less importance to the topology. We agreed on the separation of requirements for services leading to topology and low level IPSec policy and that the low level policy is the mechanism to implement the tunneling topology. The question is whether we aim for a more general approach. The outcome of this is should to shape the discovery/resolution models. 2- Confidentiality model for exchanged policy: Confidentiality was agreed as a requirement but ... We discussed two levels of confidentiality. There was agreement that providing confidentiality from gateways not involved in the resolution was a requirement, though there was not agreement that providing confidentiality from other gateways involved in the resolution was a requirement or even a good idea. This relates also to the issue of how the need for confidentiality is established (this is related to the trust model: if there is a gateway in the path that is only trusted to provide a service it might be necessary for other gateways to hide information). In addition, since the protocol would most likely work with partial information (i.e., the path is discovered in a sequential manner) then the confidentiality may not be achieved in one pass, most certainly in two. 3- Trust model between gateways and/or policy domains When policy with respect to trust was discussed, it was argued that it can be identified at two levels: "a priori" policy which states the trust relations for each entity and the level of sensitivity of various objects, and the "rule set" that can be used directly to set up an IKE agreement. The former belongs to the high level policy which is maintained by a policy management system. Trust relationships allow the participating gateways in the discovered path to determine the services that a gateway can provide. It is not clear whether previous work exists in which this policies have been specified in the form of a schema. KeyNote was suggested but more insight into the problem is required. 4- Nested domains operations of discovery and resolution This was a point of much debate: Should the outer gateway have any kind of access over the policy negotiated by the inner gateway. The final requirement will depend on the following: a- Does the outer-most gateway have policies that allow other (somewhere inside the domain) gateways to dictate the service requirements and how explicit (i.e., how much info about the service/traffic) are these service requirements. b- Is it reasonable to assume that the outer-most gateway can be reduced-to a transit gateway, this is only possible if supported by the proper trust model. 5- Discovery in a non-global addressing environment (where IPSec tunnels enable use of private addresses) It was agreed that this issue should be expressed in the requirement possibly as: It should be possible to carry out the discovery/resolution mechanisms over IPSec based VPNs. This should take care into considerations issues that may arise due to the presence of NAT and with/without the existence of VPN tunnels covering the cases when endpoints use either private or public addressing. regards Abdallah From owner-ipsec-policy@mail.vpnc.org Thu Jan 25 15:57:39 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08616 for ; Thu, 25 Jan 2001 15:57:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19772 for ipsec-policy-bks; Thu, 25 Jan 2001 11:00:38 -0800 (PST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19767 for ; Thu, 25 Jan 2001 11:00:37 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 25 Jan 2001 11:06:55 -0800 To: ipsec-policy@vpnc.org From: Paul Hoffman / VPNC Subject: Ignorable test message Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for the time-wasting filler here. I discovered a pretty disasterous problem in the mailing list archives and hope that I have fixed it. I need to seed the list with a new message, and none of you seemed to be saying much... --Paul Hoffman, Director --VPN Consortium From owner-ipsec-policy@mail.vpnc.org Mon Jan 29 19:57:49 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13007 for ; Mon, 29 Jan 2001 19:57:49 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA00884 for ipsec-policy-bks; Mon, 29 Jan 2001 15:43:57 -0800 (PST) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00879; Mon, 29 Jan 2001 15:43:55 -0800 (PST) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 14NO3J-0000Xx-00; Mon, 29 Jan 2001 23:49:41 +0000 Received: from [206.133.83.14] (helo=localhost) by dfw-mmp3.email.verio.net with esmtp id 14NO34-0000KW-00; Mon, 29 Jan 2001 23:49:26 +0000 X-Sender: misterprivacy@hushmail.com From: Dave To: "customer" Date: Mon, 29 Jan 2001 15:05:55 -0500 Subject: I could go to JAIL for selling this CD! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__13056695_54355.36" Message-Id: Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a Multipart MIME message. ------=_NextPart_000_001__13056695_54355.36 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__13056695_54355.36 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4 OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250 cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250 IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51 dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5 b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250 Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9 MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48 L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48 L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5 IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1 aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52 ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7 IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0 IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7 IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250 PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1 cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5 b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3 aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91 IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52 ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93 IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5 Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0 cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2 NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2 NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+ PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0 ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2 Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250 IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250 IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0 b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9 KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0 d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48 aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5 b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93 d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5 IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+ WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+ ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8 YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+ U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91 IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3 LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3 cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0 aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_001__13056695_54355.36--