From owner-ipsec@lists.tislabs.com Mon Jan 3 00:34:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11926; Mon, 3 Jan 2000 00:34:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA04862 Mon, 3 Jan 2000 01:26:51 -0500 (EST) Message-ID: <004e01bf55b3$88809ba0$5daf01d9@rohitpc.mihy.mot.com> From: "Rohit Aradhya" To: Date: Mon, 3 Jan 2000 11:56:56 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01BF55E1.A22FAFE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004B_01BF55E1.A22FAFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_004B_01BF55E1.A22FAFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_004B_01BF55E1.A22FAFE0-- From owner-ipsec@lists.tislabs.com Mon Jan 3 13:55:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22190; Mon, 3 Jan 2000 13:55:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07375 Mon, 3 Jan 2000 15:30:39 -0500 (EST) Date: Mon, 3 Jan 2000 15:34:43 -0500 (EST) From: "David M. Balenson" Message-Id: <200001032034.PAA00888@clipper.gw.tislabs.com> To: ipsec@tislabs.com Subject: Jan. 6th early registration deadline for ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk S A V E $ 7 0 O F F R E G I S T R A T I O N F E E ! ! R E G I S T E R B Y J A N U A R Y 6 , 2 0 0 0 THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ipsec@lists.tislabs.com Tue Jan 4 08:23:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09809; Tue, 4 Jan 2000 08:23:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09436 Tue, 4 Jan 2000 08:44:57 -0500 (EST) From: haitao.tang@nokia.com Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1011E75@eseis04nok> To: namedroppers@internic.net, dhcp-v4@bucknell.edu, ipng@sunroof.eng.sun.com, srvloc@srvloc.org, zeroconf@merit.edu, aaa-wg@merit.edu, roamops@tdmx.rutgers.edu, ipsec@lists.tislabs.com, ietf-pkix@imc.org, ietf-stime@stime.org, spki@c2.net, ietf-cat-wg@lists.stanford.edu, discuss@apps.ietf.org, www-mobile@w3.org Subject: Announcement of the Internet Spatial Location Forum Date: Thu, 30 Dec 1999 15:01:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Colleagues: Internet Spatial Location Forum, a discussion list on IP-related location issues is now active. The setting up of the forum is sparked by the huge practical value and the unreadiness of the spatial location capability for the Internet. The missing capability becomes even more demanded with the integration of IP and various network technologies including cellular and mobile systems. The forum is thus set up after our discussions with the leaders and some other members of IETF. It serves as a pre-BOF mailing list for applying a BOF in 47th IETF to address those location issues. The detailed description can be found at 'http://www-nrc.nokia.com/ip-location'. Its immediate goals are: (1) Collect the interests, concerns, and suggestions on an IP spatial location protocol, (2) Identify the further requirements of the location protocol, (3) Seek partners and enthusiasts for the joint effort, (4) Invite volunteers for their presentations on the location issues, and (5) Prepare the BOF charter for the location protocol. In brief, there is now a well-evaluated concept in its pregnancy. Please add your own influences onto its progress. To subscribe to the list, just email 'majordomo@research.nokia.com' with 'subscribe ext-ip-location' in the mail body. To discuss , just email the mailing list 'ext-ip-location@research.nokia.com'. More information (detailed forum description, mailing list archive, etc.) can be found at the web page 'http://www-nrc.nokia.com/ip-location'. Thank you for reading this far! Please forward this mail to anyone else who may be interested. Please visit the forum's web page and contribute by sending email to the mailing list. Thanks again! Yours truly, Haitao Tang / Eric Brunner From owner-ipsec@lists.tislabs.com Fri Jan 7 05:24:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02059; Fri, 7 Jan 2000 05:24:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA23608 Fri, 7 Jan 2000 06:35:00 -0500 (EST) Message-Id: <200001071139.GAA14101@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-openpgp-00.txt Date: Fri, 07 Jan 2000 06:39:19 -0500 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 : OpenPGP Key Usage in IKE Author(s) : W. Price Filename : draft-ietf-ipsec-openpgp-00.txt Pages : 3 Date : 06-Jan-00 This document defines a profile for the usage of OpenPGP keys within the IKE [IKE] protocol. The ISAKMP [ISAKMP] protocol on which IKE is based defines an identifier for the use of OpenPGP [OPENPGP] keys, but does not define how they should be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-openpgp-00.txt 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-openpgp-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-ipsec-openpgp-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: <20000106105914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-openpgp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-openpgp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000106105914.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jan 7 15:17:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14170; Fri, 7 Jan 2000 15:17:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25554 Fri, 7 Jan 2000 16:43:53 -0500 (EST) From: "Bob Doud" To: Subject: A question on IPsec AH in IPv6 Date: Fri, 7 Jan 2000 16:48:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In RFC 2402, section 3.1, there is discussion about the placement of the AH header with respect to IPv6 extension headers: "In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the semantics desired." I was trying to figure out what the ramifications are with the destination options headers being before or after the AH header. Is anyone aware of any specific requirement for the destination options to be AFTER the AH header? (Since AH doen't render the extension headers opaque, it would seem that other nodes could always process the dest. options, regardless of where they fall.) Bob Doud From owner-ipsec@lists.tislabs.com Fri Jan 7 16:56:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15276; Fri, 7 Jan 2000 16:56:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25813 Fri, 7 Jan 2000 18:39:14 -0500 (EST) From: Dan McDonald Message-Id: <200001072343.PAA24506@kebe.eng.sun.com> Subject: Re: A question on IPsec AH in IPv6 In-Reply-To: from Bob Doud at "Jan 7, 2000 04:48:46 pm" To: Bob Doud Date: Fri, 7 Jan 2000 15:43:23 -0800 (PST) CC: ipsec@lists.tislabs.com X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I was trying to figure out what the ramifications are > with the destination options headers being before or after > the AH header. Is anyone aware of any specific requirement > for the destination options to be AFTER the AH header? Typically you want the destination options to be after the AH header if only the final endpoint of a datagram needs to see the options. Destination options that fall before AH are intended (I believe) to also fall before the routing header, such that explicitly named nodes in the routing header also process the destination options. This also means that the intermediate routing-header-specified nodes process unauthenticated options, as routers process unauthenticated hop-by-hop options. Only the ultimate destination can process authenticatable options after AH computation. Dan From owner-ipsec@lists.tislabs.com Mon Jan 10 12:44:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13253; Mon, 10 Jan 2000 12:44:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12825 Mon, 10 Jan 2000 13:13:40 -0500 (EST) From: "Bob Doud" To: "Dan McDonald" Cc: Subject: RE: A question on IPsec AH in IPv6 Date: Mon, 10 Jan 2000 13:19:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200001072343.PAA24506@kebe.eng.sun.com> X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, > > Dan McDonald wrote: > > > I was trying to figure out what the ramifications are > > with the destination options headers being before or after > > the AH header. Is anyone aware of any specific requirement > > for the destination options to be AFTER the AH header? > > Typically you want the destination options to be after the AH header if only > the final endpoint of a datagram needs to see the options. > > Destination options that fall before AH are intended (I believe) to also fall > before the routing header, such that explicitly named nodes in the routing > header also process the destination options. What do you mean by routing header?... are you speaking about hop-by-hop routing headers, or the Outer Tunnel Header of IPsec? (I assume you mean hop-by-hop routing.) > > This also means that the intermediate routing-header-specified nodes process > unauthenticated options, as routers process unauthenticated hop-by-hop > options. Only the ultimate destination can process authenticatable options > after AH computation. AH authenticates all extension headers that are not mutable, so the destination options are authenticated regardless of position (unless of course they are a mutable option, in which case they're NOT authenciated, regardless of position.) Bob From owner-ipsec@lists.tislabs.com Wed Jan 12 16:03:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA23857; Wed, 12 Jan 2000 16:03:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22747 Wed, 12 Jan 2000 17:04:54 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Paul Lambert" To: ho@earth.hpc.org, ipsec@lists.tislabs.com Message-ID: <85256864.0079330C.00@domino2.certicom.com> Date: Wed, 12 Jan 2000 14:04:33 -0800 Subject: Dangerous Curves Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It looks like HP Labs may have proven that the EC2N groups in IKE (RFC 2409 and RFC 2412) are weak. There was debate on this list long ago on the dangers of using "composite curves". The article is located at: http://www.hpl.hp.com/news/ecc.html Paul From owner-ipsec@lists.tislabs.com Thu Jan 13 10:39:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26135; Thu, 13 Jan 2000 10:39:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26225 Thu, 13 Jan 2000 11:36:34 -0500 (EST) Message-ID: <20000113130457.44686.qmail@hotmail.com> X-Originating-IP: [192.100.124.218] Reply-To: marc@solsona.pp.fi From: "Marc Solsona" To: ipsec@lists.tislabs.com Subject: Oakley logs in Win2000 Date: Thu, 13 Jan 2000 05:04:57 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I don't know if this is the right place but: Is there any way to create a log of all details of the oakley negotiations, messages, payloads and sessions keys? Thanks ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Thu Jan 13 11:13:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26563; Thu, 13 Jan 2000 11:13:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26510 Thu, 13 Jan 2000 12:42:57 -0500 (EST) Message-Id: <3.0.5.32.20000113184957.00930290@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 Jan 2000 18:49:57 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Phase 1 KB lifetime Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA26259 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the wednesday interop meeting there was a notion to forbid KB lifetimes in Phase 1. I see that a lifetime does not make much sense in todays use of ISAKMP. But somebody might use the ISKAMP channel to exchange a lot a data. If a system sends 10KB per second through the ISAKMP channel, a KB lifetime makes sense. Let's keep it for now. Jörn Sierwald From owner-ipsec@lists.tislabs.com Thu Jan 13 12:03:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27151; Thu, 13 Jan 2000 12:03:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26808 Thu, 13 Jan 2000 13:40:35 -0500 (EST) Message-ID: <19398D273324D3118A2B0008C7E9A569027517D6@SIT.platinum.corp.microsoft.com> From: Brian Swander To: "'marc@solsona.pp.fi'" , "'ipsec@lists.tislabs.com'" Subject: RE: Oakley logs in Win2000 Date: Thu, 13 Jan 2000 10:32:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5DF4.83D4A8BE" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5DF4.83D4A8BE Content-Type: text/plain; charset="iso-8859-1" Just so there is no confusion, these logs will NOT dump any keys, keying material, etc., but will give all the other requested below info. bs -----Original Message----- From: Brian Swander Sent: Thursday, January 13, 2000 10:31 AM To: 'marc@solsona.pp.fi'; ipsec@lists.tislabs.com Subject: RE: Oakley logs in Win2000 Use regedt32: Under: HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\POLICYAGENT\ Create a Key called Oakley Under the new oakley key, create a DWORD value: EnableLogging, set to 1. Restart the ipsec service. Either net stop policyagent, net start policyagent, or reboot. Either will do it. The logs show up in: %SystemRoot%\debug\oakley.log, oakley.log.bak bs -----Original Message----- From: Marc Solsona [mailto:m_solsona@hotmail.com] Sent: Thursday, January 13, 2000 5:05 AM To: ipsec@lists.tislabs.com Subject: Oakley logs in Win2000 Hi, I don't know if this is the right place but: Is there any way to create a log of all details of the oakley negotiations, messages, payloads and sessions keys? Thanks ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------_=_NextPart_001_01BF5DF4.83D4A8BE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Oakley logs in Win2000

Just so there is no confusion, these logs will NOT = dump any keys, keying material, etc., but will give all the other = requested below info.

bs

-----Original Message-----
From: Brian Swander
Sent: Thursday, January 13, 2000 10:31 AM
To: 'marc@solsona.pp.fi'; = ipsec@lists.tislabs.com
Subject: RE: Oakley logs in Win2000


Use regedt32:

Under:
HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\POLICYAGENT\

Create a Key called Oakley

Under the new oakley key, create a DWORD value: = EnableLogging, set to 1.

Restart the ipsec service.  Either net stop = policyagent, net start policyagent, or reboot.  Either will do = it.

The logs show up in:

%SystemRoot%\debug\oakley.log, oakley.log.bak

bs


-----Original Message-----
From: Marc Solsona [mailto:m_solsona@hotmail.com]<= /FONT>
Sent: Thursday, January 13, 2000 5:05 AM
To: ipsec@lists.tislabs.com
Subject: Oakley logs in Win2000


Hi, I don't know if this is the right place = but:

Is there any way to create a log of all details of = the oakley
negotiations, messages, payloads and sessions = keys?

Thanks
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------_=_NextPart_001_01BF5DF4.83D4A8BE-- From owner-ipsec@lists.tislabs.com Thu Jan 13 12:10:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27216; Thu, 13 Jan 2000 12:09:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26784 Thu, 13 Jan 2000 13:39:04 -0500 (EST) Message-ID: <19398D273324D3118A2B0008C7E9A569027517D5@SIT.platinum.corp.microsoft.com> From: Brian Swander To: "'marc@solsona.pp.fi'" , ipsec@lists.tislabs.com Subject: RE: Oakley logs in Win2000 Date: Thu, 13 Jan 2000 10:30:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5DF4.4BC3DC56" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5DF4.4BC3DC56 Content-Type: text/plain; charset="iso-8859-1" Use regedt32: Under: HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\POLICYAGENT\ Create a Key called Oakley Under the new oakley key, create a DWORD value: EnableLogging, set to 1. Restart the ipsec service. Either net stop policyagent, net start policyagent, or reboot. Either will do it. The logs show up in: %SystemRoot%\debug\oakley.log, oakley.log.bak bs -----Original Message----- From: Marc Solsona [mailto:m_solsona@hotmail.com] Sent: Thursday, January 13, 2000 5:05 AM To: ipsec@lists.tislabs.com Subject: Oakley logs in Win2000 Hi, I don't know if this is the right place but: Is there any way to create a log of all details of the oakley negotiations, messages, payloads and sessions keys? Thanks ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------_=_NextPart_001_01BF5DF4.4BC3DC56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Oakley logs in Win2000

Use regedt32:

Under:
HKLM\SYSTEM\CURRENTCONTROLSET\SERVICES\POLICYAGENT\

Create a Key called Oakley

Under the new oakley key, create a DWORD value: = EnableLogging, set to 1.

Restart the ipsec service.  Either net stop = policyagent, net start policyagent, or reboot.  Either will do = it.

The logs show up in:

%SystemRoot%\debug\oakley.log, oakley.log.bak

bs


-----Original Message-----
From: Marc Solsona [mailto:m_solsona@hotmail.com]<= /FONT>
Sent: Thursday, January 13, 2000 5:05 AM
To: ipsec@lists.tislabs.com
Subject: Oakley logs in Win2000


Hi, I don't know if this is the right place = but:

Is there any way to create a log of all details of = the oakley
negotiations, messages, payloads and sessions = keys?

Thanks
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

------_=_NextPart_001_01BF5DF4.4BC3DC56-- From owner-ipsec@lists.tislabs.com Fri Jan 14 12:19:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03964; Fri, 14 Jan 2000 12:19:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01451 Fri, 14 Jan 2000 13:33:00 -0500 (EST) Message-ID: <387F6BB4.BBDCD2F1@ire-ma.com> Date: Fri, 14 Jan 2000 13:32:20 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: Deflate issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We discovered some Deflate implementation differences that control the inclusion of the Deflate header and Adler32 checksum. RFC2394 makes no mention of the Deflate header or Adler32 checksum . These items are redundant in the case of IPCOMP. It doesn't make sense to spend the time to do it as it uses bandwidth unnecessarily for the extra (8?) bytes. Unfortunately, the ability to NOT include the Deflate header and Adler32 checksum is an undocumented feature of the ZLIB implementation of Deflate, which is controlled by the -15 parameter to the deflateInit2_() Sooooo... should the inclusion of the extra header and the checksum be controlled by another IPCOMP attribute or should we simply all change the way Deflate engine is initialized from: if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break; to: if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, -11, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream))) break; And similar for Inflate, from: if (Z_OK != inflateInit(&d_stream)) break; to: if (Z_OK != inflateInit2_(&d_stream, -15, ZLIB_VERSION, sizeof(z_stream))) break; From owner-ipsec@lists.tislabs.com Fri Jan 14 13:52:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04932; Fri, 14 Jan 2000 13:52:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01784 Fri, 14 Jan 2000 15:06:43 -0500 (EST) Message-Id: <200001142010.MAA21692@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 14 Jan 2000 12:10:56 -0800 To: Slava Kavsan From: Avram Shacham Subject: Re: Deflate issue Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com In-Reply-To: <387F6BB4.BBDCD2F1@ire-ma.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava, Am I reading correctly that the DEFLATE decompression is dependent on the parameters to the compression process, i.e. an extra attribute needs to be negotiated in order to enable the decompression process? For comparison, afaik, LZS has the capability to decompress a packet regardless of the compression parameters. Your suggestion to negotiate a DEFLATE-specific attribute, while doable and supported by the protocol, will have the side-effect of excluding that compression algorithm from the list of well-known algorithms, as RFC2393 defines: Compression Parameter Index (CPI) 16-bit index. The CPI is stored in network order. The values 0-63 define well-known compression algorithms, which require no <== additional information, and are used for manual setup. The <== values themselves are identical to IPCOMP Transform identifiers as defined in [SECDOI]. [...] The values 256-61439 are negotiated between the two nodes in definition of an IPComp Association, as defined in section 4. Note: When negotiating one of the well-known algorithms, the nodes MAY select a CPI in the pre-defined range 0-63. In order to keep the advantages of using a well-known algorithm ID, I'd suggest (a) modifying RFC2394 to dictate a unified approach, or (b) creating multiple DEFLATE IDs in the DOI, one for each option. avram At 01:32 PM 1/14/00 -0500, Slava Kavsan wrote: >We discovered some Deflate implementation differences that control the >inclusion of the Deflate >header and Adler32 checksum. RFC2394 makes no mention of the Deflate >header or Adler32 checksum . These items are redundant in the case of >IPCOMP. > >It doesn't make sense to spend the time to do it as it uses bandwidth >unnecessarily for the extra >(8?) bytes. > >Unfortunately, the ability to NOT include the Deflate header and Adler32 > >checksum is an undocumented feature of the ZLIB implementation of >Deflate, >which is controlled by the -15 parameter to the deflateInit2_() > >Sooooo... should the inclusion of the extra header and the checksum be >controlled by another IPCOMP attribute or should we simply all change >the way Deflate engine is initialized from: > >if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break; > >to: > >if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, >-11, >DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream))) >break; > >And similar for Inflate, from: > >if (Z_OK != inflateInit(&d_stream)) break; > >to: > >if (Z_OK != inflateInit2_(&d_stream, -15, ZLIB_VERSION, >sizeof(z_stream))) break; > From owner-ipsec@lists.tislabs.com Fri Jan 14 13:59:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05000; Fri, 14 Jan 2000 13:59:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01820 Fri, 14 Jan 2000 15:19:44 -0500 (EST) To: ipsec@lists.tislabs.com Subject: interpretation of "encapsulation mode" attribute X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Fri, 14 Jan 2000 12:23:47 -0800 Message-ID: <629.947881427@lychee.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry if it is dumb question... RFC2407 page 14 has "Encapsulation mode" attribute for phase 2. However, interpretation of "tunnel", especially when we have multiple protocols mixed in, is totally unclear to me. I saw difference in interpretation with other implementations. I think we all agree that the following is "IP ESP AH payload". proposal 1: transform ESP, transport proposal 1: transform AH, transport What if, you get: proposal 1: transform ESP, tunnel proposal 1: transform AH, tunnel would you expect packet like "IP ESP AH payload", or "IP ESP IP AH payload"? How about proposal 1: transform ESP, tunnel proposal 1: transform AH, transport or proposal 1: transform ESP, transport proposal 1: transform AH, tunnel We can interpret the former as "IP ESP IP AH payload", and the latter as "IP ESP AH IP payload", if we regard "tunnel" as "attach IP packet and add IPsec header", and use the list of transform ordered backwards, like this: IP payload v AH tunnel (encapsulate, then insert AH) IP AH IP payload v ESP transport (insert ESP) IP ESP AH IP payload Of course you can iterate more protocols to incrase confusion. Is there any agreement on interpretation? If so, please let me know and can we have more explicit wording in future revisions? itojun From owner-ipsec@lists.tislabs.com Fri Jan 14 14:17:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05232; Fri, 14 Jan 2000 14:17:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01941 Fri, 14 Jan 2000 15:52:18 -0500 (EST) From: "Roy Pereira" To: "Slava Kavsan" , Subject: RE: Deflate issue Date: Fri, 14 Jan 2000 12:54:30 -0800 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.2314.1300 In-Reply-To: <387F6BB4.BBDCD2F1@ire-ma.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'll add whatever needed wording to the RFC. I'd like to know how many vendors implemented this feature and have we seen successful interoperability. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Slava Kavsan Sent: Friday, January 14, 2000 10:32 AM To: ipsec@lists.tislabs.com Subject: Deflate issue We discovered some Deflate implementation differences that control the inclusion of the Deflate header and Adler32 checksum. RFC2394 makes no mention of the Deflate header or Adler32 checksum . These items are redundant in the case of IPCOMP. It doesn't make sense to spend the time to do it as it uses bandwidth unnecessarily for the extra (8?) bytes. Unfortunately, the ability to NOT include the Deflate header and Adler32 checksum is an undocumented feature of the ZLIB implementation of Deflate, which is controlled by the -15 parameter to the deflateInit2_() Sooooo... should the inclusion of the extra header and the checksum be controlled by another IPCOMP attribute or should we simply all change the way Deflate engine is initialized from: if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break; to: if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, -11, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream))) break; And similar for Inflate, from: if (Z_OK != inflateInit(&d_stream)) break; to: if (Z_OK != inflateInit2_(&d_stream, -15, ZLIB_VERSION, sizeof(z_stream))) break; From owner-ipsec@lists.tislabs.com Fri Jan 14 14:41:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05560; Fri, 14 Jan 2000 14:41:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01953 Fri, 14 Jan 2000 15:54:46 -0500 (EST) Message-ID: <387F8D16.F96D9FE1@ire-ma.com> Date: Fri, 14 Jan 2000 15:54:46 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Avram Shacham CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: Deflate issue References: <200001142010.MAA21692@honeybee.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree. Our preference is that we all agree on using DEFLATE in the way I described here - I do not see any need for overheads of extra header, checksum and related computation. Avram Shacham wrote: > Slava, > > Am I reading correctly that the DEFLATE decompression is dependent > on the parameters to the compression process, i.e. an extra attribute > needs to be negotiated in order to enable the decompression process? > For comparison, afaik, LZS has the capability to decompress a packet > regardless of the compression parameters. > > Your suggestion to negotiate a DEFLATE-specific attribute, > while doable and supported by the protocol, will have the side-effect > of excluding that compression algorithm from the list of well-known > algorithms, as RFC2393 defines: > > Compression Parameter Index (CPI) > > 16-bit index. The CPI is stored in network order. The values > 0-63 define well-known compression algorithms, which require no <== > additional information, and are used for manual setup. The <== > values themselves are identical to IPCOMP Transform identifiers > as defined in [SECDOI]. [...] The values > 256-61439 are negotiated between the two nodes in definition of > an IPComp Association, as defined in section 4. Note: When > negotiating one of the well-known algorithms, the nodes MAY > select a CPI in the pre-defined range 0-63. > > In order to keep the advantages of using a well-known algorithm ID, > I'd suggest (a) modifying RFC2394 to dictate a unified approach, > or (b) creating multiple DEFLATE IDs in the DOI, one for each option. > > avram > > At 01:32 PM 1/14/00 -0500, Slava Kavsan wrote: > >We discovered some Deflate implementation differences that control the > >inclusion of the Deflate > >header and Adler32 checksum. RFC2394 makes no mention of the Deflate > >header or Adler32 checksum . These items are redundant in the case of > >IPCOMP. > > > >It doesn't make sense to spend the time to do it as it uses bandwidth > >unnecessarily for the extra > >(8?) bytes. > > > >Unfortunately, the ability to NOT include the Deflate header and Adler32 > > > >checksum is an undocumented feature of the ZLIB implementation of > >Deflate, > >which is controlled by the -15 parameter to the deflateInit2_() > > > >Sooooo... should the inclusion of the extra header and the checksum be > >controlled by another IPCOMP attribute or should we simply all change > >the way Deflate engine is initialized from: > > > >if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break; > > > >to: > > > >if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, > >-11, > >DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream))) > >break; > > > >And similar for Inflate, from: > > > >if (Z_OK != inflateInit(&d_stream)) break; > > > >to: > > > >if (Z_OK != inflateInit2_(&d_stream, -15, ZLIB_VERSION, > >sizeof(z_stream))) break; > > From owner-ipsec@lists.tislabs.com Mon Jan 17 00:32:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA29869; Mon, 17 Jan 2000 00:32:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA08482 Mon, 17 Jan 2000 01:25:27 -0500 (EST) Message-Id: <4.0.2.20000116205324.00e73100@honeybee.cisco.com> X-Sender: shacham@honeybee.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 16 Jan 2000 22:30:18 -0800 To: ippcp@external.cisco.com From: Avram Shacham Subject: VPN bakeoff - IPComp Group Meeting minutes Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the VPN bakeoff in San Diego last Wednesday, 1-12-2000, the Group Meeting discussed the following IPComp issues. The next version of rfc2393bis draft will reflect the IKE attributes decisions. 1. IKE attributes 1.1 Lifetime The Lifetime attribute is added to the list of supported attributes (with Transport Mode) when IPComp association is negotiate via IKE. 1.2 Attribute of other transforms in Protection Suite In a straw vote, not even a single participant indicated that his/her implementation sends attributes other than those needed for IPComp when negotiating a Protection Suite. Moreover, no implementation is expecting the IPCOMP proposal to include attributes from other transforms of a negotiated Protection Suite and accordingly never rejects an IPCOMP proposal that does not include attributes of the other transforms. 2. IPComp is needed in future VPN bakeoffs, as more interoperability tests are required for several implementations. Regards, avram From owner-ipsec@lists.tislabs.com Mon Jan 17 01:21:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA00799; Mon, 17 Jan 2000 01:21:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA08574 Mon, 17 Jan 2000 01:56:11 -0500 (EST) Date: Sun, 16 Jan 2000 22:45:11 -0800 (PST) From: Marc Hasson Message-Id: <200001170645.WAA27757@leo.mentat.com> To: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: Deflate issue X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan wrote: > We discovered some Deflate implementation differences that control the > inclusion of the Deflate > header and Adler32 checksum. RFC2394 makes no mention of the Deflate > header or Adler32 checksum . These items are redundant in the case of > IPCOMP. Avram Shacham wrote: > In order to keep the advantages of using a well-known algorithm ID, > I'd suggest (a) modifying RFC2394 to dictate a unified approach, > or (b) creating multiple DEFLATE IDs in the DOI, one for each option. > > avram Here's some opinions as a recent IPCOMP/DEFLATE implementer who has never looked at a line of zlib code, to my knowledge.... I found the RFCs 1951, 2393, and 2394 sufficiently detailed enough to code an IPCOMP/DEFLATE implementation that I expect to have interoperate. I found few ambiguities, though I won't be surprised to find I have a few bit-ordering problems to straighten out once I get to do interop testing with other vendors. I'd support an "implementation hint" addition to the deflate RFC for those who are using zlib, if that consists of some instruction on how to configure/invoke zlib properly so IPCOMP implementations interoperate. But I don't think in any way that the RFC should imply that zlib, a particular implementation(?), is a requirement or even an IETF recommendation. Just an implementation hint. I sure would rather avoid having multiple flavors of DEFLATE algorithm ids in the DOI unless someone has a compelling argument for it. I saw no mention (like Slava) in the above RFCs of the "Adler32 checksum" or "deflate header" mentioned at the start of this thread. Frankly I'm at a loss as to how we could permit these to be used, whatever they are, in an interoperable procotocol if the only "documentation" of them exists in a particular (zlib?) implementation and not in the compression working group's standards-track documents or references to other IETF-controlled documents. Have I misunderstood something or missed a vital RFC?? Based on the above terms, and prior discussions in this thread, it sounds like the "Adler32 checksum" is something that would be redundant with IPSec authentication or perhaps even stock ULP checksums. As far as a "deflate header", RFC 1951 clearly spells out all the "header" which a set of DEFLATE compressed data needs. And thats only 3 bits total to convey "final block" and which type (1 of 3) DEFLATE compression block follows next. As far as I can tell from RFC 1951, a receiver's DEFLATE decompression should be totally independent of any "parameters" to a sender's DEFLATE compression. The only implementation-specific parameters a compressor should have is how hard it works to achieve its compression, all symbols emitted should be decompressable. Geesh, DEFLATE even allows the sender to send the particular Huffman tree it used for its compression on a particular stretch of data! (Not that I'd expect to see that much on short packets. :-) ) Is there anyone who sees a need for these extra items to be calculated and sent in IPCOMP/DEFLATE? Is there some "magic" being conveyed between compressing/decompressing zlib implementations that needs to be sent over the wire? I sure hope (not having used zlib, :-) ) that this isn't the case... -- Marc -- From owner-ipsec@lists.tislabs.com Mon Jan 17 06:13:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07163; Mon, 17 Jan 2000 06:13:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA09610 Mon, 17 Jan 2000 07:45:35 -0500 (EST) Date: Mon, 17 Jan 2000 13:50:04 +0100 From: Markus Friedl To: ipsec@lists.tislabs.com Subject: Bruce Schneier on IPsec Message-ID: <20000117135004.A1913@faui01.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk fyi, http://www.counterpane.com/ipsec.pdf http://www.counterpane.com/ipsec.ps.zip "IPsec was a great disappointment to us. Given the quality of the people that worked on it and the time that was spent on it, we expected a much better result. We are not alone in this opinion; from various discussions with the people involved, we learned that virtually nobody is satised with the process or the result. The development of IPsec seems to have been burdened by the committee process that it was forced to use, and it shows in the results. [...] Thus, no IPsec system will achieve the goal of providing a high level of security." From owner-ipsec@lists.tislabs.com Mon Jan 17 18:16:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19384; Mon, 17 Jan 2000 18:16:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12328 Mon, 17 Jan 2000 19:24:18 -0500 (EST) Date: Mon, 17 Jan 2000 18:27:53 -0600 (CST) From: Tylor Allison X-Sender: allison@stpsowk07.sctc.com To: ipsec@lists.tislabs.com Subject: pfs support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This may be a dumb question, but what exactly is meant by saying "I support PFS"? I ran into a few problems when trying to rekey with a few vendors at the interop because my interpretation of PFS was different than theirs. I believe my implementation is accomplishing PFS for both identities and keys by uniquely binding each Phase 1 SA with a single Phase 2 SA and performing a second DH exponentiation in the Quick Mode. Therefore, when I need to start a rekey, I will create a new Phase 1 SA followed by a New Phase 2 SA. The problems I experienced was when the remote peer attempted to start the rekey, and they would use the old Phase 1 SA to establish a new Quick mode. I rejected this offer, since it attempted to use the old SA... and the rekeying seemed to suffer. Back to my question then, what is everyone else doing to support PFS? Are you supporting PFS for key material only? Or are you supporting PFS for key material and identities? Has anyone else experienced any rekey problems associated with interoperating with a vendor who has implemented a PFS mode different from what you have implemented? Thanks in advance. Tylor --- Tylor Allison tylor_allison@securecomputing.com (651) 628-1554 Secure Computing Corporation From owner-ipsec@lists.tislabs.com Mon Jan 17 19:52:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA26793; Mon, 17 Jan 2000 19:52:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12698 Mon, 17 Jan 2000 21:12:47 -0500 (EST) Message-ID: <38851E95.C8C6E8AE@cisco.com> Date: Tue, 18 Jan 2000 18:16:53 -0800 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Pyda Srisuresh CC: David Wong , l2tp@ipsec.org, ipsec@lists.tislabs.com Subject: Re: L2TP over IPSec References: <20000118021144.23584.qmail@web1405.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Copying ipsec. Pyda Srisuresh wrote: > > --- "W. Mark Townsley" wrote: > > > > Transport mode is encouraged. > > > > Can you identify a case where tunnel mode would be absolutely necessary? > > > > When L2TP tunnel end point is a tunnel mode IPsec gateway. > It is easy for a VPN/IPsec gateway to implement tunnel mode IPsec for L2TP > tunnels. Having to implement transport mode for L2TP is a bit of stretch > for the security gateway. Details please? Why is transport mode more difficult than tunnel mode? > > cheers, > suresh > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com From owner-ipsec@lists.tislabs.com Mon Jan 17 22:39:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03771; Mon, 17 Jan 2000 22:39:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA13129 Tue, 18 Jan 2000 00:00:44 -0500 (EST) Message-ID: <3883F466.68721069@cyphers.net> Date: Mon, 17 Jan 2000 21:05:41 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tylor Allison CC: ipsec@lists.tislabs.com Subject: Re: pfs support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Supporting PFS involves: 1. Doing a second key exchange with DH in Phase 2 2. Deleting the Phase 1 SA immediately after the Phase 2 to dispose of the key material involved Obviously, step 2 is not going to work very well unless both parties send and interpret Delete notifications. Inconsistent implementation of Delete notifications is the single biggest interop issue I see in other implementations. Lack of support for Initial Contact notifications would be the second. If you didn't send a Delete notification when you deleted your Phase 1 SA, it's understandable that the other side would do what you're seeing because implementation of #2 above seems to be fairly inconsistent. Tylor Allison wrote: > > This may be a dumb question, but what exactly is meant by saying > "I support PFS"? I ran into a few problems when trying to rekey with a > few vendors at the interop because my interpretation of PFS was different > than theirs. > > I believe my implementation is accomplishing PFS for both identities and > keys by uniquely binding each Phase 1 SA with a single Phase 2 SA and > performing a second DH exponentiation in the Quick Mode. Therefore, when > I need to start a rekey, I will create a new Phase 1 SA followed by a New > Phase 2 SA. The problems I experienced was when the remote peer attempted > to start the rekey, and they would use the old Phase 1 SA to establish a > new Quick mode. I rejected this offer, since it attempted to use the old > SA... and the rekeying seemed to suffer. > > Back to my question then, what is everyone else doing to support PFS? Are > you supporting PFS for key material only? Or are you supporting PFS for > key material and identities? Has anyone else experienced any rekey > problems associated with interoperating with a vendor who has implemented > a PFS mode different from what you have implemented? > > Thanks in advance. > > Tylor > > --- > Tylor Allison tylor_allison@securecomputing.com (651) 628-1554 > Secure Computing Corporation -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. From owner-ipsec@lists.tislabs.com Tue Jan 18 07:34:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21096; Tue, 18 Jan 2000 07:34:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14365 Tue, 18 Jan 2000 09:04:40 -0500 (EST) Message-Id: <3.0.32.20000117120634.00b0fe70@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Jan 2000 12:06:36 -0500 To: Markus Friedl From: "Shawn Mamros" Subject: Re: Bruce Schneier on IPsec Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Selective quoting is such an amazing tool. One can also find the following in Schneier's paper: "Even with all the serious criticisms that we have on IPsec, it is probably the best IP security protocol available at the moment." Seems to me one should read the whole paper before drawing any conclusions. -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Tue Jan 18 10:20:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23515; Tue, 18 Jan 2000 10:19:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15292 Tue, 18 Jan 2000 11:49:13 -0500 (EST) Message-ID: <38849ABE.BF7CCBDC@redcreek.com> Date: Tue, 18 Jan 2000 08:54:22 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: wprice@cyphers.net CC: Tylor Allison , ipsec@lists.tislabs.com Subject: Re: pfs support References: <3883F466.68721069@cyphers.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Will, Will Price wrote: > > Supporting PFS involves: > > 1. Doing a second key exchange with DH in Phase 2 > 2. Deleting the Phase 1 SA immediately after the Phase 2 to dispose of the > key material involved My interpretation is that there should be an "OR" between those. That is, there is ID PFS and key PFS. I think ID PFS consists in negotiating exactly one quick mode (qm) SA per main mode (mm) SA, and key pfs consists in refreshing the key material (via a qm KE payload) for each qm SA, with no requirement for deletion of the mm SA. That's not to say that you can't delete the mm SA, but I don't interpret it as a requirement. How do others interpret this? Scott From owner-ipsec@lists.tislabs.com Tue Jan 18 12:30:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25376; Tue, 18 Jan 2000 12:30:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15721 Tue, 18 Jan 2000 13:38:50 -0500 (EST) From: Dan McDonald Message-Id: <200001181843.KAA19909@kebe.eng.sun.com> Subject: IPsec/IKE testing at Connectathon? To: ipsec@lists.tislabs.com Date: Tue, 18 Jan 2000 10:43:20 -0800 (PST) CC: audrey@vanb.com Reply-To: audrey@vanb.com X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I know we just finished a bakeoff in San Diego, but we would like to host IPSec/IKE testing at Connectathon, the big interoperability event sponsored by Sun. If you're interested, check out the Connectathon web page: http://www.connectathon.org/ And if you have further questions, reply to Audrey Van Bellhingham (audrey@vanb.com). Thanks, Dan From owner-ipsec@lists.tislabs.com Tue Jan 18 12:30:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25384; Tue, 18 Jan 2000 12:30:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15426 Tue, 18 Jan 2000 12:35:23 -0500 (EST) Date: Tue, 18 Jan 2000 12:40:02 -0500 Message-Id: <200001181740.MAA22925@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: skelly@redcreek.com Cc: wprice@cyphers.net, allison@securecomputing.com, ipsec@lists.tislabs.com Subject: Re: pfs support References: <3883F466.68721069@cyphers.net> <38849ABE.BF7CCBDC@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> Hi Will, Will Price wrote: >> Supporting PFS involves: >> >> 1. Doing a second key exchange with DH in Phase 2 2. Deleting the >> Phase 1 SA immediately after the Phase 2 to dispose of the key >> material involved Scott> My interpretation is that there should be an "OR" between Scott> those. That is, there is ID PFS and key PFS. I think ID PFS Scott> consists in negotiating exactly one quick mode (qm) SA per Scott> main mode (mm) SA, and key pfs consists in refreshing the key Scott> material (via a qm KE payload) for each qm SA, with no Scott> requirement for deletion of the mm SA. That's not to say that Scott> you can't delete the mm SA, but I don't interpret it as a Scott> requirement. How do others interpret this? The description is somewhat confusing. But section 8 of RFC 2409 supports what Will said. On the other hand, section 5.4 supports what you said -- because it talks only about PFS of keys while section 8 talks about PFS of keys and of identities both. paul From owner-ipsec@lists.tislabs.com Tue Jan 18 15:30:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27862; Tue, 18 Jan 2000 15:30:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16440 Tue, 18 Jan 2000 16:37:14 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A131@exchange> From: Andrew Krywaniuk To: Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime Date: Tue, 18 Jan 2000 16:43:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA16437 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Joern. From a business perspective, I don't think this is a feature that most of our customers are asking for. However, I don't see why that is justification for excluding a feature that is necessary for maximum security. While it may seem unlikely that encrypted kbs will ever be the strongest factor in Isakmp SA degredation, it is theoretically possible, and an implementation that wants to enforce very strict security rules should be able to use them. Of course, kb lifetimes should never be used in isolation. They should be used in conjunction with time-based lifetimes and the proposed new "number of QMs" lifetime. Also, I hope that the theoretical necessity of kb lifetimes will not be used as a political argument against implementations that send additional data (Ike-cfg, XAuth, keep-alives, whatever) on the Isakmp channel. There are essentially two opinions concerning the removal of the kb lifetime notify -- one pro, one con: Pro: Implementations are not required to send lifetime notifies. If you want to enforce a kb lifetime, go ahead -- just don't tell me about it. Con: Implementations are not required to interpret lifetime notifies. Sending the kb lifetime notify does not hinder interoperability. In fact, as has been pointed out on this list before, not sending lifetime notifies can hinder interoperability with some implementations. One concern about the implementation of kb-based expiry is that it can cause interoperability problems if one side expires the SA in the middle of a QM negotiation (the same could happen with time-based expiry but the window is much smaller). The solution is to set a large deletion threshhold. Say you set your expiry limit to 10 Mb. Then you can set your app to delete/rekey the SA whenever you reach 9 Mb UNLESS you are already in the middle of an exchange. The 1 Mb cushion prevents you from disrupting an exchange that is already in progress. Note that this solution does not require any cooperation by the peer. When one side is using kb lifetimes and the other is not, interoperability is not affected. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. -----Original Message----- From: Joern Sierwald [mailto:joern@datafellows.com] Sent: Thursday, January 13, 2000 11:50 AM To: ipsec@lists.tislabs.com Subject: Phase 1 KB lifetime In the wednesday interop meeting there was a notion to forbid KB lifetimes in Phase 1. I see that a lifetime does not make much sense in todays use of ISAKMP. But somebody might use the ISKAMP channel to exchange a lot a data. If a system sends 10KB per second through the ISAKMP channel, a KB lifetime makes sense. Let's keep it for now. Jörn Sierwald From owner-ipsec@lists.tislabs.com Tue Jan 18 16:05:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28330; Tue, 18 Jan 2000 16:05:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16608 Tue, 18 Jan 2000 17:35:07 -0500 (EST) Message-Id: <200001182237.OAA17365@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: issues raised at VPN interoperability workshop MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17362.948235054.1@network-alchemy.com> Date: Tue, 18 Jan 2000 14:37:35 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The eighth IPSec/IKE (now combined with L2TP, PPTP, PPPoE) interoperability workshop was held in beautiful San Diego, California last week. Issues raised during interoperability testing were discussed in a "town hall meeting". Not surprisingly there were no issues with AH or ESP; they're all with IKE. The issues fell into 3 basic categories: the "commit bit", certificate processing, and a catch-all of miscellaneous (or just misc.). I've added the way the issue was resolved but solicit discussion on the list before they go into the Son Of IKE. Dan. ---------------------------------------------------------------------------- Commit Bit * Can you clear the commit bit during phase 2? Yes. * Is the commit bit even mandatory? If it's not and you don't support it what do you do if it's set in an offer? Refuse it? It's mandatory. * What do you do if the commit bit is set but the responder doesn't actually send the connected message? Same as if the last message w/o the commit bit didn't arrive: retransmit and give up after X retransmissions. * The fourth message is a Quick Mode exchange message with the same message ID as the Quick Mode in which the bit was set. Cert Stuff * What do I do if I receive a CRL request and don't have a CRL? Silently ignore it? Send a notify? Same issue for a cert that I don't have. Silently ignore it. * What do I do if the signature validation fails? Send an unprotected notify? Yes. * How do you retrieve a cert chain? (punted to the PKI requirements doc) * What IKE ID should one use with a cert? This needs WG resolution and probably clarification in DOI or IKE. * What does an empty cert request payload mean? "give me a cert; any cert". * How do you request something with a type of PKCS7? (punted to the PKI requirements doc) Misc. Negotiation Stuff * If the initiator wants PFS and you don't have it configured what should you do? Similarly, if the initiator offers group 2 (5) and you have group 1 (2) configured what should you do? Similarly, variable lengthed keys for ciphers which have variable lengthed keys. General acceptance for doing what is offered provided it is not expressly prohibited by policy. * What do I do if I get IPSec packets for SAs which I don't currently have? Should I send unproteted notifies or begin an IKE exchange with that person or do nothing? This is implementation specific. * What sort of padding-- if any-- should be added to variable lengthed attributes? None. * What is the meaning of KB lifetime in phase 1 and can we do away with it? It has no meaning. A request was made to leave it but note that it is not meaningful. * Can IKE payloads be padded with more than 7 bytes? Yes. * Rekeying is an issue. Phase 1 or phase 2 or both? Tim Jenkin's Rekeying Draft addresses these. If you're having rekeying problems refer to that draft (which will be a BCP RFC, I believe). * Can you send a keylength with a fixed length algorithm? No. * Nuke the authentication-only bit. The only purpose for this bit is for Key Recovery and a request was made to remove it from RFC2408. What does the WG think? From owner-ipsec@lists.tislabs.com Tue Jan 18 16:15:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28450; Tue, 18 Jan 2000 16:15:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16650 Tue, 18 Jan 2000 17:43:13 -0500 (EST) Message-Id: <200001182245.OAA17399@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime In-reply-to: Your message of "Tue, 18 Jan 2000 16:43:29 EST." <319A1C5F94C8D11192DE00805FBBADDF0110A131@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17396.948235530.1@network-alchemy.com> Date: Tue, 18 Jan 2000 14:45:30 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to nip this in the bud. The "just go ahead and enforce a lifetime, just don't tell me about it" combined with "implementations are not required to interperet lifetime notifies" is probably the reason that people have problems with rekeying. It is _never_ a good idea to just enforce a lifetime without telling the peer (assuming, as we all remember from 3rd grade, makes an ass out of you and me). Similarly it is _never_ a good idea to ignore the lifetime notify a peer gives you. If it has to be expressly stated in the RFC (I'm a bit surprised by this line of reasoning though) then so be it. Dan. On Tue, 18 Jan 2000 16:43:29 EST you wrote > > There are essentially two opinions concerning the removal of the kb lifetime > notify -- one pro, one con: > > Pro: Implementations are not required to send lifetime notifies. If you want > to enforce a kb lifetime, go ahead -- just don't tell me about it. > > Con: Implementations are not required to interpret lifetime notifies. > Sending the kb lifetime notify does not hinder interoperability. In fact, as > has been pointed out on this list before, not sending lifetime notifies can > hinder interoperability with some implementations. From owner-ipsec@lists.tislabs.com Tue Jan 18 17:21:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29276; Tue, 18 Jan 2000 17:21:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16790 Tue, 18 Jan 2000 18:22:37 -0500 (EST) Message-ID: <19398D273324D3118A2B0008C7E9A569027517F8@SIT.platinum.corp.microsoft.com> From: Brian Swander To: "'ipsec@lists.tislabs.com'" Subject: Comment on a VPN PFS issue: Date: Tue, 18 Jan 2000 15:26:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF620B.7EDE9C46" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF620B.7EDE9C46 Content-Type: text/plain; charset="iso-8859-1" >From Dan's mail: Misc. Negotiation Stuff * If the initiator wants PFS and you don't have it configured what should you do? Similarly, if the initiator offers group 2 (5) and you have group 1 (2) configured what should you do? Similarly, variable lengthed keys for ciphers which have variable lengthed keys. General acceptance for doing what is offered provided it is not expressly prohibited by policy. Sorry I wasn't able to comment in person at the bakeoff. We found that this suggestion is difficult to support in the field. For instance, take the PFS example. Initiator configured with QM PFS, responder not configured with QM PFS. When the responder gets the QM, since doing PFS is more secure, its no big deal for the responder to allow the PFS connection. However, the support hit comes if the responder initiates a rekey. Now, the responder will not propose PFS, and the initiator will expect it, so the initiator MUST fail the negotiation. This is much more difficult to troubleshoot in the field than if it failed every time. So I'd recommend either outright failure of the negotiation in the first case to signal to the admins that something is amiss, or have the responder remember that it needs to do PFS with the peer. bs ------_=_NextPart_001_01BF620B.7EDE9C46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comment on a VPN PFS issue:

From Dan's mail:
Misc. Negotiation Stuff
  * If the initiator wants = PFS and you don't have it configured what should
    you do? = Similarly, if the initiator offers group 2 (5) and you have = group
    1 (2) = configured what should you do? Similarly, variable lengthed keys
    for ciphers = which have variable lengthed keys.
General acceptance for doing = what is offered provided it is not expressly
prohibited by policy.


Sorry I wasn't able to comment = in person at the bakeoff.  We found that this suggestion is = difficult to support in the field.  For instance, take the PFS = example.  Initiator configured with QM PFS, responder not = configured with QM PFS.  When the responder gets the QM, since = doing PFS is more secure, its no big deal for the responder to allow = the PFS connection.  However, the support hit comes if the = responder initiates a rekey.  Now, the responder will not propose = PFS, and the initiator will expect it, so the initiator MUST fail the = negotiation.  This is much more difficult to troubleshoot in the = field than if it failed every time.  So I'd recommend either = outright failure of the negotiation in the first case to signal to the = admins that something is amiss, or have the responder remember that it = needs to do PFS with the peer.

bs

------_=_NextPart_001_01BF620B.7EDE9C46-- From owner-ipsec@lists.tislabs.com Wed Jan 19 08:10:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07977; Wed, 19 Jan 2000 08:10:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19738 Wed, 19 Jan 2000 08:54:23 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A1BD@exchange> From: Tim Jenkins To: Dan Harkins , ipsec@lists.tislabs.com Subject: RE: issues raised at VPN interoperability workshop Date: Wed, 19 Jan 2000 09:00:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Tim Jenkins Newbridge Networks Corporation tjenkins@timestep.com http://www.timestep.com timj@newbridge.com http://www.newbridge.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: January 18, 2000 5:38 PM > To: ipsec@lists.tislabs.com > Subject: issues raised at VPN interoperability workshop > ... > > Commit Bit > > * Can you clear the commit bit during phase 2? > > Yes. > What does this mean? Is this asking "Can the commit bit be set to 0 in quick mode?" (This is normal operation, so I doubt this was the question.) Is this asking "Can the commit bit be set to 0 in the third quick mode message by the initiator if set in the second by the responder?" (Probably not supposed to be. One vendor interpreted this as rejection of the bit, another ignored it. Maybe this should be clarified as well.) Additionally, there was talk about allowing the initiator of a quick mode exchange to set the commit bit. I'd like to propose that this be explicitly disallowed, and that it explicitly stated that only the responder of a quick mode exchange may set the commit bit. Reasons: 1) The benefit is minimal, if any. 2) It increases complexity. Does anyone do this? Does anyone support this case as responder? ... > > * Rekeying is an issue. Phase 1 or phase 2 or both? > > Tim Jenkin's Rekeying Draft addresses these. If you're having rekeying > problems refer to that draft (which will be a BCP RFC, I believe). Just to re-iterate: I plan on submitting it as informational only. When it was asked who implemented it, the number of hands shown was less than I've been told about privately, BTW. The most recent version is at . It was submitted two weeks ago, but I didn't see the announcement posted on the list. It contains significant changes in the phase 1 re-keying section to try to capture the conclusions of the WG exchanges on that topic. ... > > * Nuke the authentication-only bit. > > The only purpose for this bit is for Key Recovery and a > request was made > to remove it from RFC2408. What does the WG think? > The Niels-Schneier paper makes a good case for removal of this as well. Let's do it. From owner-ipsec@lists.tislabs.com Wed Jan 19 08:59:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08721; Wed, 19 Jan 2000 08:59:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20007 Wed, 19 Jan 2000 10:10:07 -0500 (EST) Date: Wed, 19 Jan 2000 10:14:38 -0500 Message-Id: <200001191514.KAA24417@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: akrywaniuk@TimeStep.com, joern@datafellows.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime References: <319A1C5F94C8D11192DE00805FBBADDF0110A131@exchange> <200001182245.OAA17399@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> I'd like to nip this in the bud. The "just go ahead and enforce Dan> a lifetime, just don't tell me about it" combined with Dan> "implementations are not required to interperet lifetime Dan> notifies" is probably the reason that people have problems with Dan> rekeying. I don't think so. The reason people are having problems with rekeying is that the rekeying process is subject to all sorts of timing windows and race conditions, as Tim Jenkins has documented in fine detail. If the case you mention is an issue at all, it's just a small one out of dozens. Dan> It is _never_ a good idea to just enforce a lifetime without Dan> telling the peer (assuming, as we all remember from 3rd grade, Dan> makes an ass out of you and me). I quite disagree. The protocol works if someone rekeys at a time of their choosing for reasons of their choosing. Or at least it appears to; if it doesn't work for that case then the protocol is defective and needs to be repaired. Therefore, it isn't actually necessary to tell the peer about lifetimes you enforce. I still don't understand why that stuff is in the protocol at all. Dan> Similarly it is _never_ a good Dan> idea to ignore the lifetime notify a peer gives you. Ditto. paul From owner-ipsec@lists.tislabs.com Wed Jan 19 09:25:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09172; Wed, 19 Jan 2000 09:25:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20086 Wed, 19 Jan 2000 10:39:21 -0500 (EST) Date: Wed, 19 Jan 2000 10:44:00 -0500 Message-Id: <200001191544.KAA24446@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com Subject: Re: issues raised at VPN interoperability workshop References: <200001182237.OAA17365@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> * Nuke the authentication-only bit. Dan> The only purpose for this bit is for Key Recovery and a request Dan> was made to remove it from RFC2408. Wow, that sure isn't clear from the RFC. If that's indeed all that it is good for, then yes, for RFC 1984 compliance and other good reasons it should be removed. paul From owner-ipsec@lists.tislabs.com Wed Jan 19 10:02:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09696; Wed, 19 Jan 2000 10:02:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20294 Wed, 19 Jan 2000 11:18:37 -0500 (EST) Date: Wed, 19 Jan 2000 11:22:28 -0500 Message-Id: <200001191622.LAA25130@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smamros@nortelnetworks.com Cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime References: <3.0.32.20000119112115.00b305b0@zbl6c000.corpeast.baynetworks.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Shawn" == Shawn Mamros writes: Dan> It is _never_ a good idea to just enforce a lifetime without Dan> telling the peer (assuming, as we all remember from 3rd grade, Dan> makes an ass out of you and me). >> I quite disagree. The protocol works if someone rekeys at a time >> of their choosing for reasons of their choosing. Or at least it >> appears to; if it doesn't work for that case then the protocol is >> defective and needs to be repaired. >> >> Therefore, it isn't actually necessary to tell the peer about >> lifetimes you enforce. I still don't understand why that stuff is >> in the protocol at all. Shawn> Consider the following scenario: Shawn> A Quick Mode initiator (QMi) sends a proposal for IPsec SAs Shawn> with a lifetime of one hour. The Quick Mode responder (QMr) Shawn> decides it wants to use a lifetime of only half an hour Shawn> instead, but does not use the RESPONDER-LIFETIME Notify Shawn> message to inform QMi that it is doing so. Shawn> Half an hour elapses. QMr deletes the IPsec SAs. QMr sends a Shawn> Delete to QMi, but the Delete gets lost somewhere along the Shawn> way. (Even if we have an acknowledged Informational exchange, Shawn> Deletes can still get lost; QMr is eventually going to have to Shawn> give up and delete the SAs anyways, right?) Well, yes, the lack of acknowledged delete is a known bug that's being fixed. Shawn> QMr has no further traffic requiring an IPsec SA to QMi, so Shawn> doesn't bother proposing one. QMi, however, does have traffic Shawn> and, believing there's still valid IPsec SAs, uses them. QMr, Shawn> seeing this IPsec traffic for IPsec SAs it doesn't have, drops Shawn> the packets. This continues on for another half hour, until Shawn> QMi finally deletes the IPsec SAs and negotiates new ones, and Shawn> the cycle starts again... Right. Now consider a similar situation with byte count limits rather than time limits. And assume that the network is very lossy (because otherwise acked deletes work). In that case, the sender's byte count is substantially greater than the receiver's byte count. So the sender will rekey much sooner than the receiver expects. You get the same problem then, and responder-lifetime isn't any help. paul From owner-ipsec@lists.tislabs.com Wed Jan 19 10:03:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09727; Wed, 19 Jan 2000 10:03:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20288 Wed, 19 Jan 2000 11:17:08 -0500 (EST) Message-Id: <200001191621.IAA10780@gallium.network-alchemy.com> To: Paul Koning cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: Re: issues raised at VPN interoperability workshop In-reply-to: Your message of "Wed, 19 Jan 2000 10:44:00 EST." <200001191544.KAA24446@tonga.xedia.com> Date: Wed, 19 Jan 2000 08:21:14 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, As strongly as I feel about (against) government key escrow, I don't have a problem with key escrow, per se. Though the authentication-only bit can be used for this, so can any number of other mechanisms. The question should be decided on the merit of the option of having an authenticated but unecrypted ISAKMP message and not on, "it smells like Clipper so we need to kill it." Derrell From owner-ipsec@lists.tislabs.com Wed Jan 19 10:15:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09956; Wed, 19 Jan 2000 10:15:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20359 Wed, 19 Jan 2000 11:30:30 -0500 (EST) Message-Id: <3.0.32.20000119112115.00b305b0@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Jan 2000 11:21:16 -0500 To: Paul Koning From: "Shawn Mamros" Subject: Re: Phase 1 KB lifetime Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Dan> It is _never_ a good idea to just enforce a lifetime without > Dan> telling the peer (assuming, as we all remember from 3rd grade, > Dan> makes an ass out of you and me). > >I quite disagree. The protocol works if someone rekeys at a time of >their choosing for reasons of their choosing. Or at least it appears >to; if it doesn't work for that case then the protocol is defective >and needs to be repaired. > >Therefore, it isn't actually necessary to tell the peer about >lifetimes you enforce. I still don't understand why that stuff is in >the protocol at all. Consider the following scenario: A Quick Mode initiator (QMi) sends a proposal for IPsec SAs with a lifetime of one hour. The Quick Mode responder (QMr) decides it wants to use a lifetime of only half an hour instead, but does not use the RESPONDER-LIFETIME Notify message to inform QMi that it is doing so. Half an hour elapses. QMr deletes the IPsec SAs. QMr sends a Delete to QMi, but the Delete gets lost somewhere along the way. (Even if we have an acknowledged Informational exchange, Deletes can still get lost; QMr is eventually going to have to give up and delete the SAs anyways, right?) QMr has no further traffic requiring an IPsec SA to QMi, so doesn't bother proposing one. QMi, however, does have traffic and, believing there's still valid IPsec SAs, uses them. QMr, seeing this IPsec traffic for IPsec SAs it doesn't have, drops the packets. This continues on for another half hour, until QMi finally deletes the IPsec SAs and negotiates new ones, and the cycle starts again... Now, tell me again why we don't need RESPONDER-LIFETIME? -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Wed Jan 19 11:34:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11018; Wed, 19 Jan 2000 11:34:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20681 Wed, 19 Jan 2000 12:53:53 -0500 (EST) Message-Id: <200001191756.JAA19490@potassium.network-alchemy.com> To: Paul Koning cc: akrywaniuk@TimeStep.com, joern@datafellows.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime In-reply-to: Your message of "Wed, 19 Jan 2000 10:14:38 EST." <200001191514.KAA24417@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19487.948304567.1@network-alchemy.com> Date: Wed, 19 Jan 2000 09:56:08 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000 10:14:38 EST you wrote > > Dan> It is _never_ a good idea to just enforce a lifetime without > Dan> telling the peer (assuming, as we all remember from 3rd grade, > Dan> makes an ass out of you and me). > > I quite disagree. The protocol works if someone rekeys at a time of > their choosing for reasons of their choosing. Or at least it appears > to; if it doesn't work for that case then the protocol is defective > and needs to be repaired. The protocol may work (or at least appear to-- quite a weak statement) but is that a reason to do this? No. You're free to rekey anytime you want but if you choose to enforce a lifetime different than that which you _expressly agreed to_ why wouldn't you want to notify the peer? The only reason not to do this I can see is programmer laziness. > Therefore, it isn't actually necessary to tell the peer about > lifetimes you enforce. I still don't understand why that stuff is in > the protocol at all. To minimize the problematic windows that Tim Jenkins has documented in fine detail. > Dan> Similarly it is _never_ a good > Dan> idea to ignore the lifetime notify a peer gives you. > > Ditto. Ditto. Dan. From owner-ipsec@lists.tislabs.com Wed Jan 19 11:37:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11058; Wed, 19 Jan 2000 11:37:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20720 Wed, 19 Jan 2000 12:56:51 -0500 (EST) Message-Id: <200001191751.MAA20215@linus.mitre.org> In-reply-to: "Shawn Mamros"'s message of Mon, 17 Jan 2000 12:06:36 -0500 To: "Shawn Mamros" , Markus Friedl cc: guttman@mitre.org (Joshua D. Guttman), ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec Reply-To: guttman@mitre.org (Joshua D. Guttman) References: <3.0.32.20000117120634.00b0fe70@zbl6c000.corpeast.baynetworks.com> Date: Wed, 19 Jan 2000 12:51:22 -0500 From: "Joshua D. Guttman" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > fyi, > > http://www.counterpane.com/ipsec.pdf > http://www.counterpane.com/ipsec.ps.zip Snippets aside, the paper raises a lot of important questions, and it would be worthwhile to step back from the details of IPsec to talk about them. The paper includes political, technical, and expository challenges to the current IPsec. I'll give a sample of each: 1. Political: Would we get better results with a process modeled on the NIST AES competition, rather than the current IETF committee process? 2. Technical: Could the protocols be simplified greatly without undermining their usefulness? For instance, - could transport mode be eliminated? - could AH be scrapped in favor of ESP with authentication? - could ISAKMP and IKE be significantly simplified, sharpened, and disentangled from each other? 3. Expository: Where is it explained what the overall security goals of the IPsec enterprise are, and how all the ingredients fit together to meet those security goals? It may be that the authors are ill-informed or misinformed or misguided in some of their comments. But that could also be a good reason to discuss the paper here! By the way: The paper has in fact two authors, Niels Ferguson and Bruce Schneier. Joshua -- Joshua D. Guttman MITRE, Mail Stop A150 202 Burlington Rd. Tel: +1 781 271 2654 Bedford, MA 01730-1420 USA Fax: +1 781 271 3816 From owner-ipsec@lists.tislabs.com Wed Jan 19 11:37:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11069; Wed, 19 Jan 2000 11:37:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20459 Wed, 19 Jan 2000 11:53:53 -0500 (EST) Date: Wed, 19 Jan 2000 11:57:24 -0500 Message-Id: <200001191657.LAA28431@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smamros@nortelnetworks.com Cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime References: <3.0.32.20000119114958.00b33140@zbl6c000.corpeast.baynetworks.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Shawn" == Shawn Mamros writes: Shawn> At 11:22 AM 1/19/2000 -0500, Paul Koning wrote: >> Now consider a similar situation with byte count limits rather >> than time limits. And assume that the network is very lossy >> (because otherwise acked deletes work). In that case, the >> sender's byte count is substantially greater than the receiver's >> byte count. So the sender will rekey much sooner than the >> receiver expects. >> >> You get the same problem then, and responder-lifetime isn't any >> help. Shawn> But in that case, the sender *does* rekey. Rekeying sooner Shawn> than one expects shouldn't cause a problem, should it? That's what I argued. Perhaps there's a difference in assumptions: I assumed that expiration causes rekeying, while you assumed it causes only SA deletion, not (by itself) rekeying. That makes a bit of difference. Then again, it doesn't completely affect the answer, because if the traffic stops at the right place you might still end up not rekeying if you only rekey on traffic occuring *after* expiration. Furthermore, if the network is so messed up that acknowledged deletes don't work, rekeying might not either. Bottom line is that IKE/IPSEC isn't fully self-stabilizing; it doesn't recover (in short time) from a situation where one side has SAs and the other does not -- however that situation may have come about. There's a conflict between self-stabilization and robustness in the face of DOS attack, unfortunately. That shows up in Dan's summary: > * What do I do if I get IPSec packets for SAs which I don't currently have? > Should I send unproteted notifies or begin an IKE exchange with that person > or do nothing? > > This is implementation specific. The safest answer is "do nothing" but that is also exactly the design choice for non-self-stabilitization. paul From owner-ipsec@lists.tislabs.com Wed Jan 19 11:53:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11337; Wed, 19 Jan 2000 11:53:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20948 Wed, 19 Jan 2000 13:25:22 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A311@exchange> From: Andrew Krywaniuk To: Dan Harkins , Andrew Krywaniuk Cc: Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime Date: Wed, 19 Jan 2000 13:31:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not saying that I'm not in favour of the responder lifetime. In fact, our code both parses and sends them. But are you saying that only lifetimes that both peers can agree on should be allowed? What about people who want to delete their phase 1s under low memory conditions? What about people who want to use inactivity timeouts? What about people who want to delete/rekey their SAs if they detect a security violation. Should these actions be explicitly forbidden by the spec because they can't be accurately described in a responder lifetime notify? Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. -----Original Message----- From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] Sent: Tuesday, January 18, 2000 5:46 PM To: Andrew Krywaniuk Cc: Joern Sierwald; ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime I'd like to nip this in the bud. The "just go ahead and enforce a lifetime, just don't tell me about it" combined with "implementations are not required to interperet lifetime notifies" is probably the reason that people have problems with rekeying. It is _never_ a good idea to just enforce a lifetime without telling the peer (assuming, as we all remember from 3rd grade, makes an ass out of you and me). Similarly it is _never_ a good idea to ignore the lifetime notify a peer gives you. If it has to be expressly stated in the RFC (I'm a bit surprised by this line of reasoning though) then so be it. Dan. On Tue, 18 Jan 2000 16:43:29 EST you wrote > > There are essentially two opinions concerning the removal of the kb lifetime > notify -- one pro, one con: > > Pro: Implementations are not required to send lifetime notifies. If you want > to enforce a kb lifetime, go ahead -- just don't tell me about it. > > Con: Implementations are not required to interpret lifetime notifies. > Sending the kb lifetime notify does not hinder interoperability. In fact, as > has been pointed out on this list before, not sending lifetime notifies can > hinder interoperability with some implementations. From owner-ipsec@lists.tislabs.com Wed Jan 19 12:19:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11713; Wed, 19 Jan 2000 12:19:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21081 Wed, 19 Jan 2000 13:47:04 -0500 (EST) Message-Id: <200001191849.KAA19633@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime In-reply-to: Your message of "Wed, 19 Jan 2000 13:31:25 EST." <319A1C5F94C8D11192DE00805FBBADDF0110A311@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19630.948307773.1@network-alchemy.com> Date: Wed, 19 Jan 2000 10:49:33 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000 13:31:25 EST you wrote > > But are you saying that only lifetimes that both peers can agree on should > be allowed? > > What about people who want to delete their phase 1s under low memory > conditions? > What about people who want to use inactivity timeouts? > What about people who want to delete/rekey their SAs if they detect a > security violation. > > Should these actions be explicitly forbidden by the spec because they can't > be accurately described in a responder lifetime notify? Those are quite different that what you said. And it is not at all what I said. You can delete your SAs anytime you want. You can set a panic timer to reboot your box every hour on the hour. That does not violate the protocol. What I was saying is that when someone sends you a message telling you that the lifetime you just negotiated should be less you should not just skip over it and go merrrily on your way assuming that the SA will be deleted when, in fact, it will not. That way lies problems. I'm not talking about forbidding perfectly common sense things (which, by the way don't really have much to do with the protocol) I'm talking about requiring perfectly common sense things (which do). Dan. From owner-ipsec@lists.tislabs.com Wed Jan 19 12:19:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11731; Wed, 19 Jan 2000 12:19:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21038 Wed, 19 Jan 2000 13:41:44 -0500 (EST) Message-ID: From: Sankar Ramamoorthi To: "'Paul Koning'" , smamros@nortelnetworks.com Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime Date: Wed, 19 Jan 2000 10:46:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Paul Koning [pkoning@xedia.com] >Sent: Wednesday, January 19, 2000 8:57 AM >To: smamros@nortelnetworks.com >Cc: ipsec@lists.tislabs.com >Subject: Re: Phase 1 KB lifetime > >>>>>> "Shawn" == Shawn Mamros writes: > > Shawn> At 11:22 AM 1/19/2000 -0500, Paul Koning wrote: > >> Now consider a similar situation with byte count limits rather > >> than time limits. And assume that the network is very lossy > >> (because otherwise acked deletes work). In that case, the > >> sender's byte count is substantially greater than the receiver's > >> byte count. So the sender will rekey much sooner than the > >> receiver expects. > >> > >> You get the same problem then, and responder-lifetime isn't any > >> help. > > Shawn> But in that case, the sender *does* rekey. Rekeying sooner > Shawn> than one expects shouldn't cause a problem, should it? > >That's what I argued. > >Perhaps there's a difference in assumptions: I assumed that expiration >causes rekeying, while you assumed it causes only SA deletion, not (by >itself) rekeying. That makes a bit of difference. > >Then again, it doesn't completely affect the answer, because if the >traffic stops at the right place you might still end up not rekeying >if you only rekey on traffic occuring *after* expiration. >Furthermore, if the network is so messed up that acknowledged deletes >don't work, rekeying might not either. > >Bottom line is that IKE/IPSEC isn't fully self-stabilizing; it doesn't >recover (in short time) from a situation where one side has SAs and >the other does not -- however that situation may have come about. > >There's a conflict between self-stabilization and robustness in the >face of DOS attack, unfortunately. That shows up in Dan's summary: > >> * What do I do if I get IPSec packets for SAs which I don't currently have? >> Should I send unproteted notifies or begin an IKE exchange with that person >> or do nothing? >> >> This is implementation specific. > >The safest answer is "do nothing" but that is also exactly the design >choice for non-self-stabilitization. Some questions, Are you saying that a design choice for non-self-stabilization is acceptable? Since as you mention before that the situation that one side has SA and another side does can come about in many ways, isn't self-stabilization all the more important? Why is "do nothing" a safe choice for the receiver of the bad IPSec packet (IPSec packet without SA)? How does sending a 'invalid spi' notify to the sender of the ipsec packet affect the safety of the receiver? Isn't sending a notify better than doing nothing? >From the sender (of the stale ipsec packet) point of view it may be useful to receive a notify immediately - if it can be authenticated in some way than it can even act on it immediately. > > paul Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Wed Jan 19 12:36:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11922; Wed, 19 Jan 2000 12:36:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21175 Wed, 19 Jan 2000 13:57:54 -0500 (EST) Date: Wed, 19 Jan 2000 14:02:35 -0500 Message-Id: <200001191902.OAA02766@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sankar@vpnet.com Cc: smamros@nortelnetworks.com, ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sankar" == Sankar Ramamoorthi writes: >> ... >> Bottom line is that IKE/IPSEC isn't fully self-stabilizing; it >> doesn't recover (in short time) from a situation where one side >> has SAs and the other does not -- however that situation may have >> come about. >> >> There's a conflict between self-stabilization and robustness in >> the face of DOS attack, unfortunately. ... >> The safest answer is "do nothing" but that is also exactly the >> design choice for non-self-stabilitization. Sankar> Are you saying that a design choice for Sankar> non-self-stabilization is acceptable? No (though IPSec isn't the only standard protocol that suffers from this, nor the one to suffer the most). What I meant to say is that this is the design choice that has been made, whether with the full realization of what this means or not is unclear. Sankar> Since as you mention Sankar> before that the situation that one side has SA and another Sankar> side does can come about in many ways, isn't Sankar> self-stabilization all the more important? Sure. In fact, I'd say that self-stabilization is always important and always should be a design goal for any protocol, not to be set aside except for very weighty reasons. Sankar> Why is "do nothing" a safe choice for the receiver of the bad Sankar> IPSec packet (IPSec packet without SA)? How does sending a Sankar> 'invalid spi' notify to the sender of the ipsec packet affect Sankar> the safety of the receiver? Isn't sending a notify better Sankar> than doing nothing? Not necessarily. Sending a notify consumes resources that are not consumed by simply discarding the offending packet. Since DOS attacks basically are attempts to get the receiver to consume lots of resources, the less resources you use in dealing with invalid packets the safer you are from DOS attacks. >> From the sender (of the stale ipsec packet) point of view it may Sankar> be useful to receive a notify immediately - if it can be Sankar> authenticated in some way than it can even act on it Sankar> immediately. True, but of course that's a big "if". Another SA problem scenario is where both sides have SAs, but they don't match. If that is true for the Phase 1 SAs as well, you cannot authenticate the notifies even if they were sent. And you are wise not to accept them unauthenticated because then you have a really BIG DOS attack opportunity! paul From owner-ipsec@lists.tislabs.com Wed Jan 19 13:20:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12404; Wed, 19 Jan 2000 13:20:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21533 Wed, 19 Jan 2000 14:45:46 -0500 (EST) Date: Wed, 19 Jan 2000 14:50:29 -0500 Message-Id: <200001191950.OAA03021@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: akrywaniuk@TimeStep.com Cc: ipsec@lists.tislabs.com Subject: Re: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) References: <319A1C5F94C8D11192DE00805FBBADDF0110A362@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Sankar> Why is "do nothing" a safe choice for the receiver of the bad Sankar> IPSec packet (IPSec packet without SA)? How does sending a Sankar> 'invalid spi' notify to the sender of the ipsec packet affect Sankar> the safety of the receiver? Isn't sending a notify better Sankar> than doing nothing? Andrew> Paul: >> Not necessarily. Sending a notify consumes resources that are not >> consumed by simply discarding the offending packet. Since DOS >> attacks basically are attempts to get the receiver to consume lots >> of resources, the less resources you use in dealing with invalid >> packets the safer you are from DOS attacks. Andrew> Andrew: Andrew> Not exactly. Andrew> You can't realistically ever fully protect against DoS Andrew> attacks. But a good rule of thumb is to force a DoS attacker Andrew> to consume as much of his own computing power as he consumes Andrew> of yours. I'd rather do better, because DOS attackers can operate in packs, so they have a lot more resources than you do. Andrew> You receive a spoofed packet and it causes you to perform a Andrew> DH exponentiation = BAD. You receive a spoofed packet and it Andrew> causes you to generate an unencrypted notify = OK. Andrew> Generating the unencrypted notify could involve nothing more Andrew> than a hash table lookup (which you had to do anyway to Andrew> determine that the spi/cookie was invalid), a couple of Andrew> memcpys, and a SendBuffer. Or it may be a lot more costly. IPSEC may be in hardware while IKE is in a control processor. Andrew> Plus, sending the unencrypted notify allows the peer to Andrew> generate an alarm: SOMEONE IS SPOOFING PACKETS!!! (since Andrew> either you generated the notify in response to a bad Andrew> spi/cookie or the notify itself was spoofed) Certainly you can do logging or alarms based on bad input packets, but that's a local matter, not a topic for the protocol specs since it doesn't affect the protocol. Andrew> But if you respond to the unencrypted notify by initiating a Andrew> new SA then you are at the mercy of a DoS attacker. Right. If generating an unauthenticated notify allows the receiver of that notify to take a useful action, it might make sense to take the resource hit and generate that notify. But I see no way that a receiver of such a message can take any useful action. Well, maybe you could log them, because clearly someone may be attacking you or the other end if you see those messages. On the other hand, the issue was that a half-open connection (SAs on one side but not the other) is not self-correcting. You CANNOT use unauthenticated notifies to fix that for the reasons you mentioned. Since you cannot, it makes sense for the spec to say that generating such a notify is optional and you're also allowed to take no (protocol) action at all for invalid SPI packets. paul From owner-ipsec@lists.tislabs.com Wed Jan 19 13:23:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12436; Wed, 19 Jan 2000 13:23:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21562 Wed, 19 Jan 2000 14:47:09 -0500 (EST) Message-Id: <200001191949.LAA19942@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime In-reply-to: Your message of "Wed, 19 Jan 2000 14:24:03 EST." <319A1C5F94C8D11192DE00805FBBADDF0110A34C@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19939.948311376.1@network-alchemy.com> Date: Wed, 19 Jan 2000 11:49:36 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000 14:24:03 EST you wrote > > Fine. As I said, our code has support for the responder lifetime notify. We > send it and parse it. If the responder adjusts the lifetime, we honour it > AND we send the delete. I'm not arguing with you on this point. Bully for you. What your product does is not the issue here. > I'm saying that if someone was paranoid enough to want to expire their SAs > based on a kb lifetime, which is a possible weakness (even if some consider > it too unlikely or too unworthy to protect against), then they should go > ahead and delete their SAs regardless of whether there is an assigned magic > number for kb lifetimes in the draft. > > Should they send a responder lifetime notify regarding this constraint? I don't think you understand what the responder lifetime notify is used for. When a lifetime has been reached you don't send the notify, you chain it to your Quick Mode message during negotiation so both sides have a consistent view of the world at SA establishment time. Whether a magic number exists for kb lifetimes in phase 1 is unrelated to the use of responder notifies. > On one hand, you are saying that an implementation should notify the peer of > all of its lifetime constraints. On the other hand, you want to remove (or > at least deprecate) the magic number associated with this lifetime > constraint. I'm arguing _against_ ignoring messages from the peer and blithely assuming that things are as you believe they are when they aren't (which you'd know had you parsed the message). > If the user values strict security over strict standards compliance then > they have no choice but to enforce the kb lifetime rule without sending a > notify. > > If you want to prevent implementations which enforce local kb lifetime rules > from sending a notify then fine... just don't try to legislate policy. Nobody's "legislating policy". And the enforcement of kb lifetime is not related to the use of the responder lifetime. Please read the relevent documents. Dan. From owner-ipsec@lists.tislabs.com Wed Jan 19 13:25:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12467; Wed, 19 Jan 2000 13:25:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21443 Wed, 19 Jan 2000 14:32:02 -0500 (EST) Date: Wed, 19 Jan 2000 14:36:37 -0500 Message-Id: <200001191936.OAA03009@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dharkins@network-alchemy.com Cc: akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime References: <319A1C5F94C8D11192DE00805FBBADDF0110A311@exchange> <200001191849.KAA19633@potassium.network-alchemy.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> On Wed, 19 Jan 2000 13:31:25 EST you wrote >> ... >> What about people who want to delete their phase 1s under low >> memory conditions? ... Dan> Those are quite different that what you said. And it is not at Dan> all what I said. Dan> You can delete your SAs anytime you want. You can set a panic Dan> timer to reboot your box every hour on the hour. That does not Dan> violate the protocol. What I was saying is that when someone Dan> sends you a message telling you that the lifetime you just Dan> negotiated should be less you should not just skip over it and Dan> go merrrily on your way assuming that the SA will be deleted Dan> when, in fact, it will not. That way lies problems. If the other end tells you it's using a smaller lifetime and you ignore that message, this means you will be assuming the SA will not be delete when, in fact, it will be. The reverse of what you said. That puts the protocol in the same state as the examples Andrew mentioned. Which is why I said what I said -- it seems overkill to add a protocol mechanism that blocks ONE of the possible transitions into state X without affecting a half dozen transitions into that same state X. Yes, as Shawn pointed out, state X is not a good place to be, since the protocol doesn't necessarily recover nicely. But as you said, you are allowed to go there. Dan> I'm not talking about forbidding perfectly common sense things Dan> (which, by the way don't really have much to do with the Dan> protocol) I'm talking about requiring perfectly common sense Dan> things (which do). That depends on which aspect of common sense you're after. One aspect says "take action on all the information you have". This is what you advocate. Another view says "do not add complexity if doing so doesn't gain you much". This is my point -- the global state machine still has the same number of states, and in particular still has the same undesirable state. There are still plenty of ways to get into that state. Now, if there were a proposal to get rid of this state, and a requirement to synchronize expirations comes as part of that, that would be a different matter, but I don't see that that's particularly doable. (More likely we'd have a way to recovery quickly from getting into that state -- in which case it doesn't much matter if there are 5 or 6 ways to get there.) paul From owner-ipsec@lists.tislabs.com Wed Jan 19 13:29:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12551; Wed, 19 Jan 2000 13:29:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21461 Wed, 19 Jan 2000 14:34:10 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A362@exchange> From: Andrew Krywaniuk To: Paul Koning , Sankar@vpnet.com Cc: smamros@nortelnetworks.com, ipsec@lists.tislabs.com Subject: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) Date: Wed, 19 Jan 2000 14:40:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Sankar> Why is "do nothing" a safe choice for the receiver of the bad > Sankar> IPSec packet (IPSec packet without SA)? How does sending a > Sankar> 'invalid spi' notify to the sender of the ipsec packet affect > Sankar> the safety of the receiver? Isn't sending a notify better > Sankar> than doing nothing? Paul: > Not necessarily. Sending a notify consumes resources that are not > consumed by simply discarding the offending packet. Since > DOS attacks > basically are attempts to get the receiver to consume lots of > resources, the less resources you use in dealing with invalid packets > the safer you are from DOS attacks. Andrew: Not exactly. You can't realistically ever fully protect against DoS attacks. But a good rule of thumb is to force a DoS attacker to consume as much of his own computing power as he consumes of yours. You receive a spoofed packet and it causes you to perform a DH exponentiation = BAD. You receive a spoofed packet and it causes you to generate an unencrypted notify = OK. Generating the unencrypted notify could involve nothing more than a hash table lookup (which you had to do anyway to determine that the spi/cookie was invalid), a couple of memcpys, and a SendBuffer. Plus, sending the unencrypted notify allows the peer to generate an alarm: SOMEONE IS SPOOFING PACKETS!!! (since either you generated the notify in response to a bad spi/cookie or the notify itself was spoofed) But if you respond to the unencrypted notify by initiating a new SA then you are at the mercy of a DoS attacker. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Jan 19 13:37:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12706; Wed, 19 Jan 2000 13:37:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21632 Wed, 19 Jan 2000 14:58:03 -0500 (EST) Message-Id: <200001192000.MAA19974@potassium.network-alchemy.com> To: Paul Koning cc: akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime In-reply-to: Your message of "Wed, 19 Jan 2000 14:36:37 EST." <200001191936.OAA03009@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19971.948312030.1@network-alchemy.com> Date: Wed, 19 Jan 2000 12:00:30 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000 14:36:37 EST you wrote > >>>>> "Dan" == Dan Harkins writes: > > Dan> On Wed, 19 Jan 2000 13:31:25 EST you wrote > >> ... > >> What about people who want to delete their phase 1s under low > >> memory conditions? ... > > Dan> Those are quite different that what you said. And it is not at > Dan> all what I said. > > Dan> You can delete your SAs anytime you want. You can set a panic > Dan> timer to reboot your box every hour on the hour. That does not > Dan> violate the protocol. What I was saying is that when someone > Dan> sends you a message telling you that the lifetime you just > Dan> negotiated should be less you should not just skip over it and > Dan> go merrrily on your way assuming that the SA will be deleted > Dan> when, in fact, it will not. That way lies problems. > > If the other end tells you it's using a smaller lifetime and you > ignore that message, this means you will be assuming the SA will not > be delete when, in fact, it will be. The reverse of what you said. It is? I kinda thought that was exactly what I was saying. Do not ignore the message ("you should not skip over it") because that means that you'll be in that bad state ("That way lies problems"). > That puts the protocol in the same state as the examples Andrew > mentioned. Which is why I said what I said -- it seems overkill to > add a protocol mechanism that blocks ONE of the possible transitions > into state X without affecting a half dozen transitions into that same > state X. Yes, as Shawn pointed out, state X is not a good place to > be, since the protocol doesn't necessarily recover nicely. But as > you said, you are allowed to go there. If state X is bad and there is a a way to prevent you from getting into state X-- it isn't a 100% solution but it is a partial solution to a very common way to get into state X-- why would you not want to do it? > Dan> I'm not talking about forbidding perfectly common sense things > Dan> (which, by the way don't really have much to do with the > Dan> protocol) I'm talking about requiring perfectly common sense > Dan> things (which do). > > That depends on which aspect of common sense you're after. > > One aspect says "take action on all the information you have". This > is what you advocate. > > Another view says "do not add complexity if doing so doesn't gain you > much". This is my point -- the global state machine still has the > same number of states, and in particular still has the same > undesirable state. There are still plenty of ways to get into that > state. As someone who's implemented this feature (twice) I can tell you it's not that complicated. You're parsing the offer anyway so you know the lifetime. You presumably know your configured lifetime. If the latter is less than the former add a notify to your response. There may be plenty of ways to get in a screwed up state but one of the most common ways is no longer possible. It's possible to get in a screwed up state but that doesn't mean that efforts shouldn't be taken to prevent one from getting there. There are numerous ways I can wreck my car but that fact doesn't mean that I should ignore traffic signs. Dan. From owner-ipsec@lists.tislabs.com Wed Jan 19 13:53:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12963; Wed, 19 Jan 2000 13:53:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21329 Wed, 19 Jan 2000 14:17:52 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A34C@exchange> From: Andrew Krywaniuk To: Dan Harkins , Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime Date: Wed, 19 Jan 2000 14:24:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan: > You can delete your SAs anytime you want. You can set a panic > timer to reboot > your box every hour on the hour. That does not violate the > protocol. What > I was saying is that when someone sends you a message telling > you that the > lifetime you just negotiated should be less you should not > just skip over > it and go merrrily on your way assuming that the SA will be > deleted when, > in fact, it will not. That way lies problems. > > I'm not talking about forbidding perfectly common sense > things (which, by the > way don't really have much to do with the protocol) I'm talking about > requiring perfectly common sense things (which do). Andrew: Fine. As I said, our code has support for the responder lifetime notify. We send it and parse it. If the responder adjusts the lifetime, we honour it AND we send the delete. I'm not arguing with you on this point. I'm saying that if someone was paranoid enough to want to expire their SAs based on a kb lifetime, which is a possible weakness (even if some consider it too unlikely or too unworthy to protect against), then they should go ahead and delete their SAs regardless of whether there is an assigned magic number for kb lifetimes in the draft. Should they send a responder lifetime notify regarding this constraint? On one hand, you are saying that an implementation should notify the peer of all of its lifetime constraints. On the other hand, you want to remove (or at least deprecate) the magic number associated with this lifetime constraint. If the user values strict security over strict standards compliance then they have no choice but to enforce the kb lifetime rule without sending a notify. If you want to prevent implementations which enforce local kb lifetime rules from sending a notify then fine... just don't try to legislate policy. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Jan 19 14:11:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13259; Wed, 19 Jan 2000 14:11:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21923 Wed, 19 Jan 2000 15:42:10 -0500 (EST) Message-Id: <3.0.32.20000119114958.00b33140@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Jan 2000 11:49:58 -0500 To: Paul Koning From: "Shawn Mamros" Subject: Re: Phase 1 KB lifetime Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:22 AM 1/19/2000 -0500, Paul Koning wrote: >Now consider a similar situation with byte count limits rather than >time limits. And assume that the network is very lossy (because >otherwise acked deletes work). In that case, the sender's byte count >is substantially greater than the receiver's byte count. So the >sender will rekey much sooner than the receiver expects. > >You get the same problem then, and responder-lifetime isn't any help. But in that case, the sender *does* rekey. Rekeying sooner than one expects shouldn't cause a problem, should it? The problem is when you *don't* rekey and it's actually necessary to do so (which is what my example illustrated and which RESPONDER-LIFETIME solves). -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Wed Jan 19 14:53:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13837; Wed, 19 Jan 2000 14:53:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22130 Wed, 19 Jan 2000 16:07:43 -0500 (EST) Message-ID: <3886265E.DA67E1E0@indusriver.com> Date: Wed, 19 Jan 2000 16:02:22 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Releasing IP addresses assigned with IKECFG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Assume a security gateway assigns an IP address to a remote access client via IKECFG. How does the gateway _know_ the client is done with that IP address? You can _not_ use the expiration or deletion of the Phase 1 SA because it can be rekeyed independently of the Phase 2 SA's that presumably reference the assigned IP address. The only solution I can see is for the gateway to track all Phase 1 and 2 SA's so the IP address can be reclaimed when all SA's to the client are deleted or expired. (This requires reliable DELETE's so it can't be reliably implemented without Son of IKE). Are there other options? Does IKECFG require an extension to _release_ the IP address (and any other resources allocated via IKECFG) when the client is about to disconnect from the VPN? For example, should we add a RELEASE payload type to the set of SET, ACK, REQUEST, and REPLY? -Ben McCann P.S. I'm assuming the remote client only requests an IP address after its first Phase 1 exchange with the gateway. It should continue using that address while it has existing Phase 2 SA's independent of the rekeying activity of the Phase 1 SA. In other words, only request an address after you send INITIAL_CONTACT in a Phase 1 exchange. -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Wed Jan 19 15:47:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14535; Wed, 19 Jan 2000 15:47:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22505 Wed, 19 Jan 2000 17:06:02 -0500 (EST) Message-ID: <3886340B.E64B08B2@indusriver.com> Date: Wed, 19 Jan 2000 17:00:43 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime References: <319A1C5F94C8D11192DE00805FBBADDF0110A34C@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm sorry, but I'm confused on two points: 1. How should an IPSEC station notify a peer that it received an invalid SPI in an _IPSEC_ packet (AH, ESP, or IPCOMP)? People on this thread have mentioned sending NOTIFY messages with INVALID-SPI and others have mentioned sending DELETES. Both RFC 2408 and draft-ietf-ipsec-notifymsg-02.txt state the INVALID-SPI notify message should be sent when an invalid SPI is received in a proposal payload. I don't see how it is applicable to flushing stale SA's on the other IPSEC peer. I believe a DELETE is more correct because you can tell the peer to just dump the SA which is generating the invalid SPI. (Obviously, it is desirable to send the DELETE via the phase 1 SA if one exists). Comments? 2. Substantial discussion is underway about the RESPONDER-LIFETIME notify message. Is it illegal for the responder to modify the lifetime proposal made by the initiator and send that back in his proposal selection? For example, initiator sends a proposal with: ESP with DES and 3600 second lifetime The responder finds a matching policy _except_ it requires a 2000 second lifetime. Why can't the responder send back in his SA payload the proposal: ESP with DES and 2000 second lifetime Doesn't this eliminate the need for RESPONDER-LIFETIME? -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Wed Jan 19 16:51:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15493; Wed, 19 Jan 2000 16:51:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23032 Wed, 19 Jan 2000 18:07:30 -0500 (EST) Date: Wed, 19 Jan 2000 18:11:36 -0500 (EST) From: Henry Spencer To: Ben McCann cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime In-Reply-To: <3886340B.E64B08B2@indusriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000, Ben McCann wrote: > 1. How should an IPSEC station notify a peer that it received an invalid > SPI in an _IPSEC_ packet (AH, ESP, or IPCOMP)? The first question is whether any notification should be attempted, given the potential for denial-of-service attacks. (Note that RFCs 2402 and 2406 specifically deny that you are required to attempt any sort of notification at all... so an interoperable implementation cannot depend on getting them anyway.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jan 19 16:51:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15492; Wed, 19 Jan 2000 16:51:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22402 Wed, 19 Jan 2000 16:57:45 -0500 (EST) From: "Mr. Anderson" Message-Id: <200001192126.QAA21472@linux.silkroad.com> Subject: Re: Bruce Schneier on IPsec To: guttman@mitre.org Date: Wed, 19 Jan 100 16:26:44 -0500 (EST) Cc: smamros@nortelnetworks.com, Markus.Friedl@informatik.uni-erlangen.de, ipsec@lists.tislabs.com In-Reply-To: <200001191751.MAA20215@linus.mitre.org> from "Joshua D. Guttman" at Jan 19, 0 12:51:22 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As painful as it may seem to the WG. The WG would be well advised to objectively consider Bruce's comments. > By the way: The paper has in fact two authors, Niels Ferguson and > Bruce Schneier. > > Joshua > > -- > Joshua D. Guttman > MITRE, Mail Stop A150 > 202 Burlington Rd. Tel: +1 781 271 2654 > Bedford, MA 01730-1420 USA Fax: +1 781 271 3816 > From owner-ipsec@lists.tislabs.com Wed Jan 19 17:38:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA16041; Wed, 19 Jan 2000 17:38:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23291 Wed, 19 Jan 2000 19:06:29 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A428@exchange> From: Andrew Krywaniuk To: Ben McCann , Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime Date: Wed, 19 Jan 2000 19:12:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ben: > 1. How should an IPSEC station notify a peer that it received > an invalid > SPI in an _IPSEC_ packet (AH, ESP, or IPCOMP)? Andrew: If the phase 1 exists, send a secure invalid spi (or a delete if you want). But assume that the phase 1 does not exist: An unauthenticated delete is inappropriate because the peer cannot trust it. If the peer DID trust it then an attacker could take your SAs down at any point by spoofing a delete. Not sending anything is safe, but it doesn't help the peer identify the cause of the problem if, in fact, there is a connection loss. I believe that sending a notify invalid spi is appropriate because it does not consume enough CPU time to allow a DoS attack. If you're really concerned about DoS, you can send the notify only on the first occurrence and then ignore all subsequent bad packets... but IMHO protecting against DoS attackers who have large amounts of CPU power is, in general, a losing proposition. Ben: > 2. Substantial discussion is underway about the > RESPONDER-LIFETIME notify > message. I don't know how this topic got started. I think Dan misinterpreted one of my comments and we got off on this sidetrack. > Is it illegal for the responder to modify the > lifetime proposal > made by the initiator and send that back in his proposal selection? Yes. See [IKE] pg 9. > For example, initiator sends a proposal with: > > ESP with DES and 3600 second lifetime > > The responder finds a matching policy _except_ it requires a 2000 > second lifetime. Why can't the responder send back in his > SA payload > the proposal: > > ESP with DES and 2000 second lifetime > > Doesn't this eliminate the need for RESPONDER-LIFETIME? Theoretically, this would work. I think the stipulation that the attributes may not be modified was included for the purpose of making parsing easier. It might also be a safeguard to prevent the responder from inserting covert information into the initiator's signature. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Jan 19 17:49:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA16133; Wed, 19 Jan 2000 17:49:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23260 Wed, 19 Jan 2000 18:53:57 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 19 Jan 2000 16:57:57 -0700 From: "Hilarie Orman" To: , , , Cc: , Subject: Re: Bruce Schneier on IPsec Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA23257 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure that this list is the place to discuss the process of developing security protocols, but I'd be interested in participating in an appropriate mailing list, should anyone set one up. Of course, many of the issues were discussed on the mailing list over the last many years. That's part of the value of the working group process. Of course, one has to realize that this discussion has been going on for close to 10 years already. The prospect of another 10 years of retrospection on the sins of the 90's might be of interest only to the most ascetic and masochistic among us. Hilarie From owner-ipsec@lists.tislabs.com Wed Jan 19 18:13:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17636; Wed, 19 Jan 2000 18:13:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23199 Wed, 19 Jan 2000 18:38:14 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 19 Jan 2000 15:39:37 -0800 (PST) From: Jan Vilhuber To: "Mr. Anderson" cc: guttman@mitre.org, smamros@nortelnetworks.com, Markus.Friedl@informatik.uni-erlangen.de, ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-Reply-To: <200001192126.QAA21472@linux.silkroad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 100, Mr. Anderson wrote: > > > As painful as it may seem to the WG. The WG would be > well advised to objectively consider Bruce's comments. > Despite what you may think, I believe we are doing just that. It's not even painful. Considering opposing points of view is exactly what a working group is all about, despite what the authors of the paper think of the IETF process. What I find galling is that the authors could have been part of the working group all this time, when in fact they weren't. To then come at the group after all these years and nit pick it to death is not appropriate. Especially considering that a lot of what they point out has already been discussed, and, in some cases, rejected. Not many of the points made are, in fact new, or unknown to the working group. And as far as I understood them, none of the attacks are either possible (SA proposal attack) or relevant (manual keyed ipsec example/attack). And it is my humble opinion, that the authors don't fully understand the protocol, nor indeed some of the special challenges of networking, i.e. proposing to combine the 5th and 6th MM messages into one fails to realize that this will leave the last message going in the wrong direction, i.e. will cause similar problems as the last QM message going in the wrong direction (lack of ACK, so to speak). That's not to say that there aren't valid points or valid food for thought (which I'm sure the working group will consider). Merely the the forum the authors picked is inappropriate, and smacks of hidden agenda, and not of "cryptographic analysis". jan > > By the way: The paper has in fact two authors, Niels Ferguson and > > Bruce Schneier. > > > > Joshua > > > > -- > > Joshua D. Guttman > > MITRE, Mail Stop A150 > > 202 Burlington Rd. Tel: +1 781 271 2654 > > Bedford, MA 01730-1420 USA Fax: +1 781 271 3816 > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Jan 19 18:19:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18189; Wed, 19 Jan 2000 18:19:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23537 Wed, 19 Jan 2000 19:46:22 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A42D@exchange> From: Andrew Krywaniuk To: Dan Harkins , Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime Date: Wed, 19 Jan 2000 19:52:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I think you misunderstood something I said. I was not talking specifically about responder lifetime notifies. I was talking about the general issue of phase 1 kb lifetimes (which, you will notice, is the subject of this thread). I merely made the observation that phase 1 kb lifetimes have potential security implications and it's not right to prevent people from using them. If an implementation decides to enforce kb lifetimes then they must either: 1. Locally enforce the rule without informing the peer. OR 2. Inform the peer (Initiator: put it in the proposal, Responder: send a lifetime notify). I can see arguments for doing either: 1. On one hand, I might consider reaching the kb limit an abnormal situation, in which case there's no need to notify the peer in advance. 2. On the other hand, there's no harm in sending the lifetime constraint to the peer if they might cooperate in enforcing it. But if you: 1. State that "It is _never_ a good idea to just enforce a lifetime without telling the peer". AND 2. Agree that lifetime constraints are a component of policy. AND 3. Want to remove the definition of the kb lifetime magic number from IKE. ...then like it or not you ARE legislating policy. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Wednesday, January 19, 2000 2:50 PM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: Re: Phase 1 KB lifetime > > > On Wed, 19 Jan 2000 14:24:03 EST you wrote > > > > Fine. As I said, our code has support for the responder > lifetime notify. We > > send it and parse it. If the responder adjusts the > lifetime, we honour it > > AND we send the delete. I'm not arguing with you on this point. > > Bully for you. What your product does is not the issue here. > > > I'm saying that if someone was paranoid enough to want to > expire their SAs > > based on a kb lifetime, which is a possible weakness (even > if some consider > > it too unlikely or too unworthy to protect against), then > they should go > > ahead and delete their SAs regardless of whether there is > an assigned magic > > number for kb lifetimes in the draft. > > > > Should they send a responder lifetime notify regarding this > constraint? > > I don't think you understand what the responder lifetime > notify is used for. > When a lifetime has been reached you don't send the notify, > you chain it > to your Quick Mode message during negotiation so both sides > have a consistent > view of the world at SA establishment time. Whether a magic > number exists > for kb lifetimes in phase 1 is unrelated to the use of > responder notifies. > > > On one hand, you are saying that an implementation should > notify the peer of > > all of its lifetime constraints. On the other hand, you > want to remove (or > > at least deprecate) the magic number associated with this lifetime > > constraint. > > I'm arguing _against_ ignoring messages from the peer and > blithely assuming > that things are as you believe they are when they aren't > (which you'd know > had you parsed the message). > > > If the user values strict security over strict standards > compliance then > > they have no choice but to enforce the kb lifetime rule > without sending a > > notify. > > > > If you want to prevent implementations which enforce local > kb lifetime rules > > from sending a notify then fine... just don't try to > legislate policy. > > Nobody's "legislating policy". And the enforcement of kb > lifetime is not > related to the use of the responder lifetime. Please read the relevent > documents. > > Dan. > From owner-ipsec@lists.tislabs.com Wed Jan 19 18:19:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18209; Wed, 19 Jan 2000 18:19:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23479 Wed, 19 Jan 2000 19:36:25 -0500 (EST) Message-Id: <200001200010.QAA15133@gallium.network-alchemy.com> To: "Mr. Anderson" cc: guttman@mitre.org, smamros@nortelnetworks.com, Markus.Friedl@informatik.uni-erlangen.de, ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-reply-to: Your message of "Wed, 19 Jan 0100 16:26:44 EST." <200001192126.QAA21472@linux.silkroad.com> Date: Wed, 19 Jan 2000 16:10:22 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >As painful as it may seem to the WG. The WG would be >well advised to objectively consider Bruce's comments. I can assure you that nearly every member of the IPSec WG has the uttmost respect for Bruce's opinions. In fact, most of the IPSec document authors have been expressing similar opinions for years now. His report is nothing new to us. However, IKE/IPSec is what it is, and it's what we've got to work with _today_. I don't think packing up our marbles and going home is going to benefit anyone. IPSec is clearly being deployed and I think you will find that a significant percentage of Internet traffic will be IPSec protected in just a few short years. And this is very good. Derrell From owner-ipsec@lists.tislabs.com Wed Jan 19 19:29:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23040; Wed, 19 Jan 2000 19:29:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23875 Wed, 19 Jan 2000 20:41:06 -0500 (EST) Message-Id: <200001200138.RAA20878@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime In-reply-to: Your message of "Wed, 19 Jan 2000 19:52:28 EST." <319A1C5F94C8D11192DE00805FBBADDF0110A42D@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20875.948332311.1@network-alchemy.com> Date: Wed, 19 Jan 2000 17:38:32 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000 19:52:28 EST you wrote > > But if you: > > 1. State that "It is _never_ a good idea to just enforce a lifetime without > telling the peer". > AND > 2. Agree that lifetime constraints are a component of policy. > AND > 3. Want to remove the definition of the kb lifetime magic number from IKE. > > ...then like it or not you ARE legislating policy. No I'm not. You can delete phase 1 SAs based on any arbitrary occurance you like-- phases of the moon, closing stock price of NN, whatever. Note that none of these have magic numbers in IKE. The question was raised (not by me I might add) to move kilobyte lifetime for phase 1 to the pile of other arbitrary occurances that don't really make sense and therefore do not have magic numbers assigned. I really would like to legislate the word "policy" (also known as the "p-word") out of discussions on the protocol though. My illustrated dictionary has a picture of a rat hole next to the definition of "policy". Dan. From owner-ipsec@lists.tislabs.com Wed Jan 19 20:04:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA25107; Wed, 19 Jan 2000 20:04:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23926 Wed, 19 Jan 2000 21:00:45 -0500 (EST) Date: Wed, 19 Jan 2000 21:04:52 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Bruce Schneier on IPsec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000, Jan Vilhuber wrote: > What I find galling is that the authors could have been part of the working > group all this time, when in fact they weren't. To then come at the group > after all these years and nit pick it to death is not appropriate. To analyze the results of the group's work is surely legitimate. Indeed, it is highly desirable to have such analysis done by people who were *not* part of the standard-development process. IPSEC is currently at Proposed Standard status, last I looked, which is precisely the point where such detailed critiques by non-participants are appropriate -- the protocols are believed to have settled down but are not yet deemed fully mature. > Especially considering that a lot of what they point out has already been > discussed, and, in some cases, rejected. Not many of the points made are, in > fact new, or unknown to the working group. And where, exactly, are these written up in a form intelligible to non-WG observers? In a fairly strong sense, it does not *MATTER* whether the WG has discussed them, if that discussion, its reasoning, and its conclusions are not openly and readably documented. For some protocols, a "trust us, this is right" approach is at least defensible; for security protocols, it isn't. > And it is my humble opinion, that the authors don't fully understand the > protocol, nor indeed some of the special challenges of networking... I wouldn't be surprised; in fact, the authors admit as much in some places. But whose fault is that? The IPSEC spec is better than it used to be, but it's still pretty bad. Most notably, as F&S observe, it is glaringly deficient precisely in explaining *why* it does things the way it does. Again, this is a situation which might be tolerable in some contexts but is unacceptable in the Internet's central security protocol. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jan 19 20:10:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA25598; Wed, 19 Jan 2000 20:10:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23822 Wed, 19 Jan 2000 20:34:29 -0500 (EST) Date: Wed, 19 Jan 2000 20:38:37 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Bruce Schneier on IPsec In-Reply-To: <200001200010.QAA15133@gallium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000, Derrell D. Piper wrote: > ...IPSec is clearly being deployed and I think you will find > that a significant percentage of Internet traffic will be IPSec protected in > just a few short years. And this is very good. Ah, but is it? That is an assumption, not a definitely known fact. Weak security is worse than none at all, because it breeds overconfidence. Imminent widespread deployment of IPSec would be better news if there weren't so many concerns about just how strong its security really is. In particular, I fail to see that widespread deployment of systems using 56-bit DES for encryption is cause for joy. It's disgraceful that 3DES isn't even a MUST. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jan 19 20:34:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA27407; Wed, 19 Jan 2000 20:34:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24044 Wed, 19 Jan 2000 21:53:09 -0500 (EST) Message-ID: <388679D2.8EE33AAE@storm.ca> Date: Wed, 19 Jan 2000 21:58:26 -0500 From: Sandy Harris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: <3.0.32.20000117120634.00b0fe70@zbl6c000.corpeast.baynetworks.com> <200001191751.MAA20215@linus.mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Joshua D. Guttman" wrote: > > > fyi, > > > > http://www.counterpane.com/ipsec.pdf > > http://www.counterpane.com/ipsec.ps.zip > > Snippets aside, the paper raises a lot of important questions, and it > would be worthwhile to step back from the details of IPsec to talk > about them. > > The paper includes political, technical, and expository challenges to > the current IPsec. I'll give a sample of each: > > 1. Political: Would we get better results with a process modeled on > the NIST AES competition, rather than the current IETF committee > process? > > 2. Technical: Could the protocols be simplified greatly without > undermining their usefulness? For instance, > > - could transport mode be eliminated? > - could AH be scrapped in favor of ESP with authentication? > - could ISAKMP and IKE be significantly simplified, sharpened, > and disentangled from each other? If you're going that far, why not cut it down further? Dump manual mode, aggressive mode, rekeying without PFS, ... All you really need are automatically keyed PFS connections. Of course, dump DES as Schneier and Ferguson also recommend. Then the next question is whether we can cut down the SPD and the assortment of authentication mechanisms to something simple and clean. > 3. Expository: Where is it explained what the overall security goals > of the IPsec enterprise are, and how all the ingredients fit > together to meet those security goals? > > It may be that the authors are ill-informed or misinformed or > misguided in some of their comments. But that could also be a good > reason to discuss the paper here! > > By the way: The paper has in fact two authors, Niels Ferguson and > Bruce Schneier. > > Joshua > > -- > Joshua D. Guttman > MITRE, Mail Stop A150 > 202 Burlington Rd. Tel: +1 781 271 2654 > Bedford, MA 01730-1420 USA Fax: +1 781 271 3816 From owner-ipsec@lists.tislabs.com Wed Jan 19 20:48:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28055; Wed, 19 Jan 2000 20:48:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24107 Wed, 19 Jan 2000 22:15:05 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 19 Jan 2000 19:18:11 -0800 (PST) From: Jan Vilhuber To: Henry Spencer cc: IP Security List Subject: Re: Bruce Schneier on IPsec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 19 Jan 2000, Henry Spencer wrote: > > Especially considering that a lot of what they point out has already been > > discussed, and, in some cases, rejected. Not many of the points made are, in > > fact new, or unknown to the working group. > > And where, exactly, are these written up in a form intelligible to non-WG > observers? In a fairly strong sense, it does not *MATTER* whether the WG > has discussed them, if that discussion, its reasoning, and its conclusions > are not openly and readably documented. For some protocols, a "trust us, > this is right" approach is at least defensible; for security protocols, it > isn't. > Each working group is *required* to archive its mailing list. Granted it's a lot of data to wade through, but it's there, and can be found (if you really put your mind to it, download the entire archive, and run it through something like verity or something for nice search-tools). Meeting notes are sent to this list as well. The current place of the list is at www.vpnc.org. > > And it is my humble opinion, that the authors don't fully understand the > > protocol, nor indeed some of the special challenges of networking... > > I wouldn't be surprised; in fact, the authors admit as much in some > places. But whose fault is that? The IPSEC spec is better than it used > to be, but it's still pretty bad. Most notably, as F&S observe, it is > glaringly deficient precisely in explaining *why* it does things the way > it does. Again, this is a situation which might be tolerable in some > contexts but is unacceptable in the Internet's central security protocol. > The point about documentation is well taken. I never claimed the opposite. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Jan 19 22:11:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02058; Wed, 19 Jan 2000 22:11:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24330 Wed, 19 Jan 2000 23:38:58 -0500 (EST) Message-ID: From: Sankar Ramamoorthi To: "'Paul Koning'" , akrywaniuk@TimeStep.com Cc: ipsec@lists.tislabs.com Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) Date: Wed, 19 Jan 2000 20:43:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Paul Koning [pkoning@xedia.com] >Sent: Wednesday, January 19, 2000 11:50 AM >To: akrywaniuk@TimeStep.com >Cc: ipsec@lists.tislabs.com >Subject: Re: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) > >>>>>> "Andrew" == Andrew Krywaniuk writes: > > Sankar> Why is "do nothing" a safe choice for the receiver of the bad > Sankar> IPSec packet (IPSec packet without SA)? How does sending a > Sankar> 'invalid spi' notify to the sender of the ipsec packet affect > Sankar> the safety of the receiver? Isn't sending a notify better > Sankar> than doing nothing? > > Andrew> Paul: > > >> Not necessarily. Sending a notify consumes resources that are not > >> consumed by simply discarding the offending packet. Since DOS > >> attacks basically are attempts to get the receiver to consume lots > >> of resources, the less resources you use in dealing with invalid > >> packets the safer you are from DOS attacks. > > Andrew> Andrew: > > Andrew> Not exactly. > > Andrew> You can't realistically ever fully protect against DoS > Andrew> attacks. But a good rule of thumb is to force a DoS attacker > Andrew> to consume as much of his own computing power as he consumes > Andrew> of yours. > >I'd rather do better, because DOS attackers can operate in packs, so >they have a lot more resources than you do. > > Andrew> You receive a spoofed packet and it causes you to perform a > Andrew> DH exponentiation = BAD. You receive a spoofed packet and it > Andrew> causes you to generate an unencrypted notify = OK. > > Andrew> Generating the unencrypted notify could involve nothing more > Andrew> than a hash table lookup (which you had to do anyway to > Andrew> determine that the spi/cookie was invalid), a couple of > Andrew> memcpys, and a SendBuffer. > >Or it may be a lot more costly. IPSEC may be in hardware while IKE is >in a control processor. > > Andrew> Plus, sending the unencrypted notify allows the peer to > Andrew> generate an alarm: SOMEONE IS SPOOFING PACKETS!!! (since > Andrew> either you generated the notify in response to a bad > Andrew> spi/cookie or the notify itself was spoofed) > >Certainly you can do logging or alarms based on bad input packets, but >that's a local matter, not a topic for the protocol specs since it >doesn't affect the protocol. > > Andrew> But if you respond to the unencrypted notify by initiating a > Andrew> new SA then you are at the mercy of a DoS attacker. > >Right. > >If generating an unauthenticated notify allows the receiver of that >notify to take a useful action, it might make sense to take the >resource hit and generate that notify. But I see no way that a >receiver of such a message can take any useful action. Well, maybe >you could log them, because clearly someone may be attacking you or >the other end if you see those messages. > >On the other hand, the issue was that a half-open connection (SAs on >one side but not the other) is not self-correcting. You CANNOT use >unauthenticated notifies to fix that for the reasons you mentioned. >Since you cannot, it makes sense for the spec to say that generating >such a notify is optional and you're also allowed to take no >(protocol) action at all for invalid SPI packets. > > paul In addressing the half-open connection state you seem to only consider two possiblities, a clear notify or a notify sent using an existing SA. Is it possible to send an authenticated notify without an existing SA? If one such message is possible, it can get the parties involved out of the half open state (the cost to create such a message could be cheaper than getting an SA created and one can always rate control the creation of such messages to minimize DOS attack). Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Thu Jan 20 00:40:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA07878; Thu, 20 Jan 2000 00:40:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA24703 Thu, 20 Jan 2000 02:07:28 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Henry Spencer Cc: IP Security List Subject: Re: Bruce Schneier on IPsec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jan 2000 23:12:01 -0800 Message-Id: <20000120071209.80026ACAE2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spe ncer writes: > >> And it is my humble opinion, that the authors don't fully understand the >> protocol, nor indeed some of the special challenges of networking... > >I wouldn't be surprised; in fact, the authors admit as much in some >places. But whose fault is that? The IPSEC spec is better than it used >to be, but it's still pretty bad. Most notably, as F&S observe, it is >glaringly deficient precisely in explaining *why* it does things the way >it does. Again, this is a situation which might be tolerable in some >contexts but is unacceptable in the Internet's central security protocol. Many of their comments aren't new. I've been arguing against AH for years, for example. (The WG didn't agree with me, so I haven't pursued the question.) Similarly, lots of people complained about the complexity of ISAKMP way back when. For reasons that are too painful to dredge up, it became the only choice. Those two points are, perhaps, a result of the consensus process that Ferguson and Schneier have criticized. On the other hand, the distinction between transport mode and tunnel mode is a vital matter of network architecture, and I don't think that that was properly understood by the authors. (I sent a long note to them on this topic quite some time ago.) I'm quite convinced that we made the right choice there, and see no reason to revisit it. The really interesting issue is whether or not we should revisit IKE. In one sense, I'd hate to -- it's taken a long time to get to this level of implementation and interoperability. On the other hand, at the very least the documents, and perhaps the protocol, are quite hard to understand -- just read the mailing list to see where there are differences in interpretation, questions about meaning, etc. IKE may or may not be necessary, sufficient, and correct -- but it's awfully hard to comprehend. --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Jan 20 05:31:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20157; Thu, 20 Jan 2000 05:31:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03585 Thu, 20 Jan 2000 06:53:00 -0500 (EST) Message-Id: <200001201157.GAA24902@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-base-mode-02.txt Date: Thu, 20 Jan 2000 06:57:45 -0500 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 : IKE Base Mode Author(s) : Y. Dayan, S. Bitan Filename : draft-ietf-ipsec-ike-base-mode-02.txt Pages : 6 Date : 19-Jan-00 This document describes a new Phase I mode for IKE [RFC-2409] based on the ISAKMP [RFC-2408] Base Exchange. The purpose of this new exchange is to allow support of all authentication methods with fixed and non-fixed IP addresses, while offering protection against a denial of service attack aimed at costly operations. It also enables negotiation capabilities beyond those offered by Aggressive Mode (DH/EC group). The exchange consists of only four messages and therefor is useful when performance is crucial. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-base-mode-02.txt 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-ike-base-mode-02.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-ike-base-mode-02.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: <20000119140519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-base-mode-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-base-mode-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000119140519.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jan 20 05:40:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20289; Thu, 20 Jan 2000 05:40:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03719 Thu, 20 Jan 2000 07:25:43 -0500 (EST) Message-Id: <38870158.7132CCE0@radguard.com> Date: Thu, 20 Jan 2000 14:36:40 +0200 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: ipsec@lists.tislabs.com Cc: hugo@ee.technion.ac.il Subject: draft-ietf-ipsec-ike-base-mode-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A new Base Mode draft was published. The changes regard HASH_I and HASH_R in signature mode. Hugo Krawczyk pointed out an attack on signature mode in which: A man in the middle (E) can convince the responder (R) it has exchanged and authenticated g^xy with the initiator (I), and yet it makes the initiator think that g^xy was exchanged with E. Thus it is possible that messages sent by R to I will be credited to E, even though E does not know g^xy. Although this requires that I does not know the identity of R prior to the exchange (which is not typical), the appropriate change has been made to HASH I. Due to this change, the responder will notice that E has tried to impersonate him. Since the initiator and responder ID's are known at the time of signing, we have defined the signatures to include both of them. From owner-ipsec@lists.tislabs.com Thu Jan 20 06:08:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20952; Thu, 20 Jan 2000 06:08:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03798 Thu, 20 Jan 2000 07:55:50 -0500 (EST) Message-ID: <38870715.6A597851@storm.ca> Date: Thu, 20 Jan 2000 08:01:09 -0500 From: Sandy Harris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: IP Security List Subject: Re: Bruce Schneier on IPsec References: <20000120071209.80026ACAE2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > On the other hand, the distinction between transport mode and tunnel mode is a > vital matter of network architecture, and I don't think that that was properly > understood by the authors. (I sent a long note to them on this topic quite > some time ago.) I'm quite convinced that we made the right choice there, and > see no reason to revisit it. Could you post the note here, or is it perchance in the archives? The reason for having the two modes is far from obvious to me, and perhaps others. From owner-ipsec@lists.tislabs.com Thu Jan 20 06:39:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21405; Thu, 20 Jan 2000 06:39:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03873 Thu, 20 Jan 2000 08:17:33 -0500 (EST) To: Sandy Harris cc: IP Security List In-reply-to: sandy's message of Thu, 20 Jan 2000 08:01:09 EST. <38870715.6A597851@storm.ca> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Bruce Schneier on IPsec From: itojun@iijlab.net Date: Thu, 20 Jan 2000 22:22:07 +0900 Message-ID: <26717.948374527@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> On the other hand, the distinction between transport mode and tunnel mode is a >> vital matter of network architecture, and I don't think that that was properly >> understood by the authors. (I sent a long note to them on this topic quite >> some time ago.) I'm quite convinced that we made the right choice there, and >> see no reason to revisit it. >Could you post the note here, or is it perchance in the archives? The reason >for having the two modes is far from obvious to me, and perhaps others. I agree with Sandy. I always wonder why we have tunnel mode, when there are tons of other simple tunnelling proposals (RFC1933, GRE, you name it). We can combine them to get similar behavior. If there's clear reason for having tunnel mode in IPsec document, I would like to know that (please don't repost, URL is just fine). itojun From owner-ipsec@lists.tislabs.com Thu Jan 20 07:25:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22183; Thu, 20 Jan 2000 07:25:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03999 Thu, 20 Jan 2000 08:54:45 -0500 (EST) Date: Thu, 20 Jan 2000 15:59:17 +0200 (EET) From: Markku Savela Message-Id: <200001201359.PAA18372@anise.tte.vtt.fi> To: sandy@storm.ca CC: ipsec@lists.tislabs.com In-reply-to: <38870715.6A597851@storm.ca> (message from Sandy Harris on Thu, 20 Jan 2000 08:01:09 -0500) Subject: Re: Bruce Schneier on IPsec Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > On the other hand, the distinction between transport mode and tunnel mode is a > > vital matter of network architecture, and I don't think that that was properly > > understood by the authors. (I sent a long note to them on this topic quite > > some time ago.) I'm quite convinced that we made the right choice there, and > > see no reason to revisit it. > > Could you post the note here, or is it perchance in the archives? The reason > for having the two modes is far from obvious to me, and perhaps others. I don't understand what the big fuss is about two modes. In my implementation the core IPSEC code implements only TRANSPORT MODE! The tunnel mode is achieved simply by slapping IP tunnel on a packet and THEN applying the transport mode transformation. Seems to work fine and is very simple. I suppose the problems are on the IKE side then. I still want simpler IKE, that only negotiates 1-directional SA when kernel asks it. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Jan 20 08:08:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22929; Thu, 20 Jan 2000 08:08:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04142 Thu, 20 Jan 2000 09:37:20 -0500 (EST) Message-ID: <38871C64.B381B9BD@indusriver.com> Date: Thu, 20 Jan 2000 09:32:05 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: Phase 1 KB lifetime References: <319A1C5F94C8D11192DE00805FBBADDF0110A428@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew: > I believe that sending a notify invalid spi is appropriate because it does > not consume enough CPU time to allow a DoS attack. If you're really > concerned about DoS, you can send the notify only on the first occurrence > and then ignore all subsequent bad packets... but IMHO protecting against > DoS attackers who have large amounts of CPU power is, in general, a losing > proposition. > Sorry to beat the dead horse, but two different documents define the usage of INVALID-SPI and neither definition lists replying to invalid IPSEC packets. (Those documents are RFC 2408 and draft-ietf-ipsec-notifymsg-02.txt). Are the generally accepted implementation practices different from the requirements/recommendations of those documents? -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu Jan 20 08:09:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22952; Thu, 20 Jan 2000 08:09:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04166 Thu, 20 Jan 2000 09:39:27 -0500 (EST) Date: Thu, 20 Jan 2000 09:43:58 -0500 Message-Id: <200001201443.JAA04998@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sankar@vpnet.com Cc: akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sankar" == Sankar Ramamoorthi writes: >> ... >> On the other hand, the issue was that a half-open connection (SAs >> on one side but not the other) is not self-correcting. You CANNOT >> use unauthenticated notifies to fix that for the reasons you >> mentioned. Since you cannot, it makes sense for the spec to say >> that generating such a notify is optional and you're also allowed >> to take no (protocol) action at all for invalid SPI packets. Sankar> In addressing the half-open connection state you seem to only Sankar> consider two possiblities, a clear notify or a notify sent Sankar> using an existing SA. Is it possible to send an authenticated Sankar> notify without an existing SA? If one such message is Sankar> possible, it can get the parties involved out of the half Sankar> open state (the cost to create such a message could be Sankar> cheaper than getting an SA created and one can always rate Sankar> control the creation of such messages to minimize DOS Sankar> attack). I can see a total of 4 approaches: 1. unauthenticated notify 2. notify authenticated using an existing phase 1 SA 3. notify authenticated using a newly created phase 1 SA 4. notify authenticated by a different mechanism not involving a phase 1 SA As far as I can see, (4) means a public key signature or equivalent. The cost of such a beast is on the same order as that of (3), i.e., *much* greater than (2) which is already too expensive for comfort. Yes, I suppose any of these things can be protected by rate limiting, and one would be wise to do that for notifies of any kind (including those that use an existing SA). Minimally that takes a timer, but it may also involve a hash table of recently-notified addresses. All that adds up, which is a good reason for the present rule. paul From owner-ipsec@lists.tislabs.com Thu Jan 20 08:59:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23780; Thu, 20 Jan 2000 08:59:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04102 Thu, 20 Jan 2000 09:30:08 -0500 (EST) Date: Thu, 20 Jan 2000 09:31:16 -0500 Message-Id: <200001201431.JAA04992@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: HORMAN@novell.com Cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Hilarie" == Hilarie Orman writes: Hilarie> I'm not sure that this list is the place to discuss the Hilarie> process of developing security protocols, but I'd be Hilarie> interested in participating in an appropriate mailing list, Hilarie> should anyone set one up. While I sympathize with Bruce and Niels's dissatisfaction with the committee based process, I see no particular advantage in discussing that. For better or worse, that's the IETF process. If enough people feel strongly enough that *that* is what has to change in order to have a good security protocol, they will just have to set up something different in another setting and run with it. On the other hand, if you ignore that one cosmic question, there are numerous comments in that paper that are far more concrete and *are* things that can constructively be (re)considered here. I'm all for seeing that happen. Especially since some implementation experience has been accumulated by now, so we can re-examine things like whether AH is worth having in that light. paul From owner-ipsec@lists.tislabs.com Thu Jan 20 09:25:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24194; Thu, 20 Jan 2000 09:25:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04555 Thu, 20 Jan 2000 10:48:13 -0500 (EST) Date: Thu, 20 Jan 2000 17:51:38 +0200 (IST) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: IP Security List cc: Henry Spencer Subject: Re: Bruce Schneier on IPsec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > ...IPSec is clearly being deployed and I think you will find > > that a significant percentage of Internet traffic will be IPSec protected in > > just a few short years. And this is very good. > > Ah, but is it? That is an assumption, not a definitely known fact. Weak > security is worse than none at all, because it breeds overconfidence. > Imminent widespread deployment of IPSec would be better news if there > weren't so many concerns about just how strong its security really is. > > Many things would be better in an ideal world. But given the many constraints of the dirty real world, I think that we can consider ipsec as a suitable protocol for use to protect IP traffic. It could have been better, it could have been simpler, it could have been more elegant, it could have been better documented, it could have included some better design decisions, it could have corrected known weaknesses. But, in spite of all these "could have", ipsec/ike IS a very valuable protocol. Not just the best available alternative but a good protocol in many senses. The analysis work by Ferguson and Schneier is an important document, but beware of reaching the wrong conclusions. The document discusses the faults of the protocol not its merits. Still it shows no fatal design aspect among those checked by the authors, nor it presents new significant information not previously known to the WG. The authors seem to be personally disappointed. That does not mean that the protocol is inappropriate. In my opinion nothing said there should stop ipsec deployment. (And, believe me, I had and have many complaints about the protocol, including many of the issues presented in [FS]; and I have been repeatedly frustrated by the process and bad idea of "cryptographic design by rough consensus". But none of these considerations are sufficient to invalidate the resultant protocol or make it inherently insecure.) The protocol and its many aspects still requires a lot of analysis and I hope that other security-analysis people (including cryptographers) will keep working on this. Too bad, that so few people from this area joined us when designing (or, more accurately, fighting for) this protocol. Hugo PS: After defending ipsec for once, I'd like to see also openess in the group for changes that significantly improve the quality of the protocols even at the cost of hurting some existing implementations (and the sooner things are fixed the better). We can start with many issues that [FS] point out (and other that were discussed in this list) that can be "resolved" by textual clarifications, and then proceed to the fixes that also require changing the "bits on the wire". From owner-ipsec@lists.tislabs.com Thu Jan 20 09:27:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24346; Thu, 20 Jan 2000 09:27:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04642 Thu, 20 Jan 2000 10:58:09 -0500 (EST) Message-ID: <3887314D.A2B4C73@nt.com> Date: Thu, 20 Jan 2000 11:01:17 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > And where, exactly, are these written up in a form intelligible to non-WG > observers? In a fairly strong sense, it does not *MATTER* whether the WG > has discussed them, if that discussion, its reasoning, and its conclusions > are not openly and readably documented. For some protocols, a "trust us, > this is right" approach is at least defensible; for security protocols, it > isn't. > Archives of this very mailing list, for one, and the published proceedings of IETF meetings. Granted, that doesn't quite fit the bill of being completely understandable to the unwashed, but given the process, it's about as good as you're going to get. Raise your hand if you want to volunteer to write up the minutes of IPSEC meetings in a form suitable for non-participants. Hmmm, stunning silence... > > I wouldn't be surprised; in fact, the authors admit as much in some > places. But whose fault is that? The IPSEC spec is better than it used > to be, but it's still pretty bad. Most notably, as F&S observe, it is > glaringly deficient precisely in explaining *why* it does things the way > it does. Again, this is a situation which might be tolerable in some > contexts but is unacceptable in the Internet's central security protocol. > I have to agree with this. The IKE/DOI/ISAKMP documentation, in particular, is quite hard to follow--even for someone who's been involved from the beginning. The more-or-less continuous stream of "how do I interpret this section of the IKE documents" questions on this mailing list should be a good indicator of how confusing and unclear those documents are. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Thu Jan 20 10:46:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25686; Thu, 20 Jan 2000 10:46:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05009 Thu, 20 Jan 2000 12:11:12 -0500 (EST) Message-ID: <38874303.84850113@redcreek.com> Date: Thu, 20 Jan 2000 09:16:51 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugo Krawczyk CC: IP Security List Subject: Re: Bruce Schneier on IPsec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > PS: After defending ipsec for once, I'd like to see also openess in the group > for changes that significantly improve the quality of the protocols > even at the cost of hurting some existing implementations (and the sooner > things are fixed the better). > We can start with many issues that [FS] point out (and other that > were discussed in this list) that can be "resolved" by textual clarifications, > and then proceed to the fixes that also require changing the > "bits on the wire". I agree with this sentiment, and also with Paul Koning's comments on this topic. There are some errors and misconceptions in the paper, but there is much of substance, as we all know. It is a normal part of the IETF process to modify developing standards as a result of implementation experience and analysis, and we know that IKE is already undergoing modifications for this very reason. While it may be expensive for companies deploying such early implementations to modify them, I think this is a price we must pay to play. Scott From owner-ipsec@lists.tislabs.com Thu Jan 20 10:46:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25691; Thu, 20 Jan 2000 10:46:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04966 Thu, 20 Jan 2000 12:06:01 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A54E@exchange> From: Andrew Krywaniuk To: Dan Harkins , Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Phase 1 KB lifetime Date: Thu, 20 Jan 2000 12:11:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Okay. I'm fine with that. So why did we have this whole discussion? It seems like we were only arguing over semantics. I would define "lifetime" as something like: "a predetermined longevity constraint that does not depend on transient conditions". I think that you define "lifetime" as: "a longevity constraint that has a magic number assigned to it in IKE". Maybe we need to clarify our definitions when we start violently agreeing. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: Wednesday, January 19, 2000 8:39 PM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: Re: Phase 1 KB lifetime > > > On Wed, 19 Jan 2000 19:52:28 EST you wrote > > > > But if you: > > > > 1. State that "It is _never_ a good idea to just enforce a > lifetime without > > telling the peer". > > AND > > 2. Agree that lifetime constraints are a component of policy. > > AND > > 3. Want to remove the definition of the kb lifetime magic > number from IKE. > > > > ...then like it or not you ARE legislating policy. > > No I'm not. You can delete phase 1 SAs based on any arbitrary > occurance you > like-- phases of the moon, closing stock price of NN, > whatever. Note that > none of these have magic numbers in IKE. The question was > raised (not by me > I might add) to move kilobyte lifetime for phase 1 to the > pile of other > arbitrary occurances that don't really make sense and > therefore do not have > magic numbers assigned. > > I really would like to legislate the word "policy" (also > known as the "p-word") > out of discussions on the protocol though. My illustrated > dictionary has a > picture of a rat hole next to the definition of "policy". > > Dan. > > From owner-ipsec@lists.tislabs.com Thu Jan 20 11:28:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26173; Thu, 20 Jan 2000 11:28:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05220 Thu, 20 Jan 2000 12:49:53 -0500 (EST) Date: Thu, 20 Jan 2000 09:43:21 -0800 (PST) From: Marc Hasson Message-Id: <200001201743.JAA29634@leo.mentat.com> To: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: Deflate issue X-Sun-Charset: ISO-8859-1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We interoperated with several vendor at the San Diego bakeoffs, they > used Deflate header and Adler32. IRE didn't include header and adler32, > so they had loads of problems. > > They way I see it, we were all (except IRE) wrong. But changing the > behaviour now > would break interoperability. > > I'd request a new ID in the DOI, for "DEFLATE without the rubbish". > > Jörn > Given the above comment about "rubbish" and the fact that "Deflate header" and Adler32 are not mentioned in any current IPCOMP working group direct document references (except indirectly through the mention of ZLIB) why would we want to proliferate more choices for no (as of yet) cited benefit? Can the vendors who interoperated with these additional deflate header/Adler32 "artifacts" cite any benefits to their usage in IPCOMP that they've discovered? I'd say that we should retain just the single current IPCOMP/DEFLATE DOI id to define DEFLATE without the above artifacts. Just as the RFCs 1951, 2393, and 2394 specifically describe, and which are all directly referenced or products of the IPCOMP working group's output. Sticking with these RFCs only would mean no disruption of the IPCOMP standards progress to full standards, if my understanding of the process is correct. Admittedly there may be some folks who are interoperating already with these apparently-zlib artifacts and it would be a shame to needlessly "break" them. But an earlier E-mail seemed to suggest it was pretty trivial to eliminate these zlib features. The compression stuff is still at an early stage in the standardization process, as these interops appear to be showing some non-trivial differences in interpretations of the required compression features/encodings themselves. But if these additional artifacts aren't referenced in any current IPCOMP working group documents, provide no cited benefits, and are a protocol or computational burden then I think the choice is clear to eliminate them now. And just add a warning about avoiding them as an implementation hint to the current IPCOMP DEFLATE documents. I wouldn't object, as an aid to current interoperaters with fielded product, an eventually-to-be-deprecated IPCOMP/DEFLATE DOI id for the "with rubbish" version that is clearly documented as an "interim" id. As long as the official/standard one doesn't have the "rubbish"! -- Marc -- From owner-ipsec@lists.tislabs.com Thu Jan 20 11:29:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26186; Thu, 20 Jan 2000 11:29:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05267 Thu, 20 Jan 2000 12:59:12 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A57C@exchange> From: Stephane Beaulieu To: ipsec Subject: FW: Releasing IP addresses assigned with IKECFG Date: Thu, 20 Jan 2000 13:05:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, meant to post this to the list. -----Original Message----- From: Stephane Beaulieu Sent: Thursday, January 20, 2000 9:52 AM To: 'Ben McCann' Subject: RE: Releasing IP addresses assigned with IKECFG > > Assume a security gateway assigns an IP address to a remote > access client > via IKECFG. How does the gateway _know_ the client is done > with that IP > address? You can _not_ use the expiration or deletion of the Phase 1 > SA because it can be rekeyed independently of the Phase 2 SA's that > presumably reference the assigned IP address. > > The only solution I can see is for the gateway to track all Phase 1 > and 2 SA's so the IP address can be reclaimed when all SA's to the > client are deleted or expired. (This requires reliable DELETE's so it > can't be reliably implemented without Son of IKE). This is one possible solution. You don't necessarily need reliable DELETEs if you have some other method of detecting dead SAs. In the remote access case, you often don't get the deletes because people often disconnect their laptaps before tearing down the IPSec connection. Things would be much simpler if we could assume that the phase 1 SA would always be around to help manage our phase 2 SAs. Then you could bind the IP address to the phase 1 SAs only. > > Are there other options? Does IKECFG require an extension to _release_ > the IP address (and any other resources allocated via IKECFG) when the > client is about to disconnect from the VPN? For example, should we add > a RELEASE payload type to the set of SET, ACK, REQUEST, and REPLY? Perhaps, but then you'd have to set up a phase 1 SA just to release it's IP address. And again, many times, the Clients terminate their connections in a very non-friendly way, and you wouldn't have the chance to send a RELEASE payload. Perhaps the best way is to just wait until all the phase 1s and phase 2s disapear for whatever reason (deletes, inactivity, missing hearbeats...) The protocol does allow one method which might help you address this issue. With IKE-CFG you can specify a time period for which the IP address is leased. The Client is then responsible for requesting a new IP (or renewing the lease on the existing one) before that time expires. If he doesn't do so, the GW will (or at least should) tear down all SAs and put that IP back in it's available pool. Hope this helps, Stephane. > > -Ben McCann > > P.S. I'm assuming the remote client only requests an IP address after > its first Phase 1 exchange with the gateway. It should continue using > that address while it has existing Phase 2 SA's independent > of the rekeying > activity of the Phase 1 SA. In other words, only request an > address after > you send INITIAL_CONTACT in a Phase 1 exchange. > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 > From owner-ipsec@lists.tislabs.com Thu Jan 20 13:10:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27530; Thu, 20 Jan 2000 13:10:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05709 Thu, 20 Jan 2000 14:25:48 -0500 (EST) Message-Id: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 20 Jan 2000 11:30:19 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Bruce Schneier on IPsec In-Reply-To: <3887314D.A2B4C73@nt.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:01 AM 1/20/00 -0500, Marcus Leech wrote: >Raise your hand if you want to volunteer to write up the minutes of > IPSEC meetings in a form suitable for non-participants. I intend to an IPsec implementors guide. I haven't started it yet because the IPsec WG is still moving on some important protocols, but I have already been collecting the basis for it from VPNC members. It will be much more than a "minutes of the meetings"; it will cover the technical arguments on the mailing list as well. > Hmmm, stunning > silence... It is generally a good idea to wait a moment for people to respond before declaring failure. :-) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jan 20 15:58:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01192; Thu, 20 Jan 2000 15:58:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06315 Thu, 20 Jan 2000 17:13:57 -0500 (EST) From: "Roy Pereira" To: "Stephane Beaulieu" , "ipsec" Subject: RE: Releasing IP addresses assigned with IKECFG Date: Thu, 20 Jan 2000 14:16:24 -0800 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) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0110A57C@exchange> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A better way is to use the expiration attribute and have the gateway expire the allocated address. It is up to the client software to renegotiate for the same or another address. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephane Beaulieu Sent: Thursday, January 20, 2000 10:05 AM To: ipsec Subject: FW: Releasing IP addresses assigned with IKECFG Sorry, meant to post this to the list. -----Original Message----- From: Stephane Beaulieu Sent: Thursday, January 20, 2000 9:52 AM To: 'Ben McCann' Subject: RE: Releasing IP addresses assigned with IKECFG > > Assume a security gateway assigns an IP address to a remote > access client > via IKECFG. How does the gateway _know_ the client is done > with that IP > address? You can _not_ use the expiration or deletion of the Phase 1 > SA because it can be rekeyed independently of the Phase 2 SA's that > presumably reference the assigned IP address. > > The only solution I can see is for the gateway to track all Phase 1 > and 2 SA's so the IP address can be reclaimed when all SA's to the > client are deleted or expired. (This requires reliable DELETE's so it > can't be reliably implemented without Son of IKE). This is one possible solution. You don't necessarily need reliable DELETEs if you have some other method of detecting dead SAs. In the remote access case, you often don't get the deletes because people often disconnect their laptaps before tearing down the IPSec connection. Things would be much simpler if we could assume that the phase 1 SA would always be around to help manage our phase 2 SAs. Then you could bind the IP address to the phase 1 SAs only. > > Are there other options? Does IKECFG require an extension to _release_ > the IP address (and any other resources allocated via IKECFG) when the > client is about to disconnect from the VPN? For example, should we add > a RELEASE payload type to the set of SET, ACK, REQUEST, and REPLY? Perhaps, but then you'd have to set up a phase 1 SA just to release it's IP address. And again, many times, the Clients terminate their connections in a very non-friendly way, and you wouldn't have the chance to send a RELEASE payload. Perhaps the best way is to just wait until all the phase 1s and phase 2s disapear for whatever reason (deletes, inactivity, missing hearbeats...) The protocol does allow one method which might help you address this issue. With IKE-CFG you can specify a time period for which the IP address is leased. The Client is then responsible for requesting a new IP (or renewing the lease on the existing one) before that time expires. If he doesn't do so, the GW will (or at least should) tear down all SAs and put that IP back in it's available pool. Hope this helps, Stephane. > > -Ben McCann > > P.S. I'm assuming the remote client only requests an IP address after > its first Phase 1 exchange with the gateway. It should continue using > that address while it has existing Phase 2 SA's independent > of the rekeying > activity of the Phase 1 SA. In other words, only request an > address after > you send INITIAL_CONTACT in a Phase 1 exchange. > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 > From owner-ipsec@lists.tislabs.com Thu Jan 20 18:06:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04089; Thu, 20 Jan 2000 18:06:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06653 Thu, 20 Jan 2000 19:33:07 -0500 (EST) Message-ID: From: Sankar Ramamoorthi To: "'Paul Koning'" , Sankar Ramamoorthi Cc: akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) Date: Thu, 20 Jan 2000 16:37:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Paul Koning [pkoning@xedia.com] >Sent: Thursday, January 20, 2000 6:44 AM >To: Sankar@vpnet.com >Cc: akrywaniuk@TimeStep.com; ipsec@lists.tislabs.com >Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) > >>>>>> "Sankar" == Sankar Ramamoorthi writes: > > >> ... > >> On the other hand, the issue was that a half-open connection (SAs > >> on one side but not the other) is not self-correcting. You CANNOT > >> use unauthenticated notifies to fix that for the reasons you > >> mentioned. Since you cannot, it makes sense for the spec to say > >> that generating such a notify is optional and you're also allowed > >> to take no (protocol) action at all for invalid SPI packets. > > Sankar> In addressing the half-open connection state you seem to only > Sankar> consider two possiblities, a clear notify or a notify sent > Sankar> using an existing SA. Is it possible to send an authenticated > Sankar> notify without an existing SA? If one such message is > Sankar> possible, it can get the parties involved out of the half > Sankar> open state (the cost to create such a message could be > Sankar> cheaper than getting an SA created and one can always rate > Sankar> control the creation of such messages to minimize DOS > Sankar> attack). > >I can see a total of 4 approaches: >1. unauthenticated notify >2. notify authenticated using an existing phase 1 SA >3. notify authenticated using a newly created phase 1 SA >4. notify authenticated by a different mechanism not involving a phase > 1 SA > >As far as I can see, (4) means a public key signature or equivalent. >The cost of such a beast is on the same order as that of (3), i.e., >*much* greater than (2) which is already too expensive for comfort. > >Yes, I suppose any of these things can be protected by rate limiting, >and one would be wise to do that for notifies of any kind (including >those that use an existing SA). Minimally that takes a timer, but it >may also involve a hash table of recently-notified addresses. All >that adds up, which is a good reason for the present rule. > > paul I don't fully agree with the rationale of the present rule. With the present rule, one end of the communication could endup sending packets into a blackhole and there is no way to notice it till the sender's SA expires - which forces me to implement keepalive (works only in intranet scenarios) solution to detect the problem. I would have rather preferred a solution mandated by the protocol and find ways to optmize the performance cost in the implementation. -- sankar -- From owner-ipsec@lists.tislabs.com Thu Jan 20 18:35:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07298; Thu, 20 Jan 2000 18:35:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06769 Thu, 20 Jan 2000 20:12:30 -0500 (EST) Message-ID: <3887B39D.D7A157DE@nortelnetworks.com> Date: Thu, 20 Jan 2000 20:17:17 -0500 From: "Marcus Leech" Organization: Nortel Networks, Information Systems X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman wrote: > > At 11:01 AM 1/20/00 -0500, Marcus Leech wrote: > >Raise your hand if you want to volunteer to write up the minutes of > > IPSEC meetings in a form suitable for non-participants. > > I intend to an IPsec implementors guide. I haven't started it > yet because the IPsec WG is still moving on some important protocols, but I > have already been collecting the basis for it from VPNC members. It will be > much more than a "minutes of the meetings"; it will cover the technical > arguments on the mailing list as well. > I don't know if you've ever seen the movie "Sick", which is about the life and death of Bob Flanagan, a notorious masochist performance artist, but the task you describe somehow reminds me of that... From owner-ipsec@lists.tislabs.com Thu Jan 20 19:25:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11213; Thu, 20 Jan 2000 19:25:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06954 Thu, 20 Jan 2000 20:38:04 -0500 (EST) Message-Id: <4.2.1.20000120173822.00b476f0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 20 Jan 2000 17:42:29 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Bruce Schneier on IPsec In-Reply-To: <3887B39D.D7A157DE@nortelnetworks.com> References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:17 PM 1/20/00 -0500, Marcus Leech wrote: >I don't know if you've ever seen the movie "Sick", which is about the > life and death of Bob Flanagan, a notorious masochist performance >artist, > but the task you describe somehow reminds me of that... I haven't seen it, but I've read about it. Somehow, IPsec documentation as performance art seems appropriate. Jokes aside, I believe that it is one of the jobs of an industry trade group to help assure that future implementors can interoperate as well as today's. In other words, it is one of the things VPNC's members pay for. The investment should pay off, given that future implementors will tend to mess up the market less as they enter. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jan 20 21:53:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA16988; Thu, 20 Jan 2000 21:53:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07362 Thu, 20 Jan 2000 23:33:27 -0500 (EST) Date: Thu, 20 Jan 2000 23:37:32 -0500 Message-Id: <200001210437.XAA03345@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "Marcus Leech" CC: Henry Spencer , ipsec@lists.tislabs.com In-reply-to: Marcus Leech's message of Thu, 20 Jan 2000 11:01:17 -0500, <3887314D.A2B4C73@nt.com> Subject: Re: Bruce Schneier on IPsec Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Thu, 20 Jan 2000 11:01:17 -0500 From: "Marcus Leech" I have to agree with this. The IKE/DOI/ISAKMP documentation, in particular, is quite hard to follow--even for someone who's been involved from the beginning. The more-or-less continuous stream of "how do I interpret this section of the IKE documents" questions on this mailing list should be a good indicator of how confusing and unclear those documents are. Agreed, 100%. However, to make a similar comment to the one which Marcus made: If anyone wants to donate a technical writer plus an IPSEC expert to make sure the technical writer gets things right, please raise your hand.... Reworking parts of the documents to make them more understandable is certainly something we can consider during the next edit cycle. The problem is that in order to really address right, we will need a lot of people to step up to the plate and spend their precious time working on making sure it gets done right. - Ted From owner-ipsec@lists.tislabs.com Thu Jan 20 22:34:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA17452; Thu, 20 Jan 2000 22:34:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07441 Fri, 21 Jan 2000 00:22:32 -0500 (EST) Date: Fri, 21 Jan 2000 00:26:25 -0500 (EST) From: Henry Spencer To: Sankar Ramamoorthi cc: ipsec@lists.tislabs.com Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 20 Jan 2000, Sankar Ramamoorthi wrote: > With the present rule, one end of the communication could endup > sending packets into a blackhole and there is no way to notice > it till the sender's SA expires... Given properly-functioning ends, how could such a situation arise? How would one end forget an SA that the other end was still using? About the only way for this to happen is to have one end crash and reboot... and that's what the Initial-Contact notification is for. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jan 20 22:57:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA17940; Thu, 20 Jan 2000 22:57:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07546 Fri, 21 Jan 2000 00:52:29 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 20 Jan 2000 21:56:37 -0800 (PST) From: Jan Vilhuber To: Henry Spencer cc: Sankar Ramamoorthi , ipsec@lists.tislabs.com Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 21 Jan 2000, Henry Spencer wrote: > On Thu, 20 Jan 2000, Sankar Ramamoorthi wrote: > > With the present rule, one end of the communication could endup > > sending packets into a blackhole and there is no way to notice > > it till the sender's SA expires... > > Given properly-functioning ends, how could such a situation arise? How > would one end forget an SA that the other end was still using? About > the only way for this to happen is to have one end crash and reboot... > and that's what the Initial-Contact notification is for. > It's my understanding that initial contact is sent with the next IKE exchange. If you don't rekey or need to bring up new SA's with the peer that is black-holing you, you won't get the initial-contact (at least not until the next exchange, which could be quite a while). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Jan 21 08:26:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06406; Fri, 21 Jan 2000 08:26:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09259 Fri, 21 Jan 2000 09:28:10 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0110A74D@exchange> From: Stephane Beaulieu To: Roy Pereira , Stephane Beaulieu , ipsec Subject: RE: Releasing IP addresses assigned with IKECFG Date: Fri, 21 Jan 2000 09:34:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Roy. That's what I stated in my last paragraph. There are other ways of doing it in an interoperable way (such as a few things that Ben suggested). However, the IP expiration method seems to be the best way, given that there is no way to tell when a Client hangs up "un-politely". But I guess that just means we agree. Cheers, Steph. > -----Original Message----- > From: Roy Pereira [mailto:royp@cisco.com] > Sent: Thursday, January 20, 2000 5:16 PM > To: Stephane Beaulieu; ipsec > Subject: RE: Releasing IP addresses assigned with IKECFG > > > A better way is to use the expiration attribute and have the > gateway expire > the allocated address. It is up to the client software to > renegotiate for > the same or another address. > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephane Beaulieu > Sent: Thursday, January 20, 2000 10:05 AM > To: ipsec > Subject: FW: Releasing IP addresses assigned with IKECFG > > > Sorry, meant to post this to the list. > > -----Original Message----- > From: Stephane Beaulieu > Sent: Thursday, January 20, 2000 9:52 AM > To: 'Ben McCann' > Subject: RE: Releasing IP addresses assigned with IKECFG > > > > > > Assume a security gateway assigns an IP address to a remote > > access client > > via IKECFG. How does the gateway _know_ the client is done > > with that IP > > address? You can _not_ use the expiration or deletion of the Phase 1 > > SA because it can be rekeyed independently of the Phase 2 SA's that > > presumably reference the assigned IP address. > > > > The only solution I can see is for the gateway to track all Phase 1 > > and 2 SA's so the IP address can be reclaimed when all SA's to the > > client are deleted or expired. (This requires reliable > DELETE's so it > > can't be reliably implemented without Son of IKE). > > This is one possible solution. You don't necessarily need > reliable DELETEs > if you have some other method of detecting dead SAs. In the > remote access > case, you often don't get the deletes because people often > disconnect their > laptaps before tearing down the IPSec connection. > > Things would be much simpler if we could assume that the > phase 1 SA would > always be around to help manage our phase 2 SAs. Then you > could bind the IP > address to the phase 1 SAs only. > > > > > > Are there other options? Does IKECFG require an extension > to _release_ > > the IP address (and any other resources allocated via > IKECFG) when the > > client is about to disconnect from the VPN? For example, > should we add > > a RELEASE payload type to the set of SET, ACK, REQUEST, and REPLY? > > Perhaps, but then you'd have to set up a phase 1 SA just to > release it's IP > address. And again, many times, the Clients terminate their > connections in > a very non-friendly way, and you wouldn't have the chance to > send a RELEASE > payload. Perhaps the best way is to just wait until all the > phase 1s and > phase 2s disapear for whatever reason (deletes, inactivity, missing > hearbeats...) > > The protocol does allow one method which might help you > address this issue. > With IKE-CFG you can specify a time period for which the IP address is > leased. The Client is then responsible for requesting a new > IP (or renewing > the lease on the existing one) before that time expires. If > he doesn't do > so, the GW will (or at least should) tear down all SAs and > put that IP back > in it's available pool. > > Hope this helps, > Stephane. > > > > > -Ben McCann > > > > P.S. I'm assuming the remote client only requests an IP > address after > > its first Phase 1 exchange with the gateway. It should > continue using > > that address while it has existing Phase 2 SA's independent > > of the rekeying > > activity of the Phase 1 SA. In other words, only request an > > address after > > you send INITIAL_CONTACT in a Phase 1 exchange. > > > > -- > > Ben McCann Indus River Networks > > 31 Nagog Park > > Acton, MA, 01720 > > email: bmccann@indusriver.com web: www.indusriver.com > > phone: (978) 266-8140 fax: (978) 266-8111 > > > > From owner-ipsec@lists.tislabs.com Fri Jan 21 10:06:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07955; Fri, 21 Jan 2000 10:06:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09660 Fri, 21 Jan 2000 11:25:18 -0500 (EST) Date: Fri, 21 Jan 2000 11:29:27 -0500 Message-Id: <200001211629.LAA09844@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: henry@spsystems.net Cc: Sankar@vpnet.com, ipsec@lists.tislabs.com Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Henry" == Henry Spencer writes: Henry> On Thu, 20 Jan 2000, Sankar Ramamoorthi wrote: >> With the present rule, one end of the communication could endup >> sending packets into a blackhole and there is no way to notice it >> till the sender's SA expires... Henry> Given properly-functioning ends, how could such a situation Henry> arise? How would one end forget an SA that the other end was Henry> still using? ... If you want the protocol to be self-stabilizing, you should *not* approach the question that way! "Self-stabilizing" means: the protocol recovers in a reasonable amount of time from faults, including from getting into states it wasn't supposed to have gotten into. Robust protocols have this property; protocols that don't are fragile. (For example, you may find yourself having to reboot an entire network to recover from an implementation bug.) Than again "reasonable amount of time" may be minutes or hours in the case of states that can be reached only through faults. paul From owner-ipsec@lists.tislabs.com Sun Jan 23 21:58:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25157; Sun, 23 Jan 2000 21:58:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16530 Sun, 23 Jan 2000 22:37:21 -0500 (EST) Message-Id: <10001240344.AA03005@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Mon, 24 Jan 2000 12:44:00 +0900 To: Andrew Krywaniuk Cc: Paul Koning , Sankar@vpnet.com, smamros@nortelnetworks.com, ipsec@lists.tislabs.com Subject: Re: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0110A362@exchange> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Andrew, I agree with you and think DoS-resistant protocols should work in the following order: (1) The responder carries out expensive (but initiator-independent) computation. (2) The initiator carries out expensive (and responder-dependent) computation. This computation must also be session-dependent. (3) With light computation, the responder checks whether the responder has really completed (2). (4) The responder carries out expensive (and initiator-dependent) computation. (1) can be pre-computed. If the resultant state is too large, we can be helped by "stateless connection" (state materials are encrypted by local secret key and sent back and forth between the responder and the initiator. This encryption can be a fast symmetric-key encryption and the key can be used many times.). Please consult about details with http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt. Finally, I'd like to point out that Base Mode (draft-ietf-ipsec-ike-base-mode-01.txt) is aimed at DoS resistance but it does not follow the protocol design direction listed above as (1)-(4). Signature-verification cost might probably exhaust the responder's resource, for example. (Even if RSA signature verification is not really expensive due to the deployment of small exponent, we had better design the protocol in a DoS-resistant way, not devoted to a single specific algorithm.) Andrew Krywaniuk wrote: >>> Sankar> Why is "do nothing" a safe choice for the receiver of the bad >>> Sankar> IPSec packet (IPSec packet without SA)? How does sending a >>> Sankar> 'invalid spi' notify to the sender of the ipsec packet affect >>> Sankar> the safety of the receiver? Isn't sending a notify better >>> Sankar> than doing nothing? >> >>Paul: >> >>> Not necessarily. Sending a notify consumes resources that are not >>> consumed by simply discarding the offending packet. Since >>> DOS attacks >>> basically are attempts to get the receiver to consume lots of >>> resources, the less resources you use in dealing with invalid packets >>> the safer you are from DOS attacks. >> >>Andrew: >> >>Not exactly. >> >>You can't realistically ever fully protect against DoS attacks. But a good >>rule of thumb is to force a DoS attacker to consume as much of his own >>computing power as he consumes of yours. >> >>You receive a spoofed packet and it causes you to perform a DH >>exponentiation = BAD. >>You receive a spoofed packet and it causes you to generate an unencrypted >>notify = OK. >> >>Generating the unencrypted notify could involve nothing more than a hash >>table lookup (which you had to do anyway to determine that the spi/cookie >>was invalid), a couple of >>memcpys, and a SendBuffer. >> >>Plus, sending the unencrypted notify allows the peer to generate an alarm: >>SOMEONE IS SPOOFING PACKETS!!! (since either you generated the notify in >>response to a bad spi/cookie or the notify itself was spoofed) >> >>But if you respond to the unencrypted notify by initiating a new SA then you >>are at the mercy of a DoS attacker. >> >>Andrew >>_______________________________________________ >> Beauty without truth is insubstantial. >> Truth without beauty is unbearable. >> ---- **** ---- Kanta MATSUURA, Ph.D. Lecturer 3rd Department, Institute of Industrial Science, University of Tokyo, Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN Tel: +81-3-3402-6231 (ext. 2325) Fax: +81-3-3479-1736 E-Mail: kanta@iis.u-tokyo.ac.jp From owner-ipsec@lists.tislabs.com Mon Jan 24 04:32:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03149; Mon, 24 Jan 2000 04:32:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17627 Mon, 24 Jan 2000 05:54:00 -0500 (EST) From: "Lisa Wilkinson" To: Subject: leaving the list Date: Mon, 24 Jan 2000 03:05:51 -0800 Message-ID: <000d01bf665a$fa9ce7e0$aa15a8c0@lw_sat.baltimore.ie> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Im leaving this list now and Baltimore Technologies. Thanks for all your help. Next week I may be found at ladywishbone@hotmail.com Bye Lisa Wilkinson From owner-ipsec@lists.tislabs.com Mon Jan 24 04:32:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03161; Mon, 24 Jan 2000 04:32:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17643 Mon, 24 Jan 2000 05:55:02 -0500 (EST) From: "Lisa Wilkinson" To: Subject: Remove Date: Mon, 24 Jan 2000 03:07:22 -0800 Message-ID: <000e01bf665b$30f93a00$aa15a8c0@lw_sat.baltimore.ie> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, How do I remove myself from this list...... anyone? Lisa From owner-ipsec@lists.tislabs.com Mon Jan 24 08:16:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06384; Mon, 24 Jan 2000 08:16:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18424 Mon, 24 Jan 2000 09:19:32 -0500 (EST) From: Barney Wolff To: Date: Thu, 20 Jan 2000 12:54 EST Subject: Re: Bruce Schneier on IPsec Content-Type: text/plain Message-ID: <38874c9a0.2c38@databus.databus.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As long as we're responding to commentary, will some kind soul point out the convincing rebuttal to the vigorous assertion by the unperson (wjs) that IKE is subject to DoS attack. Surely there is one ... Barney Wolff From owner-ipsec@lists.tislabs.com Mon Jan 24 08:17:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06433; Mon, 24 Jan 2000 08:17:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18425 Mon, 24 Jan 2000 09:19:37 -0500 (EST) Message-Id: <3.0.5.32.20000120174624.00ac2d40@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 20 Jan 2000 17:46:24 +0100 To: ipsec@lists.tislabs.com, ippcp@external.cisco.com From: Joern Sierwald Subject: Re: Deflate issue In-Reply-To: <200001142010.MAA21692@honeybee.cisco.com> References: <387F6BB4.BBDCD2F1@ire-ma.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA04820 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:10 14.1.2000 -0800, Avram Shacham wrote: >Slava, > >Am I reading correctly that the DEFLATE decompression is dependent >on the parameters to the compression process, i.e. an extra attribute >needs to be negotiated in order to enable the decompression process? >For comparison, afaik, LZS has the capability to decompress a packet >regardless of the compression parameters. > >Your suggestion to negotiate a DEFLATE-specific attribute, >while doable and supported by the protocol, will have the side-effect >of excluding that compression algorithm from the list of well-known >algorithms, as RFC2393 defines: > > Compression Parameter Index (CPI) > > 16-bit index. The CPI is stored in network order. The values > 0-63 define well-known compression algorithms, which require no <== > additional information, and are used for manual setup. The <== > values themselves are identical to IPCOMP Transform identifiers > as defined in [SECDOI]. [...] The values > 256-61439 are negotiated between the two nodes in definition of > an IPComp Association, as defined in section 4. Note: When > negotiating one of the well-known algorithms, the nodes MAY > select a CPI in the pre-defined range 0-63. > >In order to keep the advantages of using a well-known algorithm ID, >I'd suggest (a) modifying RFC2394 to dictate a unified approach, >or (b) creating multiple DEFLATE IDs in the DOI, one for each option. > >avram > We interoperated with several vendor at the San Diego bakeoffs, they used Deflate header and Adler32. IRE didn't include header and adler32, so they had loads of problems. They way I see it, we were all (except IRE) wrong. But changing the behaviour now would break interoperability. I'd request a new ID in the DOI, for "DEFLATE without the rubbish". Jörn From owner-ipsec@lists.tislabs.com Mon Jan 24 08:22:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06493; Mon, 24 Jan 2000 08:22:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18437 Mon, 24 Jan 2000 09:20:31 -0500 (EST) Message-Id: <200001241401.JAA06583@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: poised@lists.tislabs.com From: The IESG Subject: Protocol Action: IAB and IESG Selection, Confirmation, and Recall to BCP Date: Mon, 24 Jan 2000 09:01:36 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved the Internet-Draft 'IAB and IESG Selection, Confirmation, and Recall' as a BCP. In the same action, the IESG approved publication of Publicly Verifiable Nomcom Random Selection as an Informational RFC. These documents are the product of the Process for Organization of Internet Standards ONgoing Working Group. The IESG contact person is Fred Baker. Technical Summary IAB and IESG Selection, Confirmation, and Recall documents the process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. Publicly Verifiable Nomcom Random Selection describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. Protocol Quality This draft was reviewed for utility and representation of the known process by Randy Bush. Note to RFC Editor The IESG requests the RFC Editor to make two minor editing changes before publishing draft-ietf-poisson-nomcom-v2: 1. In Section 2, subsection (6), the last paragraph should be changed from: It is consistent with this rule for nominating committee members who have served on prior nominating committees to advise the current committee on the deliberations and results of the prior committee, as necessary and appropriate. to: It is consistent with this rule for current nominating committee members who have served on prior nominating committees to advise the current committee on the deliberations and results of the prior committee, as necessary and appropriate. 2. In Section 3, subsection (7), the text "in favor of a specific outcome." should be appended at the end of the second paragraph. The end result will be: A method is fair if each eligible volunteer is equally likely to be selected. A method is unbiased if no one can influence its outcome in favor of a specific outcome. From owner-ipsec@lists.tislabs.com Mon Jan 24 10:04:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08206; Mon, 24 Jan 2000 10:04:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19065 Mon, 24 Jan 2000 11:13:27 -0500 (EST) Date: Mon, 24 Jan 2000 11:18:13 -0500 From: "Michael H. Warfield" To: Barney Wolff Cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec Message-ID: <20000124111813.C2165@alcove.wittsend.com> References: <38874c9a0.2c38@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <38874c9a0.2c38@databus.databus.com>; from barney@databus.com on Thu, Jan 20, 2000 at 12:54:00PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jan 20, 2000 at 12:54:00PM -0500, Barney Wolff wrote: > As long as we're responding to commentary, will some kind soul point out > the convincing rebuttal to the vigorous assertion by the unperson (wjs) > that IKE is subject to DoS attack. Surely there is one ... Similarly, can someone post a demonstration of said DoS attack? I would like to examine it. > Barney Wolff Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Mon Jan 24 11:23:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09581; Mon, 24 Jan 2000 11:23:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19596 Mon, 24 Jan 2000 12:50:58 -0500 (EST) Date: Mon, 24 Jan 2000 12:52:04 -0500 (EST) From: "David M. Balenson" Message-Id: <200001241752.MAA11465@clipper.gw.tislabs.com> To: ipsec@tislabs.com Subject: Last chance to register for NDSS 2000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk L A S T C H A N C E - R E G I S T E R F O R N D S S 2 0 0 0 THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 REGISTER ONLINE ON OR BEFORE WEDNESDAY, JANUARY 26 REGISTER ONSITE AFTER WEDNESDAY, JANUARY 26 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ipsec@lists.tislabs.com Mon Jan 24 11:23:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09597; Mon, 24 Jan 2000 11:23:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19530 Mon, 24 Jan 2000 12:39:17 -0500 (EST) Date: Mon, 24 Jan 2000 12:43:35 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Bruce Schneier on IPsec In-Reply-To: <38886529.E3D38477@bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 21 Jan 2000, Steve Kent wrote: > ...The attached > document is in MS Word, because I use the change control features to > make the annotations. An ASCII version can be made available... Please do. Some of us are not equipped to read proprietary data formats easily. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 24 11:35:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09854; Mon, 24 Jan 2000 11:35:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18412 Mon, 24 Jan 2000 09:18:32 -0500 (EST) Message-ID: <38886529.E3D38477@bbn.com> Date: Fri, 21 Jan 2000 08:54:50 -0500 From: Steve Kent Reply-To: kent@bbn.com Organization: GTE Internetworking X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> <4.2.1.20000120173822.00b476f0@mail.vpnc.org> Content-Type: multipart/mixed; boundary="------------C118C512B01573D8EDFA4DF1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------C118C512B01573D8EDFA4DF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Since there has been so much mail recently re Bruce's comments, I thought it appropriate to post my annotated comments on the evaluation. I apologize to Bruce, in advance, for not supplying these to him privately first. He kindly sent a copy of his analysis a while ago, but I was able to find time to review it only recently. I was planning to send him this document, but I feel that it is appropriate to reply to the list now, given the growing volume of comments. The attached document is in MS Word, because I use the change control features to make the annotations. An ASCII version can be made available later, if necessary. Steve --------------C118C512B01573D8EDFA4DF1 Content-Type: application/msword; x-mac-type="5738424E"; x-mac-creator="4D535744"; name="IPsec review comments" Content-Transfer-Encoding: base64 Content-Description: Unknown Document Content-Disposition: inline; filename="IPsec review comments" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAFAAAAAAAAAAAA AAAAEAAAagEAAAEAAAD+////AAAAAAEAAABhAQAASwEAAEwBAABxAQAA//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJ AgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAA4LuE7GO/AQ0CAABABAAAAAAAADEAVABhAGIA bABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAOAAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cgEAAJI5AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAQAgAAAKoCAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAC0AQAAAAAAAHAB AAD9////////////////////BwAAAHoBAABPAQAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwA AAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcA AAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAA RQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIA AABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAA YAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0A AABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAA ewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAAFQAZQB4AHQAAAACAA8ADABDShQAT0oEAFFKBAAk AC8AAQACASQAAAAEAEwAaQBzAHQAAAAKABAAD4RoARGEmP4AACoAQgABABIBKgAAAAkAQgBv AGQAeQAgAFQAZQB4AHQAAAAGABEAFKR4AAAAPABDAAEAIgE8AAAAEABCAG8AZAB5ACAAVABl AHgAdAAgAEkAbgBkAGUAbgB0AAAACgASAA+EaAEUpHgAAAAyABwAAQAyATIAAAANAE4AbwBy AG0AYQBsACAASQBuAGQAZQBuAHQAAAAGABMAD4TQAgAAKABVQKIAQQEoAAAACQBIAHkAcABl AHIAbABpAG4AawAAAAYAPioBQioCAAAAAH/6AAADAACoAgAAAP////8SAAAABCH//wEAAAAA AAAh//8CAAAAAAAEIf//AwAAAAAAACH//wQAAAAAAAQh//8FAAAAAAAAIP//BgAAAAAABCD/ /wcAAAAAAAAg//8IAAAAAAAEIP//CQAAAAAAACD//woAAAAAAAQg//8LAAAAAAAAIP//DAAA AAAABCD//w0AAAAAAAAg//8OAAAAAAAEIP//DwAAAAAAACD//xAAAAAAAAQg//8RAAAAAAAA IP//EgAAAAAAAAAAAE4LAAA+GAAAvCYAAEE0AACVQQAAa08AAMNeAABsbQAAC3wAADJSAG8A bwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAAlzx1 7GO/AfUBAABABAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATQEAAC1sAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4AQAAAKoCAAAA AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAoAAAC0AQAAAAAAAP//////////WQEAAO4BAAD9////BwAAAHoBAABPAQAA CQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYA AAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAA JAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEA AAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAA PwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwA AABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAA WgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcA AABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAA dQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAAG8AbgB0 AAAAAAAAAAAAAAAAADQAWkABAPIANAAAAAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIADwAM AENKFABPSgQAUUoEACQALwABAAIBJAAAAAQATABpAHMAdAAAAAoAEAAPhGgBEYSY/gAAKgBC AAEAEgEqAAAACQBCAG8AZAB5ACAAVABlAHgAdAAAAAYAEQAUpHgAAAA8AEMAAQAiATwAAAAQ AEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAAAAKABIAD4RoARSkeAAAADIAHAAB ADIBMgAAAA0ATgBvAHIAbQBhAGwAIABJAG4AZABlAG4AdAAAAAYAEwAPhNACAAAoAFVAogBB ASgAAAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAABgA+KgFCKgIAAAAAS/oAAAMAAKgCAAQA//// /xIAAAAEIf//AQAAAAAAACH//wIAAAAAAAQh//8DAAAAAAAAIf//BAAAAAAABCH//wUAAAAA AAAg//8GAAAAAAAEIP//BwAAAAAAACD//wgAAAAAAAQg//8JAAAAAAAAIP//CgAAAAAABCD/ /wsAAAAAAAAg//8MAAAAAAAEIP//DQAAAAAAACD//w4AAAAAAAQg//8PAAAAAAAAIP//EAAA AAAABCD//xEAAAAAAAAg//8SAAAABgARABSkeAAAADwAQwABACIBPAAAABAAQgBvAGQAeQAg AFQAZQB4AHQAIABJAG4AZABlAG4AdAAAAAoAEgAPhGgBFKR4AAAAMgAcAAEAMgEyAAAADQBO AG8AcgBtAGEAbAAgAEkAbgBkAGUAbgB0AAAABgATAA+E0AIAACgAVUCiAEEBKAAAAAkASAB5 AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqAgAAAAB/+gAAAwAAqAIAAAD/////EgAAAAQh//8B AAAAAAAAIf//AgAAAAAABCH//wMAAAAAAAAh//8EAAAAAAAEIf//BQAAAAAAACD//wYAAAAA AAQg//8HAAAAAAAAIP//CAAAAAAABCD//wkAAAAAAAAg//8KAAAAAAAEIP//CwAAAAAAACD/ /wwAAAAAAAQg//8NAAAAAAAAIP//DgAAAAAABCD//w8AAAAAAAAg//8QAAAAAAAEIP//EQAA AAAAACD//xIAAAAAAAAAAABOCwAAPhgAALwmAABBNAAAlUEAAGtPAADDXgAAbG0AAAt8AAAy igAAT5gAAP2nAAA0tgAAIcYAABbUAABN4wAAbvIAAH/6AAAAABcAAAABAAEAAAACAIgCAAAD AIQBAAAEAJ8AAAAFANAAAAAGANcEAAAHAGgAAAAIAOkAAAAJAPEEAAAKAHQBAAAAAAAAAABO CwAAPhgAALwmAABBNAAAlUEAAGtPAADDXgAAZG0AAAN8AAAqigAAR5gAAPWnAAAUtgAAAcYA APbTAAAt4wAATvIAAEv6AAAAABcAAAABAAEAAAACAIgCAAADAIQBAAAEAJ8AAAAFANAAAAAG ANcEAAAHAGgAAAAIAOkAAAAJAPEEAAAKAHQBAAALAAQBAAAMAAoCAAANAFsAAAAOAC4DAAAP AC0BAAAQABUBAAARAAAAAAAAAAAALgAAAEcAAABbAAAAbwAAAHAAAAB/AAAAgAAAAKcAAADS AAAABAEAACUBAABkAQAAmwEAAJwBAACtAQAAuAEAALkBAADWAQAAWwMAAFwDAAD1BgAA9gYA AMcIAADICAAA6gkAAOsJAAA7CwAAPAsAAE0LAABOCwAARCkAAEUpAAAgKgAAISoAAJEsAACS LAAAsi0AALMtAAC0LQAA1y0AAMIvAADDLwAAvzAAAMAwAABVMwAAVjMAAMU1AADGNQAAxzUA APU1AAD2NQAA6zcAAOw3AADtNwAABTgAAJc6AACYOgAAWj8AAFs/AADIQAAAyUAAAMpAAAD1 QAAANEIAADVCAABKQgAAS0IAAI1DAACOQwAA50MAAOhDAAD6QwAAoEYAAKFGAADVSgAA1koA ADtQAAA8UAAAH1YAACBWAABXMSBhbmQgUkZDIDI0NTEgIFxjaXRle1JGQzI0MDEsUkZDMjQw MixSRkMyNDAzLFJGQzI0MDQsUkZDMjQwNSxSRkMyNDA2LFJGQzI0MDcsUkZDMjQwOCxSRkMy NDA5LFJGQzI0MTAsUkZDMjQxMSxSRkMyNDUxfS4gVGhlIE9ha2xleSBwcm90b2NvbCBcY2l0 ZXtSRkMyNDEyfSBpcyBvbmx5IGFuIGluZm9ybWF0aW9uYWwgUkZDOyBpdCBpcyBub3QgcGFy dCBvZiB0aGUgc3RhbmRhcmQgYW5kIGlzIG5vdCB1c2VkIGluIElTQUtNUC4gUkZDIGRvY3Vt ZW50cyBhcmUgYXZhaWxhYmxlIGZyb20ge1x0dCBmdHA6ZnRwLmlzaS5lZHVcc2xhc2ggaW4t bm90ZXNcc2xhc2ggcmZjPG4+LnR4dH0uIA0NQXMgXGNpdGV7UkZDMjQwMX0gc3RhdGVzOiBg YFRoZSBzdWl0ZSBvZiBJUHNlYyBwcm90b2NvbHMgYW5kIGFzc29jaWF0ZWQgZGVmYXVsdCBh bGdvcml0aG1zIGFyZSBkZXNpZ25lZCB0byBwcm92aWRlIGhpZ2ggcXVhbGl0eSBzZWN1cml0 eSBmb3IgSW50ZXJuZXQgdHJhZmZpYy4gSG93ZXZlciwgdGhlIHNlY3VyaXR5IG9mZmVyZWQg YnkgdXNlIG9mIHRoZXNlIHByb3RvY29scyB1bHRpbWF0ZWx5IGRlcGVuZHMgb24gdGhlIHF1 YWxpdHkgb2YgdGhlIHRoZWlyIGltcGxlbWVudGF0aW9uLCB3aGljaCBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIHNldCBvZiBzdGFuZGFyZHMuICBNb3Jlb3ZlciwgdGhlIHNlY3Vy aXR5IG9mIGEgY29tcHV0ZXIgc3lzdGVtIG9yIG5ldHdvcmsgaXMgYSBmdW5jdGlvbiBvZiBt YW55IGZhY3RvcnMsIGluY2x1ZGluZyBwZXJzb25uZWwsIHBoeXNpY2FsLCBwcm9jZWR1cmFs LCBjb21wcm9taXNpbmcgZW1hbmF0aW9ucywgYW5kIGNvbXB1dGVyIHNlY3VyaXR5IHByYWN0 aWNlcy4gIFRodXMgSVBzZWMgaXMgb25seSBvbmUgcGFydCBvZiBhbiBvdmVyYWxsIHN5c3Rl bSBzZWN1cml0eSBhcmNoaXRlY3R1cmUuJycgVGhpcyBldmFsdWF0aW9uIG9ubHkgZGVhbHMg d2l0aCB0aGUgSVBzZWMgYW5kIElTQUtNUCBzcGVjaWZpY2F0aW9ucyBhbmQgaXMgbm90IGRp cmVjdGx5IGNvbmNlcm5lZCB3aXRoIGFueSBvZiB0aGUgb3RoZXIgZmFjdG9ycy4gSG93ZXZl ciwgd2UgZG8gY29tbWVudCBvbiBhc3BlY3RzIG9mIHRoZSBzcGVjaWZpY2F0aW9ucyB0aGF0 IGFmZmVjdCBvdGhlciBzZWN1cml0eSBmYWN0b3JzLg0NSVBzZWMgYW5kIElTQUtNUCBhcmUg aGlnaGx5IGNvbXBsZXggc3lzdGVtcy4gVW5mb3J0dW5hdGVseSwgd2UgY2Fubm90IGdpdmUg YSBzdWZmaWNpZW50bHkgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlc2Ugc3lzdGVtcyBp biB0aGlzIGRvY3VtZW50IHRvIGFsbG93IHRoZSByZWFkZXIgdG8gdW5kZXJzdGFuZCBvdXIg Y29tbWVudHMgd2l0aG91dCBiZWluZyBmYW1pbGlhciB3aXRoIElQc2VjIGFuZCBJU0FLTVAu IE91ciBjb21tZW50cyBmcmVxdWVudGx5IHJlZmVyIHRvIHNwZWNpZmljIHBsYWNlcyBpbiB0 aGUgUkZDIGRvY3VtZW50cyBmb3IgZWFzZSBvZiByZWZlcmVuY2UuDQ1UaGUgcmVzdCBvZiB0 aGlzIHJlcG9ydCBpcyBzdHJ1Y3R1cmVkIGFzIGZvbGxvd3MuIENoYXB0ZXJ+XHJlZntjaGFw OmdlbmVyYWx9IGdpdmVzIHNvbWUgZ2VuZXJhbCBjb21tZW50cy4gQ2hhcHRlcn5ccmVme2No YXA6YnVsa30gZGlzY3Vzc2VzIHRoZSBJUHNlYyBwcm90b2NvbHMgdGhhdCBoYW5kbGUgYnVs ayBkYXRhLiBDaGFwdGVyflxyZWZ7Y2hhcDpJU0FLTVB9IGRpc2N1c3NlcyB0aGUgSVNBS01Q IGdlbmVyaWMgZGVmaW5pdGlvbnMuIENoYXB0ZXJ+XHJlZntjaGFwOklQc2VjRE9JfSB0YWxr cyBhYm91dCB0aGUgSVBzZWMgRG9tYWluIG9mIEludGVycHJldGF0aW9uIHdoaWNoIGdpdmVz IG1vcmUgZGV0YWlscyBvbiBob3cgdGhlIGdlbmVyaWMgSVNBS01QIHN0cnVjdHVyZSBhcHBs aWVzIHRvIHRoZSBJUHNlYyBwcm90b2NvbHMuIEZpbmFsbHksIGNoYXB0ZXJ+XHJlZntjaGFw OklLRX0gZGlzY3Vzc2VzIHRoZSBJS0UgcHJvdG9jb2wgdGhhdCBpcyB0aGUgZGVmYXVsdCBr ZXkgbWFuYWdlbWVudCBwcm90b2NvbCB1c2VkIHdpdGggSVNBS01QLg0NXGNoYXB0ZXJ7R2Vu ZXJhbCBjb21tZW50c31cbGFiZWx7Y2hhcDpnZW5lcmFsfQ0NXHNlY3Rpb257Q29tcGxleGl0 eX0NDUNvbXBsZXhpdHkgaXMgdGhlIGJpZ2dlc3QgZW5lbXkgb2Ygc2VjdXJpdHkuIFRoaXMg bWlnaHQgc2VlbSBhbiBvZGQgc3RhdGVtZW50IGluIHRoZSBsaWdodCBvZiB0aGUgbWFueSBm aWVsZGVkIHN5c3RlbXMgdGhhdCBleGhpYml0IGNyaXRpY2FsIHNlY3VyaXR5IGZhaWx1cmVz IGZvciB2ZXJ5IHNpbXBsZSByZWFzb25zLiBJdCBpcyB0cnVlIG5vbmV0aGVsZXNzLiBUaGUg c2ltcGxlIGZhaWx1cmVzIGFyZSBzaW1wbGUgdG8gYXZvaWQsIGFuZCBvZnRlbiBzaW1wbGUg dG8gZml4LiBUaGUgcHJvYmxlbSBpcyBub3QgdGhhdCB3ZSBkbyBub3Qga25vdyBob3cgdG8g c29sdmUgdGhlbTsgaXQgaXMgdGhhdCB0aGlzIGtub3dsZWRnZSBpcyBvZnRlbiBub3QgYXBw bGllZC4gQ29tcGxleGl0eSwgaG93ZXZlciwgaXMgYSBkaWZmZXJlbnQgYmVhc3QgYmVjYXVz ZSB3ZSBkbyBub3QgcmVhbGx5IGtub3cgaG93IHRvIGhhbmRsZSBpdC4NDURlc2lnbmluZyBh bnkgc29mdHdhcmUgc3lzdGVtIGlzIGFsd2F5cyBhIG1hdHRlciBvZiB3ZWlnaGluZyB2YXJp b3VzIHJlcXVpcmVtZW50cy4gVGhlc2UgaW5jbHVkZSBmdW5jdGlvbmFsaXR5LCBlZmZpY2ll bmN5LCBwb2xpdGljYWwgYWNjZXB0YWJpbGl0eSwgc2VjdXJpdHksIGJhY2t3YXJkIGNvbXBh dGliaWxpdHksIGRlYWRsaW5lcywgZmxleGliaWxpdHksIGVhc2Ugb2YgdXNlLCBhbmQgbWFu eSBtb3JlLiBUaGUgdW5zcG9rZW4gcmVxdWlyZW1lbnQgaXMgb2Z0ZW4gdGhlIGNvbXBsZXhp dHkuIElmIHRoZSBzeXN0ZW0gZ2V0cyB0b28gY29tcGxleCwgaXQgYmVjb21lcyB0b28gZGlm ZmljdWx0LCBhbmQgdGhlcmVmb3JlIHRvbyBleHBlbnNpdmUsIHRvIG1ha2UuIEFzIGZ1bGZp bGxpbmcgbW9yZSBvZiB0aGUgcmVxdWlyZW1lbnRzIHVzdWFsbHkgaW52b2x2ZXMgYSBtb3Jl IGNvbXBsZXggZGVzaWduLCBtYW55IHN5c3RlbXMgZW5kIHVwIHdpdGggYSBkZXNpZ24gdGhh dCBpcyBhcyBjb21wbGV4IGFzIHRoZSBkZXNpZ25lcnMgYW5kIGltcGxlbWVudG9ycyBjYW4g cmVhc29uYWJseSBoYW5kbGUuIA0NVmlydHVhbGx5IGFsbCBzb2Z0d2FyZSBpcyBkZXZlbG9w ZWQgdXNpbmcgYSB0cnktYW5kLWZpeCBtZXRob2RvbG9neS4gU21hbGwgcGllY2VzIGFyZSBp bXBsZW1lbnRlZCwgdGVzdGVkLCBmaXhlZCwgYW5kIHRlc3RlZCBhZ2Fpbi5cZm9vdG5vdGV7 VXN1YWxseSBzZXZlcmFsIGl0ZXJhdGlvbnMgYXJlIHJlcXVpcmVkLn0gU2V2ZXJhbCBvZiB0 aGVzZSBzbWFsbCBwaWVjZXMgYXJlIGNvbWJpbmVkIGludG8gYSBsYXJnZXIgbW9kdWxlLCBh bmQgdGhpcyBtb2R1bGUgaXMgdGVzdGVkLCBmaXhlZCwgYW5kIHRlc3RlZCBhZ2Fpbi4gVGhl IGVuZCByZXN1bHQgaXMgc29mdHdhcmUgdGhhdCBtb3JlIG9yIGxlc3MgZnVuY3Rpb25zIGFz IGV4cGVjdGVkLCBhbHRob3VnaCB3ZSBhcmUgYWxsIGZhbWlsaWFyIHdpdGggdGhlIGhpZ2gg ZnJlcXVlbmN5IG9mIGZ1bmN0aW9uYWwgZmFpbHVyZXMgb2Ygc29mdHdhcmUgc3lzdGVtcy4N DVRoaXMgcHJvY2VzcyBvZiBtYWtpbmcgZmFpcmx5IGNvbXBsZXggc3lzdGVtcyBhbmQgaW1w bGVtZW50aW5nIHRoZW0gd2l0aCBhIHRyeS1hbmQtZml4IG1ldGhvZG9sb2d5IGhhcyBhIGRl dmFzdGF0aW5nIGVmZmVjdCBvbiB0aGUgc2VjdXJpdHkuIFRoZSBjZW50cmFsIHJlYXNvbiBp cyB0aGF0IHlvdSBjYW5ub3QgdGVzdCBmb3Igc2VjdXJpdHkuIFRoZXJlZm9yZSwgc2VjdXJp dHkgYnVncyBhcmUgbm90IGRldGVjdGVkIGR1cmluZyB0aGUgZGV2ZWxvcG1lbnQgcHJvY2Vz cyBpbiB0aGUgc2FtZSB3YXkgdGhhdCBmdW5jdGlvbmFsIGJ1Z3MgYXJlLiBTdXBwb3NlIGEg cmVhc29uYWJseSBzaXplZCBwcm9ncmFtIGlzIGRldmVsb3BlZCB3aXRob3V0IGFueSB0ZXN0 aW5nIGF0IGFsbCBkdXJpbmcgZGV2ZWxvcG1lbnQgYW5kIHF1YWxpdHkgY29udHJvbC4gV2Ug ZmVlbCBjb25maWRlbnQgaW4gc3RhdGluZyB0aGF0IHRoZSByZXN1bHQgd2lsbCBiZSBhIGNv bXBsZXRlbHkgdXNlbGVzcyBwcm9ncmFtOyBtb3N0IGxpa2VseSBpdCB3aWxsIG5vdCBwZXJm b3JtIGFueSBvZiB0aGUgZGVzaXJlZCBmdW5jdGlvbnMgY29ycmVjdGx5LiBZZXQgdGhpcyBp cyBleGFjdGx5IHdoYXQgd2UgZ2V0IGZyb20gdGhlIHRyeS1hbmQtZml4IG1ldGhvZG9sb2d5 IHdoZW4gd2UgbG9vayBhdCBzZWN1cml0eS4gDQ1UaGUgb25seSByZWFzb25hYmxlIHdheSB0 byBgYHRlc3QnJyB0aGUgc2VjdXJpdHkgb2YgYSBzZWN1cml0eSBwcm9kdWN0IGlzIHRvIHBl cmZvcm0gc2VjdXJpdHkgcmV2aWV3cyBvbiBpdC5cZm9vdG5vdGV7QSBjcmFja2luZyBjb250 ZXN0IGNhbiBiZSBzZWVuIGFzIGEgY2hlYXAgd2F5IG9mIGdldHRpbmcgb3RoZXIgcGVvcGxl IHRvIGRvIGEgc2VjdXJpdHkgYW5hbHlzaXMuIFRoZSBiaWcgcHJvYmxlbSBpcyBpbnRlcnBy ZXRpbmcgdGhlIHJlc3VsdHMuIElmIHRoZSBwcml6ZSBpcyBub3QgY2xhaW1lZCwgaXQgZG9l cyBub3QgaW1wbHkgdGhhdCBhbnkgY29tcGV0ZW50IGFuYWx5c2lzIHdhcyBkb25lIGFuZCBj YW1lIHVwIGVtcHR5Ln0gQSBzZWN1cml0eSByZXZpZXcgaXMgYSBtYW51YWwgcHJvY2Vzczsg aXQgaXMgcmVsYXRpdmVseSBleHBlbnNpdmUgaW4gdGVybXMgb2YgdGltZSBhbmQgZWZmb3J0 IGFuZCBpdCB3aWxsIG5ldmVyIGJlIGFibGUgdG8gc2hvdyB0aGF0IHRoZSBwcm9kdWN0IGlz IGluIGZhY3Qgc2VjdXJlLiBbdGhpcyBzZWVtcyB0byBpZ25vcmUgdGhlIGFwcHJvYWNoZXMg dXN1YWxseSBlbXBsb3llZCBmb3IgaGlnaCBhc3N1cmFuY2Ugc3lzdGVtIGRlc2lnbiBhbmQg aW1wbGVtZW50YXRpb24gLCBpLmUuLCBjYXJlZnVsIGRlc2lnbiBhbmQgcmV2aWV3IGNvdXBs ZWQgd2l0aCByaWdpZCBkZXZlbG9wbWVudCBwcm9jZWR1cmVzLCBhbGwgcHJpb3IgdG8gdGVz dGluZy5dDQ1UaGUgbW9yZSBjb21wbGV4IHRoZSBzeXN0ZW0gaXMsIHRoZSBoYXJkZXIgYSBz ZWN1cml0eSBldmFsdWF0aW9uIGJlY29tZXMuIEEgbW9yZSBjb21wbGV4IHN5c3RlbSB3aWxs IGhhdmUgbW9yZSBzZWN1cml0eS1yZWxhdGVkIGVycm9ycyBpbiB0aGUgc3BlY2lmaWNhdGlv biwgZGVzaWduLCBhbmQgaW1wbGVtZW50YXRpb24uIFdlIGNsYWltIHRoYXQgdGhlIG51bWJl ciBvZiBlcnJvcnMgYW5kIGRpZmZpY3VsdHkgb2YgdGhlIGV2YWx1YXRpb24gYXJlIG5vdCBs aW5lYXIgZnVuY3Rpb25zIG9mIHRoZSBjb21wbGV4aXR5LCBidXQgaW4gZmFjdCBncm93IG11 Y2ggZmFzdGVyLg0NRm9yIHRoZSBzYWtlIG9mIHNpbXBsaWNpdHksIGxldCB1cyBhc3N1bWUg dGhlIHN5c3RlbSBoYXMgJG4kIGRpZmZlcmVudCBvcHRpb25zLCBlYWNoIHdpdGggdHdvIHBv c3NpYmxlIGNob2ljZXMuXGZvb3Rub3Rle1dlIHVzZSAkbiQgYXMgdGhlIG1lYXN1cmUgb2Yg dGhlIGNvbXBsZXhpdHkuIFRoaXMgc2VlbXMgcmVhc29uYWJsZSwgYXMgdGhlIGxlbmd0aCBv ZiB0aGUgc3lzdGVtIHNwZWNpZmljYXRpb24gYW5kIHRoZSBpbXBsZW1lbnRhdGlvbiBpcyBw cm9wb3J0aW9uYWwgdG8gJG4kLn0gVGhlbiB0aGVyZSBhcmUgJG4obi0xKS8yID0gTyhuXjIp JCBkaWZmZXJlbnQgcGFpcnMgb2Ygb3B0aW9ucyB0aGF0IGNvdWxkIGludGVyYWN0IGluIHVu ZXhwZWN0ZWQgd2F5cywgYW5kICQyXm4kIGRpZmZlcmVudCBjb25maWd1cmF0aW9ucyBhbHRv Z2V0aGVyLiBFYWNoIHBvc3NpYmxlIGludGVyYWN0aW9uIGNhbiBsZWFkIHRvIGEgc2VjdXJp dHkgd2Vha25lc3MsIGFuZCB0aGUgbnVtYmVyIG9mIHBvc3NpYmxlIGNvbXBsZXggaW50ZXJh Y3Rpb25zIHRoYXQgaW52b2x2ZSBzZXZlcmFsIG9wdGlvbnMgaXMgaHVnZS4gQXMgZWFjaCBp bnRlcmFjdGlvbiBjYW4gcHJvZHVjZSBhIHNlY3VyaXR5IHdlYWtuZXNzLCB3ZSBleHBlY3Qg dGhhdCB0aGUgbnVtYmVyIG9mIGFjdHVhbCBzZWN1cml0eSB3ZWFrbmVzc2VzIGdyb3dzIHZl cnkgcmFwaWRseSB3aXRoIGluY3JlYXNpbmcgY29tcGxleGl0eS4NDVRoZSBzYW1lIGhvbGRz IGZvciB0aGUgc2VjdXJpdHkgZXZhbHVhdGlvbi4gRm9yIGEgc3lzdGVtIHdpdGggYSBtb2Rl cmF0ZSBudW1iZXIgb2Ygb3B0aW9ucywgY2hlY2tpbmcgYWxsIHRoZSBpbnRlcmFjdGlvbnMg YmVjb21lcyBhIGh1Z2UgYW1vdW50IG9mIHdvcmsuIENoZWNraW5nIGV2ZXJ5IHBvc3NpYmxl IGNvbmZpZ3VyYXRpb24gaXMgZWZmZWN0aXZlbHkgaW1wb3NzaWJsZS4gVGh1cyB0aGUgZGlm ZmljdWx0eSBvZiBwZXJmb3JtaW5nIHNlY3VyaXR5IGV2YWx1YXRpb25zIGFsc28gZ3Jvd3Mg dmVyeSByYXBpZGx5IHdpdGggaW5jcmVhc2luZyBjb21wbGV4aXR5LiBUaGUgY29tYmluYXRp b24gb2YgYWRkaXRpb25hbCAocG90ZW50aWFsKSB3ZWFrbmVzc2VzIGFuZCBhIG1vcmUgZGlm ZmljdWx0IHNlY3VyaXR5IGFuYWx5c2lzIHVuYXZvaWRhYmx5IHJlc3VsdHMgaW4gaW5zZWN1 cmUgc3lzdGVtcy4NDUluIGFjdHVhbCBzeXN0ZW1zLCB0aGUgc2l0dWF0aW9uIGlzIG5vdCBx dWl0ZSBzbyBiYWQ7IHRoZXJlIGFyZSBvZnRlbiBvcHRpb25zIHRoYXQgYXJlIGBgb3J0aG9n b25hbCcnIGluIHRoYXQgdGhleSBoYXZlIG5vIHJlbGF0aW9uIG9yIGludGVyYWN0aW9uIHdp dGggZWFjaCBvdGhlci4gVGhpcyBvY2N1cnMsIGZvciBleGFtcGxlLCBpZiB0aGUgb3B0aW9u cyBhcmUgb24gZGlmZmVyZW50IGxheWVycyBpbiB0aGUgY29tbXVuaWNhdGlvbiBzeXN0ZW0s IGFuZCB0aGUgbGF5ZXJzIGFyZSBzZXBhcmF0ZWQgYnkgYSB3ZWxsLWRlZmluZWQgaW50ZXJm YWNlIHRoYXQgZG9lcyBub3QgYGBzaG93JycgdGhlIG9wdGlvbnMgb24gZWl0aGVyIHNpZGUu IEZvciB0aGlzIHZlcnkgcmVhc29uLCBzdWNoIGEgc2VwYXJhdGlvbiBvZiBhIHN5c3RlbSBp bnRvIHJlbGF0aXZlbHkgaW5kZXBlbmRlbnQgbW9kdWxlcyB3aXRoIGNsZWFybHkgZGVmaW5l ZCBpbnRlcmZhY2VzIGlzIGEgaGFsbG1hcmsgb2YgZ29vZCBkZXNpZ24uIEdvb2QgbW9kdWxh cml6YXRpb24gY2FuIGRyYW1hdGljYWxseSByZWR1Y2UgdGhlIGBgZWZmZWN0aXZlJycgY29t cGxleGl0eSBvZiBhIHN5c3RlbSB3aXRob3V0IHRoZSBuZWVkIHRvIGVsaW1pbmF0ZSBpbXBv cnRhbnQgZmVhdHVyZXMuIE9wdGlvbnMgd2l0aGluIGEgc2luZ2xlIG1vZHVsZSBjYW4gb2Yg Y291cnNlIHN0aWxsIGhhdmUgaW50ZXJhY3Rpb25zIHRoYXQgbmVlZCB0byBiZSBhbmFseXpl ZCwgc28gdGhlIG51bWJlciBvZiBvcHRpb25zIHBlciBtb2R1bGUgc2hvdWxkIGJlIG1pbmlt aXplZC4gTW9kdWxhcml6YXRpb24gd29ya3Mgd2VsbCB3aGVuIHVzZWQgcHJvcGVybHksIGJ1 dCBtb3N0IGFjdHVhbCBzeXN0ZW1zIHN0aWxsIGluY2x1ZGUgY3Jvc3MtZGVwZW5kZW5jaWVz IHdoZXJlIG9wdGlvbnMgaW4gZGlmZmVyZW50IG1vZHVsZXMgZG8gYWZmZWN0IGVhY2ggb3Ro ZXIuDQ1BIG1vcmUgY29tcGxleCBzeXN0ZW0gbG9zZXMgb24gYWxsIGZyb250cy4gSXQgY29u dGFpbnMgbW9yZSB3ZWFrbmVzc2VzIHRvIHN0YXJ0IHdpdGgsIGl0IGlzIG11Y2ggaGFyZGVy IHRvIGFuYWx5emUsIGFuZCBpdCBpcyBtdWNoIGhhcmRlciB0byBpbXBsZW1lbnQgd2l0aG91 dCBpbnRyb2R1Y2luZyBzZWN1cml0eS1jcml0aWNhbCBlcnJvcnMgaW4gdGhlIGltcGxlbWVu dGF0aW9uLg0NQ29tcGxleGl0eSBub3Qgb25seSBtYWtlcyBpdCB2aXJ0dWFsbHkgaW1wb3Nz aWJsZSB0byBjcmVhdGUgYSBzZWN1cmUgaW1wbGVtZW50YXRpb24sIGl0IGFsc28gbWFrZXMg dGhlIHN5c3RlbSBleHRyZW1lbHkgaGFyZCB0byBtYW5hZ2UuIFRoZSBwZW9wbGUgcnVubmlu ZyB0aGUgYWN0dWFsIHN5c3RlbSB0eXBpY2FsbHkgZG8gbm90IGhhdmUgYSB0aG9yb3VnaCB1 bmRlcnN0YW5kaW5nIG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMgaW52b2x2ZWQuIENvbmZpZ3Vy YXRpb24gb3B0aW9ucyBzaG91bGQgdGhlcmVmb3JlIGJlIGtlcHQgdG8gYSBtaW5pbXVtLCBh bmQgdGhlIG9wdGlvbnMgc2hvdWxkIHByb3ZpZGUgYSB2ZXJ5IHNpbXBsZSBtb2RlbCB0byB0 aGUgdXNlci4gQ29tcGxleCBjb21iaW5hdGlvbnMgb2Ygb3B0aW9ucyBhcmUgdmVyeSBsaWtl bHkgdG8gYmUgY29uZmlndXJlZCBlcnJvbmVvdXNseSwgd2hpY2ggcmVzdWx0cyBpbiBhIGxv c3Mgb2Ygc2VjdXJpdHkuIFRoZSBzdG9yaWVzIGluIFxjaXRle1RoZUNvZGVicmVha2Vyc30g YW5kIFxjaXRle0E6V2h5RmFpbH0gaWxsdXN0cmF0ZSBob3cgbWFuYWdlbWVudCBvZiBjb21w bGV4IHN5c3RlbXMgaXMgb2Z0ZW4gdGhlIHdlYWtlc3QgbGluay4NDUJvdGggSVBzZWMgYW5k IElTQUtNUCBhcmUgdG9vIGNvbXBsZXggdG8gYmUgc2VjdXJlLiBUaGUgZGVzaWduIG9idmlv dXNseSB0cmllcyB0byBzdXBwb3J0IG1hbnkgZGlmZmVyZW50IHNpdHVhdGlvbnMgd2l0aCBk aWZmZXJlbnQgb3B0aW9ucy4gV2UgZmVlbCB2ZXJ5IHN0cm9uZ2x5IHRoYXQgdGhlIHJlc3Vs dGluZyBzeXN0ZW0gaXMgd2VsbCBiZXlvbmQgdGhlIGxldmVsIG9mIGNvbXBsZXhpdHkgdGhh dCBjYW4gYmUgaW1wbGVtZW50ZWQgc2VjdXJlbHkgd2l0aCBjdXJyZW50IG1ldGhvZG9sb2dp ZXMuDQ0NXHNlY3Rpb257U3RhdGluZyB3aGF0IGlzIGFjaGlldmVkfQ1BIHNlY3VyaXR5IGFu YWx5c2lzIGV2YWx1YXRlcyB0aGUgc2VjdXJpdHkgYXNwZWN0cyBvZiBhIHN5c3RlbS4gVG8g YmUgYWJsZSB0byBnaXZlIGFueSBzZW5zaWJsZSBhbnN3ZXIsIGl0IHNob3VsZCBiZSBjbGVh ciB3aGF0IHByb3BlcnRpZXMgdGhlIHN5c3RlbSBjbGFpbXMgdG8gaGF2ZS4gVGhhdCBpcywg dGhlIHN5c3RlbSBkb2N1bWVudGF0aW9uIHNob3VsZCBjbGVhcmx5IHN0YXRlIHdoYXQgc2Vj dXJpdHkgcHJvcGVydGllcyBhcmUgYWNoaWV2ZWQuIFRoaXMgY2FuIGJlIHNlZW4gYXMgdGhl IGZ1bmN0aW9uYWwgc3BlY2lmaWNhdGlvbiBvZiB0aGUgc2VjdXJpdHkgcHJvcGVydGllcy4g VGhpcyBhcHBsaWVzIG5vdCBvbmx5IHRvIHRoZSBlbnRpcmUgc3lzdGVtLCBidXQgYWxzbyB0 byB0aGUgaW5kaXZpZHVhbCBtb2R1bGVzLiBBdCBlYWNoIG1vZHVsZSBvciBmdW5jdGlvbiwg dGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgc2hvdWxkIGJlIHNwZWNpZmllZC4gDQ1BIGdvb2Qg Y29tcGFyaXNvbiBpcyB0aGUgdGVzdGluZyBvZiBhIHByb2R1Y3QuIFRoZSB0ZXN0aW5nIHZl cmlmaWVzIHRoYXQgdGhlIHByb2R1Y3QgcGVyZm9ybXMgYWNjb3JkaW5nIHRvIHRoZSBmdW5j dGlvbmFsIHNwZWNpZmljYXRpb25zLiBXaXRob3V0IHNwZWNpZmljYXRpb25zLCB0aGUgdGVz dGVycyBtaWdodCBoYXZlIHNvbWUgaW50ZXJlc3RpbmcgY29tbWVudHMsIGJ1dCB0aGV5IGNh biBuZXZlciBnaXZlIGEgcmVhbCBhbnN3ZXIuIA0NV2l0aG91dCBzZWN1cml0eSBzcGVjaWZp Y2F0aW9ucywgdGhlIGZpcnN0IHRhc2sgb2YgdGhlIHNlY3VyaXR5IGFuYWx5c2lzIGlzIHRv IGNyZWF0ZSBkZXNjcmlwdGlvbnMgb2YgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgYWNoaWV2 ZWQsIGJhc2VkIG9uIHRoZSBwZXJjZWl2ZWQgaW50ZW50aW9ucyBvZiB0aGUgc3lzdGVtIGRl c2lnbmVyLiBUaGUgc3Vic2VxdWVudCBldmFsdWF0aW9uIG1pZ2h0IHRoZW4gdHVybiB1cCBw cm9ibGVtcyBvZiB0aGUgZm9ybSBgYHRoaXMgZnVuY3Rpb24gZG9lcyBub3QgYWNoaWV2ZSB0 aGUgcHJvcGVydGllcyB0aGF0IHdlIHRoaW5rIGl0IHNob3VsZCBoYXZlLicnIFRoZSBvYnZp b3VzIGFuc3dlciB3aWxsIGJlOiBgYGJ1dCB0aGF0IGlzIG5vdCB0aGUgcHJvcGVydGllcyB0 aGF0IEkgZGVzaWduZWQgaXQgdG8gaGF2ZS4nJyBWZXJ5IHF1aWNrbHkgdGhlIGRpc2N1c3Np b24gbW92ZXMgYXdheSBmcm9tIHRoZSBhY3R1YWwgc2VjdXJpdHkgaW50byB3aGF0IHdhcyBt ZWFudC4gVGhlIG92ZXJhbGwgcmVzdWx0IGlzIGEgc2VjdXJpdHkgZXZhbHVhdGlvbiB0aGF0 IG1pZ2h0IHBvaW50IG91dCBzb21lIHBvdGVudGlhbCB3ZWFrbmVzc2VzLCBidXQgdGhhdCB3 aWxsIGhhcmRseSBoZWxwIGluIGltcHJvdmluZyB0aGUgc2VjdXJpdHkuDQ1UaGUgSVBzZWMg YW5kIElTQUtNUCBwcm90b2NvbHMgZG8gbm90IHNwZWNpZnkgY2xlYXJseSB3aGljaCBzZWN1 cml0eSBwcm9wZXJ0aWVzIHRoZXkgY2xhaW0gdG8gYWNoaWV2ZS4gW1JGQ3MgMjQwMSwgMjQw MiwgYW5kIDI0MDYgY2xlYXJseSBzdGF0ZSB0aGUgc2VjdXJpdHkgc2VydmljZXMgb2ZmZXJl ZCBieSB0aGUgQUggYW5kIEVTUCBwcm90b2NvbHMuXSBUaGUgc2FtZSBob2xkcyBmb3IgdGhl IG1vZHVsZXMgYW5kIGZ1bmN0aW9ucy4gW21vZHVsZXMgYXJlIG5vdCBzcGVjaWZpZWQgYnkg dGhlc2Ugc3RhbmRhcmRzOyB0aGV5IGFyZSBpbXBsZW1lbnRhdGlvbiBhcnRpZmFjdHMuXSBX ZSByZWNvbW1lbmQgdGhhdCBlYWNoIGZ1bmN0aW9uLCBtb2R1bGUsIGFuZCBwcm90b2NvbCBi ZSBleHRlbmRlZCB0byBpbmNsdWRlIGNsZWFyIHNwZWNpZmljYXRpb25zIHJlZ2FyZGluZyB0 aGUgc2VjdXJpdHktcmVsYXRlZCBmdW5jdGlvbmFsaXR5IHRoZXkgYWNoaWV2ZS4gV2UgZmVl bCB0aGF0IHVubGVzcyB0aGlzIGlzIGRvbmUsIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRv IHBlcmZvcm0gYW4gYWRlcXVhdGUgc2VjdXJpdHkgZXZhbHVhdGlvbiBvbiBhIHN5c3RlbSBv ZiB0aGlzIGNvbXBsZXhpdHkuDQ0NXGNoYXB0ZXJ7QnVsayBkYXRhIGhhbmRsaW5nfVxsYWJl bHtjaGFwOmJ1bGt9DQ1JbiB0aGlzIGNoYXB0ZXIgd2UgZGlzY3VzcyB0aGUgbWV0aG9kcyB1 c2VkIHRvIGhhbmRsZSB0aGUgZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRpb24gb2YgdGhl IGJ1bGsgZGF0YSwgYXMgc3BlY2lmaWVkIGluIFxjaXRle1JGQzI0MDEsUkZDMjQwMixSRkMy NDAzLFJGQzI0MDQsUkZDMjQwNSxSRkMyNDA2LFJGQzI0NTEsUkZDMjQxMCxSRkMyNDExfS4g VG9nZXRoZXIgdGhlc2UgZG9jdW1lbnRzIHNwZWNpZnkgdGhlIElQc2VjIHByb3RvY29sLiBU aGV5IHNwZWNpZnkgdGhlIGFjdHVhbCBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBv ZiBwYWNrZXRzLCBhc3N1bWluZyB0aGF0IHN5bW1ldHJpYyBrZXlzIGhhdmUgYWxyZWFkeSBi ZWVuIGV4Y2hhbmdlZC4gV2UgcmVmZXIgdGhlIHJlYWRlciB0byBcY2l0ZXtSRkMyNDAxfSBz ZWN0aW9ucyAxLS00LjIgZm9yIGFuIG92ZXJ2aWV3IG9mIHRoaXMgcGFydCBvZiBJUHNlYyBh bmQgdGhlIHJlbGV2YW50IHRlcm1pbm9sb2d5Lg0NDVxzZWN0aW9ue0Z1bmN0aW9uYWxpdHl9 DUlQc2VjIGlzIGNhcGFibGUgb2YgcHJvdmlkaW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBjb25m aWRlbnRpYWxpdHkgc2VydmljZXMgb24gYSBwYWNrZXQgbGV2ZWwuIFRoZSBzZWN1cml0eSBj b25maWd1cmF0aW9uIG9mIGFuIElQc2VjIGltcGxlbWVudGF0aW9uIGlzIGRvbmUgY2VudHJh bGx5LCBwcmVzdW1hYmx5IGJ5IHRoZSBzeXN0ZW0gYWRtaW5pc3RyYXRvci4gW0luIHNvbWUg ZW52aXJvbm1lbnRzLCBhIHNpbmdsZSBhZG1pbmlzdHJhdG9yIG1pZ2h0IGNvbnRyb2wgdGhl IGNvbmZpZ3VyYXRpb24gb2YgZWFjaCBJUHNlYyBpbXBsZW1lbnRhdGlvbiwgb3IgZWFjaCB1 c2VyIG1pZ2h0IGhhdmUgc29tZSBjb250cm9sIG92ZXIgaXQuICBUaGUgbGF0dGVyIHdvdWxk IHRlbmQgdG8gYmUgY2hhcmFjdGVyaXplZCBhcyBhIGRpc3RyaWJ1dGVkIG1hbmFnZW1lbnQg cGFyYWRpZ20sIG5vdCBhIGNlbnRyYWwgb25lLiAgQWxzbywgdHdvIElQc2VjIHBlZXJzIGNv bW11bmljYXRlIE9OTFkgaWYgYm90aCBhZ3JlZSBvbiB0aGUgc2VjdXJpdHkgcGFyYW1ldGVy cyBmb3IgdGhlIFNBLCBpLmUuLCB0aGVyZSBpcyBzdWl0YWJsZSBvdmVybGFwIGluIHRoZSBT UERzLiAgSW4gdGhhdCBzZW5zZSB0b28sIHNlY3VyaXR5IGNvbmZpZ3VyYXRpb24gaXMgZGlz dHJpYnV0ZWQuXQ0NSVBzZWMgaXMgdmVyeSBzdWl0YWJsZSBmb3IgY3JlYXRpbmcgYSBWUE4g b3ZlciB0aGUgSW50ZXJuZXQsIGltcHJvdmVkIHNlY3VyaXR5IGZvciBkaWFsLWluIGNvbm5l Y3Rpb25zIHRvIHBvcnRhYmxlcywgcmVzdHJpY3RpbmcgYWNjZXNzIHRvIHBhcnRzIG9mIGEg bmV0d29yaywgZXRjLiBUaGVzZSBhcmUgdmVyeSBtdWNoIG5ldHdvcmstbGV2ZWwgZnVuY3Rp b25zLiBJUHNlYyBieSBpdHNlbGYgZG9lcyBub3Qgc3VwcGx5IGFwcGxpY2F0aW9uLWxldmVs IHNlY3VyaXR5LiBBdXRoZW50aWNhdGlvbiBsaW5rcyB0aGUgcGFja2V0IHRvIHRoZSBzZWN1 cml0eSBnYXRld2F5IG9mIHRoZSBvcmlnaW5hdGluZyBuZXR3b3JrLCB0aGUgb3JpZ2luYXRp bmcgaG9zdCwgb3IgcG9zc2libHkgdGhlIG9yaWdpbmF0aW5nIHVzZXIsIGJ1dCBub3QgdG8g dGhlIGFwcGxpY2F0aW9uIGluIHF1ZXN0aW9uIG9yIHRoZSBkYXRhIHRoZSBhcHBsaWNhdGlv biB3YXMgaGFuZGxpbmcgd2hlbiBpdCBzZW50IHRoZSBwYWNrZXQuIFt0cnVlLCBidXQgZm9y IG1hbnkgYXBwbGljYXRpb25zLCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBpcyBub3Qg bmVlZGVkLCBhbmQgaXRzIGltcGxlbWVudGF0aW9uIG1pZ2h0IHdlbGwgYmUgYWNjb3JkZWQg bGVzcyBhc3N1cmFuY2UgdGhhbiB0aGUgbmV0d29yayBsYXllciBzZWN1cml0eSBwcm92aWRl ZCBieSBJUHNlYy4gVGhpcyBwYXJhZ3JhcGggc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IHRoZXJl IGlzIHNvbWUgaW1wb3J0YW50IGJlbmVmaXQgdG8gbGlua2luZyBkYXRhIHRvIGFuIGFwcGxp Y2F0aW9uLCB0aHJvdWdoIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmljIHNlY3VyaXR5IG1lY2hh bmlzbS4gIFRoZXJlIGFyZSBnb29kIGV4YW1wbGVzIG9mIHdoZXJlIHRoaXMgaXMgdHJ1ZSwg ZS5nLiwgZS1tYWlsIGFuZCBkaXJlY3Rvcmllcy4gSG93ZXZlciwgdW5sZXNzIHRoZXJlIGFy ZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBzZWN1cml0eSBzZW1hbnRpY3MgdGhhdCBjYW5ub3Qg YmUgY2FwdHVyZWQgYnkgdXNlIG9mIGFuIGFwcGxpY2F0aW9uIHNlY3VyaXR5IHByb3RvY29s LCB5b3VyIG93biBhcmd1bWVudHMgYWJvdXQgc2ltcGxpY2l0eSwgYXMgd2VsbCBhcyBhIG51 bWJlciBvZiBhcmd1bWVudHMgcmUgYXNzdXJhbmNlLCBhcmd1ZSBhZ2FpbnN0IHByb2xpZmVy YXRpb24gb2YgYXBwbGljYXRpb24gc2VjdXJpdHkgcHJvdG9jb2xzLl0NDVRoZSBJUHNlYyBm dW5jdGlvbmFsaXR5IGNhbiBzaWduaWZpY2FudGx5IGluY3JlYXNlIHRoZSBzZWN1cml0eSBv ZiB0aGUgbmV0d29yay4gSXQgaXMgbm90IGEgcGFuYWNlYSBmb3IgYWxsIHNlY3VyaXR5IHBy b2JsZW1zLCBhbmQgYXBwbGljYXRpb25zIHRoYXQgcmVxdWlyZSBzZWN1cml0eSBzZXJ2aWNl cyB3aWxsIHR5cGljYWxseSBoYXZlIHRvIHVzZSBvdGhlciBzZWN1cml0eSBzeXN0ZW1zIGlu IGFkZGl0aW9uIHRvIElQc2VjLiBbSSBtaWdodCBkaXNhZ3JlZSB3aXRoIHRoZSB0ZXJtIJN0 eXBpY2FsbHmUIGhlcmUuIEEgbG90IGRlcGVuZHMgb24gdGhlIGFwcGxpY2F0aW9uLCB3aGVy ZSBJUHNlYyBpcyBpbXBsZW1lbnRlZCwgZXRjLl0NDQ1cc2VjdGlvbntDb21wbGV4aXR5fVxs YWJlbHtzZWM6Y29tcGxleGl0eX0NT3VyIGJpZ2dlc3QgY3JpdGljaXNtIGlzIHRoYXQgSVBz ZWMgaXMgdG9vIGNvbXBsZXguIFRoZXJlIGFyZSB0b28gbWFueSBvcHRpb25zIHRoYXQgYWNo aWV2ZSB0aGUgc2FtZSBvciBzaW1pbGFyIHByb3BlcnRpZXMuIFtpZiB0aGV5IHdlcmUgY29t cGxldGVseSBlcXVpdmFsZW50IHRoaXMgd291bGQgYmUgYSBnb29kIGJhc2lzIGZvciBzaW1w bGlmeWluZyBJUHNlYy4gSG93ZXZlciwgdGhlcmUgYXJlIHN1YnRsZSBkaWZmZXJlbmNlcyB0 aGF0IGhhdmUgcmVzdWx0ZWQgaW4gdGhlIHByb2xpZmVyYXRpb24gb2Ygb3B0aW9ucyB5b3Ug YWRkcmVzcyBiZWxvdy5dDQ1cc3Vic2VjdGlvbntPcHRpb25zfQ0NSVBzZWMgc3VmZmVycyBm cm9tIGFuIGFidW5kYW5jZSBvZiBvcHRpb25zLiBGb3IgZXhhbXBsZSwgdHdvIGhvc3RzIHRo YXQgd2FudCB0byBhdXRoZW50aWNhdGUgSVAgcGFja2V0cyBjYW4gdXNlIGZvdXIgZGlmZmVy ZW50IG1vZGVzOiB0cmFuc3BvcnQvQUgsIHR1bm5lbC9BSCwgdHJhbnNwb3J0L0VTUCB3aXRo IE5VTEwgZW5jcnlwdGlvbiwgYW5kIHR1bm5lbC9FU1Agd2l0aCBOVUxMIGVuY3J5cHRpb24u IFRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZXNlIG9wdGlvbnMsIGJvdGggaW4gZnVuY3Rp b25hbGl0eSBhbmQgcGVyZm9ybWFuY2UsIGFyZSBtaW5vci4gDQ1JbiBwYXJ0aWN1bGFyLCB0 aGUgZm9sbG93aW5nIG9wdGlvbnMgc2VlbSB0byBjcmVhdGUgYSBncmVhdCBkZWFsIG9mIG5l ZWRsZXNzIGNvbXBsZXhpdHk6DQ1cYmVnaW57ZW51bWVyYXRlfQ1caXRlbSBUaGVyZSBhcmUg dHdvIG1vZGVzIHRoYXQgY2FuIGJlIHVzZWQ6IHRyYW5zcG9ydCBtb2RlIGFuZCB0dW5uZWwg bW9kZS4gSW4gdHJhbnNwb3J0IG1vZGUsIHRoZSBJUCBoZWFkZXIgb2YgdGhlIHBhY2tldCBp cyBsZWZ0IHVudG91Y2hlZC4gQUggYXV0aGVudGljYXRlcyBib3RoIHRoZSBJUCBoZWFkZXIg YW5kIHRoZSBwYWNrZXQgcGF5bG9hZC4gRVNQIGVuY3J5cHRzIGFuZCBhdXRoZW50aWNhdGVz IHRoZSBwYXlsb2FkLCBidXQgbm90IHRoZSBoZWFkZXIuIFRoZSBsYWNrIG9mIGhlYWRlciBh dXRoZW50aWNhdGlvbiBpbiB0cmFuc3BvcnQvRVNQIGlzIGEgcmVhbCB3ZWFrbmVzcywgYXMg aXQgYWxsb3dzIHZhcmlvdXMgbWFuaXB1bGF0aW9ucyB0byBiZSBwZXJmb3JtZWQuIEluIHR1 bm5lbCBtb2RlLCB0aGUgZnVsbCBvcmlnaW5hbCBJUCBwYWNrZXQgKGluY2x1ZGluZyBoZWFk ZXJzKSBpcyB1c2VkIGFzIHRoZSBwYXlsb2FkIGluIGEgbmV3IElQIHBhY2tldCB3aXRoIG5l dyBoZWFkZXJzLiBUaGUgc2FtZSBBSCBvciBFU1AgZnVuY3Rpb25zIGFyZSB1c2VkLiBBcyB0 aGUgb3JpZ2luYWwgaGVhZGVyIGlzIG5vdyBpbmNsdWRlZCBpbiB0aGUgRVNQIGF1dGhlbnRp Y2F0aW9uLCB0aGUgdHJhbnNwb3J0L0VTUCBhdXRoZW50aWNhdGlvbiB3ZWFrbmVzcyBubyBs b25nZXIgZXhpc3RzLg0NVHJhbnNwb3J0IG1vZGUgcHJvdmlkZXMgYSBzdWJzZXQgb2YgdGhl IGZ1bmN0aW9uYWxpdHkgb2YgdHVubmVsIG1vZGUuIFRoZSBvbmx5IGFkdmFudGFnZSB0aGF0 IHdlIGNhbiBzZWUgdG8gdHJhbnNwb3J0IG1vZGUgaXMgdGhhdCBpdCB1c2VzIGEgc29tZXdo YXQgc21hbGxlciBiYW5kd2lkdGguIEhvd2V2ZXIsIHRoZSB0dW5uZWwgbW9kZSBjb3VsZCBi ZSBleHRlbmRlZCBpbiBhIHN0cmFpZ2h0Zm9yd2FyZCB3YXkgd2l0aCBhIHNwZWNpYWxpemVk IGhlYWRlci1jb21wcmVzc2lvbiBzY2hlbWUgdGhhdCB3ZSB3aWxsIGV4cGxhaW4gc2hvcnRs eS4gVGhpcyB3b3VsZCBhY2hpZXZlIHZpcnR1YWxseSB0aGUgc2FtZSBwZXJmb3JtYW5jZSBh cyB0cmFuc3BvcnQgbW9kZSB3aXRob3V0IGludHJvZHVjaW5nIGFuIGVudGlyZWx5IG5ldyBt b2RlLiBXZSB0aGVyZWZvcmUgcmVjb21tZW5kIHRoYXQgdGhlIHRyYW5zcG9ydCBtb2RlIGJl IGVsaW1pbmF0ZWQuIFt0cmFuc3BvcnQgbW9kZSBhbmQgdHVubmVsIG1vZGUgYWRkcmVzcyBm dW5kYW1lbnRhbGx5IGRpZmZlcmVudCByZXF1aXJlbWVudHMsIGZyb20gYSBuZXR3b3JraW5n IHBvaW50IG9mIHZpZXcuIFdoZW4gc2VjdXJpdHkgZ2F0ZXdheXMgYXJlIGludm9sdmVkLCB0 aGUgdXNlIG9mIHR1bm5lbCBtb2RlIGlzIGFuIGFic29sdXRlIHJlcXVpcmVtZW50LCB3aGVy ZWFzIGl0IGlzIGEgbWlub3IgKGFuZCByYXJlbHkgdXNlZCkgZmVhdHVyZSBmb3IgY29tbXVu aWNhdGlvbnMgYmV0d2VlbiBlbmQgc3lzdGVtcy4gQSBwcm9wb3NhbCB0byBtYWtlIGFsbCB0 cmFmZmljIHR1bm5lbCBtb2RlLCBhbmQgdG8gdHJ5IHRvIG9mZnNldCB0aGUgYWRkZWQgb3Zl cmhlYWQgdGhyb3VnaCBjb21wcmVzc2lvbiwgc2VlbXMgdG8gaWdub3JlIHRoZSBJUENPTVAg ZmFjaWxpdHkgdGhhdCBpcyBhbHJlYWR5IGF2YWlsYWJsZSB0byBJUHNlYyBpbXBsZW1lbnRh dGlvbnMuXQ0NXGl0ZW0gVGhlcmUgYXJlIHR3byBwcm90b2NvbHM6IEFIIGFuZCBFU1AuIEFI IHByb3ZpZGVzIGF1dGhlbnRpY2F0aW9uLCBhbmQgRVNQIHByb3ZpZGVzIGVuY3J5cHRpb24s IGF1dGhlbnRpY2F0aW9uLCBvciBib3RoLiBJbiB0cmFuc3BvcnQgbW9kZSwgQUggcHJvdmlk ZXMgYSBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0aGFuIEVTUCBjYW4gcHJvdmlkZSwgYXMg aXQgYWxzbyBhdXRoZW50aWNhdGVzIHRoZSBJUCBoZWFkZXIuIE9uZSBvZiB0aGUgc3RhbmRh cmQgbW9kZXMgb2Ygb3BlcmF0aW9uIHdvdWxkIHNlZW0gdG8gYmUgdG8gdXNlIGJvdGggQUgg YW5kIEVTUCBpbiB0cmFuc3BvcnQgbW9kZS4gW2FsdGhvdWdoIHRoaXMgbW9kZSBpcyByZXF1 aXJlZCB0byBiZSBzdXBwb3J0ZWQsIGl0IHNlZW1zIHRvIGJlIHJhcmVseSB1c2VkLiBQZXJo YXBzIHRoZSBiZXN0IHVzZSBjYXNlIGZvciB0aGlzIGFyaXNlcyBpZiB0aGVyZSBhcmUgb3B0 aW9ucyB0byBiZSBwcm90ZWN0ZWQgaW4gdGhlIElQIGhlYWRlciB0aGF0IG1pZ2h0IGJlIHZl cmlmaWVkIGVuIHJvdXRlICh1c2luZyBzeW1tZXRyaWMga2V5cyBhdmFpbGFibGUgdG8gYm90 aCB0aGUgZW5kcG9pbnRzIGFuZCB0aGUgaW50ZXJtZWRpYXRlIHN5c3RlbXMpIHdoaWxlIHRo ZSBFU1AgaW50ZWdyaXR5L2F1dGhlbnRpY2l0eSBrZXlzIGFyZSBhdmFpbGFibGUgb25seSB0 byB0aGUgZW5kIHBvaW50cy5dIEluIHR1bm5lbCBtb2RlLCB0aGUgYXV0aGVudGljYXRpb24g dGhhdCBFU1AgcHJvdmlkZXMgaXMgZ29vZCBlbm91Z2ggKGl0IGluY2x1ZGVzIHRoZSBJUCBo ZWFkZXIpLCBhbmQgQUggaXMgdHlwaWNhbGx5IG5vdCBjb21iaW5lZCB3aXRoIEVTUCBcY2l0 ZVtzZWN0aW9uIDQuNV17UkZDMjQwMX0uIFt0aGUgZXhhbXBsZSBhYm92ZSBzaG93cyB3aHkg b25lIG1pZ2h0IHdpc2ggdG8gdXNlIEFIIGZvciB0aGUgb3V0ZXIgaGVhZGVyLCBidXQgbW9z dCBsaWtlbHkgd2l0aCBFU1AgaW4gdHJhbnNwb3J0IG1vZGUuXSAoSW1wbGVtZW50YXRpb25z IGFyZSBub3QgcmVxdWlyZWQgdG8gc3VwcG9ydCBuZXN0ZWQgdHVubmVscyB0aGF0IHdvdWxk IGFsbG93IEVTUCBhbmQgQUggdG8gYm90aCBiZSB1c2VkLikNDVRoZSBBSCBwcm90b2NvbCBc Y2l0ZXtSRkMyNDAyfSBhdXRoZW50aWNhdGVzIHRoZSBJUCBoZWFkZXJzIG9mIHRoZSBsb3dl ciBsYXllcnMuIFtBSCBhdXRoZW50aWNhdGVzIHRoZSBJUCBoZWFkZXIgYXQgdGhlIFNBTUUg bGF5ZXIsIGluIG1hbnkgcmVzcGVjdHMuIEFIIHdhcyBvcmlnaW5hbGx5IGRlc2NyaWJlZCBh cyBhbiBJUCAodjQpIG9wdGlvbi4gSW4gSVB2NiwgQUggaXMgdmlld2VkIGFzICBwYXJ0IG9m IHRoZSBBSCBoZWFkZXIsIGFuZCBtYXkgYXBwZWFyIGJlZm9yZSBvdGhlciBoZWFkZXIgZXh0 ZW5zaW9ucyAoc2VlIHNlY3Rpb24gNC4xIG9mIFJGQyAyNDAxKS4gSSBhZ3JlZSB0aGF0IEFI IHJlcHJlc2VudHMgdWdseSBsYXllcmluZywgYnV0IGl0knMgbm90IGFzIGJhZCBhcyB5b3Ug c3VnZ2VzdCBoZXJlLl0gVGhpcyBjcmVhdGVzIGFsbCBraW5kIG9mIHByb2JsZW1zLCBhcyBz b21lIGhlYWRlciBmaWVsZHMgY2hhbmdlIGluIHRyYW5zaXQuIEFzIGEgcmVzdWx0LCB0aGUg QUggcHJvdG9jb2wgbmVlZHMgdG8gYmUgYXdhcmUgb2YgYWxsIGRhdGEgZm9ybWF0cyB1c2Vk IGF0IGxvd2VyIGxheWVycyBzbyB0aGF0IHRoZXNlIG11dGFibGUgZmllbGRzIGNhbiBiZSBh dm9pZGVkLiBbdGhpcyBpcyBhbiBpbmFjY3VyYXRlIGNoYXJhY3Rlcml6YXRpb24sIGVzcGVj aWFsbHkgZ2l2ZW4gdGhlIHN0YXR1cyBvZiBBSCByZSBJUHY2LiBEb26SdCB0aGluayBvZiBB SCBhcyBhIHRyYW5zcG9ydCBwcm90b2NvbC4gSXQgaXNuknQuXSBUaGlzIGlzIGEgdmVyeSB1 Z2x5IGNvbnN0cnVjdGlvbiwgYW5kIG9uZSB0aGF0IHdpbGwgY3JlYXRlIG1vcmUgcHJvYmxl bXMgd2hlbiBmdXR1cmUgZXh0ZW5zaW9ucyB0byB0aGUgSVAgcHJvdG9jb2wgYXJlIG1hZGUg dGhhdCBjcmVhdGUgbmV3IGZpZWxkcyB0aGF0IHRoZSBBSCBwcm90b2NvbCBpcyBub3QgYXdh cmUgb2YuIFtSRkMgMjQwMiBleHBsYWlucyBob3cgdG8gZGVhbCB3aXRoIG5ldyBJUCBoZWFk ZXIgZmllbGRzIGluIHY2IChzZWUgc2VjdGlvbiAzLjMuMy4xLjIuMikuIFRoZSBleGlzdGVu Y2Ugb2YgYSBtdXRhYmlsaXR5IGZsYWcgaW4gc3VjaCBleHRlbnNpb25zIG1ha2VzIHByb2Nl c3NpbmcgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQuXSBBbHNvLCBhcyBzb21lIGhlYWRl ciBmaWVsZHMgYXJlIG5vdCBhdXRoZW50aWNhdGVkLCB0aGUgcmVjZWl2aW5nIGFwcGxpY2F0 aW9uIHN0aWxsIGNhbm5vdCByZWx5IG9uIHRoZSBlbnRpcmUgcGFja2V0LiBUbyBmdWxseSB1 bmRlcnN0YW5kIHRoZSBhdXRoZW50aWNhdGlvbiBwcm92aWRlZCBieSBBSCwgYW4gYXBwbGlj YXRpb24gbmVlZHMgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIHNhbWUgY29tcGxleCBJUCBo ZWFkZXIgcGFyc2luZyBydWxlcyB0aGF0IEFIIHVzZXMuIFRoZSBjb21wbGV4IGRlZmluaXRp b24gb2YgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCBBSCBwcm92aWRlcyBjYW4gZWFzaWx5IGxl YWQgdG8gc2VjdXJpdHktcmVsZXZhbnQgZXJyb3JzLg0NVGhlIHR1bm5lbC9FU1AgYXV0aGVu dGljYXRpb24gYXZvaWRzIHRoaXMgcHJvYmxlbSwgYnV0IHVzZXMgbW9yZSBiYW5kd2lkdGgu IFtidXQgaXQgZG9lcyBub3QgcHJvdmlkZSBleGFjdGx5IHRoZSBzYW1lIGZlYXR1cmVzLCBh cyBub3RlZCBhYm92ZSwgc28gdGhlIGFsdGVybmF0aXZlIGlzIG5vdCBxdWl0ZSBlcXVpdmFs ZW50Ll0gVGhlIGV4dHJhIGJhbmR3aWR0aCByZXF1aXJlbWVudCBjYW4gYmUgcmVkdWNlZCBi eSBhIHNpbXBsZSBzcGVjaWFsaXplZCBjb21wcmVzc2lvbiBzY2hlbWU6IGZvciBzb21lIHN1 aXRhYmx5IGNob3NlbiBzZXQgb2YgSVAgaGVhZGVyIGZpZWxkcyAkWCQsIGEgc2luZ2xlIGJp dCBpbiB0aGUgRVNQIGhlYWRlciBpbmRpY2F0ZXMgd2hldGhlciB0aGUgJFgkIGZpZWxkcyBp biB0aGUgaW5uZXIgSVAgaGVhZGVyIGFyZSBpZGVudGljYWwgdG8gdGhlIGNvcnJlc3BvbmRp bmcgZmllbGRzIGluIHRoZSBvdXRlciBoZWFkZXIuXGZvb3Rub3Rle0EgdHJpdmlhbCBnZW5l cmFsaXphdGlvbiBpcyB0byBoYXZlIHNldmVyYWwgZmxhZyBiaXRzLCBlYWNoIGNvbnRyb2xs aW5nIGEgc2V0IG9mIElQIGhlYWRlciBmaWVsZHMufSBUaGUgZmllbGRzIGluIHF1ZXN0aW9u IGFyZSB0aGVuIHJlbW92ZWQgdG8gcmVkdWNlIHRoZSBwYXlsb2FkIHNpemUuIFRoaXMgY29t cHJlc3Npb24gc2hvdWxkIGJlIGFwcGxpZWQgYWZ0ZXIgY29tcHV0aW5nIHRoZSBhdXRoZW50 aWNhdGlvbiBidXQgYmVmb3JlIGFueSBlbmNyeXB0aW9uLiBUaGUgYXV0aGVudGljYXRpb24g aXMgdGh1cyBzdGlsbCBjb21wdXRlZCBvbiB0aGUgZW50aXJlIG9yaWdpbmFsIHBhY2tldC4g VGhlIHJlY2VpdmVyIHJlY29uc3RpdHV0ZXMgdGhlIG9yaWdpbmFsIHBhY2tldCB1c2luZyB0 aGUgb3V0ZXIgaGVhZGVyIGZpZWxkcywgYW5kIHZlcmlmaWVzIHRoZSBhdXRoZW50aWNhdGlv bi4gQSBzdWl0YWJsZSBjaG9pY2Ugb2YgdGhlIHNldCBvZiBoZWFkZXIgZmllbGRzICRYJCBh bGxvd3MgdHVubmVsL0VTUCB0byBhY2hpZXZlIHZpcnR1YWxseSB0aGUgc2FtZSBsb3cgbWVz c2FnZSBleHBhbnNpb24gYXMgdHJhbnNwb3J0L0FILg0NV2UgY29uY2x1ZGUgdGhhdCBlbGlt aW5hdGluZyB0cmFuc3BvcnQgbW9kZSBhbGxvd3MgdGhlIGVsaW1pbmF0aW9uIG9mIHRoZSBB SCBwcm90b2NvbCBhcyB3ZWxsLCB3aXRob3V0IGxvc3Mgb2YgZnVuY3Rpb25hbGl0eS4gIFtj b3VudGVyIGV4YW1wbGVzIHByb3ZpZGVkIGFib3ZlIHN1Z2dlc3QgdGhhdCB0aGlzIGNsYWlt IGlzIGEgYml0IG92ZXJzdGF0ZWQuXQ0NXGl0ZW0gVGhlIHN0YW5kYXJkIGRlZmluZXMgdHdv IGNhdGVnb3JpZXMgb2YgbWFjaGluZXM6IGhvc3RzIGFuZCBzZWN1cml0eSBnYXRld2F5cy4g SG9zdHMgY2FuIHVzZSB0cmFuc3BvcnQgbW9kZSwgYnV0IHNlY3VyaXR5IGdhdGV3YXlzIG11 c3QgYWx3YXlzIHVzZSB0dW5uZWwgbW9kZS4gRWxpbWluYXRpbmcgdHJhbnNwb3J0IG1vZGUg d291bGQgYWxzbyBhbGxvdyB0aGlzIGRpc3RpbmN0aW9uIHRvIGJlIGVsaW1pbmF0ZWQuIFZh cmlvdXMgY29tcHV0ZXJzIGNvdWxkIG9mIGNvdXJzZSBzdGlsbCBmdW5jdGlvbiBhcyBob3N0 cyBvciBzZWN1cml0eSBnYXRld2F5cywgYnV0IHRoZXNlIGRpZmZlcmVudCB1c2VzIHdvdWxk IG5vIGxvbmdlciBhZmZlY3QgdGhlIHByb3RvY29sLg0NXGl0ZW0gVGhlIEVTUCBwcm90b2Nv bCBhbGxvd3MgdGhlIHBheWxvYWQgdG8gYmUgZW5jcnlwdGVkIHdpdGhvdXQgYmVpbmcgYXV0 aGVudGljYXRlZC4gSW4gdmlydHVhbGx5IGFsbCBjYXNlcywgZW5jcnlwdGlvbiB3aXRob3V0 IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCB1c2VmdWwuIFRoZSBvbmx5IHNpdHVhdGlvbiBpbiB3 aGljaCBpdCBtYWtlcyBzZW5zZSBub3QgdG8gdXNlIGF1dGhlbnRpY2F0aW9uIGluIHRoZSBF U1AgcHJvdG9jb2wgaXMgd2hlbiB0aGUgYXV0aGVudGljYXRpb24gaXMgcHJvdmlkZWQgYnkg YSBzdWJzZXF1ZW50IGFwcGxpY2F0aW9uIG9mIHRoZSBBSCBwcm90b2NvbCAoYXMgaXMgZG9u ZSBpbiB0cmFuc3BvcnQgbW9kZSBiZWNhdXNlIEVTUCBhdXRoZW50aWNhdGlvbiBpbiB0cmFu c3BvcnQgbW9kZSBpcyBub3Qgc3Ryb25nIGVub3VnaCkuIFt0aGlzIGlzIG9uZSBleGFtcGxl IG9mIHdoZW4gb25lIG1pZ2h0IG5vdCBuZWVkIGF1dGhlbnRpY2F0aW9uIHdpdGggRVNQLCBi dXQgaXQgaXMgbm90IHRoZSBvbmx5IG9uZS4gSW4gZ2VuZXJhbCwgaWYgdGhlcmUgaXMgYSBo aWdoZXIgbGF5ZXIgaW50ZWdyaXR5IGFuZC9vciBhdXRoZW50aWNhdGlvbiBmdW5jdGlvbiBp biBwbGFjZSwgcHJvdmlkaW5nIGludGVncml0eS9hdXRoZW50aWNhdGlvbiBpbiBJUHNlYyBp cyByZWR1bmRhbnQsIGJvdGggaW4gdGVybXMgb2Ygc3BhY2UgYW5kIHByb2Nlc3NpbmcuIFRo ZSBhdXRoZW50aWNhdGlvbiBmaWVsZCBmb3IgRVNQIG9yIEFIIGlzIDEyIGJ5dGVzLiBGb3Ig YXBwbGljYXRpb25zIHdoZXJlIHBhY2tldCBzaXplcyBhcmUgcXVpdGUgc21hbGwsIGFuZCBm b3Igc29tZSBlbnZpcm9ubWVudHMgd2hlcmUgcGFja2V0IHNpemUgaXMgb2YgY3JpdGljYWwg aW1wb3J0YW5jZSwgZS5nLiwgcGFja2V0IHZvaWNlIGluIGEgd2lyZWxlc3MgZW52aXJvbm1l bnQsIEVTUCB3L28gYXV0aGVudGljYXRpb24gbWF5IGJlIGFwcHJvcHJpYXRlLiBUaGlzIGlz IGVzcGVjaWFsbHkgdHJ1ZSBpZiB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wgZW1ib2RpZXMg YW4gYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLiBUaGlzIG1pZ2h0IGhhcHBlbiBpZiB0aGUg YXBwbGljYXRpb24gcHJvdG9jb2wgd2FudHMgdG8gb2ZmZXIgdW5pZm9ybSBwcm90ZWN0aW9u IGlycmVzcGVjdGl2ZSBvZiB0aGUgbG93ZXIgbGF5ZXJzLiAgQWRtaXR0ZWRseSwgdGhpcyBt aWdodCBhbHNvIGNhdXNlIHRoZSBhcHBsaWNhdGlvbiB0byBvZmZlciBjb25maWRlbnRpYWxp dHkgYXMgd2VsbCwgYnV0IGRlcGVuZGluZyBvbiB0aGUgYXBwbGljYXRpb24sIHRoZSBjaG9p Y2VzIG9mIHdoYXQgc2VjdXJpdHkgc2VydmljZXMgYXJlIGJlaW5nIG9mZmVyZWQgbWF5IHZh cnkuXSBXaXRob3V0IHRoZSB0cmFuc3BvcnQgbW9kZSB0byB3b3JyeSBhYm91dCwgRVNQIHNo b3VsZCBhbHdheXMgcHJvdmlkZSBpdHMgb3duIGF1dGhlbnRpY2F0aW9uLiBXZSByZWNvbW1l bmQgdGhhdCBFU1AgYXV0aGVudGljYXRpb24gYWx3YXlzIGJlIHVzZWQsIGFuZCBvbmx5IGVu Y3J5cHRpb24gYmUgbWFkZSBvcHRpb25hbC4gW3RoZSBxdWVzdGlvbiBvZiBhdXRoZW50aWNh dGlvbiBhcyBhbiBpbnRyaW5zaWMgcGFydCBvZiBFU1AgaXMgaW5kZXBlbmRlbnQgb2YgbW9k ZSwgaS5lLiwgd2hldGhlciBvbmUgY2hvb3NlIHRvIHByb3ZpZGUgYXV0aGVudGljYXRpb24g YXMgYSBwYXJ0IG9mIEVTUCBpcyBub3QgZGV0ZXJtaW5lZCBieSB0aGUgY2hvaWNlIG9mIHRy YW5zcG9ydCB2cy4gdHVubmVsIG1vZGUuXSANDVxlbmR7ZW51bWVyYXRlfQ0NV2UgY2FuIHRo dXMgcmVtb3ZlIHRocmVlIG9mIHRoZSBmb3VyIG9wZXJhdGlvbmFsIG1vZGVzIHdpdGhvdXQg YW55IHNpZ25pZmljYW50IGxvc3Mgb2YgZnVuY3Rpb25hbGl0eS4gW3NvcnJ5LCBjYW6SdCBh Z3JlZSwgZ2l2ZW4gdGhlIGNvdW50ZXIgZXhhbXBsZXMgYWJvdmUuXQ0NXHN1YnNlY3Rpb257 VW5kZXNpcmFibGUgb3B0aW9uc30NVGhlcmUgYXJlIGV4aXN0aW5nIGNvbWJpbmF0aW9ucyBv ZiBvcHRpb25zIHRoYXQgYXJlIHVuZGVzaXJhYmxlLiBUaGVzZSBwb3NlIGEgcHJvYmxlbSB3 aGVuIG5vbi1leHBlcnRzIGhhdmUgdG8gY29uZmlndXJlIGFuIElQc2VjIGluc3RhbGxhdGlv bi4gR2l2ZW4gdGhlIGZhY3QgdGhhdCBleHBlcnRzIGFyZSByYXJlIGFuZCB1c3VhbGx5IGhh dmUgYmV0dGVyIHRoaW5ncyB0byBkbywgbW9zdCBJUHNlYyBpbnN0YWxsYXRpb25zIHdpbGwg YmUgY29uZmlndXJlZCBieSBub24tZXhwZXJ0cy4gW3llcywgd2Ugd2VyZSBhd2FyZSBvZiB0 aGlzIGNvbmNlcm4uIEhvd2V2ZXIsIHRoZXJlIGlzIGFsd2F5cyBhIHRyYWRlb2ZmIGJldHdl ZW4gYWRvcHRpbmcgdGhlIJN3ZSBrbm93IHdoYXSScyBiZXN0IGZvciB5b3WUIGFwcHJvYWNo LCB2cy4gdGhlIJN5b3UgY2FuIHNjcmV3IGl0IHVwIGlmIHlvdSB3YW50IHRvIGFwcHJvYWNo LpQgV2Ugb3B0ZWQgZm9yIGEgcG9pbnQgc29tZXdoZXJlIGFsb25nIHRoaXMgc3BlY3RydW0s IGJ1dCBub3QgYXQgZWl0aGVyIGVuZC5dDQ1cYmVnaW57ZW51bWVyYXRlfQ1caXRlbSBJbiB0 cmFuc3BvcnQgbW9kZSwgdXNlIG9mIEVTUCBwcm92aWRlcyBhdXRoZW50aWNhdGlvbiBvZiB0 aGUgcGF5bG9hZCBvbmx5LiBUaGUgYXV0aGVudGljYXRpb24gZXhjbHVkZXMgdGhlIElQIGhl YWRlcnMgb2YgdGhlIHBhY2tldC4gVGhlIHJlc3VsdCBpcyBhIGRhdGEgc3RyZWFtIHRoYXQg aXMgYWR2ZXJ0aXNlZCBhcyBgYGF1dGhlbnRpY2F0ZWQnJyBmb3Igd2hpY2ggY3JpdGljYWwg cGllY2VzIG9mIGluZm9ybWF0aW9uIChzdWNoIGFzIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0 aW9uIElQIG51bWJlcikgYXJlIG5vdCBhdXRoZW50aWNhdGVkLiBVbmxlc3MgdGhlIHN5c3Rl bSBhZG1pbmlzdHJhdG9yIGlzIGludGltYXRlbHkgZmFtaWxpYXIgd2l0aCB0aGUgZGlmZmVy ZW50IGZvcm1zIG9mIGF1dGhlbnRpY2F0aW9uIHVzZWQgYnkgSVBzZWMsIGl0IGlzIHF1aXRl IGxpa2VseSB0aGF0IHRoZSBhZG1pbmlzdHJhdG9yIHdpbGwgYXNzdW1lIHRoYXQgdGhlIGF1 dGhlbnRpY2F0aW9uIHByb3RlY3RzIHRoZSBlbnRpcmUgcGFja2V0LiBUaGUgY29tYmluYXRp b24gb2YgdHJhbnNwb3J0IG1vZGUgYW5kIHRoZSBFU1AgcHJvdG9jb2wgKHdpdGhvdXQgdGhl IEFIIHByb3RvY29sKSBzaG91bGQgdGhlcmVmb3JlIG5vdCBiZSBhbGxvd2VkLiBbVGhlIElQ IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzcyBhcmUgY292ZXJlZCBieSB0aGUgVENQ IGNoZWNrc3VtLCB3aGljaCBpcyBjb3ZlcmVkIGJ5IHRoZSBFU1AgaW50ZWdyaXR5IGNoZWNr LCBzbyB0aGlzIGRvZXMgbGltaXQgKGEgdGlueSBiaXQpIHRoZSBhYmlsaXR5IHRvIGNoYW5n ZSB0aGVzZSB2YWx1ZXMgd2l0aG91dCBkZXRlY3Rpb24uIEEgbW9yZSBzaWduaWZpY2FudCBv YnNlcnZhdGlvbiBpcyB0aGF0IHRyYW5zcG9ydCBtb2RlIElQc2VjIFNBcyB3aWxsIHByb2Jh Ymx5IGFsd2F5cyB1c2Ugc291cmNlIGFuZC9vciBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMg YXMgcGFydCBvZiB0aGUgc2VsZWN0b3Igc2V0LiBJbiBzdWNoIGNhc2VzLCB0YW1wZXJpbmcg d2l0aCB0aGUgZWl0aGVyIGFkZHJlc3Mgd2lsbCByZXN1bHQgaW4gZmFpbGVkIGF1dGhlbnRp Y2F0aW9uLl0NDVxpdGVtIFRoZSBzdGFuZGFyZCBhbGxvd3MgRVNQIHRvIGJlIHVzZWQgd2l0 aCB0aGUgTlVMTCBlbmNyeXB0aW9uLCBzdWNoIHRoYXQgaXQgcHJvdmlkZXMgb25seSBhdXRo ZW50aWNhdGlvbi4gVGhlIGF1dGhlbnRpY2F0aW9uIHByb3ZpZGVkIGJ5IEVTUCBpbiB0cmFu c3BvcnQgbW9kZSBpcyBsZXNzIGZ1bmN0aW9uYWwgdGhhbiB0aGUgYXV0aGVudGljYXRpb24g cHJvdmlkZWQgYnkgQUgsIGF0IGEgc2ltaWxhciBjb3N0LiBJZiB0cmFuc3BvcnQgbW9kZSBp cyByZXRhaW5lZCwgZWl0aGVyIHRoZSBFUFMgRVNQIGF1dGhlbnRpY2F0aW9uIHNob3VsZCBi ZSBleHRlbmRlZCBvciB0aGUgdXNlIG9mIEVTUCB3aXRoIG9ubHkgYXV0aGVudGljYXRpb24g c2hvdWxkIGJlIGZvcmJpZGRlbiBhbmQgcmVwbGFjZWQgYnkgdGhlIHVzZSBvZiBBSC4gW0VT UCBhdXRoZW50aWNhdGlvbiBpcyBtb3JlIGVmZmljaWVudCB0byBjb21wdXRlIHRoYW4gQUgs IGJlY2F1c2Ugb2YgdGhlIHNlbGVjdGl2ZSBJUCBoZWFkZXIgY292ZXJhZ2UgcHJvdmlkZWQg YnkgQUguICBUaHVzIHRoZXJlIGlzIGdvb2QgcmVhc29uIHRvIGFsbG93IGF1dGhlbnRpY2F0 aW9uLW9ubHkgRVNQIGFzIGFuIGFsdGVybmF0aXZlIHRvIEFILiBUaGlzIHBvaW50IHdhcyBk ZWJhdGVkIGJ5IHRoZSBncm91cCBhbmQsIHdpdGggaW1wbGVtZW50YXRpb24gZXhwZXJpZW5j ZSwgdmVuZG9ycyBjYW1lIHRvIGFncmVlIHRoYXQgdGhpcyBpcyB0cnVlLl0NDVxpdGVtIFRo ZSBFU1AgcHJvdG9jb2wgY2FuIHByb3ZpZGUgZW5jcnlwdGlvbiB3aXRob3V0IGF1dGhlbnRp Y2F0aW9uLiBUaGlzIGRvZXMgbm90IG1ha2UgbXVjaCBzZW5zZSBpbiBhbiBhcHBsaWNhdGlv bi4gSXQgcHJvdGVjdHMgdGhlIGFwcGxpY2F0aW9uIGFnYWluc3QgcGFzc2l2ZSBlYXZlc2Ry b3BwZXJzLCBidXQgcHJvdmlkZXMgbm8gcHJvdGVjdGlvbiBhZ2FpbnN0IGFjdGl2ZSBhdHRh Y2tzIHRoYXQgYXJlIG9mdGVuIGZhciBtb3JlIGRldmFzdGF0aW5nLiBBZ2FpbiwgdGhpcyBt b2RlIGNhbiBsdXJlIG5vbi1leHBlcnQgdXNlcnMgaW50byB1c2luZyBhbiB1bnNhZmUgY29u ZmlndXJhdGlvbiB0aGF0IHRoZXkgdGhpbmsgaXMgc2VjdXJlLiBFbmNyeXB0aW9uIHdpdGhv dXQgYXV0aGVudGljYXRpb24gc2hvdWxkIGJlIGZvcmJpZGRlbi4gW2FzIG5vdGVkIGFib3Zl LCB0aGVyZSBhcmUgZXhhbXBsZXMgd2hlcmUgdGhpcyBmZWF0dXJlIHNldCBmb3IgRVNQIGlz IGF0dHJhY3RpdmUuXQ0NXGVuZHtlbnVtZXJhdGV9DQ1cc3Vic2VjdGlvbntPcnRob2dvbmFs aXR5fQ1JUHNlYyBhbHNvIHN1ZmZlcnMgZnJvbSBhIGxhY2sgb2Ygb3J0aG9nb25hbGl0eS4g VGhlIEFIIGFuZCBFU1AgcHJvdG9jb2xzIGNhbiBiZSB1c2VkIHRvZ2V0aGVyLCBidXQgc2hv dWxkIG9ubHkgYmUgdXNlZCBpbiBvbmUgcGFydGljdWxhciBvcmRlci4gSW4gdHJhbnNwb3J0 IG1vZGUsIEVTUCBieSBpdHNlbGYgcHJvdmlkZXMgb25seSBwYXJ0aWFsIGF1dGhlbnRpY2F0 aW9uIG9mIHRoZSBJUCBwYWNrZXQsIGFuZCB1c2luZyBBSCB0b28gaXMgYWR2aXNhYmxlLiBb bm90IGluIG1vc3QgY2FzZXMsIGFzIG5vdGVkIGFib3ZlLl0gSW4gdHVubmVsIG1vZGUgdGhl IEVTUCBwcm90b2NvbCBhdXRoZW50aWNhdGVzIHRoZSBpbm5lciBoZWFkZXJzLCBzbyB1c2Ug b2YgQUggaXMgbm8gbG9uZ2VyIHJlcXVpcmVkLiBUaGVzZSBpbnRlcmRlcGVuZGVuY2llcyBi ZXR3ZWVuIHRoZSBjaG9pY2VzIGRlbW9uc3RyYXRlIHRoYXQgdGhlc2Ugb3B0aW9ucyBhcmUg bm90IGluZGVwZW5kZW50IG9mIGVhY2ggb3RoZXIuIFt0cnVlLCBidXQgd2hvIHNheXMgdGhh dCB0aGlzIGlzIGEgY3JpdGljYWwgY3JpdGVyaWE/IFRDUCBhbmQgSVAgYXJlIG5vdCBvcnRo b2dvbmFsIGVpdGhlciwgZS5nLiwgbm90ZSB0aGUgVENQIGNoZWNrc3VtIGNvdmVyaW5nIHBh cnRzIG9mIHRoZSBJUCBoZWFkZXIuXQ0NXHN1YnNlY3Rpb257Q29tcGF0aWJpbGl0eX0NVGhl IElQc2VjIHByb3RvY29scyBhcmUgYWxzbyBoYW1wZXJlZCBieSB0aGUgY29tcGF0aWJpbGl0 eSByZXF1aXJlbWVudHMuIEEgc2ltcGxlIHByb2JsZW0gaXMgdGhlIFRPUyBmaWVsZCBpbiB0 aGUgSVAgaGVhZGVyIFxjaXRlW3AuXCAxMF17UkZDMjQwMn0uIEFsdGhvdWdoIHRoaXMgaXMg c3VwcG9zZWQgdG8gYmUgdW5jaGFuZ2VkIGR1cmluZyB0aGUgdHJhbnNtaXNzaW9uIG9mIGEg cGFja2V0IChhY2NvcmRpbmcgdG8gdGhlIElQIHNwZWNpZmljYXRpb25zKSwgc29tZSByb3V0 ZXJzIGFyZSBrbm93biB0byBjaGFuZ2UgdGhpcyBmaWVsZC4gSVBzZWMgY2hvc2UgdG8gZXhj bHVkZSB0aGUgVE9TIGZpZWxkIGZyb20gdGhlIGF1dGhlbnRpY2F0aW9uIHByb3ZpZGVkIGJ5 IHRoZSBBSCBwcm90b2NvbCB0byBhdm9pZCBlcnJvcnMgaW50cm9kdWNlZCBieSBzdWNoIHJv Z3VlIHJvdXRlcnMuIFRoZSByZXN1bHQgaXMgdGhhdCwgaW4gdHJhbnNwb3J0L0FIIHBhY2tl dHMgdGhhdCBoYXZlIGFuIGF1dGhlbnRpY2F0ZWQgaGVhZGVyLCB0aGUgVE9TIGZpZWxkIGlz IG5vdCBhdXRoZW50aWNhdGVkLiBUaGlzIGlzIGNsZWFybHkgdW5leHBlY3RlZCBmcm9tIHRo ZSBhcHBsaWNhdGlvbiBwb2ludCBvZiB2aWV3LCB3aGljaCBtaWdodCB3YW50IHRvIHJlbHkg b24gdGhlIGNvcnJlY3QgdmFsdWUgb2YgdGhlIFRPUyBmaWVsZC4gVGhpcyBwcm9ibGVtIGRv ZXMgbm90IG9jY3VyIGluIHR1bm5lbCBtb2RlLiBbaXQgaXMgdW5mb3J0dW5hdGUgdGhhdCBj aXNjbyBjaG9zZSB0byBub3QgZm9sbG93IHRoZSBzcGVjcyBoZXJlLCBhbmQgaW4gc2V2ZXJh bCBvdGhlciBwbGFjZXMuIEkgYWdyZWUgdGhhdCBhbiB1bmVubGlnaHRlbmVkIHN5c3RlbSBh ZG1pbmlzdHJhdG9yIG1pZ2h0IGJlIHN1cnByaXNlZCBpbiB0aGlzIGNhc2UuIEJ1dCwgaW4g cHJhY3RpY2UsIHRoZSBlZmZlY3QgaXMgbWluaW1hbC4gIFlvdXIgZXhhbXBsZSBjaXRlcyB0 cmFuc3BvcnQgbW9kZSwgd2hpY2ggbWVhbnMgdGhhdCB0aGUgVE9TIGJpdHMgYXJlIGJlaW5n IGFjdGVkIHVwb24gYnkgdGhlIGVuZCBzeXN0ZW0uIElmIGVuZCBzeXN0ZW1zIHJlYWxseSBw YWlkIGF0dGVudGlvbiB0byB0aGVzZSBiaXRzIGluIHRoZSBmaXJzdCBwbGFjZSwgY2lzY28g d291bGQgbm90IGhhdmUgYmVlbiBhYmxlIHRvIGNvcnJ1cHQgdGhlbSB3aXRoIGltcHVuaXR5 ISBUaGUgcmVhc29uIHRoYXQgdGhlc2UgYml0cyBhcmUgYmVpbmcgcmUtdXNlZCBieSB0aGUg RUNOIGZvbGtzIGlzIGJlY2F1c2UgaG9zdHMgaGF2ZSBuZXZlciBtYWRlIHVzZSBvZiB0aGVt LiAgU3RpbGwsIGdvaW5nIGZvcndhcmQsIG9uZSBzaG91bGQgcGF5IGF0dGVudGlvbiB0byB0 aGlzIHZ1bG5lcmFiaWxpdHkuXQ0NQSBtb3JlIGNvbXBsZXggY29tcGF0aWJpbGl0eSBwcm9i bGVtIGlzIHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIGZyYWdtZW50YXRpb24gYW5kIElQc2Vj IFxjaXRlW2FwcGVuZGl4IEJde1JGQzI0MDF9LiBUaGlzIGlzIGEgY29tcGxleCBhcmVhLCBi dXQgYSB0eXBpY2FsIElQc2VjIGltcGxlbWVudGF0aW9uIGhhcyB0byBwZXJmb3JtIHNwZWNp YWxpemVkIHByb2Nlc3NpbmcgdG8gZmFjaWxpdGF0ZSB0aGUgcHJvcGVyIGJlaGF2aW9yIG9m IGhpZ2hlci1sZXZlbCBwcm90b2NvbHMgaW4gcmVsYXRpb24gdG8gZnJhZ21lbnRhdGlvbi4g U3RyaWN0bHkgc3BlYWtpbmcsIGZyYWdtZW50YXRpb24gaXMgcGFydCBvZiB0aGUgY29tbXVu aWNhdGlvbiBsYXllciBiZWxvdyB0aGUgSVBzZWMgbGF5ZXIsIGFuZCBpbiBhbiBpZGVhbCB3 b3JsZCBpdCB3b3VsZCBiZSB0cmFuc3BhcmVudCB0byBJUHNlYy4gQ29tcGF0aWJpbGl0eSBy ZXF1aXJlbWVudHMgd2l0aCBleGlzdGluZyBwcm90b2NvbHMgKHN1Y2ggYXMgVENQKSBmb3Jj ZSBJUHNlYyB0byBleHBsaWNpdGx5IGhhbmRsZSBmcmFnbWVudGF0aW9uIGlzc3Vlcywgd2hp Y2ggYWRkcyBzaWduaWZpY2FudGx5IHRvIHRoZSBvdmVyYWxsIGNvbXBsZXhpdHkuIFVuZm9y dHVuYXRlbHksIHRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUgYW4gZWxlZ2FudCBzb2x1dGlv biB0byB0aGlzIHByb2JsZW0uIFtUaGUgcmVxdWlyZW1lbnQgaGVyZSBpcyB0aGUgc2FtZSB0 aGF0IGFyaXNlcyB3aGVuZXZlciBhbiBpbnRlcm1lZGlhdGUgc3lzdGVtIGFkZHMgaW5mbyB0 byBhIHBhY2tldCwgb3Igd2hlbiBhIHNtYWxsZXIgTVRVIGludGVybWVkaWF0ZSBzeXN0ZW0g aXMgdHJhdmVyc2VkLiBJUHNlYyBpbiBhbiBTRyBpcyBkb2luZyB3aGF0IGEgcm91dGVyIGFs b25nIGEgcGF0aCB3b3VsZCBkbyBpZiB0aGUgk290aGVyIHNpZGWUIG5ldHdvcmsgd2VyZSBz bWFsbGVyLiBJUHNlYyBpbiBhIGhvc3QgaXMgZG9pbmcgd2hhdCB0aGUgTklDIHdvdWxkIGRv IGlmIHRoZSBMQU4gTVRVIGNoYW5nZWQuIFRoZSByZWFsIGNvbXBsZXhpdHkgYXJpc2VzIHdo ZW4gd2Ugd2lzaCB0byBkbyB0aGlzIG9wdGltYWxseSwgYXQgYSBzZWN1cml0eSBnYXRld2F5 IG9yIGEgQklUUyBvciBCSVRXIGltcGxlbWVudGF0aW9uLCBpbiBjYXNlcyB3aGVyZSBkaWZm ZXJlbnQgU0FzIHVzZSBkaWZmZXJlbnQgY29tYmluYXRpb25zIG9mIEFIIGFuZCBFU1AsIG9y IGRpZmZlcmVudCBhbGdvcml0aG1zLCBldGMuXQ0NXHN1YnNlY3Rpb257Q29uY2x1c2lvbn0N VGhlIG92ZXJhbGwgcmVzdWx0IGlzIHRoYXQgSVBzZWMgYnVsayBkYXRhIGhhbmRpbmcgaXMg b3Zlcmx5IGNvbXBsZXguIEluIG91ciBvcGluaW9uIGl0IGlzIHBvc3NpYmxlIHRvIGRlZmlu ZSBhbiBlcXVpdmFsZW50IHN5c3RlbSB0aGF0IGlzIGZhciBsZXNzIGNvbXBsZXguIA0NDVxz ZWN0aW9ue09yZGVyIG9mIG9wZXJhdGlvbnN9DQ1cc3Vic2VjdGlvbntJbnRyb2R1Y3Rpb259 DVdoZW4gYm90aCBlbmNyeXB0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBhcmUgcHJvdmlkZWQs IElQc2VjIHBlcmZvcm1zIHRoZSBlbmNyeXB0aW9uIGZpcnN0LCBhbmQgYXV0aGVudGljYXRl cyB0aGUgY2lwaGVydGV4dC4gSW4gb3VyIG9waW5pb24sIHRoaXMgaXMgdGhlIHdyb25nIG9y ZGVyLiBHb2luZyBieSB0aGUgYGBIb3J0b24gcHJpbmNpcGxlJycgXGNpdGV7V1M6U1NMMzB9 LCB0aGUgcHJvdG9jb2wgc2hvdWxkIGF1dGhlbnRpY2F0ZSB3aGF0IHdhcyBtZWFudCwgbm90 IHdoYXQgd2FzIHNhaWQuIFRoZSBgYG1lYW5pbmcnJyBvZiB0aGUgY2lwaGVydGV4dCBzdGls bCBkZXBlbmRzIG9uIHRoZSBkZWNyeXB0aW9uIGtleSB1c2VkLiBBdXRoZW50aWNhdGlvbiBz aG91bGQgdGh1cyBiZSBhcHBsaWVkIHRvIHRoZSBwbGFpbnRleHQgKGFzIGl0IGlzIGluIFNT TCBcY2l0ZXtTU0x2M05vdjk2fSksIGFuZCBub3QgdG8gdGhlIGNpcGhlcnRleHQuW1RoZSBv cmRlciBvZiBwcm9jZXNzaW5nIGlzIGludGVudGlvbmFsLiBJdCBpcyBleHBsaWNpdGx5IGRl c2lnbmVkIHRvIGFsbG93IGEgcmVjZWl2ZXIgdG8gZGlzY2FyZCBhIHBhY2tldCBhcyBxdWlj a2x5IGFzIHBvc3NpYmxlLCBpbiB0aGUgZXZlbnQgb2YgRG9TIGF0dGFja3MsIGFzIHlvdSBh Y2tub3dsZWRnZSBiZWxvdy4gVGhlIHN1Z2dlc3Rpb24gdGhhdCB0aGlzIGNvbmNlcm4gYmUg YWRkcmVzc2VkIGJ5IHRoZSBhZGRpdGlvbiBvZiBhIHNlY29uZGFyeSBNQUMgc2VlbXMgdG8g dmlvbGF0ZSB0aGUgc3Bpcml0IG9mIHNpbXBsaWNpdHkgdGhhdCB0aGlzIGRvY3VtZW50IGVz cG91c2VzIHNvIHN0cm9uZ2x5LCBhbmQgdGhlIHNwZWNpZmljIHByb3Bvc2VkIGZpeCBpcyBu b3Qgc3Ryb25nIGVub3VnaCB0byB3YXJyYW50IGl0cyBpbmNvcnBvcmF0aW9uLiBNb3Jlb3Zl ciwgdGhpcyBvcmRlcmluZyBhbGxvd3MgcGFyYWxsZWwgcHJvY2Vzc2luZyBhdCBhIHJlY2Vp dmVyLCBhcyBhIG1lYW5zIG9mIGluY3JlYXNpbmcgdGhyb3VnaHB1dCBhbmQgcmVkdWNpbmcg ZGVsYXkuXSANDVRoaXMgZG9lcyBub3QgYWx3YXlzIGxlYWQgdG8gYSBkaXJlY3Qgc2VjdXJp dHkgcHJvYmxlbS4gSW4gdGhlIGNhc2Ugb2YgdGhlIEVTUCBwcm90b2NvbCwgdGhlIGVuY3J5 cHRpb24ga2V5IGFuZCBhdXRoZW50aWNhdGlvbiBrZXkgYXJlIHBhcnQgb2YgYSBzaW5nbGUg RVNQIGtleSBpbiB0aGUgU0EuIEEgc3VjY2Vzc2Z1bCBhdXRoZW50aWNhdGlvbiBzaG93cyB0 aGF0IHRoZSBwYWNrZXQgd2FzIHNlbnQgYnkgc29tZW9uZSB3aG8ga25ldyB0aGUgYXV0aGVu dGljYXRpb24ga2V5LiBUaGUgcmVjaXBpZW50IHRydXN0cyB0aGUgc2VuZGVyIHRvIGVuY3J5 cHQgdGhhdCBwYWNrZXQgd2l0aCB0aGUgb3RoZXIgaGFsZiBvZiB0aGUgRVNQIGtleSwgc28g dGhhdCB0aGUgZGVjcnlwdGVkIGRhdGEgaXMgaW4gZmFjdCB0aGUgc2FtZSBhcyB0aGUgb3Jp Z2luYWwgZGF0YSB0aGF0IHdhcyBzZW50LiBUaGUgZXhhY3QgYXJndW1lbnQgd2h5IHRoaXMg aXMgc2VjdXJlIGdldHMgdG8gYmUgdmVyeSBjb21wbGljYXRlZCwgYW5kIHJlcXVpcmVzIHNw ZWNpYWwgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGtleSBhZ3JlZW1lbnQgcHJvdG9jb2wuIEZv ciBleGFtcGxlLCBzdXBwb3NlIGFuIGF0dGFja2VyIGNhbiBtYW5pcHVsYXRlIHRoZSBrZXkg YWdyZWVtZW50IHByb3RvY29sIHVzZWQgdG8gc2V0IHVwIHRoZSBTQSBpbiBzdWNoIGEgd2F5 IHRoYXQgdGhlIHR3byBwYXJ0aWVzIGdldCBhbiBhZ3JlZW1lbnQgb24gdGhlIGF1dGhlbnRp Y2F0aW9uIGtleSBidXQgYSBkaXNhZ3JlZW1lbnQgb24gdGhlIGVuY3J5cHRpb24ga2V5LiBX aGVuIHRoaXMgaXMgZG9uZSwgdGhlIGRhdGEgdHJhbnNtaXR0ZWQgd2lsbCBiZSBhdXRoZW50 aWNhdGVkIHN1Y2Nlc3NmdWxseSwgYnV0IGRlY3J5cHRpb24gdGFrZXMgcGxhY2Ugd2l0aCBh IGRpZmZlcmVudCBrZXkgdGhhbiBlbmNyeXB0aW9uLCBhbmQgYWxsIHRoZSBwbGFpbnRleHQg ZGF0YSBpcyBzdGlsbCBnYXJibGVkLiBbVGhlIGZ1bmRhbWVudGFsIGFzc3VtcHRpb24gaXMg dGhhdCBhbiBFU1AgU0EgdGhhdCBlbXBsb3lzIGJvdGggZW5jcnlwdGlvbiBhbmQgYW4gSE1B QyB3aWxsIGhhdmUgdGhlIGtleXMgYm91bmQgdG9nZXRoZXIsIGlycmVzcGVjdGl2ZSBvZiB0 aGUgbWVhbnMgYnkgd2hpY2ggdGhleSBhcmUgZ2VuZXJhdGVkLiBUaGlzIGFzc3VtcHRpb24g cHJvYmFibHkgY291bGQgYmUgYmV0dGVyIHN0YXRlZCBpbiB0aGUgUkZDcy5dDQ1JbiBvdGhl ciBzaXR1YXRpb25zLCB0aGUgd3Jvbmcgb3JkZXIgZG9lcyBsZWFkIHRvIGRpcmVjdCBzZWN1 cml0eSB3ZWFrbmVzc2VzLg0NXHN1YnNlY3Rpb257QW4gYXR0YWNrIG9uIElQc2VjfQ1TdXBw b3NlIHR3byBob3N0cyBoYXZlIGEgbWFudWFsbHkga2V5ZWQgdHJhbnNwb3J0LW1vZGUgQUgt cHJvdG9jb2wgU0EsIHdoaWNoIHdlIHdpbGwgY2FsbCBTQWFoLiBEdWUgdG8gdGhlIG1hbnVh bCBrZXlpbmcsIHRoZSBBSCBwcm90b2NvbCBkb2VzIG5vdCBwcm92aWRlIGFueSByZXBsYXkg cHJvdGVjdGlvbi4gVGhlc2UgdHdvIGhvc3RzIG5vdyBuZWdvdGlhdGUgYSB0cmFuc3BvcnQt bW9kZSBlbmNyeXB0aW9uLW9ubHkgRVNQIFNBICh3aGljaCB3ZSB3aWxsIGNhbGwgU0Flc3Ax KSBhbmQgdXNlIHRoaXMgdG8gc2VuZCBpbmZvcm1hdGlvbiB1c2luZyBib3RoIFNBZXNwMSBh bmQgU0FhaC4gVGhlIGFwcGxpY2F0aW9uIGNhbiBleHBlY3QgdG8gZ2V0IGNvbmZpZGVudGlh bGl0eSBhbmQgYXV0aGVudGljYXRpb24gb24gdGhpcyBjaGFubmVsLCBidXQgbm8gcmVwbGF5 IHByb3RlY3Rpb24uIFdoZW4gdGhlIGltbWVkaWF0ZSBpbnRlcmFjdGlvbiBpcyBmaW5pc2hl ZCwgU0Flc3AxIGlzIGRlbGV0ZWQuIEEgZmV3IGhvdXJzIGxhdGVyLCB0aGUgdHdvIGhvc3Rz IGFnYWluIG5lZ290aWF0ZSBhIHRyYW5zcG9ydC1tb2RlIGVuY3J5cHRpb24tb25seSBFU1Ag U0EgKFNBZXNwMiksIGFuZCB0aGUgcmVjZWl2ZXIgY2hvb3NlcyB0aGUgc2FtZSBTUEkgdmFs dWUgZm9yIFNBZXNwMiBhcyB3YXMgdXNlZCBmb3IgU0Flc3AxLiBBZ2FpbiwgZGF0YSBpcyB0 cmFuc21pdHRlZCB1c2luZyBib3RoIFNBZXNwMiBhbmQgU0FhaC4gVGhlIGF0dGFja2VyIG5v dyBpbnRyb2R1Y2VzIG9uZSBvZiB0aGUgcGFja2V0cyBmcm9tIHRoZSBmaXJzdCBleGNoYW5n ZS4gVGhpcyBwYWNrZXQgd2FzIGVuY3J5cHRlZCB1c2luZyBTQWVzcDEgYW5kIGF1dGhlbnRp Y2F0ZWQgdXNpbmcgU0FhaC4gVGhlIHJlY2VpdmVyIGNoZWNrcyB0aGUgYXV0aGVudGljYXRp b24gYW5kIGZpbmRzIGl0IHZhbGlkLiAoQXMgcmVwbGF5IHByb3RlY3Rpb24gaXMgbm90IGVu YWJsZWQsIHRoZSBzZXF1ZW5jZSBudW1iZXIgZmllbGQgaXMgaWdub3JlZC4pIFRoZSByZWNl aXZlciB0aGVuIHByb2NlZWRzIHRvIGRlY3J5cHQgdGhlIHBhY2tldCB1c2luZyBTQWVzcDIs IHdoaWNoIHByZXN1bWFibHkgaGFzIGEgZGlmZmVyZW50IGRlY3J5cHRpb24ga2V5IHRoZW4g U0Flc3AxLiBUaGUgZW5kIHJlc3VsdCBpcyB0aGF0IHRoZSByZWNlaXZlciBhY2NlcHRzIHRo ZSBwYWNrZXQgYXMgdmFsaWQsIGRlY3J5cHRzIGl0IHdpdGggdGhlIHdyb25nIGtleSwgYW5k IHByZXNlbnRzIHRoZSBnYXJibGVkIGRhdGEgdG8gdGhlIGFwcGxpY2F0aW9uLiBDbGVhcmx5 LCB0aGUgYXV0aGVudGljYXRpb24gcHJvcGVydHkgaGFzIGJlZW4gdmlvbGF0ZWQuIFt0aGlz IGF0dGFjayBpcyBub3QgYSBjcml0aWNpc20gb2YgdGhlIGNob2ljZSBvZiBFU1Agb3BlcmF0 aW9uIG9yZGVyaW5nLCBidXQgcmF0aGVyIHRoZSBub3Rpb24gb2YgYXBwbHlpbmcgQUggYW5k IEVTUCAoZW5jcnlwdGlvbiBvbmx5KSBpbiBhIHBhcnRpY3VsYXIgb3JkZXIsIGFzIGFsbG93 ZWQgYnkgUkZDIDI0MDEuIFRoZSBzcGVjaWZpYyBjb21iaW5hdGlvbiBvZiBrZXlpbmcgb3Bl cmF0aW9ucyBkZXNjcmliZWQgaGVyZSwgdGhvdWdoIG5vdCBwcm9oaWJpdGVkIGJ5IDI0MDEs IGRvZXMgbm90IHNlZW0gbGlrZWx5IHRvIG9jY3VyIGluIHByYWN0aWNlLiBTcGVjaWZpY2Fs bHksIGlmIGFuIElQc2VjIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGF1dG9tYXRlZCBrZXkg bWFuYWdlbWVudCwgYXMgZGVzY3JpYmVkIGFib3ZlIGZvciB0aGUgRVNQIFNBcywgdGhlbiBp dCBpcyBoaWdobHkgdW5saWtlbHkgdGhhdCB0aGUgQUggU0Egd291bGQgYmUgbWFudWFsbHkg a2V5ZWQuIFRoZSBwdXNoIHRvIHJldGFpbiBtYW51YWwga2V5aW5nIGFzIGEgYmFzZSBmYWNp bGl0eSBmb3IgSVBzZWMgaXMgd2FuaW5nLCBhbmQgbW9zdCBpbXBsZW1lbnRhdGlvbnMgaGF2 ZSBJS0UgYXZhaWxhYmxlLiAgVW5kZXIgdGhlc2UgY2lyY3Vtc3RhbmNlcywgdGhpcyB2dWxu ZXJhYmlsaXR5IGlzIHVubGlrZWx5IHRvIGJlIHJlYWxpemVkLl0gDQ1cc3Vic2VjdGlvbntP dGhlciBjb25zaWRlcmF0aW9uc30NRG9pbmcgdGhlIGVuY3J5cHRpb24gZmlyc3QgYW5kIGF1 dGhlbnRpY2F0aW9uIGxhdGVyIGFsbG93cyB0aGUgcmVjaXBpZW50IHRvIGRpc2NhcmQgcGFj a2V0cyB3aXRoIGVycm9uZW91cyBhdXRoZW50aWNhdGlvbiBmYXN0ZXIsIHdpdGhvdXQgdGhl IG92ZXJoZWFkIG9mIHRoZSBkZWNyeXB0aW9uLiBUaGlzIGhlbHBzIHRoZSBjb21wdXRlciBj b3BlIHdpdGggZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrcyBpbiB3aGljaCBhIGxhcmdlIG51 bWJlciBvZiBmYWtlIHBhY2tldHMgZWF0IHVwIGEgbG90IG9mIENQVSB0aW1lLiBXZSBxdWVz dGlvbiB3aGV0aGVyIHRoaXMgd291bGQgYmUgdGhlIHByZWZlcnJlZCBtb2RlIG9mIGF0dGFj ayBhZ2FpbnN0IGEgVENQL0lQLWVuYWJsZWQgY29tcHV0ZXIuIElmIHRoaXMgcHJvcGVydHkg aXMgcmVhbGx5IGltcG9ydGFudCwgYSAxLSBvciAyLWJ5dGUgTUFDIChNZXNzYWdlIEF1dGhl bnRpY2F0aW9uIENvZGUpIG9uIHRoZSBjaXBoZXJ0ZXh0IGNvdWxkIGJlIGFkZGVkLiBUaGUg TUFDIGNvZGUgYWxsb3dzIHRoZSByZWNpcGllbnQgdG8gcmFwaWRseSBkaXNjYXJkIHZpcnR1 YWxseSBhbGwgYm9ndXMgcGFja2V0cyBhdCB0aGUgY29zdCBvZiBhbiBhZGRpdGlvbmFsIE1B QyBjb21wdXRhdGlvbiBwZXIgcGFja2V0LiBbYSBvbmUgb3IgdHdvIGJ5dGUgTUFDIHByb3Zp ZGVzIHNvIGxpdHRsZSBwcm90ZWN0aW9uIHRoYXQgdGhpcyBkb2VzIG5vdCBzZWVtIHRvIGJl IGFuIGF0dHJhY3RpdmUgY291bnRlci1wcm9wb3NhbC4gQWxzbywgYXMgbm90ZWQgYWJvdmUs IGl0IGFkZHMgY29tcGxleGl0eSCFXQ0NXHN1YnNlY3Rpb257Q29uY2x1c2lvbn0NVGhlIG9y ZGVyaW5nIG9mIGVuY3J5cHRpb24gYW5kIGF1dGhlbnRpY2F0aW9uIGluIElQc2VjIGlzIHdy b25nLiBBdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgYXBwbGllZCB0byB0aGUgcGxhaW50ZXh0 IG9mIHRoZSBwYXlsb2FkLCBhbmQgZW5jcnlwdGlvbiBzaG91bGQgYmUgYXBwbGllZCBhZnRl ciB0aGF0Lg0NDVxzZWN0aW9ue1NlY3VyaXR5IEFzc29jaWF0aW9uc30NQSBTZWN1cml0eSBB c3NvY2lhdGlvbiAoU0EpIGlzIGEgc2ltcGxleCBgYGNvbm5lY3Rpb24nIHRoYXQgYWZmb3Jk cyBzZWN1cml0eSBzZXJ2aWNlcyB0byB0aGUgdHJhZmZpYyBjYXJyaWVkIGJ5IGl0IFxjaXRl W3NlY3Rpb24gNF17UkZDMjQwMX0uIFRoZSB0d28gY29tcHV0ZXJzIG9uIGVpdGhlciBzaWRl IG9mIHRoZSBTQSBzdG9yZSB0aGUgbW9kZSwgcHJvdG9jb2wsIGFsZ29yaXRobXMsIGFuZCBr ZXlzIHVzZWQgaW4gdGhlIFNBLiBFYWNoIFNBIGlzIHVzZWQgb25seSBpbiBvbmUgZGlyZWN0 aW9uOyBmb3IgYmlkaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9ucyB0d28gU0FzIGFyZSByZXF1 aXJlZC4gRWFjaCBTQSBpbXBsZW1lbnRzIGEgc2luZ2xlIG1vZGUgYW5kIHByb3RvY29sOyBp ZiB0d28gcHJvdG9jb2xzIChzdWNoIGFzIEFIIGFuZCBFU1ApIGFyZSB0byBiZSBhcHBsaWVk IHRvIGEgc2luZ2xlIHBhY2tldCwgdHdvIFNBcyBhcmUgcmVxdWlyZWQuDQ1Nb3N0IG9mIG91 ciBhZm9yZW1lbnRpb25lZCBjb21tZW50cyBhbHNvIGFmZmVjdCB0aGUgU0Egc3lzdGVtOyB0 aGUgdXNlIG9mIHR3byBtb2RlcyBhbmQgdHdvIHByb3RvY29scyBtYWtlIHRoZSBTQSBzeXN0 ZW0gbW9yZSBjb21wbGV4IHRoYW4gbmVjZXNzYXJ5Lg0NVGhlcmUgYXJlIHZlcnkgZmV3IChp ZiBhbnkpIHNpdHVhdGlvbnMgaW4gd2hpY2ggYSBjb21wdXRlciBzZW5kcyBhbiBJUCBwYWNr ZXQgdG8gYSBob3N0LCBidXQgbm8gcmVwbHkgaXMgZXZlciBzZW50LiBbd2UgaGF2ZSBhIGdy b3dpbmcgbnVtYmVyIG9mIGFwcHMgd2hlcmUgdGhpcyBmdW5jdGlvbmFsaXR5IG1heSBiZSBh cHByb3ByaWF0ZS4gRm9yIGV4YW1wbGUsIGJyb2FkY2FzdCBwYWNrZXQgdmlkZW8gZmVlZHMg YW5kIHNlY3VyZSB0aW1lIGZlZWRzIGFyZSB1bmlkaXJlY3Rpb25hbC5dIFRoZXJlIGFyZSBh bHNvIHZlcnkgZmV3IHNpdHVhdGlvbnMgaW4gd2hpY2ggdGhlIHRyYWZmaWMgaW4gb25lIGRp cmVjdGlvbiBuZWVkcyB0byBiZSBzZWN1cmVkLCBidXQgdGhlIHRyYWZmaWMgaW4gdGhlIG90 aGVyIGRpcmVjdGlvbiBkb2VzIG5vdCBuZWVkIHRvIGJlIHNlY3VyZWQuIEl0IHRoZXJlZm9y ZSBzZWVtcyB0aGF0IGluIHZpcnR1YWxseSBhbGwgcHJhY3RpY2FsIHNpdHVhdGlvbnMsIFNB cyBvY2N1ciBpbiBwYWlycyB0byBhbGxvdyBiaWRpcmVjdGlvbmFsIHNlY3VyZWQgY29tbXVu aWNhdGlvbnMuIEluIGZhY3QsIHRoZSBJS0UgcHJvdG9jb2wgbmVnb3RpYXRlcyBTQXMgaW4g cGFpcnMuIFtJS0UgaGFzIG5vdCBhbHdheXMgYmVlbiB3ZWxsIGNvb3JkaW5hdGVkIHdpdGgg SVBzZWMsIHVuZm9ydHVuYXRlbHkuIFRoaXMgaXMgd2h5IHdlIGhhdmUgdG8gaGF2ZSBudWxs IGVuY3J5cHRpb24gYW5kIG51bGwgYXV0aGVudGljYXRpb24gYWxnb3JpdGhtcy4gU28sIEkg ZG9uknQgdGhpbmsgb25lIHNob3VsZCBjaXRlIElLRSBiZWhhdmlvciBhcyBhIGJhc2lzIGZv ciBtYWtpbmcgU0FzIGJpLWRpcmVjdGlvbmFsLiBJIGFncmVlIHRoYXQgdGhlIHZhc3QgbWFq b3JpdHkgb2YgZXhhbXBsZXMgdGhhdCB3ZSBzZWUgbm93IGFyZSBmdWxsIGR1cGxleCwgYnV0 IHdlIGhhdmUgZXhhbXBsZSB3aGVyZSB0aGlzIG1heSBub3QgYXBwbHksIGFzIG5vdGVkIGFi b3ZlLl0NDVRoaXMgd291bGQgc3VnZ2VzdCB0aGF0IGl0IGlzIG1vcmUgbG9naWNhbCB0byBt YWtlIGFuIFNBIGEgYmlkaXJlY3Rpb25hbCBgYGNvbm5lY3Rpb24nJyBiZXR3ZWVuIHR3byBt YWNoaW5lcy4gVGhpcyB3b3VsZCBoYWx2ZSB0aGUgbnVtYmVyIG9mIFNBcyBpbiB0aGUgb3Zl cmFsbCBzeXN0ZW0uIEl0IHdvdWxkIGFsc28gYXZvaWQgYXN5bW1ldHJpYyBzZWN1cml0eSBj b25maWd1cmF0aW9ucywgd2hpY2ggd2UgdGhpbmsgYXJlIHVuZGVzaXJhYmxlIChzZWUgc2Vj dGlvbn5ccmVme3NlYzpTUER9KS4gW1RoZSBTUEkgdGhhdCBpcyB1c2VkIGFzIGEgcHJpbWFy eSBkZS1tdWx0aXBsZXhpbmcgdmFsdWUsIG11c3QgYmUgY2hvc2VuIGxvY2FsbHksIGJ5IHRo ZSByZWNlaXZlciwgc28gaGF2aW5nIGJpLWRpcmVjdGlvbmFsIFNBcyBwcm9iYWJseSB3b26S dCBjaGFuZ2UgdGhlIHNpemUgb2YgdGhlIFNBRCBzdWJzdGFudGlhbGx5LiBTcGVjaWZpY2Fs bHksIGhvdyBkbyB5b3UgZW52aXNpb24gdGhhdCBhIHN3aXRjaCB0byBiaS1kaXJlY3Rpb25h bGl0eSB3b3VsZCBzaW1wbGlmeSBpbXBsZW1lbnRhdGlvbnM/XQ0NXHNlY3Rpb257U2VjdXJp dHkgcG9saWNpZXN9XGxhYmVse3NlYzpTUER9DVRoZSBzZWN1cml0eSBwb2xpY2llcyBhcmUg c3RvcmVkIGluIHRoZSBTUEQgKFNlY3VyaXR5IFBvbGljeSBEYXRhYmFzZSkuIEZvciBldmVy eSBwYWNrZXQgdGhhdCBpcyB0byBiZSBzZW50IG91dCwgdGhlIFNQRCBpcyBjaGVja2VkIHRv IGZpbmQgaG93IHRoZSBwYWNrZXQgaXMgdG8gYmUgcHJvY2Vzc2VkLiBUaGUgU1BEIGNhbiBz cGVjaWZ5IHRocmVlIGFjdGlvbnM6IGRpc2NhcmQgdGhlIHBhY2tldCwgbGV0IHRoZSBwYWNr ZXQgYnlwYXNzIElQc2VjIHByb2Nlc3NpbmcsIG9yIGFwcGx5IElQc2VjIHByb2Nlc3Npbmcu IEluIHRoZSBsYXN0IGNhc2UsIHRoZSBTUEQgYWxzbyBzcGVjaWZpZXMgd2hpY2ggU0FzIHNo b3VsZCBiZSB1c2VkIChpZiBzdWl0YWJsZSBTQXMgaGF2ZSBhbHJlYWR5IGJlZW4gc2V0IHVw KSBvciBzcGVjaWZpZXMgd2l0aCB3aGF0IHBhcmFtZXRlcnMgbmV3IFNBcyBzaG91bGQgYmUg c2V0IHVwIHRvIGJlIHVzZWQuDQ1UaGUgU1BEIHNlZW1zIHRvIGJlIGEgdmVyeSBmbGV4aWJs ZSBjb250cm9sIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBhIHZlcnkgZmluZS1ncmFpbmVkIGNv bnRyb2wgb3ZlciB0aGUgc2VjdXJpdHkgcHJvY2Vzc2luZyBvZiBlYWNoIHBhY2tldC4gUGFj a2V0cyBhcmUgY2xhc3NpZmllZCBhY2NvcmRpbmcgdG8gYSBsYXJnZSBudW1iZXIgb2Ygc2Vs ZWN0b3JzLCBhbmQgdGhlIFNQRCBjYW4gbWF0Y2ggc29tZSBvciBhbGwgc2VsZWN0b3JzIHRv IGRldGVybWluZSB0aGUgYXBwcm9wcmlhdGUgYWN0aW9uLiBEZXBlbmRpbmcgb24gdGhlIFNQ RCwgdGhpcyBjYW4gcmVzdWx0IGluIGVpdGhlciBhbGwgdHJhZmZpYyBiZXR3ZWVuIHR3byBj b21wdXRlcnMgYmVpbmcgY2FycmllZCBvbiBhIHNpbmdsZSBTQSwgb3IgYSBzZXBhcmF0ZSBT QSBiZWluZyB1c2VkIGZvciBlYWNoIGFwcGxpY2F0aW9uLCBvciBldmVuIGVhY2ggVENQIGNv bm5lY3Rpb24uIFN1Y2ggYSB2ZXJ5IGZpbmUgZ3JhbnVsYXJpdHkgaGFzIGRpc2FkdmFudGFn ZXMuIFRoZXJlIGlzIGEgc2lnbmlmaWNhbnRseSBpbmNyZWFzZWQgb3ZlcmhlYWQgaW4gc2V0 dGluZyB1cCB0aGUgcmVxdWlyZWQgU0FzLCBhbmQgbW9yZSB0cmFmZmljIGFuYWx5c2lzIGlu Zm9ybWF0aW9uIGlzIG1hZGUgYXZhaWxhYmxlIHRvIHRoZSBhdHRhY2tlci4gQXQgdGhlIHNh bWUgdGltZSB3ZSBkbyBub3Qgc2VlIGFueSBuZWVkIGZvciBzdWNoIGEgZmluZS1ncmFpbmVk IGNvbnRyb2wuIFthIGxvdCBvZiBjdXN0b21lcnMgZm9yIElQc2VjIHByb2R1Y3RzIGRpc2Fn cmVlIV0gVGhlIFNQRCBzaG91bGQgc3BlY2lmeSB3aGV0aGVyIGEgcGFja2V0IHNob3VsZCBi ZSBkaXNjYXJkZWQsIHNob3VsZCBieXBhc3MgYW55IElQc2VjIHByb2Nlc3NpbmcsIHJlcXVp cmVzIGF1dGhlbnRpY2F0aW9uLCBvciByZXF1aXJlcyBhdXRoZW50aWNhdGlvbiBhbmQgZW5j cnlwdGlvbi4gV2hldGhlciBzZXZlcmFsIHBhY2tldHMgYXJlIGNvbWJpbmVkIG9uIHRoZSBz YW1lIFNBIGlzIG5vdCBpbXBvcnRhbnQuIFt5ZXMgaXQgaXMuIEJ5IGFsbG93aW5nIGFuIGFk bWluaXN0cmF0b3IgdGhlIGFiaWxpdHkgdG8gc2VsZWN0IHRoZSBncmFudWxhcml0eSBvZiBw cm90ZWN0aW9uLCBvbmUgY2FuIGNvbnRyb2wgdGhlIGxldmVsIG9mIHBhcnRpYWwgdHJhZmZp YyBmbG93IGNvbmZpZGVudGlhbGl0eSBvZmZlcmVkIGJldHdlZW4gc2VjdXJpdHkgZ2F0ZXdh eXMuIEFsc28sIGZpbmUtZ3JhaW5lZCBhY2Nlc3MgY29udHJvbCBhbGxvd3MgYW4gYWRtaW4g dG8gYWxsb3cgc29tZSBmb3JtcyBvZiBjb25uZWN0aW9ucyB0aHJvdWdoIHRoZSBnYXRld2F5 LCB3aGlsZSByZWplY3Rpbmcgb3RoZXJzLiBBY2Nlc3MgY29udHJvbCBpcyBvZnRlbiB0aGUg cHJpbWFyeSwgdW5kZXJseWluZyBtb3RpdmF0aW9uIGZvciB1c2luZyBJUHNlYy4gQSBudW1i ZXIgb2YgYXR0YWNrcyBiZWNvbWUgcG9zc2libGUgaWYgb25lIGNhbm5vdCB0aWdodGx5IGJp bmQgdGhlIGF1dGhlbnRpY2F0aW9uIHByb3ZpZGVkIGJ5IElQc2VjIHRvIHRoZSBhY2Nlc3Mg Y29udHJvbCBkZWNpc2lvbi4gQWxzbywgZ2l2ZW4gdGhlIGNvbXB1dGF0aW9uYWwgY29zdHMg b2YgU0EgZXN0YWJsaXNobWVudCB2aWEgSUtFLCBpdCBpcyBpbXBvcnRhbnQgdG8gYWxsb3cg YW4gYWRtaW5pc3RyYXRvciB0byBzZWxlY3QgdGhlIGdyYW51bGFyaXR5IG9mIFNBcy5dIFRo ZSBzYW1lIGhvbGRzIGZvciB0aGUgZXhhY3QgY2hvaWNlIG9mIGNyeXB0b2dyYXBoaWMgYWxn b3JpdGhtOiBhbnkgZ29vZCBhbGdvcml0aG0gd2lsbCBkby4gVGhlcmUgYXJlIHR3byByZWFz b25zIGZvciB0aGlzLiBGaXJzdCBvZiBhbGwsIG5vYm9keSBldmVyIGF0dGFja3MgYSBzeXN0 ZW0gYnkgY3J5cHRhbmFseXNpcy4gSW5zdGVhZCwgYXR0YWNrcyBhcmUgbWFkZSBvbiB0aGUg dXNlcnMsIGltcGxlbWVudGF0aW9uLCBtYW5hZ2VtZW50LCBldGMuIEFueSByZWFzb25hYmxl IGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBwcm90ZWN0 aW9uLiBUaGUgc2Vjb25kIHJlYXNvbiBpcyB0aGF0IHRoZXJlIGFyZSB2ZXJ5IGVmZmljaWVu dCBhbmQgc2VjdXJlIGFsZ29yaXRobXMgYXZhaWxhYmxlLiBUd28gbWFjaGluZXMgc2hvdWxk IG5lZ290aWF0ZSB0aGUgc3Ryb25nZXN0IGFsZ29yaXRobSB0aGF0IHRoZXkgYXJlIGFsbG93 ZWQuIFRoZXJlIGlzIG5vIHJlYXNvbiB0byBzZWxlY3QgaW5kaXZpZHVhbCBhbGdvcml0aG1z IG9uIGFuIGFwcGxpY2F0aW9uLWJ5LWFwcGxpY2F0aW9uIGJhc2lzLiBbaWYgb25lIHdlcmUg dG8gZW1wbG95IEVTUCB3aXRob3V0IGF1dGhlbnRpY2F0aW9uLCBiZWNhdXNlIGEgc3BlY2lm aWMgaGlnaGVyIGxheWVyIHByb3RvY29sIHByb3ZpZGVkIGl0cyBvd24gYXV0aGVudGljYXRp b24sIGFuZCBtYXliZSBiZWNhdXNlIHRoZSBhcHBsaWNhdGlvbiBlbXBsb3llZCBGRUMsIHRo ZW4gb25lIG1pZ2h0IHdlbGwgaW1hZ2luZSB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBh bGdvcml0aG1zLCBvciBkaWZmZXJlbnQgbW9kZXMgKGUuZy4sIGJsb2NrIHZzLiBzdHJlYW0p IGZvciBkaWZmZXJlbnQgU0FzLiB3aGlsZSBJIGFncmVlIHRoYXQgdGhlIGZvY3VzIG9uIGFs Z29yaXRobSBhZ2lsaXR5IG1heSBiZSBvdmVyc3RhdGVkLCBpdCBkb2VzIGFsbG93IGNvbW11 bmljYXRpbmcgcGFydGllcyB0byBzZWxlY3QgYSBoaWdoZXIgcXVhbGl0eSBhbGdvcml0aG0s IHJlbGF0aXZlIHRvIHRoZSBtYW5kYXRlZCBkZWZhdWx0LCBpZiB0aGV5IGJvdGggc3VwcG9y dCB0aGF0IGFsZ29yaXRobS5dIA0NSW4gb3VyIG9waW5pb24sIG1hbmFnZW1lbnQgb2YgdGhl IElQc2VjIHByb3RvY29scyBjYW4gYmUgc2ltcGxpZmllZCBieSBsZXR0aW5nIHRoZSBTUEQg Y29udGFpbiBwb2xpY2llcyBmb3JtdWxhdGVkIGF0IHN1Y2ggYSBoaWdoZXIgbGV2ZWwuIEFz IHdlIGFyZ3VlZCBpbiBzZWN0aW9uflxyZWZ7c2VjOmNvbXBsZXhpdHl9LCBzaW1wbGlmaWNh dGlvbiB3aWxsIHN0cmVuZ3RoZW4gdGhlIGFjdHVhbCBzeXN0ZW0uIFtleGFtcGxlcyBwcm92 aWRlZCBhYm92ZSBpbGx1c3RyYXRlIHdoeSBmaW5lLWdyYWluZWQgYWNjZXNzIGNvbnRyb2wg aXMgaW1wb3J0YW50Ll0NDUl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIHNhbWUgaGlnaC1sZXZl bCBhcHByb2FjaCBjb3VsZCBiZSBkb25lIGluIHJlbGF0aW9uIHRvIHRoZSBjaG9pY2Ugb2Yg U0EgZW5kLXBvaW50cy4gQXMgdGhlcmUgY3VycmVudGx5IGRvZXMgbm90IHNlZW0gdG8gYmUg YSByZWxpYWJsZSBhdXRvbWF0aWMgbWV0aG9kIG9mIGRldGVjdGluZyBJUHNlYy1lbmFibGVk IHNlY3VyaXR5IGdhdGV3YXlzLCB3ZSBkbyBub3Qgc2VlIGEgcHJhY3RpY2FsIGFsdGVybmF0 aXZlIHRvIG1hbnVhbCBjb25maWd1cmF0aW9uIG9mIHRoZXNlIHBhcmFtZXRlcnMuIEl0IGlz IHF1ZXN0aW9uYWJsZSB3aGV0aGVyIGF1dG9tYXRpYyBkZXRlY3Rpb24gb2YgSVBzZWMtZW5h YmxlZCBnYXRld2F5cyBpcyBwb3NzaWJsZSBhdCBhbGwuIFdpdGhvdXQgc29tZSBpbml0aWFs IGtub3dsZWRnZSBvZiB0aGUgb3RoZXIgc2lkZSwgYW55IGRldGVjdGlvbiBhbmQgbmVnb3Rp YXRpb24gYWxnb3JpdGhtIGNhbiBiZSBzdWJ2ZXJ0ZWQgYnkgYW4gYWN0aXZlIGF0dGFja2Vy LiBbdGhlIGF1dGhvcnMgaWRlbnRpZnkgYSBnb29kIHByb2JsZW0sIGJ1dCBpdCBpcyBoYXJk bHkgYW4gdW5zb2x2YWJsZSBvbmUuIEEgcHJvcG9zYWwgd2FzIHB1dCBmb3J0aCAoYnkgQm9i IE1vc2Nvd3Rpeiwgb3ZlciBhIHllYXIgYWdvKSB0byBpbmNsdWRlIHJlY29yZHMgaW4gdGhl IEROUyBhbmFsb2dvdXMgdG8gTVggcmVjb3Jkcy4gV2hlbiBvbmUgdHJpZWQgdG8gZXN0YWJs aXNoIGFuIFNBIHRvIGEgaG9zdCCTYmVoaW5klCBhbiBTRywgZmV0Y2hpbmcgdGhpcyByZWNv cmQgd291bGQgZGlyZWN0IHRoZSBpbml0aWF0b3IgdG8gYW4gYXBwcm9wcmlhdGUgU0cuICBU aGlzIHNvbHZlcyB0aGUgU0cgZGlzY292ZXJ5IHByb2JsZW0uIE90aGVyIGFwcHJvYWNoZXMg aGF2ZSBiZWVuIHB1dCBmb3J0aCBpbiB0aGUgbW9yZSByZWNlbnQgQkJOIHdvcmsgb24gc2Vj dXJpdHkgcG9saWN5IG1hbmFnZW1lbnQsIHdoaWNoIGZvcm1zIHRoZSBiYXNpcyBmb3IgYSBu ZXcgSUVURiBXRywgY2hhaXJlZCBieSBMdWlzIFNhbmNoZXouIFRoZSBmYWN0IHRoYXQgbm9u ZSBvZiB0aGUgYXBwcm9hY2hlcyBoYXMgYmVlbiBkZXBsb3llZCBzYXlzIG1vcmUgYWJvdXQg dGhlIHByaW9yaXRpZXMgb2YgSVBzZWMgdmVuZG9ycyBhbmQgZWFybHkgYWRvcHRlcnMgdGhh biBhYm91dCB0aGUgaW50cmFjdGFiaWxpdHkgb2YgdGhlIHByb2JsZW0uIFRoZSBvdGhlciBw YXJ0IG9mIHRoZSBwcm9ibGVtIGlzIHZlcmlmeWluZyB0aGF0IGFuIFNHIGlzIGF1dGhvcml6 ZWQgdG8gcmVwcmVzZW50IHRoZSBTQSB0YXJnZXQuIEhlcmUgdG9vIHZhcmlvdXMgYXBwcm9h Y2hlcyBoYXZlIGJlZW4gZGVzY3JpYmVkIG9uIHRoZSBJUHNlYyBtYWlsaW5nIGxpc3QuXQ0N XHNlY3Rpb257R2VuZXJhbCBjb21tZW50c30NVGhpcyBzZWN0aW9uIGNvbnRhaW5zIGdlbmVy YWwgY29tbWVudHMgdGhhdCBjYW1lIHVwIGR1cmluZyBvdXIgZXZhbHVhdGlvbiBvZiBJUHNl Yy4gDQ1cYmVnaW57ZW51bWVyYXRlfQ1caXRlbSBJbiBcY2l0ZVtwLlwgMjJde1JGQzI0MDF9 LCBzZXZlcmFsIGZpZWxkcyBpbiB0aGUgU0FEIGFyZSByZXF1aXJlZCBmb3IgYWxsIGltcGxl bWVudGF0aW9ucywgYnV0IG9ubHkgdXNlZCBpbiBzb21lIG9mIHRoZW0uIEl0IGRvZXMgbm90 IG1ha2Ugc2Vuc2UgdG8gcmVxdWlyZSB0aGUgcHJlc2VuY2Ugb2YgZmllbGRzIHdpdGhpbiBh biBpbXBsZW1lbnRhdGlvbi4gT25seSB0aGUgZXh0ZXJuYWwgYmVoYXZpb3Igb2YgdGhlIHN5 c3RlbSBzaG91bGQgYmUgc3RhbmRhcmRpemVkLiBbdGhlIFNBRCBkZWZpbmVkIGluIDI0MDEg aXMgbm9taW5hbCwgYXMgdGhlIHRleHQgZXhwbGFpbnMuIEFuIGltcGxlbWVudGF0aW9uIGlz IG5vdCByZXF1aXJlZCB0byBpbXBsZW1lbnQgdGhlc2UgZmllbGRzLCBidXQgbXVzdCBleGhp Yml0IGJlaGF2aW9yIGNvbnNpc3RlbnQgd2l0aCB0aGUgcHJlc2VuY2Ugb2YgdGhlc2UgZmll bGRzLiBXZSB3ZXJlIHVuYWJsZSB0byBzcGVjaWZ5IGV4dGVybmFsIGJlaGF2aW9yIHdpdGhv dXQgcmVmZXJlbmNlIHRvIGEgY29uc3RydWN0IG9mIHRoaXMgc29ydC4gVGhlIFNBRCBoYXMg dGhlIHNhbWUgcHJvcGVydHkuXQ0NXGl0ZW0gQWNjb3JkaW5nIHRvIFxjaXRlW3AuXCAyM117 UkZDMjQwMX0sIGFuIFNBIGNhbiBiZSBlaXRoZXIgZm9yIHRyYW5zcG9ydCBtb2RlLCB0dW5u ZWwgbW9kZSwgb3IgYGB3aWxkY2FyZCwnJyBpbiB3aGljaCBjYXNlIHRoZSBzZW5kaW5nIGFw cGxpY2F0aW9uIGNhbiBjaG9vc2UgdGhlIG1vZGUgb24gYSBwYWNrZXQtYnktcGFja2V0IGJh c2lzLiBNdWNoIG9mIHRoZSByZXN0IG9mIHRoZSB0ZXh0IGRvZXMgbm90IHNlZW0gdG8gdGFr ZSB0aGlzIHBvc3NpYmlsaXR5IGludG8gYWNjb3VudC4gSXQgYWxzbyBhcHBlYXJzIHRvIHVz IHRvIGJlIG5lZWRsZXNzIGNvbXBsZXhpdHkgdGhhdCB3aWxsIGhhcmRseSBldmVyeSBiZSB1 c2VkLCBhbmQgaXMgbmV2ZXIgYSBuZWNlc3NpdHkuIFdlIGhhdmUgYWxyZWFkeSBhcmd1ZWQg dGhhdCB0cmFuc3BvcnQgbW9kZSBzaG91bGQgYmUgZWxpbWluYXRlZCwgd2hpY2ggaW1wbGll cyB0aGF0IHRoaXMgb3B0aW9uIGlzIHJlbW92ZWQgdG9vLiBJZiB0cmFuc3BvcnQgbW9kZSBp cyB0byBiZSByZXRhaW5lZCwgd2Ugd291bGQgY2VydGFpbmx5IGdldCByaWQgb2YgdGhpcyBv cHRpb24uIFtJIGFncmVlLCBidXQgRGFuIE1jRG9uYWxkIG9mIFN1biBpcyBhZGFtYW50IGFi b3V0IHRoaXMuIFNvLCBjaGFsayBpdCB1cCB0byB0aGUgY29tbWl0dGVlIHByb2Nlc3MhXQ0N XGl0ZW0gSVBzZWMgZG9lcyBub3QgYWxsb3cgcmVwbGF5IHByb3RlY3Rpb24gb24gYW4gU0Eg dGhhdCB3YXMgZXN0YWJsaXNoZWQgdXNpbmcgbWFudWFsIGtleSBtYW5hZ2VtZW50IHRlY2hu aXF1ZXMuIFRoaXMgaXMgYSBzdHJhbmdlIHJlcXVpcmVtZW50LiBXZSByZWFsaXplIHRoYXQg dGhlIHJlcGxheSBwcm90ZWN0aW9uIGxpbWl0cyB0aGUgbnVtYmVyIG9mIHBhY2tldHMgdGhh dCBjYW4gYmUgdHJhbnNtaXR0ZWQgd2l0aCB0aGUgU0EgdG8gJDJeezMyfS0xJC4gU3RpbGws IHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhhdCBoYXZlIGEgbG93IGRhdGEgcmF0ZSB3aGVy ZSByZXBsYXkgcHJvdGVjdGlvbiBpcyBpbXBvcnRhbnQgYW5kIG1hbnVhbCBrZXlpbmcgaXMg dGhlIGVhc2llc3Qgc29sdXRpb24uIFtlbHNld2hlcmUgdGhpcyBjcml0aXF1ZSBhcmd1ZXMg Zm9yIG5vdCBwcmVzZW50aW5nIG9wdGlvbnMgaW4gYSBzdGFuZGFyZCB0aGF0IGNhbiBiZSBt aXNjb25maWd1cmVkLiBZZXQgaGVyZSwgdGhlIGF1dGhvcnMgbWFrZSBhbiBhcmd1bWVudCBm b3IganVzdCBzdWNoIGFuIG9wdGlvbiEgVGhlIFdHIGRlY2lkZWQgdGhhdCB0aGVyZSB3YXMg dG9vIGdyZWF0IGEgY2hhbmNlIHRoYXQgYSBtYW51YWxseSBrZXllZCBTQSB3b3VsZCBmYWls IHRvIG1haW50YWluIGNvdW50ZXIgc3RhdGUgYWNyb3NzIGtleSBsaWZldGltZSBhbmQgdGh1 cyBtYWRlIGEgdmFsdWUganVkZ2VtZW50IHRvIGJhbiBhbnRpLXJlcGxheSBpbiB0aGlzIGNv bnRleHQuXQ0NXGl0ZW0gXGNpdGVbc2VjdGlvbiA1LjIuMSwgcG9pbnQgM117UkZDMjQwMX0g c3VnZ2VzdHMgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gZmluZCB0aGUgbWF0Y2hpbmcg U1BEIGVudHJ5IGZvciBhIHBhY2tldCB1c2luZyBiYWNrLXBvaW50ZXJzIGZyb20gdGhlIFNB RCBlbnRyaWVzLiBJbiBnZW5lcmFsIHRoaXMgd2lsbCBub3Qgd29yayBjb3JyZWN0bHkuIFN1 cHBvc2UgdGhlIFNQRCBjb250YWlucyB0d28gcnVsZXM6IHRoZSBmaXJzdCBvbmUgb3V0bGF3 cyBhbGwgcGFja2V0cyB0byBwb3J0ICRYJCwgYW5kIHRoZSBzZWNvbmQgb25lIGFsbG93cyBh bGwgaW5jb21pbmcgcGFja2V0cyB0aGF0IGhhdmUgYmVlbiBhdXRoZW50aWNhdGVkLiBBbiBT QSBpcyBzZXQgdXAgZm9yIHRoaXMgc2Vjb25kIHJ1bGUuIFRoZSBzZW5kZXIgbm93IHNlbmRz IGEgcGFja2V0IG9uIHRoaXMgU0EgYWRkcmVzc2VkIHRvIHBvcnQgJFgkLiBUaGlzIHBhY2tl dCBzaG91bGQgYmUgcmVmdXNlZCBhcyBpdCBtYXRjaGVzIHRoZSBmaXJzdCBTUEQgcnVsZS4g SG93ZXZlciwgdGhlIGJhY2twb2ludGVyIGZyb20gdGhlIFNBIHBvaW50cyB0byB0aGUgc2Vj b25kIHJ1bGUgaW4gdGhlIFNQRCwgd2hpY2ggYWxsb3dzIHRoZSBwYWNrZXQuIFRoaXMgc2hv d3MgdGhhdCBiYWNrLXBvaW50ZXJzIGZyb20gdGhlIFNBIGRvIG5vdCBhbHdheXMgcG9pbnQg dG8gdGhlIGFwcHJvcHJpYXRlIHJ1bGUsIGFuZCB0aGF0IHRoaXMgaXMgbm90IGEgcHJvcGVy IG1ldGhvZCBvZiBmaW5kaW5nIHRoZSByZWxldmFudCBTUEQgZW50cnkuIFt0aGlzIGlzIHBv aW50ICMzIGFuZCBpcyBhcHBsaWVkIG9ubHkgYWZ0ZXIgcG9pbnRzICMxIGFuZCAjMi4gU2lu Y2UgcG9pbnQgIzEgY2FsbHMgZm9yIGEgbGluZXIgc2VhcmNoIG9mIHRoZSBTUEQsIHRoZSBw YWNrZXQgd291bGQgYmUgcmVqZWN0ZWQsIGFzIHJlcXVpcmVkLiBUaHVzIHBvaW50ICMzIGlz IG5vdCBpbiBlcnJvci5dDQ1caXRlbSBUaGUgaGFuZGxpbmcgb2YgSUNNUCBtZXNzYWdlcyBh cyBkZXNjcmliZWQgaW4gXGNpdGVbc2VjdGlvbiA2XXtSRkMyNDAxfSBpcyB1bmNsZWFyIHRv IHVzLiBJdCBzdGF0ZXMgdGhhdCBhbiBJQ01QIG1lc3NhZ2UgZ2VuZXJhdGVkIGJ5IGEgcm91 dGVyIG11c3Qgbm90IGJlIGZvcndhcmRlZCBvdmVyIGEgdHJhbnNwb3J0LW1vZGUgU0EsIGJ1 dCB0cmFuc3BvcnQgbW9kZSBTQXMgY2FuIG9ubHkgb2NjdXIgaW4gaG9zdHMuIEJ5IGRlZmlu aXRpb24sIGhvc3RzIGRvIG5vdCBmb3J3YXJkIHBhY2tldHMsIGFuZCBhIHJvdXRlciBuZXZl ciBoYXMgYWNjZXNzIHRvIGEgdHJhbnNwb3J0LW1vZGUgU0EuIFs/Pz9dIA0NVGhlIHRleHQg ZnVydGhlciBzdWdnZXN0cyB0aGF0IHVuYXV0aGVudGljYXRlZCBJQ01QIG1lc3NhZ2VzIHNo b3VsZCBiZSBkaXNyZWdhcmRlZC4gVGhpcyBjcmVhdGVzIHByb2JsZW1zLiBMZXQgdXMgZW52 aXNpb24gdHdvIG1hY2hpbmVzIHRoYXQgYXJlIGdlb2dyYXBoaWNhbGx5IGZhciBhcGFydCBh bmQgaGF2ZSBhIHR1bm5lbC1tb2RlIFNBIHNldCB1cC4gVGhlcmUgYXJlIHByb2JhYmx5IGEg ZG96ZW4gcm91dGVycyBiZXR3ZWVuIHRoZXNlIHR3byBtYWNoaW5lcyB0aGF0IGZvcndhcmQg dGhlIHBhY2tldHMuIE5vbmUgb2YgdGhlc2Ugcm91dGVycyBrbm93cyBhYm91dCB0aGUgZXhp c3RlbmNlIG9mIHRoZSBTQS4gQW55IElDTVAgbWVzc2FnZXMgcmVsYXRpbmcgdG8gdGhlIHBh Y2tldHMgdGhhdCBhcmUgc2VudCB3aWxsIGJlIHVuYXV0aGVudGljYXRlZCBhbmQgdW5lbmNy eXB0ZWQuIFNpbXBseSBkaXNjYXJkaW5nIHRoZXNlIElDTVAgbWVzc2FnZXMgcmVzdWx0cyBp biBhIGxvc3Mgb2YgSVAgZnVuY3Rpb25hbGl0eS4gVGhpcyBwcm9ibGVtIGlzIG1lbnRpb25l ZCwgYnV0IHRoZSB0ZXh0IGNsYWltcyB0aGlzIGlzIGR1ZSB0byB0aGUgcm91dGVycyBub3Qg aW1wbGVtZW50aW5nIElQc2VjLiBFdmVuIGlmIHRoZSByb3V0ZXJzIGltcGxlbWVudCBJUHNl YywgdGhleSBzdGlsbCBjYW5ub3Qgc2VuZCBhdXRoZW50aWNhdGVkIElDTVAgbWVzc2FnZXMg YWJvdXQgdGhlIHR1bm5lbCB1bmxlc3MgdGhleSB0aGVtc2VsdmVzIHNldCB1cCBhbiBTQSB3 aXRoIHRoZSB0dW5uZWwgZW5kLXBvaW50IGZvciB0aGUgcHVycG9zZSBvZiBzZW5kaW5nIHRo ZSBJQ01QIHBhY2tldC4gVGhlIHR1bm5lbCBlbmQtcG9pbnQgaW4gdHVybiB3YW50cyB0byBi ZSBzdXJlIHRoZSBzb3VyY2UgaXMgYSByZWFsIHJvdXRlci4gVGhpcyByZXF1aXJlcyBhIGdl bmVyaWMgcHVibGljLWtleSBpbmZyYXN0cnVjdHVyZSwgd2hpY2ggZG9lcyBub3QgZXhpc3Qu IFsyNDAxIGNsZWFybHkgc3RhdGVzIHRoZSBkYW5nZXJzIGFzc29jaWF0ZWQgd2l0aCBibGlu ZGx5IGFjY2VwdGluZyB1bmF1dGhlbnRpY2F0ZWQgSUNNUCwgYW5kIHRoZSBmdW5jdGlvbmFs aXR5IHByb2JsZW1zIGFzc29jaWF0ZWQgd2l0aCBkaXNjYXJkaW5nIHN1Y2ggbWVzc2FnZXMu IFN5c3RlbSBhZG1pbmlzdHJhdG9ycyBhcmUgcHJvdmlkZWQgd2l0aCB0aGUgYWJpbGl0eSB0 byBtYWtlIHRoaXMgdHJhZGVvZmYgbG9jYWxseS4gVGhlIGZpcnN0IHN0ZXAgdG8gYWRkcmVz c2luZyB0aGlzIHByb2JsZW0gaXMgdGhlIGFkZGl0aW9uIG9mIElQc2VjIGludG8gcm91dGVy cywgYXMgc3RhdGVkIGluIHRoZSBSRkMuIE9ubHkgdGhlbiBkb2VzIG9uZSBmYWNlIHRoZSBu ZWVkIHRvIGhhdmUgYSBQS0kgdGhhdCBpZGVudGlmaWVzIHJvdXRlcnMuIFllcywgdGhpcyBz ZWNvbmQgUEtJIGRvZXMgbm90IGV4aXN0LCBidXQgYSBzdWJzZXQgb2YgaXQgKGF0IEJHUCBy b3V0ZXJzKSBtaWdodCBiZSBlc3RhYmxpc2hlZCBpZiB0aGUgUy1CR1AgdGVjaG5vbG9neSBp cyBkZXBsb3llZC4gVGhlc2UgYXJlIHRoZSByb3V0ZXJzIG1vc3QgbGlrZWx5IHRvIGlzc3Vl IElDTVAgUE1UVSBtZXNzYWdlcy5dDQ1BcyBmYXIgYXMgd2UgdW5kZXJzdGFuZCB0aGlzIHBy b2JsZW0sIHRoaXMgaXMgYSBmdW5kYW1lbnRhbCBjb21wYXRpYmlsaXR5IHByb2JsZW0gd2l0 aCB0aGUgZXhpc3RpbmcgSVAgcHJvdG9jb2wgdGhhdCBkb2VzIG5vdCBoYXZlIGEgZ29vZCBz b2x1dGlvbi4gDQ1caXRlbSBcY2l0ZVtzZWN0aW9uIDYuMS4yLjFde1JGQzI0MDF9IGxpc3Rz IGEgbnVtYmVyIG9mIHBvc3NpYmxlIHdheXMgb2YgaGFuZGxpbmcgSUNNUCBQTVRVIG1lc3Nh Z2VzLiBBbiBvcHRpb24gdGhhdCBpcyBub3QgbWVudGlvbmVkIGlzIHRvIGtlZXAgYSBsaW1p dGVkIGhpc3Rvcnkgb2YgcGFja2V0cyB0aGF0IHdlcmUgc2VudCwgYW5kIHRvIG1hdGNoIHRo ZSBoZWFkZXIgaW5zaWRlIHRoZSBQTVRVIHBhY2tldCB0byB0aGUgaGlzdG9yeSBsaXN0LiBU aGlzIGNhbiBpZGVudGlmeSB0aGUgaG9zdCB3aGVyZSB0aGUgcGFja2V0IHRoYXQgd2FzIHRv byBsYXJnZSBvcmlnaW5hdGVkLiBbdGhlIGFwcHJvYWNoIHN1Z2dlc3RlZCBieSB0aGUgYXV0 aG9ycyB3YXMgcmVqZWN0ZWQgYXMgaW1wb3NpbmcgdG9vIG11Y2ggb2YgYSBidXJkZW4gb24g YW4gU0cuIHNlY3Rpb24gNi4xLjIuMSBvZmZlcnMgb3B0aW9ucyAobm90IHN1Z2dlc3Rpb25z KSBmb3IgYW4gU0cgdG8gcmVzcG9uZCB0byBJQ01QIFBNVFUgbWVzc2FnZXMsIGluY2x1ZGlu ZyBoZXVyaXN0aWNzIHRvIGVtcGxveSB3aGVuIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24gaXMg cHJlc2VudCBpbiB0aGUgcmV0dXJuZWQgaGVhZGVyLiBUaGVzZSBvcHRpb25zIG1heSBub3Qg YXMgcmVzcG9uc2l2ZSBhcyBhIHN0cmF0ZWd5IHRoYXQgY2FjaGVzIHRyYWZmaWMgb24gZWFj aCBTQSwgYnV0IHRoZXkgYXJlIG1vZGVzdCBpbiB0aGUgb3ZlcmhlYWQgaW1wb3NlZC4gQWxz bywgYW4gU0EgdGhhdCBjYXJyaWVzIGEgd2lkZSByYW5nZSBvZiB0cmFmZmljIChub3QgZmlu ZS1ncmFpbmVkKSBtaWdodCBub3QgYmVuZWZpdCBmcm9tIGEgbGltaXRlZCB0cmFmZmljIGhp c3RvcnksIGFzIHRoZSB0cmFmZmljIHRoYXQgY2F1c2VkIHRoZSBJQ01QIG1pZ2h0IHdlbGwg YmUgZnJvbSBhIGhvc3Qgd2hvc2UgdHJhZmZpYyBoYXMgYmVlbiBmbHVzaGVkIGZyb20gdGhl IJNsaW1pdGVkIGhpc3RvcnkulF0NDVxpdGVtIFxjaXRlW3NlY3Rpb24gN117UkZDMjQwMX0g bWVudGlvbnMgdGhhdCBlYWNoIGF1ZGl0YWJsZSBldmVudCBpbiB0aGUgQUggYW5kIEVTUCBz cGVjaWZpY2F0aW9ucyBsaXN0cyBhIG1pbmltdW0gc2V0IG9mIGluZm9ybWF0aW9uIHRoYXQg c2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBhdWRpdC1sb2cgZW50cnkuIE5vdCBhbGwgYXVk aXRhYmxlIGV2ZW50cyBkZWZpbmVkIGluIFxjaXRle1JGQzI0MDZ9IGluY2x1ZGUgdGhhdCBp bmZvcm1hdGlvbi4gRnVydGhlcm1vcmUsIGF1ZGl0YWJsZSBldmVudHMgaW4gXGNpdGV7UkZD MjQwMX0gZG8gbm90IHNwZWNpZnkgc3VjaCBhIG1pbmltdW0gbGlzdCBvZiBpbmZvcm1hdGlv bi4gVGhlIGRvY3VtZW50YXRpb24gc2hvdWxkIGJlIHJldmlld2VkIHRvIGVuc3VyZSB0aGF0 IGEgbWluaW11bSBsaXN0IG9mIGF1ZGl0LWxvZyBpbmZvcm1hdGlvbiBpcyBzcGVjaWZpZWQg d2l0aCBlYWNoIGF1ZGl0YWJsZSBldmVudC4gWz8/P10NDVxpdGVtIFZhcmlvdXMgYWxnb3Jp dGhtIHNwZWNpZmljYXRpb25zIHJlcXVpcmUgdGhlIGltcGxlbWVudGF0aW9uIHRvIHJlamVj dCBrbm93biB3ZWFrIGtleXMuIEZvciBleGFtcGxlLCB0aGUgREVTLUNCQyBlbmNyeXB0aW9u IGFsZ29yaXRobSBzcGVjaWZpY2F0aW9ucyBcY2l0ZXtSRkMyNDA1fSByZXF1aXJlcyB0aGF0 IERFUyB3ZWFrIGtleXMgYXJlIHJlamVjdGVkLiBJdCBpcyBxdWVzdGlvbmFibGUgd2hldGhl ciB0aGlzIGFjdHVhbGx5IGluY3JlYXNlcyBzZWN1cml0eS4gSXQgbWlnaHQgdmVyeSB3ZWxs IGJlIHRoYXQgdGhlIGV4dHJhIGNvZGUgdGhhdCB0aGlzIHJlcXVpcmVzIGNyZWF0ZXMgbW9y ZSBzZWN1cml0eSBwcm9ibGVtcyBkdWUgdG8gYnVncyB0aGFuIGFyZSBzb2x2ZWQgYnkgcmVq ZWN0aW5nIHdlYWsga2V5cy4NDVdlYWsga2V5cyBhcmUgbm90IHJlYWxseSBhIHByb2JsZW0g aW4gbW9zdCBzaXR1YXRpb25zLiBGb3IgREVTLCBpdCBpcyBmYXIgbGVzcyB3b3JrIGZvciBh biBhdHRhY2tlciB0byBkbyBhbiBleGhhdXN0aXZlIHNlYXJjaCBvdmVyIGFsbCBwb3NzaWJs ZSBrZXlzIHRoYW4gdG8gd2FpdCBmb3IgYW4gU0EgdGhhdCBoYXBwZW5zIHRvIHVzZSBhIHdl YWsga2V5LiBBZnRlciBhbGwsIHRoZSBlYXNpZXN0IHdheSBmb3IgdGhlIGF0dGFja2VyIHRv IGRldGVjdCB0aGUgd2VhayBrZXlzIGlzIHRvIHRyeSB0aGVtIGFsbC4gV2Vhay1rZXkgcmVq ZWN0aW9uIGlzIG9ubHkgcmVxdWlyZWQgZm9yIGFsZ29yaXRobXMgd2hlcmUgZGV0ZWN0aW5n IHRoZSB3ZWFrIGtleSBjbGFzcyBieSB0aGUgd2VhayBjaXBoZXIgcHJvcGVydGllcyBpcyBz aWduaWZpY2FudGx5IGxlc3Mgd29yayB0aGFuIHRyeWluZyBhbGwgdGhlIHdlYWsga2V5cyBp biBxdWVzdGlvbi4NDVdlIHJlY29tbWVuZCB0aGF0IHRoZSB3ZWFrLWtleSBlbGltaW5hdGlv biByZXF1aXJlbWVudCBiZSByZW1vdmVkLiBFbmNyeXB0aW9uIGFsZ29yaXRobXMgdGhhdCBo YXZlIGxhcmdlIGNsYXNzZXMgb2Ygd2VhayBrZXlzIHRoYXQgaW50cm9kdWNlIHNlY3VyaXR5 IHdlYWtuZXNzZXMgc2hvdWxkIHNpbXBseSBub3QgYmUgdXNlZC4gW0kgdGVuZCB0byBhZ3Jl ZSB3aXRoIHRoaXMgYW5hbHlzaXMuIFRoZSBhcmd1bWVudCBmb3Igd2VhayBrZXkgY2hlY2tp bmcgd2FzIG1hZGUgYnkgZm9sa3Mgd2hvIGRvbpJ0IHVuZGVyc3RhbmQgdGhlIGNyeXB0b2dy YXBoaWMgaXNzdWVzIGludm9sdmVkLCBidXQgd2hvIGFyZSBwZXJzaXN0ZW50IGFuZCBsb3Vk LCBlLmcuLCBCaWxsIFNpbXBzb24uIEFub3RoZXIgZmxhdyBpbiB0aGUgY29tbWl0dGVlIHBy b2Nlc3MuXQ0NXGl0ZW0gVGhlIG9ubHkgbWFuZGF0b3J5IGVuY3J5cHRpb24gYWxnb3JpdGht IGluIEVTUCBpcyBERVMtQ0JDLiBEdWUgdG8gdGhlIHZlcnkgbGltaXRlZCBrZXkgbGVuZ3Ro IG9mIERFUywgdGhpcyBjYW5ub3QgYmUgY29uc2lkZXJlZCB0byBiZSB2ZXJ5IHNlY3VyZS4g V2Ugc3Ryb25nbHkgdXJnZSB0aGF0IHRoaXMgYWxnb3JpdGhtIG5vdCBiZSBzdGFuZGFyZGl6 ZWQgYnV0IGJlIHJlcGxhY2VkIGJ5IGEgc3Ryb25nZXIgYWx0ZXJuYXRpdmUuIFRoZSBtb3N0 IG9idmlvdXMgY2FuZGlkYXRlIGlzIHRyaXBsZS1ERVMuIEJsb3dmaXNoIGNvdWxkIGJlIHVz ZWQgYXMgYW4gaW50ZXJpbSBoaWdoLXNwZWVkIHNvbHV0aW9uLlxmb290bm90ZXtPbiBhIFBl bnRpdW0gQ1BVLCBCbG93ZmlzaCBpcyBhYm91dCBzaXggdG8gc2V2ZW4gdGltZXMgZmFzdGVy IHRoYW4gdHJpcGxlLURFUy59IFRoZSB1cGNvbWluZyBBRVMgc3RhbmRhcmQgd2lsbCBwcmVz dW1hYmx5IGdhaW4gcXVpY2sgYWNjZXB0YW5jZSBhbmQgcHJvYmFibHkgYmVjb21lIHRoZSBk ZWZhdWx0IGVuY3J5cHRpb24gbWV0aG9kIGZvciBtb3N0IHN5c3RlbXMuIFtERVMgYXMgYSBk ZWZhdWx0IHdhcyBtYW5kYXRlZCBiZWNhdXNlIG9mIHByZXNzdXJlIGZyb20gdmVuZG9ycyB3 aG8sIGF0IHRoZSB0aW1lLCBjb3VsZCBub3QgZ2V0IGV4cG9ydCBwZXJtaXNzaW9uIGZvciAz REVTLiBUcmlwbGUgREVTIG9yIEFFUyB3aWxsIGNlcnRhaW5seSBhdWdtZW50IERFUywgYW5k IG1heSByZXBsYWNlIGl0IGluIHRoZSBmdXR1cmUuIF0NDVxpdGVtIFRoZSBpbnNpc3RlbmNl IG9uIHJhbmRvbWx5IHNlbGVjdGVkIElWIHZhbHVlcyBpbiBcY2l0ZXtSRkMyNDA1fSBzZWVt cyB0byBiZSBvdmVya2lsbC4gSXQgaXMgdHJ1ZSB0aGF0IGEgY291bnRlciB3b3VsZCBwcm92 aWRlIGtub3duIGxvdyBIYW1taW5nLXdlaWdodCBpbnB1dCBkaWZmZXJlbnRpYWxzIHRvIHRo ZSBibG9jayBjaXBoZXIuIEFsbCByZWFzb25hYmxlIGJsb2NrIGNpcGhlcnMgYXJlIHNlY3Vy ZSBlbm91Z2ggYWdhaW5zdCB0aGlzIHR5cGUgb2YgYXR0YWNrLiBVc2Ugb2YgYSByYW5kb20g Z2VuZXJhdG9yIHJlc3VsdHMgaW4gYW4gaW5jcmVhc2VkIHJpc2sgb2YgYW4gaW1wbGVtZW50 YXRpb24gZXJyb3IgdGhhdCB3aWxsIGxlYWQgdG8gbG93LWVudHJvcHkgb3IgY29uc3RhbnQg SVYgdmFsdWVzOyBzdWNoIGFuIGVycm9yIHdvdWxkIHR5cGljYWxseSBub3QgYmUgZm91bmQg ZHVyaW5nIHRlc3RpbmcuIFtpbiBwcmFjdGljZSB0aGUgSVYgaXMgdXN1YWxseSBhY3F1aXJl ZCBmcm9tIHByZXZpb3VzIGNpcGhlcnRleHQgb3V0cHV0LCB3aGljaCBpcyBlYXN5IHRvIGFj cXVpcmUgYW5kIG5vdCBsaWtlbHkgdG8gcmVzdWx0IGluIHNpZ25pZmljYW50IGNvbXBsZXhp dHkuIEluIGhhcmR3YXJlIGFzc2lzdGVkIGVudmlyb25tZW50IGFuIFJORyBpcyB1c3VhbGx5 IGF2YWlsYWJsZSBhbnl3YXkuXQ0NXGl0ZW0gVXNlIG9mIGEgYmxvY2sgY2lwaGVyIHdpdGgg YSA2NC1iaXQgYmxvY2sgc2l6ZSBzaG91bGQgaW4gZ2VuZXJhbCBiZSBsaW1pdGVkIHRvIGF0 IG1vc3QgJDJeezMyfSQgYmxvY2sgZW5jcnlwdGlvbnMgcGVyIGtleS4gVGhpcyBpcyBkdWUg dG8gdGhlIGJpcnRoZGF5IHBhcmFkb3guIEFmdGVyICQyXnszMn0kIGJsb2NrcyB3ZSBjYW4g ZXhwZWN0IG9uZSBjb2xsaXNpb24uXGZvb3Rub3Rle1RvIGdldCBhICQxMF57LTZ9JCBwcm9i YWJpbGl0eSBvZiBhIGNvbGxpc2lvbiBpdCBzaG91bGQgYmUgbGltaXRlZCB0byBhYm91dCAk Ml57MjJ9JCBibG9ja3MufSBJbiBDQkMgbW9kZSwgdHdvIGVxdWFsIGNpcGhlcnRleHRzIGdp dmUgdGhlIGF0dGFja2VyIHRoZSBYT1Igb2YgdHdvIGJsb2NrcyBvZiB0aGUgcGxhaW50ZXh0 LiBUaGUgc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBERVMtQ0JDIGVuY3J5cHRpb24gYWxnb3Jp dGhtIFxjaXRle1JGQzI0MDV9IHNob3VsZCBtZW50aW9uIHRoaXMsIGFuZCByZXF1aXJlIHRo YXQgYW55IFNBIHVzaW5nIHN1Y2ggYW4gYWxnb3JpdGhtIGxpbWl0IHRoZSB0b3RhbCBhbW91 bnQgb2YgZGF0YSBlbmNyeXB0ZWQgYnkgYSBzaW5nbGUga2V5IHRvIGEgc3VpdGFibGUgdmFs dWUuIA0NXGl0ZW0gVGhlIHByZWZlcnJlZCBtb2RlIGZvciB1c2luZyBhIGJsb2NrIGNpcGhl ciBpbiBFU1Agc2VlbXMgdG8gYmUgQ0JDIG1vZGUgXGNpdGV7UkZDMjQ1MX0uIFRoaXMgaXMg cHJvYmFibHkgdGhlIG1vc3Qgd2lkZWx5IHVzZWQgY2lwaGVyIG1vZGUsIGJ1dCBpdCBoYXMg c29tZSBkaXNhZHZhbnRhZ2VzLiBBcyBtZW50aW9uZWQgZWFybGllciwgYSBjb2xsaXNpb24g Z2l2ZXMgZGlyZWN0IGluZm9ybWF0aW9uIGFib3V0IHRoZSByZWxhdGlvbiBvZiB0d28gcGxh aW50ZXh0IGJsb2Nrcy4gRnVydGhlcm1vcmUsIGluIGhhcmR3YXJlIGltcGxlbWVudGF0aW9u cyBlYWNoIG9mIHRoZSBlbmNyeXB0aW9ucyBoYXMgdG8gYmUgZG9uZSBpbiB0dXJuLiBUaGlz IGdpdmVzIGEgbGltaXRlZCBwYXJhbGxlbGlzbSwgd2hpY2ggaGluZGVycyBoaWdoLXNwZWVk IGhhcmR3YXJlIGltcGxlbWVudGF0aW9ucy4gW2ZpcnN0LCB0aGlzIGlzIG5vdCBhbiBpbnRy aW5zaWMgcGFydCBvZiB0aGUgYXJjaGl0ZWN0dXJlOyBvbmUgY2FuIGRlZmluZSBkaWZmZXJl bnQgbW9kZXMgZm9yIHVzZSB3aXRoIGV4aXN0aW5nIG9yIGRpZmZlcmVudCBhbGdvcml0aG1z IGlmIHRoZSBXRyBpcyBzbyBtb3RpdmF0ZWQuIFNlY29uZCwgY3VycmVudCBoYXJkd2FyZSBp cyBhdmFpbGFibGUgYXQgc3BlZWRzIGhpZ2hlciB0aGFuIHRoZSBhc3NvY2lhdGVkIHBhY2tl dCBwcm9jZXNzaW5nIGNhcGFiaWxpdHkgb2YgSVBzZWMgZGV2aWNlcywgc28gdGhpcyBkb2Vz IG5vdCBhcHBlYXIgdG8gYmUgYSBwcm9ibGVtIGZvciB0aGUgbmVhciB0ZXJtLiBUcmFuc2l0 aW9uIHRvIEFFUyB3aWxsIGRlY3JlYXNlIHRoZSBwcm9jZXNzaW5nIGJ1cmRlbiAocmVsYXRp dmUgdG8gM0RFUyksIHdoaWNoIG1heSByZW5kZXIgdGhpcyBjb25jZXJuIGxlc3Mgc2VyaW91 cy5dDQ1BbHRob3VnaCBub3QgdXNlZCB2ZXJ5IG9mdGVuLCB0aGUgY291bnRlciBtb2RlIHNl ZW1zIHRvIGJlIHByZWZlcmFibGUuIFRoZSBjaXBoZXJ0ZXh0IG9mIGJsb2NrICRpJCBpcyBm b3JtZWQgYXMgJENfaSA9IFBfaSBcb3BsdXMgRV9LKCBpICkkLCB3aGVyZSAkaSQgaXMgdGhl IGJsb2NrIG51bWJlciB0aGF0IG5lZWRzIHRvIGJlIHNlbnQgYXQgdGhlIHN0YXJ0IG9mIHRo ZSBwYWNrZXQuXGZvb3Rub3Rle0lmIHJlcGxheSBwcm90ZWN0aW9uIGlzIGFsd2F5cyBpbiB1 c2UsIHRoZW4gdGhlIHN0YXJ0aW5nICRpJC12YWx1ZSBjb3VsZCBiZSBmb3JtZWQgYXMgJDJe ezMyfSQgdGltZXMgdGhlIHNlcXVlbmNlIG51bWJlci4gVGhpcyBzYXZlcyBlaWdodCBieXRl cyBwZXIgcGFja2V0Ln0gQWZ0ZXIgbW9yZSB0aGFuICQyXnszMn0kIGJsb2NrcyBjb3VudGVy IG1vZGUgYWxzbyByZXZlYWxzIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBsYWludGV4 dCwgYnV0IHRoaXMgaXMgbGVzcyB0aGFuIHdoYXQgb2NjdXJzIGluIENCQy4gVGhlIGJpZyBh ZHZhbnRhZ2Ugb2YgY291bnRlciBtb2RlIGlzIHRoYXQgaGFyZHdhcmUgaW1wbGVtZW50YXRp b25zIGNhbiBwYXJhbGxlbGl6ZSB0aGUgZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBwcm9j ZXNzLCB0aHVzIGFjaGlldmluZyBhIG11Y2ggaGlnaGVyIHRocm91Z2hwdXQuIFtlYXJsaWVy IHRoZSBhdXRob3JzIGNyaXRpY2l6ZSBJUHNlYyBmb3IgYSBsYWNrIG9mIG9ydGhvZ29uYWxp dHksIGJ1dCBpbnRyb2R1Y2luZyBpbnRlcmRlcGVuZGVuY2UgYmV0d2VlbiB0aGUgYW50aS1y ZXBsYXkgY291bnRlciBhbmQgZW5jcnlwdGlvbiB3b3VsZCBjZXJ0YWlubHkgdmlvbGF0ZSB0 aGUgc3Bpcml0IG9mIHRoZSBlYXJsaWVyIGNyaXRpY2lzbSEgQ291bnRlciBtb2RlIHZlcnNp b25zIG9mIGFsZ29yaXRobXMgY2FuIGJlIGFkZGVkIHRvIHRoZSBsaXN0IGVhc2lseSBpZiB0 aGVyZSBpcyBzdWZmaWNpZW50IHZlbmRvciBzdXBwb3J0Ll0NDVxpdGVtIFxjaXRlW3NlY3Rp b24gMi4zXXtSRkMyNDUxfSBzdGF0ZXMgdGhhdCBCbG93ZmlzaCBoYXMgd2VhayBrZXlzLCBi dXQgdGhhdCB0aGUgbGlrZWxpaG9vZCBvZiBnZW5lcmF0aW5nIG9uZSBpcyB2ZXJ5IHNtYWxs LiBXZSBkaXNhZ3JlZSB3aXRoIHRoZXNlIHN0YXRlbWVudHMuIFRoZSBsaWtlbGlob29kIG9m IGdldHRpbmcgdHdvIGVxdWFsIDMyLWJpdCB2YWx1ZXMgaW4gYW55IG9uZSAyNTYtZW50cnkg Uy1ib3ggaXMgYWJvdXQgJHsyNTYgXGNob29zZSAyfSBcY2RvdCAyXnstMzJ9IFxhcHByb3gg Ml57LTE3fSQuIFRoaXMgaXMgYW4gZXZlbnQgdGhhdCB3aWxsIGNlcnRhaW5seSBvY2N1ciBp biBwcmFjdGljZS4gSG93ZXZlciwgdGhlIEJsb3dmaXNoIHdlYWsga2V5cyBvbmx5IGxlYWQg dG8gZGV0ZWN0YWJsZSB3ZWFrbmVzc2VzIGluIHJlZHVjZWQtcm91bmQgdmVyc2lvbnMgb2Yg dGhlIGNpcGhlci4gVGhlcmUgYXJlIG5vIGtub3duIHdlYWsga2V5cyBmb3IgdGhlIGZ1bGwg Qmxvd2Zpc2ggY2lwaGVyLiANDVxpdGVtIEluIFxjaXRlW3NlY3Rpb24gMi41XXtSRkMyNDUx fSwgaXQgaXMgc3VnZ2VzdGVkIHRvIG5lZ290aWF0ZSB0aGUgbnVtYmVyIG9mIHJvdW5kcyBv ZiBhIGNpcGhlci4gV2UgY29uc2lkZXIgdGhpcyB0byBiZSBhIHZlcnkgYmFkIGlkZWEuIFRo ZSBudW1iZXIgb2Ygcm91bmRzIGlzIGludGVncmFsIHRvIHRoZSBjaXBoZXIgc3BlY2lmaWNh dGlvbnMgYW5kIHNob3VsZCBub3QgYmUgY2hhbmdlZCBhdCB3aWxsLiBFdmVuIGZvciBjaXBo ZXJzIHRoYXQgYXJlIHNwZWNpZmllZCB3aXRoIGEgdmFyaWFibGUgbnVtYmVyIG9mIHJvdW5k cywgdGhlIGRldGVybWluYXRpb24gb2YgdGhlIG51bWJlciBvZiByb3VuZHMgc2hvdWxkIG5v dCBiZSBsZWZ0IHVwIHRvIHRoZSBpbmRpdmlkdWFsIHN5c3RlbSBhZG1pbmlzdHJhdG9ycy4g VGhlIElQc2VjIHN0YW5kYXJkIHNob3VsZCBzcGVjaWZ5IHRoZSBudW1iZXIgb2Ygcm91bmRz IGZvciB0aG9zZSBjaXBoZXJzLiBbPz8/XQ0NXGl0ZW0gXGNpdGVbc2VjdGlvbiAyLjVde1JG QzI0NTF9IHByb3Bvc2VzIHRoZSB1c2Ugb2YgUkM1LiBXZSB1cmdlIGNhdXRpb24gaW4gdGhl IHVzZSBvZiB0aGlzIGNpcGhlci4gSXQgdXNlcyBzb21lIG5ldyBpZGVhcyB0aGF0IGhhdmUg bm90IGJlZW4gZnVsbHkgYW5hbHl6ZWQgb3IgdW5kZXJzdG9vZCBieSB0aGUgY3J5cHRvZ3Jh cGhpYyBjb21tdW5pdHkuIFRoZSBvcmlnaW5hbCBSQzUgYXMgcHJvcG9zZWQgKHdpdGggMTIg cm91bmRzKSB3YXMgYnJva2VuLCBhbmQgaW4gcmVzcG9uc2UgdG8gdGhhdCB0aGUgcmVjb21t ZW5kZWQgbnVtYmVyIG9mIHJvdW5kcyB3YXMgaW5jcmVhc2VkIHRvIDE2LiBXZSBmZWVsIHRo YXQgZnVydGhlciByZXNlYXJjaCBpbnRvIHRoZSB1c2Ugb2YgZGF0YS1kZXBlbmRlbnQgcm90 YXRpb25zIGlzIHJlcXVpcmVkIGJlZm9yZSBSQzUgaXMgdXNlZCBpbiBmaWVsZGVkIHN5c3Rl bXMuIFtSQzUgaXMgbm90IHJlcXVpcmVkIGJ5IElQc2VjIGltcGxlbWVudGF0aW9ucy4gSW4g dGhlIHNwaXJpdCBvZiBmbGV4aWJsZSBpbXBsZW1lbnRhdGlvbnMsIHZlbmRvcnMgYXJlIGZy ZWUgdG8gb2ZmZXIgYW55IGFkZGl0aW9uYWwgYWxnb3JpdGhtcyBpbiBhZGRpdGlvbiB0byB0 aGUgcmVxdWlyZWQgZGVmYXVsdC4gSW4gZ2VuZXJhbCwgdGhlIElFVEYgaXMgbm90IHByZXBh cmVkIHRvIG1ha2UgdmFsdWUganVkZ2VtZW50cyBhYm91dCB0aGVzZSBhbGdvcml0aG1zLl0N DVxpdGVtIFxjaXRlW3NlY3Rpb24gMi40XXtSRkMyNDA2fSBzcGVjaWZpZXMgdGhhdCB0aGUg RVNQIHBhZGRpbmcgc2hvdWxkIHBhZCB0aGUgcGxhaW50ZXh0IHRvIGEgbGVuZ3RoIHNvIHRo YXQgdGhlIG92ZXJhbGwgY2lwaGVydGV4dCBsZW5ndGggaXMgYm90aCBhIG11bHRpcGxlIG9m IHRoZSBibG9jayBzaXplIGFuZCBhIG11bHRpcGxlIG9mIDQuIElmIGEgYmxvY2sgY2lwaGVy IG9mIHVudXN1YWwgYmxvY2sgc2l6ZSBpcyB1c2VkIChlLmcuLCAxNSBieXRlcyksIHRoZW4g dGhpcyBjYW4gcmVxdWlyZSB1cCB0byA1OSBieXRlcyBvZiBwYWRkaW5nLiBUaGlzIHBhZGRp bmcgcnVsZSB3b3JrcyBiZXN0IGZvciBibG9jayBzaXplcyB0aGF0IGFyZSBhIG11bHRpcGxl IG9mIDQsIHdoaWNoIGZvcnR1bmF0ZWx5IGlzIHRoZSBjYXNlIGZvciBtb3N0IGJsb2NrIGNp cGhlcnMuIFt0aGlzIHBhZGRpbmcgcnVsZSBpcyBiYXNlZCBwcmltYXJpbHkgb24gSVAgcGFj a2V0IGFsaWdubWVudCBjb25zaWRlcmF0aW9ucywgbm90IG9uIGNvbW1vbiBibG9jayBjaXBo ZXIgc2l6ZXMsIGFzIHN0YXRlZCBpbiB0aGUgdGV4dF0NDVxpdGVtIFxjaXRlW3AuXCA2LCBw b2ludCBhXXtSRkMyNDA2fSBzdGF0ZXMgdGhhdCB0aGUgcGFkZGluZyBjb21wdXRhdGlvbnMg b2YgdGhlIEVTUCBwYXlsb2FkIHdpdGggcmVnYXJkIHRvIHRoZSBibG9jayBzaXplIG9mIHRo ZSBjaXBoZXIgYXBwbHkgdG8gdGhlIHBheWxvYWQgZGF0YSwgZXhjbHVkaW5nIHRoZSBJViAo aWYgcHJlc2VudCksIFBhZCBMZW5ndGgsIGFuZCBOZXh0IEhlYWRlciBmaWVsZHMuIFRoaXMg d291bGQgaW1wbHkgdGhhdCB0aGUgUGFkIExlbmd0aCBhbmQgTmV4dCBIZWFkZXIgZmllbGRz IGFyZSBub3QgYmVpbmcgZW5jcnlwdGVkLiBZZXQgdGhlIHJlc3Qgb2YgdGhlIHNwZWNpZmlj YXRpb24gaXMgY2xlYXIgdGhhdCB0aGUgUGFkIExlbmd0aCBhbmQgTmV4dCBIZWFkZXIgZmll bGQgYXJlIHRvIGJlIGVuY3J5cHRlZCwgd2hpY2ggaXMgd2hhdCBzaG91bGQgaGFwcGVuLiBU aGUgdGV4dCBvZiBwb2ludCBhIHNob3VsZCBiZSBtYWRlIGNvbnNpc3RlbnQgd2l0aCB0aGUg cmVzdCBvZiB0aGUgdGV4dC4gW1RoZSB0ZXh0IHNheXMgk4V0aGUgcGFkZGluZyBjb21wdXRh dGlvbiBhcHBsaWVzIHRvIHRoZSBQYXlsb2FkIERhdGEgZXhjbHVzaXZlIG9mIHRoZSBJViwg dGhlIFBhZCBMZW5ndGgsIGFuZCBOZXh0IEhlYWRlciBmaWVsZHMulCBUaGUgY29tbWEgYWZ0 ZXIgk0lWlCBpcyBtZWF0IHRvIHRlcm1pbmF0ZSB0aGUgc2NvcGUgb2YgdGhlIHdvcmQgk2V4 Y2x1c2l2ZSyUIGFuZCB0aHVzIHRoZSBpbnRlbnQgaXMgdG8gaW5jbHVkZSB0aGUgcGFkIGxl bmd0aCBhbmQgbmV4dCBoZWFkZXIgZmllbGRzLiBUaGUgdGVybSCTcGF5bG9hZJQgaW4gRVNQ IGFwcGxpZXMgdG8gYSBzZXQgb2YgZGF0YSBub3QgaW5jbHVkaW5nIHRoZSBsYXR0ZXIgdHdv IGZpZWxkcywgc28gdGhlIHNlbnRlbmNlIGlzLCB0ZWNobmljYWxseSwgdW5hbWJpZ3VvdXMs IGFuZCBpdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIHRlcm1zIGVtcGxveWVkIGluIHRoZSBm aWd1cmUgaW4gc2VjdGlvbiAyLiAgQnV0LCBJIGFkbWl0IHRoZSB3b3JkaW5nIGNvdWxkIGJl IGltcHJvdmVkLl0NDVxpdGVtIFRoZXJlIGlzIGEgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHRo ZSBOVUxMIGVuY3J5cHRpb24gYWxnb3JpdGhtIHVzZWQgaW4gRVNQIFxjaXRle1JGQzI0MTB9 LCBidXQgbm8gZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHRoZSBOVUxMIGF1dGhlbnRpY2F0aW9u IGFsZ29yaXRobSwgd2hpY2ggaXMgYWxzbyB1c2VkIGJ5IEVTUCBcY2l0ZVtzZWN0aW9uIDVd e1JGQzI0MDZ9LiBbZ29vZCBwb2ludC4gQW5vdGhlciBSRkMgcHVibGljYXRpb24gb3Bwb3J0 dW5pdHkhXQ0NXGl0ZW0gVGhlIE5VTEwgY2lwaGVyIHNwZWNpZmllcyBhbiBJViBsZW5ndGgg b2YgemVybyBcY2l0ZXtSRkMyNDEwfS4gVGhpcyB3b3VsZCBzZWVtIHRvIGltcGx5IHRoYXQg dGhlIE5VTEwgY2lwaGVyIGlzIHVzZWQgaW4gQ0JDIG1vZGUsIHdoaWNoIGlzIGNsZWFybHkg bm90IHRoZSBjYXNlLiBUaGUgTlVMTCBjaXBoZXIgaXMgaW4gZmFjdCB1c2VkIGluIEVDQiBt b2RlLCB3aGljaCBkb2VzIG5vdCByZXF1aXJlIGFuIElWLiBUaGVyZWZvcmUsIG5vIElWIGxl bmd0aCBzaG91bGQgYmUgc3BlY2lmaWVkLiBbdXNlIG9mIHRoZSBOVUxMIGNpcGhlciBpbiBF Q0IgbW9kZSB3b3VsZCBiZSBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgZ3VpZGFuY2UgaW4gRklQ UyA4MiwgYW5kIHRodXMgQ0JDIG1vZGUgaXMgaW50ZW5kZWQsIHRvIHByZXNlcnZlIHRoZSBj b25maWRlbnRpYWxpdHkgY2hhcmFjdGVyaXN0aWNzIGluaGVyZW50IGluIHRoaXMgY2lwaGVy IDotKS5dDQ1cZW5ke2VudW1lcmF0ZX0NDVxzZWN0aW9ue0NvbmNsdXNpb25zfQ1UaGUgSVBz ZWMgc3lzdGVtIHNob3VsZCBiZSBzaW1wbGlmaWVkIHNpZ25pZmljYW50bHkuIFRoaXMgY2Fu IGJlIGRvbmUgd2l0aG91dCBsb3NzIG9mIGZ1bmN0aW9uYWxpdHkgb3IgcGVyZm9ybWFuY2Uu IFRoZXJlIGFyZSBhbHNvIHNvbWUgc2VjdXJpdHkgd2Vha25lc3NlcyB0aGF0IHNob3VsZCBi ZSBmaXhlZC4gW3RoZSBleHRlbnNpdmUgY29tbWVudHMgYWJvdmUgaWxsdXN0cmF0ZSB0aGF0 IHRoZSBwcm9wb3NlZCBjaGFuZ2VzIHRvIElQc2VjIHdvdWxkIGNoYW5nZSB0aGUgZnVuY3Rp b25hbGl0eSwgY29udHJhcnkgdG8gdGhlIGNsYWltIG1hZGUgaGVyZS4gT25lIG1pZ2h0IGFy Z3VlIGFib3V0IHRoZSBpbXBvcnRhbmNlIG9mIHNvbWUgb2YgdGhpcyBmdW5jdGlvbmFsaXR5 LCBidXQgc2V2ZXJhbCBleGFtcGxlcyBoYXZlIGJlZW4gcHJvdmlkZWQgdG8gaWxsdXN0cmF0 ZSBhcHBsaWNhdGlvbiBjb250ZXh0cyB0aGF0IHRoZSBhdXRob3JzIG9mIHRoaXMgcmVwb3J0 IGRpZCBub3QgY29uc2lkZXIgaW4gdGhlaXIgYW5hbHlzaXMuIFNldmVyYWwgbWlzdW5kZXJz dGFuZGluZ3Mgb2Ygc29tZSBSRkNzIGFsc28gd2VyZSBub3RlZC5dIA0NRHVlIHRvIGl0cyBo aWdoIGNvbXBsZXhpdHksIHdlIGhhdmUgbm90IGJlZW4gYWJsZSB0byBhbmFseXplIElQc2Vj IGFzIHRob3JvdWdobHkgYXMgd2Ugd291bGQgaGF2ZSBsaWtlZC4gQWZ0ZXIgc2ltcGxpZmlj YXRpb24sIGEgbmV3IHNlY3VyaXR5IGFuYWx5c2lzIHNob3VsZCBiZSBwZXJmb3JtZWQuDQ0N XGNoYXB0ZXJ7SVNBS01QfVxsYWJlbHtjaGFwOklTQUtNUH0NDUlTQUtNUCBcY2l0ZXtSRkMy NDA4fSBkZWZpbmVzIHRoZSBvdmVyYWxsIHN0cnVjdHVyZSBvZiB0aGUgcHJvdG9jb2xzIHVz ZWQgdG8gZXN0YWJsaXNoIFNBcyBhbmQgdG8gcGVyZm9ybSBvdGhlciBrZXkgbWFuYWdlbWVu dCBmdW5jdGlvbnMuIElTQUtNUCBzdXBwb3J0cyBzZXZlcmFsIERvbWFpbnMgT2YgSW50ZXJw cmV0YXRpb24gKERPSSksIG9mIHdoaWNoIHRoZSBJUHNlYy1ET0kgaXMgb25lLiBJU0FLTVAg ZG9lcyBub3Qgc3BlY2lmeSB0aGUgd2hvbGUgcHJvdG9jb2wsIGJ1dCBwcm92aWRlcyBidWls ZGluZyBibG9ja3MgZm9yIHRoZSB2YXJpb3VzIERPSXMgYW5kIGtleS1leGNoYW5nZSBwcm90 b2NvbHMuDQ1UaGlzIGNoYXB0ZXIgYW5hbHl6ZXMgdGhlIElTQUtNUCBzcGVjaWZpY2F0aW9u cy4gU2VjdGlvbiByZWZlcmVuY2VzIGFuZCBwYWdlIG51bWJlcnMgaW4gdGhpcyBjaGFwdGVy IHJlZmVyIHRvIFxjaXRle1JGQzI0MDh9Lg0NV2UgZm91bmQgdGhlIElTQUtNUCBkb2N1bWVu dCBcY2l0ZXtSRkMyNDA4fSB2ZXJ5IGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kLiBFc3NlbnRp YWwgZXhwbGFuYXRpb25zIGFyZSBtaXNzaW5nLCBhbmQgdGhlIGRvY3VtZW50IGNvbnRyYWRp Y3RzIGl0c2VsZiBpbiB2YXJpb3VzIHBsYWNlcy4gDQ1cc2VjdGlvbntIZWFkZXIgdHlwZXN9 DVRoZSBkZWZpbml0aW9uIG9mIHRoZSBJU0FLTVAgaGVhZGVycyBnaXZlcyByaXNlIHRvIHZh cmlvdXMgcXVlc3Rpb25zLiBUaGUgc3RhbmRhcmQgaGVhZGVyIGZvciBlYWNoIHBheWxvYWQg Y29udGFpbnMgdGhlIHR5cGUgb2YgdGhlIFxlbXBoe25leHRcL30gcGF5bG9hZCBpbiB0aGUg bWVzc2FnZSBcY2l0ZVtzZWN0aW9uIDMuMl17UkZDMjQwOH0uIFRoaXMgaXMgYW4gb2RkIGNv bnN0cnVjdGlvbiB0aGF0IHdvdWxkIHNlZW0gdG8gY29tcGxpY2F0ZSBib3RoIHRoZSBnZW5l cmF0aW9uIGFuZCBwYXJzaW5nIG9mIG1lc3NhZ2VzLiBBcyB0aGUgSVNBS01QIGhlYWRlciBh bHJlYWR5IGNvbnRhaW5zIHRoZSBvdmVyYWxsIGxlbmd0aCwgdGhlIHBhcnNlciBhbHJlYWR5 IGtub3dzIHdoZXRoZXIgdGhlcmUgaXMgYW5vdGhlciBwYXlsb2FkIGluIHRoZSBtZXNzYWdl LiBJdCB3b3VsZCBzZWVtIHNpbXBsZXIgdG8gaGF2ZSBlYWNoIHBheWxvYWQgY29udGFpbiBp dHMgb3duIHR5cGUgaW4gdGhlIHN0YW5kYXJkaXplZCBwYXlsb2FkLWhlYWRlciwgaW5zdGVh ZCBvZiB0aGUgdHlwZSBvZiB0aGUgbmV4dCBwYXlsb2FkLg0NU2VjdGlvbiAzLjQgZG9lcyBu b3QgbWFrZSBpdCBjbGVhciB0aGF0IHRoZSBTZWN1cml0eSBBc3NvY2lhdGlvbiBQYXlsb2Fk IGlzIGluIGZhY3QgYSBoZWFkZXIsIGFuZCBpcyBhbHdheXMgZm9sbG93ZWQgYnkgemVybyBv ciBtb3JlIFByb3Bvc2FsIHBheWxvYWRzLiAoQSBzaW1pbGFyIHNpdHVhdGlvbiBvY2N1cnMg d2l0aCB0aGUgUHJvcG9zYWwgYW5kIFRyYW5zZm9ybSBwYXlsb2Fkcy4pIFRoaXMgdHlwZSBv ZiBkZXBlbmRlbmN5IHNob3VsZCBiZSBkb2N1bWVudGVkIG1vcmUgY2xlYXJseS4gVGhlIGN1 cnJlbnQgdGV4dCBjYXVzZWQgdGhlIGF1dGhvcnMgbXVjaCBjb25mdXNpb24sIGFzIGl0IHdh cyBub3QgYXQgYWxsIGNsZWFyIHRoYXQgc3VjaCBhIHN5c3RlbSBvZiBzdWItcGF5bG9hZHMg d2FzIGJlaW5nIHVzZWQuIEFub3RoZXIgb2RkaXR5IGlzIHRoZSBmYWN0IHRoYXQgdGhlcmUg aXMgbm8gZmllbGQgaW4gdGhlIFNBIGhlYWRlciB0byBpbmRpY2F0ZSB0aGUgdHlwZSBvZiB0 aGUgZmlyc3Qgc3ViLXBheWxvYWQuIEVhY2ggcGF5bG9hZCBzcGVjaWZpZXMgdGhlIHR5cGUg b2YgdGhlIFxlbXBoe25leHRcL30gcGF5bG9hZCwgYnV0IHRoZXJlIGlzIG5vIGNvcnJlc3Bv bmRpbmcgZmllbGQgZm9yIHRoZSB2ZXJ5IGZpcnN0IHN1Yi1wYXlsb2FkLiBQcmVzdW1hYmx5 IHRoZSByZWNlaXZlciBoYXMgdG8ga25vdyB0aGF0IGFuIFNBIHBheWxvYWQgd2lsbCBhbHdh eXMgaGF2ZSBhIHByb3Bvc2FsIHBheWxvYWQgYXMgdGhlIGZpcnN0IHN1Yi1wYXlsb2FkLiBU aGlzIGdpdmVzIHJpc2UgdG8gdGhlIHF1ZXN0aW9uIHdoeSB0aGUgcHJvcG9zYWwgcGF5bG9h ZCBoYXMgYSBgYG5leHQgaGVhZGVyJycgZmllbGQgYXQgYWxsLiBVc2luZyB0aGUgc2FtZSB0 eXBlIG9mIGluZm9ybWF0aW9uIChhbGxvd2VkIHN1Yi1wYXlsb2FkIHN0cnVjdHVyZXMpLCB0 aGUgcmVjZWl2ZXIgY2FuIGFscmVhZHkgZGVkdWNlIHdoYXQgdGhlIHZhbHVlIG9mIHRoaXMg ZmllbGQgc2hvdWxkIGJlLiBUaGVyZSBhcmUgYWxzbyBvdGhlciBpbmNvbnNpc3RlbmNpZXMu IFRoZSBTQSBoZWFkZXIgZG9lcyBub3Qgc3BlY2lmeSBob3cgbWFueSBwcm9wb3NhbHMgYXJl IGluY2x1ZGVkIGFzIHN1Yi1wYXlsb2FkcywgYnV0IHRoZSBwcm9wb3NhbCBoZWFkZXIgZG9l cyBzcGVjaWZ5IGhvdyBtYW55IHRyYW5zZm9ybSBwYXlsb2FkcyBhcmUgaW5jbHVkZWQgYXMg c3ViLXBheWxvYWRzLiBXaHk/DQ1UaGUgc3lzdGVtIG9mIHN1Yi1wYXlsb2FkcyBzaG91bGQg YmUgZG9jdW1lbnRlZCBtb3JlIGNsZWFybHkuIFdlIHdvdWxkIHN1Z2dlc3QgdGhhdCB0aGUg YGBuZXh0IGhlYWRlcicnIGZpZWxkIGJlIGNoYW5nZWQgaW50byBhIGBgdGhpcyBoZWFkZXIn JyBmaWVsZC4gVGhhdCB3b3VsZCBjZXJ0YWlubHkgbWFrZSBhIGxvdCBvZiB0aGluZ3Mgc2lt cGxlci4gDQ1UaGUgY29uZnVzaW9uIG92ZXIgdGhlIHN1Yi1wYXlsb2FkcyBhbHNvIGxlYWRz IHRvIGEgc2Vjb25kIGNvbmZ1c2lvbi4gUHJlc3VtYWJseSBhIENlcnRpZmljYXRlIFJlcXVl c3QgcGF5bG9hZCBtYXkgbm90IGJlIGluc2VydGVkIGJldHdlZW4gdHdvIFByb3Bvc2FsIHBh eWxvYWRzLCBhbHRob3VnaCB0aGlzIGlzIG5vdCBtYWRlIGNsZWFyLiBJZiBhIENlcnRpZmlj YXRlIFJlcXVlc3QgcGF5bG9hZCB3YXMgaW5zZXJ0ZWQgYmVmb3JlIHRoZSBmaXJzdCBwcm9w b3NhbCwgdGhlIHJlY2lwaWVudCB3b3VsZCBoYXZlIG5vIHdheSBvZiBpZGVudGlmeWluZyB0 aGF0IHBheWxvYWQgYXMgYSBDZXJ0aWZpY2F0ZSBSZXF1ZXN0IHBheWxvYWQsIGFuZCB3b3Vs ZCBpbnRlcnByZXQgaXQgYXMgYSBQcm9wb3NhbC4gVGhlIGZhY3QgdGhhdCB0aGUgQ2VydGlm aWNhdGUgUmVxdWVzdCBQYXlsb2FkIHNlY3Rpb24gc3BlY2lmaWVzIHRoYXQgaXQgbXVzdCBi ZSBhY2NlcHRlZCBhdCBhbnkgcG9pbnQgZHVyaW5nIHRoZSBleGNoYW5nZSBvbmx5IGFkZHMg dG8gdGhlIGNvbmZ1c2lvbi4NDQ1cc2VjdGlvbntDb21tZW50cyBvbiB0aGUgZG9jdW1lbnRh dGlvbn0NVGhlIGRlc2NyaXB0aW9uIG9mIElTQUtNUCBpcyBub3QgdmVyeSBjbGVhci4gV2Ug aGFkIGdyZWF0IHRyb3VibGUgdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50aW9ucyBvZiB0aGUg bXVjaCBvZiB0aGUgZGVzY3JpcHRpb24uDQ1cYmVnaW57ZW51bWVyYXRlfQ0NXGl0ZW0gVGhl IGRvY3VtZW50IG9mdGVuIGNvbnRhaW5zIHJlcGVhdGVkIGluc3RhbmNlcyBvZiB0aGUgc2Ft ZSB0ZXh0LCBvciB2ZXJ5IHNpbWlsYXIgdGV4dHMuIFRoaXMgbWFrZXMgdGhlIHRleHQgdW5u ZWNlc3NhcmlseSBsb25nLCBhbmQgaGFyZCB0byByZWFkLiBGb3IgZXhhbXBsZSwgaW4gc2Vj dGlvbiA1LjIgdGhlIGxpc3Qgb2YgY2hlY2tpbmcgYWN0aW9ucyBhbmQgcG9zc2libGUgbG9n Z2luZyBhbmQgbm90aWZpY2F0aW9ucyBjb3VsZCBiZSBkZXNjcmliZWQgbXVjaCBtb3JlIHN1 Y2NpbmN0bHkuDQ1caXRlbSBTZWN0aW9uIDIuNS4zIGltcG9zZXMgc29tZSByZXF1aXJlbWVu dHMgb24gdGhlIGNvb2tpZXMuIEl0IGNvbnRpbnVlcyB0byBzdWdnZXN0IGEgbWV0aG9kIG9m IGdlbmVyYXRpbmcgdGhlbSwgYW5kIHRoZW4gcmVxdWlyZXMgY2VydGFpbiBmZWF0dXJlcyB0 byBiZSB1c2VkIGluIHRoaXMgbWV0aG9kLiBUaGUgdGV4dCBzaG91bGQgYmUgY2xlYXIgYXMg dG8gd2hldGhlciB0aGUgbWV0aG9kIGlzIGEgc3VnZ2VzdGlvbiAoaW4gd2hpY2ggdGhlIHdv cmQgYGBNVVNUJycgc2hvdWxkIG5vdCBiZSB1c2VkKSBvciB3aGV0aGVyIGl0IGlzIHBhcnQg b2YgdGhlIHN0YW5kYXJkLg0NXGl0ZW0gU2VjdGlvbiA1LjIgc3BlY2lmaWVzIGhvdyB0byBz dGFydCBhbiBJU0FLTVAgZXhjaGFuZ2UsIGJ1dCBjbGFpbXMgdG8gc3BlY2lmeSBob3cgdG8g c2VuZCBhbiBJU0FLTVAgbWVzc2FnZS4gSWYgbmV3IGNvb2tpZXMgYXJlIGNyZWF0ZWQgZm9y IGVhY2ggbWVzc2FnZSwgdGhlIHN5c3RlbSB3aWxsIG9idmlvdXNseSBmYWlsLiBUaGUgZGVz Y3JpcHRpb24gc2hvdWxkIGJlIGZpeGVkLg0gDVxpdGVtIFxjaXRlW3NlY3Rpb24gMy4xMV17 UkZDMjQwOH0gZGVmaW5lcyB0aGUgSGFzaCBQYXlsb2FkLCB3aGljaCBpcyB1c2VkIHRvIHZl cmlmeSB0aGUgaW50ZWdyaXR5IGFuZCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgZGF0YSBpbiB0 aGUgSVNBS01QIG1lc3NhZ2UuIFRoZSBkYXRhIGlzIGRlc2NyaWJlZCBhcyBiZWluZyB0aGUg cmVzdWx0IG9mIGEgaGFzaCBmdW5jdGlvbiBhcHBsaWVkIHRvIHRoZSBtZXNzYWdlOyB0aGlz IHByb3ZpZGVzIG5vIGludGVncml0eSBvciBhdXRoZW50aWNhdGlvbi4gUHJlc3VtYWJseSB0 aGlzIHBheWxvYWQgY29udGFpbnMgYSBNQUMsIGluIHdoaWNoIGNhc2UgdGhlIG5hbWUgYGBI YXNoIFBheWxvYWQnJyAoYXMgd2VsbCBhcyB0aGUgYGBIYXNoIERhdGEnJyBmaWVsZCBuYW1l KSBpcyBhIG1pc25vbWVyLiANDVxpdGVtIFBhZ2UgNDUgc3RhdGVzIHRoYXQgdGhlIG9yZGVy IG9mIHBheWxvYWRzIHdpdGhpbiBhIG1lc3NhZ2UgaXMgbm90IG1hbmRhdGVkLiBQYWdlIDQ2 IHN0YXRlcyB0aGF0IHRoZSBIRFIgZXhjaGFuZ2UgdHlwZSBkZWZpbmVzIHRoZSBwYXlsb2Fk IG9yZGVyaW5ncy4gVGhpcyBpcyBhIGNvbnRyYWRpY3Rpb24uDQ1caXRlbSBTZWN0aW9uIDUu MSBzcGVjaWZpZXMgdGhlIGdlbmVyaWMgcHJvY2Vzc2luZyBvZiBzZW5kaW5nIGFuIElTQUtN UCBtZXNzYWdlLiBUaGUgZGVzY3JpcHRpb24gbWV0aG9kIHVzZWQgdG8gc3BlY2lmeSB0aGUg YWxnb3JpdGhtIGlzIGFtYmlndW91cywgYW5kIHByb2JhYmx5IGV2ZW4gd3JvbmcuIEl0IGlz IG5vdCBjbGVhciB3aGVuIGV4YWN0bHkgc3RlcCA0IGlzIGVudGVyZWQuIFN0cmljdGx5IHNw ZWFraW5nLCBpbiBzdGVwIDIgdGhlIG1lc3NhZ2UgaXMgcmVzZW50IGFuZCB0aGUgY291bnRl ciBpcyBkZWNyZW1lbnRlZC4gTGV0IHVzIHN1cHBvc2UgaXQgcmVhY2hlcyAwLiBTdGVwIDMg aXMgbm93IGV4ZWN1dGVkIGltbWVkaWF0ZWx5LCB3aGljaCBsb2dzIHRoZSBSRVRSWSBMSU1J VCBSRUFDSEVEIGV2ZW50IGluIHRoZSBsb2cgYmVmb3JlIHRoZSBvdGhlciBzaWRlIGhhcyBo YWQgYSBjaGFuY2UgdG8gcmVzcG9uZCB0byB0aGUgbGFzdCByZXNlbmQuIEFzc3VtaW5nIHN0 ZXAgNCBpcyBleGVjdXRlZCBpbW1lZGlhdGVseSBhZnRlciBzdGVwIDMsIHRoZSBsYXN0IHJl c2VuZCBvZiB0aGUgcGFja2V0IHdpbGwgbmV2ZXIgYmUgYW5zd2VyZWQsIGFuZCBpcyBpbiB2 YWluLiBUaGlzIGlzIGNsZWFybHkgbm90IHRoZSBpbnRlbnRpb24gb2YgdGhlIGRlc2lnbmVy cy4gVGhlIGRlc2NyaXB0aW9uIG9mIHRoZSByZXNlbmQgbWVjaGFuaXNtIHNob3VsZCBiZSBj bGFyaWZpZWQuDQ1QcmVzdW1hYmx5IHRoZSByZXNlbmQgbWVjaGFuaXNtIGlzIGRpc2FibGVk IGFzIHNvb24gYXMgYSB2YWxpZCByZXBseSBpcyByZWNlaXZlZC4NDVxpdGVtIEluIHNlY3Rp b24gNS4yLCB0aGUgcmVjaXBpZW50IGlzIGV4cGVjdGVkIHRvIHZlcmlmeSBib3RoIGNvb2tp ZXMuIEFzIHRoZSByZWNpcGllbnQgaGFzIG9ubHkgaGlzIG93biBjb29raWUtZ2VuZXJhdGlv biBrZXksIGhlIGNhbm5vdCB2ZXJpZnkgdGhlIGNvb2tpZSBvZiB0aGUgc2VuZGVyIG9mIHRo ZSBtZXNzYWdlLiANDVxpdGVtIFNlY3Rpb24gNS4xMyByZXF1aXJlcyB0aGUgbm9uY2UgdmFs dWUgdGhhdCBhIHBhcnR5IGdlbmVyYXRlcyB0byBiZSB1bmlxdWUuIFRoZSBzdGFuZGFyZCBz aG91bGQgc3BlY2lmeSB0aGUgc2V0IHdpdGhpbiB3aGljaCB0aGUgbm9uY2UgaGFzIHRvIGJl IHVuaXF1ZS4NDVxpdGVtIERhdGEgYXR0cmlidXRlcyBhcmUgb25seSBwcmVzZW50IGluIGEg VHJhbnNmb3JtIHBheWxvYWQuIFRoZSBJUHNlYyBET0kgZGVmaW5lcyBzZXZlcmFsIGRhdGEg YXR0cmlidXRlcyB0aGF0IGFwcGx5IHRvIHRoZSB2YXJpb3VzIGxldmVscy4gU29tZSBhdHRy aWJ1dGVzIGFwcGx5IHRvIHRoZSBlbnRpcmUgU0EuIEFuIFNBIGNhbiBjb250YWluIHNldmVy YWwgcHJvcG9zYWxzLCBhbmQgYSBwcm9wb3NhbCBjYW4gY29udGFpbiBzZXZlcmFsIHRyYW5z Zm9ybXMuIFNob3VsZCB0aGUgU0Etd2lkZSBhdHRyaWJ1dGVzIGJlIGluIHRoZSBmaXJzdCB0 cmFuc2Zvcm0sIGluIGVhY2ggb2YgdGhlIHRyYW5zZm9ybXMsIG9yIGVsc2V3aGVyZT8gSG93 IHNob3VsZCB0aGUgdmFyaW91cyBwbGFjaW5ncyBvZiBhdHRyaWJ1dGVzIGJlIGludGVycHJl dGVkPw0NXGVuZHtlbnVtZXJhdGV9DQ0NXHNlY3Rpb257U2VjdXJpdHkgY29tbWVudHN9DVdl IGZvdW5kIHNldmVyYWwgY2FzZXMgaW4gd2hpY2ggdGhlIHNlY3VyaXR5IG9mIHRoZSBjb25z dHJ1Y3Rpb25zIGlzIHF1ZXN0aW9uYWJsZS4gQXMgdGhlIElTQUtNUCBpcyBhIHZlcnkgZ2Vu ZXJhbCBzdHJ1Y3R1cmUgZG9jdW1lbnQsIGl0IGlzIG9mdGVuIHVuY2xlYXIgd2hldGhlciB0 aGlzIHdpbGwgcmVzdWx0IGluIHdlYWtuZXNzZXMgaW4gYWN0dWFsIHNwZWNpZmljIGNhc2Vz IGluIHdoaWNoIElTQUtNUCBpcyB1c2VkLg0NXGJlZ2lue2VudW1lcmF0ZX0NXGl0ZW0gSVNB S01QIGFsbG93cyBncmVhdCBsYXRpdHVkZSB0byB0aGUgcGFydGljaXBhbnRzIGluIHRoZSBl eGFjdCBtZXNzYWdlcyB0aGF0IGFyZSBzZW50IGFuZCB0aGUgZXhhY3QgcHJvY2Vzc2luZyB0 aGF0IGlzIGRvbmUuIFRoaXMgbWFrZXMgaXQgZXh0cmVtZWx5IGhhcmQgdG8gZ2l2ZSBhbnkg cmVhc29uYWJsZSBzdGF0ZW1lbnQgYWJvdXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgYWNo aWV2ZWQgYnkgdGhlIHByb3RvY29scy4gVGhlIGF1dGhvcnMgZG8gbm90IGZlZWwgdGhleSBo YXZlIGEgZ29vZCBvdmVydmlldyBvZiBhbGwgdGhlIGRpZmZlcmVudCB2YXJpYXRpb25zIHRo YXQgYXJlIGFsbG93ZWQgYnkgSVNBS01QLiBUaGlzIG1ha2VzIGEgZ29vZCBzZWN1cml0eSBh bmFseXNpcyBleHRyZW1lbHkgaGFyZCB0byBkby4NIA1caXRlbSBTZWN0aW9uIDUuMSBzcGVj aWZpZXMgdGhlIHJlc2VuZCBmdW5jdGlvbmFsaXR5LiBXaGF0IGlzIG5vdCBjbGVhciBpcyBo b3cgdGhlIHJlY2VpdmVyIHJlc3BvbmRzIHRvIG11bHRpcGxlIGNvcGllcyBvZiB0aGUgc2Ft ZSBtZXNzYWdlLiBJZGVhbGx5LCB0aGUgaW1wbGVtZW50YXRpb24gc2hvdWxkIHZlcmlmeSB0 aGF0IGFsbCBjb3BpZXMgaXQgcmVjZWl2ZXMgYXJlIGlkZW50aWNhbCwgYW5kIHJlc2VuZCBp ZGVudGljYWwgY29waWVzIG9mIHRoZSBmaXJzdCByZXBseSB0aGF0IGl0IHNlbnQuIA0NQSBs ZXNzIGNhcmVmdWwgaW1wbGVtZW50YXRpb24gbWlnaHQgcmUtcHJvY2VzcyB0aGUgaW5jb21p bmcgbWVzc2FnZS4gVGhpcyBvcGVucyB1cCB2YXJpb3VzIG1vZGVzIG9mIGF0dGFjay4gRm9y IGV4YW1wbGUsIGluIHRoZSBpZGVudGl0eSBwcm90ZWN0aW9uIGV4Y2hhbmdlIGFuIGF0dGFj a2VyIGNvdWxkIHJlc2VuZCB0aGUgZm91cnRoIG1lc3NhZ2UgdG8gdGhlIGluaXRpYXRvciwg YW5kIGNvbGxlY3QgYXV0aGVudGljYXRpb25zIG9uIG1hbnkgY2hvc2VuIG1lc3NhZ2VzIGJ5 IHZhcnlpbmcgdGhlIG5vbmNlLiAoV2UgYXJlIGlnbm9yaW5nIHRoZSBlbmNyeXB0aW9uIGZv ciB0aGUgbW9tZW50OyBub3RlIHRoYXQgdGhlIGVuY3J5cHRpb24gbWlnaHQgYmUgd2VhayBv ciBub25leGlzdGVudC4pIEV2ZW4gbW9yZSB0aHJlYXRlbmluZywgYnkgY2hhbmdpbmcgdGhl IEtFIHBheWxvYWQgdGhlIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gdXNlIHN1YnRsZSBp bnRlcmFjdGlvbnMgdG8gZmluZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUga2V5Lg0NQW4gYXR0 YWNrIGFsb25nIHRoZSBmb2xsb3dpbmcgbGluZXMgbWlnaHQgYmUgcG9zc2libGUuIEFuIGF0 dGFja2VyIGVhdmVzZHJvcHMgb24gYW4gaWRlbnRpdHkgcHJvdGVjdGlvbiBleGNoYW5nZSwg YW5kIHRoZW4gcmVzZW5kcyB0aGUgZm91cnRoIG1lc3NhZ2Ugd2l0aCBtb2RpZmllZCBLRSBw YXlsb2Fkcy4gTGV0IHVzIGFzc3VtZSB0aGF0IGEgREgga2V5IGFncmVlbWVudCBwcm90b2Nv bCBtb2R1bG8gJHAkIGlzIHVzZWQgd2l0aCBhIHN1Ymdyb3VwIG9mIHNpemUgJHF8KHAtMSkk LCBhbmQgdGhhdCAkcC0xJCBoYXMgc2V2ZXJhbCBvdGhlciBzbWFsbCBkaXZpc29ycy4gKEV2 ZW4gdGhvdWdoIHRoaXMgc3BlY2lmaWMgY2hvaWNlIG9mIERIIGdyb3VwIG1pZ2h0IHNlZW0g dW5mb3J0dW5hdGUsIGl0IGNvdWxkIGJlIHVzZWQgaW4gYSBwcmFjdGljYWwgYW5kIHNlY3Vy ZSBrZXkgZXhjaGFuZ2UgYWxnb3JpdGhtLikgVGhlIGF0dGFja2VyIGNhbiBub3cgcmVjb3Zl ciB0aGUgREggc2VjcmV0IG9mIHRoZSBpbml0aWF0b3IgYnkgcmVwZWF0ZWRseSBzZW5kaW5n IEtFIHBheWxvYWRzIHRoYXQgY29udGFpbiBlbGVtZW50cyBvZiBhIGxvdyBvcmRlciBhbmQg Y2hlY2tpbmcgd2hpY2ggb2YgdGhlIGxpbWl0ZWQgc2V0IG9mIHBvc3NpYmxlIGtleXMgaXMg YmVpbmcgdXNlZCBpbiB0aGUgZW5jcnlwdGlvbi4gVGhpcyByZXZlYWxzIHRoZSBpbml0aWF0 b3IncyBESCBzZWNyZXQgbW9kdWxvIHRoZSBvcmRlciBvZiB0aGUgZWxlbWVudCBzZW50IGlu IHRoZSBLRSBwYXlsb2FkLiBDb21iaW5pbmcgc2V2ZXJhbCBvZiB0aGVzZSB0cmllcyByZXZl YWxzIHRoZSBlbnRpcmUgREggc2VjcmV0LiBPbmNlIHRoZSBESCBzZWNyZXQgb2YgdGhlIGlu aXRpYXRvciBpcyBrbm93biwgdGhlIGF0dGFja2VyIHJlc2VuZHMgdGhlIG9yaWdpbmFsIGZv dXJ0aCBtZXNzYWdlLiBUaGlzIHJldHVybnMgYm90aCBwYXJ0aWVzIHRvIHRoZSBzYW1lIHN0 YXRlIHRoZXkgaGFkIGJlZm9yZSB0aGUgYXR0YWNrZXIgaW50ZXJmZXJlZC4gQW55IHN1YnNl cXVlbnQgZXhjaGFuZ2UgY29udGludWVzIGFzIG5vcm1hbCwgYnV0IHRoZSBhdHRhY2tlciBo YXMgdGhlIGtleSwgd2hpY2ggY2xlYXJseSB2aW9sYXRlcyB0aGUgaW50ZW50aW9uIG9mIHRo ZSBwcm90b2NvbC4NDVRoaXMgc2hvd3MgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gc3BlY2lm eSBob3cgZWFjaCBwYXJ0eSBzaG91bGQgcmVhY3QgdG8gYSByZXBlYXQgb2YgYSBtZXNzYWdl IGluIGFuIGV4Y2hhbmdlLiBXZSBoYXZlIG5vdCBhbmFseXplZCBvdGhlciBwcm90b2NvbHMg Zm9yIHNpbWlsYXIgd2Vha25lc3NlcywgYnV0IGl0IHNlZW1zIGNsZWFyIHRoYXQgYW55IHNv bHV0aW9uIHRoYXQgcmVwcm9jZXNzZXMgYSBwcm90b2NvbCBzdGVwIGNhbiBpbnRyb2R1Y2Ug YWRkaXRpb25hbCB3ZWFrbmVzc2VzLiBUaGVyZWZvcmUsIHRoZSByZXRyYW5zbWlzc2lvbiBz eXN0ZW0gYW5kIGhhbmRsaW5nIG9mIGR1cGxpY2F0ZSBtZXNzYWdlcyBzaG91bGQgYXZvaWQg cmVwcm9jZXNzaW5nIG1lc3NhZ2VzLg0NUmVqZWN0aW5nIGNvcGllcyBvZiBhIG1lc3NhZ2Ug dGhhdCBhcmUgbm90IGlkZW50aWNhbCB0byB0aGUgZmlyc3QgY29weSByZWNlaXZlZCBkb2Vz IG5vdCBwcm92aWRlIGZvciByZWNvdmVyeSBmcm9tIGEgYm9ndXMgbWVzc2FnZS4gVGhlcmUg aXMgbGl0dGxlIHNlY3VyaXR5IHJpc2sgaW4gbm90IHByb3ZpZGluZyBmb3IgdGhpcyByZWNv dmVyeS4gVGhlIGV4Y2hhbmdlIHdpbGwgaGF2ZSB0byBiZSBhYmFuZG9uZWQgYW5kIGEgbmV3 IG9uZSBzdGFydGVkLiBJbiBnZW5lcmFsLCB0aGVyZSBpcyBubyBtZXRob2Qgb2YgZW5zdXJp bmcgdGhlIGNvbXBsZXRpb24gb2YgYW4gZXhjaGFuZ2UgaW4gdGhlIHByZXNlbmNlIG9mIGFu IGFjdGl2ZSBhdHRhY2tlci4gSXQgaXMgYWx3YXlzIHBvc3NpYmxlIGZvciB0aGUgYXR0YWNr ZXIgdG8gZmxpcCBzb21lIGJpdHMgaW4gZWFjaCBtZXNzYWdlLCBpbiB3aGljaCBjYXNlIGFu eSBleGNoYW5nZSB3aWxsIGZhaWwuDQ1caXRlbSBTZWN0aW9uIDQuNiBkZWZpbmVzIHRoZSBh dXRoZW50aWNhdGlvbi1vbmx5IGV4Y2hhbmdlIHRoYXQgcHJvdmlkZXMgYXV0aGVudGljYXRp b24gb2YgdGhlIG90aGVyIHBhcnR5IGJ1dCBkb2VzIG5vdCBleGNoYW5nZSBrZXlzLiBUaGVy ZSBpcyBubyBkaXJlY3QgdXNlIGZvciB0aGlzIHByb3RvY29sLiBBdCB0aGUgZW5kIG9mIHRo ZSBleGNoYW5nZSBib3RoIHBhcnRpZXMga25vdyB3aG8gdGhleSB3ZXJlIHRhbGtpbmcgdG8s IGJ1dCBieSBpdHNlbGYgdGhhdCBkb2VzIG5vdCBwcm92aWRlIG11Y2ggaW5mb3JtYXRpb24u IA0NV2UgYXNzdW1lIHRoaXMgcHJvdG9jb2wgaXMgbWVhbnQgdG8gYmUgdXNlZCB0byBhdXRo ZW50aWNhdGUgdGhlIG90aGVyIHBhcnR5IHdoZW4gYSBzZWN1cmUgY2hhbm5lbCBoYXMgYWxy ZWFkeSBiZWVuIGVzdGFibGlzaGVkIHdpdGhvdXQgYXV0aGVudGljYXRpb24uIFRoaXMgZG9l cyBub3Qgd29yaywgYXMgdGhlIG90aGVyIHNpZGUgY2FuIHBlcmZvcm0gYSBtYW4taW4tdGhl LW1pZGRsZSBhdHRhY2sgYWdhaW5zdCB0aGUgYXV0aGVudGljYXRpb24tb25seSBwcm90b2Nv bC4gVGhpcyBpcyBpbiBmYWN0IGEgZ2VuZXJhbCBwcm9wZXJ0eSBvZiB0aGUgZm91ciBleGNo YW5nZXMgZGVmaW5lZCBpbiBJU0FLTVAuIEFsbCBvZiB0aGVtIGNhbiBiZSBjb21wbGV0ZWQg YnkgYSBtYW4gaW4gdGhlIG1pZGRsZS4gSG93ZXZlciwgdGhlIG1hbiBpbiB0aGUgbWlkZGxl IGRvZXMgbm90IGxlYXJuIHRoZSBrZXkgdGhhdCBpcyBlc3RhYmxpc2hlZCBieSB0aGUgZXhj aGFuZ2UuIEFzIHRoZSBhdXRoZW50aWNhdGlvbi1vbmx5IHByb3RvY29sIGRvZXMgbm90IGVz dGFibGlzaCBhIGtleSwgYW5kIGRvZXMgbm90IGxpbmsgdGhlIGF1dGhlbnRpY2F0aW9uIHRv IGFuIGV4aXN0aW5nIGtleSwgbm9uZSBvZiB0aGUgcGFydGljaXBhbnRzIGluIHRoZSBwcm90 b2NvbCBpcyBtdWNoIHdpc2VyIGF0IHRoZSBlbmQuDQ1XZSBmYWlsIHRvIHNlZSBhbnkgdXNl IGZvciB0aGlzIHByb3RvY29sLg0NXGl0ZW0gVGhlIElkZW50aXR5IFByb3RlY3Rpb24gRXhj aGFuZ2Ugb2Ygc2VjdGlvbiA0LjUgaXMgdnVsbmVyYWJsZSB0byBhbiBhY3RpdmUgYXR0YWNr LiBUaGUgSW5pdGlhdG9yIHNlbmRzIGl0cyBpZGVudGl0eSBiZWZvcmUgaGF2aW5nIGF1dGhl bnRpY2F0ZWQgdGhlIG90aGVyIHBhcnR5LiBBbiBhY3RpdmUgYXR0YWNrZXIgY2FuIHByZXRl bmQgdG8gYmUgdGhlIHJlc3BvbmRlciwgYW5kIGNvbGxlY3QgdGhlIEluaXRpYXRvcidzIGlk ZW50aXR5IGJlZm9yZSBhYmFuZG9uaW5nIHRoZSBwcm90b2NvbC4gVGhlIEluaXRpYXRvciBo YXMgbGl0dGxlIGNob2ljZSBidXQgdG8gdHJ5IGFnYWluIHRvIG5lZ290aWF0ZSB0aGUgU0Eu IElmIHRoZSBhdHRhY2tlciBkb2VzIG5vdCBpbnRlcmZlcmUgdGhpcyB3aWxsIGNvbXBsZXRl LCBidXQgdGhlIGF0dGFja2VyIGhhcyByZXRyaWV2ZWQgdGhlIElEaWkgdmFsdWUuDQ1Ob3Rl IHRoYXQgdGhpcyB0eXBlIG9mIHdlYWtuZXNzIGNhbiBiZSBhdm9pZGVkIGJ5IHRoZSB1c2Ug b2YgcHVibGljLWtleSBlbmNyeXB0aW9uLiBUaGUgaW5pdGlhdG9yIGNhbiBzZW5kIGhpcyBv d24gaWRlbnRpdHkgZW5jcnlwdGVkIHdpdGggdGhlIHB1YmxpYyBrZXkgb2YgdGhlIHJlc3Bv bmRlci4gRm9yIHRoaXMgdG8gd29yaywgdGhlIGluaXRpYXRvciBoYXMgdG8gcmV0cmlldmUg dGhlIHJlc3BvbmRlcidzIHB1YmxpYyBrZXkgaW4gc29tZSB3YXkuIEEgY2VudHJhbCBwdWJs aWMta2V5IGRpcmVjdG9yeSBjYW4gcHJvdmlkZSB0aGlzIHNlcnZpY2UsIHdpdGhvdXQgcmV2 ZWFsaW5nIG1vcmUgaW5mb3JtYXRpb24gdG8gYW4gYXR0YWNrZXIgdGhhbiB0aGF0IHRoZSBp bml0aWF0b3IgaXMgcmV0cmlldmluZyBzb21lYm9keSdzIGtleS4gDQ1cZW5ke2VudW1lcmF0 ZX0NDVxzZWN0aW9ue0Z1bmN0aW9uYWwgY29tbWVudHN9DVRoZSBmb2xsb3dpbmcgY29tbWVu dHMgYXJlIG1vc3RseSBvbiB0aGUgZnVuY3Rpb25hbGl0eSBvZiBJU0FLTVAuDQ1cYmVnaW57 ZW51bWVyYXRlfQ0NXGl0ZW0gQ29va2llcyBhcmUgNjQgYml0cywgYW5kIGFyZSB1c2VkIHRv IGlkZW50aWZ5IHRoZSBJU0FLTVAgU0EgYW5kIHRoZSBuZWdvdGlhdGlvbiB0aGVyZW9mLiBU aGVyZSBpcyBhIG5vbi1uZWdsaWdpYmxlIHByb2JhYmlsaXR5IHRoYXQgYSBzZXJ2ZXIgd2ls bCBpc3N1ZSB0aGUgc2FtZSBjb29raWUgdmFsdWUgdHdpY2UuIFdlIGV4cGVjdCB0aGlzIHRv IGhhcHBlbiBhZnRlciBhYm91dCAkMl57MzJ9JCBuZWdvdGlhdGlvbnMuIEFmdGVyICQyXnsy Mn0kIG5lZ290aWF0aW9ucywgdGhlIGNoYW5jZSBvZiBzdWNoIGEgY29sbGlzaW9uIGlzIG9u IHRoZSBvcmRlciBvZiAkMl57LTIwfSQuIFRoaXMgd291bGQgYWxsb3cgYW4gYXR0YWNrZXIg dG8gY3JlYXRlIHR3byBTQSBuZWdvdGlhdGlvbnMgdGhhdCBoYXZlIHRoZSBzYW1lIHNldCBv ZiBjb29raWVzLCBhbmQgdG8gYXR0ZW1wdCB0byBzd2FwIG1lc3NhZ2VzIGJldHdlZW4gdGhl IHR3by4gSXQgaXMgdW5jbGVhciB3aGF0IHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhpcyB3b3Vs ZCBiZTsgdGhhdCBkZXBlbmRzIG9uIHRoZSBkZXRhaWxzIG9mIHRoZSBhY3R1YWwgcHJvdG9j b2wuIEF0IGEgbWluaW11bSwgaXQgc2hvdWxkIGJlIG5vdGVkIGluIHRoZSBJU0FLTVAgZG9j dW1lbnRhdGlvbiB0aGF0IHRoZSBjb29raWVzIGJ5IHRoZW1zZWx2ZXMgZG8gbm90IHByb3Zp ZGUgYSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGV4Y2hhbmdlIGFuZCB0aGF0IGluZGl2 aWR1YWwgcHJvdG9jb2xzIHNob3VsZCBwcm92aWRlIHRoZWlyIG93biByYW5kb20gbm9uY2Vz IHRvIHByb3RlY3QgYWdhaW5zdCB0aGVzZSB0eXBlcyBvZiBhdHRhY2tzLg0NXGl0ZW0gVGhl IHNlcGFyYXRpb24gb2YgZnVuY3Rpb25zIGJldHdlZW4gdGhlIElTQUtNUCAgYW5kIHRoZSBE T0kgaXMgaGFwaGF6YXJkLiBGb3IgZXhhbXBsZSwgdGhlIGZvcm1hdHRpbmcgb2YgdGhlIGtl eSBleGNoYW5nZSBwYXlsb2FkIGlzIGxlZnQgY29tcGxldGVseSBmb3IgdGhlIERPSSB0byBk ZWZpbmUsIGJ1dCBmb3IgdGhlIGlkZW50aWZpY2F0aW9uIHBheWxvYWQgdGhlIElTQUtNUCBy ZXN0cmljdHMgdGhlIERPSSBhbmQgZm9yY2VzIGEgY2VydGFpbiBmb3JtYXR0aW5nIHN0cnVj dHVyZS4gSWYgdGhlIElTQUtNUCBhbmQgRE9JIGFyZSB0byBiZSBzZXBhcmF0ZWQsIHRoZW4g YW55dGhpbmcgdGhhdCBkb2VzIG5vdCBkaXJlY3RseSBhZmZlY3QgdGhlIElTQUtNUCBzaG91 bGQgYmUgbGVmdCB0byB0aGUgRE9JLg0NXGl0ZW0gVGhlIENlcnRpZmljYXRlIFJlcXVlc3Qg UGF5bG9hZCBpcyB1c2VkIHRvIHJlcXVlc3QgYSBjZXJ0aWZpY2F0ZSBmcm9tIHRoZSBvdGhl ciBwYXJ0eS4gSXQgYWxsb3dzIHRoZSByZXF1ZXN0b3IgdG8gc3BlY2lmeSBhIHNpbmdsZSBD QSB0aGF0IGl0IHdpbGwgYWNjZXB0LiBUaGUgcmVzcG9uZGVyIG11c3Qgc2VuZCBgYGl0cyBj ZXJ0aWZpY2F0ZSBiYXNlZCBvbiB0aGUgdmFsdWUgY29udGFpbmVkIGluIHRoZSBwYXlsb2Fk LicnIEluIG1hbnkgcHJhY3RpY2FsIHN5c3RlbXMsIGEgc2luZ2xlIHJlc3BvbmRlciBtaWdo dCBoYXZlIG1hbnkgY2VydGlmaWNhdGVzLiBJdCBpcyB1bmNsZWFyIHdoZXRoZXIgdGhlIHJl c3BvbmRlciBzaG91bGQgc2VuZCBvbmx5IG9uZSBzdWl0YWJsZSBjZXJ0aWZpY2F0ZSwgb3Ig YWxsIHN1aXRhYmxlIGNlcnRpZmljYXRlcy4gVGhpcyBpc3N1ZSBzaG91bGQgYmUgY2xhcmlm aWVkIGluIHRoZSBzdGFuZGFyZC4NDVxpdGVtIFRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUg YSB3YXkgZm9yIG9uZSBvZiB0aGUgcGFydGllcyB0byBhc2sgZm9yIGEgY2VydGlmaWNhdGUg aXNzdWVkIGJ5IGFueSBvbmUgb2YgYSBsaXN0IG9mIENBcy4gVGhpcyBjb3VsZCBiZSB2ZXJ5 IHVzZWZ1bC4gVGhlcmUgYXJlIGN1cnJlbnRseSBtYW55IGNvbXBldGluZyBDQXMgZm9yIFgu NTA5djMgY2VydGlmaWNhdGVzLiBBIHNwZWNpZmljIG1hY2hpbmUgbWlnaHQgdmVyeSB3ZWxs IHRydXN0IGEgc3Vic2V0IG9mIHRoZW0uIEluIHRoYXQgY2FzZSBpdCB3b3VsZCBhY2NlcHQg YSBjZXJ0aWZpY2F0ZSBzaWduZWQgYnkgYW55IG9uZSBvZiBhIGxpc3Qgb2YgQ0FzLiBJbiBJ U0FLTVAsIHNlbmRpbmcgYSBsaXN0IG9mIENBcyBpcyBpbnRlcnByZXRlZCBhcyBhc2tpbmcg Zm9yIGFsbCBjZXJ0aWZpY2F0ZXMgZnJvbSB0aGVzZSBTQXMgKHNlZSBzZWN0aW9uIDMuMTAp Lg0gDVxpdGVtIFNlY3Rpb24gNC41IGRlZmluZXMgdGhlIElkZW50aXR5IFByb3RlY3Rpb24g RXhjaGFuZ2UuIFRoZSBub25jZXMgaW4gdGhpcyBwcm90b2NvbCBjb3VsZCBhbHNvIGJlIHNl bnQgaW4gdGhlIGZpcnN0IHR3byBtZXNzYWdlcywgbWFraW5nIHRoaXMgcHJvdG9jb2wgbW9y ZSBsaWtlIHRoZSBiYXNlIGV4Y2hhbmdlLiBGdXJ0aGVybW9yZSwgdGhlIGV4Y2hhbmdlIGNh biBiZSBzaG9ydGVuZWQgYnkgdHdvIG1lc3NhZ2VzLiANDVRoZSBvcmRlciBvZiB0aGUgdGhp cmQgYW5kIGZvdXJ0aCBtZXNzYWdlIGFyZSBub3QgaW1wb3J0YW50LiBJZiB0aGUgb3JkZXIg b2YgdGhlc2UgdHdvIG1lc3NhZ2VzIGlzIHN3YXBwZWQsIHRoZW4gZWFjaCBvZiB0aGVtIGNh biBiZSBtZXJnZWQgd2l0aCBhbiBhZGphY2VudCBtZXNzYWdlIGFuZCBzZW50IGluIGEgc2lu Z2xlIHBhY2tldC4gVGhpcyB3b3VsZCBzYXZlIGEgZnVsbCByb3VuZC10cmlwIHRpbWUgaW4g dGhlIG5lZ290aWF0aW9ucyB3aXRob3V0IGxvc3Mgb2YgZnVuY3Rpb25hbGl0eS4gDQ1caXRl bSBTZWN0aW9uIDQuNyBkZWZpbmVzIHRoZSBhZ2dyZXNzaXZlIGV4Y2hhbmdlLiBJdCBzdGF0 ZXMgdGhhdCB0aGUgaW5pdGlhbCBTQSBwYXlsb2FkIGNhbiBvbmx5IGNvbnRhaW4gb25lIHBy b3Bvc2FsIGFuZCBvbmUgdHJhbnNmb3JtLiBUaGlzIGRvZXMgbm90IHNlZW0gdG8gYmUgYSBu ZWNlc3NhcnkgcmVzdHJpY3Rpb24uIEZpcnN0IG9mIGFsbCwgdHdvIHByb3Bvc2FsIHBheWxv YWRzIHdpdGggdGhlIHNhbWUgcHJvcG9zYWwgbnVtYmVyIGNvbnN0aXR1dGUgYSBzaW5nbGUg cHJvcG9zYWwuIElmIHRoZSBjb25jZXJuIGlzIHRoYXQgdGhlIEluaXRpYXRvciBtdXN0IGtu b3cgdGhlIGZpbmFsIHRyYW5zZm9ybXMgdG8gYmUgdXNlZCB3aGlsZSBzZW5kaW5nIHRoZSBm aXJzdCBtZXNzYWdlLCB0aGVuIHRoZSByZXF1aXJlbWVudCB0aGF0IG9ubHkgb25lIHByb3Bv c2FsIG51bWJlciBpcyB1c2VkIGlzIGVub3VnaC4gDQ1BcyB0aGUgS0UgcGF5bG9hZCBpcyBu b3QgZGVwZW5kZW50IG9uIHRoZSB3YXkgaW4gd2hpY2ggdGhlIGZpbmFsIGtleXMgYXJlIGFj dHVhbGx5IGJlaW5nIHVzZWQsIHdlIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IHRoZSBzaW5n bGUtcHJvcG9zYWwgcmVzdHJpY3Rpb24gaXMgaW4gcGxhY2UuDQ1UaGUgcmVzdHJpY3Rpb24g dG8gYSBzaW5nbGUgdHJhbnNmb3JtIHNlZW1zIHJlZHVuZGFudC4gV2Ugc2VlIG5vIHByb2Js ZW1zIHdpdGggYSBzaW5nbGUgcHJvcG9zYWwgdGhhdCBjb250YWlucyBtdWx0aXBsZSB0cmFu c2Zvcm1zLiANDVxpdGVtIFNlY3Rpb24gNS41IGZvcmNlcyB0aGUgU1BJIHRvIGJlIGdlbmVy YXRlZCBwc2V1ZG9yYW5kb21seS4gVGhpcyBpcyBhIG5lZWRsZXNzIHJlc3RyaWN0aW9uIG9u IHRoZSBzZW5kZXIsIGFuZCBzaG91bGQgYmUgcmVtb3ZlZC4gU29tZSBpbXBsZW1lbnRhdGlv bnMgbWlnaHQgd2lzaCB0byB1c2UgdGhlIFNQSSBkaXJlY3RseSBhcyBhIGluZGV4IGludG8g YSB0YWJsZSwgaW4gd2hpY2ggY2FzZSBpdCBjYW5ub3QgYmUgZ2VuZXJhdGVkIHBzZXVkb3Jh bmRvbWx5LiBcY2l0ZVthcHBlbmRpeCBBXXtSRkMyNDAxfSBzdGF0ZXMgdGhhdCB0aGUgU1BJ IGhhcyBvbmx5IGxvY2FsIHNpZ25pZmljYW5jZSwgYW5kIHRoYXQgdGhlIHJlY2lwaWVudCBt YXkgY2hvb3NlIHZhcmlvdXMgd2F5cyB0byBpbnRlcnByZXQgdGhlIFNQSS4gVGhpcyB3b3Vs ZCBzZWVtIHRvIGltcGx5IHRoYXQgdGhlIFNQSSBkb2VzIG5vdCBoYXZlIHRvIGJlIGNob3Nl biByYW5kb21seS4NDVRoZSB1bmlxdWVuZXNzIHJlcXVpcmVtZW50IHNob3VsZCBiZSBkb2N1 bWVudGVkIGZ1cnRoZXI7IGl0IHNob3VsZCBiZSBzcGVjaWZpZWQgd2l0aGluIHdoYXQgc2V0 IG9mIHZhbHVlcyB0aGUgbmV3bHkgY2hvc2VuIFNQSSB2YWx1ZSBoYXMgdG8gYmUgdW5pcXVl Lg0NXGl0ZW0gU2VjdGlvbiA1LjUgYWxsb3dzIHRoZSByZXNwb25kZXIgdG8gc2VuZCBhbiBJ TlZBTElELVBST1RPQ09MLUlEIG5vdGlmaWNhdGlvbiBpbiBjYXNlIGhlIGRvZXMgbm90IGtu b3cgdGhlIHByb3RvY29sIGluIHF1ZXN0aW9uLiBUaGlzIGlzIGxpc3RlZCBhcyBhbiBgYGVy cm9yJycgbm90aWZpY2F0aW9uLCB3aGljaCB3b3VsZCBhdCBsZWFzdCBzdWdnZXN0IHRoYXQg dGhlIGV4Y2hhbmdlIGlzIGFib3J0ZWQuIFdlIHN1Z2dlc3QgdGhhdCB0aGUgcmVzcG9uZGVy IHNpbXBseSBpZ25vcmUgdGhlIHBheWxvYWQsIHRoZSBhc3NvY2lhdGVkIHRyYW5zZm9ybXMs IGFuZCBhbnkgb3RoZXIgcHJvcG9zYWwgcGF5bG9hZHMgd2l0aCB0aGUgc2FtZSBwcm9wb3Nh bCBudW1iZXIuIFVua25vd24gcHJvdG9jb2xzIGNhbiBiZSBzZWVuIGFzIHVuYWNjZXB0YWJs ZSBwcm90b2NvbHMuIElmIHRoZSBzZW5kZXIgaXMgdG8gYmUgaW5mb3JtZWQgb2YgdGhpcyBm YWN0LCB0aGVuIGEgd2FybmluZyBub3RpZmljYXRpb24gc2hvdWxkIGJlIHNlbnQsIG5vdCBh biBlcnJvci4NDVxpdGVtIFZhcmlvdXMgZmVhdHVyZXMsIHN1Y2ggYXMgdGhlIGNvb2tpZXMs IGFyZSBpbmNsdWRlZCB0byBwcmV2ZW50IGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFja3MgYWdh aW5zdCB0aGUgcGFydGljaXBhbnRzLiBBcyBzdGF0ZWQgaW4gXGNpdGVbc2VjdGlvbiAxLjcu MV17UkZDMjQwOH0sIGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFja3MgY2Fubm90IGJlIHByZXZl bnRlZCBjb21wbGV0ZWx5LiBXZSBhcmUgbm90IGNvbnZpbmNlZCB0aGF0IGl0IGlzIGEgZ29v ZCBpZGVhIHRvIGluY3JlYXNlIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBwcm90b2NvbCB0byBw cm92aWRlIGEgcGFydGlhbCBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0uIFRoaXMgd291bGQg cmVxdWlyZSBhbiBhbmFseXNpcyBvZiB0aGUgY29tcGxleGl0eSBvZiB0aGUgdmFyaW91cyBm b3JtcyBvZiBJUC1yZWxhdGVkIGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFja3MgYWdhaW5zdCBj b21wdXRlcnMuIFBhcnRpYWwgY291bnRlcm1lYXN1cmVzIG9ubHkgbWFrZSBzZW5zZSBpZiB0 aGV5IG1ha2UgYXR0YWNrcyBoYXJkZXIgdG8gcGVyZm9ybS4gUHJvdGVjdGluZyBhZ2FpbnN0 IGRpZmZpY3VsdCBhdHRhY2tzIG1ha2VzIG5vIHNlbnNlIGlmIHRoZXJlIGlzIG5vIHByb3Rl Y3Rpb24gYWdhaW5zdCB0aGUgZWFzeSBmb3JtcyBvZiBhdHRhY2suIFRoaXMgcmVtYWlucyBh biBhcmVhIGZvciBmdXJ0aGVyIHN0dWR5Lg0NXGVuZHtlbnVtZXJhdGV9DQ0NXHNlY3Rpb257 R2VuZXJhbCBjb21tZW50c30NDVxiZWdpbntlbnVtZXJhdGV9DQ1caXRlbSBJdCBpcyBpbnRl cmVzdGluZyB0byBub3RlIHRoYXQgXGNpdGVbc2VjdGlvbiAxXXtSRkMyNDA4fSBjbGFpbXMg dGhhdCBzcGxpdHRpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgaW50byB0aGUgSVNBS01QLCBET0ks IGFuZCBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgbWFrZXMgdGhlIHNlY3VyaXR5IGFuYWx5c2lz IG1vcmUgY29tcGxleC4gV2UgZmVlbCB0aGF0IGEgbW9kdWxhcml6YXRpb24gYWxvbmcgd2Vs bC1jaG9zZW4gYm91bmRhcmllcyBjb3VsZCBzaW1wbGlmeSB0aGUgYW5hbHlzaXMgc2lnbmlm aWNhbnRseS4gVW5mb3J0dW5hdGVseSwgdGhlIElTQUtNUCwgRE9JIGFuZCBrZXkgZXhjaGFu Z2UgcHJvdG9jb2wgZG9jdW1lbnQgc3RpbGwgY29udGFpbiBudW1lcm91cyBjcm9zcy1kZXBl bmRlbmNpZXMuDQ1caXRlbSBBbiBleGNoYW5nZSB0eXBlIGRvZXMgbm90IHNwZWNpZnkgdGhl IG9yZGVyIG9mIHRoZSBwYXlsb2FkcyB3aXRoaW4gYSBtZXNzYWdlLiBUaGlzIGlzIG5lZWRs ZXNzIGZsZXhpYmlsaXR5IHRoYXQgb25seSBhZGRzIHRvIHRoZSBjb21wbGV4aXR5IG9mIHRo ZSBzb2Z0d2FyZS4NDVxlbmR7ZW51bWVyYXRlfQ0NXGNoYXB0ZXJ7VGhlIElQc2VjIERPSX1c bGFiZWx7Y2hhcDpJUHNlY0RPSX0NVGhlIElQc2VjIERvbWFpbiBPZiBJbnRlcnByZXRhdGlv biBpcyBnaXZlbiBpbiBcY2l0ZXtSRkMyNDA3fS4gVGhlIERPSSBpcyBtb3N0bHkgY29uY2Vy bmVkIHdpdGggc3BlY2lmeWluZyB0aGUgZXhhY3Qgd2F5IGluIHdoaWNoIHZhcmlvdXMgdmFs dWVzIGFyZSBpbnRlcnByZXRlZDsgbW9zdCBvZiB0aGUgRE9JIGlzIG5vdCBzZWN1cml0eS1j cml0aWNhbC4NDVxzZWN0aW9ue0dlbmVyYWwgY29tbWVudHN9DVxiZWdpbntlbnVtZXJhdGV9 DVxpdGVtIFNlY3Rpb24gNC40LjMgc3BlY2lmaWVzIHRyYW5zZm9ybSBJRHMgdGhhdCBhcmUg YSBraW5kIG9mIGdlbmVyaWMgZ3JvdXAgYmFzZWQgb24gYSBzcGVjaWZpYyBwcmltaXRpdmUu IFRoZSBleGFjdCB1c2Ugb2YgdGhlIHByaW1pdGl2ZSBpcyBmdXJ0aGVyIHNwZWNpZmllZCBi eSBhbiBhdHRyaWJ1dGUuIFRoaXMgZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlLiBUaGUgZW50 aXJlIE1BQyBjb25zdHJ1Y3Rpb24gc2hvdWxkIGJlIHNlZW4gYXMgb25lIGluZGl2aXNpYmxl IHVuaXQuIFRoZXJlIGlzIG5vdGhpbmcgdG8gYmUgZ2FpbmVkIGZyb20gZ3JvdXBpbmcgdGhl bSBpbnRvIHRyYW5zZm9ybS1ncm91cHMgYnkgdGhlaXIgcHJpbWl0aXZlLg0NTm8gc3VjaCBn cm91cGluZyBpcyB1c2VkIGZvciB0aGUgRVNQIGVuY3J5cHRpb24gdHJhbnNmb3Jtcy4gRWFj aCB0cmFuc2Zvcm0gaXMgc3BlY2lmaWVkIGZ1bGx5IGJ5IHRoZSB0cmFuc2Zvcm0gSUQuIFRo ZSBFU1AgYXV0aGVudGljYXRpb24gYWxnb3JpdGhtIGlzIHNwZWNpZmllZCBieSB0aGUgYXR0 cmlidXRlcy4gDQ1XZSB3b3VsZCBzdWdnZXN0IHRoYXQgYSBzaW5nbGUgbWV0aG9kIG9mIHNw ZWNpZnlpbmcgYXV0aGVudGljYXRpb24gdHJhbnNmb3JtcyBpcyB1c2VkIGZvciBib3RoIEFI IGFuZCBFU1AuDQ1caXRlbSBPbiBwYWdlIDE0LCBLUERLIGlzIGxpc3RlZCBhcyBhbiBBdXRo ZW50aWNhdGlvbiBBbGdvcml0aG0uIFRoaXMgaXMgbm90IGEgZnVsbHkgc3BlY2lmaWVkIGFs Z29yaXRobS4gSXQgY2FuIGJlIHVzZWQgYnkgQUggaW4gY29tYmluYXRpb24gd2l0aCB0aGUg QUggdHJhbnNmb3JtIElELCBidXQgaXQgY2Fubm90IGJlIHVzZWQgYnkgRVNQLiBUaGlzIGlz IHdlaXJkLCBhbmQgd2UgaGF2ZSBubyBpZGVhIHdoeSB0aGUgc3RhbmRhcmQgaXMgd3JpdHRl biB0aGlzIHdheS4gV2UgcHJvcG9zZSB0byByZW1vdmUgdGhlIEtQREsgYWxnb3JpdGhtLCBv ciBzcGVjaWZ5IEtQREstTUQ1IGFuZCBLUERLLVNIQSBzZXBhcmF0ZWx5Lg0NXGl0ZW0gVGhl IGRlZmluaXRpb24gb2YgdGhlIFNBIExpZmUgVHlwZSBhbmQgU0EgRHVyYXRpb24gYXR0cmli dXRlcyBpcyB1bmZvcnR1bmF0ZS4gVGhpcyBpbnRyb2R1Y2VzIG9yZGVyLWRlcGVuZGVuY2ll cyBhbmQgZm9yY2VzIHRoZSBwYXJzZXIgdG8gY2Fycnkgc3RhdGUsIGJvdGggb2Ygd2hpY2gg bWFrZSB0aGUgcGFyc2VyIG1vcmUgY29tcGxleC4gSXQgd291bGQgYmUgbXVjaCBzaW1wbGVy IHRvIGNyZWF0ZSB0d28gYXR0cmlidXRlczogU0EtbGlmZXRpbWUtc2Vjb25kcyBhbmQgU0Et bGlmZXRpbWUta2J5dGVzLiBBZGRpdGlvbmFsIGxpZmV0aW1lIHVuaXRzIGFyZSB0aGVuIGlu dHJvZHVjZWQgYnkgYWRkaW5nIG5ldyBhdHRyaWJ1dGVzLCBpbnN0ZWFkIG9mIGFkZGluZyBu ZXcgYXR0cmlidXRlIHZhbHVlcy4NDVxpdGVtIEl0IGlzIG5vdCBjbGVhciB0byB1cyBmcm9t IHRoZSBkb2N1bWVudGF0aW9uIHdoYXQgdGhlIGhpZ2hlci1sZXZlbCBpbnRlcnByZXRhdGlv biBpcyBvZiB0aGUgU2VjcmVjeSBsZXZlbCwgU2VjcmVjeSBjYXRlZ29yeSBiaXRtYXAsIElu dGVncml0eSBsZXZlbCwgYW5kIEludGVncml0eSBjYXRlZ29yeSBiaXRtYXAgZmllbGRzIGlu IHRoZSBTQSBwYXlsb2FkIGluIHNlY3Rpb24gNC42LjEuIEFzIHRoZXJlIGFyZSBjdXJyZW50 bHkgbm8gbGFiZWxlZCBkb21haW4gaWRlbnRpZmllcnMgYWxsb2NhdGVkLCB0aGVzZSBmaWVs ZHMgZG8gbm90IHNlZW0gdG8gYmUgdXNlZCBpbiBhbnkgY3VycmVudCBzeXN0ZW0uDQ1caXRl bSBTZWN0aW9uIDQuNi4yIHN0YXRlcyB0aGF0IHRoZSBJZGVudGlmaWNhdGlvbiBwYXlsb2Fk IGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGluaXRpYXRvci4gVGhlIHByb3RvY29scyBpbiBc Y2l0ZXtSRkMyNDA4fSBhbHNvIHVzZSB0aGUgaWRlbnRpZmljYXRpb24gcGF5bG9hZCB0byBp ZGVudGlmeSB0aGUgcmVzcG9uZGVyLg0NXGVuZHtlbnVtZXJhdGV9DQ1cY2hhcHRlcntJS0V9 XGxhYmVse2NoYXA6SUtFfQ0NSUtFIGlzIHRoZSBkZWZhdWx0IGtleS1leGNoYW5nZSBwcm90 b2NvbCBmb3IgSVNBS01QLCBhbmQgYXQgdGhlIG1vbWVudCB0aGUgb25seSBvbmUuIElLRSBp cyBidWlsdCBvbiB0b3Agb2YgSVNBS01QIGFuZCBwZXJmb3JtcyB0aGUgYWN0dWFsIGVzdGFi bGlzaG1lbnQgb2YgYm90aCBJU0FLTVAgU0FzIGFuZCBJUHNlYyBTQXMuDQ1cc2VjdGlvbntQ cmltaXRpdmUgZnVuY3Rpb25zfQ1JS0Ugc3VwcG9ydHMgdGhlIG5lZ290aWF0aW9uIG9mIHZh cmlvdXMgcHJpbWl0aXZlIGZ1bmN0aW9ucyBmb3IgdXNlIGluIHRoZSBwcm90b2NvbHMuIEFt b25nIHRoZXNlIGFyZSB0aGUgaGFzaCBmdW5jdGlvbiBhbmQgdGhlIHBzZXVkb3JhbmRvbSBm dW5jdGlvbiAoUFJGKSB0byBiZSB1c2VkLiBObyByZXF1aXJlbWVudHMgYXJlIGdpdmVuIGZv ciB0aGUgaGFzaCBmdW5jdGlvbiBhbmQgUFJGLiBUaGVyZSBpcyBubyBtZW50aW9uIG9mIHRo ZSBwcm9wZXJ0aWVzIHRoYXQgSUtFIGFzc3VtZXMgdGhlIGhhc2ggZnVuY3Rpb24gYW5kIFBS RiBoYXZlLiANDVxzdWJzZWN0aW9ue0hhc2ggZnVuY3Rpb259XGxhYmVse3NlYzpoYXNoZnVu Y30NVGhlIG1vc3Qgd2lkZWx5IHVzZWQgZGVmaW5pdGlvbiBvZiBhIGhhc2ggZnVuY3Rpb24g dXNlcyB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUgaGFzaCBmdW5jdGlvbiBpcyBjb2xsaXNp b24tcmVzaXN0YW50LiBUaHVzLCBpdCBzaG91bGQgYmUgaW1wb3NzaWJsZSB0byBmaW5kIHR3 byBtZXNzYWdlcyAkbV8xJCBhbmQgJG1fMiQgc3VjaCB0aGF0ICRIKG1fMSk9SChtXzIpJCB3 aGVyZSAkSCQgaXMgdGhlIGhhc2ggZnVuY3Rpb24uIEluIFxjaXRle0FuZDpIYXNoOTN9IFJv c3MgQW5kZXJzb24gc2hvd2VkIHRoYXQgdGhpcyBpcyBvZnRlbiBub3QgZW5vdWdoLCBhbmQg dGhhdCBtYW55IHByb3RvY29scyBicmVhayBmb3IgY2VydGFpbiBjb2xsaXNpb24tcmVzaXN0 YW50IGhhc2ggZnVuY3Rpb25zLiBIZSBnYXZlIG9uZSBzaW1wbGUgZXhhbXBsZS4gTGV0ICRt JyQgYmUgdGhlIGZpcnN0ICRuJCBiaXRzIG9mIHRoZSBtZXNzYWdlICRtJCwgYW5kIGxldCAk bScnJCBiZSB0aGUgcmVzdC4gRGVmaW5lICRIJyhtJ3xtJycpIDo9IG0nIHwgSCggbScnICkk IGZvciBhbnkgY29sbGlzaW9uLXJlc2lzdGFudCBoYXNoIGZ1bmN0aW9uICRIJC4gSXQgaXMg Y2xlYXIgdGhhdCAkSCckIGlzIGFzIGNvbGxpc2lvbi1yZXNpc3RhbnQgYXMgJEgkIGlzLiBI b3dldmVyLCBtYW55IHByb3RvY29scyBzaWxlbnRseSBhc3N1bWUgdGhhdCB0aGUgaGFzaCBm dW5jdGlvbiBpcyBtb3JlIG9yIGxlc3MgYSByYW5kb20gb3JhY2xlLCBhbmQgY2FuIGZhaWwg d2hlbiB0aGlzIGlzIG5vdCB0aGUgY2FzZSBcY2l0ZXtBbmQ6SGFzaDkzfS4gRm9yIGV4YW1w bGUsIHRoZSBITUFDIGNvbnN0cnVjdGlvbiBmYWlscyBtaXNlcmFibHkgd2l0aCAkSCckIGFz IGhhc2ggZnVuY3Rpb24sIGFzIGl0IHJldmVhbHMgdGhlIGtleSBpbiB0aGUgb3V0cHV0LiBU aGlzIHNob3dzIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGRlZmluZSB3aGljaCBwcm9wZXJ0 aWVzIGFyZSByZXF1aXJlZCBmcm9tIHRoZSBoYXNoIGZ1bmN0aW9uLiBBcHBseWluZyBITUFD IHRvIGEgY29sbGlzaW9uLXJlc2lzdGFudCBoYXNoIGZ1bmN0aW9uIGRvZXMgbm90IGFsd2F5 cyByZXN1bHQgaW4gYSBnb29kIE1BQyBmdW5jdGlvbi4NDVxzdWJzZWN0aW9ue1BSRn0NQ3Vy cmVudGx5IG5vIHNwZWNpYWwgUFJGcyBhcmUgZGVmaW5lZDsgdGhlIGRlZmF1bHQgbW9kZSBv ZiB1c2luZyB0aGUgbmVnb3RpYXRlZCBoYXNoIGZ1bmN0aW9uIGluIHRoZSBITUFDIGNvbnN0 cnVjdGlvbiBpcyB1c2VkIGluc3RlYWQuIFRoZXJlIGFyZSBubyByZXF1aXJlbWVudHMgZ2l2 ZW4gZm9yIGEgbmV3IFBSRjsgdGhlIGRlc2NyaXB0aW9uIGNhbGxzIGZvciBhIGBga2V5ZWQg cHNldWRvcmFuZG9tIGZ1bmN0aW9uLicnIEZvbGxvd2luZyB0aGUgbm90YXRpb25hbCBjb252 ZW50aW9uIG9mIFxjaXRle1JGQzI0MDl9LCB3ZSB3aWxsIGNhbGwgdGhlIGZpcnN0IGFyZ3Vt ZW50IG9mIHRoZSBQUkYgdGhlIGtleSBhbmQgdGhlIHNlY29uZCBhcmd1bWVudCB0aGUgbWVz c2FnZS4gDQ1XZSB0YWtlIHRoaXMgdG8gbWVhbiB0aGUgZm9sbG93aW5nOiBmb3IgYSBmaXhl ZCBrZXksIHRoZSBtYXBwaW5nIG9mIG1lc3NhZ2VzIHRvIHRoZSBvdXRwdXQgaXMgYSBwc2V1 ZG9yYW5kb20gZnVuY3Rpb24uIFRoZSBQUkYgc2hvdWxkIGJlIGluZGlzdGluZ3Vpc2hhYmxl IGZyb20gYSBmdW5jdGlvbiB3aGVyZSB0aGUga2V5IHVuaWZvcm1seSBzZWxlY3RzIGEgcmFu ZG9tIGVsZW1lbnQgb2YgdGhlIHNldCBvZiBhbGwgZnVuY3Rpb25zIG1hcHBpbmcgbWVzc2Fn ZXMgaW50byBzdWl0YWJsZSBvdXRwdXQgdmFsdWVzLiANDU5vdGUgdGhhdCB0aGlzIGRlZmlu aXRpb24gZG9lcyBub3QgcHJlY2x1ZGUgYSBQUkYgdGhhdCBpcyBpbnZlcnRpYmxlIGZvciBh IGtub3duIGtleS4gV2UgZGVmaW5lIGEgUFJGIGNhbGxlZCBOUFJGIChmb3IgTmFzdHkgUFJG KSBhcyBmb2xsb3dzOiBmb3IgYSBzaG9ydCBtZXNzYWdlIHRoZSBQUkYgaXMgZGVmaW5lZCBh cyANJCQNXG1ib3h7cHJmfShrLG0pID0gRSggaywgMCB8IG0gKQ0kJA13aGlsZSBmb3IgbG9u ZyBtZXNzYWdlcyBpdCBpcyBkZWZpbmVkIGFzDSQkDVxtYm94e3ByZn0oayxtKSA9IEUoIGss IDEgfCBIKG0pICkNJCQNSGVyZSwgJEgkIGlzIGEgc3VpdGFibGUgaGFzaCBmdW5jdGlvbiwg JEUkIGlzIGEgYmxvY2sgY2lwaGVyIGVuY3J5cHRpb24gdGFraW5nIGEga2V5IGFuZCBhIHBs YWludGV4dCBibG9jayBhcyBhcmd1bWVudHMsIGFuZCBhIG1lc3NhZ2UgaXMgY29uc2lkZXJl ZCBgYGxvbmcnJyBpZiBpdCBpcyBhdCBsZWFzdCBhcyBsb25nIGFzIHRoZSBibG9jayBzaXpl IG9mIHRoZSBibG9jayBjaXBoZXIuIEZvciBzaG9ydCBtZXNzYWdlcywgdGhpcyBQUkYgaXMg aW52ZXJ0aWJsZSBpZiB0aGUga2V5IGlzIGtub3duLiBJZiB0aGUgYmxvY2sgY2lwaGVyIGlz IGdvb2QgYW5kIHRoZSBibG9jayBzaXplIGlzIGxhcmdlIGVub3VnaCAoZS5nLiwgMTAyNCBi aXRzKSwgdGhpcyBmdW5jdGlvbiBpcyBpbmRpc3Rpbmd1aXNoYWJsZSBmcm9tIGEgcmFuZG9t IGZ1bmN0aW9uLCBhcyBkZXRlY3RpbmcgdGhlIGZhY3QgdGhhdCBpdCBpcyBhIHBlcm11dGF0 aW9uIGFuZCBub3QgYSByYW5kb20gZnVuY3Rpb24gcmVxdWlyZXMgdG9vIG11Y2ggd29yay4N DUlLRSB1c2VzIHRoZSBQUkYgc29tZXRpbWVzIHdpdGgga25vd24ga2V5IGlucHV0LiBJdCBp cyBjbGVhcmx5IG5vdCB0aGUgZGVzaWduZXIncyBpbnRlbnRpb24gdG8gaGF2ZSBhbiBpbnZl cnRpYmxlIGZ1bmN0aW9uIGluIHRoaXMgY2FzZS4gQXMgd2l0aCB0aGUgaGFzaCBmdW5jdGlv biwgSUtFIHNob3VsZCBzcGVjaWZ5IHdoYXQgcHJvcGVydGllcyBpdCBleHBlY3RzIGZyb20g aXRzIFBSRi4NDVRoZSBkZWZhdWx0IGNvbnN0cnVjdGlvbiBvZiB0aGUgUFJGIGlzIHRvIHVz ZSBITUFDIGFuZCB0aGUgaGFzaCBmdW5jdGlvbi4gQXMgc2hvd24gYWJvdmUsIHNvbWUgaGFz aCBmdW5jdGlvbnMgcmVzdWx0IGluIHZlcnkgYmFkIFBSRnMgd2hlbiB1c2VkIHdpdGggdGhl IEhNQUMgY29uc3RydWN0aW9uLiBUaGlzIGNhbiBicmVhayBhbnkgcHJvdG9jb2wgdXNpbmcg dGhlIFBSRi4gRm9yIGV4YW1wbGUsIHRoZSBtYWluIG1vZGUgZXhjaGFuZ2Ugd2l0aCBwdWJs aWMta2V5IGVuY3J5cHRpb24gZmFpbHMgd2hlbiB1c2luZyBITUFDIHdpdGggJEgnJCBkZWZp bmVkIGFib3ZlIGFzIHRoZSBIQVNIXF9JIHJldmVhbHMgU0tFWUlELCBhbGxvd2luZyBhIGZh a2UgcmVzcG9uZGVyIHRvIGltcGVyc29uYXRlIHRoZSByZWFsIHJlc3BvbmRlci4NDVxzdWJz ZWN0aW9ue0NvbmNsdXNpb25zfQ1XaGVuZXZlciBwcmltaXRpdmUgZnVuY3Rpb25zIGFyZSB1 c2VkLCBpdCBpcyBpbXBvcnRhbnQgdG8gc3BlY2lmeSBleGFjdGx5IHdoaWNoIHByb3BlcnRp ZXMgYXJlIGFzc3VtZWQuIFRoaXMgY2FuIGJlIHNlZW4gYXMgc3BlY2lmeWluZyB0aGUgaW50 ZXJmYWNlIGJldHdlZW4gdGhlIHR3byBwYXJ0cyBvZiB0aGUgZGVmaW5pdGlvbi4gSXQgYWxs b3dzIGVhY2ggb2YgdGhlIHBhcnRzIHRvIGJlIGFuYWx5emVkIHNlcGFyYXRlbHkuIFdpdGhv dXQgc3VjaCBjbGVhciBzcGVjaWZpY2F0aW9ucyBpdCBpcyBtdWNoIGhhcmRlciB0byBhbmFs eXplIHRoZSBzZWN1cml0eSBvZiB0aGUgc3lzdGVtLiBGdXJ0aGVybW9yZSwgdGhlcmUgaXMg YSBzZXJpb3VzIGRhbmdlciB0aGF0IHNvbWUgZnV0dXJlIGV4dGVuc2lvbiB3aWxsIGludHJv ZHVjZSBhIG5ldyBwcmltaXRpdmUgd2l0aCBhbiB1bmRlc2lyYWJsZSBwcm9wZXJ0eSB0aGF0 IHdhcyBzaWxlbnRseSBhc3N1bWVkIGJ5IHRoZSBkZXNpZ25lcnMgYW5kIGV2YWx1YXRvcnMg b2YgdGhlIG9yaWdpbmFsIHZlcnNpb24uDQ1cc2VjdGlvbntEZXJpdmF0aW9uIG9mIFNLRVlJ RCBkYXRhfQ0NT2JzZXJ2ZSB0aGUgY29tcHV0YXRpb24gb2YgU0tFWUlEIFxjaXRlW3BhZ2Ug MTBde1JGQzI0MDl9IGluIHRoZSB0aHJlZSBkaWZmZXJlbnQgYXV0aGVudGljYXRpb24gY2Fz ZXMuIEZvciBzaWduYXR1cmUgYXV0aGVudGljYXRpb24sIHRoZSBrZXkgaW5wdXQgb2YgdGhl IFBSRiBpcyBwdWJsaWMsIGFuZCB0aGUgbWVzc2FnZSBpbnB1dCBpcyBzZWNyZXQuIFRoaXMg aXMgY2xlYXJseSBhbiBhYnVzZSBvZiB0aGUgUFJGLiAoSWYgdGhlIE5QUkYgaXMgdXNlZCwg cmV2ZWFsaW5nIFNLRVlJRCBhbHNvIHJldmVhbHMgJGdee3h5fSQuKSBGdXJ0aGVybW9yZSwg dGhlIGNvbmNhdGVuYXRpb24gb2YgdGhlIHR3byBub25jZXMgY2FuIGJlIHVwIHRvIDUxMiBi eXRlcyBsb25nLCB3aGlsZSB0aGUgSE1BQyBjb25zdHJ1Y3Rpb24gdGFrZXMgYXQgbW9zdCA2 NCBieXRlcyBvZiBrZXkuIFRoZSBwdWJsaWMta2V5IGVuY3J5cHRpb24gY2FzZSBvbiB0aGUg bmV4dCBsaW5lIHJlc29sdmVzIHRoaXMgYnkgaW5zZXJ0aW5nIGFuIGV4dHJhIGhhc2ggZnVu Y3Rpb24gYXBwbGljYXRpb24uIA0NVGhlIHRocmVlIGZvcm11bGFzIGZvciBjb21wdXRpbmcg U0tFWUlEIHNlZW0gc29tZXdoYXQgYWQgaG9jLiBJdCBpcyBub3QgY2xlYXIgd2hhdCBwcm9w ZXJ0aWVzIGFyZSB3YW50ZWQsIGFuZCB3aGljaCBhcmUgYWNoaWV2ZWQuIFdoeSBhcmUgdGhl IGNvb2tpZXMgdXNlZCBpbiB0aGUgcHVibGljLWtleSBlbmNyeXB0aW9uIGNhc2UsIGFuZCBu b3QgaW4gdGhlIHByZS1zaGFyZWQga2V5IGNhc2U/IE9uZSBpZGVhIHNlZW1zIHRvIGJlIHRv IHVzZSBldmVyeSB2YWx1ZSBhdCBtb3N0IG9uY2UgYXMgaW5wdXQuIFRoaXMgcHJpbmNpcGxl IGlzIG5vdCBmb2xsb3dlZCBpbiB0aGUgZGVyaXZhdGlvbiBvZiB0aGUgU0tFWUlEXF9kLCBT S0VZSURcX2EsIGFuZCBTS0VZSURcX2Ugd2hlcmUgdGhlIHNhbWUgdmFsdWVzIGFyZSByZXBl YXRlZGx5IHVzZWQgaW4gdGhlIGRlcml2YXRpb24uIEluIHRoZSBzaWduYXR1cmUgYXV0aGVu dGljYXRpb24gY2FzZSwgJGdee3h5fSQgYWZmZWN0cyBib3RoIHRoZSBrZXkgYW5kIHRoZSBt ZXNzYWdlIGZpZWxkIG9mIHRoZSBQUkYgYXBwbGljYXRpb24gdXNlZCB0byBjb21wdXRlIFNL RVlJRFxfZC4gDQ1BcyBmYXIgYXMgd2UgYXJlIGFibGUgdG8gc2VlIHRoZXNlIHByb3BlcnRp ZXMgZG8gbm90IGxlYWQgdG8gYSBkaXJlY3Qgd2Vha25lc3MsIGFzIFBSRnMgYXJlIHZlcnkg Zm9yZ2l2aW5nIChpbiB0aGUgaWRlYWwgY2FzZSkuIFRoZSBzaWduYXR1cmUgYXV0aGVudGlj YXRpb24gY2FzZSBpcyBzYXZlZCBieSB0aGUgZmFjdCB0aGF0IFNLRVlJRCBpdHNlbGYgaXMg bmV2ZXIgcmV2ZWFsZWQsIGJ1dCBvbmx5IHVzZWQgYXMga2V5IGlucHV0IHRvIG90aGVyIFBS RiBhcHBsaWNhdGlvbnMuIFdlIHJlY29tbWVuZCB0aGF0IHRoZSBkZXJpdmF0aW9uIG9mIFNL RVlJRCBhbmQgYXNzb2NpYXRlZCB2YWx1ZXMgYmUgcmUtZXZhbHVhdGVkLCBhbmQgdGhhdCB0 aGUgU0tFWUlEIGNvbXB1dGF0aW9uIGZvciB0aGUgc2lnbmF0dXJlIGF1dGhlbnRpY2F0aW9u IGNhc2UgYmUgY2hhbmdlZC4NDVxzZWN0aW9ue1RoZSBIQVNIIGF1dGhlbnRpY2F0aW9uIHZh bHVlc30NQWxvbmdzaWRlIHRoZSBTS0VZSUQgZGVyaXZhdGlvbiwgdGhlIEhBU0ggdmFsdWVz IGFyZSBkZWZpbmVkIHRoYXQgYXJlIHVzZWQgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIGZ1bmN0 aW9ucy4gVGhlc2UgSEFTSCB2YWx1ZXMgYXJlIGNvbXB1dGVkIGFzIFBSRiBhcHBsaWNhdGlv bnMgdXNpbmcgU0tFWUlEIGFzIHRoZSBrZXkgYW5kIGEgY29uY2F0ZW5hdGlvbiBvZiB2YXJp b3VzIGRhdGEgZmllbGRzIGFzIG1lc3NhZ2UuIA0NVGhlIG5vbmNlcyBvbmx5IGFmZmVjdCB0 aGUgSEFTSCB2YWx1ZXMgdGhyb3VnaCB0aGUgU0tFWUlELiBJdCB3b3VsZCBzZWVtIG1vcmUg b2J2aW91cyB0byBpbmNsdWRlIGFsbCByZWxldmFudCBmaWVsZHMgb2YgdGhlIHByb3RvY29s IGluIHRoZSBtZXNzYWdlIHBhcnQgb2YgdGhlIFBSRi4gDQ1cc3Vic2VjdGlvbntBIHJlZmxl Y3Rpb24gYXR0YWNrfQ1UaGUgdHdvIGZvcm11bGFzIGZvciBjb21wdXRpbmcgSEFTSFxfSSBh bmQgSEFTSFxfUiBhcmUgc3ltbWV0cmljYWwgd2l0aCByZWdhcmQgdG8gc3dhcHBpbmcgdGhl IGluaXRpYXRvciBhbmQgdGhlIHJlc3BvbmRlci4gVGhpcyBvcGVucyB1cCB0aGUgcG9zc2li aWxpdHkgb2YgYSByZWZsZWN0aW9uIGF0dGFjay4gSW4gbWFpbiBtb2RlIHdpdGggcHJlLXNo YXJlZCBrZXlzLCBhIGZyYXVkdWxlbnQgcmVzcG9uZGVyIGNhbiBjbGFpbSB0aGUgc2FtZSBp ZGVudGl0eSBhcyB0aGUgaW5pdGlhdG9yIGFuZCBzdGlsbCBwYXNzIHRoZSBhdXRoZW50aWNh dGlvbiBwaGFzZS4gVGhlIHJlc3BvbmRlciBkb2VzIHRoaXMgYnkgY2hvb3NpbmcgQ0tZLVIg YXMgQ0tZLUkgYW5kICRnXnt4X3J9JCBhcyAkZ157eF9pfSQsIGFuZCB1c2luZyB0aGUgaW5p dGlhdG9yJ3MgaWRlbnRpdHkuIEluIHRoaXMgY2FzZSBIQVNIXF9SIGlzIGVxdWFsIHRvIEhB U0hcX0ksIHNvIHRoZSByZXNwb25kZXIgY2FuIGp1c3Qgc2VuZCB0aGUgYmFjayB0aGUgdmFs dWUgdGhhdCB0aGUgaW5pdGlhdG9yIHNlbnQuXGZvb3Rub3Rle0FjdHVhbGx5LCB0aGUgZnJh dWR1bGVudCByZXNwb25kZXIgY2Fubm90IHJlYWQgdGhlIGZpZnRoIG1lc3NhZ2UgaXQgZ2V0 cyBmcm9tIHRoZSBpbml0aWF0b3IsIGFzIGl0IGlzIGVuY3J5cHRlZC4gVGhpcyBkb2VzIG5v dCBtYXR0ZXIsIGFzIHRoZSBtZXNzYWdlIHRoYXQgaGUgd2FudHMgdG8gc2VuZCBpbiByZXBs eSBoYXMgdGhlIHNhbWUgZm9ybWF0LCBzbyB0aGUgZW5jcnlwdGVkIGZpZnRoIG1lc3NhZ2Ug Y2FuIGJlIHNlbnQgYmFjayBhcyB0aGUgc2l4dGggbWVzc2FnZS59IA0NVGhlIHJlbGF0ZWQg YXR0YWNrIGZvciBhIGZyYXVkdWxlbnQgaW5pdGlhdG9yIGluIGFnZ3Jlc3NpdmUgbW9kZSBk b2VzIG5vdCB3b3JrIGFzIHRoZSBpbml0aWF0b3IgaGFzIHRvIGNvbW1pdCB0byAkZ157eF9p fSQgYmVmb3JlIHRoZSByZXNwb25kZXIgY2hvb3NlcyAkZ157eF9yfSQgaW4gYSByYW5kb20g bWFubmVyLiANDVRoZSBzYW1lIGF0dGFjayBzZWVtcyB0byBhcHBseSB0byB0aGUgc2lnbmF0 dXJlIGF1dGhlbnRpY2F0ZWQgbWFpbiBtb2RlIGV4Y2hhbmdlLiBUaGUgcmVzcG9uZGVyIGNh biByZXBsYXkgYWxsIHRoZSBpbml0aWF0b3IncyB2YWx1ZXMgYW5kIHRoZSBsYXN0IG1lc3Nh Z2UsIGFuZCBwYXNzIHRoZSBhdXRoZW50aWNhdGlvbi4NDVxzdWJzZWN0aW9ue0EgcHJvcG9z YWwgYXR0YWNrfQ1UaGUgSEFTSCBjb21wdXRhdGlvbnMgZG8gbm90IGluY2x1ZGUgdGhlIFNB IHJlcGx5IGJ5IHRoZSByZXNwb25kZXIuIFRoaXMgaW1wbGllcyB0aGF0IGFuIGF0dGFja2Vy IGNhbiBtYW5pcHVsYXRlIHRoaXMgcGF5bG9hZCB3aXRob3V0IGFkdmVyc2UgZWZmZWN0cyB3 aXRoaW4gdGhlIHByb3RvY29sLiBTdXBwb3NlIHRoZSBpbml0aWF0b3Igc2VuZHMgYSBsaXN0 IG9mIG1hbnkgcHJvcG9zYWxzIGluIG9yZGVyIG9mIHByZWZlcmVuY2UuIFRoZSBsZWFzdCBw cmVmZXJyZWQgcHJvcG9zYWwgb25seSBwcm92aWRlcyBtYXJnaW5hbCBzZWN1cml0eSAoZS5n LiwgNDAgYml0cyBvciBzbykuIFRoZSBhdHRhY2tlciBjYW4gbm93IG1vZGlmeSB0aGUgcmVz cG9uZGVyJ3MgU0EgdG8gc2VsZWN0IHRoaXMgd2VhayBtb2RlLCBhbmQgbGV0IHRoZSByZXN0 IG9mIHRoZSBleGNoYW5nZSBjb21wbGV0ZSBhcyB1c3VhbC4gVGhlIGluaXRpYXRvciB3aWxs IG5vdyBzdGFydCB1c2luZyB0aGUgbmV3bHkgbmVnb3RpYXRlZCBTQSwgd2hpY2ggaXMgY29u c2lkZXJhYmx5IHdlYWtlciB0aGFuIGl0IHNob3VsZCBiZS4gDQ1TdXBwb3NlIHRoaXMgaXMg ZG9uZSBpbiBhbiBhZ2dyZXNzaXZlIG1vZGUgbmVnb3RpYXRpb24gZm9yIHBoYXNlIDEuIFRo ZSByZXN1bHRpbmcgSVNBS01QIFNBIGlzIHdlYWsuIEFzIHNvb24gYXMgdGhlIGluaXRpYXRv ciBzdGFydHMgdG8gdXNlIHRoZSB3ZWFrIGtleXMsIHRoZSBhdHRhY2tlciBjYW4gZG8gYSBi cnV0ZS1mb3JjZSBzZWFyY2ggZm9yIHRoZSBrZXlzLiBPbmNlIGZvdW5kLCB0aGUgYXR0YWNr ZXIgaGFzIHJlY292ZXJlZCB0aGUgSVNBS01QIFNBIGtleXMgYW5kIGNhbiBub3cgbmVnb3Rp YXRlIGZ1bGwtc3RyZW5ndGggSVBzZWMgU0FzIHdpdGggdGhlIGluaXRpYXRvciB3aGlsZSBw cmV0ZW5kaW5nIHRvIGJlIHRoZSByZXNwb25kZXIuIFRoaXMgaXMgYSBjbGVhciB2aW9sYXRp b24gb2YgdGhlIGludGVudGlvbiBvZiB0aGUgcHJvdG9jb2wuDQ1Bbm90aGVyIHN1YnRsZXR5 IGlzIHRoYXQgY2hhbmdpbmcgdGhlIHJlc3BvbmRlcidzIFNBIG1pZ2h0IGNoYW5nZSB0aGUg bW9kZSBiZWluZyB1c2VkLiBBbiBhdHRhY2tlciBjYW4gdGh1cyBoYXZlIHRoZSByZXNwb25k ZXIgcGVyZm9ybWluZyB0aGUgcHJvdG9jb2wgaW4gb25lIG1vZGUsIGFuZCB0aGUgaW5pdGlh dG9yIHRoZSBwcm90b2NvbCBpbiBhbm90aGVyIG1vZGUuIFdlIGhhdmUgbm90IGludmVzdGln YXRlZCB0aGUgcG9zc2libGUgaW50ZXJhY3Rpb25zLCBidXQgdGhpcyBpcyBjbGVhcmx5IHVu ZGVzaXJhYmxlLiBUaGUgcmVzcG9uZGVyJ3MgU0Egc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRo ZSBIQVNIIGNvbXB1dGF0aW9ucy4NDVxzdWJzZWN0aW9ue0NvbmNsdXNpb259DVRoZSBkZWZp bml0aW9uIG9mIHRoZSBIQVNIIHZhbHVlcyBpcyB1bmFjY2VwdGFibHkgd2VhayBhbmQgc2hv dWxkIGJlIGltcHJvdmVkLg0NXHNlY3Rpb257UGFyc2luZyBhIHN0cmluZyBvZiBieXRlc30N VGhlIFBSRnMsIHNpZ25hdHVyZSBmdW5jdGlvbnMsIGFuZCBoYXNoIGZ1bmN0aW9ucyBhcmUg ZWFjaCBhcHBsaWVkIHRvIHN0cmluZ3Mgb2YgYnl0ZXMuIEJ5IHRoZW1zZWx2ZXMsIHRoZXNl IHN0cmluZ3Mgb2YgYnl0ZXMgZG8gbm90IHNwZWNpZnkgaG93IHRoZXkgYXJlIGZvcm1hdHRl ZC4gVGhpcyBvcGVucyB1cCBhIGxvdCBvZiBmcmVlZG9tIGZvciBhbiBhdHRhY2tlci4gTGV0 IHVzIHN1cHBvc2UgdGhhdCB0aGVyZSBhcmUgdHdvIHBsYWNlcyBpbiB0aGUgcHJvdG9jb2wg d2hlcmUgYSBQUkYgZnVuY3Rpb24gaXMgYXBwbGllZCB3aXRoIHRoZSBzYW1lIGtleSBidXQg d2l0aCBkaWZmZXJlbnQgbWVzc2FnZSBmb3JtYXRzLiBJZiB0aGVzZSBmb3JtYXRzIGNvdWxk IGdlbmVyYXRlIHN0cmluZ3Mgb2YgdGhlIHNhbWUgbGVuZ3RoLCB0aGVuIGl0IGlzIGluIHBy aW5jaXBsZSBwb3NzaWJsZSB0byBjb25mdXNlIHRoZSB0d28gUFJGIGNvbXB1dGF0aW9ucy4g QW4gYXR0YWNrZXIgY2FuIHRha2UgdGhlIHJlc3VsdCBvZiB0aGUgZmlyc3QgUFJGIGNvbXB1 dGF0aW9uICh3aGljaCBoZSBtaWdodCByZWNlaXZlIGluIHRoZSBmaXJzdCBwYXJ0IG9mIHRo ZSBwcm90b2NvbCkgYW5kIHVzZSB0aGlzIHZhbHVlIGluIHRoZSBzZWNvbmQgUFJGIGNvbXB1 dGF0aW9uLiBXaGV0aGVyIG9yIG5vdCB0aGlzIGxlYWRzIHRvIGFuIGFjdHVhbCB3ZWFrbmVz cyBkZXBlbmRzIG9uIHRvbyBtYW55IGZhY3RvcnMsIGJ1dCBpdCBpcyBjbGVhcmx5IGFuIHVu ZGVzaXJhYmxlIHByb3BlcnR5LiBJbnN0ZWFkIG9mIGF1dGhlbnRpY2F0aW5nIHRoZSBpbnRl bmRlZCBtZXNzYWdlLCB0aGUgUFJGIGlzIGF1dGhlbnRpY2F0aW5nIGEgc3RyaW5nIG9mIGJ5 dGVzIHdob3NlIGludGVycHJldGF0aW9uIGlzIG5vdCBmdWxseSBkZWZpbmVkLiBUaGlzIHZp b2xhdGVzIHRoZSBgYEhvcnRvbiBwcmluY2lwbGUnJyBcY2l0ZXtXUzpTU0wzMH0uDQ1FdmVu IGlmIHRoZSBzZXQgYW5kIG9yZGVyIG9mIHRoZSBmaWVsZHMgaXMga25vd24sIHRoZSBwYXJz aW5nIG9mIHNvbWUgb2YgdGhlIG1lc3NhZ2VzIGRlcGVuZHMgb24gb3V0c2lkZSBpbmZvcm1h dGlvbi4gRm9yIGV4YW1wbGUgdGhlIEhBU0hcX0kgY29tcHV0YXRpb24gaGFzIGEgbWVzc2Fn ZSB0aGF0IGNvbnNpc3RzIG9mIHNpeCBjb25jYXRlbmF0ZWQgZmllbGRzLiBUaGUgbGVuZ3Ro IG9mIGVhY2ggZmllbGQgaGFzIHRvIGJlIGRlcml2ZWQgZnJvbSBzb21lIGNvbnRleHQsIHdo aWNoIGlzIG9wZW4gdG8gbWFuaXB1bGF0aW9uIGJ5IGFuIGF0dGFja2VyLiANDVRoZXJlIGFy ZSB0b28gbWFueSB3YXlzIGluIHdoaWNoIHRoaXMgdHlwZSBvZiBhdHRhY2sgY2FuIGJlIGF0 dGVtcHRlZCB0byBhbmFseXplIHRoZW0gYWxsLiBXZSBzdHJvbmdseSByZWNvbW1lbmQgdGhh dCB0aGUgaW5wdXQgdG8gZXZlcnkgaGFzaCBmdW5jdGlvbiwgUFJGIGZ1bmN0aW9uLCBhbmQg c2lnbmF0dXJlIGJlIGV4dGVuZGVkIHdpdGggYSBmaWVsZCB0aGF0IHVuaXF1ZWx5IGlkZW50 aWZpZXMgdGhlIHBvc2l0aW9uIHdpdGhpbiB0aGUgcHJvdG9jb2wuIEZ1cnRoZXJtb3JlLCBl YWNoIG1lc3NhZ2UgdGhhdCBpcyB1c2VkIGFzIGFuIGlucHV0IHRvIGEgaGFzaCwgUFJGLCBv ciBzaWduYXR1cmUgYWxnb3JpdGhtIHNob3VsZCBiZSBwYXJzZWFibGUgaW50byBpdHMgY29u c3RpdHVlbnQgZmllbGRzIHdpdGhvdXQgYW55IG91dHNpZGUgaW5mb3JtYXRpb24uIFRoaXMg Y2FuIGJlIGFjaGlldmVkIGJ5IHVzaW5nIGEgVGFnLUxlbmd0aC1WYWx1ZSAoVExWKSBlbmNv ZGluZyBzY2hlbWUgYWxvbmcgdGhlIGxpbmVzIG9mIEFTTi4xLlxmb290bm90ZXtXZSB3b3Vs ZCBub3QgYWR2b2NhdGUgdXNpbmcgQVNOLjEgaXRzZWxmLCBhcyBpdCBpcyB2ZXJ5IGNvbXBs ZXgufQ0NXHNlY3Rpb257RWZmaWNpZW5jeX0NQXMgd2Ugbm90ZWQgZWFybGllciwgdGhlIElT QUtNUCBpZGVudGl0eSBwcm90ZWN0aW9uIGV4Y2hhbmdlIGNhbiBiZSBzaG9ydGVuZWQgdG8g Zm91ciBtZXNzYWdlcy4gVGhlIE1haW4gbW9kZSBleGNoYW5nZXMgb2YgSUtFIGFyZSBpbXBs ZW1lbnRhdGlvbnMgb2YgdGhlIGlkZW50aXR5IHByb3RlY3Rpb24gZXhjaGFuZ2Ugb2YgSVNB S01QLiBUaGUgbWFpbiBtb2RlIGV4Y2hhbmdlIHdpdGggc2lnbmF0dXJlIGF1dGhlbnRpY2F0 aW9uIG9yIHByZS1zaGFyZWQga2V5cyBhdXRoZW50aWNhdGlvbiBjYW4gYmUgc2hvcnRlbmVk IGluIHRoZSBzYW1lIHdheS4gDQ1UaGUgbWFpbiBtb2RlcyB0aGF0IHVzZSBwdWJsaWMta2V5 IGVuY3J5cHRpb24gZm9yIGF1dGhlbnRpY2F0aW9uIGNhbm5vdCBiZSBzaG9ydGVuZWQgaW4g ZXhhY3RseSB0aGUgc2FtZSB3YXksIGFzIHRoZSByZXNwb25kZXIgd291bGQgbmVlZCB0byBr bm93IHRoZSBpZGVudGl0eSBvZiB0aGUgaW5pdGlhdG9yIGluc3RlYWQgb2YgdGhlIG90aGVy IHdheSBhcm91bmQuIFRoaXMgd291bGQgY2hhbmdlIHRoZSBwcm9wZXJ0aWVzIG9mIHRoZSBw cm90b2NvbC4gSG93ZXZlciwgaXQgaXMgcG9zc2libGUgdG8gc2hvcnRlbiB0aGUgZXhjaGFu Z2UgdG8gZml2ZSBtZXNzYWdlcywgYnkgc3dhcHBpbmcgdGhlIG9yZGVyIG9mIHRoZSBsYXN0 IHR3byBhbmQgbWVyZ2luZyB0aGUgdHdvIGFkamFjZW50IG1lc3NhZ2VzIHRoYXQgdGhlIHJl c3BvbmRlciBzZW5kcyBpbnRvIGEgc2luZ2xlIHBhY2tldC4NDVxzZWN0aW9ue0NvbW1lbnRz IHJlbGF0aW5nIHRvIHNlY3VyaXR5fQ1cYmVnaW57ZW51bWVyYXRlfQ1caXRlbSBJS0UgY2Fu IHVzZSB0aGUgVGlnZXIgaGFzaCBmdW5jdGlvbi4gVGhpcyBpcyBhIGZhaXJseSBuZXcgaGFz aCBmdW5jdGlvbiB0aGF0IHVzZXMgc29tZSBuZXcgaWRlYXMgdGhhdCBoYXZlIG5vdCB5ZXQg YmVlbiB0aG9yb3VnaGx5IGFuYWx5emVkLiBBdCB0aGUgbW9tZW50IG9mIHdyaXRpbmcgd2Ug YXJlIG5vdCBhd2FyZSBvZiBhbnkgcHVibGlzaGVkIHJlc3VsdHMgb24gVGlnZXIgb3RoZXIg dGhhbiB0aGUgb3JpZ2luYWwgcGFwZXIuIFdlIGZlZWwgdGhhdCBpdCBpcyB0b28gZWFybHkg dG8gdXNlIFRpZ2VyIGluIGEgcHJvZHVjdGlvbiBzeXN0ZW0uDQ1caXRlbSBQYWdlIDExIGRl c2NyaWJlcyBob3cgdGhlIGNob2ljZSBvZiBzaWduYXR1cmUgYWxnb3JpdGhtIGFmZmVjdHMg dGhlIGNob2ljZSBvZiBQUkYgYWxnb3JpdGhtIHVzZWQgdG8gY29tcHV0ZSB0aGUgSEFTSCB2 YWx1ZXMuIFRoaXMgaXMgYW4gdWdseSBjb25zdHJ1Y3Rpb24sIGFuZCBzaG91bGQgYmUgcmVt b3ZlZC4gSXQgY2FuIGV2ZW4gYWZmZWN0IHNlY3VyaXR5LiBTdXBwb3NlIHRoZSBzaWduYXR1 cmUgbWV0aG9kIHVzZXMgYSB3ZWlyZCBoYXNoIGZ1bmN0aW9uIGxpa2UgdGhlIG9uZSBpbiBz ZWN0aW9uflxyZWZ7c2VjOmhhc2hmdW5jfTsgdGhpcyBpcyBwZXJmZWN0bHkgc3VpdGFibGUg Zm9yIGEgc2lnbmF0dXJlIHN5c3RlbSwgYXMgdGhlIGhhc2ggZnVuY3Rpb24gaXMgY29sbGlz aW9uLXJlc2lzdGFudC4gSUtFIHdvdWxkIHVzZSB0aGlzIGhhc2ggZnVuY3Rpb24gaW4gSE1B QyBtb2RlLCB3aGljaCBpcyBub3QgYXQgYWxsIHNlY3VyZS4gVGhlIG92ZXJhbGwgZWZmZWN0 IG1pZ2h0IHZlcnkgd2VsbCBiZSB0byByZXZlYWwgU0tFWUlEIHRvIGFuIGF0dGFja2VyLg0N VGhpcyBpcyBub3QgYXMgZmFyLWZldGNoZWQgYXMgaXQgc2VlbXMuIFRoZSBSU0Egc3lzdGVt IGFsbG93cyBtZXNzYWdlIGJpdHMgdG8gYmUgcmVjb3ZlcmVkIGZyb20gYSBzaWduYXR1cmUu IEEgc3lzdGVtIHRoYXQgd2FudHMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhpcyBwcm9wZXJ0 eSBjb3VsZCB2ZXJ5IHdlbGwgdXNlIGEgZGVmaW5pdGlvbiBzaW1pbGFyIHRvIHRoZSBvbmUg d2UgZ2F2ZSBpbiBzZWN0aW9uflxyZWZ7c2VjOmhhc2hmdW5jfSwgYXMgdGhpcyBwcm9kdWNl cyBleGFjdGx5IHRoZSB0eXBlIG9mIHZhbHVlIHRoYXQgaXMgc3VpdGFibGUgZm9yIGFuIFJT QSBzaWduYXR1cmUgd2l0aCAocGFydGlhbCkgbWVzc2FnZSByZWNvdmVyeS4NDVxpdGVtIEFw cGVuZGl4IEIgY29udGFpbnMgZXhwbGljaXQgcnVsZXMgdG8gc3VwcG9ydCBDQkMgbW9kZSBl bmNyeXB0aW9uIGFsZ29yaXRobXMuIFRoaXMgaXMgYSB2aW9sYXRpb24gb2YgbW9kdWxlIGJv dW5kYXJpZXMsIGFuZCBjb21wbGljYXRlcyB0aGUgcHJvdG9jb2wgKGFuZCB0aGUgc29mdHdh cmUpIGJ5IGludHJvZHVjaW5nIGFyYml0cmFyeSBkZXBlbmRlbmNpZXMuIFdlIGFkdmlzZSB0 aGF0IHN1Y2ggZGVwZW5kZW5jaWVzIGJlIHJlbW92ZWQgYW5kIGVuY3J5cHRpb24gYmUgbGVm dCB0byB0aGUgZW5jcnlwdGlvbiB0cmFuc2Zvcm0uDQ1UaGUgSVYgcnVsZXMgaW4gYXBwZW5k aXggQiBkbyBub3QgZ3VhcmFudGVlIGEgdW5pcXVlIElWIGZvciBhbGwgbWVzc2FnZXMuIElm IHR3byBwaGFzZSAyIG5lZ290aWF0aW9ucyBhcmUgZG9uZSB0aGF0IGhhcHBlbiB0byBoYXZl IHRoZSBzYW1lIG1lc3NhZ2UgSUQsIHRoZW4gdGhlIHNhbWUgSVYgd2lsbCBiZSBnZW5lcmF0 ZWQuIFRoZSByZXN1bHQgaXMgdGhhdCBhIHBhc3NpdmUgZWF2ZXNkcm9wcGVyIGNhbiByZWNv Z25pemUgd2hldGhlciB0aGUgZmlyc3QgZWlnaHQgYnl0ZXMgb2YgdGhlIGVuY3J5cHRlZCBt ZXNzYWdlIGFyZSB0aGUgc2FtZSBvciBub3QuIEdpdmVuIHRoZSB2ZXJ5IHN0cnVjdHVyZWQg Zm9ybSBvZiB0aGUgc3RhcnQgb2YgYSBtZXNzYWdlIHRoaXMgbWlnaHQgYWN0dWFsbHkgaGFw cGVuIG9uY2UgaW4gYSB3aGlsZSwgYW5kIHRodXMgcmV2ZWFsIGluZm9ybWF0aW9uIHRvIHRo ZSBhdHRhY2tlci4gQ29sbGlzaW9ucyBvbiB0aGUgbWVzc2FnZSBJRCBhcmUgZmFyIG1vcmUg bGlrZWx5IHRoYW4gY29sbGlzaW9ucyBvbiB0aGUgSVYsIGFzIHRoZSBtZXNzYWdlIElEIGlz IG9ubHkgZm91ciBieXRlcy4NDVxpdGVtIFRoZSBtZXRob2QgdXNlZCB0byBkZXJpdmUgdGhl IGtleSBtYXRlcmlhbCBmb3IgdGhlIG5ld2x5IG5lZ290aWF0ZWQgU0EgaW4gdGhlIHBoYXNl IDIgcXVpY2sgbW9kZSBjb250YWlucyBhIHdlYWtuZXNzLiBUaGUgS0VZTUFUIHZhbHVlIGRl cGVuZHMgb24gU0tFWUlEXF9kLCB0aGUgcHJvdG9jb2wsIHRoZSBTUEksIGFuZCBib3RoIG5v bmNlcy4gVGhlIFNQSSB2YWx1ZXMgYXJlIG9ubHkgMzItYml0LCBhbmQgbWlnaHQgdmVyeSB3 ZWxsIGJlIGNob3NlbiBmcm9tIGEgbXVjaCBzbWFsbGVyIHNldCBvZiBpbmRleCB2YWx1ZXMu IFRoaXMgaW1wbGllcyB0aGF0IGl0IGlzIHF1aXRlIGxpa2VseSB0aGF0IGJvdGggdGhlIGlu aXRpYXRvciBhbmQgdGhlIHJlc3BvbmRlciB3aWxsIGNob29zZSB0aGUgc2FtZSBTUEkgdmFs dWUuIEluIHRoYXQgY2FzZSwgdGhlIGtleWluZyBtYXRlcmlhbCBmb3IgdGhlIHR3byBTQXMg KG9uZSBpbiBlYWNoIGRpcmVjdGlvbikgd2lsbCBiZSB0aGUgc2FtZSwgd2hpY2ggaW4gdHVy biBhbGxvd3MgYWxsIGtpbmQgb2Ygc3BsaWNpbmcgYXR0YWNrcy4gVGhpcyB3ZWFrbmVzcyBl eGlzdHMgd2hldGhlciBQRlMgd2FzIHVzZWQgb3Igbm90Lg0NV2UgcmVjb21tZW5kIHRoYXQg dGhlIGtleSBtYXRlcmlhbCBkZXJpdmF0aW9uIGJlIGNoYW5nZWQgdG8gYXZvaWQgdGhpcyBw cm9ibGVtLg0NXGl0ZW0gSW4gc2VjdGlvbiA1LjYsIHRoZSBOZXcgR3JvdXAgTW9kZSBpcyBz cGVjaWZpZWQuIFRoZSB0d28gSEFTSCB2YWx1ZXMgdXNlZCBmb3IgYXV0aGVudGljYXRpb24g YXJlIGNvbXB1dGVkIGluIGV4YWN0bHkgdGhlIHNhbWUgbWFubmVyLiBJZiB0aGUgU0EgaW4g dGhlIGZpcnN0IG1lc3NhZ2UgY29udGFpbnMgb25seSBhIHNpbmdsZSBwcm9wb3NhbCwgdGhl biB0aGUgU0EgcmVwbHkgd2lsbCBiZSBpZGVudGljYWwsIGFuZCBIQVNIKDIpIHdpbGwgYmUg aWRlbnRpY2FsIHRvIEhBU0goMSkuIEFzIGEgcmVzdWx0LCBIQVNIKDIpIGRvZXMgbm90IHJl YWxseSBwcm92aWRlIGFueSBhdXRoZW50aWNhdGlvbi4gSWYgYXV0aGVudGljYXRpb24gaXMg bmVlZGVkLCB0aGUgZGVmaW5pdGlvbnMgb2YgdGhlIEhBU0ggdmFsdWVzIHNob3VsZCBiZSBj aGFuZ2VkLiBJZiBhdXRoZW50aWNhdGlvbiBpcyBub3QgbmVlZGVkLCB0aGUgSEFTSCB2YWx1 ZXMgc2hvdWxkIGJlIHJlbW92ZWQuDQ1caXRlbSBXZSBtZW50aW9uZWQgZWFybGllciB0aGF0 IHRoZXJlIGlzIGFuIGFjdGl2ZSBhdHRhY2sgYWdpbnN0IHRoZSBJZGVudGl0eSBQcm90ZWN0 aW9uIEV4Y2hhbmdlIHByb3RvY29sIG9mIElTQUtNUC4gSW4gdGhpcyBhdHRhY2sgdGhlIGF0 dGFja2VyIHByZXRlbmRzIHRvIGJlIHRoZSByZXNwb25kZXIsIGFuZCBjb2xsZWN0cyB0aGUg aW5pdGlhdG9yJ3MgaWRlbnRpdHkgYmVmb3JlIGFiYW5kb25pbmcgdGhlIHByb3RvY29sIGV4 ZWN1dGlvbi4NDVRoaXMgd29ya3MgYWdhaW5zdCB0aGUgbWFpbiBtb2RlIGV4Y2hhbmdlcyB3 aXRoIHNpZ25hdHVyZSBhdXRoZW50aWNhdGlvbiBhbmQgd2l0aCBwcmUtc2hhcmVkIGtleSBh dXRoZW50aWNhdGlvbi4gSXQgZG9lcyBub3Qgd29yayBhZ2FpbnN0IHRoZSBwdWJsaWMta2V5 IGVuY3J5cHRpb24gYXV0aGVudGljYXRlZCB2ZXJzaW9ucy4NDVxlbmR7ZW51bWVyYXRlfQ0N DVxzZWN0aW9ue0dlbmVyYWwgY29tbWVudHN9DVdlIGhhdmUgdGhlIGZvbGxvd2luZyBnZW5l cmFsIGNvbW1lbnRzIG9uIElLRS4NDVxiZWdpbntlbnVtZXJhdGV9DVxpdGVtIFNlY3Rpb24g NSBkZWZpbmVzIGVuY29kaW5nIG9mIGdyb3VwIGVsZW1lbnRzIGluIHRoZSBLRSBwYXlsb2Fk LiBUaGlzIGlzIGRpZmZlcmVudCBmcm9tIG90aGVyIGdyb3VwIGVsZW1lbnQgZW5jb2Rpbmdz IGluIG90aGVyIHBhcnRzIG9mIHRoZSBwcm90b2NvbHMuIEdyb3VwIGVsZW1lbnQgZW5jb2Rp bmdzIHNob3VsZCBiZSBjb25zaXN0ZW50Lg0NXGl0ZW0gU2VjdGlvbiA1IHNwZWNpZmllcyB0 aGF0IHRoZSBmaW5hbCBtZXNzYWdlIG9mIHRoZSBhZ2dyZXNzaXZlIGV4Y2hhbmdlIG1heSBu b3QgYmUgcHJvdGVjdGVkIGJ5IHRoZSBJU0FLTVAgU0EuIFRoZSBuZXh0IHNlbnRlbmNlIHNh eXMgdGhhdCB0aGUgbWVzc2FnZSBkb2VzIG5vdCBoYXZlIHRvIGJlIGluIHRoZSBjbGVhci4g VGhlc2UgdHdvIHNlbnRlbmNlcyBzZWVtIHRvIGNvbnRyYWRpY3QgZWFjaCBvdGhlci4NDVxp dGVtIFNlY3Rpb24gNS4yIHNob3dzIHRoZSBtYWluIG1vZGUgYW5kIGFnZ3Jlc3NpdmUgbW9k ZSBwcm90b2NvbHMgZm9yIGF1dGhlbnRpY2F0aW9uIGJ5IHB1YmxpYy1rZXkgZW5jcnlwdGlv bi4gRXZlbiB0aG91Z2ggdGhlIG9yZGVyIG9mIHRoZSBmaWVsZHMgaW4gdGhlIGFjdHVhbCBp bXBsZW1lbnRhdGlvbiBjYW4gYmUgYXJiaXRyYXJ5LCBtb3N0IGRlc2NyaXB0aW9ucyB1c2Ug dGhlIHNhbWUgb3JkZXIgb2YgZmllbGRzLiBUaGUgb3JkZXIgb2YgS0UgYW5kIEhBU0goMSkg c2hvd24gaW4gdGhlIHR3byBwcm90b2NvbHMgYXJlIGRpZmZlcmVudC4gSWYgdGhlcmUgaXMg YSByZWFzb24gZm9yIHRoaXMsIGl0IHNob3VsZCBiZSBkb2N1bWVudGVkLiBPdGhlcndpc2Us IHdlIHN1Z2dlc3QgdGhhdCBhIHNpbmdsZSBvcmRlciBiZSB1c2VkIGZvciBjbGFyaXR5Lg0N XGl0ZW0gU2VjdGlvbiA1LjMgc2hvd3MgYSByZXZpc2VkIG1vZGUgb2YgdXNpbmcgcHVibGlj LWtleSBlbmNyeXB0aW9uIGZvciBhdXRoZW50aWNhdGlvbi4gRnJvbSB0aGUgcHJvcGVydGll cyBnaXZlbiwgdGhpcyBtb2RlIGlzIHN1cGVyaW9yIHRvIHRoZSBtb2RlIG9mIHNlY3Rpb24g NS4yLiBBcyB0aGVyZSBkb2VzIG5vdCBzZWVtIHRvIGJlIGEgcmVhc29uIHRvIHJldGFpbiB0 aGUgbW9kZXMgb2Ygc2VjdGlvbiA1LjIsIHRoZXNlIHNob3VsZCBiZSByZW1vdmVkLg0NXGl0 ZW0gU2VjdGlvbiA1LjMgcG9zZXMgYWRkaXRpb25hbCByZXN0cmljdGlvbnMgb24gdGhlIG9y ZGVyIG9mIHRoZSBwYXlsb2FkcyBpbiBhIG1lc3NhZ2UuIFRoaXMgaXMgb3Zlcmx5IGNvbXBs ZXguIFRoZSBvcmRlciBzaG91bGQgZWl0aGVyIGJlIHdlbGwtZGVmaW5lZCwgb3IgZnJlZSBv ZiByZXN0cmljdGlvbnMuIA0NXGl0ZW0gQXBwZW5kaXggQiBkZWZpbmVzIHRoZSBtZXRob2Rz IHVzZWQgdG8gc3RyZXRjaCB0aGUgb3V0cHV0IGxlbmd0aCBvZiB0aGUgUFJGLCBvciB0byBz dHJldGNoIG90aGVyIGtleWluZyBtYXRlcmlhbC4gVGhlc2UgbWV0aG9kcyBhcmUgc3Ryb25n IGVub3VnaCAoZ2l2ZW4gYSBnb29kIGVub3VnaCBQUkYpLCBidXQgY2FuIGJlIGltcHJvdmVk LiBFdmVuIHdpdGggYSB0aGVvcmV0aWNhbGx5IHBlcmZlY3QgUFJGLCB0aGUgY3VycmVudCBk ZWZpbml0aW9uIGRvZXMgbm90IGdlbmVyYXRlIHVuaWZvcm1seSBkaXN0cmlidXRlZCBvdXRw dXRzLg0NSW4gdGhlIGV4YW1wbGUgZ2l2ZW4gb24gcGFnZSAzNywgaWYgQkxPQ0sxLTggaXMg ZXF1YWwgdG8gQkxPQ0s5LTE2LCB0aGVuIGl0IG11c3QgYWxzbyBiZSBlcXVhbCB0byBCTE9D SzE3LTI0LiBUaGlzIGltcGxpZXMgdGhhdCBhYm91dCAkMl57LTY0fSQgb2YgYWxsIHBvc3Np YmxlIFNLRVlJRCB2YWx1ZXMgY2Fubm90IGJlIGdlbmVyYXRlZCBieSB0aGlzIGNvbnN0cnVj dGlvbi4NDVRoZSBzYW1lIGNyaXRpY2lzbSBhcHBsaWVzIHRvIHRoZSBzdHJldGNoaW5nIG9m IGVuY3J5cHRpb24ga2V5cyBmb3IgY2lwaGVycyB0aGF0IG5lZWQgYSBsb25nZXIga2V5LiBU aGlzIGlzIHNob3duIG9uIHBhZ2VzIDE1LCAxOSwgYW5kIDM4LiBUaGlzIGNvbnN0cnVjdGlv biBjYW5ub3QgZ2VuZXJhdGUgYWxsIHBvc3NpYmxlIHNlcXVlbmNlcyBvZiBLMSwgSzIsIGFu ZCBLMy4NDVRoZXNlIHN0cmV0Y2hpbmcgbWV0aG9kcyBjYW4gZWFzaWx5IGJlIGZpeGVkIGJ5 IGluY2x1ZGluZyBhIGNvdW50ZXIgaW4gdGhlIG1lc3NhZ2UgaW5wdXQgb2YgdGhlIFBSRi4g VGhpcyBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgaW4gZGVyaXZpbmcgdGhlIFNLRVlJRFxfZCwg U0tFWUlEXF9hLCBhbmQgU0tFWUlEXF9lIGZyb20gU0tFWUlELg0NVGhlIGRlcml2YXRpb24g b2YgdGhlIHZhbHVlcyBTS0VZSURcX2QsIFNLRVlJRFxfYSwgYW5kIFNLRVlJRFxfZSBmcm9t IFNLRVlJRCBjb3VsZCB1c2UgdGhlIHNhbWUgc3RyZXRjaGluZyBmdW5jdGlvbiwgd2hpY2gg d291bGQgc2ltcGxpZnkgdGhlIGltcGxlbWVudGF0aW9uLg0NXGl0ZW0gT24gcGFnZSAxNSwg YSBDQkMgZW5jcnlwdGlvbiBtb2RlIGlzIGRlZmluZWQuIFRoaXMgb25lIGlzIGRpZmZlcmVu dCBmcm9tIHRoZSBDQkMgZW5jcnlwdGlvbiBtb2RlcyB1c2VkIGJ5IHRoZSBJUHNlYyBFU1Ag cHJvdG9jb2wuIFRoZXJlIGRvZXMgbm90IHNlZW0gYSBnb29kIHJlYXNvbiBmb3IgaGF2aW5n IHR3byBpbmNvbXBhdGlibGUgQ0JDIG1vZGVzIGluIHVzZS4gTm90ZSB0aGF0IHRoaXMgQ0JD IG1vZGUgdXNlcyBhIGZpeGVkIElWIG9mIDAsIHdoZXJlYXMgdGhlIEVTUCBlbmNyeXB0aW9u IHVzZXMgYSByYW5kb21seSBnZW5lcmF0ZWQgSVYuDQ1FbmNyeXB0aW9uIHNob3VsZCBiZSBk ZWZpbmVkIGFzIGEgY2xlYXJseSBzZXBhcmF0ZSB0cmFuc2Zvcm1hdGlvbi4gVGhlIEVTUCBw YXJ0IG9mIHRoZSBzdGFuZGFyZCBpbmNsdWRlcyBjbGVhciBkZWZpbml0aW9ucyBvZiBzdWNo IGEgc2VwYXJhdGUgdHJhbnNmb3JtYXRpb24uIFdlIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBJ U0FLTVAgdXNlIHRoZSBzYW1lIGVuY3J5cHRpb24gZnVuY3Rpb25zIGFzIEVTUC4NDVxpdGVt IFRoZSBwcm90b2NvbCBpbiBzZWN0aW9uIDUuNCBjYW4gYmUgbWFkZSBtb3JlIGZsZXhpYmxl IGJ5IGFsbG93aW5nIGFuIGFkZGl0aW9uYWwgZGF0YSBmaWVsZCB0aGF0IHByb3ZpZGVzIHNv bWUga2luZCBvZiBpZGVudGlmaWVyIGZvciB0aGUgcHJlLXNoYXJlZCBrZXkuIFRoZSBhZ2dy ZXNzaXZlIGV4Y2hhbmdlIGFscmVhZHkgcHJvdmlkZXMgdGhlIGlkZW50aXR5IGluIHRoZSBj bGVhciwgYW5kIHRoaXMgaXMgZ2l2ZW4gYXMgYW4gYWR2YW50YWdlIG9mIGFnZ3Jlc3NpdmUg bW9kZS4gQWRkaW5nIGEga2V5LWlkZW50aWZpY2F0aW9uIGZpZWxkIGdpdmVzIHRoZSBtYWlu IG1vZGUgZXhjaGFuZ2UgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eS4NDVxpdGVtIEl0IGlzIG5v dCBxdWl0ZSBjbGVhciB3aGF0IHRoZSB1c2Ugb2YgdGhlIGNsaWVudCBpZGVudGl0aWVzIGFy ZSBpbiBRdWljayBtb2RlIChzZWUgcGFnZSAxNykuIFRoZXNlIGFyZSB1c2VkIHRvIGluZGlj YXRlIHRoZSBjbGllbnQgaWRlbnRpdGllcyB0aGF0IHdpbGwgYmUgdXNpbmcgdGhpcyBTQSwg YW5kIHRvIHJvdXRlIHRyYWZmaWMgZnJvbSB0aGVzZSBjbGllbnRzIHRvIHRoZSByaWdodCB0 dW5uZWwuIFdlIHNlZSBubyByZWFzb24gd2h5IGEgY2xpZW50IHdvdWxkIG5lZWQgdG8gc3Bl Y2lmeSBhIHBhcnRpY3VsYXIgdHVubmVsLCBvciBoYXZlIGhpcyBvd24gdHVubmVsLiBUaGlz IGlzIHRyYW5zcGFyZW50IHRvIHRoZSBjbGllbnQuIFdoYXQgdGhlIGNsaWVudCBjb3VsZCBy ZXF1ZXN0IGlzIGEgbGV2ZWwgb2Ygc2VydmljZSwgc3VjaCBhcyBlbmNyeXB0aW9uLCBvciBh IGNlcnRhaW4gbGV2ZWwgb2Ygc2VjdXJpdHkuIFdoZXRoZXIgdGhlIHRyYWZmaWMgb2YgdGhh dCBjbGllbnQgaXMgc2VudCB0aHJvdWdoIHRoZSBzYW1lIHR1bm5lbCBhcyBvdGhlciB0cmFm ZmljIGlzIHVuaW1wb3J0YW50LiANDVxpdGVtIFxjaXRle1JGQzI0MDl9IGNvbnNpc3RlbnRs eSBjb25mdXNlcyBhIGhhc2ggd2l0aCBhIFBSRi4gVGhlIG91dHB1dCBvZiBhIFBSRiBpcyBv ZnRlbiBjYWxsZWQgYSBIQVNIIHZhbHVlLiBUaGlzIG5vbnN0YW5kYXJkIHRlcm1pbm9sb2d5 IGlzIGNvbmZ1c2luZyB0byBvdGhlcnMuDQ1caXRlbSBUaGUgUXVpY2sgbW9kZSBuZWdvdGlh dGlvbiBwcm90b2NvbCBjb3VsZCBiZSBzaW1wbGlmaWVkIHNpZ25pZmljYW50bHkgYnkgdXNp bmcgdGhlIEVTUCB0cmFuc2Zvcm0gZnJvbSBJUHNlYyBmb3IgYm90aCBlbmNyeXB0aW9uIGFu ZCBhdXRoZW50aWNhdGlvbi4gVGhlIGN1cnJlbnQgc29sdXRpb24gdXNlcyBhIHNlcGFyYXRl IENCQyBlbmNyeXB0aW9uIG1vZGUsIGFuZCBhZCBob2MgbWVzc2FnZSBhdXRoZW50aWNhdGlv biBiYXNlZCBvbiBzcGVjaWZpYyBIQVNIIHZhbHVlcy4gVGhlIHByb3RvY29scyB3b3VsZCBi ZSBtdWNoIGVhc2llciB0byBhbmFseXplIGlmIHRoZSBJU0FLTVAgU0Egd2VyZSB1c2VkIHRv IHNldCB1cCBhbiBjb25maWRlbnRpYWwgYW5kIGF1dGhlbnRpY2F0ZWQgdHVubmVsICh3aXRo b3V0IHJlcGxheSBwcm90ZWN0aW9uKSwgYW5kIHRoZSBxdWljayBtb2RlIHdhcyBidWlsdCBv biB0b3Agb2YgdGhhdC4gQXMgZXZlcnkgSVNBS01QIGltcGxlbWVudGF0aW9uIG11c3QgYWxz byBzdXBwb3J0IElQc2VjLCB0aGlzIHdvdWxkIGFsc28gc2ltcGxpZnkgYW55IGltcGxlbWVu dGF0aW9uLg0NXGVuZHtlbnVtZXJhdGV9DQ1cY2hhcHRlcntDb25jbHVzaW9uc30NSVBzZWMg YW5kIElTQUtNUCBoYXZlIGJlZW4gYSBncmVhdCBkaXNhcHBvaW50bWVudCB0byB1cy4gVGhl eSBhcmUgZmFyIHRvbyBjb21wbGV4LCBhbmQgdGhlIGNvbXBsZXhpdHkgaGFzIGxlYWQgdG8g YSBsYXJnZSBudW1iZXIgb2YgYW1iaWd1aXRpZXMsIGluZWZmaWNpZW5jaWVzLCBhbmQgd2Vh a25lc3Nlcy4gSXQgaGFzIGJlZW4gdmVyeSBoYXJkIHRvIHBlcmZvcm0gYSBzZWN1cml0eSBh bmFseXNpcy4gV2UgZG8gbm90IGZlZWwgdGhhdCB3ZSBoYXZlIGJlZW4gYWJsZSB0byBldmFs dWF0ZSBhbGwgYXNwZWN0cyBvZiB0aGUgc3lzdGVtIHdpdGhpbiB0aGUgYXZhaWxhYmxlIHRp bWUgZnJhbWUuIA0NV2UgaGF2ZSBmb3VuZCBzZXZlcmFsIHNlcmlvdXMgc2VjdXJpdHkgd2Vh a25lc3NlcyBpbiBJUHNlYyBhbmQgSVNBS01QLiBXaGF0IHdvcnJpZXMgdXMgbW9yZSBpcyB0 aGUgY29tcGxleGl0eSBvZiB0aGUgc3lzdGVtcy4gSW4gb3VyIG9waW5pb24sIGN1cnJlbnQg aW1wbGVtZW50YXRpb24gbWV0aG9kcyBhcmUgbm90IGNhcGFibGUgb2YgY3JlYXRpbmcgYSBz ZWN1cmUgaW1wbGVtZW50YXRpb24gb2YgYSBzeXN0ZW0gYXMgY29tcGxleCBhcyB0aGlzLiAN DUZpeGluZyB0aGUgc3BlY2lmaWMgc2VjdXJpdHkgd2Vha25lc3NlcyB0aGF0IHdlIGZvdW5k IHdpbGwgYmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQuIEJ5IGl0c2VsZiB0aGlzIHdp bGwgbm90IG1ha2UgdGhlIHByb3RvY29scyBzZWN1cmUuIE91ciBhbmFseXNpcyB3YXMgaW4g bm8gd2F5IGV4aGF1c3RpdmUsIGFuZCB3ZSBleHBlY3QgdGhhdCB0aGVyZSBhcmUgbWFueSBt b3JlIHdlYWtuZXNzZXMgc3RpbGwgdG8gYmUgZm91bmQuIFdlIGZlZWwgdGhhdCB0aGUgb25s eSB3YXkgdG8gc2FsdmFnZSB0aGUgc3lzdGVtIGlzIHRvIHJpZ29yb3VzbHkgcmVkdWNlIHRo ZSBjb21wbGV4aXR5IGJ5IGVsaW1pbmF0aW5nIG9wdGlvbnMgYW5kIGltcHJvdmluZyB0aGUg bW9kdWxhcml6YXRpb24uIFRoaXMgd2lsbCByZXF1aXJlIGEgbWFqb3Igb3ZlcmhhdWwuDQ1C YXNlZCBvbiB0aGUgaW5mb3JtYXRpb24gdGhhdCB3ZSBoYXZlLCB3ZSBzdHJvbmdseSBkaXNj b3VyYWdlIHRoZSB1c2Ugb2YgSVBzZWMgZm9yIHByb3RlY3Rpb24gb2YgY29uZmlkZW50aWFs IGluZm9ybWF0aW9uLg0NDQ0lXGJpYmxpb2dyYXBoeXN0eWxle2FscGhhfQ0lXGJpYmxpb2dy YXBoeXtjb3VudGVycGFuZSxyZmN9DSUgQmV0aDogdGhpcyBiaWJsaW9ncmFwaHkgd2FzIGdl bmVyYXRlZCBhdXRvbWF0aWNhbGx5LiANJSAgICAgICBUaGVyZSBpcyBub3QgbXVjaCByZWFz b24gdG8gY2hlY2sgaXQuDXsNXG5ld2NvbW1hbmR7XG5vb3Bzb3J0fVsxXXt9XGRlZlx4e1xh bGxvd2JyZWFrfVxkZWZcc3tcc2xhc2h9DVxiZWdpbnt0aGViaWJsaW9ncmFwaHl9e01TU1Q5 OH0NDVxiaWJpdGVtW0FuZDkzYV17QTpXaHlGYWlsfQ1Sb3NzIEFuZGVyc29uLg1cbmV3Ymxv Y2sgV2h5IGNyeXB0b3N5c3RlbXMgZmFpbC4NXG5ld2Jsb2NrIEluIHtcZW0gUHJvY2VlZGlu Z3Mgb2YgdGhlIDFzdCB7QUNNfSBDb25mZXJlbmNlIG9uIENvbXB1dGVyDSAgQ29tbXVuaWNh dGlvbnMgU2VjdXJpdHkgJzkzfSwgcGFnZXMgMjE1LS0yMjcsIE5vdmVtYmVyIDE5OTMuDQ1c YmliaXRlbVtBbmQ5M2Jde0FuZDpIYXNoOTN9DVJvc3MgQW5kZXJzb24uDVxuZXdibG9jayBU aGUgY2xhc3NpZmljYXRpb24gb2YgaGFzaCBmdW5jdGlvbnMuDVxuZXdibG9jayBJbiB7XGVt IFByb2NlZWRpbmdzIG9mIHRoZSBGb3VydGgge0lNQX0gQ29uZmVyZW5jZSBvbiBDcnlwdG9n cmFwaHkNICBhbmQgQ29kaW5nfSwgcGFnZXMgODMtLTkzLCAxOTkzLg1cbmV3YmxvY2sgQXZh aWxhYmxlIGZyb20ge1x0dCBodHRwOi9ccyB3d3cuY2wuY2FtLmFjLnVrXHMgZnRwXHMgdXNl cnNccyByamExNFxzDSAgaGFzaC5wcy5afS4NDVxiaWJpdGVtW0ZLSzk2XXtTU0x2M05vdjk2 fQ1BbGFufk8uIEZyZWllciwgUGhpbGlwIEthcmx0b24sIGFuZCBQYXVsfkMuIEtvY2hlci4N XG5ld2Jsb2NrIFRoZSB7U1NMfSBwcm90b2NvbCwgdmVyc2lvbiAzLjAuDVxuZXdibG9jayBJ bnRlcm5ldCBkcmFmdCwgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IFdvcmtpbmcgR3JvdXAs IE5vdmVtYmVyfjE4LA0gIDE5OTYuDVxuZXdibG9jayBBdmFpbGFibGUgZnJvbSB7XHR0IGh0 dHA6L1xzIGhvbWUubmV0c2NhcGUuY29tXHMgZW5nXHMgc3NsMy99Lg0NXGJpYml0ZW1bR0s5 OF17UkZDMjQxMH0NUi5+R2xlbm4gYW5kIFMufktlbnQuDVxuZXdibG9jayBUaGUge05VTEx9 IGVuY3J5cHRpb24gYWxnb3JpdGhtIGFuZCBpdHMgdXNlIHdpdGgge0lQc2VjfSwgTm92ZW1i ZXINICAxOTk4Lg1cbmV3YmxvY2sgUkZDIDI0MTAuDQ1cYmliaXRlbVtIQzk4XXtSRkMyNDA5 fQ1ELn5IYXJraW5zIGFuZCBELn5DYXJyZWwuDVxuZXdibG9jayBUaGUge0l9bnRlcm5ldCBr ZXkgZXhjaGFuZ2UgKHtJS0V9KSwgTm92ZW1iZXIgMTk5OC4NXG5ld2Jsb2NrIFJGQyAyNDA5 Lg0NXGJpYml0ZW1bS0E5OGFde1JGQzI0MDJ9DVMufktlbnQgYW5kIFIufkF0a2luc29uLg1c bmV3YmxvY2sge0lQfSBhdXRoZW50aWNhdGlvbiBoZWFkZXIsIE5vdmVtYmVyIDE5OTguDVxu ZXdibG9jayBSRkMgMjQwMi4NDVxiaWJpdGVtW0tBOThiXXtSRkMyNDA2fQ1TLn5LZW50IGFu ZCBSLn5BdGtpbnNvbi4NXG5ld2Jsb2NrIHtJUH0gZW5jYXBzdWxhdGluZyBzZWN1cml0eSBw YXlsb2FkICh7RVNQfSksIE5vdmVtYmVyIDE5OTguDVxuZXdibG9jayBSRkMgMjQwNi4NDVxi aWJpdGVtW0tBOThjXXtSRkMyNDAxfQ1TLn5LZW50IGFuZCBSLn5BdGtpbnNvbi4NXG5ld2Js b2NrIFNlY3VyaXR5IGFyY2hpdGVjdHVyZSBmb3IgdGhlIGludGVybmV0IHByb3RvY29sLCBO b3ZlbWJlciAxOTk4Lg1cbmV3YmxvY2sgUkZDIDI0MDEuDQ1cYmliaXRlbVtLYWg2N117VGhl Q29kZWJyZWFrZXJzfQ1EYXZpZCBLYWhuLg1cbmV3YmxvY2sge1xlbSBUaGUgQ29kZWJyZWFr ZXJzLCBUaGUgU3Rvcnkgb2YgU2VjcmV0IFdyaXRpbmd9Lg1cbmV3YmxvY2sgTWFjbWlsbGFu IFB1Ymxpc2hpbmcgQ28uLCBOZXcgWW9yaywgMTk2Ny4NDVxiaWJpdGVtW01EOThde1JGQzI0 MDV9DUMufk1hZHNvbiBhbmQgTi5+RG9yYXN3YW15Lg1cbmV3YmxvY2sgVGhlIHtFU1B9IHtE RVMtQ0JDfSBjaXBoZXIgYWxnb3JpdGhtIHdpdGggZXhwbGljaXQge0lWfSwgTm92ZW1iZXIN ICAxOTk4Lg1cbmV3YmxvY2sgUkZDIDI0MDUuDQ1cYmliaXRlbVtNRzk4YV17UkZDMjQwM30N Qy5+TWFkc29uIGFuZCBSLn5HbGVubi4NXG5ld2Jsb2NrIFRoZSB1c2Ugb2Yge0hNQUMtTUQ1 LTk2fSB3aXRoaW4ge0VTUH0gYW5kIHtBSH0sIE5vdmVtYmVyIDE5OTguDVxuZXdibG9jayBS RkMgMjQwMy4NDVxiaWJpdGVtW01HOThiXXtSRkMyNDA0fQ1DLn5NYWRzb24gYW5kIFIufkds ZW5uLg1cbmV3YmxvY2sgVGhlIHVzZSBvZiB7SE1BQy1TSEEtMS05Nn0gd2l0aGluIHtFU1B9 IGFuZCB7QUh9LCBOb3ZlbWJlciAxOTk4Lg1cbmV3YmxvY2sgUkZDIDI0MDQuDQ1cYmliaXRl bVtNU1NUOThde1JGQzI0MDh9DUQufk1hdWdoYW4sIE0uflNjaGVydGxlciwgTS5+U2NobmVp ZGVyLCBhbmQgSi5+VHVybmVyLg1cbmV3YmxvY2sgSW50ZXJuZXQgc2VjdXJpdHkgYXNzb2Np YXRpb24gYW5kIGtleSBtYW5hZ2VtZW50IHByb3RvY29sICh7SVNBS01QfSksDSAgTm92ZW1i ZXIgMTk5OC4NXG5ld2Jsb2NrIFJGQyAyNDA4Lg0NXGJpYml0ZW1bT3JtOThde1JGQzI0MTJ9 DUgufk9ybWFuLg1cbmV3YmxvY2sgVGhlIHtPQUtMRVl9IGtleSBkZXRlcm1pbmF0aW9uIHBy b3RvY29sLCBOb3ZlbWJlciAxOTk4Lg1cbmV3YmxvY2sgUkZDIDI0MTIuDQ1cYmliaXRlbVtQ QTk4XXtSRkMyNDUxfQ1SLn5QZXJlaXJhIGFuZCBSLn5BZGFtcy4NXG5ld2Jsb2NrIFRoZSB7 RVNQfSB7Q0JDfS1tb2RlIGNpcGhlciBhbGdvcml0aG1zLCBOb3ZlbWJlciAxOTk4Lg1cbmV3 YmxvY2sgUkZDIDI0NTEuDQ1cYmliaXRlbVtQaXA5OF17UkZDMjQwN30NRC5+UGlwZXIuDVxu ZXdibG9jayBUaGUge0l9bnRlcm5ldCB7SVB9IHNlY3VyaXR5IGRvbWFpbiBvZiBpbnRlcnBy ZXRhdGlvbiBmb3Ige0lTQUtNUH0sDSAgTm92ZW1iZXIgMTk5OC4NXG5ld2Jsb2NrIFJGQyAy NDA3Lg0NXGJpYml0ZW1bVERHOThde1JGQzI0MTF9DVIuflRoYXllciwgTi5+RG9yYXN3YW15 LCBhbmQgUi5+R2xlbm4uDVxuZXdibG9jayB7SVB9IHNlY3VyaXR5IGRvY3VtZW50IHJvYWRt YXAsIE5vdmVtYmVyIDE5OTguDVxuZXdibG9jayBSRkMgMjQxMS4NDVxiaWJpdGVtW1dTOTZd e1dTOlNTTDMwfQ1EYXZpZCBXYWduZXIgYW5kIEJydWNlIFNjaG5laWVyLg1cbmV3YmxvY2sg QW5hbHlzaXMgb2YgdGhlIHtTU0x9IDMuMCBwcm90b2NvbC4NXG5ld2Jsb2NrIEluIHtcZW0g VGhlIFNlY29uZCB7VVNFTklYfSBXb3Jrc2hvcCBvbiBFbGVjdHJvbmljIENvbW1lcmNlDSAg UHJvY2VlZGluZ3N9LCBwYWdlcyAyOS0tNDAuIFVTRU5JWCBQcmVzcywgMTk5Ni4NXG5ld2Js b2NrIFJldmlzZWQgdmVyc2lvbiBhdmFpbGFibGUgZnJvbSB7XHR0IGh0dHA6L1xzIHd3dy5j b3VudGVycGFuZS5jb219Lg0NXGVuZHt0aGViaWJsaW9ncmFwaHl9DX0NDQ1cYXBwZW5kaXgN DVxjaGFwdGVye1doYXQgd2Ugd291bGQgbGlrZSB0byBjaGFuZ2UgaW4gSVBzZWN9DUluIHRo aXMgYXBwZW5kaXggd2Ugb3V0bGluZSBzb21lIG9mIHRoZSBtYWpvciBjaGFuZ2VzIHRoYXQg d2Ugd291bGQgbGlrZSB0byBzZWUgaW4gSVBzZWMuDQ1cYmVnaW57ZW51bWVyYXRlfQ1caXRl bSBFbGltaW5hdGUgdHJhbnNwb3J0IG1vZGUuIFR1bm5lbCBtb2RlIGNhbiBwcm92aWRlIGFs bCBuZWNlc3NhcnkgZnVuY3Rpb25hbGl0eS4gSWYgdGhlIHJlZHVjZWQgYmFuZHdpZHRoIHJl cXVpcmVtZW50IG9mIHRyYW5zcG9ydCBtb2RlIGlzIGNydWNpYWwsIGl0IGNhbiBiZSBhY2hp ZXZlZCBieSBhcHBseWluZyBhIHNwZWNpYWxpemVkIGNvbXByZXNzaW9uIHRvIHRoZSB0dW5u ZWwgcGF5bG9hZCAodXNpbmcgdGhlIG91dGVyIElQIGhlYWRlciBhcyB0ZW1wbGF0ZSkuDQ1c aXRlbSBFbGltaW5hdGUgdGhlIEFIIHByb3RvY29sLiBFU1AgY2FuIHByb3ZpZGUgdGhlIGF1 dGhlbnRpY2F0aW9uIG9mIHRoZSBpbm5lciBoZWFkZXIgaW4gdHVubmVsIG1vZGUuIElmIGF1 dGhlbnRpY2F0aW9uIG9mIHRoZSBvdXRlciBoZWFkZXIgaXMgcmVxdWlyZWQsIHRoZSBhdXRo ZW50aWNhdGlvbiBvZiBFU1AgY2FuIGJlIGV4dGVuZGVkIHRvIGNvdmVyIHRoaXMgYXMgd2Vs bC4gQXV0aGVudGljYXRpb24tb25seSBjb21tdW5pY2F0aW9ucyBhcmUgcHJvdmlkZWQgYnkg c2VsZWN0aW5nIHRoZSBOVUxMIGVuY3J5cHRpb24gYWxnb3JpdGhtLg0NXGl0ZW0gQWx3YXlz IGFwcGx5IGF1dGhlbnRpY2F0aW9uIHRvIGFueSBJUHNlYyBwcm9jZXNzZWQgcGFja2V0LiBF bmNyeXB0aW9uIHdpdGhvdXQgYXV0aGVudGljYXRpb24gaXMgaGFyZGx5IGV2ZXIgdXNlZnVs LiANDVxpdGVtIENoYW5nZSB0aGUgb3JkZXIgb2YgZW5jcnlwdGlvbiBhbmQgYXV0aGVudGlj YXRpb24uIFRoZSBhdXRoZW50aWNhdGlvbiBzaG91bGQgYmUgcGVyZm9ybWVkIG9uIHRoZSBw bGFpbnRleHQsIG5vdCBvbiB0aGUgY2lwaGVydGV4dC4NDVxpdGVtIE1ha2UgSVBzZWMgU0Fz IGJpZGlyZWN0aW9uYWwuDQ1caXRlbSBJbXByb3ZlIG1vZHVsYXJpemF0aW9uIG9mIElQc2Vj IGFuZCB0aGUgSVBzZWMgZG9jdW1lbnRhdGlvbi4NDVxpdGVtIFJldmlzZSBJU0FLTVAgYW5k IElLRSB0aG9yb3VnaGx5LiBUaGVyZSBhcmUgdG9vIG1hbnkgcHJvYmxlbXMgdG8gYmUgbGlz dGVkIGluZGl2aWR1YWxseSBoZXJlLg0NXGVuZHtlbnVtZXJhdGV9DQ1cZW5ke2RvY3VtZW50 fQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 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 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 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 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 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 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 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACDBwAAzQcAAM4HAADUBwAA4gcAACgIAACACAAA mggAAJsIAAAdDAAAUgwAAFMMAABUDAAAZQwAAHwMAADGDAAAxCIAABUjAAAgIwAARiMAAJIj AAC9NwAAvjcAAMM3AADJNwAA2DcAAAc4AAALOAAAFjgAACI4AABQOAAAozgAANM8AAByPQAA vD0AAM89AABcPgAAbT4AAAD27fbk9u3b7QDSydLJwMkAt663rgCl5KWcpZOKkwCTAIF4b3hm AAAAAAAAAAAAABEBCIEESAEABWiwijymB0gAABEBCIEESAEABWj6U0EmB0gAABEBCIEESAEA BWivijymB0gAABEBCIEESAEABWiuijymB0gAABEBCIEESAEABWj5U0EmB0gAABEBCIEESAEA BWitijymB0gAABEBCIEESAEABWisijymB0gAABEBCIEESAEABWirijymB0gAABEBCIEESAEA BWiqijymB0gAABEBCIEESAEABWipijymB0gAABEBCIEESAEABWioijymB0gAABEBCIEESAEA BWinijymB0gAABEBCIEESAEABWimijymB0gAABEBCIEESAEABWilijymB0gAABEBCIEESAEA BWj4U0EmB0gAABEBCIEESAEABWieijymB0gAABEBCIEESAEABWidijymB0gAAAAmAAQAAC4E AABHBAAAWwQAAG8EAABwBAAAfwQAAIAEAACnBAAA0gQAAAQFAAAlBQAAZAUAAJsFAACcBQAA rQUAALgFAAC5BQAA1gUAAFsHAABcBwAA9QoAAPYKAADHDAAAyAwAAOoNAADrDQAAOw8AADwP AABNDwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQ8AAB0ABAAALgQAAEcEAABbBAAAbwQAAHAEAAB/BAAAgAQAAKcE AADSBAAABAUAACUFAABkBQAAmwUAAJwFAACtBQAAuAUAALkFAADWBQAAWwcAAFwHAACSBwAA nQcAANQHAADiBwAAmQgAAPUKAAD2CgAAxwwAAMgMAADqDQAA6w0AADsPAAA8DwAATQ8AAE4P AABlDwAAZg8AANUPAADWDwAATBEAAE0RAAB8FAAAfRQAAMgVAADJFQAA5RcAAOYXAAAVGAAA FhgAACsYAAAsGAAAAhoAAAMaAAA+HAAAPxwAABAeAAARHgAAtCAAALUgAACTIwAAlCMAANsk AADcJAAAtScAALYnAACAKQAAgSkAAEQtAABFLQAAIC4AACEuAACRMAAAkjAAALIxAACzMQAA tDEAANcxAADCMwAAwzMAAL80AADANAAAVTcAAFY3AAC+NwAAwzcAAAc4AAAKOAAACzgAABY4 AAAfOAAAxTkAAMY5AADHOQAA9TkAAPY5AADrOwAA7DsAAO07AAAFPAAA/f39/f39/f39/f39 /f39/f39/f37+/v7+/v9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f37+/v7+/v7+/39/f39/f39AAAAAgEBAAMCDwAAY00PAABODwAA ZQ8AAGYPAADVDwAA1g8AAEwRAABNEQAAfBQAAH0UAADIFQAAyRUAAOUXAADmFwAAFRgAABYY AAArGAAALBgAAAIaAAADGgAAPhwAAD8cAAAQHgAAER4AALQgAAC1IAAAkyMAAJQjAADbJAAA 3CQAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEPAAAd3CQAALUnAAC2JwAAgCkAAIEpAABELQAARS0AACAuAAAhLgAA kTAAAJIwAACyMQAAszEAALQxAADXMQAAwjMAAMMzAAC/NAAAwDQAAFU3AABWNwAAxTkAAMY5 AADHOQAA9TkAAPY5AADrOwAA7DsAAO07AAAFPAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB0FPAAA1DwAALw9 AADPPQAAlz4AAJg+AADKQgAA60IAAAZDAAAZQwAAWkMAAFtDAADIRAAAyUQAAMpEAAD1RAAA cUUAAHlFAAA0RgAANUYAAEpGAABLRgAAjUcAAI5HAADnRwAA6EcAAPpHAACgSgAAoUoAAGZO AABnTgAAulIAALtSAABCUwAAT1MAAAFUAACeWAAAn1gAANZcAADXXAAApV0AAKZdAACaXgAA KF8AAClfAADYYgAAkGUAABZmAAAZZgAAGmYAACpmAAArZgAAqmYAAKtmAADJZgAAymYAAOtm AADUaAAA3mgAAPdoAAALaQAADGkAAB5pAAB7bAAAhmwAALlsAADBbAAAwmwAAMhsAADXbAAA 2mwAAPdsAAADbQAAD20AAGltAABqbQAAvm8AANZvAADXbwAA2G8AANlvAADdbwAA5m8AACBw AABJcAAAS3AAAExwAABIcgAASXIAAFlyAABacgAAdXIAAM90AAAMdQAAD3UAABB1AAArdQAA 33kAAOB5AACIegAAiXoAAP7+/v78/v7+/v78/Pz8/P7+/vz8/Pz8/Pz8/Pz8/Pz8/v7+/vz8 /Pz8/v78/v7+/vz8/P7+/vz8/v7+/vz8/v7+/v7+/v7+/v7+/P7+/v7+/v7+/v78/Pz8/Pz+ /v78/P7+/vwDAg8AAgEBZG0+AABuPgAAlj4AAJpAAACoQAAA10AAAChBAAAsQQAAOkEAAFVB AADuQQAA70EAAEBCAAD2QgAAAkMAADRDAABYQwAAWUMAAFFEAACGRAAAx0QAAHFFAAAYRgAA IEYAADNGAACETAAApUwAAPRMAABiTQAAdE0AAI1NAACkTQAA6U0AAGVOAAC9TwAAvk8AAMxP AADuTwAA8E8AAApQAAASUAAA9u0A7eTt5O3k29Lb0snSyeQAycAAwLfAAK6lnJOck6WKAIF4 gXiBbwAAAAAAAAAAAAAAAAAAAAAAABEBCIEESAEABWjkG0EmB0gAABEBCIEESAEABWjnG0Em B0gAABEBCIEESAEABWjjG0EmB0gAABEBCIEESAEABWi0ijymB0gAABEBCIEESAEABWjiG0Em B0gAABEBCIEESAEABWjhG0EmB0gAABEBCIEESAEABWizijymB0gAABEBCIEESAEABWiyijym B0gAABEBCIEESAEABWjgG0EmB0gAABEBCIEESAEABWjfG0EmB0gAABEBCIEESAEABWjeG0Em B0gAABEBCIEESAEABWjdG0EmB0gAABEBCIEESAEABWjcG0EmB0gAABEBCIEESAEABWixijym B0gAABEBCIEESAEABWiwijymB0gAABEBCIEESAEABWjbG0EmB0gAAAAoBTwAAJc+AACYPgAA WkMAAFtDAADIRAAAyUQAAMpEAAD1RAAANEYAADVGAABKRgAAS0YAAI1HAACORwAA50cAAOhH AAD6RwAAoEoAAKFKAABmTgAAZ04AALpSAAC7UgAAnlgAAJ9YAADWXAAA11wAAKVdAACmXQAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAADDwBDJAEAAQ8AAB0SUAAAFVAAABtQAAAfUAAAJFAAADRQAAA3UAAAWVAAAGlQAACeUAAA n1AAAN5QAADrUAAA7FAAAANRAAAIUQAAFlEAABtRAAAiUQAAL1EAANdRAAAhUgAATVIAAE5S AABPUgAAUFIAAAxTAABCUwAAT1MAAFBTAABUUwAAc1MAAHZTAAB7UwAAjVMAAI5TAACcUwAA nVMAAAFUAAACVAAAA1QAAClUAABTVAAAVFQAAFVUAAAmVQAATlUAAFlVAAB6VQAAsFUAAGlW AABxVgAA9u3k7fbt5O3b0tvJ7fbJ9sn2yQDSwNLA0gDAt8Cupa6lrqWuwKWcpZyTnKUAnIqc igCKAAAAAAAAAAAAAAAAAAAAAAARAQiBBEgBAAVoDBxBJgdIAAARAQiBBEgBAAVoEBxBJgdI AAARAQiBBEgBAAVoCxxBJgdIAAARAQiBBEgBAAVoChxBJgdIAAARAQiBBEgBAAVoCBxBJgdI AAARAQiBBEgBAAVoAVRBJgdIAAARAQiBBEgBAAVoBxxBJgdIAAARAQiBBEgBAAVoAhxBJgdI AAARAQiBBEgBAAVoBRxBJgdIAAARAQiBBEgBAAVoAxxBJgdIAAARAQiBBEgBAAVo4xtBJgdI AAARAQiBBEgBAAVo5BtBJgdIAAARAQiBBEgBAAVoBBxBJgdIAAAAM3FWAAByVgAAkVYAAKdW AACpVgAAtVYAAMBWAADBVgAAJ1cAAOtYAADsWAAA71gAAC1ZAAA2WQAAQlkAAE9ZAABZWQAA XFkAAFVdAACkXQAA2mAAAL9hAADEYQAAxWEAAD1iAABEYgAAiWIAAIpiAADCYgAAy2IAANhi AAAIYwAACmMAABZjAAAbYwAAImMAAC1jAABSYwAAWmMAAFxjAACsYwAAhmQAAIlkAABAZQAA QmUAAFJlAABhZQAAF2YAAPbt5Pbb9tvkANvS28nAycDbAMAAt663rqWut6WcpZyTnJOck5yK nJOBigCKeIp4ABEBCIEESAEABWgcHEEmB0gAABEBCIEESAEABWgeHEEmB0gAABEBCIEESAEA BWgbHEEmB0gAABEBCIEESAEABWgdHEEmB0gAABEBCIEESAEABWgaHEEmB0gAABEBCIEESAEA BWgZHEEmB0gAABEBCIEESAEABWgYHEEmB0gAABEBCIEESAEABWgXHEEmB0gAABEBCIEESAEA BWgVHEEmB0gAABEBCIEESAEABWgUHEEmB0gAABEBCIEESAEABWgTHEEmB0gAABEBCIEESAEA BWgQHEEmB0gAABEBCIEESAEABWgNHEEmB0gAABEBCIEESAEABWgMHEEmB0gAABEBCIEESAEA BWgPHEEmB0gAAAAvpl0AAChfAAApXwAAGWYAABpmAAAqZgAAK2YAAMlmAADKZgAA62YAAAtp AAAMaQAAHmkAAGltAABqbQAAS3AAAExwAABIcgAASXIAAFlyAABacgAAdXIAAA91AAAQdQAA K3UAAIh6AACJegAAa38AAGx/AACEfwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAADDwBDJAEAAQ8AAB0XZgAAGGYAAJBmAACqZgAA q2YAAMhmAAABaAAAvWgAANRoAADeaAAACmkAAKhrAACpawAA92sAAHtsAACGbAAAqmwAAK9s AACwbAAAuWwAAMFsAADCbAAAyGwAANdsAADabAAA92wAAANtAAAQbQAAaG0AAIVuAACJbgAA jW4AAAxvAAC+bwAA1m8AANdvAADmbwAASXAAAEpwAAD0cQAAR3IAAH1zAACicwAAdHQAAPYA 7eTtANvS5NIA0snAt8CuwK6lrreupa6lrpwAk4oAiqWKpYGKAHgAbwAAAAARAQiBBEgBAAVo JxxBJgdIAAARAQiBBEgBAAVoJhxBJgdIAAARAQiBBEgBAAVoSVtBRgdIAAARAQiBBEgBAAVo JRxBJgdIAAARAAiBY0gBAGRoJRxBJmdIAAARAQiBBEgBAAVoJBxBJgdIAAARAQiBBEgBAAVo SFtBRgdIAAARAQiBBEgBAAVoIxxBJgdIAAARAQiBBEgBAAVoR1tBRgdIAAARAQiBBEgBAAVo IhxBJgdIAAARAQiBBEgBAAVoIRxBJgdIAAARAQiBBEgBAAVoIBxBJgdIAAARAQiBBEgBAAVo HxxBJgdIAAARAQiBBEgBAAVoBFRBJgdIAAARAQiBBEgBAAVoHBxBJgdIAAARAQiBBEgBAAVo GxxBJgdIAAAAK3R0AADPdAAADHUAAA51AAAIeAAACXgAALx4AAAleQAAJnkAACd5AAAqeQAA MXkAAN95AADgeQAAHXoAAId6AABEfQAARn0AAOJ9AADnfQAA6H0AAEh+AABNfgAATn4AAJh+ AACjfgAAzX4AAAV/AAAffwAAIH8AACJ/AABqfwAAPIIAAD2CAAA+ggAAaIIAANuCAAD0ggAA 9YIAAJiDAADpgwAA9u32AOTb0snSydLJwMm3AK6lnKWck5yTipOBk4qTigCKeIp4b3hvZhEB CIEESAEABWhJHEEmB0gAABEBCIEESAEABWhDHEEmB0gAABEBCIEESAEABWhAHEEmB0gAABEB CIEESAEABWhLW0FGB0gAABEBCIEESAEABWg7HEEmB0gAABEBCIEESAEABWg6HEEmB0gAABEB CIEESAEABWg5HEEmB0gAABEBCIEESAEABWg4HEEmB0gAABEBCIEESAEABWgtHEEmB0gAABEB CIEESAEABWgsHEEmB0gAABEBCIEESAEABWhKW0FGB0gAABEBCIEESAEABWgrHEEmB0gAABEB CIEESAEABWgqHEEmB0gAABEBCIEESAEABWgpHEEmB0gAABEBCIEESAEABWgoHEEmB0gAABEB CIEESAEABWhJW0FGB0gAABEBCIEESAEABWgnHEEmB0gAAAAoiXoAAPR9AACTfgAAzX4AAAV/ AABpfwAAa38AAGx/AACEfwAAIoAAACOAAAAkgAAAQoAAAEOAAABdgAAA6oMAAOuDAADsgwAA 9IMAAA+EAAA6hAAAZIQAAGeEAABohAAAIYkAAC2JAAAwiQAAMYkAAH+JAACAiQAAoIkAAOSO AADmjgAAR48AAE+PAABtjwAAcI8AAIOPAACSjwAAlo8AAJyPAACdjwAAoI8AABGQAAAjkAAA JJAAACWQAAAxkAAAOJAAAD2QAAA+kAAAWJAAAHiQAACQkAAAkZAAAJOQAACYkAAAn5AAAKaQ AADWkAAA15AAANiQAADbkAAAD5EAABSRAAAVkQAATpEAAE+RAABUkQAAbZEAAJeRAACYkQAA mZEAAJqRAACbkQAAvZEAAOmUAADqlAAAApUAALKVAACzlQAAtJUAANSVAAC7lwAAvJcAAFKY AABTmAAAx5gAAMiYAAACmQAACJkAAAmZAAAUmQAAFpkAABeZAAAamQAAI5kAAC2ZAAAzmQAA P5kAAEOZAAD+/v7+/v78/Pz8/Pz8/P7+/v7+/v7+/P7+/vz8/Pz+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/Pz8/Pz8/Pz8/Pz8/P7+/v7+/v7+/v7+/v7+ AwIPAAIBAWSEfwAAIoAAACOAAAAkgAAAQoAAAEOAAABdgAAAZ4QAAGiEAAAwiQAAMYkAAH+J AACAiQAAoIkAAJqRAACbkQAAvZEAAOmUAADqlAAAApUAALKVAACzlQAAtJUAANSVAAC7lwAA vJcAAFKYAABTmAAAOpwAADucAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHemDAADqgwAAOoQAAGSEAABmhAAA QIgAAEKIAABSiAAAXYgAAPKIAAAhiQAALYkAAC+JAADkjgAA5o4AAEePAABPjwAAbY8AAHCP AACDjwAAko8AAJaPAACgjwAAkJAAAJGQAACTkAAAn5AAAKaQAADWkAAA15AAAFSRAACXkQAA mJEAAPbt5NsA0snAybeutwClnJOck5yKk4qBeIF4b3hvZl1UAAAAABEBCIEESAEABWhHHEEm B0gAABEBCIEESAEABWhYHEEmB0gAABEBCIEESAEABWhXHEEmB0gAABEBCIEESAEABWhWHEEm B0gAABEBCIEESAEABWhVHEEmB0gAABEBCIEESAEABWhUHEEmB0gAABEBCIEESAEABWhTHEEm B0gAABEBCIEESAEABWhRW0FGB0gAABEBCIEESAEABWhOHEEmB0gAABEBCIEESAEABWhFHEEm B0gAABEBCIEESAEABWhQW0FGB0gAABEBCIEESAEABWhNHEEmB0gAABEBCIEESAEABWhMHEEm B0gAABEBCIEESAEABWhLHEEmB0gAABEBCIEESAEABWhKHEEmB0gAABEBCIEESAEABWhAHEEm B0gAABEBCIEESAEABWhOW0FGB0gAABEBCIEESAEABWhNW0FGB0gAABEBCIEESAEABWhDHEEm B0gAAAAgmJEAAJmRAABJlAAAapQAAG2UAACrlAAA6JQAAMeYAADImAAAApkAAAiZAAAJmQAA FJkAAD+ZAABDmQAAVZkAAGmZAABrmQAAwZoAAMKaAACumwAA/psAADmcAABWnQAAWJ0AAHyd AAB9nQAAxp0AAMedAADTnQAAD54AAHWeAABqowAAfqMAAJGjAACZowAAnKMAAIekAADFpAAA Y6UAAE6mAAD2APbt9uQA29LJ0sDSydLJ0gC3wK6lAJyTt5O3k7eKAIF4b4EAgW9mEQEIgQRI AQAFaGQcQSYHSAAAEQEIgQRIAQAFaGMcQSYHSAAAEQEIgQRIAQAFaFhbQUYHSAAAEQEIgQRI AQAFaGIcQSYHSAAAEQEIgQRIAQAFaGEcQSYHSAAAEQEIgQRIAQAFaF4cQSYHSAAAEQEIgQRI AQAFaFwcQSYHSAAAEQEIgQRIAQAFaFdbQUYHSAAAEQEIgQRIAQAFaFZbQUYHSAAAEQEIgQRI AQAFaF8cQSYHSAAAEQEIgQRIAQAFaGAcQSYHSAAAEQEIgQRIAQAFaFVbQUYHSAAAEQEIgQRI AQAFaFkcQSYHSAAAEQEIgQRIAQAFaFgcQSYHSAAAEQEIgQRIAQAFaEccQSYHSAAAEQEIgQRI AQAFaFYcQSYHSAAAEQEIgQRIAQAFaEYcQSYHSAAAAChDmQAAVZkAAGmZAABqmQAAa5kAAMGa AADCmgAAxpoAAMqaAADVmgAA2poAAOGaAADrmgAA8JoAAPWaAAD2mgAABJsAAAabAAAHmwAA C5sAACKbAABUmwAAVpsAAFebAABZmwAAWpsAAFubAABcmwAAX5sAAGCbAABymwAAk5sAAKGb AACimwAArpsAAK+bAACwmwAAsZsAAMWbAAD+mwAAGZwAADmcAAA6nAAAO5wAAHaeAAB3ngAA op4AAH+gAACAoAAAaqMAAH6jAACCowAAh6MAAIijAACRowAAmaMAAJyjAACHpAAAk6QAAJSk AACWpAAAxaQAABqlAAAbpQAAL6UAADelAABIpQAASqUAAEulAABPpQAAY6UAAIWlAACJpQAA iqUAAMylAADNpQAA0qUAAOelAAARpgAAFqYAABemAAAYpgAAGaYAABqmAABOpgAAT6YAAFum AAB2pgAAe6YAAHymAAB/pgAAm6YAAJymAADwpgAAEacAABSnAAAopwAAKqcAAHCpAAByqQAA rqkAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/vz8/Pz8/P7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v4DAg8A AgEBZDucAAB2ngAAd54AAKKeAAB/oAAAgKAAAHirAAB5qwAAt6wAALisAAAjsgAAJLIAAD+y AACUsgAAlbIAAKeyAAD2tAAA97QAAJ+3AACgtwAAnLoAAJ26AABwvgAAcb4AANC/AADRvwAA DsYAAA/GAACkxgAApcYAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdTqYAAE+mAABbpgAAdqYAAHumAAB8pgAA m6YAAPCmAAAopwAAKqcAAHCpAACuqQAAt6kAAM2pAADVqQAA8qkAAPepAAAAqgAAD6oAADqq AABfqgAAjKoAAKCqAADJqgAAP6sAAEirAAB0qwAAdqsAAHerAABjrAAAk6wAAJSsAACVrAAA lqwAALasAADFrgAAEK8AAB6vAAAprwAATa8AAGOvAABmrwAAZ68AACywAABYsAAArbAAAPbt 5Pbk9tvS9gD2yfbJ9sn2yfbJwMnAt663pfYApa6lrqUAnJOcipyBnIF4kwAAAAAAAAAAAAAA EQEIgQRIAQAFaGocQSYHSAAAEQEIgQRIAQAFaGkcQSYHSAAAEQEIgQRIAQAFaGwcQSYHSAAA EQEIgQRIAQAFaGscQSYHSAAAEQEIgQRIAQAFaGgcQSYHSAAAEQEIgQRIAQAFaGccQSYHSAAA EQEIgQRIAQAFaF9bQUYHSAAAEQEIgQRIAQAFaF5bQUYHSAAAEQEIgQRIAQAFaF1bQUYHSAAA EQEIgQRIAQAFaGYcQSYHSAAAEQEIgQRIAQAFaFpbQUYHSAAAEQEIgQRIAQAFaFlbQUYHSAAA EQEIgQRIAQAFaGIcQSYHSAAAEQEIgQRIAQAFaGQcQSYHSAAAEQEIgQRIAQAFaGUcQSYHSAAA AC2uqQAAt6kAAM2pAADVqQAA8qkAAPepAAAAqgAAD6oAADqqAABfqgAAg6oAAIyqAACgqgAA pqoAAKeqAACoqgAAyaoAAMqqAADSqgAA5aoAAD+rAABIqwAAWasAAGurAAB0qwAAdqsAAHer AAB4qwAAeasAAGOsAABwrAAAiqwAAJKsAACTrAAAlKwAAJWsAACWrAAAtqwAALesAAC4rAAA xa4AANOuAAAQrwAAGq8AAB6vAAAprwAATa8AAGOvAABmrwAAZ68AAGuvAACwrwAAsa8AALev AAC4rwAA868AAA2wAAAssAAALbAAAC6wAAAzsAAAWLAAAIywAACTsAAAnLAAAK2wAACysAAA zrAAAM+wAADpsAAA9LAAAP2wAAAosQAALbEAAC6xAAB3sQAAeLEAAHuxAADMsQAAz7EAANWx AADXsQAA2LEAANyxAADgsQAADrIAABOyAAAUsgAAIrIAACOyAAAksgAAP7IAAJSyAACVsgAA p7IAAPa0AAD3tAAAn7cAAKC3AACcugAAnboAAP7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /vz+/v7+/v7+/v7+/P7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/Pz8/Pz8/Pz8/PwDAg8AAgEBZK2wAACysAAAzrAAAM+wAAB3sQAAe7EAAA6y AAATsgAAFLIAACKyAAC6swAA+bMAANq0AAD1tAAAOrcAAE23AACetwAAL7kAAJi5AACbugAA sr0AALy9AADBvQAA370AAOW9AAD3vQAA/L0AACW+AABvvgAAyL8AAMq/AADOvwAAz78AAKbD AACnwwAAL8QAAPbt5Nvk0snSyQDAt64ApZwArpMAioGKgYqBioEAeG9mAG9dAAAAAAAAABEB CIEESAEABWiFHEEmB0gAABEBCIEESAEABWiDHEEmB0gAABEBCIEESAEABWiEHEEmB0gAABEB CIEESAEABWiCHEEmB0gAABEBCIEESAEABWh1HEEmB0gAABEBCIEESAEABWh0HEEmB0gAABEB CIEESAEABWhxHEEmB0gAABEBCIEESAEABWhzHEEmB0gAABEBCIEESAEABWhyHEEmB0gAABEB CIEESAEABWhwHEEmB0gAABEBCIEESAEABWhvHEEmB0gAABEBCIEESAEABWhuHEEmB0gAABEB CIEESAEABWhtHEEmB0gAABEBCIEESAEABWhqHEEmB0gAABEBCIEESAEABWhsHEEmB0gAABEB CIEESAEABWhpHEEmB0gAABEBCIEESAEABWhrHEEmB0gAABEBCIEESAEABWhgW0FGB0gAAAAj EgAVAAoAAQBbAA8AAgADAAAAAwAoAABA8f8CACgAAAAGAE4AbwByAG0AYQBsAAAAAgAAAAgA Q0oYAG1ICQQAAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQA IABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAANABaQAEA8gA0AAAA CgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgAPAAwAQ0oUAE9KBABRSgQAJAAvAAEAAgEkAAAA BABMAGkAcwB0AAAACgAQAA+EaAERhJj+AAAqAEIAAQASASoAAAAJAEIAbwBkAHkAIABUAGUA eAB0AAAABgARABSkeAAAADwAQwABACIBPAAAABAAQgBvAGQAeQAgAFQAZQB4AHQAIABJAG4A ZABlAG4AdAAAAAoAEgAPhGgBFKR4AAAAMgAcAAEAMgEyAAAADQBOAG8AcgBtAGEAbAAgAEkA bgBkAGUAbgB0AAAABgATAA+E0AIAACgAVUCiAEEBKAAAAAkASAB5AHAAZQByAGwAaQBuAGsA AAAGAD4qAUIqAgAAAAAf+AAAAwAAggIAAwD/////EgAAAAQh//8BAAAAAAAAIf//AgAAAAAA BCH//wMAAAAAAAAh//8EAAAAAAAEIf//BQAAAAAAACD//wYAAAAAAAQh//8HAAAAAAAAIP// CAAAAAAABCD//wkAAAAAAAAg//8KAAAAAAAEIP//CwAAAAAAACD//wwAAAAAAAQg//8NAAAA AAAAIP//DgAAAAAABCD//w8AAAAAAAAg//8QAAAAAAAGIP//EQAAAAAAACD//xIAAAAAAAAA AABOCwAAPhgAALwmAABBNAAAlUEAALtOAACDXgAATGwAAGt7AACUiQAAsZcAAAynAAAxtQAA 28QAABHTAABA4gAAa/EAAB/4AAAAABcAAAABAAEAAAACAIgCAAADAIQBAAAEAJ8AAAAFAOMF AAAGAJYDAAAHAPwBAAAIAAEAAAAJAAYEAAAKAIkAAAALAGwAAAAMAGwBAAANAAEAAAAOAJIC AAAPAJkAAAAQAHcAAAARAAAAAAAAAAAALgAAAEcAAABbAAAAbwAAAHAAAAB/AAAAgAAAAKcA AADSAAAABAEAACUBAABkAQAAmwEAAJwBAACtAQAAuAEAALkBAADWAQAAWwMAAFwDAAD1BgAA 9gYAAMcIAADICAAA6gkAAOsJAAA7CwAAPAsAAE0LAABOCwAARCkAAEUpAAAgKgAAISoAAJEs AACSLAAAsi0AALMtAAC0LQAA1y0AAMIvAADDLwAAvzAAAMAwAABVMwAAVjMAAMU1AADGNQAA xzUAAPU1AAD2NQAA6zcAAOw3AADtNwAABTgAAJc6AACYOgAAWj8AAFs/AADIQAAAyUAAAMpA AAD1QAAANEIAADVCAABKQgAAS0IAAI1DAACOQwAA50MAAOhDAAD6QwAAoEYAAKFGAABmSgAA Z0oAALpOAAC7TgAAnlQAAJ9UAADWWAAA11gAAKVZAACmWQAAKFsAAClbAAAZYgAAGmIAACpi AAArYgAAyWIAAMpiAADrYgAAC2UAAAxlAAAeZQAAaWkAAGppAABLbAAATGwAAEhuAABJbgAA WW4AAFpuAAB1bgAAD3EAABBxAAArcQAAiHYAAIl2AABrewAAbHsAAIR7AAAifAAAI3wAACR8 AABCfAAAQ3wAAF18AABngAAAaIAAADCFAAAxhQAAf4UAAICFAACghQAAmo0AAJuNAAC9jQAA 6ZAAAOqQAAACkQAAspEAALORAAC0kQAA1JEAALuTAAC8kwAAUpQAAFOUAAA6mAAAO5gAAHaa AAB3mgAAopoAAH+cAACAnAAAeKcAAHmnAAC3qAAAuKgAACSuAAAlrgAAQK4AAJWuAACWrgAA qK4AAPewAAD4sAAAoLMAAKGzAACdtgAAnrYAAHG6AAByugAASb0AAEq9AADbxAAA3MQAAHHF AAByxQAASMkAAEnJAADPzAAA0MwAAHDOAABxzgAAUNAAAFHQAAB00gAAddIAAKPVAACk1QAA 19gAANjYAABQ2wAAUdsAAO3eAADu3gAA2eIAANriAADj5AAA5OQAAEHoAABC6AAAfOsAAH3r AAC/7QAAwO0AAOLxAADj8QAA7PIAAO3yAADR9AAA0vQAAOL0AADj9AAA+fQAAEX3AABG9wAA 8vcAAPP3AAAe+AAAIfgAAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAAMAACCJQAA+zECAAAB AACCJQAA+zECAAAGAACCJQAA+zECAAABAACCJQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA +zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAABAACCJQAA+zECAAADAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA +zECAAABAACCJQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA +zECAAAJAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA+zECAAAQ AACCJQAA+zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAACAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAAB AACCJQAA+zECAAAPAACCJQAA+zECAAABAACCJQAA+zECAAAUAACCJQAA+zECAAABAACCJQAA +zECAAAOAACCJQAA+zECAAABAACCJQAA+zECAAADAACCJQAA+zECAAABAACCJQAA+zECAAAF AACCJQAA+zECAAABAACCJQAA+zECAAAXAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAACAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAI AACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAPAACCJQAA+zECAAABAACCJQAA +zECAAAKAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAASAACCJQAA+zECAAABAACCJQAA+zECAAAQAACCJQAA+zECAAAB AACCJQAA+zECAAABAACCJQAA+zECAAACAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAOAACCJQAA+zECAAAB AACCJQAA+zECAAAQAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAAbAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAL AACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAADAACCJQAA+zECAAABAACCJQAA +zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA+zECAAAC AACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAABAACCJQAA+zECAAAIAACCJQAA +zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA+zECAAAl AACCJQAA+zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAASAACCJQAA +zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAACAACCJQAA+zECAAABAACCJQAA+zECAAAB AACCJQAA+zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA +zECAAAKAACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAABAACCJQAA+zECAAAK AACCJQAA+zECAAABAACCJQAA+zECAAAaAACCJQAA+zECAAABAACCJQAA+zECAAACAACCJQAA +zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAABAACCJQAA+zECAAAMAACCJQAA+zECAAAB AACCJQAA+zECAAAGAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA +zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAALAACCJQAA+zECAAABAACCJQAA+zECAAAL AACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA +zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAAB AACCJQAA+zECAAIAAAAAAAAAAAAAAAABAACCJQAA+zECAAALAACCJQAA+zECAAABAACCJQAA +zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAAOAACCJQAA+zECAAABAACCJSEPAQDCEAEA xBABAOQRAQDlEQEA/RMBAP4TAQB+GAEAfxgBAAMaAQAEGgEA6BsBAOkbAQAYHQEAGR0BAL0f AQC+HwEA6B8BAOkfAQC1IQEAtiEBAFwjAQBdIwEAbSMBAG4jAQCMIwEAziMBAM8jAQDhIwEA 4iMBACwnAQAtJwEAxygBAMgoAQCrKgEArCoBAH4sAQCALAEAdS0BAHYtAQCTLgEAlC4BAGcw AQBoMAEADzEBABAxAQCVMQEAljEBAH4zAQB/MwEAFjQBABc0AQA5NgEAOjYBAAg5AQAJOQEA GTkBABo5AQAbOQEANjkBADc5AQBJOQEASjkBAN46AQDfOgEAgjsBAIM7AQCTOwEAlDsBAME7 AQCNPAEAjjwBAKk8AQC7PAEAKj4BACs+AQDgPgEA4T4BAEw/AQBNPwEAskABALNAAQBLQgEA TEIBAKtDAQCsQwEAaUQBAGpEAQB6RAEAe0QBAJlEAQCaRAEAVUUBAFZFAQB0RQEArUYBAK5G AQDdRgEAM0sBADRLAQBFSwEA/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/QAAAwIPAABkbiMBAIwjAQDOIwEAzyMBAOEjAQDiIwEALCcBAC0nAQDHKAEA yCgBAKsqAQCsKgEAfiwBAIAsAQB1LQEAdi0BAJMuAQCULgEAZzABAGgwAQAPMQEAEDEBAJUx AQCWMQEAfjMBAH8zAQAWNAEAFzQBADk2AQA6NgEA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB06NgEACDkBAAk5 AQAZOQEAGjkBABs5AQA2OQEANzkBAEk5AQBKOQEA3joBAN86AQCCOwEAgzsBAJM7AQCUOwEA wTsBAI08AQCOPAEAqTwBALs8AQAqPgEAKz4BAOA+AQDhPgEATD8BAE0/AQCyQAEAs0ABAEtC AQD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AAAAAAAAAAAAAAABDwAAHUtCAQBMQgEAq0MBAKxDAQBpRAEAakQBAHpEAQB7RAEAmUQBAJpE AQBVRQEAVkUBAHRFAQCtRgEArkYBAN1GAQAzSwEANEsBAEVLAQDJTAEAykwBAPFNAQDyTQEA q04BAK5OAQDOTgEA0U4BAPpOAQD9TgEAIE8BAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdRUsBAMlMAQDKTAEA 8U0BAPJNAQCrTgEArk4BAM5OAQDRTgEA+k4BAP1OAQAgTwEAI08BADBRAQAxUQEAEVIBABJS AQCyUwEAs1MBAMxTAQDtVQEA7lUBABJWAQATVgEAOlgBADtYAQCCWgEAg1oBADpcAQA7XAEA ZFwBAFNdAQBUXQEA+l0BAPtdAQAcXgEAYWEBAGJhAQAZYgEAGmIBANNiAQDUYgEA82IBACll AQAqZQEA2WYBANpmAQBDaAEARGgBAFxoAQCraAEArGgBANBoAQCXbAEAmGwBANdtAQDYbQEA N3ABADhwAQBNcAEAiXEBAIpxAQBKcwEAS3MBAHNzAQCFcwEAxXQBAMZ0AQDxdgEA8nYBAGN4 AQBkeAEAmXkBAJp5AQDeewEA33sBAEF+AQBCfgEAkn4BAJN+AQCGgAEAh4ABAIeBAQCIgQEA RIIBAEWCAQBVggEAVoIBAFeCAQByggEAoYIBAKKCAQC0ggEAfoMBAH+DAQBvhAEAcIQBACGG AQAihgEALIcBAC2HAQD9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39AAADAg8AAGQgTwEAI08BADBRAQAxUQEAEVIBABJSAQCyUwEAs1MBAMxTAQDtVQEA 7lUBABJWAQATVgEAOlgBADtYAQCCWgEAg1oBADpcAQA7XAEAZFwBAFNdAQBUXQEA+l0BAPtd AQAcXgEAYWEBAGJhAQAZYgEAGmIBANNiAQD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHdNiAQDUYgEA82IBACll AQAqZQEA2WYBANpmAQBDaAEARGgBAFxoAQCraAEArGgBANBoAQCXbAEAmGwBANdtAQDYbQEA N3ABADhwAQBNcAEAiXEBAIpxAQBKcwEAS3MBAHNzAQCFcwEAxXQBAMZ0AQDxdgEA8nYBAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEPAAAd8nYBAGN4AQBkeAEAmXkBAJp5AQDeewEA33sBAEF+AQBCfgEAkn4BAJN+ AQCGgAEAh4ABAIeBAQCIgQEARIIBAEWCAQBVggEAVoIBAFeCAQByggEAoYIBAKKCAQC0ggEA foMBAH+DAQBvhAEAcIQBACGGAQAihgEA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB0ihgEALIcBAC2HAQDjhwEA 5IcBABuJAQAciQEA9IkBAPWJAQDMigEAzYoBAI6LAQCPiwEALYwBAC6MAQBtjQEAbo0BAFaO AQBXjgEAx48BAMiPAQAHkgEACJIBAK2SAQCukgEA7pQBAO+UAQD/lAEAAJUBABaVAQD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAABDwAAHS2HAQDjhwEA5IcBABuJAQAciQEA9IkBAPWJAQDMigEAzYoBAI6LAQCPiwEA LYwBAC6MAQBtjQEAbo0BAFaOAQBXjgEAx48BAMiPAQAHkgEACJIBAK2SAQCukgEA7pQBAO+U AQD/lAEAAJUBABaVAQBrlgEAbJYBAG6XAQBvlwEAHJkBAB2ZAQCYmQEAmZkBAJqZAQCbmQEA tpkBANaZAQAOmgEAPJoBAD6aAQB7mgEAm5oBAJyaAQC4mgEAx5oBAOmaAQAvmwEAbpsBAG+b AQCMmwEAm5sBAMubAQAYnAEAO5wBAIucAQCZnAEAmpwBALacAQDqnAEAFZ0BAGSdAQBsnQEA tZ0BALadAQDOnQEA5J0BADGeAQA5ngEATZ4BAE6eAQBmngEAgJ4BAL6eAQDSngEA054BAOye AQAFnwEAOp8BAE6fAQBPnwEAaJ8BAIGfAQDHnwEA258BANyfAQD1nwEADqABAFigAQBsoAEA baABAI6gAQCaoAEA2aABAA2hAQAOoQEAJqEBAEKhAQCOoQEA/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/QAAAwIPAABkFpUBAGuWAQBslgEAbpcBAG+X AQAcmQEAHZkBAJiZAQCZmQEAmpkBAJuZAQC2mQEA1pkBAA6aAQA8mgEAPpoBAHuaAQCbmgEA nJoBALiaAQDHmgEA6ZoBAC+bAQBumwEAb5sBAIybAQCbmwEAy5sBABicAQA7nAEA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQ8AAB07nAEAi5wBAJmcAQCanAEAtpwBAOqcAQAVnQEAZJ0BAGydAQC1nQEAtp0BAM6d AQDknQEAMZ4BADmeAQBNngEATp4BAGaeAQCAngEAvp4BANKeAQDTngEA7J4BAAWfAQA6nwEA Tp8BAE+fAQBonwEAgZ8BAMefAQD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHcefAQDbnwEA3J8BAPWfAQAOoAEA WKABAGygAQBtoAEAjqABAJqgAQDZoAEADaEBAA6hAQAmoQEAQqEBAI6hAQCWoQEAqqEBAKuh AQDEoQEA3KEBACWiAQA5ogEAOqIBAFOiAQBrogEAtqIBAMqiAQDLogEA5aIBAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEPAAAdjqEBAJahAQCqoQEAq6EBAMShAQDcoQEAJaIBADmiAQA6ogEAU6IBAGuiAQC2ogEA yqIBAMuiAQDlogEAHKMBAGyjAQB9owEAkaMBAJKjAQCrowEAtaMBAPejAQALpAEADKQBACSk AQA9pAEAfqQBAJKkAQCTpAEArKQBALakAQAEpQEAFaUBACmlAQAqpQEAQ6UBAGqlAQCjpQEA t6UBALilAQDRpQEA8qUBACCmAQBmpgEAmKYBAOWmAQDmpgEA/KYBAP6mAQD/pgEAAKcBAAqn AQALpwEAO6cBAJWnAQCWpwEAqKcBALioAQC5qAEA8akBAPKpAQBtqgEAbqoBAPeqAQD4qgEA HKsBAB2rAQBgqwEAYasBAMWrAQDGqwEA1qsBANerAQDmqwEA56sBAOirAQDpqwEA6qsBAP39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAg8AAE7logEAHKMBAGyjAQB9owEAkaMBAJKj AQCrowEAtaMBAPejAQALpAEADKQBACSkAQA9pAEAfqQBAJKkAQCTpAEArKQBALakAQAEpQEA FaUBACmlAQAqpQEAQ6UBAGqlAQCjpQEAt6UBALilAQDRpQEA8qUBACCmAQD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB DwAAHSCmAQBmpgEAmKYBAOWmAQDmpgEA/KYBAP6mAQD/pgEAAKcBAAqnAQALpwEAO6cBAJWn AQCWpwEAqKcBALioAQC5qAEA8akBAPKpAQBtqgEAbqoBAPeqAQD4qgEAHKsBAB2rAQBgqwEA YasBAMWrAQDGqwEA1qsBAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdAAD7MQIAAAQAAIIlAAD7MQIAAAEAAIIl AAD7MQIAAAcAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIA AAEAAIIlAAD7MQIAAAgAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAMAAIIlAAD7MQIAAAEAAIIl AAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAAAAFwDAAD1BgAAVjMAAMU1AAAFOAAA lzoAAJg6AABaPwAA9UAAADRCAAC7TgAAnlQAAKZZAAAoWwAAKVsAABliAAArYgAAyWIAAOti AAALZQAAHmUAAGlpAABqaQAAS2wAAHVuAAAPcQAAK3EAAIh2AACJdgAAa3sAAF18AABngAAA aIAAADCFAACghQAAmo0AAFOUAAA6mAAAgJwAAHinAAB5pwAAt6gAALioAAAkrgAAqK4AAPew AAByugAASb0AAEq9AADbxAAASckAAM/MAABR0AAAdNIAAHXSAACj1QAApNUAANfYAABR2wAA 7d4AAOTkAABB6AAAQugAAHzrAAB96wAAv+0AAPL3AADz9wAAHvgAACH4AACcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAA AAAAgAAAAICaAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAIAABAAAbT4AABJQAABxVgAAF2YAAHR0AADpgwAAmJEAAE6mAACtsAAAL8QAAM/Z AAAA7gAAoooCAMyaAgASAQAAGAEAABoBAAAbAQAAHQEAAB4BAAAhAQAAIgEAACUBAAAnAQAA KQEAACsBAAAsAQAARgEAAAAEAABNDwAA3CQAAAU8AACmXQAAhH8AADucAAClxgAAhO4AAFAB AQD9DQEAbiMBADo2AQBLQgEAIE8BANNiAQDydgEAIoYBABaVAQA7nAEAx58BAOWiAQAgpgEA 1qsBAHCLAgATAQAAFQEAABYBAAAZAQAAHAEAACABAAAkAQAAKgEAAC0BAAAuAQAALwEAADEB AAAyAQAAMwEAADUBAAA2AQAANwEAADgBAAA6AQAAOwEAADwBAAA+AQAAPwEAAEABAAAABAAA BTwAAIl6AABDmQAArqkAAJ26AAAhDwEARUsBAC2HAQCOoQEA6qsBABQBAAAXAQAAHwEAACMB AAAmAQAAKAEAADABAAA0AQAAOQEAAD0BAAD//1cAAAAHAFUAbgBrAG4AbwB3AG4ACgBTAHQA ZQB2AGUAIABLAGUAbgB0AAkASwBhAHIAZQBuACAAUwBlAG8AAwBCAEIATgAEAEIAQgBOAC4A BgBmAG8AbwBiAGEAcgALAEsAaQBtACAATABlAGcAZQBsAGkAcwAQAFIAaQBjAGgAYQByAGQA IABBAC4AIABCAGEAcgBvAG4ADwBSAGEAYwBoAGUAbAAgAEYALgAgAEMAbwBoAGUAbgAMAEsA YQByAGUAbgAgAFMAaQByAG8AaQBzAAkAcwBzAGEAeQBkAGoAYQByAGkAEABSAG8AYgBlAHIA dAAgAFcALgAgAFMAaABpAHIAZQB5AA0ASwBlAG4AIABUAGgAZQByAGkAYQB1AGwAdAAMAEwA aQBzAGEAIABSAGEAcABoAGEAZQBsABIAQgByAGkAYQBuACAAQQAuACAATABhAE0AYQBjAGMA aABpAGEADABTAHQAZQB2AGUAIABMAGkAcABuAGUAcgAMAEMAaABhAHIAbABlAHMAIABMAHkA bgBuAAwATABhAHIAcgB5ACAATABhAHkAdABlAG4ADQBDAG8AcgBpACAARAAuACAAUABlAGUA bABlAA4AUgBvAGIAZQByAHQAIABNAGUAdQBzAGgAYQB3AA0AVABpAG0AIABNAGMAQwBoAGUA cwBuAGUAeQAQAFMAdABlAHYAZQBuACAAQgAuACAATABpAHAAbgBlAHIAAwBzAG0AdwALAEIA bwBiACAAQgBsAGEAawBsAGUAeQAQAEoAbwBlACAAVwBhAGwAdABlAHIAcwAsACAASgByAC4A DgBEAGUAYgBvAHIAYQBoACAATQBlAGwAbwBuAGUAEwBEAGUAcAB0AC4AIAA3AEIAIABQAHUA YgBsAGkAYwAgAE0AYQBjABMARwBUAEUAIABJAG4AdABlAHIAbgBlAHQAdwBvAHIAawBpAG4A ZwASAFAAcgBlAGYAZQByAHIAZQBkACAAQwB1AHMAdABvAG0AZQByAAwASABvAHcAYQByAGQA IABHAHIAbwBzAHMABABHAFQARQBJABwAVgBhAGwAdQBlAGQAIABHAGEAdABlAHcAYQB5ACAA MgAwADAAMAAgAEMAdQBzAHQAbwBtAGUAcgALAEcAYQByAHkAIABEAGUAZQB0AGUAcgAOAEsA YQByAGUAbgAgAFMAYQB1AG4AZABlAHIAcwANAFQAaQBtAG8AdABoAHkAIABCAG8AdwBlAG4A DgBMAGkAcwBhACAARABpACAAUABpAGUAdAByAG8ADABKAGEAcwBvAG4AIABSAC4AIABPAGMA aAAJAEQAaQBjAGsAIABMAGkAbwB1ABIASQB2AGEAbgBhACAAUgAuACAAQQBiAHIAdQB6AHoA ZQBzAGUAEQBTAGgAbwBwAEwAaQBuAGsAIABFAG0AcABsAG8AeQBlAGUAEgBLAGUAbgBuAGUA dABoACAAUwAuACAARwBvAGwAZABtAGEAbgAOAEIAcgBhAGQAIABEAC4AIABNAGUAZQBoAGEA bgAMAE0AaQBrAGUAIABTAGgAdQBtAHcAYQB5AAoASgBpAG0AIABTAGMAaABhAGEAZAAUAEgA ZQBtAG0AYQAgAFAAcgBhAGYAdQBsAGwAYwBoAGEAbgBkAHIAYQATAE0AZQBsAGkAcwBzAGEA IABBAC4AIABNAGkAbABsAGkAZwBhAG4ACwBKAGkAbQAgAEQAZQBsAGEAbgBkAGUAGQBEAHIA LgAgAFIAbwBiAGUAcgB0ACAAVwBpAGwAbABpAGEAbQAgAFMAaABpAHIAZQB5AAsASgBlAGYA ZgAgAEEAbABpAGIAZQByAAwAUABlAHQAZQByACAASAB1AHMAcwBlAHkADQBIAHUAcwBzAGUA eQAsACAAUABlAHQAZQByABoARwBFAE0AUABMAFUAUwAgAEMAQQBSAEQAIABJAE4AVABFAFIA TgBBAFQASQBPAE4AQQBMAAoAQwBvAHIAaQAgAFAAZQBlAGwAZQALAEsAYQB5ACAAUABhAHUA bQBpAGUAcgAOAE0AZQByAHkAbAAgAEYAcgBhAG4AegBtAGEAbgADAFMAQwBDAAUAYwBjAGEA aQBuABIATABhAHUAcgBpAGEAdQBsAHQALAAgAFMAaQBtAG8AbgBuAGUADABTAGMAbwB0AHQA IABBAHQAdwBlAGwAbAAFAHAAYwBhAGkAbgAPAEQAYQB2AGkAZAAgAEUAcwBjAGEAbABhAG4A dABlAAkARQBzAGMAYQBsAGEAbgB0AGUAEwBCAGUAbgBqAGEAbQBpAG4AIABKAC4AIABXAG8A egBuAGkAYwBrABcAQgBCAE4AIABDAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBuAHMAIABJAG4A YwAuABQARwBUAEUAIABJAG4AdABlAHIAbgBlAHQAdwBvAHIAawBpAG4AZwAuAAsAQgBpAGwA bAAgAE4AZQBsAHMAbwBuAAkATQBpAGsAZQAgAEsAbwBuAGcADQBBAG4AZAByAGUAdwAgAFMA aABvAHIAZQBzAAoAQQBzAGMAZQBuAGQAIABlAG0AbQAaAEEAcwBjAGUAbgBkACAAQwBvAG0A bQB1AG4AaQBjAGEAdABpAG8AbgBzACAAVQBzAGUAcgAOAEoAbwBlACAAVwBoAGkAdABlAGgA bwB1AHMAZQAHAEMAYQBzAGMAYQBkAGUADABBAGEAcgBvAG4AIABCAGEAdwBjAG8AbQAIAGEA bQBhAGcAdQBpAHIAZQAQAEYAcgBhAG4AawAgAE0AYQBuAGkAcwBjAGEAbABjAG8AAgAuAC4A EABDAGEAdABoAGUAcgBpAG4AZQAgAEsAbgBpAGsAZQByAA8AQwBoAHIAaQBzAHQAaQBuAGUA IABTAGkAbAB2AGEADQBCAHIAYQBkACAARAAgAE0AZQBlAGgAYQBuAAwASgBpAG0AIABPACcA QwBvAG4AbgBvAHIAFABUAGUAYwBoAG4AaQBjAGEAbAAgAEMAbwByAHIAaQBnAGUAbgBkAGEA FABIAG8AeQB0ACAATAAuACAASwBlAHMAdABlAHIAcwBvAG4AIABJAEkABwBTAEIAbwBlAHkA ZQBuAAwAUgBvAGQAIABMAGUAbgBuAGkAZwBlAHIADQBKAEEATgBFAFQAIABMAEUAQgBMAE8A TgBEAAMAYgBiAG4AAwBEADQATQAf+AAAAAAAAAEAAAAOAAAALwAAADkAAAA+AAAARQAAAEgA AABSAAAAUwAAAFkAAABcAAAAZgAAAGcAAABtAAAAcgAAAH4AAACvAAAAtAAAAMgAAADQAAAA 0wAAAN8AAADiAAAA8QAAACYBAAAyAQAArgEAALcBAAA9CwAATAsAAHwMAACCDAAAFg0AABgN AAAZDQAALg0AADINAAA9DQAAPg0AAEENAAD7EQAABxIAAAgSAAAUEgAAMxIAAD8SAABAEgAA SRIAAIASAACMEgAAjRIAAJgSAADEEgAA0BIAANESAADeEgAAdRMAAIETAACCEwAAihMAAAcU AAATFAAAGRgAACUYAAC8GAAAyxgAAB4dAAAqHQAAQyEAAFQhAAAjLAAAMiwAAD4sAABHLAAA 6jUAAPM1AABVOgAAWToAAOVAAADzQAAAe1YAAItWAACwaAAAs2gAAGZuAABzbgAAl24AAKRu AAAhdAAAJnQAAJZ1AACbdQAAHnsAACF7AAASfQAAGH0AAM9+AADSfgAA+oUAAP6FAADrhgAA 74YAAIOIAACHiAAAEIkAABSJAACPjAAAkowAAPeSAAAEkwAAGJMAABuTAACpkwAArJMAAEyW AABPlgAAaJYAAHWWAACzlgAAtpYAAJuXAACelwAAdpgAAIOYAADImAAAy5gAAD+ZAABLmQAA TJkAAFOZAADTmQAA1pkAAEOaAABFmgAAmZoAAKCaAAD6mwAA/ZsAABqcAAAdnAAAXpwAAGGc AADTngAA1p4AACSjAAAnowAAm6YAAJ6mAAAUqAAAIKgAACGoAAAvqAAAMasAADqrAAC+uAAA ybgAAEq7AABNuwAAfMkAAIXJAAAIygAAEcoAAGfKAABwygAA6MoAAPHKAABlywAAbssAAL3L AADGywAAvswAAMfMAADY0QAA3NEAAMzTAADe0wAAddUAAH3VAABE2QAAT9kAAKbZAAC52QAA L9oAADraAACd3AAAqNwAAF/fAABi3wAAZd8AAGjfAABq3wAAb98AAHXfAAB23wAAw98AANPf AABD4QAATuEAANLhAADf4QAA5OMAAOjjAADy4wAA+OMAADvoAABA6AAAIfgAAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAEBAAACAQAA AwEAAAQBAAAFAQAABgEAAAcBAAAIAQAACQEAAAoBAAALAQAADAEAAA0BAAAOAQAADwEAABAB AAARAQAAEgEAABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAaAQAAGwEAABwBAAAdAQAA HgEAAB8BAAAgAQAAIQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAAKIBAAApAQAAKgEAACsB AAAsAQAALQEAAC4BAAAvAQAAQAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAA OQEAADoBAAA7AQAAPAEAAD0BAAA+AQAAPwEAALABAABBAQAAQgEAAEMBAABEAQAARQEAAEYB AABHAQAASAEAAEkBAABKAQAAVAEAAP3////9//////////////9bAQAA//////////////// /////1UBAABWAQAAVwEAAFgBAAB3AQAA//////////9cAQAAXQEAAF4BAABfAQAAYAEAAGIB AAD9////YwEAAGQBAABlAQAAZgEAAGcBAABoAQAAaQEAAGsBAAD+////bAEAAG0BAABuAQAA bwEAAO8BAAD+/////f///3MBAAB0AQAAdQEAAHYBAADSAQAAeAEAAAUAAAD/////fwEAAP// //////////////////+AAQAAhAEAAP/////dAQAA/////4UBAACGAQAAhwEAAIgBAACUAQAA //////////////////////////////////////////////////////////+WAQAA/////5cB AACYAQAAmgEAAP////+bAQAAnQEAAP////+eAQAArwEAAP///////////////6MBAACkAQAA pQEAAKYBAACnAQAAqAEAAKkBAAAwAQAA///////////////////////////iAQAAsQEAALIB AACzAQAAxQEAAP////////////////////////////////////////////////////////// ////////////////////////////////xgEAAMcBAADIAQAAyQEAAMoBAADLAQAAzAEAAM0B AADOAQAAzwEAAIIBAAD//////////9MBAADUAQAA1QEAANYBAADXAQAA2AEAANkBAADaAQAA 2wEAANwBAAAAAgAA3gEAAN8BAADgAQAA4QEAAP7////jAQAA5AEAAOUBAADmAQAA5wEAAOgB AADpAQAA6gEAAOsBAADsAQAA7QEAAP7/////////8AEAAPEBAADyAQAA8wEAAPQBAAAGAAAA //////////////////////////////////////////////////////////8SABUACgABAFsA DwACAAMAAAADACgAAEDx/wIAKAAAAAYATgBvAHIAbQBhAGwAAAACAAAACABDShgAbUgJBAAA AAAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEA ZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAA0AFpAAQDyADQAAAAKAFAAbABhAGkA bgAgAFQAZQB4AHQAAAACAA8ADABDShQAT0oEAFFKBAAkAC8AAQACASQAAAAEAEwAaQBzAHQA AAAKABAAD4RoARGEmP4AACoAQgABABIBKgAAAAkAQgBvAGQAeQAgAFQAZQB4AHQAAAAGABEA FKR4AAAAPABDAAEAIgE8AAAAEABCAG8AZAB5ACAAVABlAHgAdAAgAEkAbgBkAGUAbgB0AAAA CgASAA+EaAEUpHgAAAAyABwAAQAyATIAAAANAE4AbwByAG0AYQBsACAASQBuAGQAZQBuAHQA AAAGABMAD4TQAgAAKABVQKIAQQEoAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAYAPioBQioC AAAAACH4AAADAACCAgADAP////8SAAAABCH//wEAAAAAAAAh//8CAAAAAAAEIf//AwAAAAAA ACH//wQAAAAAAAQh//8FAAAAAAAAIP//BgAAAAAABCH//wcAAAAAAAAg//8IAAAAAAAEIP// CQAAAAAAACD//woAAAAAAAQg//8LAAAAAAAAIP//DAAAAAAABCD//w0AAAAAAAAg//8OAAAA AAAEIP//DwAAAAAAACD//xAAAAAAAAQg//8RAAAAAAAAIP//EgAAAAAAAAAAAE4LAAA+GAAA vCYAAEE0AACVQQAAu04AAINeAABMbAAAa3sAAJSJAACxlwAADKcAADG1AADbxAAAEdMAAEDi AABr8QAAIfgAAAAAFwAAAAEAAQAAAAIAiAIAAAMAhAEAAAQAnwAAAAUA4wUAAAYAlgMAAAcA /AEAAAgAAQAAAAkABgQAAAoAiQAAAAsAbAAAAAwAbAEAAA0AAQAAAA4AkgIAAA8AmQAAABAA dwAAABEAAAAAAAAAAAAuAAAARwAAAFsAAABvAAAAcAAAAH8AAACAAAAApwAAANIAAAAEAQAA JQEAAGQBAACbAQAAnAEAAK0BAAC4AQAAuQEAANYBAABbAwAAXAMAAPUGAAD2BgAAxwgAAMgI AADqCQAA6wkAADsLAAA8CwAATQsAAE4LAABEKQAARSkAACAqAAAhKgAAkSwAAJIsAACyLQAA sy0AALQtAADXLQAAwi8AAMMvAAC/MAAAwDAAAFUzAABWMwAAxTUAAMY1WgAAWFoAACZbAAAn WwAAqVwAAKpcAACaYwAAm2MAAKtjAACsYwAASmQAAEtkAABsZAAAjGYAAI1mAACfZgAA6moA AOtqAADMbQAAzW0AAMlvAADKbwAA2m8AANtvAAD2bwAAkHIAAJFyAACscgAACXgAAAp4AADs fAAA7XwAAAV9AACjfQAApH0AAKV9AADDfQAAxH0AAN59AADogQAA6YEAALGGAACyhgAAAIcA AAGHAAAhhwAAG48AAByPAAA+jwAAapIAAGuSAACDkgAAM5MAADSTAAA1kwAAVZMAADyVAAA9 lQAA05UAANSVAAC7mQAAvJkAAPebAAD4mwAAI5wAAACeAAABngAA+agAAPqoAAA4qgAAOaoA AKWvAACmrwAAwa8AABawAAAXsAAAKbAAAHiyAAB5sgAAIbUAACK1AAAeuAAAH7gAAPK7AADz uwAAyr4AAMu+AABcxgAAXcYAAPLGAADzxgAAycoAAMrKAABQzgAAUc4AAPHPAADyzwAA0dEA ANLRAAD10wAA9tMAACTXAAAl1wAAWNoAAFnaAADR3AAA0twAAG7gAABv4AAAWuQAAFvkAABk 5gAAZeYAAMLpAADD6QAA/ewAAP7sAABA7wAAQe8AAGPzAABk8wAAbfQAAG70AABS9gAAU/YA AGP2AABk9gAAevYAAMYAAMc1AAD1NQAA9jUAAOs3AADsNwAA7TcAAAU4AACXOgAAmDoAAFo/ AABbPwAAyEAAAMlAAADKQAAA9UAAADRCAAA1QgAASkIAAEtCAACNQwAAjkMAAOdDAADoQwAA +kMAAKBGAAChRgAAZkoAAGdKAAC6TgAAu04AAJ5UAACfVAAA1lgAANdYAAClWQAAplkAAChb AAApWwAAGWIAABpiAAAqYgAAK2IAAMliAADKYgAA62IAAAtlAAAMZQAAHmUAAGlpAABqaQAA S2wAAExsAABIbgAASW4AAFluAABabgAAdW4AAA9xAAAQcQAAK3EAAIh2AACJdgAAa3sAAGx7 AACEewAAInwAACN8AAAkfAAAQnwAAEN8AABdfAAAZ4AAAGiAAAAwhQAAMYUAAH+FAACAhQAA oIUAAJqNAACbjQAAvY0AAOmQAADqkAAAApEAALKRAACzkQAAtJEAANSRAAC7kwAAvJMAAFKU AABTlAAAOpgAADuYAAB2mgAAd5oAAKKaAAB/nAAAgJwAAHinAAB5pwAAt6gAALioAAAkrgAA Ja4AAECuAACVrgAAlq4AAKiuAAD3sAAA+LAAAKCzAAChswAAnbYAAJ62AABxugAAcroAAEm9 AABKvQAA28QAANzEAABxxQAAcsUAAEjJAABJyQAAz8wAANDMAABwzgAAcc4AAFDQAABR0AAA dNIAAHXSAACj1QAApNUAANfYAADY2AAAUNsAAFHbAADt3gAA7t4AANniAADa4gAA4+QAAOTk AABB6AAAQugAAHzrAAB96wAAv+0AAMDtAADi8QAA4/EAAOzyAADt8gAA0fQAANL0AADi9AAA 4/QAAPn0AABF9wAARvcAAPL3AADz9wAAIPgAACP4AAAAAQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAADAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABAAA giUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAA giUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABAAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABAAA giUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAFAAA giUAAPsxAgAAAQAAgiUAAPsxAgAADgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsx AgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAFwAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADwAA giUAAPsxAgAAAQAAgiUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEgAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAA giUAAPsxAgAAARwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABAAHAP//FAAAAAoA UwB0AGUAdgBlACAASwBlAG4AdAA4AEgAYQByAGQAIABEAGkAcwBrADoAVABlAG0AcABvAHIA YQByAHkAIABJAHQAZQBtAHMAOgBBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUA IABvAGYAIABJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAEwBIAGEA cgBkACAARABpAHMAawA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAASwBlAG4A dAATAEgAYQByAGQAIABEAGkAcwBrADoASQBQAFMAZQBjAC4AdABlAHgACgBTAHQAZQB2AGUA IABLAGUAbgB0ABMASABhAHIAZAAgAEQAaQBzAGsAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMA dABlAHYAZQAgAEsAZQBuAHQAEwBIAGEAcgBkACAARABpAHMAawA6AEkAUABTAGUAYwAuAHQA ZQB4AAoAUwB0AGUAdgBlACAASwBlAG4AdAATAEgAYQByAGQAIABEAGkAcwBrADoASQBQAFMA ZQBjAC4AdABlAHgACgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgA IABIAEQAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAFgBNAGEA YwBpAG4AdABvAHMAaAAgAEgARAA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAA SwBlAG4AdAAWAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4AdABlAHgA CgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBJAFAA UwBlAGMALgB0AGUAeAD/QAOAAQBA6AAAQOgAAFCTvwwBAAEAQOgAAAAAAADa5wAAAAAAAAEA AQDFAqQCAhwGAAAAAAAA360AAOCtAADbsAAA3bAAAMu7AADTuwAA1LsAAPG7AABMvAAAULwA AGy8AABtvAAAb7wAAHa8AAB3vAAAE70AAC+9AABAvQAARr0AACHBAAAlwQAAe8EAAITBAACS wwAAk8MAAJTDAACWwwAAssMAAMzDAAAPxAAAEMQAABPEAAAnxAAASsQAAFXEAABaxAAAW8QA AI/EAACQxAAAk8QAALzEAADZxAAATMoAAFDKAABRygAAW8oAAFzKAABjygAAZsoAAKbKAACs ygAArcoAALrKAAC7ygAAvMoAAL3KAADaygAAPssAAIXLAACOywAAl8sAAJnLAACaywAAnMsA AN3LAAAUzAAAFcwAABzMAABKzAAAS8wAAM7MAADU0QAA1dEAANjRAADd0QAA8tEAAEzSAABb 1QAAXtUAAH3VAAB31wAAetcAAMHXAADe1wAA4tcAAOfXAADw1wAAgdgAAILYAACD2AAAhNgA AIfYAACL2AAA1dgAACTeAAAs3gAA1+IAAMzmAADN5gAAzuYAAPfmAAAm5wAAQucAAHLnAACe 5wAAn+cAAMnnAADa5wAAA+gAAAToAAAG6AAAQOgAAEfqAABM6gAAX+oAAHPqAAAx6wAAVusA AHnrAACg7QAAoe0AAKLtAACq7QAAvO0AAL3tAADy9wAA8/cAAB34AAAe+AAAH/gAADAAAAgA QAAAMQAeggIAAAAwAL5jAUAAADEAIIICAAAAMAC4aQFAAAAxAACOAgAAADEAEI4CAAAAMQAS jgIAAAAxAEyOAgAAADEAAo8CAAAAMQAKjwIAAAAxAEKPAgAAADEARI8CAAAAMQBIjwIAAAAx AFaPAgAAADEAWI8CAAAAMQCQkAIAAAAxAMiQAgAAADEA6pACAAAAMACafwFAAAAxACSCAgAA ADEAUIcBQAAAMQAAhAIAAAAxAPyHAUAAADEAEoQCAAAAMQAUhAIAAAAxABaEAgAAADEAGoQC AAAAMQBShAIAAAAxAIaEAgAAADEADIUCAAAAMQAOhQIAAAAxABSFAgAAADEAPIUCAAAAMQCC hQIAAAAxAJiFAgAAADEAooUCAAAAMQCkhQIAAAAxAAyGAgAAADEADoYCAAAAMQAUhgIAAAAx AGaGAgAAADAAGIwBQAAAMQD2kAIAAAAxAP6QAgAAADEAAJECAAAAMQAUkQIAAAAxABaRAgAA ADEAJJECAAAAMQAqkQIAAAAxAKqRAgAAADEAtpECAAAAMQC4kQIAAAAxANKRAgAAADEA1JEC AAAAMQDWkQIAAAAxANiRAgAAADEA/pYBQAAAMQASkgIAAAAxAKCSAgAAADEAspICAAAAMQDE kgIAAAAxAMiSAgAAADEAypICAAAAMQDOkgIAAAAxAFCTAgAAADEAvpMCAAAAMQDAkwIAAAAx AM6TAgAAADEAKpQCAAAAMQDGlwFAAAAwANiYAUAAADEAoIYCAAAAMQCihgIAAAAxAKiGAgAA ADEAAIoCAAAAMQCyhgIAAAAwAOSiAUAAADEAZocCAAAAMQBshwIAAAAwAAKpAUAAADEAqocC AAAAMQD8rAFAAAAxACqKAgAAADEAZIoCAAAAMQBsigIAAAAxAHaKAgAAADEAiq0BQAAAMQCw hwIAAAAxALKHAgAAADEAtIcCAAAAMQC2hwIAAAAxALyHAgAAADEAxIcCAAAAMACsrgFAAAAx AIiKAgAAADAASrkBQAAAMACgwgFAAAAxAACWAgAAADEAApYCAAAAMQAElgIAAAAxAFaWAgAA ADEAtJYCAAAAMQDslgIAAAAxAEyXAgAAADEApJcCAAAAMQCmlwIAAAAxAPqXAgAAADEAAJoC AAAAMQBSmgIAAAAxAFSaAgAAADEAWJoCAAAAMACSygFAAAAxAJiKAgAAADEAoM4BQAAAMQCi igIAAAAxAMbOAUAAADEAyooCAAAAMQAUiwIAAAAwAELQAUAAADEAWosCAAAAMQCS1AFAAAAx AFyLAgAAADEAmtQBQAAAMQBsiwIAAAAwAL7UAUAAADAAbosCAAAAMQBwiwIAAAAwANBXA0AA ADAA0lcDQAAABQAAAEcGkAEAAAICBgMFBAUCAwQAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABU AGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADWKAABPmAAA/acAADS2AAAhxgAAFtQA AE3jAABu8gAAf/oAAAAAFwAAAAEAAQAAAAIAiAIAAAMAhAEAAAQAnwAAAAUA0AAAAAYA1wQA AAcAaAAAAAgA6QAAAAkA8QQAAAoAdAEAAAsABAEAAAwACgIAAA0AWwAAAA4ALgMAAA8ALQEA ABAAFQEAABEAAAAAAAAAAAAuAAAARwAAAFsAAABvAAAAcAAAAH8AAACAAAAApwAAANIAAAAE AQAAJQEAAGQBAACbAQAAnAEAAK0BAAC4AQAAuQEAANYBAABbAwAAXAMAAPUGAAD2BgAAxwgA AMgIAADqCQAA6wkAADsLAAA8CwAATQsAAE4LAABEKQAARSkAACAqAAAhKgAAkSwAAJIsAACy LQAAsy0AALQtAADXLQAAwi8AAMMvAAC/MAAAwDAAAFUzAABWMwAAxTUAAMY1AADHNQAA9TUA APY1AADrNwAA7DcAAO03AAAFOAAAlzoAAJg6AABaPwAAWz8AAMhAAADJQAAAykAAAPVAAAA0 QgAANUIAAEpCAABLQgAAjUMAAI5DAADnQwAA6EMAAPpDAACgRgAAoUYAANVKAADWSgAAO1AA ADxQAAAfVgAAIFYAAFdaAABYWgAAJlsAACdbAACpXAAAqlwAAJpjAACbYwAAq2MAAKxjAABK ZAAAS2QAAGxkAACMZgAAjWYAAJ9mAADyagAA82oAANRtAADVbQAA0W8AANJvAADibwAA428A AP5vAACYcgAAmXIAALRyAAAReAAAEngAAPR8AAD1fAAADX0AAKt9AACsfQAArX0AAMt9AADM fQAA5n0AAPCBAADxgQAAuYYAALqGAAAIhwAACYcAACmHAAAjjwAAJI8AAEaPAABykgAAc5IA AIuSAAA7kwAAPJMAAD2TAABdkwAARJUAAEWVAADblQAA3JUAAMOZAADEmQAA/5sAAACcAAAr nAAACJ4AAAmeAAABqQAAAqkAAECqAABBqgAAra8AAK6vAADJrwAAHrAAAB+wAAAxsAAAgLIA AIGyAABBtQAAQrUAAD64AAA/uAAAErwAABO8AADqvgAA674AAHzGAAB9xgAAEscAABPHAADp ygAA6soAAHDOAABxzgAAEdAAABLQAADx0QAA8tEAABXUAAAW1AAARNcAAEXXAAB42gAAedoA APHcAADy3AAAjuAAAI/gAAB65AAAe+QAAITmAACF5gAA4ukAAOPpAAAd7QAAHu0AAGDvAABh 7wAAg/MAAITzAACN9AAAjvQAAHL2AABz9gAAg/YAAIT2AACa9gAA5vgAAOf4AACT+QAAlPkA AH76AACB+gAAAAEAAIIlAAD7MQIAAAEAAIIlAAD7+AAAx/gAAHP5AAB0+QAASvoAAE36AAAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA BQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABgAAgiUA APsxAgAAAQAAgiUAAPsxAgAABAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA BAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUA APsxAgAAAQAAgiUAAPsxAgAABAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEAAAgiUAAPsxAgAAAQAAgiUA APsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA BQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA CQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEgAAgiUA APsxAgAAAQAAgiUAAPsxAgAAFAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADgAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAFwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAADwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACgAAgiUAAPsxAgAA AQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA EgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEAAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA GwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACwAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUA APsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAJQAAgiUAAPsxAgAAAQAAgiUA APsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUA APsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACgAAgiUAAPsxAgAA AQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUA APsxAgAAGgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA DQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABgAAgiUA APsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAA AQAAgiUAAPsxAgAACwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACwAAgiUAAPsxAgAAAQAAgiUA APsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA DQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADAAAgiUA APsxAgAAAQAAgiUAAPsxAgAACwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAA AQAAgiUAAPsxAgAADgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABAAAgiUAAPsxAgAAAQAAgiUA APsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAAAAXAMAAPUGAABWMwAAxTUAAAU4AACX OgAAmDoAAFo/AAD1QAAANEIAAKFGAADVSgAA1koAADtQAAA8UAAAH1YAACdbAACpXAAAqlwA AJpjAACsYwAASmQAAGxkAACMZgAAn2YAAOpqAADragAAzG0AAPZvAACQcgAArHIAAAl4AAAK eAAA7HwAAN59AADogQAA6YEAALGGAAAhhwAAG48AANSVAAC7mQAAAZ4AAPmoAAD6qAAAOKoA ADmqAAClrwAAKbAAAHiyAADzuwAAyr4AAMu+AABcxgAAysoAAFDOAADS0QAA9dMAAPbTAAAk 1wAAJdcAAFjaAADS3AAAbuAAAGXmAADC6QAAw+kAAP3sAAD+7AAAQO8AAHP5AAB0+QAASvoA AE36AACcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAA gAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAA gAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAA gAAAAICYAAAADwAAAAAAAAAAgAAAAICegQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgA AACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAA lgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMA AACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAA sQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4A AAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAA zAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkA AADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA 5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQA AAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAAAAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAA AAAAAAAAAACAAAAAgAAEAABtPgAAElAAAHFWAAAXZgAAdHQAAOmDAACYkQAATqYAAK2wAAAv xAAAz9kAAADuAACiigIAop8CAJqkAgASAQAAGAEAABoBAAAbAQAAHQEAAB4BAAAhAQAAIgEA ACUBAAAnAQAAKQEAACsBAAAsAQAARgEAAFMBAAAABAAATQ8AANwkAAAFPAAApl0AAIR/AAA7 nAAApcYAAITuAABQAQEA/Q0BAG4jAQA6NgEAS0IBACBPAQDTYgEA8nYBACKGAQAWlQEAO5wB AMefAQDlogEAIKYBANarAQBwiwIAEwEAABUBAAAWAQAAGQEAABwBAAAgAQAAJAEAACoBAAAt AQAALgEAAC8BAAAxAQAAMgEAADMBAAA1AQAANgEAADcBAAA4AQAAOgEAADsBAAA8AQAAPgEA AD8BAABAAQAAAAQAAAU8AACJegAAQ5kAAK6pAACdugAAIQ8BAEVLAQAthwEAjqEBAOqrAQAU AQAAFwEAAB8BAAAjAQAAJgEAACgBAAAwAQAANAEAADkBAAA9AQAA//9XAAAABwBVAG4AawBu AG8AdwBuAAoAUwB0AGUAdgBlACAASwBlAG4AdAAJAEsAYQByAGUAbgAgAFMAZQBvAAMAQgBC AE4ABABCAEIATgAuAAYAZgBvAG8AYgBhAHIACwBLAGkAbQAgAEwAZQBnAGUAbABpAHMAEABS AGkAYwBoAGEAcgBkACAAQQAuACAAQgBhAHIAbwBuAA8AUgBhAGMAaABlAGwAIABGAC4AIABD AG8AaABlAG4ADABLAGEAcgBlAG4AIABTAGkAcgBvAGkAcwAJAHMAcwBhAHkAZABqAGEAcgBp ABAAUgBvAGIAZQByAHQAIABXAC4AIABTAGgAaQByAGUAeQANAEsAZQBuACAAVABoAGUAcgBp AGEAdQBsAHQADABMAGkAcwBhACAAUgBhAHAAaABhAGUAbAASAEIAcgBpAGEAbgAgAEEALgAg AEwAYQBNAGEAYwBjAGgAaQBhAAwAUwB0AGUAdgBlACAATABpAHAAbgBlAHIADABDAGgAYQBy AGwAZQBzACAATAB5AG4AbgAMAEwAYQByAHIAeQAgAEwAYQB5AHQAZQBuAA0AQwBvAHIAaQAg AEQALgAgAFAAZQBlAGwAZQAOAFIAbwBiAGUAcgB0ACAATQBlAHUAcwBoAGEAdwANAFQAaQBt ACAATQBjAEMAaABlAHMAbgBlAHkAEABTAHQAZQB2AGUAbgAgAEIALgAgAEwAaQBwAG4AZQBy AAMAcwBtAHcACwBCAG8AYgAgAEIAbABhAGsAbABlAHkAEABKAG8AZQAgAFcAYQBsAHQAZQBy AHMALAAgAEoAcgAuAA4ARABlAGIAbwByAGEAaAAgAE0AZQBsAG8AbgBlABMARABlAHAAdAAu ACAANwBCACAAUAB1AGIAbABpAGMAIABNAGEAYwATAEcAVABFACAASQBuAHQAZQByAG4AZQB0 AHcAbwByAGsAaQBuAGcAEgBQAHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUAcgAM AEgAbwB3AGEAcgBkACAARwByAG8AcwBzAAQARwBUAEUASQAcAFYAYQBsAHUAZQBkACAARwBh AHQAZQB3AGEAeQAgADIAMAAwADAAIABDAHUAcwB0AG8AbQBlAHIACwBHAGEAcgB5ACAARABl AGUAdABlAHIADgBLAGEAcgBlAG4AIABTAGEAdQBuAGQAZQByAHMADQBUAGkAbQBvAHQAaAB5 ACAAQgBvAHcAZQBuAA4ATABpAHMAYQAgAEQAaQAgAFAAaQBlAHQAcgBvAAwASgBhAHMAbwBu ACAAUgAuACAATwBjAGgACQBEAGkAYwBrACAATABpAG8AdQASAEkAdgBhAG4AYQAgAFIALgAg AEEAYgByAHUAegB6AGUAcwBlABEAUwBoAG8AcABMAGkAbgBrACAARQBtAHAAbABvAHkAZQBl ABIASwBlAG4AbgBlAHQAaAAgAFMALgAgAEcAbwBsAGQAbQBhAG4ADgBCAHIAYQBkACAARAAu ACAATQBlAGUAaABhAG4ADABNAGkAawBlACAAUwBoAHUAbQB3AGEAeQAKAEoAaQBtACAAUwBj AGgAYQBhAGQAFABIAGUAbQBtAGEAIABQAHIAYQBmAHUAbABsAGMAaABhAG4AZAByAGEAEwBN AGUAbABpAHMAcwBhACAAQQAuACAATQBpAGwAbABpAGcAYQBuAAsASgBpAG0AIABEAGUAbABh AG4AZABlABkARAByAC4AIABSAG8AYgBlAHIAdAAgAFcAaQBsAGwAaQBhAG0AIABTAGgAaQBy AGUAeQALAEoAZQBmAGYAIABBAGwAaQBiAGUAcgAMAFAAZQB0AGUAcgAgAEgAdQBzAHMAZQB5 AA0ASAB1AHMAcwBlAHkALAAgAFAAZQB0AGUAcgAaAEcARQBNAFAATABVAFMAIABDAEEAUgBE ACAASQBOAFQARQBSAE4AQQBUAEkATwBOAEEATAAKAEMAbwByAGkAIABQAGUAZQBsAGUACwBL AGEAeQAgAFAAYQB1AG0AaQBlAHIADgBNAGUAcgB5AGwAIABGAHIAYQBuAHoAbQBhAG4AAwBT AEMAQwAFAGMAYwBhAGkAbgASAEwAYQB1AHIAaQBhAHUAbAB0ACwAIABTAGkAbQBvAG4AbgBl AAwAUwBjAG8AdAB0ACAAQQB0AHcAZQBsAGwABQBwAGMAYQBpAG4ADwBEAGEAdgBpAGQAIABF AHMAYwBhAGwAYQBuAHQAZQAJAEUAcwBjAGEAbABhAG4AdABlABMAQgBlAG4AagBhAG0AaQBu ACAASgAuACAAVwBvAHoAbgBpAGMAawAXAEIAQgBOACAAQwBvAG0AbQB1AG4AaQBjAGEAdABp AG8AbgBzACAASQBuAGMALgAUAEcAVABFACAASQBuAHQAZQByAG4AZQB0AHcAbwByAGsAaQBu AGcALgALAEIAaQBsAGwAIABOAGUAbABzAG8AbgAJAE0AaQBrAGUAIABLAG8AbgBnAA0AQQBu AGQAcgBlAHcAIABTAGgAbwByAGUAcwAKAEEAcwBjAGUAbgBkACAAZQBtAG0AGgBBAHMAYwBl AG4AZAAgAEMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AcwAgAFUAcwBlAHIADgBKAG8AZQAg AFcAaABpAHQAZQBoAG8AdQBzAGUABwBDAGEAcwBjAGEAZABlAAwAQQBhAHIAbwBuACAAQgBh AHcAYwBvAG0ACABhAG0AYQBnAHUAaQByAGUAEABGAHIAYQBuAGsAIABNAGEAbgBpAHMAYwBh AGwAYwBvAAIALgAuABAAQwBhAHQAaABlAHIAaQBuAGUAIABLAG4AaQBrAGUAcgAPAEMAaABy AGkAcwB0AGkAbgBlACAAUwBpAGwAdgBhAA0AQgByAGEAZAAgAEQAIABNAGUAZQBoAGEAbgAM AEoAaQBtACAATwAnAEMAbwBuAG4AbwByABQAVABlAGMAaABuAGkAYwBhAGwAIABDAG8AcgBy AGkAZwBlAG4AZABhABQASABvAHkAdAAgAEwALgAgAEsAZQBzAHQAZQByAHMAbwBuACAASQBJ AAcAUwBCAG8AZQB5AGUAbgAMAFIAbwBkACAATABlAG4AbgBpAGcAZQByAA0ASgBBAE4ARQBU ACAATABFAEIATABPAE4ARAADAGIAYgBuAAMARAA0AE0AS/oAAAAAAAABAAAADgAAAC8AAAA5 AAAAPgAAAEUAAABIAAAAUgAAAFMAAABZAAAAXAAAAGYAAABnAAAAbQAAAHIAAAB+AAAArwAA ALQAAADIAAAA0AAAANMAAADfAAAA4gAAAPEAAAAmAQAAMgEAAK4BAAC3AQAAAP7///8DAAAA BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAA/v///wsAAAAMAAAADQAAAA4AAAAPAAAAEAAAAP7/ //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////8BAAA9CwAATAsAAHwMAACCDAAAFg0AABgNAAAZDQAALg0AADINAAA9 DQAAPg0AAEENAAD7EQAABxIAAAgSAAAUEgAAMxIAAD8SAABAEgAASRIAAIASAACMEgAAjRIA AJgSAADEEgAA0BIAANESAADeEgAAdRMAAIETAACCEwAAihMAAAcUAAATFAAAGRgAACUYAAC8 GAAAyxgAAB4dAAAqHQAAQyEAAFQhAAAjLAAAMiwAAD4sAABHLAAA6jUAAPM1AABVOgAAWToA AOVAAADzQAAApU4AAK9OAAD8VwAADFgAADFqAAA0agAA528AAPRvAAAYcAAAJXAAAKJ1AACn dQAAF3cAABx3AACffAAAonwAAJN+AACZfgAAUIAAAFOAAAB7hwAAf4cAAGyIAABwiAAABIoA AAiKAACRigAAlYoAABCOAAATjgAAeJQAAIWUAACZlAAAnJQAACqVAAAtlQAAzZcAANCXAADp lwAA9pcAADSYAAA3mAAAHJkAAB+ZAAD3mQAABJoAAEmaAABMmgAAwJoAAMyaAADNmgAA1JoA AFSbAABXmwAAxJsAAMabAAAanAAAIZwAAHudAAB+nQAAm50AAJ6dAADfnQAA4p0AAFSgAABX oAAApaQAAKikAAAcqAAAH6gAAJWpAAChqQAAoqkAALCpAACyrAAAu6wAAD+6AABKugAAy7wA AM68AAD9ygAABssAAInLAACSywAA6MsAAPHLAABpzAAAcswAAObMAADvzAAAPs0AAEfNAAA/ zgAASM4AAFnTAABd0wAATdUAAF/VAAD21gAA/tYAAMXaAADQ2gAAJ9sAADrbAACw2wAAu9sA AB7eAAAp3gAA4OAAAOPgAADm4AAA6eAAAOvgAADw4AAA9uAAAPfgAABE4QAAVOEAAMTiAADP 4gAAU+MAAGDjAABl5QAAaeUAAHPlAAB55QAATfoAAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHAP//FAAAAAoAUwB0AGUAdgBlACAASwBlAG4AdAATAEgAYQByAGQAIABE AGkAcwBrADoASQBQAFMAZQBjAC4AdABlAHgACgBTAHQAZQB2AGUAIABLAGUAbgB0ABMASABh AHIAZAAgAEQAaQBzAGsAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBu AHQAEwBIAGEAcgBkACAARABpAHMAawA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBl ACAASwBlAG4AdAAWAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4AdABl AHgACgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBJ AFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAFgBNAGEAYwBpAG4AdABv AHMAaAAgAEgARAA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAASwBlAG4AdAAW AE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4AdABlAHgACgBTAHQAZQB2 AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBJAFAAUwBlAGMALgB0 AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAOQBIAGEAcgBkACAARABpAHMAawA6AFQAZQBt AHAAbwByAGEAcgB5ACAASQB0AGUAbQBzADoAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABz AGEAdgBlACAAbwBmACAASQBQAHMAZQBjACAAcgBlAHYAaQAKAFMAdABlAHYAZQAgAEsAZQBu AHQAJQBIAGEAcgBkACAARABpAHMAawA6AEkAUABTAEUAQwA6AEkAUABzAGUAYwAgAHIAZQB2 AGkAZQB3ACAAYwBvAG0AbQBlAG4AdABzAP9AAYABAKVOAAClTgAA2O0KBgEAAQClTgAAAAAA AIxOAAAAAAAAAQABAMUCpAIBgwBFxoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGGAEMkAUXGgAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAnQIAAAAAAAAZEoAAGVKAABmSgAAa0oAAI1KAACWSgAAokoA ANNKAADWSgAAd0wAAH1MAAB/TAAAgEwAAIFMAADOTAAA00wAANRMAADbTAAA8UwAAP9MAAAf TQAAIE0AACNNAAAsTQAAZE0AAIZNAAC7TQAA1U0AAN9NAADmTQAA6E0AAAlOAAATTgAAHE4A AFZOAABXTgAAW04AAGVOAABqTgAAjE4AAKVOAACtTgAArk4AADtQAABgrwAAYa8AAFyyAABe sgAATL0AAFS9AABVvQAAcr0AAM29AADRvQAA7b0AAO69AADwvQAA970AAPi9AACUvgAAsL4A AMG+AADHvgAAosIAAKbCAAD8wgAABcMAABPFAAAUxQAAFcUAABfFAAAzxQAATcUAAJDFAACR xQAAlMUAAKjFAADLxQAA1sUAANvFAADcxQAAEMYAABHGAAAUBQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAIAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABYAAAAAAAAADAAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAEAADemAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAgAAAgIAAAMCAAAEAgAABQIAAAYCAAAHAgAACAIAAAkCAAAKAgAACwIAAAwC AAD+////DgIAAA8CAAD+////EQIAABICAAATAgAAFAIAABUCAAAWAgAAFwIAAAgAAAD///// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////xIAFQAKAAEAWwAPAAIAAwAAAAMA KAAAQPH/AgAoAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAIAENKGABtSAkEAAAAAAAAAAAAAAAA AAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgA IABGAG8AbgB0AAAAAAAAAAAAAAAAADQAWkABAPIANAAAAAoAUABsAGEAaQBuACAAVABlAHgA dAAAAAIADwAMAENKFABPSgQAUUoEACQALwABAAIBJAAAAAQATABpAHMAdAAAAAoAEAAPhGgB EYSY/gAAKgBCAAEAEgEqAAAACQBCAG8AZAB5ACAAVABlAHgAdAAAAAYAEQAUpHgAAAA8AEMA AQAiATwAAAAQAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAAAAKABIAD4RoARSk eAAAADIAHAABADIBMgAAAA0ATgBvAHIAbQBhAGwAIABJAG4AZABlAG4AdAAAAAYAEwAPhNAC AAAoAFVAogBBASgAAAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAABgA+KgFCKgIAAAAAx/gAAAMA AKgCAAMA/////xIAAAAEIf//AQAAAAAAACD//wIAAAAAAAQg//8DAAAAAAAAIP//BAAAAAAA BCD//wUAAAAAAAAg//8GAAAAAAAEIP//BwAAAAAAACD//wgAAAAAAAQg//8JAAAAAAAAIP// CgAAAAAABCD//wsAAAAAAAAg//8MAAAAAAAEIP//DQAAAAAAACD//w4AAAAAAAQg//8PAAAA AAAAIP//EAAAAAAABCD//xEAAAAAAAAg//8SAAAAAAAAAAAA0gwAAIMaAABpKAAAVTUAAC9C AACNUQAASWEAAEZuAADHfAAAwowAAEeaAAB1qQAAWrgAALrHAAAq1gAAzeQAAMjzAADH+AAA AADyAQAAAQB5AAAAAgBwAgAAAwDeAAAABAABAAAABQDaAgAABgCZAAAABwCaAgAACABxAwAA CQCpAAAACgABAAAACwCABAAADAAAAgAADQB3AQAADgCWAgAADwBdAwAAEADyAAAAEQAAAAAA AAAAAAEAAAAeAAAAowEAAKQBAAA9BQAAPgUAAA8HAAAQBwAAMggAADMIAACDCQAAhAkAAJUJ AACWCQAArQkAAK4JAAAdCgAAHgoAAJQLAACVCwAAxA4AAMUOAAAQEAAAERAAAC0SAAAuEgAA XRIAAF4SAABzEgAAdBIAAEoUAABLFAAAhhYAAIcWAABYGAAAWRgAAPwaAAD9GgAA2x0AANwd AAAjHwAAJB8AAP0hAAD+IQAAyCMAAMkjAACMJwAAjScAAGgoAABpKAAA2SoAANoqAAD6KwAA +ysAAPwrAAAfLAAACi4AAAsuAAAHLwAACC8AAJ0xAACeMQAADTQAAA40AAAPNAAAPTQAAD40 AAAzNgAANDYAADU2AABNNgAA3zgAAOA4AACiPQAAoz0AABA/AAARPwAAEj8AAD0/AAB8QAAA fUAAAJJAAACTQAAA1UEAANZBAAAvQgAAMEIAAEJCAADoRAAA6UQAAB1JAAAeSQAAg04AAIRO AABnVAAAaFQAAJ9YAACgWAAAblkAAG9ZAADxWgAA8loAAOJhAADjYQAA82EAAPRhAACSYgAA k2IAALRiAADUZAAA1WQAAOdkAAA6aQAAO2kAABxsAAAdbAAAGW4AABpuAAAqbgAAK24AAEZu AADgcAAA4XAAAPxwAABZdgAAWnYAADx7AAA9ewAAVXsAAPN7AAD0ewAA9XsAABN8AAAUfAAA LnwAADiAAAA5gAAAAYUAAAKFAABQhQAAUYUAAHGFAABrjQAAbI0AAI6NAAC6kAAAu5AAANOQ AACDkQAAhJEAAIWRAAClkQAAjJMAAI2TAAAjlAAAJJQAAAuYAAAMmAAAR5oAAEiaAABzmgAA UJwAAFGcAABJpwAASqcAAIioAACJqAAA9a0AAPatAAARrgAAZq4AAGeuAAB5rgAAyLAAAMmw AACJswAAirMAAIa2AACHtgAAWroAAFu6AAAyvQAAM70AAMTEAADFxAAAWsUAAFvFAAAxyQAA MskAALjMAAC5zAAAWc4AAFrOAAA50AAAOtAAAF3SAABe0gAAjNUAAI3VAADA2AAAwdgAADnb AAA62wAA1t4AANfeAADC4gAAw+IAAMzkAADN5AAAKugAACvoAABl6wAAZusAAKjtAACp7QAA y/EAAMzxAADV8gAA1vIAALr0AAC79AAAy/QAAMz0AADi9AAALvcAAC/3AADb9wAA3PcAAMb4 AADJ+AAAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAUAAIIlAAD7MQIAAAEAAIIlAAD7MQIA AAwAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAYAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAQAAIIl AAD7MQIAAAEAAIIlAAD7MQIAAAUAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIA AAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAIAAIIlAAD7MQIAAAEAAIIl AAD7MQIAAAYAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAsAAIIlAAD7MQIAAAEAAIIlAAD7MQIA AAUAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAcAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIl AAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAYAAIIlAAD7MQIA AAEAAIIlAAD7MQIAAAgAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAYAAIIlAAD7MQIAAAEAAIIl AAD7MQIAAAkAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAoAAIIlAAD7MQIAAAEAAIIlAAD7MQIA AAUAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAoAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAYAAIIl AAD7MQIAAAEAAIIlAAD7MQIAAA0AAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAMAAIIlAAD7MQIA AAEAAIIlAAD7MQIAAAkAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAQAAIIlAAD7MQIAAAEAAIIl AAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAcAAIIlAAD7MQIAAAEAAIIlAAD7MQIA AAQAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAkAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAkAAIIl AAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIA AAcGkAECAAIABQAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAA ADMGkAEAAAILBgQCAgICAgQAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAAz BpABAAACAAUAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzAAAAPwaQ AQAAAgcDCQICBQIEBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEMAbwB1AHIAaQBlAHIAIABO AGUAdwAAACIABAAxiIgYAADQAgAAaAEAAAAAq4o8pmNkQWYAAAAALgAzAQAAryMAAGvLAAAS AGgAAAAEAIMQsQEAAAAAAAAAAAAAEgABAAAAAQAAAAAAAADsAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAHjAAABEAGQBkAAAAGQAA AM/5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADLuwAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAF0C//8SAAAAAAAAAC0AXABkAG8AYwB1AG0AZQBuAHQAYwBs AGEAcwBzAFsAYwBoAGEAcAB0AGUAcgBwAGEAZwBlACwAMQAyAHAAdABdAHsAYwBvAHUAbgB0 AGUAcgBwAGEAbgBlAH0AAAAAAAAACgBTAHQAZQB2AGUAIABLAGUAbgB0AAoAUwB0AGUAdgBl ACAASwBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAFQAKAAEAWwAPAAIAAwAAAAMAKAAA QPH/AgAoAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAIAENKGABtSAkEAAAAAAAAAAAAAAAAAAAA AAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABG AQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEAAA4B AAAPAQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAAbAQAA HAEAAB0BAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAogEAACkB AAAqAQAAKwEAACwBAAAtAQAALgEAAC8BAABAAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAA NwEAADgBAAA5AQAAOgEAADsBAAA8AQAAPQEAAD4BAAA/AQAAsAEAAEEBAABCAQAAQwEAAEQB AABFAQAARgEAAEcBAABIAQAASQEAAEoBAABUAQAA//////////9OAQAAUAEAAFsBAABRAQAA UgEAAFMBAAB7AQAAVQEAAFYBAABXAQAAWAEAAHcBAABaAQAAnAEAAFwBAABdAQAAXgEAAF8B AABgAQAAYgEAAP3///9jAQAAZAEAAGUBAABmAQAAZwEAAGgBAABpAQAAawEAAP7///9sAQAA bQEAAG4BAABvAQAA7wEAAP////////////////////////////////////94AQAABQAAAP3/ //9/AQAAfAEAAH0BAAB+AQAAgQEAAIABAAAACwAEAQAADAAKAgAADQBbAAAADgAuAwAADwAt AQAAEAAVAQAAEQAAAAAAAAAAAC4AAABHAAAAWwAAAG8AAABwAAAAfwAAAIAAAACnAAAA0gAA AAQBAAAlAQAAZAEAAJsBAACcAQAArQEAALgBAAC5AQAA1gEAAFsDAABcAwAA9QYAAPYGAADH CAAAyAgAAOoJAADrCQAAOwsAADwLAABNCwAATgsAAEQpAABFKQAAICoAACEqAACRLAAAkiwA ALItAACzLQAAtC0AANctAADCLwAAwy8AAL8wAADAMAAAVTMAAFYzAADFNQAAxjUAAMc1AAD1 NQAA9jUAAOs3AADsNwAA7TcAAAU4AACXOgAAmDoAAFo/AABbPwAAyEAAAMlAAADKQAAA9UAA ADRCAAA1QgAASkIAAEtCAACNQwAAjkMAAOdDAADoQwAA+kMAAKBGAAChRgAA1UoAANZKAAA7 UAAAPFAAAB9WAAAgVgAAV1oAAFhaAAAmWwAAJ1sAAKlcAACqXAAAmmMAAJtjAACrYwAArGMA AEpkAABLZAAAbGQAAIxmAACNZgAAn2YAAPJqAADzagAA1G0AANVtAADRbwAA0m8AAOJvAADj bwAA/m8AAJhyAACZcgAAtHIAABF4AAASeAAA9HwAAPV8AAANfQAAq30AAKx9AACtfQAAywAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADgAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAGwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAACwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAJQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEgAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAA giUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAGgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAA giUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADAAAgiUAAPsx AgAAAQAAgiUAAPsxAgAABgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAA giUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACwAAgiUAAPsxAgAAAQAAgiUAAPsx AgAACwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAA giUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsx AgAAAQAAgiUAAPsxAgAADAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACwAAgiUAAPsxAgAAAQAA giUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADgAAgiUAAPsxAgAAAQAAgiUAAPsx AgAABAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAAAA XAMAAPUGAABWMwAAxTUAAAU4AACXOgAAmDoAAFo/AAD1QAAANEIAALtOAACeVAAAplkAAChb AAApWwAAGWIAACtiAADJYgAA62IAAAtlAAAeZQAAaWkAAGppAABLbAAAdW4AAA9xAAArcQAA iHYAAIl2AABrewAAXXwAAGeAAABogAAAMIUAAKCFAACajQAAU5QAADqYAACAnAAAeKcAAHmn AAC3qAAAuKgAACSuAACorgAA97AAAHK6AABJvQAASr0AANvEAABJyQAAz8wAAFHQAAB00gAA ddIAAKPVAACk1QAA19gAAFHbAADt3gAA5OQAAEHoAABC6AAAfOsAAH3rAAC/7QAA8vcAAPP3 AAAg+AAAI/gAAJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAA AAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAA AAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAA AAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAA AAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAA AAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAA AAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAA AAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAA AAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAA AAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAA AAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAfQAAzH0A AOZ9AADwgQAA8YEAALmGAAC6hgAACIcAAAmHAAAphwAAI48AACSPAABGjwAAcpIAAHOSAACL kgAAO5MAADyTAAA9kwAAXZMAAESVAABFlQAA25UAANyVAADDmQAAxJkAAP+bAAAAnAAAK5wA AAieAAAJngAAAakAAAKpAABAqgAAQaoAAK2vAACurwAAya8AAB6wAAAfsAAAMbAAAICyAACB sgAAQbUAAEK1AAA+uAAAP7gAABK8AAATvAAA6r4AAOu+AAB8xgAAfcYAABLHAAATxwAA6coA AOrKAABwzgAAcc4AABHQAAAS0AAA8dEAAPLRAAAV1AAAFtQAAETXAABF1wAAeNoAAHnaAADx 3AAA8twAAI7gAACP4AAAeuQAAHvkAACE5gAAheYAAOLpAADj6QAAHe0AAB7tAABg7wAAYe8A AIPzAACE8wAAjfQAAI70AABy9gAAc/YAAIP2AACE9gAAmvYAAOb4AADn+AAAk/kAAJT5AAB+ +gAAgfoAAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACC JQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAAMAACCJQAA+zECAAABAACCJQAA+zEC AAAGAACCJQAA+zECAAABAACCJQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA+zECAAAFAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAADAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACC JQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAAHAACCJQAA+zECAAABAACCJQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA+zECAAAJAACC JQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA+wAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAA AAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAA AAAAgAAAAICeAAAAAAAAAAAAIABUAG8AZABhAHkALAAgAHQAcgBhAG4AcwBwAG8AcgB0ACAA bQBvAGQAZQAgAGkAcwAgAHUAcwBlAGQAIABwAHIAaQBtAGEAcgBpAGwAeQAgAHQAbwAgAGMA YQByAHIAeQAgAEwAMgBUAFAAIAB0AHIAYQBmAGYAaQBjACwAIABhAGwAdABoAG8AdQBnAGgA IAB0AGgAaQBzACAAaQBzACAAcAByAGkAbQBhAHIAaQBsAHkAIABhAG4AIABlAGYAZgBpAGMA aQBlAG4AYwB5ACAAaQBzAHMAdQBlAC4AIAB0AG8AZABhAHkAQQAgAHAAbABhAHUAcwBpAGIA bABlACwAIABuAGUAYQByAC0AdABlAHIAbQAgAHUAcwBlACAAZgBvAHIAIABBAEgAIABpAHMA IAB0AG8AIABwAHIAbwB2AGkAZABlACAAaQBuAHQAZQBnAHIAaQB0AHkAIABhAG4AZAAgAGEA dQB0AGgAZQBuAHQAaQBjAGkAdAB5ACAAZgBvAHIAIABJAFAAcwBlAGMAIAB0AHIAYQBmAGYA aQBjACAAYgBlAHQAdwBlAGUAbgAgAGEAbgAgAGUAbgBkACAAcwB5AHMAdABlAG0AIABhAG4A ZAAgAGEAIABmAGkAcgBzAHQALQBoAG8AcAAgAGkAbgB0AGUAcgBtAGUAZACEAQAAiQEAAN0B AAD9////hQEAAIYBAACHAQAAiAEAAJQBAACKAQAAiwEAAIwBAACNAQAAjgEAAI8BAACQAQAA kQEAAJIBAACTAQAAlQEAAJYBAACZAQAAlwEAAJgBAACaAQAA0AEAAJsBAACdAQAAnwEAAJ4B AACvAQAAoAEAAKEBAACqAQAAowEAAKQBAAClAQAApgEAAKcBAACoAQAAqQEAADABAACrAQAA rAEAAK0BAACuAQAAtAEAAOIBAACxAQAAsgEAALMBAADFAQAAtQEAALYBAAC3AQAAuAEAALkB AAC6AQAAuwEAALwBAAC9AQAAvgEAAL8BAADAAQAAwQEAAMIBAADDAQAAxAEAAP7////GAQAA xwEAAMgBAADJAQAAygEAAMsBAADMAQAAzQEAAM4BAADPAQAAggEAANEBAAACAAAA//////// ///////////////////////////////////////////////////eAQAA3wEAAOABAADhAQAA /v///+MBAADkAQAA5QEAAOYBAADnAQAA6AEAAOkBAADqAQAA6wEAAOwBAADtAQAA/v////7/ ///wAQAA8QEAAPIBAADzAQAA9AEAAAYAAAD2AQAA9wEAAP7////5AQAA+gEAAPsBAAD8AQAA /QEAAP4BAAD/AQAACAAAADECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zEC AAABAACCJQAA+zECAAAQAACCJQAA+zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAACAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACCJQAA+zEC AAAPAACCJQAA+zECAAABAACCJQAA+zECAAASAACCJQAA+zECAAABAACCJQAA+zECAAAUAACC JQAA+zECAAABAACCJQAA+zECAAAOAACCJQAA+zECAAABAACCJQAA+zECAAADAACCJQAA+zEC AAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAAXAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAACAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAPAACC JQAA+zECAAABAACCJQAA+zECAAAKAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAJAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAASAACCJQAA+zECAAABAACCJQAA+zEC AAAQAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAACAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAAOAACCJQAA+zECAAABAACCJQAA+zECAAAQAACCJQAA+zECAAABAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAbAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAALAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAADAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zEC AAABAACCJQAA+zECAAACAACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAABAACC JQAA+zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zEC AAABAACCJQAA+zECAAAlAACCJQAA+zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACC JQAA+zECAAASAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAACAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAAJAACC JQAA+zECAAABAACCJQAA+zECAAAKAACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA+zEC AAABAACCJQAA+zECAAAKAACCJQAA+zECAAABAACCJQAA+zECAAAaAACCJQAA+zECAAABAACC JQAA+zECAAACAACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAABAACCJQAA+zEC AAAMAACCJQAA+zECAAABAACCJQAA+zECAAAGAACCJQAA+zECAAABAACCJQAA+zECAAAHAACC JQAA+zECAAABAACCJQAA+zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAALAACCJQAA+zEC AAABAACCJQAA+zECAAALAACCJQAA+zECAAABAACCJQAA+zECAAAJAACCJQAA+zECAAABAACC JQAA+zECAAANAACCJQAA+zECAAABAACCJQAA+zECAAANAACCJQAA+zECAAABAACCJQAA+zEC AAAHAACCJQAA+zECAAABAACCJQAA+zECAAAMAACCJQAA+zECAAABAACCJQAA+zECAAALAACC JQAA+zECAAABAACCJQAA+zECAAAIAACCJQAA+zECAAABAACCJQAA+zECAAAOAACCJQAA+zEC AAABAACCJQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAAIAACCJQAA+zEC AAABAACCJQAA+zECAAADAACCJQAA+zECAAABAACCJQAA+zECAAADAACCJQAA+zECAAABAACC JQAA+zECAAAAAAAuAAAARwAAAFsAAABvAAAAcAAAAH8AAACAAAAApwAAANIAAAAEAQAAJQEA AGQBAACbAQAAnAEAAK0BAAC4AQAAuQEAAFwDAAD1BgAAVjMAAMU1AAAFOAAAlzoAAJg6AABa PwAA9UAAADRCAAChRgAA1UoAANZKAAA7UAAAPFAAAB9WAAAnWwAAqVwAAKpcAACaYwAArGMA AEpkAABsZAAAjGYAAJ9mAADyagAA82oAANRtAAD+bwAAmHIAALRyAAAReAAAEngAAPR8AADm fQAA8IEAAPGBAAC5hgAAKYcAACOPAADclQAAw5kAAAmeAAABqQAAAqkAAECqAABBqgAAra8A ADGwAACAsgAAgbIAAEG1AAATvAAA6r4AAOu+AAB8xgAA6soAAHDOAADy0QAAFdQAABbUAABE 1wAARdcAAHjaAADy3AAAjuAAAI/gAAB65AAAheYAAOLpAADj6QAAHe0AAB7tAABg7wAAk/kA AJT5AAB++gAAgfoAAJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAP AAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAACAAAAAgJgAAAAPAAAA AAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAA AAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAA AAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgAAEAABtPgAA ElAAAHFWAAAXZgAAdHQAAOmDAACYkQAATqYAAK2wAAAvxAAAz9kAAADuAACiigIABJwCABIB AAAYAQAAGgEAABsBAAAdAQAAHgEAACEBAAAiAQAAJQEAACcBAAApAQAAKwEAACwBAABGAQAA AAQAAE0PAADcJAAABTwAAKZdAACEfwAAO5wAAKXGAACE7gAAUAEBAP0NAQBuIwEAOjYBAEtC AQAgTwEA02IBAPJ2AQAihgEAFpUBADucAQDHnwEA5aIBACCmAQDWqwEAcIsCABMBAAAVAQAA FgEAABkBAAAcAQAAIAEAACQBAAAqAQAALQEAAC4BAAAvAQAAMQEAADIBAAAzAQAANQEAADYB AAA3AQAAOAEAADoBAAA7AQAAPAEAAD4BAAA/AQAAQAEAAAAEAAAFPAAAiXoAAEOZAACuqQAA nboAACEPAQBFSwEALYcBAI6hAQDqqwEAFAEAABcBAAAfAQAAIwEAACYBAAAoAQAAMAEAADQB AAA5AQAAPQEAAP//VwAAAAcAVQBuAGsAbgBvAHcAbgAKAFMAdABlAHYAZQAgAEsAZQBuAHQA CQBLAGEAcgBlAG4AIABTAGUAbwADAEIAQgBOAAQAQgBCAE4ALgAGAGYAbwBvAGIAYQByAAsA SwBpAG0AIABMAGUAZwBlAGwAaQBzABAAUgBpAGMAaABhAHIAZAAgAEEALgAgAEIAYQByAG8A bgAPAFIAYQBjAGgAZQBsACAARgAuACAAQwBvAGgAZQBuAAwASwBhAHIAZQBuACAAUwBpAHIA bwBpAHMACQBzAHMAYQB5AGQAagBhAHIAaQAQAFIAbwBiAGUAcgB0ACAAVwAuACAAUwBoAGkA cgBlAHkADQBLAGUAbgAgAFQAaABlAHIAaQBhAHUAbAB0AAwATABpAHMAYQAgAFIAYQBwAGgA YQBlAGwAEgBCAHIAaQBhAG4AIABBAC4AIABMAGEATQBhAGMAYwBoAGkAYQAMAFMAdABlAHYA ZQAgAEwAaQBwAG4AZQByAAwAQwBoAGEAcgBsAGUAcwAgAEwAeQBuAG4ADABMAGEAcgByAHkA IABMAGEAeQB0AGUAbgANAEMAbwByAGkAIABEAC4AIABQAGUAZQBsAGUADgBSAG8AYgBlAHIA dAAgAE0AZQB1AHMAaABhAHcADQBUAGkAbQAgAE0AYwBDAGgAZQBzAG4AZQB5ABAAUwB0AGUA dgBlAG4AIABCAC4AIABMAGkAcABuAGUAcgADAHMAbQB3AAsAQgBvAGIAIABCAGwAYQBrAGwA ZQB5ABAASgBvAGUAIABXAGEAbAB0AGUAcgBzACwAIABKAHIALgAOAEQAZQBiAG8AcgBhAGgA IABNAGUAbABvAG4AZQATAEQAZQBwAHQALgAgADcAQgAgAFAAdQBiAGwAaQBjACAATQBhAGMA EwBHAFQARQAgAEkAbgB0AGUAcgBuAGUAdAB3AG8AcgBrAGkAbgBnABIAUAByAGUAZgBlAHIA cgBlAGQAIABDAHUAcwB0AG8AbQBlAHIADABIAG8AdwBhAHIAZAAgAEcAcgBvAHMAcwAEAEcA VABFAEkAHABWAGEAbAB1AGUAZAAgAEcAYQB0AGUAdwBhAHkAIAAyADAAMAAwACAAQwB1AHMA dABvAG0AZQByAAsARwBhAHIAeQAgAEQAZQBlAHQAZQByAA4ASwBhAHIAZQBuACAAUwBhAHUA bgBkAGUAcgBzAA0AVABpAG0AbwB0AGgAeQAgAEIAbwB3AGUAbgAOAEwAaQBzAGEAIABEAGkA IABQAGkAZQB0AHIAbwAMAEoAYQBzAG8AbgAgAFIALgAgAE8AYwBoAAkARABpAGMAawAgAEwA aQBvAHUAEgBJAHYAYQBuAGEAIABSAC4AIABBAGIAcgB1AHoAegBlAHMAZQARAFMAaABvAHAA TABpAG4AawAgAEUAbQBwAGwAbwB5AGUAZQASAEsAZQBuAG4AZQB0AGgAIABTAC4AIABHAG8A bABkAG0AYQBuAA4AQgByAGEAZAAgAEQALgAgAE0AZQBlAGgAYQBuAAwATQBpAGsAZQAgAFMA aAB1AG0AdwBhAHkACgBKAGkAbQAgAFMAYwBoAGEAYQBkABQASABlAG0AbQBhACAAUAByAGEA ZgB1AGwAbABjAGgAYQBuAGQAcgBhABMATQBlAGwAaQBzAHMAYQAgAEEALgAgAE0AaQBsAGwA aQBnAGEAbgALAEoAaQBtACAARABlAGwAYQBuAGQAZQAZAEQAcgAuACAAUgBvAGIAZQByAHQA IABXAGkAbABsAGkAYQBtACAAUwBoAGkAcgBlAHkACwBKAGUAZgBmACAAQQBsAGkAYgBlAHIA DABQAGUAdABlAHIAIABIAHUAcwBzAGUAeQANAEgAdQBzAHMAZQB5ACwAIABQAGUAdABlAHIA GgBHAEUATQBQAEwAVQBTACAAQwBBAFIARAAgAEkATgBUAEUAUgBOAEEAVABJAE8ATgBBAEwA CgBDAG8AcgBpACAAUABlAGUAbABlAAsASwBhAHkAIABQAGEAdQBtAGkAZQByAA4ATQBlAHIA eQBsACAARgByAGEAbgB6AG0AYQBuAAMAUwBDAEMABQBjAGMAYQBpAG4AEgBMAGEAdQByAGkA YQB1AGwAdAAsACAAUwBpAG0AbwBuAG4AZQAMAFMAYwBvAHQAdAAgAEEAdAB3AGUAbABsAAUA cABjAGEAaQBuAA8ARABhAHYAaQBkACAARQBzAGMAYQBsAGEAbgB0AGUACQBFAHMAYwBhAGwA YQBuAHQAZQATAEIAZQBuAGoAYQBtAGkAbgAgAEoALgAgAFcAbwB6AG4AaQBjAGsAFwBCAEIA TgAgAEMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AcwAgAEkAbgBjAC4AFABHAFQARQAgAEkA bgB0AGUAcgBuAGUAdAB3AG8AcgBrAGkAbgBnAC4ACwBCAGkAbABsACAATgBlAGwAcwBvAG4A CQBNAGkAawBlACAASwBvAG4AZwANAEEAbgBkAHIAZQB3ACAAUwBoAG8AcgBlAHMACgBBAHMA YwBlAG4AZAAgAGUAbQBtABoAQQBzAGMAZQBuAGQAIABDAG8AbQBtAHUAbgBpAGMAYQB0AGkA bwBuAHMAIABVAHMAZQByAA4ASgBvAGUAIABXAGgAaQB0AGUAaABvAHUAcwBlAAcAQwBhAHMA YwBhAGQAZQAMAEEAYQByAG8AbgAgAEIAYQB3AGMAbwBtAAgAYQBtAGEAZwB1AGkAcgBlABAA RgByAGEAbgBrACAATQBhAG4AaQBzAGMAYQBsAGMAbwACAC4ALgAQAEMAYQB0AGgAZQByAGkA bgBlACAASwBuAGkAawBlAHIADwBDAGgAcgBpAHMAdABpAG4AZQAgAFMAaQBsAHYAYQANAEIA cgBhAGQAIABEACAATQBlAGUAaABhAG4ADABKAGkAbQAgAE8AJwBDAG8AbgBuAG8AcgAUAFQA ZQBjAGgAbgBpAGMAYQBsACAAQwBvAHIAcgBpAGcAZQBuAGQAYQAUAEgAbwB5AHQAIABMAC4A IABLAGUAcwB0AGUAcgBzAG8AbgAgAEkASQAHAFMAQgBvAGUAeQBlAG4ADABSAG8AZAAgAEwA ZQBuAG4AaQBnAGUAcgANAEoAQQBOAEUAVAAgAEwARQBCAEwATwBOAEQAAwBiAGIAbgADAEQA NABNACH4AAAAAAAAAQAAAA4AAAAvAAAAOQAAAD4AAABFAAAASAAAAFIAAABTAAAAWQAAAFwA AABmAAAAZwAAAG0AAAByAAAAfgAAAK8AAAC0AAAAyAAAANAAAADTAAAA3wAAAOIAAADxAAAA JgEAADIBAACuAQAAtwEAAD0LAABMCwAAfAwAAIIMAAAWDQAAGA0AABkNAAAuDQAAMg0AAD0N AAA+DQAAQQ0AAPsRAAAHEgAACBIAABQSAAAzEgAAPxIAAEASAABJEgAAgBIAAIwSAACNEgAA mBIAAMQSAADQEgAA0RIAAN4SAAB1EwAAgRMAAIITAACKEwAABxQAABMUAAAZGAAAJRgAALwY AADLGAAAHh0AACodAABDIQAAVCEAACMsAAAyLAAAPiwAAEcsAADqNQAA8zUAAFU6AABZOgAA 5UAAAPNAAAB7VgAAi1YAALBoAACzaAAAZm4AAHNuAACXbgAApG4AACF0AAAmdAAAlnUAAJt1 AAAeewAAIXsAABJ9AAAYfQAAz34AANJ+AAD6hQAA/oUAAOuGAADvhgAAg4gAAIeIAAAQiQAA FIkAAI+MAACSjAAA95IAAASTAAAYkwAAG5MAAKmTAACskwAATJYAAE+WAABolgAAdZYAALOW AAC2lgAAm5cAAJ6XAAB2mAAAg5gAAMiYAADLmAAAP5kAAEuZAABMmQAAU5kAANOZAADWmQAA Q5oAAEWaAACZmgAAoJoAAPqbAAD9mwAAGpwAAB2cAABenAAAYZwAANOeAADWngAAJKMAACej AACbpgAAnqYAABSoAAAgqAAAIagAAC+oAAAxqwAAOqsAAL64AADJuAAASrsAAE27AAB8yQAA hckAAAjKAAARygAAZ8oAAHDKAADoygAA8coAAGXLAABuywAAvcsAAMbLAAC+zAAAx8wAANjR AADc0QAAzNMAAN7TAAB11QAAfdUAAETZAABP2QAAptkAALnZAAAv2gAAOtoAAJ3cAACo3AAA X98AAGLfAABl3wAAaN8AAGrfAABv3wAAdd8AAHbfAADD3wAA098AAEPhAABO4QAA0uEAAN/h AADk4wAA6OMAAPLjAAD44wAA/vcAAAb4AAAj+AAABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAEAAcA//8UAAAACgBTAHQAZQB2AGUAIABLAGUAbgB0ABMASABhAHIAZAAgAEQA aQBzAGsAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAEwBIAGEA cgBkACAARABpAHMAawA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAASwBlAG4A dAATAEgAYQByAGQAIABEAGkAcwBrADoASQBQAFMAZQBjAC4AdABlAHgACgBTAHQAZQB2AGUA IABLAGUAbgB0ABMASABhAHIAZAAgAEQAaQBzAGsAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMA dABlAHYAZQAgAEsAZQBuAHQAEwBIAGEAcgBkACAARABpAHMAawA6AEkAUABTAGUAYwAuAHQA ZQB4AAoAUwB0AGUAdgBlACAASwBlAG4AdAAWAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoA SQBQAFMAZQBjAC4AdABlAHgACgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQA bwBzAGgAIABIAEQAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQA FgBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUA dgBlACAASwBlAG4AdAAWAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4A dABlAHgACgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQA OgBJAFAAUwBlAGMALgB0AGUAeAD/QAGAAQAG+AAABvgAAFCTvwwBAAEABvgAAAAAAAAE+AAA AAAAAAEAAQDFAqQCAjQGAAAAAAAA360AAOCtAADbsAAA3bAAAMu7AADTuwAA1LsAAPG7AABM vAAAULwAAGy8AABtvAAAb7wAAHa8AAB3vAAAE70AAC+9AABAvQAARr0AACHBAAAlwQAAe8EA AITBAACSwwAAk8MAAJTDAACWwwAAssMAAMzDAAAPxAAAEMQAABPEAAAnxAAASsQAAFXEAABa xAAAW8QAAI/EAACQxAAAk8QAALzEAADZxAAATMoAAFDKAABRygAAW8oAAFzKAABjygAAZsoA AKbKAACsygAArcoAALrKAAC7ygAAvMoAAL3KAADaygAAPssAAIXLAACOywAAl8sAAJnLAACa ywAAnMsAAN3LAAAUzAAAFcwAABzMAABKzAAAS8wAAM7MAADU0QAA1dEAANjRAADd0QAA8tEA AEzSAABb1QAAXtUAAH3VAAB31wAAetcAAMHXAADe1wAA4tcAAOfXAADw1wAAgdgAAILYAACD 2AAAhNgAAIfYAACL2AAA1dgAACTeAAAs3gAA1+IAAMzmAADN5gAAzuYAAPfmAAAm5wAAQucA AHLnAACe5wAAn+cAAMnnAADa5wAAA+gAAAToAAAG6AAAQOgAAEfqAABM6gAAX+oAAHPqAAAx 6wAAVusAAHnrAACg7QAAoe0AAKLtAACq7QAAvO0AAL3tAADy9wAA8/cAAAT4AAAG+AAAH/gA ACD4AAAh+AAAMAAACABAAAAxAB6CAgAAADAAvmMBQAAAMQAgggIAAAAwALhpAUAAADEAAI4C AAAAMQAQjgIAAAAxABKOAgAAADEATI4CAAAAMQACjwIAAAAxAAqPAgAAADEAQo8CAAAAMQBE jwIAAAAxAEiPAgAAADEAVo8CAAAAMQBYjwIAAAAxAJCQAgAAADEAyJACAAAAMQDqkAIAAAAw AAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICYAAAADwAA AAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAA AAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAA AAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAA AAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAA AAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICYAAAADwAA AAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAA AAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAA AAAAAAAAgAAAAICYAAAADwAAAAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAAICYAAAADwAA AAAAAAAAgAAAAICcAAAAAAAAAAAAAAAAgAAAmn8BQAAAMQAkggIAAAAxAFCHAUAAADEAAIQC AAAAMQD8hwFAAAAxABKEAgAAADEAFIQCAAAAMQAWhAIAAAAxABqEAgAAADEAUoQCAAAAMQCG hAIAAAAxAAyFAgAAADEADoUCAAAAMQAUhQIAAAAxADyFAgAAADEAgoUCAAAAMQCYhQIAAAAx AKKFAgAAADEApIUCAAAAMQAMhgIAAAAxAA6GAgAAADEAFIYCAAAAMQBmhgIAAAAwABiMAUAA ADEA9pACAAAAMQD+kAIAAAAxAACRAgAAADEAFJECAAAAMQAWkQIAAAAxACSRAgAAADEAKpEC AAAAMQCqkQIAAAAxALaRAgAAADEAuJECAAAAMQDSkQIAAAAxANSRAgAAADEA1pECAAAAMQDY kQIAAAAxAP6WAUAAADEAEpICAAAAMQCgkgIAAAAxALKSAgAAADEAxJICAAAAMQDIkgIAAAAx AMqSAgAAADEAzpICAAAAMQBQkwIAAAAxAL6TAgAAADEAwJMCAAAAMQDOkwIAAAAxACqUAgAA ADEAxpcBQAAAMADYmAFAAAAxAKCGAgAAADEAooYCAAAAMQCohgIAAAAxAACKAgAAADEAsoYC AAAAMADkogFAAAAxAGaHAgAAADEAbIcCAAAAMAACqQFAAAAxAKqHAgAAADEA/KwBQAAAMQAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAA gJoAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgAAEAABtPgAAElAAAHFWAAAX ZgAAdHQAAOmDAACYkQAATqYAAK2wAAAvxAAAz9kAAADuAACiigIAop8CADipAgASAQAAGAEA ABoBAAAbAQAAHQEAAB4BAAAhAQAAIgEAACUBAAAnAQAAKQEAACsBAAAsAQAARgEAAFMBAAAA BAAATQ8AANwkAAAFPAAApl0AAIR/AAA7nAAApcYAAITuAABQAQEA/Q0BAG4jAQA6NgEAS0IB ACBPAQDTYgEA8nYBACKGAQAWlQEAO5wBAMefAQDlogEAIKYBANarAQBwiwIAEwEAABUBAAAW AQAAGQEAABwBAAAgAQAAJAEAACoBAAAtAQAALgEAAC8BAAAxAQAAMgEAADMBAAA1AQAANgEA ADcBAAA4AQAAOgEAADsBAAA8AQAAPgEAAD8BAABAAQAAAAQAAAU8AACJegAAQ5kAAK6pAACd ugAAIQ8BAEVLAQAthwEAjqEBAOqrAQAUAQAAFwEAAB8BAAAjAQAAJgEAACgBAAAwAQAANAEA ADkBAAA9AQAA//9XAAAABwBVAG4AawBuAG8AdwBuAAoAUwB0AGUAdgBlACAASwBlAG4AdAAJ AEsAYQByAGUAbgAgAFMAZQBvAAMAQgBCAE4ABABCAEIATgAuAAYAZgBvAG8AYgBhAHIACwBL AGkAbQAgAEwAZQBnAGUAbABpAHMAEABSAGkAYwBoAGEAcgBkACAAQQAuACAAQgBhAHIAbwBu AA8AUgBhAGMAaABlAGwAIABGAC4AIAAqigIAAAAxAGSKAgAAADEAbIoCAAAAMQB2igIAAAAx AIqtAUAAADEAsIcCAAAAMQCyhwIAAAAxALSHAgAAADEAtocCAAAAMQC8hwIAAAAxAMSHAgAA ADAArK4BQAAAMQCIigIAAAAwAEq5AUAAADAAoMIBQAAAMQAAlgIAAAAxAAKWAgAAADEABJYC AAAAMQBWlgIAAAAxALSWAgAAADEA7JYCAAAAMQBMlwIAAAAxAKSXAgAAADEAppcCAAAAMQD6 lwIAAAAxAACaAgAAADEAUpoCAAAAMQBUmgIAAAAxAFiaAgAAADAAksoBQAAAMQCYigIAAAAx AKDOAUAAADEAoooCAAAAMQDGzgFAAAAxAMqKAgAAADEAFIsCAAAAMABC0AFAAAAxAFqLAgAA ADEAktQBQAAAMQBciwIAAAAxAJrUAUAAADEAbIsCAAAAMAC+1AFAAAAwAG6LAgAAADEAcIsC AAAAMQAAnAIAAAAxAJKLAgAAADAA0FcDQAAAMADSVwNAAAAFAAAARwaQAQAAAgIGAwUEBQID BAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu AAAANQaQAQIAAgAFAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAACAAAAAAFMAeQBtAEMAbwBo AGUAbgAMAEsAYQByAGUAbgAgAFMAaQByAG8AaQBzAAkAcwBzAGEAeQBkAGoAYQByAGkAEABS AG8AYgBlAHIAdAAgAFcALgAgAFMAaABpAHIAZQB5AA0ASwBlAG4AIABUAGgAZQByAGkAYQB1 AGwAdAAMAEwAaQBzAGEAIABSAGEAcABoAGEAZQBsABIAQgByAGkAYQBuACAAQQAuACAATABh AE0AYQBjAGMAaABpAGEADABTAHQAZQB2AGUAIABMAGkAcABuAGUAcgAMAEMAaABhAHIAbABl AHMAIABMAHkAbgBuAAwATABhAHIAcgB5ACAATABhAHkAdABlAG4ADQBDAG8AcgBpACAARAAu ACAAUABlAGUAbABlAA4AUgBvAGIAZQByAHQAIABNAGUAdQBzAGgAYQB3AA0AVABpAG0AIABN AGMAQwBoAGUAcwBuAGUAeQAQAFMAdABlAHYAZQBuACAAQgAuACAATABpAHAAbgBlAHIAAwBz AG0AdwALAEIAbwBiACAAQgBsAGEAawBsAGUAeQAQAEoAbwBlACAAVwBhAGwAdABlAHIAcwAs ACAASgByAC4ADgBEAGUAYgBvAHIAYQBoACAATQBlAGwAbwBuAGUAEwBEAGUAcAB0AC4AIAA3 AEIAIABQAHUAYgBsAGkAYwAgAE0AYQBjABMARwBUAEUAIABJAG4AdABlAHIAbgBlAHQAdwBv AHIAawBpAG4AZwASAFAAcgBlAGYAZQByAHIAZQBkACAAQwB1AHMAdABvAG0AZQByAAwASABv AHcAYQByAGQAIABHAHIAbwBzAHMABABHAFQARQBJABwAVgBhAGwAdQBlAGQAIABHAGEAdABl AHcAYQB5ACAAMgAwADAAMAAgAEMAdQBzAHQAbwBtAGUAcgALAEcAYQByAHkAIABEAGUAZQB0 AGUAcgAOAEsAYQByAGUAbgAgAFMAYQB1AG4AZABlAHIAcwANAFQAaQBtAG8AdABoAHkAIABC AG8AdwBlAG4ADgBMAGkAcwBhACAARABpACAAUABpAGUAdAByAG8ADABKAGEAcwBvAG4AIABS AC4AIABPAGMAaAAJAEQAaQBjAGsAIABMAGkAbwB1ABIASQB2AGEAbgBhACAAUgAuACAAQQBi AHIAdQB6AHoAZQBzAGUAEQBTAGgAbwBwAEwAaQBuAGsAIABFAG0AcABsAG8AeQBlAGUAEgBL AGUAbgBuAGUAdABoACAAUwAuACAARwBvAGwAZABtAGEAbgAOAEIAcgBhAGQAIABEAC4AIABN AGUAZQBoAGEAbgAMAE0AaQBrAGUAIABTAGgAdQBtAHcAYQB5AAoASgBpAG0AIDECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zEC AAABAACCJQAA+zECAAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAAMAACC JQAA+zECAAABAACCJQAA+zECAAAGAACCJQAA+zECAAABAACCJQAA+zECAAAEAACCJQAA+zEC AAABAACCJQAA+zECAAAFAACCJQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAABAACCJQAA+zECAAADAACCJQAA+zECAAABAACCJQAA+zEC AAAJAACCJQAA+zECAAABAACCJQAA+zECAAAEAACCJQAA+zECAAABAACCJQAA+zECAAABAACC JQAA+zECAAABAACCJQAA+zECAAAHAACCJQAA+zECAAABAACCJQAA+zECAAAEAACCJQAA+zEC AAABAACCJQAA+zECAAAJAACCAFMAYwBoAGEAYQBkABQASABlAG0AbQBhACAAUAByAGEAZgB1 AGwAbABjAGgAYQBuAGQAcgBhABMATQBlAGwAaQBzAHMAYQAgAEEALgAgAE0AaQBsAGwAaQBn AGEAbgALAEoAaQBtACAARABlAGwAYQBuAGQAZQAZAEQAcgAuACAAUgBvAGIAZQByAHQAIABX AGkAbABsAGkAYQBtACAAUwBoAGkAcgBlAHkACwBKAGUAZgBmACAAQQBsAGkAYgBlAHIADABQ AGUAdABlAHIAIABIAHUAcwBzAGUAeQANAEgAdQBzAHMAZQB5ACwAIABQAGUAdABlAHIAGgBH AEUATQBQAEwAVQBTACAAQwBBAFIARAAgAEkATgBUAEUAUgBOAEEAVABJAE8ATgBBAEwACgBD AG8AcgBpACAAUABlAGUAbABlAAsASwBhAHkAIABQAGEAdQBtAGkAZQByAA4ATQBlAHIAeQBs ACAARgByAGEAbgB6AG0AYQBuAAMAUwBDAEMABQBjAGMAYQBpAG4AEgBMAGEAdQByAGkAYQB1 AGwAdAAsACAAUwBpAG0AbwBuAG4AZQAMAFMAYwBvAHQAdAAgAEEAdAB3AGUAbABsAAUAcABj AGEAaQBuAA8ARABhAHYAaQBkACAARQBzAGMAYQBsAGEAbgB0AGUACQBFAHMAYwBhAGwAYQBu AHQAZQATAEIAZQBuAGoAYQBtAGkAbgAgAEoALgAgAFcAbwB6AG4AaQBjAGsAFwBCAEIATgAg AEMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AcwAgAEkAbgBjAC4AFABHAFQARQAgAEkAbgB0 AGUAcgBuAGUAdAB3AG8AcgBrAGkAbgBnAC4ACwBCAGkAbABsACAATgBlAGwAcwBvAG4ACQBN AGkAawBlACAASwBvAG4AZwANAEEAbgBkAHIAZQB3ACAAUwBoAG8AcgBlAHMACgBBAHMAYwBl AG4AZAAgAGUAbQBtABoAQQBzAGMAZQBuAGQAIABDAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBu AHMAIABVAHMAZQByAA4ASgBvAGUAIABXAGgAaQB0AGUAaABvAHUAcwBlAAcAQwBhAHMAYwBh AGQAZQAMAEEAYQByAG8AbgAgAEIAYQB3AGMAbwBtAAgAYQBtAGEAZwB1AGkAcgBlABAARgBy AGEAbgBrACAATQBhAG4AaQBzAGMAYQBsAGMAbwACAC4ALgAQAEMAYQB0AGgAZQByAGkAbgBl ACAASwBuAGkAawBlAHIADwBDAGgAcgBpAHMAdABpAG4AZQAgAFMAaQBsAHYAYQANAEIAcgBh AGQAIABEACAATQBlAGUAaCUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADwAAgiUA APsxAgAAAQAAgiUAAPsxAgAAEgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAFAAAgiUAAPsxAgAA AQAAgiUAAPsxAgAADgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAAgiUA APsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAFwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADwAAgiUAAPsxAgAA AQAAgiUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEAAAgiUA APsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADgAAgiUA APsxAgAAAQAAgiUAAPsxAgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAGwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUA APsxAgAACwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAA AQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA CAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUA APsxAgAAJQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA EgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUA APsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAA AQAAgiUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUA APsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAGgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAA AgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgp26AABwvgAAcb4AANC/ AADRvwAADsYAAA/GAACkxgAApcYAAHvKAAB8ygAAbcwAAG7MAAAOzgAAD84AAO7PAADvzwAA mtEAAJvRAACn1AAAqNQAAFjXAABZ1wAA0dkAANLZAABm3QAAZ90AAFLhAABT4QAAXOMAAF3j AABK5QAAS+UAACToAAAl6AAAYeoAAGLqAACE7gAAhe4AAI7vAACP7wAAc/EAAHTxAACE8QAA hfEAAJvxAADn8wAA6PMAAJT0AACV9AAAlvQAALr0AAC79AAAF/YAABj2AACW9gAAl/YAAD33 AAA+9wAAVfcAAJP5AACU+QAAXf4AAF7+AAAp/wAAKv8AAFABAQBRAQEAUgEBAHoBAQD5AQEA +gEBAAwCAQANAgEALgMBAC8DAQB5BAEAegQBAFoFAQBcBQEAAgcBAAMHAQC3BwEAuAcBAJAK AQCRCgEA4woBAOQKAQCgCwEAoQsBAD8MAQBADAEA6w0BAOwNAQD8DQEA/Q0BAP4NAQAaDgEA Dg8BAA8PAQAhDwEA/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39 /f39/QAAAwIPAABkL8QAANnEAADexAAA38QAAHTFAACUxQAAnMUAAKnFAAC2xQAADcYAAPHH AAD1xwAA9scAAADIAAAZyAAAUcgAAHDIAACCyAAAmsgAAAHJAAAayQAAHckAACLJAAAlyQAA kMkAALzJAADOyQAAB8oAAD7KAAA/ygAAesoAAGbMAABszAAAqtAAAM/QAAB60QAAmdEAANjT AABV1AAAptQAAHvWAACI1gAAV9cAAM/ZAAD27fbt5O3k7eQA29Lb0tvSydvJwLfAt8C327eu t64ApQCck4oAioEAgXgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQEIgQRIAQAFaJUcQSYHSAAA EQEIgQRIAQAFaJQcQSYHSAAAEQEIgQRIAQAFaJMcQSYHSAAAEQEIgQRIAQAFaJIcQSYHSAAA EQEIgQRIAQAFaJEcQSYHSAAAEQEIgQRIAQAFaJAcQSYHSAAAEQEIgQRIAQAFaI8cQSYHSAAA EQEIgQRIAQAFaI4cQSYHSAAAEQEIgQRIAQAFaI0cQSYHSAAAEQEIgQRIAQAFaIwcQSYHSAAA EQEIgQRIAQAFaIscQSYHSAAAEQEIgQRIAQAFaIkcQSYHSAAAEQEIgQRIAQAFaIgcQSYHSAAA EQEIgQRIAQAFaIccQSYHSAAAEQEIgQRIAQAFaIYcQSYHSAAAACulxgAAe8oAAHzKAABtzAAA bswAAA7OAAAPzgAA7s8AAO/PAACa0QAAm9EAAKfUAACo1AAAWNcAAFnXAADR2QAA0tkAAGbd AABn3QAAUuEAAFPhAABc4wAAXeMAAErlAABL5QAAJOgAACXoAABh6gAAYuoAAITuAAD8AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAB DwADDwBDJAEAHc/ZAADQ2QAAltsAAJjbAAAe3AAAQtwAAJbcAACy3AAA7twAACTdAABl3QAA F+AAABngAACG4AAAi+AAAJLgAADm4AAAUeEAAEPlAABF5QAASeUAABrnAAC+5wAAv+cAAM3n AADa5wAA3ecAACPoAADa6QAAJuoAAEjqAABf6gAAYOoAAG3sAABv7AAAeOwAAB/tAACH7QAA AO4AAPYA7eTb7dLt5NIA28nAycC3AK6lAJyTnJOckwClioGKAIp4b3hmAAAAAAAAAAAAABEB CIEESAEABWirHEEmB0gAABEBCIEESAEABWipHEEmB0gAABEBCIEESAEABWiqHEEmB0gAABEB CIEESAEABWimHEEmB0gAABEBCIEESAEABWiiHEEmB0gAABEBCIEESAEABWigHEEmB0gAABEB CIEESAEABWifHEEmB0gAABEBCIEESAEABWihHEEmB0gAABEBCIEESAEABWieHEEmB0gAABEB CIEESAEABWidHEEmB0gAABEBCIEESAEABWicHEEmB0gAABEBCIEESAEABWibHEEmB0gAABEB CIEESAEABWiYHEEmB0gAABEBCIEESAEABWiaHEEmB0gAABEBCIEESAEABWiZHEEmB0gAABEB CIEESAEABWiXHEEmB0gAABEBCIEESAEABWiWHEEmB0gAAAAmAO4AAAvuAAAR7gAAF+4AACfu AAAr7gAAQe4AAEjuAACD7gAAWu8AAI3vAACt8AAAcvEAAEzyAABr8gAAgvMAAInzAACZ8wAA 5vMAAOqrAQAgggIAJIICACyCAgAShAIAPIUCAKCGAgBshwIAqocCALCHAgBYiAIAiIoCAJiK AgCiigIA9u3k7fbk7fYA5ADkANvSydLJAMC3rqWck4qBeIFvZl0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAEQEIgQRIAQAFaBlcQUYHSAAAEQEIgQRIAQAFaBdcQUYHSAAAEQEIgQRIAQAFaBZc QUYHSAAAEQEIgQRIAQAFaJQcQSYHSAAAEQEIgQRIAQAFaOBbQUYHSAAAEQEIgQRIAQAFaN9b QUYHSAAAEQEIgQRIAQAFaN5bQUYHSAAAEQEIgQRIAQAFaN1bQUYHSAAAEQEIgQRIAQAFaNxb QUYHSAAAEQEIgQRIAQAFaGNbQUYHSAAAEQEIgQRIAQAFaHAcQSYHSAAAEQEIgQRIAQAFaGFb QUYHSAAAEQEIgQRIAQAFaLAcQSYHSAAAEQEIgQRIAQAFaK8cQSYHSAAAEQEIgQRIAQAFaK4c QSYHSAAAEQEIgQRIAQAFaK0cQSYHSAAAEQEIgQRIAQAFaKscQSYHSAAAEQEIgQRIAQAFaKwc QSYHSAAAACCE7gAAhe4AAI7vAACP7wAAc/EAAHTxAACE8QAAhfEAAJvxAADn8wAA6PMAAJT0 AACV9AAAlvQAALr0AAC79AAAF/YAABj2AACW9gAAl/YAAD33AAA+9wAAVfcAAJP5AACU+QAA Xf4AAF7+AAAp/wAAKv8AAFABAQD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHVABAQBRAQEAUgEBAHoBAQD5AQEA +gEBAAwCAQANAgEALgMBAC8DAQB5BAEAegQBAFoFAQBcBQEAAgcBAAMHAQC3BwEAuAcBAJAK AQCRCgEA4woBAOQKAQCgCwEAoQsBAD8MAQBADAEA6w0BAOwNAQD8DQEA/Q0BAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEPAAAd/Q0BAP4NAQAaDgEADg8BAA8PAQAhDwEAwhABAMQQAQDkEQEA5REBAP0TAQD+EwEA fhgBAH8YAQADGgEABBoBAOgbAQDpGwEAGB0BABkdAQC9HwEAvh8BAOgfAQDpHwEAtSEBALYh AQBcIwEAXSMBAG0jAQBuIwEA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB0lAAD7MQIAAAwAAIIlAAD7MQIAAAEA AIIlAAD7MQIAAAYAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAcAAIIlAAD7MQIAAAEAAIIlAAD7 MQIAAAgAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAsAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAsA AIIlAAD7MQIAAAEAAIIlAAD7MQIAAAkAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAA0AAIIlAAD7 MQIAAAEAAIIlAAD7MQIAAA0AAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAcAAIIlAAD7MQIAAAEA AIIlAAD7MQIAAAwAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAsAAIIlAAD7MQIAAAEAAIIlAAD7 MQIAAAgAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAA4AAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAQA AIIlAAD7MQIAAAEAAIIlAAD7MQIAAAcAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7 MQIAAAEAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAgAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAMA AIIlAAD7MQIAAAEAAIIlAAD7MQIAAAMAAIIlAAD7MQIAAAEAAIIlAAD7MQIAAAAAAFwDAAD1 BgAAVjMAAMU1AAAFOAAAlzoAAJg6AABaPwAA9UAAADRCAAChRgAA1UoAANZKAAA7UAAAPFAA AB9WAAAnWwAAqVwAAKpcAACaYwAArGMAAEpkAABsZAAAjGYAAJ9mAADyagAA82oAANRtAAD+ bwAAmHIAALRyAAAReAAAEngAAPR8AADmfQAA8IEAAPGBAAC5hgAAKYcAACOPAADclQAAw5kA AAmeAAABqQAAAqkAAECqAABBqgAAra8AADGwAACAsgAAgbIAAEG1AAATvAAA6r4AAOu+AAB8 xgAA6soAAHDOAADy0QAAFdQAABbUAABE1wAARdcAAHjaAADy3AAAjuAAAI/gAAB65AAAheYA AOLpAADj6QAAHe0AAB7tAABg7wAAk/kAAJT5AAB++gAAgfoAAJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAA gJoAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAA gJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgAAEAABtPgAAElAAAHFWAAAX ZgAAdHQAAOmDAACYkQAATqYAAK2wAAAvxAAAz9kAAADuAACiigIAop8CADipAgASAQAAGAEA ABoBAAAbAQAAHQEAAB4BAAAhAQAAIgEAACUBAAAnAQAAKQEAACsBAAAsAQAARgEAAFMBAAAA BAAATQ8AANwkAAAFPAAApl0AAIR/AAA7nAAApcYAAITuAABQAQEA/Q0BAG4jAQA6NgEAS0IB ACBPAQDTYgEA8nYBACKGAQAWlQEAO5wBAMefAQDlogEAIKYBANarAQBwiwIAEwEAABUBAAAW AQAAGQEAABwBAAAgAQAAJAEAACoBAAAtAQAALgEAAC8BAAAxAQAAMgEAADMBAAA1AQAANgEA ADcBAAA4AQAAOgEAADsBAAA8AQAAPgEAAD8BAABAAQAAAAQAAAU8AACJegAAQ5kAAK6pAACd AGEAbgAMAEoAaQBtACAATwAnAEMAbwBuAG4AbwByABQAVABlAGMAaABuAGkAYwBhAGwAIABD AG8AcgByAGkAZwBlAG4AZABhABQASABvAHkAdAAgAEwALgAgAEsAZQBzAHQAZQByAHMAbwBu ACAASQBJAAcAUwBCAG8AZQB5AGUAbgAMAFIAbwBkACAATABlAG4AbgBpAGcAZQByAA0ASgBB AE4ARQBUACAATABFAEIATABPAE4ARAADAGIAYgBuAAMARAA0AE0Af/oAAAAAAAABAAAADgAA AC8AAAA5AAAAPgAAAEUAAABIAAAAUgAAAFMAAABZAAAAXAAAAGYAAABnAAAAbQAAAHIAAAB+ AAAArwAAALQAAADIAAAA0AAAANMAAADfAAAA4gAAAPEAAAAmAQAAMgEAAK4BAAC3AQAAPQsA AEwLAAB8DAAAggwAABYNAAAYDQAAGQ0AAC4NAAAyDQAAPQ0AAD4NAABBDQAA+xEAAAcSAAAI EgAAFBIAADMSAAA/EgAAQBIAAEkSAACAEgAAjBIAAI0SAACYEgAAxBIAANASAADREgAA3hIA AHUTAACBEwAAghMAAIoTAAAHFAAAExQAABkYAAAlGAAAvBgAAMsYAAAeHQAAKh0AAEMhAABU IQAAIywAADIsAAA+LAAARywAAOo1AADzNQDWqwEA16sBAOarAQDnqwEA6KsBAOmrAQDqqwEA cIsCAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABEDwBDJAFFxoAAAAEAHFxBRgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAABxwA H7DQLyCw7j0hsCcFIrAnBSOQoAUkkKAFJbAAACwAUwBQAFIARgBDACAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIABtAGUAcwBzAGEAZwBlAHMAIABTAG8ALAAgAHQA aABlACAAYQBuAHMAdwBlAHIAIABoAGUAcgBlACAAaQBzACAAdABoAGEAdAAgAHQAaABlACAA cwBwAGUAYwBpAGYAaQBjAGEAdABpAG8AbgBzACAAYQBsAGwAbwB3ACAAcwBpAHQAZQAgAGEA ZABtAGkAbgBpAHMAdAByAGEAdABvAHIAcwAgAHQAbwAgAG0AYQBrAGUAIABzAGUAYwB1AHIA aQB0AHkALwBmAHUAbgBjAHQAaQBvAG4AYQBsAGkAdAB5ACAAdAByAGEAZABlAG8AZgBmAHMA LAAgAGwAbwBjAGEAbABsAHkALgAgAFQAaABlACAAbABvAG4AZwBlAHIAIAB0AGUAcgBtACAA cwBvAGwAdQB0AGkAbwBuACAAZABlAHMAYwByAGkAYgBlAGQAIAB3AG8AdQBsAGQAIAByAGUA cQB1AGkAcgBlACAAcgBvAHUAdABlAHIAcwAgAHQAbwAgAGkAbQBwAGwAZQBtAGUAbgB0ACAA SQBQAHMAZQBjACwAIABzAG8AIAB0AGgAYQB0ACAAdABoAGUAeQAgAGMAYQBuACAAcwBlAG4A ZAAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABlAGQAIABJAEMATQBQACAAbQBlAHMAcwBhAGcA ZQBzAC4AIABZAGUAcwAsACAAdABoAGkAcwAgAHcAbwB1AGwAZAAgAHIAZQBxAHUAaQByAGUA IABhACAAUABLAEkALAAgAGIAdQB0ACAAcwB1AGMAaAAgAGEAIABQAEsASQAgAG0AYQB5ACAA YQByAGkAcwBlACAAZgBvAHIAIABvAHQAaABlAHIAIAByAGUAYQBzAG8AbgBzAC4AVABlAGQA IABUACcAcwBvACAAYQBuAGQAIABJACAAZABpAHMAYwB1AHMAcwBlAGQAIAB0AGgAaQBzACAA cAByAG8AYgBsAGUAbQAsACAAYQBuAGQAIAB0AHIAaQBlAGQAIAB0AG8AIABlAHgAcABsAGEA aQBuACAAaQB0ACAAdABvACAAdABoAGUAIABsAGkAcwB0ACwAIABiAHUAdAAgAHcAZQByAGUA IAB1AG4AcwB1AGMAYwBlAHMAcwBmAHUAbAAuACAAIABhAHMAIABhAGQAZABpAHQAaQBvAG4A YQBsACwAIABtAGEAbgBkAGEAdABvAHIAeQAgAGQAZQBmAHUAYQBsAHQAcwAgAFsASQAgAEkA bgAgAGEAIABoAGkAZwBoACAAYQBzAHMAdQByAGEAbgBjAGUAIABoAGEAcgBkAHcAYQByAGUA IABpAG0AcABsAGUAbQBlAG4AdABhALoAACEPAQBFSwEALYcBAI6hAQDqqwEAFAEAABcBAAAf AQAAIwEAACYBAAAoAQAAMAEAADQBAAA5AQAAPQEAAP//VwAAAAcAVQBuAGsAbgBvAHcAbgAK AFMAdABlAHYAZQAgAEsAZQBuAHQACQBLAGEAcgBlAG4AIABTAGUAbwADAEIAQgBOAAQAQgBC AE4ALgAGAGYAbwBvAGIAYQByAAsASwBpAG0AIABMAGUAZwBlAGwAaQBzABAAUgBpAGMAaABh AHIAZAAgAEEALgAgAEIAYQByAG8AbgAPAFIAYQBjAGgAZQBsACAARgAuACAAQwBvAGgAZQBu AAwASwBhAHIAZQBuACAAUwBpAHIAbwBpAHMACQBzAHMAYQB5AGQAagBhAHIAaQAQAFIAbwBi AGUAcgB0ACAAVwAuACAAUwBoAGkAcgBlAHkADQBLAGUAbgAgAFQAaABlAHIAaQBhAHUAbAB0 AAwATABpAHMAYQAgAFIAYQBwAGgAYQBlAGwAEgBCAHIAaQBhAG4AIABBAC4AIABMAGEATQBh AGMAYwBoAGkAYQAMAFMAdABlAHYAZQAgAEwAaQBwAG4AZQByAAwAQwBoAGEAcgBsAGUAcwAg AEwAeQBuAG4ADABMAGEAcgByAHkAIABMAGEAeQB0AGUAbgANAEMAbwByAGkAIABEAC4AIABQ AGUAZQBsAGUADgBSAG8AYgBlAHIAdAAgAE0AZQB1AHMAaABhAHcADQBUAGkAbQAgAE0AYwBD AGgAZQBzAG4AZQB5ABAAUwB0AGUAdgBlAG4AIABCAC4AIABMAGkAcABuAGUAcgADAHMAbQB3 AAsAQgBvAGIAIABCAGwAYQBrAGwAZQB5ABAASgBvAGUAIABXAGEAbAB0AGUAcgBzACwAIABK AHIALgAOAEQAZQBiAG8AcgBhAGgAIABNAGUAbABvAG4AZQATAEQAZQBwAHQALgAgADcAQgAg AFAAdQBiAGwAaQBjACAATQBhAGMAEwBHAFQARQAgAEkAbgB0AGUAcgBuAGUAdAB3AG8AcgBr AGkAbgBnABIAUAByAGUAZgBlAHIAcgBlAGQAIABDAHUAcwB0AG8AbQBlAHIADABIAG8AdwBh AHIAZAAgAEcAcgBvAHMAcwAEAEcAVABFAEkAHABWAGEAbAB1AGUAZAAgAEcAYQB0AGUAdwBh AHkAIAAyADAAMAAwACAAQwB1AHMAdABvAG0AZQByAAsARwBhAHIAeQAgAEQAZQBlAHQAZQBy AA4ASwBhAHIAZQBuACAAUwBhAHUAbgBkAGUAcgBzAA0AVABpAG0AbwB0AGgAeQAgAEIAbwB3 AGUAbgAOAEwAaQBzAGEAIABEAGkAIABQAGkAZQB0AHIAbwAMAEoAYQBzAG8AbgAgAFIALgAg AE8AYwBoAAkARABpAGMAawAgAEwAaQBvAHUAEgBJAHYAYQBuAGEAIABSAC4AIABBAGIAcgB1 AHoAegBlAHMAZQARAFMAaABvAHAATABpAG4AawAgAEUAbQBwAGwAbwB5AGUAZQASAEsAZQBu AG4AZQB0AGgAIABTAC4AIABHAG8AbABkAG0AYQBuAA4AQgByAGEAZAAgAEQALgAgAE0AZQBl AGgAYQBuAAwATQBpAGsAZQAgAFMAaAB1AG0AdwBhAHkACgBKAGkAbQAgAFMAYwBoAGEAYQBk ABQASABlAG0AbQBhACAAUAByAGEAZgB1AGwAbABjAGgAYQBuAGQAcgBhABMATQBlAGwAaQBz AHMAYQAgAEEALgAgAE0AaQBsAGwAaQBnAGEAbgALAEoAaQBtACAARABlAGwAYQBuAGQAZQAZ AEQAcgAuACAAUgBvAGIAZQByAHQAIABXAGkAbABsAGkAYQBtACAAUwBoAGkAcgBlAHkACwBK AGUAZgBmACAAQQBsAGkAYgBlAHIADABQAGUAdABlAHIAIABIAHUAcwBzAGUAeQANAEgAdQBz AHMAZQB5ACwAIABQAGUAdABlAHIAGgBHAEUATQBQAEwAVQBTACAAQwBBAFIARAAgAEkATgBU AEUAUgBOAEEAVABJAE8ATgBBAEwACgBDAG8AcgBpACAAUABlAGUAbABlAAsASwBhAHkAIABQ AGEAdQBtAGkAZQByAA4ATQBlAHIAeQBsACAARgByAGEAbgB6AG0AYQBuAAMAUwBDAEMABQBj AGMAYQBpAG4AEgBMAGEAdQByAGkAYQB1AGwAdAAsACAAUwBpAG0AbwBuAG4AZQAMAFMAYwBv AHQAdAAgAEEAdAB3AGUAbABsAAUAcABjAGEAaQBuAA8ARABhAHYAaQBkACAARQBzAGMAYQBs AGEAbgB0AGUACQBFAHMAYwBhAGwAYQBuAHQAZQATAEIAZQBuAGoAYQBtAGkAbgAgAEoALgAg AFcAbwB6AG4AaQBjAGsAFwBCAEIATgAgAEMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AcwAg AEkAbgBjAC4AFABHAFQARQAgAEkAbgB0AGUAcgBuAGUAdAB3AG8AcgBrAGkAbgBnAC4ACwBC AGkAbABsACAATgBlAGwAcwBvAG4ACQBNAGkAawBlACAASwBvAG4AZwANAEEAbgBkAHIAZQB3 ACAAUwBoAG8AcgBlAHMACgBBAHMAYwBlAG4AZAAgAGUAbQBtABoAQQBzAGMAZQBuAGQAIABD AG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBuAHMAIABVAHMAZQByAA4ASgBvAGUAIABXAGgAaQB0 AGUAaABvAHUAcwBlAAcAQwBhAHMAYwBhAGQAZQAMAEEAYQByAG8AbgAgAEIAYQB3AGMAbwBt AAgAYQBtAGEAZwB1AGkAcgBlABAARgByAGEAbgBrACAATQBhAG4AaQBzAGMAYQBsAGMAbwAC AC4ALgAQAEMAYQB0AGgAZQByAGkAbgBlACAASwBuAGkAawBlAHIADwBDAGgAcgBpAHMAdABp AG4AZQAgAFMAaQBsAHYAYQANAEIAcgBhAGQAIABEACAATQBlAGUAaABhAG4ADABKAGkAbQAg AE8AJwBDAG8AbgBuAG8AcgAUAFQAZQBjAGgAbgBpAGMAYQBsACAAQwBvAHIAcgBpAGcAZQBu AGQAYQAUAEgAbwB5AHQAIABMAC4AIABLAGUAcwB0AGUAcgBzAG8AbgAgAEkASQAHAFMAQgBv AGUAeQBlAG4ADABSAG8AZAAgAEwAZQBuAG4AaQBnAGUAcgANAEoAQQBOAEUAVAAgAEwARQBC AEwATwBOAEQAAwBiAGIAbgADAEQANABNAH/6AAAAAAAAAQAAAA4AAAAvAAAAOQAAAD4AAABF AAAASAAAAFIAAABTAAAAWQAAAFwAAABmAAAAZwAAAG0AAAByAAAAfgAAAK8AAAC0AAAAyAAA ANAAAADTAAAA3wAAAOIAAADxAAAAJgEAADIBAACuAQAAtwEAAD0LAABMCwAAfAwAAIIMAAAW DQAAGA0AABkNAAAuDQAAMg0AAD0NAAA+DQAAQQ0AAPsRAAAHEgAACBIAABQSAAAzEgAAPxIA AEASAABJEgAAgBIAAIwSAACNEgAAmBIAAMQSAADQEgAA0RIAAN4SAAB1EwAAgRMAAIITAACK EwAABxQAABMUAAAZGAAAJRgAALwYAADLGAAAHh0AACodAABDIQAAVCEAACMsAAAyLAAAPiwA AEcsAADqNQAA8zUAAFU6AABZOgAA5UAAAPNAAAD8VwAADFgAADFqAAA0agAA728AAPxvAAAg cAAALXAAAKp1AACvdQAAH3cAACR3AACnfAAAqnwAAJt+AAChfgAAWIAAAFuAAACDhwAAh4cA AHSIAAB4iAAADIoAABCKAACZigAAnYoAABiOAAAbjgAAgJQAAI2UAAChlAAApJQAADKVAAA1 lQAA1ZcAANiXAADxlwAA/pcAADyYAAA/mAAAJJkAACeZAAD/mQAADJoAAFGaAABUmgAAyJoA ANSaAADVmgAA3JoAAFybAABfmwAAzJsAAM6bAAAinAAAKZwAAIOdAACGnQAAo50AAKadAADn nQAA6p0AAFygAABfoAAAraQAALCkAAAkqAAAJ6gAAJ2pAACpqQAAqqkAALipAAC6rAAAw6wA AF+6AABqugAA67wAAO68AAAdywAAJssAAKnLAACyywAACMwAABHMAACJzAAAkswAAAbNAAAP zQAAXs0AAGfNAABfzgAAaM4AAHnTAAB90wAAbdUAAH/VAADl2gAA8NoAAEfbAABa2wAA0NsA ANvbAAA+3gAASd4AAADhAAAD4QAABuEAAAnhAAAL4QAAEOEAABbhAAAX4QAAZOEAAHThAADk 4gAA7+IAAHPjAACA4wAAheUAAInlAACT5QAAmeUAAIH6AAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcA//8UAAAACgBTAHQAZQB2AGUAIABLAGUAbgB0ABMASABhAHIAZAAgAEQAaQBz AGsAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAEwBIAGEAcgBk ACAARABpAHMAawA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAASwBlAG4AdAAW AE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4AdABlAHgACgBTAHQAZQB2 AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBJAFAAUwBlAGMALgB0 AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAFgBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6 AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAASwBlAG4AdAAWAE0AYQBjAGkAbgB0 AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4AdABlAHgACgBTAHQAZQB2AGUAIABLAGUAbgB0 ABYATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABl AHYAZQAgAEsAZQBuAHQAOQBIAGEAcgBkACAARABpAHMAawA6AFQAZQBtAHAAbwByAGEAcgB5 ACAASQB0AGUAbQBzADoAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBm ACAASQBQAHMAZQBjACAAcgBlAHYAaQAKAFMAdABlAHYAZQAgAEsAZQBuAHQAJQBIAGEAcgBk ACAARABpAHMAawA6AEkAUABTAEUAQwA6AEkAUABzAGUAYwAgAHIAZQB2AGkAZQB3ACAAYwBv AG0AbQBlAG4AdABzAAoAUwB0AGUAdgBlACAASwBlAG4AdAAlAEgAYQByAGQAIABEAGkAcwBr ADoASQBQAFMARQBDADoASQBQAHMAZQBjACAAcgBlAHYAaQBlAHcAIABjAG8AbQBtAGUAbgB0 AHMA/0ADgAEAffoAAH36AAB4x1wGEQIRAn36AAAAAAAAffoAAAAAAAABAAEAxQKkAgGDAEXG gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAYYAQyQBRcaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACfAkA AAAAAABkSgAAZUoAAGZKAABrSgAAjUoAAJZKAACiSgAA00oAANZKAAB3TAAAfUwAAH9MAACA TAAAgUwAAM5MAADTTAAA1EwAANtMAADxTAAA/0wAAB9NAAAgTQAAI00AACxNAABkTQAAhk0A ALtNAADVTQAA300AAOZNAADoTQAACU4AABNOAAAcTgAAVk4AAFdOAABbTgAAZU4AAGpOAACM TgAApU4AAK1OAACuTgAAO1AAANJqAADUagAA6WoAAO9qAABorwAAaa8AAGSyAABmsgAAz7QA AOC0AADotAAA6bQAAO60AAD4tAAAAbUAABS1AABsvQAAdL0AAHW9AACSvQAA7b0AAPG9AAAN vgAADr4AABC+AAAXvgAAGL4AALS+AADQvgAA4b4AAOe+AADCwgAAxsIAABzDAAAlwwAAM8UA ADTFAAA1xQAAN8UAAFPFAABtxQAAsMUAALHFAAC0xQAAyMUAAOvFAAD2xQAA+8UAAPzFAAAw xgAAMcYAADTGAABdxgAAesYAAO3LAADxywAA8ssAAPzLAAD9ywAABMwAAAfMAABHzAAATcwA AE7MAABbzAAAXMwAAF3MAABezAAAe8wAAN/MAAAmzQAAL80AADjNAAA6zQAAO80AAD3NAAB+ zQAAtc0AALbNAAC9zQAA680AAOzNAABvzgAAddMAAHbTAAB50wAAftMAAJPTAADt0wAA/NYA AP/WAAAZ1wAAGtcAABvXAAAe1wAAGNkAABvZAABi2QAAf9kAAIPZAACI2QAAkdkAACLaAAAj 2gAAJNoAACXaAAAo2gAALNoAAHbaAADF3wAAzd8AAH3jAAB45AAAbegAAG7oAABv6AAAmOgA AMfoAADj6AAAE+kAAD/pAABA6QAAaukAAHvpAACk6QAApekAAKfpAADh6QAA6OsAAO3rAAAA 7AAAFOwAANLsAAD37AAAGu0AAEHvAABC7wAAQ+8AAEvvAABd7wAAXu8AAJP5AACU+QAApfkA AKf5AADA+QAAwfkAANX5AADp+QAACfoAAAz6AAAT+gAAFPoAABz6AAA1+gAAffoAAH76AAB/ +gAAMAAACABAAAAxAACeAgAAADEAAp4CAAAAMQAEngIAAAAxAA6eAgAAADEAUp4CAAAAMQBk ngIAAAAxAHyeAgAAADAAyJwAQAAAMQDOnABAAQAxAN6eAgAAADEAEKAAQAEAMQDqngIAAAAx AOyeAgAAADEA7p4CAAAAMQCInwIAAAAxAJKfAgAAADEAlJ8CAAAAMQCinwIAAAAxAM6fAgAA ADEA6p8CAAAAMQAqoAIAAAAxACygAgAAADEAMqACAAAAMQBEoAIAAAAxALSgAgAAADEA+KAC AAAAMQBioQIAAAAxAJahAgAAADEAqqECAAAAMQC4oQIAAAAxALyhAgAAADEA/qECAAAAMQAS ogIAAAAxACSiAgAAADEAmKICAAAAMQCaogIAAAAxAKKiAgAAADEAtqICAAAAMQDAogIAAAAx AASjAgAAADEANqMCAAAAMQBGowIAAAAwAFqiAEADADAAdKUAQAAAMQAeqAIAAAAxAKLaAEAA ADEAIqgCAAAAMADM2gBAAAAxAB6CAgAAADAAvmMBQAAAMQAgggIAAAAwALhpAUAAADEALqgC AAAAMQBQqAIAAAAxAGCoAgAAADEAYqgCAAAAMQBsqAIAAAAxAICoAgAAADEAvm4BQAAAMADk bgFAAAAxAACOAgAAADEAEI4CAAAAMQASjgIAAAAxAEyOAgAAADEAAo8CAAAAMQAKjwIAAAAx AEKPAgAAADEARI8CAAAAMQBIjwIAAAAxAFaPAgAAADEAWI8CAAAAMQCQkAIAAAAxAMiQAgAA ADEA6pACAAAAMACafwFAAAAxACSCAgAAADEAUIcBQAAAMQAAhAIAAAAxAPyHAUAAADEAEoQC AAAAMQAUhAIAAAAxABaEAgAAADEAGoQCAAAAMQBShAIAAAAxAIaEAgAAADEADIUCAAAAMQAO hQIAAAAxABSFAgAAADEAPIUCAAAAMQCChQIAAAAxAJiFAgAAADEAooUCAAAAMQCkhQIAAAAx AAyGAgAAADEADoYCAAAAMQAUhgIAAAAxAGaGAgAAADAAGIwBQAAAMQD2kAIAAAAxAP6QAgAA ADEAAJECAAAAMQAUkQIAAAAxABaRAgAAADEAJJECAAAAMQAqkQIAAAAxAKqRAgAAADEAtpEC AAAAMQC4kQIAAAAxANKRAgAAADEA1JECAAAAMQDWkQIAAAAxANiRAgAAADEA/pYBQAAAMQAS kgIAAAAxAKCSAgAAADEAspICAAAAMQDEkgIAAAAxAMiSAgAAADEAypICAAAAMQDOkgIAAAAx AFCTAgAAADEAvpMCAAAAMQDAkwIAAAAxAM6TAgAAADEAKpQCAAAAMQDGlwFAAAAwANiYAUAA ADEAoIYCAAAAMQCihgIAAAAxAKiGAgAAADEAAIoCAAAAMQCyhgIAAAAwAOSiAUAAADEAZocC AAAAMQCSqAIAAAAxAKKHAgAAADEAxqgCAAAAMQCkhwIAAAAwAAKpAUAAADEAqocCAAAAMQD8 rAFAAAAxACqKAgAAADEAZIoCAAAAMQBsigIAAAAxAHaKAgAAADEAiq0BQAAAMQCwhwIAAAAx ALKHAgAAADEAtIcCAAAAMQC2hwIAAAAxALyHAgAAADEAxIcCAAAAMACsrgFAAAAxAIiKAgAA ADAASrkBQAAAMQCqwAFAAAAwAKDCAUAAADEAAJYCAAAAMQAClgIAAAAxAASWAgAAADEAVpYC AAAAMQC0lgIAAAAxAOyWAgAAADEATJcCAAAAMQCklwIAAAAxAKaXAgAAADEA+pcCAAAAMQAA mgIAAAAxAFKaAgAAADEAVJoCAAAAMQBYmgIAAAAwAJLKAUAAADEAmIoCAAAAMQCgzgFAAAAx AKKKAgAAADEAxs4BQAAAMQDKigIAAAAxABSLAgAAADAAQtABQAAAMQBaiwIAAAAxAJLUAUAA ADEAXIsCAAAAMQCa1AFAAAAxAGyLAgAAADAAvtQBQAAAMABuiwIAAAAxAHCLAgAAADEAAJwC AAAAMQCSiwIAAAAxAEijAgAAADEASqMCAAAAMQDIqAIAAAAxAPCoAgAAADEAMKkCAAAAMQC6 owIAAAAxADapAgAAADEAyKMCAAAAMQDYowIAAAAxAAqkAgAAADAA0FcDQAAAMADSVwNAAAAF AAAARwaQAQAAAgIGAwUEBQIDBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAg AE4AZQB3ACAAUgBvAG0AYQBuAAAANQaQAQIAAgAFAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAA AACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQAQAAAgsGBAICAgICBAAAAAMAAAAAAAAAAAAAAAAB AAAAAAAAAEEAcgBpAGEAbAAAADMGkAEAAAIABQAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAQAA AAAAAABUAGkAbQBlAHMAAAA/BpABAAACBwMJAgIFAgQEAAAAAwAAAAAAAAAAAAAAAAEAAAAA AAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAIgAEAHGIiBgAANACAABoAQAAAACrijymLKpB pgAAAAAxAIkBAACvIwAAa8sAABIAaAAAAAQAgxCxAQAAAAAAAAAAAAASAAEAAAABAAAAAAAA AOwDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0 ALQAgAAeMAAAEQAZAGQAAAAZAAAAz/kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGRKAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAXQL//xIAAAAAAAAALQBc AGQAbwBjAHUAbQBlAG4AdABjAGwAYQBzAHMAWwBjAGgAYQBwAHQAZQByAHAAYQBnAGUALAAx ADIAcAB0AF0AewBjAG8AdQBuAHQAZQByAHAAYQBuAGUAfQAAAAAAAAAKAFMAdABlAHYAZQAg AEsAZQBuAHQACgBTAHQAZQB2AGUAIABLAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0AGkAbwBuACwAIAB0AGgAZQAgAGMA cgB5AHAAdABvACAAYwBoAGkAcAAgAHcAbwB1AGwAZAAgAGcAZQBuAGUAcgBhAHQAZQAgAHQA aABlACAASQBWAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACgAYwBvAC0AYwBoAGEAaQByACAAbwBmACAAdABoAGUAIABXAEcAKQAgAGEAcwAgAHMA dQBnAGcAZQBzAHQAZQBkACAAaQBuACAAdABoAGUAIAB0AGUAeAB0ACAAZgBvAHIAIABDAEIA QwAgAG0AbwBkAGUAIABjAGkAcABoAGUAcgBzACwAIABjAHUAcgByAGUAbgB0ACAASQBFAFQA RgAgAHAAYQByAGEAbQBlAHQAZQByAGkAegBhAHQAaQBvAG4AIABvAGYAIAAgAGEAbgBkACAA cwBvACAAbwBuAGUAIABtAGEAeQAgAHMAZQBlACAAUgBGAEMAcwAgAHQAaABhAHQAIABzAHAA ZQBjAGkAZgB5ACAAYQAgAHYAYQByAGkAZQB0AHkAIABvAGYAIABhAGQAZABpAHQAaQBvAG4A YQBsACAAYQBsAGcAbwByAGkAdABoAG0AcwAhAFQAaABpAHMAIABpAHMAIAAuAA0ASQAgAGgA YQB2AGUAIABuAG8AdAAgAHIAZQB2AGkAZQB3ACAAdABoAGUAIABJAFMAQQBLAE0AUAAvAEkA SwBFACAAYwBvAG0AbQBlAG4AdABzAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoooCAFqLAgBciwIAbIsCAG6LAgDEiwIA EI4CABKOAgBMjgIASI8CAJCQAgDIkAIA6pACAPaQAgASkgIAoJICALKSAgDEkgIAzpMCACqU AgAslAIAVpYCAOyWAgCmlwIAHJgCAB6YAgAgmAIAzJoCAAScAgDengIAop8CAPbt9uTb0snA ycC3wLeupZylnJOlioF4gYp4b2ZdVAAAAAAAAAAAAAAAAAAAEQEIgQRIAQAFaPmSQUYHSAAA EQEIgQRIAQAFaPiSQUYHSAAAEQEIgQRIAQAFaGNkQWYHSAAAEQEIgQRIAQAFaGJkQWYHSAAA EQEIgQRIAQAFaGFkQWYHSAAAEQEIgQRIAQAFaGBkQWYHSAAAEQEIgQRIAQAFaF9kQWYHSAAA EQEIgQRIAQAFaFlkQWYHSAAAEQEIgQRIAQAFaFhkQWYHSAAAEQEIgQRIAQAFaFdkQWYHSAAA EQEIgQRIAQAFaFVkQWYHSAAAEQEIgQRIAQAFaFJkQWYHSAAAEQEIgQRIAQAFaFFkQWYHSAAA EQEIgQRIAQAFaFBkQWYHSAAAEQEIgQRIAQAFaE5kQWYHSAAAEQEIgQRIAQAFaBxcQUYHSAAA EQEIgQRIAQAFaBtcQUYHSAAAEQEIgQRIAQAFaKYcQSYHSAAAEQEIgQRIAQAFaBpcQUYHSAAA AB50AGgAZQAgAHQAZQB4AHQAIABpAG4AIAB0AGgAZQAgAGIAZQBnAGkAbgBuAGkAbgBnACAA bwBmACAAcwBlAGMAdABpAG8AbgAgADYAIABpAHMAIABlAG0AcABoAGEAcwBpAHoAaQBuAGcA IAB0AGgAYQB0ACAAYQBuACAAUwBBACAAZgByAG8AbQAgAGEAIAByAG8AdQB0AGUAcgAgAHQA bwAgAGEAIABoAG8AcwB0ACAAbwByACAAcwBlAGMAdQByAGkAdAB5ACAAZwBhAHQAZQB3AGEA eQAsACAAbQB1AHMAdAAgAGIAZQAgAGEAIAB0AHUAbgBuAGUAbAAgAG0AbwBkAGUAIABTAEEA LAAgAHYAcwAuACAAYQAgAHQAcgBhAG4AcwBwAG8AcgB0ACAAbQBvAGQAZQAgAFMAQQAuACAA SQBmACAAdwBlACAAZABpAGQAbgAZIHQAIABtAGEAawBlACAAdABoAGkAcwAgAGMAbABlAGEA cgAsACAAcwBvAG0AZQBvAG4AZQAgAG0AaQBnAGgAdAAgAGMAaABvAG8AcwBlACAAdABvACAA ZQBzAHQAYQBiAGwAaQBzAGgAIABhACAAdAByAGEAbgBzAHAAbwByAHQAIABtAG8AZABlACAA UwBBACAAZgByAG8AbQAgAGEAbgAgAGkAbgB0AGUAcgBtAGUAZABpAGEAdABlACAAcwB5AHMA dABlAG0ALAAgAGEAbgBkACAAdABoAGkAcwAgAHcAbwB1AGwAZAAgAGMAYQB1AHMAZQAgAHQA aABlACAAcwBvAHUAcgBjAGUAIABhAGQAZAByAGUAcwBzACAAYwBoAGUAYwBrAHMAIAB0AG8A IABmAGEAaQBsACAAdQBuAGQAZQByACAAYwBlAHIAdABhAGkAbgAgAGMAaQByAGMAdQBtAHMA dABhAG4AYwBlAHMALAAgAGEAcwAgAG4AbwB0AGUAZAAgAGIAeQAgAHQAaABlACAAdABlAHgA dAAuAFsAeQBvAHUAGSByAGUAIAByAGkAZwBoAHQALgAgAEUAeABhAGMAdABsAHkAIABvAG4A ZQAgAGEAdQBkAGkAdABhAGIAbABlACAAZQB2AGUAbgB0ACAAaQBuACAAMgA0ADAANgAgAGQA bwBlAHMAIABuAG8AdAAgAHMAcABlAGMAaQBmAHkAIAB0AGgAZQAgAGwAaQBzAHQAIABvAGYA IABkAGEAdABhACAAdABoAGEAdAAgAFMASABPAFUATABEACAAYgBlACAAYQB1AGQAaQB0AGUA ZAAuACAAIABXAGUAGSBsAGwAIABmAGkAeAAgAHQAaABhAHQAIABpAG4AIAB0AGgAZQAgAG4A ZQB4AHQAIABwAGEAcwBzAC4AWwB0AGgAZQByAGUAIABhAHIAZQAgAGUAeABhAGMAdABsAHkA IAAzACAAZQB2AGUAbgB0AHMAIABkAGUAZgBpAG4AZQBkACAAYQBzACAAYQB1AGQAaQB0AGEA YgBsAGUAIABpAG4AIAAyADQAMAAxACwAIABvAG4AZQAgAG8AZgAgAHcAaABpAGMAaAAgAG8A dgBlAHIAbABhAHAAcwAgAHcAaQB0AGgAIAAyADQAMAA2AC4AIABTAG8ALAAgAHQAbwAgAGIA ZQAgAG0AbwByAGUAIABwAHIAZQBjAGkAcwBlACwAIAB0AGgAZQAgAG8AdABoAGUAcgAgADIA IABhAHUAZABpAHQAYQBiAGwAZQAgAGUAdgBlAG4AdABzACAAZABlAGYAaQBuAGUAZAAgAGkA bgAgADIANAAwADEAIABvAHUAZwBoAHQAIAB0AG8AIABoAGEAdgBlACAAdABoAGUAIABtAGkA bgBpAG0AdQBtACAAZABhAHQAYQAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzACAAZABlAGYA aQBuAGUAZAAuACAAIABBAG4AbwB0AGgAZQByACAAZwBvAG8AZAAgAHAAbwBpAG4AdAAgAHQA aABhAHQAIAB3AGUAIAB3AGkAbABsACAAZgBpAHgAIABpAG4AIAB0AGgAZQAgAG4AZQB4AHQA IABwAGEAcwBzAC4AXQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEkA IABhAGcAcgBlAGUAIAB0AGgAYQB0ACAAdABoAGkAcwAgAGEAbABnAG8AcgBpAHQAaABtACAA cwBwAGUAYwAgAG8AdQBnAGgAdAAgAG4AbwB0ACAAZQBuAGMAbwB1AHIAYQBnAGUAIABuAGUA ZwBvAHQAaQBhAHQAaQBvAG4AIABvAGYAIAB0AGgAZQAgAG4AdQBtAGIAZQByACAAbwBmACAA cgBvAHUAbgBkAHMALAAgAHcAaQB0AGgAbwB1AHQAIABzAHAAZQBjAGkAZgB5AGkAbgBnACAA YQAgAG0AaQBuAGkAbQB1AG0AIABmAG8AcgAgAGUAYQBjAGgAIABjAGkAcABoAGUAcgAsACAA YQBsAHQAaABvAHUAZwBoACAAdABoAGkAcwAgAGcAZQB0AHMAIAB1AHMAIABpAG4AdABvACAA dABoAGUAIABjAHIAeQBwAHQAbwAgAHMAdAByAGUAbgBnAHQAaAAgAHYAYQBsAHUAZQAgAGoA dQBkAGcAZQBtAGUAbgB0ACAAYQByAGUAbgBhACAAYQBnAGEAaQBuAC4AIABBAGwAcwBvACwA IAB0AGgAZQAgAGkAbgBjAGwAdQBzAGkAbwBuACAAbwBmACAAMwBEAEUAUwAgAGkAbgAgAHQA aABpAHMAIAB0AGEAYgBsAGUAIABpAHMAIABpAG4AYQBwAHAAcgBvAHAAcgBpAGEAdABlACEA XQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAGEA cwAgAGkAdAAgAGkAcwAgAGEAIAA0ADgAIAByAG8AdQBuAGQAIABhAGwAZwBvAHIAaQB0AGgA bQAsACAAcABlAHIAaQBvAGQALgAgACAAUwBvACwAIAB5AGUAcwAsACAAdABoAGUAcgBlACAA aQBzACAAZABlAGYAaQBuAGkAdABlACAAcgBvAG8AbQAgAGYAbwByACAAaQBtAHAAcgBvAHYA ZQBtAGUAbgB0ACAAaQBuACAAdABoAGkAcwAgAFIARgBDAC4AXQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGUAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGIAbwBs AAAAMwaQAQAAAgsGBAICAgICBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAA ADMGkAEAAAIABQAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAAAA/ BpABAAACBwMJAgIFAgQEAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAAQwBvAHUAcgBpAGUAcgAg AE4AZQB3AAAAIgAEAHGIiBgAANACAABoAQAAAACrijymY2RBZgAAAAAvADMBAACvIwAAa8sA ABIAaAAAAAQAgxCxAQAAAAAAAAAAAAASAAEAAAABAAAAAAAAAOwDAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAAeMAAAEQAZAGQAAAAZ AAAAz/kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMu7AAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAXQL//xIAAAAAAAAALQBcAGQAbwBjAHUAbQBlAG4AdABj AGwAYQBzAHMAWwBjAGgAYQBwAHQAZQByAHAAYQBnAGUALAAxADIAcAB0AF0AewBjAG8AdQBu AHQAZQByAHAAYQBuAGUAfQAAAAAAAAAKAFMAdABlAHYAZQAgAEsAZQBuAHQACgBTAHQAZQB2 AGUAIABLAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAVAAoAAQBbAA8AAgADAAAAAwAo AABA8f8CACgAAAAGAE4AbwByAG0AYQBsAAAAAgAAAAgAQ0oYAG1ICQQAAAAAAAAAAAAAAAAA AAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAg AEYAbwBuAHQAAAAAAAAAAAAAAAAANABaQAEA8gA0AAAACgBQAGwAYQBpAG4AIAAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAA giUAAPsxAgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADwAA giUAAPsxAgAAAQAAgiUAAPsxAgAAEgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAFAAAgiUAAPsx AgAAAQAAgiUAAPsxAgAADgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAA giUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAFwAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAA giUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADwAAgiUAAPsx AgAAAQAAgiUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAEAAA giUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADgAA giUAAPsxAgAAAQAAgiUAAPsxAgAAEAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAGwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAA giUAAPsxAgAACwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAA giUAAPsxAgAAJQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAEgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAgAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAA giUAAPsxAgAACgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAGgAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADAAA giUAAPsxAgAAAQAAgiUAAPsxAgAABgAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsx AgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACwAAgiUAAPsxAgAAAQAA giUAAPsxAgAACwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACQAAgiUAAPsxAgAAAQAAgiUAAPsx AgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAA giUAAPsxAgAAAQAAgiUAAPsxAgAADAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACwAAgiUAAPsx AgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAADgAAgiUAAPsxAgAAAQAA giUAAPsxAgAABAAAgiUAAPsxAgAAAQAAgiUAAPsxAgAABwAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAQAAgiUAAPsxAgAACAAAgiUAAPsxAgAAAQAA giUAAPsxAgAAAwAAgiUAAPsxAgAAAQAAgiUAAPsxAgAAAwAAgiUAAPsxAgAAAQAAgiUAAPsx AgAAAAAAAQAAAKQBAAA9BQAAnjEAAA00AABNNgAA3zgAAOA4AACiPQAAPT8AAHxAAADpRAAA HUkAAB5JAACDTgAAhE4AAGdUAABvWQAA8VoAAPJaAADiYQAA9GEAAJJiAAC0YgAA1GQAAOdk AAA6aQAAO2kAABxsAABGbgAA4HAAAPxwAABZdgAAWnYAADx7AAAufAAAOIAAADmAAAABhQAA cYUAAGuNAAAklAAAC5gAAFGcAABJpwAASqcAAIioAACJqAAA9a0AAHmuAADIsAAAybAAAImz AABbugAAMr0AADO9AADExAAAMskAALjMAAA60AAAXdIAAF7SAACM1QAAjdUAAMDYAAA62wAA 1t4AANfeAADC4gAAzeQAACroAAAr6AAAZesAAGbrAACo7QAA2/cAANz3AADG+AAAyfgAAJoA AAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4A AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4A AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJoAAAAPAAAAAAAAAACAAAAAgJ4A AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJ4AAAAAAAAAAAAAAACAAAAAgJgA AAAPAAAAAAAAAACAAAAAgJwAAAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJgAAAAPAAAAAAAAAACAAAAAgJwA AAAAAAAAAAAAAACAAAAAgAAEAABtPgAAElAAAHFWAAAXZgAAdHQAAOmDAACYkQAATqYAAK2w AAAvxAAAz9kAAADuAACiigIAop8CADipAgASAQAAGAEAABoBAAAbAQAAHQEAAB4BAAAhAQAA IgEAACUBAAAnAQAAKQEAACsBAAAsAQAARgEAAFMBAAAABAAATQ8AANwkAAAFPAAApl0AAIR/ AAA7nAAApcYAAITuAABQAQEA/Q0BAG4jAQA6NgEAS0IBACBPAQDTYgEA8nYBACKGAQAWlQEA O5wBAMefAQDlogEAIKYBANarAQBwiwIAEwEAABUBAAAWAQAAGQEAABwBAAAgAQAAJAEAACoB AAAtAQAALgEAAC8BAAAxAQAAMgEAADMBAAA1AQAANgEAADcBAAA4AQAAOgEAADsBAAA8AQAA PgEAAD8BAABAAQAAAAQAAAU8AACJegAAQ5kAAK6pAACdugAAIQ8BAEVLAQAthwEAjqEBAOqr AQAUAQAAFwEAAB8BAAAjAQAAJgEAACgBAAAwAQAANAEAADkBAAA9AQAA//9XAAAABwBVAG4A awBuAG8AdwBuAAoAUwB0AGUAdgBlACAASwBlAG4AdAAJAEsAYQByAGUAbgAgAFMAZQBvAAMA QgBCAE4ABABCAEIATgAuAAYAZgBvAG8AYgBhAHIACwBLAGkAbQAgAEwAZQBnAGUAbABpAHMA EABSAGkAYwBoAGEAcgBkACAAQQAuACAAQgBhAHIAbwBuAA8AUgBhAGMAaABlAGwAIABGAC4A IABDAG8AaABlAG4ADABLAGEAcgBlAG4AIABTAGkAcgBvAGkAcwAJAHMAcwBhAHkAZABqAGEA cgBpABAAUgBvAGIAZQByAHQAIABXAC4AIABTAGgAaQByAGUAeQANAEsAZQBuACAAVABoAGUA cgBpAGEAdQBsAHQADABMAGkAcwBhACAAUgBhAHAAaABhAGUAbAASAEIAcgBpAGEAbgAgAEEA LgAgAEwAYQBNAGEAYwBjAGgAaQBhAAwAUwB0AGUAdgBlACAATABpAHAAbgBlAHIADABDAGgA YQByAGwAZQBzACAATAB5AG4AbgAMAEwAYQByAHIAeQAgAEwAYQB5AHQAZQBuAA0AQwBvAHIA aQAgAEQALgAgAFAAZQBlAGwAZQAOAFIAbwBiAGUAcgB0ACAATQBlAHUAcwBoAGEAdwANAFQA aQBtACAATQBjAEMAaABlAHMAbgBlAHkAEABTAHQAZQB2AGUAbgAgAEIALgAgAEwAaQBwAG4A ZQByAAMAcwBtAHcACwBCAG8AYgAgAEIAbABhAGsAbABlAHkAEABKAG8AZQAgAFcAYQBsAHQA ZQByAHMALAAgAEoAcgAuAA4ARABlAGIAbwByAGEAaAAgAE0AZQBsAG8AbgBlABMARABlAHAA dAAuACAANwBCACAAUAB1AGIAbABpAGMAIABNAGEAYwATAEcAVABFACAASQBuAHQAZQByAG4A ZQB0AHcAbwByAGsAaQBuAGcAEgBQAHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUA cgAMAEgAbwB3AGEAcgBkACAARwByAG8AcwBzAAQARwBUAEUASQAcAFYAYQBsAHUAZQBkACAA RwBhAHQAZQB3AGEAeQAgADIAMAAwADAAIABDAHUAcwB0AG8AbQBlAHIACwBHAGEAcgB5ACAA RABlAGUAdABlAHIADgBLAGEAcgBlAG4AIABTAGEAdQBuAGQAZQByAHMADQBUAGkAbQBvAHQA aAB5ACAAQgBvAHcAZQBuAA4ATABpAHMAYQAgAEQAaQAgAFAAaQBlAHQAcgBvAAwASgBhAHMA bwBuACAAUgAuACAATwBjAGgACQBEAGkAYwBrACAATABpAG8AdQASAEkAdgBhAG4AYQAgAFIA LgAgAEEAYgByAHUAegB6AGUAcwBlABEAUwBoAG8AcABMAGkAbgBrACAARQBtAHAAbABvAHkA ZQBlABIASwBlAG4AbgBlAHQAaAAgAFMALgAgAEcAbwBsAGQAbQBhAG4ADgBCAHIAYQBkACAA RAAuACAATQBlAGUAaABhAG4ADABNAGkAawBlACAAUwBoAHUAbQB3AGEAeQAKAEoAaQBtACAA UwBjAGgAYQBhAGQAFABIAGUAbQBtAGEAIABQAHIAYQBmAHUAbABsAGMAaABhAG4AZAByAGEA EwBNAGUAbABpAHMAcwBhACAAQQAuACAATQBpAGwAbABpAGcAYQBuAAsASgBpAG0AIABEAGUA bABhAG4AZABlABkARAByAC4AIABSAG8AYgBlAHIAdAAgAFcAaQBsAGwAaQBhAG0AIABTAGgA aQByAGUAeQALAEoAZQBmAGYAIABBAGwAaQBiAGUAcgAMAFAAZQB0AGUAcgAgAEgAdQBzAHMA ZQB5AA0ASAB1AHMAcwBlAHkALAAgAFAAZQB0AGUAcgAaAEcARQBNAFAATABVAFMAIABDAEEA UgBEACAASQBOAFQARQBSAE4AQQBUAEkATwBOAEEATAAKAEMAbwByAGkAIABQAGUAZQBsAGUA CwBLAGEAeQBpAGEAcgB5AC4AIABGAG8AcgAgAGUAeABhAG0AcABsAGUALAAgAEEASAAgAGMA YQBuACAAYgBlACAAdQBzAGUAZAAgACAAYgBlAHQAdwBlAGUAbgAgAGEAIABoAG8AcwB0ACAA aQBuAHMAaQBkAGUAIABhAG4AIABlAG4AYwBsAGEAdgBlACAAYQBuAGQAIABhACAAcwBlAGMA dQByAGkAdAB5ACAAZwBhAHQAZQB3AGEAeQAgAGEAdAAgAHQAaABlACAAcABlAHIAaQBtAGUA dABlAHIALAAgAHQAbwAgAGEAbABsAG8AdwAgAHQAaABlACAAUwBHACAAdABvACAAYwBvAG4A dAByAG8AbAAgAHcAaABhAHQAIAB0AHIAYQBmAGYAaQBjACAAbABlAGEAdgBlAHMAIAB0AGgA ZQAgAGUAbgBjAGwAYQB2AGUALAAgAHcAaQB0AGgAbwB1AHQAIABnAHIAYQBuAHQAaQBuAGcA IAB0AGgAZQAgAFMARwAgAGEAYwBjAGUAcwBzACAAdABvACAAcABsAGEAaQBuAHQAZQB4AHQA IAB0AHIAYQBmAGYAaQBjAC4AIABUAGgAaQBzACwAIABhAG4AZAAgAHMAaQBtAGkAbABhAHIA IABjAG8AbgBjAGEAdABlAG4AYQB0AGUAZAAgAFMAQQAgAGUAeABhAG0AcABsAGUAcwAsACAA bQBvAHQAaQB2AGEAdABlACAAcgBlAHQAZQBuAHQAaQBvAG4AIABvAGYAIABBAEgALgAgAE8A bgBlACAAYwBvAHUAbABkACAAYQBjAGgAaQBlAHYAZQAgAGEAIABzAGkAbQBpAGwAYQByACAA ZQBmAGYAZQBjAHQAIAB3AGkAdABoACAAKABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4A LQBvAG4AbAB5ACkAIABFAFMAUAAgAHQAdQBuAG4AZQBsAHMALAAgAGIAdQB0ACAAdwBpAHQA aAAgAGkAbgBjAHIAZQBhAHMAZQBkACAAYgBhAG4AZAB3AGkAZAB0AGgAIABhAG4AZAAgAHAA cgBvAGMAZQBzAHMAaQBuAGcAIABvAHYAZQByAGgAZQBhAGQALgAgAEgAbwB3AGUAdgBlAHIA LAAgAEkAIABhAGcAcgBlAGUAIAB0AGgAYQB0ACAAdABoAGkAcwAgAHAAcgBvAHQAbwBjAG8A bAAgAGkAcwAgAHYAZQByAHkAIABjAG8AbQBwAGwAZQB4ACwAIAB0AGgAZQAgAHIAZQBzAHUA bAB0ACAAbwBmACAAaQBuAGMAcgBlAG0AZQBuAHQAYQBsACAAZQBuAGgAYQBuAGMAZQBtAGUA bgB0ACAAYQBuAGQAIABhACAAcgBlAGwAdQBjAHQAYQBuAGMAZQAgAG8AbgAgAHQAaABlACAA cABhAHIAdAAgAG8AZgAgAGQAZQB2AGUAbABvAHAAZQByAHMAIAB0AG8AIABkAGkAcwBjAGEA cgBkACAAbwBsAGQAZQByACAAdgBlAHIAcwBpAG8AbgBzACAAbwBmACAAYwBvAGQAZQAuAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACinwIAKKACACqgAgAsoAIAMqACAESg AgC0oAIAYqECALihAgC8oQIA/qECAJiiAgCaogIAoqICALaiAgDAogIABKMCADajAgBIowIA mqQCAC6oAgCAqAIAkqgCAMaoAgDIqAIANqkCADipAgD27fbk9tvS5NvkycDJwMnAt8CupZyl k5yuigAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAQiBBEgBAAVoLKpBpgdI AAARAQiBBEgBAAVo4FtBRgdIAAARAQiBBEgBAAVoK6pBpgdIAAARAQiBBEgBAAVoKqpBpgdI AAARAQiBBEgBAAVo9pJBRgdIAAARAQiBBEgBAAVoTpNBRgdIAAARAQiBBEgBAAVoTZNBRgdI AAARAQiBBEgBAAVoS5NBRgdIAAARAQiBBEgBAAVo+5JBRgdIAAARAQiBBEgBAAVo+ZJBRgdI AAARAQiBBEgBAAVoSpNBRgdIAAARAQiBBEgBAAVoAJNBRgdIAAARAQiBBEgBAAVo+pJBRgdI AAAAGhwAH7DQLyCw7j0hsCcFIrAnBSOQoAUkkKAFJbAAAGEAIAAgAGMAaABlAGMAawBiAHUA dAAgAGEAdAAgAGwAZQBhAHMAdAAgAG8AbgBlACAAawBuAG8AdwBsAGUAZABnAGUAYQBiAGwA ZQAgAFcARwAgAG0AZQBtAGIAZQByACAAdwBhAHMAIABxAHUAaQB0AGUAIABhAGQAZABpAHQA aQBvAG4AYQBsACwAIABtAGEAbgBkAGEAdABvAHIAeQAgAGQAZQBmAHUAdAAgAHQAaABpAHMA IABwAHIAbwB0AG8AYwBvAGwAIABpAHMAIAB2AGUAcgB5ACAAYwBvAG0AcABsAGUAeAAuACAA TQB1AGMAaAAgAG8AZgAgAHQAaABlACAAYwBvAG0AcABsAGUAeABpAHQAeQBzAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFU6AABZOgAA5UAAAPNAAAD8VwAADFgA ADFqAAA0agAA728AAPxvAAAgcAAALXAAAKp1AACvdQAAH3cAACR3AACnfAAAqnwAAJt+AACh fgAAWIAAAFuAAACDhwAAh4cAAHSIAAB4iAAADIoAABCKAACZigAAnYoAABiOAAAbjgAAgJQA AI2UAAChlAAApJQAADKVAAA1lQAA1ZcAANiXAADxlwAA/pcAADyYAAA/mAAAJJkAACeZAAD/ mQAADJoAAFGaAABUmgAAyJoAANSaAADVmgAA3JoAAFybAABfmwAAzJsAAM6bAAAinAAAKZwA AIOdAACGnQAAo50AAKadAADnnQAA6p0AAFygAABfoAAAraQAALCkAAAkqAAAJ6gAAJ2pAACp qQAAqqkAALipAAC6rAAAw6wAAF+6AABqugAA67wAAO68AAAdywAAJssAAKnLAACyywAACMwA ABHMAACJzAAAkswAAAbNAAAPzQAAXs0AAGfNAABfzgAAaM4AAHnTAAB90wAAbdUAAH/VAADl 2gAA8NoAAEfbAABa2wAA0NsAANvbAAA+3gAASd4AAADhAAAD4QAABuEAAAnhAAAL4QAAEOEA ABbhAAAX4QAAZOEAAHThAADk4gAA7+IAAHPjAACA4wAAheUAAInlAACT5QAAmeUAAIH6AAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA//8UAAAACgBTAHQAZQB2AGUAIABLAGUAbgB0 ABMASABhAHIAZAAgAEQAaQBzAGsAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAg AEsAZQBuAHQAFgBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AEkAUABTAGUAYwAuAHQAZQB4 AAoAUwB0AGUAdgBlACAASwBlAG4AdAAWAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQ AFMAZQBjAC4AdABlAHgACgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBz AGgAIABIAEQAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAFgBN AGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBl ACAASwBlAG4AdAAWAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4AdABl AHgACgBTAHQAZQB2AGUAIABLAGUAbgB0ADkASABhAHIAZAAgAEQAaQBzAGsAOgBUAGUAbQBw AG8AcgBhAHIAeQAgAEkAdABlAG0AcwA6AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBh AHYAZQAgAG8AZgAgAEkAUABzAGUAYwAgAHIAZQB2AGkACgBTAHQAZQB2AGUAIABLAGUAbgB0 ACUASABhAHIAZAAgAEQAaQBzAGsAOgBJAFAAUwBFAEMAOgBJAFAAcwBlAGMAIAByAGUAdgBp AGUAdwAgAGMAbwBtAG0AZQBuAHQAcwAKAFMAdABlAHYAZQAgAEsAZQBuAHQAJQBIAGEAcgBk ACAARABpAHMAawA6AEkAUABTAEUAQwA6AEkAUABzAGUAYwAgAHIAZQB2AGkAZQB3ACAAYwBv AG0AbQBlAG4AdABzAAoAUwB0AGUAdgBlACAASwBlAG4AdAAlAEgAYQByAGQAIABEAGkAcwBr ADoASQBQAFMARQBDADoASQBQAHMAZQBjACAAcgBlAHYAaQBlAHcAIABjAG8AbQBtAGUAbgB0 AHMA/0ADgAEArAEAAKwBAAAo0GoGcABwAKwBAAAAAAAArAEAAAAAAAABAAEAxQKkAgERAAAI AWNIAQBkaDGqQaZnSAAAAYMARcaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhgBDJAFFxoAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAI8CgAAAAAAAC4AAABHAAAAWwAAAG8AAABwAAAAfwAAAIAAAACn AAAA0gAAAAQBAAAlAQAAZAEAAJsBAACcAQAArQEAALgBAABkSgAAZUoAAGZKAABrSgAAjUoA AJZKAACiSgAA00oAANZKAAB3TAAAfUwAAH9MAACATAAAgUwAAM5MAADTTAAA1EwAANtMAADx TAAA/0wAAB9NAAAgTQAAI00AACxNAABkTQAAhk0AALtNAADVTQAA300AAOZNAADoTQAACU4A ABNOAAAcTgAAVk4AAFdOAABbTgAAZU4AAGpOAACMTgAApU4AAK1OAACuTgAAO1AAANJqAADU agAA6WoAAO9qAABorwAAaa8AAGSyAABmsgAAz7QAAOC0AADotAAA6bQAAO60AAD4tAAAAbUA ABS1AABsvQAAdL0AAHW9AACSvQAA7b0AAPG9AAANvgAADr4AABC+AAAXvgAAGL4AALS+AADQ vgAA4b4AAOe+AADCwgAAxsIAABzDAAAlwwAAM8UAADTFAAA1xQAAN8UAAFPFAABtxQAAsMUA ALHFAAC0xQAAyMUAAOvFAAD2xQAA+8UAAPzFAAAwxgAAMcYAADTGAABdxgAAesYAAO3LAADx ywAA8ssAAPzLAAD9ywAABMwAAAfMAABHzAAATcwAAE7MAABbzAAAXMwAAF3MAABezAAAe8wA AN/MAAAmzQAAL80AADjNAAA6zQAAO80AAD3NAAB+zQAAtc0AALbNAAC9zQAA680AAOzNAABv zgAAddMAAHbTAAB50wAAftMAAJPTAADt0wAA/NYAAP/WAAAZ1wAAGtcAABvXAAAe1wAAGNkA ABvZAABi2QAAf9kAAIPZAACI2QAAkdkAACLaAAAj2gAAJNoAACXaAAAo2gAALNoAAHbaAADF 3wAAzd8AAH3jAAB45AAAbegAAG7oAABv6AAAmOgAAMfoAADj6AAAE+kAAD/pAABA6QAAaukA AHvpAACk6QAApekAAKfpAADh6QAA6OsAAO3rAAAA7AAAFOwAANLsAAD37AAAGu0AAEHvAABC 7wAAQ+8AAEvvAABd7wAAXu8AAJP5AACU+QAApfkAAKf5AADA+QAAwfkAANX5AADp+QAACfoA AAz6AAAT+gAAFPoAABz6AAA1+gAAffoAAH76AAB/+gAAMAAACABAAQAwAFwIAEABADAAjggA QAEAMAC2CABAAQAwAN4IAEABADAA4AgAQAEAMAD+CABAAQAwAAAJAEABADAATgkAQAEAMACk CQBAAQAwAAgKAEABADAASgoAQAEAMADICgBAAQAwADYLAEABADAAOAsAQAEAMABaCwBAAQAw AHALAEAAADEAAJ4CAAAAMQACngIAAAAxAASeAgAAADEADp4CAAAAMQBSngIAAAAxAGSeAgAA ADEAfJ4CAAAAMADInABAAAAxAM6cAEADADEA3p4CAAAAMQAQoABAAwAxAOqeAgAAADEA7J4C AAAAMQDungIAAAAxAIifAgAAADEAkp8CAAAAMQCUnwIAAAAxAKKfAgAAADEAzp8CAAAAMQDq nwIAAAAxACqgAgAAADEALKACAAAAMQAyoAIAAAAxAESgAgAAADEAtKACAAAAMQD4oAIAAAAx AGKhAgAAADEAlqECAAAAMQCqoQIAAAAxALihAgAAADEAvKECAAAAMQD+oQIAAAAxABKiAgAA ADEAJKICAAAAMQCYogIAAAAxAJqiAgAAADEAoqICAAAAMQC2ogIAAAAxAMCiAgAAADEABKMC AAAAMQA2owIAAAAxAEajAgAAADAAWqIAQAUAMAB0pQBAAAAxAB6oAgAAADEAotoAQAAAMQAi qAIAAAAwAMzaAEAAADEAHoICAAAAMAC+YwFAAAAxACCCAgAAADAAuGkBQAAAMQAuqAIAAAAx AFCoAgAAADEAYKgCAAAAMQBiqAIAAAAxAGyoAgAAADEAgKgCAAAAMQC+bgFAAAAwAORuAUAA ADEAAI4CAAAAMQAQjgIAAAAxABKOAgAAADEATI4CAAAAMQACjwIAAAAxAAqPAgAAADEAQo8C AAAAMQBEjwIAAAAxAEiPAgAAADEAVo8CAAAAMQBYjwIAAAAxAJCQAgAAADEAyJACAAAAMQDq kAIAAAAwAJp/AUAAADEAJIICAAAAMQBQhwFAAAAxAACEAgAAADEA/IcBQAAAMQAShAIAAAAx ABSEAgAAADEAFoQCAAAAMQAahAIAAAAxAFKEAgAAADEAhoQCAAAAMQAMhQIAAAAxAA6FAgAA ADEAFIUCAAAAMQA8hQIAAAAxAIKFAgAAADEAmIUCAAAAMQCihQIAAAAxAKSFAgAAADEADIYC AAAAMQAOhgIAAAAxABSGAgAAADEAZoYCAAAAMAAYjAFAAAAxAPaQAgAAADEA/pACAAAAMQAA kQIAAAAxABSRAgAAADEAFpECAAAAMQAkkQIAAAAxACqRAgAAADEAqpECAAAAMQC2kQIAAAAx ALiRAgAAADEA0pECAAAAMQDUkQIAAAAxANaRAgAAADEA2JECAAAAMQD+lgFAAAAxABKSAgAA ADEAoJICAAAAMQCykgIAAAAxAMSSAgAAADEAyJICAAAAMQDKkgIAAAAxAM6SAgAAADEAUJMC AAAAMQC+kwIAAAAxAMCTAgAAADEAzpMCAAAAMQAqlAIAAAAxAMaXAUAAADAA2JgBQAAAMQCg hgIAAAAxAKKGAgAAADEAqIYCAAAAMQAAigIAAAAxALKGAgAAADAA5KIBQAAAMQBmhwIAAAAx AJKoAgAAADEAoocCAAAAMQDGqAIAAAAxAKSHAgAAADAAAqkBQAAAMQCqhwIAAAAxAPysAUAA ADEAKooCAAAAMQBkigIAAAAxAGyKAgAAADEAdooCAAAAMQCKrQFAAAAxALCHAgAAADEAsocC AAAAMQC0hwIAAAAxALaHAgAAADEAvIcCAAAAMQDEhwIAAAAwAKyuAUAAADEAiIoCAAAAMABK uQFAAAAxAKrAAUAAADAAoMIBQAAAMQAAlgIAAAAxAAKWAgAAADEABJYCAAAAMQBWlgIAAAAx ALSWAgAAADEA7JYCAAAAMQBMlwIAAAAxAKSXAgAAADEAppcCAAAAMQD6lwIAAAAxAACaAgAA ADEAUpoCAAAAMQBUmgIAAAAxAFiaAgAAADAAksoBQAAAMQCYigIAAAAxAKDOAUAAADEAoooC AAAAMQDGzgFAAAAxAMqKAgAAADEAFIsCAAAAMABC0AFAAAAxAFqLAgAAADEAktQBQAAAMQBc iwIAAAAxAJrUAUAAADEAbIsCAAAAMAC+1AFAAAAwAG6LAgAAADEAcIsCAAAAMQAAnAIAAAAx AJKLAgAAADEASKMCAAAAMQBKowIAAAAxAMioAgAAADEA8KgCAAAAMQAwqQIAAAAxALqjAgAA ADEANqkCAAAAMQDIowIAAAAxANijAgAAADEACqQCAAAAMADQVwNAAAAwANJXA0AAAAUAAABH BpABAAACAgYDBQQFAgMEAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAAA1BpABAgACAAUAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAIAA AAAAUwB5AG0AYgBvAGwAAAAzBpABAAACCwYEAgICAgIEAAAAAwAAAAAAAAAAAAAAAAEAAAAA AAAAQQByAGkAYQBsAAAAMwaQAQAAAgAFAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAABAAAAAAAA AFQAaQBtAGUAcwAAAD8GkAEAAAIHAwkCAgUCBAQAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABD AG8AdQByAGkAZQByACAATgBlAHcAAAAiAAQAcYiIGAAA0AIAAGgBAAAAAKuKPKYxqkGmAAAA ADIAiQEAAK8jAABrywAAEgBoAAAABACDELEBAAAAAAAAAAAAABIAAQAAAAEAAAAAAAAA7AMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA AB4wAAARABkAZAAAABkAAADP+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAABdAv//EgAAAAAAAAAtAFwAZABv AGMAdQBtAGUAbgB0AGMAbABhAHMAcwBbAGMAaABhAHAAdABlAHIAcABhAGcAZQAsADEAMgBw AHQAXQB7AGMAbwB1AG4AdABlAHIAcABhAG4AZQB9AAAAAAAAAAoAUwB0AGUAdgBlACAASwBl AG4AdAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAIAAAAAAAABAEMAbwBtAHAATwBiAGoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAAA AAAAADAAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAEAADemAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADGAAA9xgAAWsYA AM3LAADRywAA0ssAANzLAADdywAA5MsAAOfLAAAnzAAALcwAAC7MAAA7zAAAPMwAAD3MAAA+ zAAAW8wAAL/MAAAGzQAAD80AABjNAAAazQAAG80AAB3NAABezQAAlc0AAJbNAACdzQAAy80A AMzNAABPzgAAVdMAAFbTAABZ0wAAXtMAAHPTAADN0wAA3NYAAN/WAAD+1gAA+NgAAPvYAABC 2QAAX9kAAGPZAABo2QAAcdkAAALaAAAD2gAABNoAAAXaAAAI2gAADNoAAFbaAACl3wAArd8A AFjkAABN6AAATugAAE/oAAB46AAAp+gAAMPoAADz6AAAH+kAACDpAABK6QAAW+kAAITpAACF 6QAAh+kAAMHpAADI6wAAzesAAODrAAD06wAAsuwAANfsAAD67AAAIe8AACLvAAAj7wAAK+8A AD3vAAA+7wAAc/kAAHT5AACF+QAAh/kAAKD5AACh+QAA6PkAAAH6AABJ+gAASvoAAEv6AAAw AAAIAEAAADEAAJ4CAAAAMQACngIAAAAxAASeAgAAADEADp4CAAAAMQBSngIAAAAxAGSeAgAA ADEAfJ4CAAAAMADInABAAAAxAM6cAEABADEA3p4CAAAAMQAQoABAAQAxAOqeAgAAADEA7J4C AAAAMQDungIAAAAxAIifAgAAADEAkp8CAAAAMQCUnwIAAAAxAKKfAgAAADEAzp8CAAAAMQDq nwIAAAAxACqgAgAAADEALKACAAAAMQAyoAIAAAAxAESgAgAAADEAtKACAAAAMQD4oAIAAAAx AGKhAgAAADEAlqECAAAAMQCqoQIAAAAxALihAgAAADEAvKECAAAAMQD+oQIAAAAxABKiAgAA ADEAJKICAAAAMQCYogIAAAAxAJqiAgAAADEAoqICAAAAMQC2ogIAAAAxAMCiAgAAADEABKMC AAAAMQA2owIAAAAxAEajAgAAADAAWqIAQAMAMAB0pQBAAAAxAB6CAgAAADAAvmMBQAAAMQAg ggIAAAAwALhpAUAAADEAAI4CAAAAMQAQjgIAAAAxABKOAgAAADEATI4CAAAAMQACjwIAAAAx AAqPAgAAADEAQo8CAAAAMQBEjwIAAAAxAEiPAgAAADEAVo8CAAAAMQBYjwIAAAAxAJCQAgAA ADEAyJACAAAAMQDqkAIAAAAwAJp/AUAAADEAJIICAAAAMQBQhwFAAAAxAACEAgAAADEA/IcB QAAAMQAShAIAAAAxABSEAgAAADEAFoQCAAAAMQAahAIAAAAxAFKEAgAAADEAhoQCAAAAMQAM hQIAAAAxAA6FAgAAADEAFIUCAAAAMQA8hQIAAAAxAIKFAgAAADEAmIUCAAAAMQCihQIAAAAx AKSFAgAAADEADIYCAAAAMQAOhgIAAAAxABSGAgAAADEAZoYCAAAAMAAYjAFAAAAxAPaQAgAA ADEA/pACAAAAMQAAkQIAAAAxABSRAgAAADEAFpECAAAAMQAkkQIAAAAxACqRAgAAADEAqpEC AAAAMQC2kQIAAAAxALiRAgAAADEA0pECAAAAMQDUkQIAAAAxANaRAgAAADEA2JECAAAAMQD+ lgFAAAAxABKSAgAAADEAoJICAAAAMQCykgIAAAAxAMSSAgAAADEAyJICAAAAMQDKkgIAAAAx AM6SAgAAADEAUJMCAAAAMQC+kwIAAAAxAMCTAgAAADEAzpMCAAAAMQAqlAIAAAAxAMaXAUAA ADAA2JgBQAAAMQCghgIAAAAxAKKGAgAAADEAqIYCAAAAMQAAigIAAAAxALKGAgAAADAA5KIB QAAAMQBmhwIAAAAxAGyHAgAAADAAAqkBQAAAMQCqhwIAAAAxAPysAUAAADEAKooCAAAAMQBk igIAAAAxAGyKAgAAADEAdooCAAAAMQCKrQFAAAAxALCHAgAAADEAsocCAAAAMQC0hwIAAAAx ALaHAgAAADEAvIcCAAAAMQDEhwIAAAAwAKyuAUAAADEAiIoCAAAAMABKuQFAAAAwAKDCAUAA ADEAAJYCAAAAMQAClgIAAAAxAASWAgAAADEAVpYCAAAAMQC0lgIAAAAxAOyWAgAAADEATJcC AAAAMQCklwIAAAAxAKaXAgAAADEA+pcCAAAAMQAAmgIAAAAxAFKaAgAAADEAVJoCAAAAMQBY mgIAAAAwAJLKAUAAADEAmIoCAAAAMQCgzgFAAAAxAKKKAgAAADEAxs4BQAAAMQDKigIAAAAx ABSLAgAAADAAQtABQAAAMQBaiwIAAAAxAJLUAUAAADEAXIsCAAAAMQCa1AFAAAAxAGyLAgAA ADAAvtQBQAAAMABuiwIAAAAxAHCLAgAAADEAAJwCAAAAMQCSiwIAAAAxAEijAgAAADEASqMC AAAAMQDYowIAAAAxAAqkAgAAADAA0FcDQAAAMADSVwNAAAAFAAAARwaQAQAAAgIGAwUEBQID BAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu AAAANQaQAQIAAgAFAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBs AAAAMwaQAQAAAgsGBAICAgICBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAA ADMGkAEAAAIABQAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAAAA/ BpABAAACBwMJAgIFAgQEAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAAQwBvAHUAcgBpAGUAcgAg AE4AZQB3AAAAIgAEAHGIiBgAANACAABoAQAAAACrijymT5NBRgAAAAAwAIUBAACvIwAAa8sA ABIAaAAAAAQAgxCxAQAAAAAAAAAAAAASAAEAAAABAAAAAAAAAOwDAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAAeMAAAEQAZAGQAAAAZ AAAAz/kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRKAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAXQL//xIAAAAAAAAALQBcAGQAbwBjAHUAbQBlAG4AdABj AGwAYQBzAHMAWwBjAGgAYQBwAHQAZQByAHAAYQBnAGUALAAxADIAcAB0AF0AewBjAG8AdQBu AHQAZQByAHAAYQBuAGUAfQAAAAAAAAAKAFMAdABlAHYAZQAgAEsAZQBuAHQACgBTAHQAZQB2 AGUAIABLAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAVAAoAAQBbAA8AAgADAAAAAwAo AABA8f8CACgAAAAGAE4AbwByAG0AYQBsAAAAAgAAAAgAQ0oYAG1ICQQAAAAAAAAAAAAAAAAA AAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAg AEYAbwBuAHQAAAAAAAAAAAAAAAAANABaQAEA8gA0AAAACgBQAGwAYQBpAG4AIABUAGUAeAB0 AAAAAgAPAAwAQ0oUAE9KBABRSgQAJAAvAAEAAgEkAAAABABMAGkAcwB0AAAACgAQAA+EaAER hJj+AAAqAEIAAQASASoAAAAJAEIAbwBkAHkAIABUAGUAeAB0AAABAP7/AgABAP////8GCQIA AAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AP7///9OQjZXEAAAAFdv cmQuRG9jdW1lbnQuOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXV zdWcLhsQk5cIACss+a5oAQAAJAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIwAAAAGAAAA lAAAABEAAACcAAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAAEwAAALwAAAAWAAAAxAAAAA0A AADMAAAADAAAAAYBAAACAAAAECcAAB4AAAARAAAAQkJOIFRlY2hub2xvZ2llcwBzAHMDAAAA sQEAAAMAAABoAAAAAwAAAM/5AAADAAAAYhYIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAAHhAAAAEAAAAuAAAAXGRvY3VtZW50Y2xhc3NbY2hhcHRlcnBhZ2UsMTJwdF17Y291 bnRlcnBhbmV9AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAJgAAAADAAAAAAAAACAA AAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAAAQJwAAQQAAAE4A AAB7AEIAMgAwADQAQwAxADAAMAAtAEIANAA2AEMALQAxADEARAAzAC0AQgBGAEQARgAtADAA MAAwADUAMAAyADgANQAyAEYAMgA5AH0AAAAAAAAA/v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAA AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAhAEAABAAAAABAAAAiAAAAAIAAACQAAAAAwAAAMgA AAAEAAAA1AAAAAUAAADoAAAABwAAAPQAAAAIAAAABAEAAAkAAAAYAQAAEgAAACQBAAAKAAAA QAEAAAwAAABMAQAADQAAAFgBAAAOAAAAZAEAAA8AAABsAQAAEAAAAHQBAAATAAAAfAEAAAIA AAAQJwAAHgAAAC4AAABcZG9jdW1lbnRjbGFzc1tjaGFwdGVycGFnZSwxMnB0XXtjb3VudGVy cGFuZX0ALjAeAAAAAQAAAABkb2MeAAAACwAAAFN0ZXZlIEtlbnQAYR4AAAABAAAAAHRldh4A AAAHAAAATm9ybWFsAGUeAAAACwAAAFN0ZXZlIEtlbnQAYR4AAAADAAAANTAAdh4AAAATAAAA TWljcm9zb2Z0IFdvcmQgOC4wAHRAAAAAAHbG5jYAAABAAAAAANqJZaVIvwFAAAAAAO4JRRZk vwEDAAAAEgAAAAMAAACvIwAAAwAAAGvLAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADspcEAcwAJBAAAtBC/AAAAAAABEQABAAEABAAA6qsBAA4AamJqYsAJwAkAAAAA AAAAAAAAAAAAAAAAAAAJBBYAAKoCAKprAQCqawEAf/oAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0A AAAAAAAAAADtagAAugEAAKdsAAAAAAAAp2wAAAAAAACnbAAAAAAAAKdsAAAAAAAAp2wAABQA AAAAAAAAAAAAACtuAABkDQAAvYMAAAAAAAC9gwAAAAAAAL2DAAAAAAAAvYMAAHwAAAA5hAAA xAAAAI97AAAAAAAAbaIAACoBAADJjgAABAAAAM2OAAAAAAAAzY4AAAAAAADNjgAAAAAAAM2O AAAAAAAAzY4AAAAAAADNjgAAAAAAAM2OAAAAAAAA25YAAAIAAADdlgAAAAAAAN2WAAAAAAAA 3ZYAAAAAAADdlgAAAAAAAN2WAAAAAAAA3ZYAACwAAACXowAA9AEAAIulAACsAAAACZcAAGQL AAAAAAAAAAAAAAAAAAAAAAAAp2wAAAAAAADNjgAAAAAAAAAAAAAAAAAAAAAAAAAAAADNjgAA AAAAAM2OAAAAAAAAzY4AAAAAAADNjgAAAAAAAAmXAAAAAAAAk5MAAAAAAACnbAAAAAAAAKds AAAAAAAAzY4AAAAAAAAAAAAAAAAAAM2OAAAAAAAAUYUAAHgJAACTkwAAAAAAAJOTAAAAAAAA k5MAAAAAAADNjgAAxgQAAKdsAAAAAAAAzY4AAAAAAACnbAAAAAAAAM2OAAAAAAAA25YAAAAA AAAAAAAAAAAAAAAAAAAAAAAAu2wAALgAAABzbQAAuAAAAKdsAAAAAAAAp2wAAAAAAACnbAAA AAAAAKdsAAAAAAAAzY4AAAAAAADblgAAAAAAAJOTAABIAwAAk5MAAAAAAAAAAAAAAAAAANuW AAAAAAAAp2wAAAAAAACnbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA25YAAAAAAAAAAAAAAAAAAP2EAABUAAAAdhSutAAA AACPewAALggAAL2DAAAAAAAAk5MAAAAAAADblgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAXGRvY3VtZW50Y2xhc3NbY2hhcHRlcnBhZ2UsMTJwdF17Y291bnRlcnBhbmV9DVx1 c2VwYWNrYWdlW1QxXXtmb250ZW5jfQ1cdXNlcGFja2FnZXt4c3BhY2V9DVx1c2VwYWNrYWdl e2Vwc2ZpZ30NDSVccmFnZ2VkYm90dG9tDQ1cdGl0bGV7QSBTZWN1cml0eSBFdmFsdWF0aW9u IG9mIElQc2VjfQ1cYXV0aG9ye05pZWxzIEZlcmd1c29uIGFuZCBCcnVjZSBTY2huZWllcn0N XGNvbnRhY3RlbWFpbHtce25pZWxzLHNjaG5laWVyXH1AY291bnRlcnBhbmUuY29tfQ1ccHVy cG9zZXtUZWNobmljYWwgcmVwb3J0IDk5LTEzfQ1cZG9jdW1lbnRkYXRlezE5OTkvMDIvMjd9 ICUgQmV0aCwgdGhpcyBkYXRlIGZvcm1hdCBpcyBjb3JyZWN0Lg0JCQkgICUgVGhlIHN0eWxl IHNoZWV0IGNvbnZlcnRzIGl0IHRvIHNvbWV0aGluZyBuaWNlci4NDVxiZWdpbntkb2N1bWVu dH0NXG1ha2V0aXRsZQ0NXGNoYXB0ZXIqe0V4ZWN1dGl2ZSBzdW1tYXJ5fQ1JUHNlYyBpcyBh IHNldCBvZiBwcm90b2NvbHMgdGhhdCBwcm92aWRlcyBjb21tdW5pY2F0aW9uIHNlY3VyaXR5 IGZvciBjb21wdXRlcnMgdXNpbmcgSVAtYmFzZWQgY29tbXVuaWNhdGlvbiBuZXR3b3Jrcy4g SXQgcHJvdmlkZXMgYXV0aGVudGljYXRpb24gYW5kIGNvbmZpZGVudGlhbGl0eSBzZXJ2aWNl cyBvbiBhIHBhY2tldCBsZXZlbC4gVG8gc3VwcG9ydCB0aGUgSVBzZWMgc2VjdXJpdHksIGEg a2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgY2FsbGVkIElTQUtNUCBpcyB1c2VkLiBJU0FLTVAg dXNlcyBwdWJsaWMta2V5IGNyeXB0b2dyYXBoaWMgdGVjaG5pcXVlcyB0byBzZXQgdXAga2V5 cyBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgcGFydGllcyB0byBiZSB1c2VkIHdpdGggSVBzZWMu DQ1Cb3RoIElQc2VjIGFuZCBJU0FLTVAgYXJlIHRvbyBjb21wbGV4LiBbYSBwcm90b2NvbCBp cyB0b28gY29tcGxleCBvbmx5IHJlbGF0aXZlIHRvIGEgc3BlY2lmaWVkIHNldCBvZiByZXF1 aXJlbWVudHMgdGhhdCBhcmUgc2F0aXNmaWVkIGJ5IGEgc2ltcGxlciBwcm90b2NvbC4gVG8g c3Vic3RhbnRpYXRlIHRoaXMgb2JzZXJ2YXRpb24sIG9uZSBvdWdodCB0byBkZWZpbmUgdGhl IHJlcXVpcmVtZW50cyB0aGF0IG9uZSBiZWxpZXZlcyB0aGUgcHJvdG9jb2wgaXMgdHJ5aW5n IHRvcCBzYXRpc2Z5LCBhbmQgdGhlbiAgb2ZmZXIgYSBzaW1wbGVyIHByb3RvY29sLl0gVGhp cyBoaWdoIGNvbXBsZXhpdHkgbGVhZHMgdG8gZXJyb3JzLiBXZSBoYXZlIGZvdW5kIHNlY3Vy aXR5IGZsYXdzIGluIGJvdGggSVBzZWMgYW5kIElTQUtNUCwgYW5kIGV4cGVjdCB0aGF0IHRo ZXJlIGFyZSBtYW55IG1vcmUuIFdlIGV4cGVjdCBhbnkgYWN0dWFsIGltcGxlbWVudGF0aW9u IHRvIGNvbnRhaW4gbWFueSBtb3JlIGVycm9ycywgc29tZSBvZiB3aGljaCB3aWxsIGNhdXNl IHNlY3VyaXR5IHdlYWtuZXNzZXMuIFRoZXNlIHByb3RvY29scyBnaXZlIHRoZSBpbXByZXNz aW9uIG9mIGhhdmluZyBiZWVuIGRlc2lnbmVkIGJ5IGEgY29tbWl0dGVlOiB0aGV5IHRyeSB0 byBiZSBldmVyeXRoaW5nIGZvciBldmVyeWJvZHkgYXQgdGhlIGNvc3Qgb2YgY29tcGxleGl0 eS4gRm9yIG5vcm1hbCBzdGFuZGFyZHMsIHRoYXQgaXMgYmFkIGVub3VnaDsgZm9yIHNlY3Vy aXR5IHN5c3RlbXMsIGl0IGlzIGNhdGFzdHJvcGhpYy4gSW4gb3VyIG9waW5pb24sIHRoZSBj b21wbGV4aXR5IG9mIGJvdGggSVBzZWMgYW5kIElTQUtNUCBjYW4gYmUgcmVkdWNlZCBieSBh IGxhcmdlIGZhY3RvciB3aXRob3V0IGEgc2lnbmlmaWNhbnQgbG9zcyBvZiBmdW5jdGlvbmFs aXR5Lg0NSVBzZWMgaXMgaW4gYmV0dGVyIHNoYXBlIHRoYW4gSVNBS01QLiBUaGUgZGVzY3Jp cHRpb24gYW5kIGRlZmluaXRpb25zIGFyZSByZWFzb25hYmx5IGNsZWFyLiBBIGNhcmVmdWwg aW1wbGVtZW50YXRpb24gb2YgSVBzZWMgY2FuIGFjaGlldmUgYSBnb29kIGxldmVsIG9mIHNl Y3VyaXR5LiBVbmZvcnR1bmF0ZWx5LCBJUHNlYyBieSBpdHNlbGYgaXMgbm90IGEgdmVyeSB1 c2VmdWwgcHJvdG9jb2wuIFVzZSBvbiBhIGxhcmdlIHNjYWxlIHJlcXVpcmVzIHRoZSBrZXkg bWFuYWdlbWVudCBmdW5jdGlvbnMgb2YgSVNBS01QLiBbd2hpbGUgSSB3b3VsZCB0ZW5kIHRv IGFncmVlIHdpdGggdGhpcyBvYnNlcnZhdGlvbiwgSSBzaG91bGQgbm90ZSB0aGF0IGEgbm9u LXRyaXZpYWwgbnVtYmVyIG9mIElQc2VjIGltcGxlbWVudGF0aW9ucywgdXNlZCBpbiBjb25z dHJhaW5lZCBjb250ZXh0cywgYXJlIG1hbnVhbGx5IGtleWVkLl0NDUlTQUtNUCBpcyBjdXJy ZW50bHkgbm90IGluIGEgc3VpdGFibGUgc3RhdGUgZm9yIGltcGxlbWVudGF0aW9uLiBNYWpv ciB3b3JrIHdpbGwgYmUgcmVxdWlyZWQgdG8gZ2V0IGl0IHRvIHRoYXQgcG9pbnQuIFRoZXJl IGFyZSBtYW55IHNlY3VyaXR5LWNyaXRpY2FsIGVycm9ycywgYXMgd2VsbCBhcyBtYW55IHVu bmVjZXNzYXJ5IGNyb3NzLWRlcGVuZGVuY2llcyB3aXRoaW4gdGhlIHByb3RvY29sLiBUaGVz ZSBzaG91bGQgYWxsIGJlIGVsaW1pbmF0ZWQgYmVmb3JlIGEgbmV3IGV2YWx1YXRpb24gaXMg ZG9uZS4NDUJhc2VkIG9uIG91ciBhbmFseXNpcywgd2UgcmVjb21tZW5kIHRoYXQgSVBzZWMg YW5kIElTQUtNUCBub3QgYmUgdXNlZCBmb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBB dCB0aGUgbW9tZW50IHdlIGNhbm5vdCByZWNvbW1lbmQgYSBkaXJlY3QgYWx0ZXJuYXRpdmUu IFNvbWUgYXBwbGljYXRpb25zIG1pZ2h0IGJlIGFibGUgdG8gdXNlIFNTTCBcY2l0ZXtTU0x2 M05vdjk2fSwgd2hpY2ggaW4gb3VyIG9waW5pb24gaXMgYSBtdWNoIGJldHRlciBwcm90b2Nv bCB0aGF0IHByb3ZpZGVzIGEgbXVjaCBoaWdoZXIgbGV2ZWwgb2Ygc2VjdXJpdHkgd2hlbiB1 c2VkIGFwcHJvcHJpYXRlbHkuDQ1cdGFibGVvZmNvbnRlbnRzDQ1cY2hhcHRlcntJbnRyb2R1 Y3Rpb259DQ1BdCB0aGUgcmVxdWVzdCBvZiBOU0EsIENvdW50ZXJwYW5lIGhhcyBjb25kdWN0 ZWQgYSBzZWN1cml0eSByZXZpZXcgb2YgdGhlIElQc2VjIGFuZCBJU0FLTVAgc2VjdXJpdHkg cHJvdG9jb2xzLg0NVGhpcyBldmFsdWF0aW9uIGlzIGJhc2VkIG9uIFJGQ3MgMjQwMS0tMjQx IABQAGEAdQBtAGkAZQByAA4ATQBlAHIAeQBsACAARgByAGEAbgB6AG0AYQBuAAMAUwBDAEMA BQBjAGMAYQBpAG4AEgBMAGEAdQByAGkAYQB1AGwAdAAsACAAUwBpAG0AbwBuAG4AZQAMAFMA YwBvAHQAdAAgAEEAdAB3AGUAbABsAAUAcABjAGEAaQBuAA8ARABhAHYAaQBkACAARQBzAGMA YQBsAGEAbgB0AGUACQBFAHMAYwBhAGwAYQBuAHQAZQATAEIAZQBuAGoAYQBtAGkAbgAgAEoA LgAgAFcAbwB6AG4AaQBjAGsAFwBCAEIATgAgAEMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4A cwAgAEkAbgBjAC4AFABHAFQARQAgAEkAbgB0AGUAcgBuAGUAdAB3AG8AcgBrAGkAbgBnAC4A CwBCAGkAbABsACAATgBlAGwAcwBvAG4ACQBNAGkAawBlACAASwBvAG4AZwANAEEAbgBkAHIA ZQB3ACAAUwBoAG8AcgBlAHMACgBBAHMAYwBlAG4AZAAgAGUAbQBtABoAQQBzAGMAZQBuAGQA IABDAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBuAHMAIABVAHMAZQByAA4ASgBvAGUAIABXAGgA aQB0AGUAaABvAHUAcwBlAAcAQwBhAHMAYwBhAGQAZQAMAEEAYQByAG8AbgAgAEIAYQB3AGMA bwBtAAgAYQBtAGEAZwB1AGkAcgBlABAARgByAGEAbgBrACAATQBhAG4AaQBzAGMAYQBsAGMA bwACAC4ALgAQAEMAYQB0AGgAZQByAGkAbgBlACAASwBuAGkAawBlAHIADwBDAGgAcgBpAHMA dABpAG4AZQAgAFMAaQBsAHYAYQANAEIAcgBhAGQAIABEACAATQBlAGUAaABhAG4ADABKAGkA bQAgAE8AJwBDAG8AbgBuAG8AcgAUAFQAZQBjAGgAbgBpAGMAYQBsACAAQwBvAHIAcgBpAGcA ZQBuAGQAYQAUAEgAbwB5AHQAIABMAC4AIABLAGUAcwB0AGUAcgBzAG8AbgAgAEkASQAHAFMA QgBvAGUAeQBlAG4ADABSAG8AZAAgAEwAZQBuAG4AaQBnAGUAcgANAEoAQQBOAEUAVAAgAEwA RQBCAEwATwBOAEQAAwBiAGIAbgADAEQANABNAMf4AAAAAAAAhQkAAJQJAADECgAAygoAAF4L AABgCwAAYQsAAHYLAAB6CwAAhQsAAIYLAACJCwAAQxAAAE8QAABQEAAAXBAAAHsQAACHEAAA iBAAAJEQAADIEAAA1BAAANUQAADgEAAADBEAABgRAAAZEQAAJhEAAL0RAADJEQAAyhEAANIR AABPEgAAWxIAAGEWAABtFgAABBcAABMXAABmGwAAchsAAIsfAACcHwAAayoAAHoqAACGKgAA jyoAADI0AAA7NAAAnTgAAKE4AAAtPwAAOz8AAERWAABUVgAAeWgAAHxoAAA3bgAARG4AAGhu AAB1bgAA8nMAAPdzAABndQAAbHUAAO96AADyegAA43wAAOl8AACgfgAAo34AAMuFAADPhQAA vIYAAMCGAABUiAAAWIgAAOGIAADliAAAYIwAAGOMAADIkgAA1ZIAAOmSAADskgAAepMAAH2T AAAdlgAAIJYAADmWAABGlgAAhJYAAIeWAABslwAAb5cAAEeYAABUmAAAmZgAAJyYAAAQmQAA HJkAAB2ZAAAkmQAApJkAAKeZAAAUmgAAFpoAAGqaAABxmgAAy5sAAM6bAADrmwAA7psAAC+c AAAynAAApJ4AAKeeAAD1ogAA+KIAAGymAABvpgAA5acAAPGnAADypwAAAKgAAAKrAAALqwAA p7gAALK4AAAzuwAANrsAAGXJAABuyQAA8ckAAPrJAABQygAAWcoAANHKAADaygAATssAAFfL AACmywAAr8sAAKfMAACwzAAAwdEAAMXRAAC10wAAx9MAAC3ZAAA42QAAj9kAAKLZAAAY2gAA I9oAAIbcAACR3AAASN8AAEvfAABO3wAAUd8AAFPfAABY3wAAXt8AAF/fAACs3wAAvN8AACzh AAA34QAAu+EAAMjhAADN4wAA0eMAANvjAADh4wAAyfgAAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcA//8UAAAACgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgA IABIAEQAOgBJAFAAUwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAFgBNAGEA YwBpAG4AdABvAHMAaAAgAEgARAA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAA SwBlAG4AdAAWAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoASQBQAFMAZQBjAC4AdABlAHgA CgBTAHQAZQB2AGUAIABLAGUAbgB0ABYATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBJAFAA UwBlAGMALgB0AGUAeAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAFgBNAGEAYwBpAG4AdABvAHMA aAAgAEgARAA6AEkAUABTAGUAYwAuAHQAZQB4AAoAUwB0AGUAdgBlACAASwBlAG4AdAA5AEgA YQByAGQAIABEAGkAcwBrADoAVABlAG0AcABvAHIAYQByAHkAIABJAHQAZQBtAHMAOgBBAHUA dABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABJAFAAcwBlAGMAIAByAGUA dgBpAAoAUwB0AGUAdgBlACAASwBlAG4AdAAlAEgAYQByAGQAIABEAGkAcwBrADoASQBQAFMA RQBDADoASQBQAHMAZQBjACAAcgBlAHYAaQBlAHcAIABjAG8AbQBtAGUAbgB0AHMACgBTAHQA ZQB2AGUAIABLAGUAbgB0ACUASABhAHIAZAAgAEQAaQBzAGsAOgBJAFAAUwBFAEMAOgBJAFAA cwBlAGMAIAByAGUAdgBpAGUAdwAgAGMAbwBtAG0AZQBuAHQAcwAKAFMAdABlAHYAZQAgAEsA ZQBuAHQAJQBIAGEAcgBkACAARABpAHMAawA6AEkAUABTAEUAQwA6AEkAUABzAGUAYwAgAHIA ZQB2AGkAZQB3ACAAYwBvAG0AbQBlAG4AdABzAAoAUwB0AGUAdgBlACAASwBlAG4AdAAlAEgA YQByAGQAIABEAGkAcwBrADoASQBQAFMARQBDADoASQBQAHMAZQBjACAAcgBlAHYAaQBlAHcA IABjAG8AbQBtAGUAbgB0AHMA/0ADAAEAAQAAAAouAAAo0GoGAQABAAEAAAACAAAAAQAAAAAA AAABAAEAxQKkAgGDAEXGgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYYAQyQBRcaAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACfAkAAAAAAACsSAAArUgAAK5IAACzSAAA1UgAAN5IAADqSAAAG0kAAB5J AAC/SgAAxUoAAMdKAADISgAAyUoAABZLAAAbSwAAHEsAACNLAAA5SwAAR0sAAGdLAABoSwAA a0sAAHRLAACsSwAAzksAAANMAAAdTAAAJ0wAAC5MAAAwTAAAUUwAAFtMAABkTAAAnkwAAJ9M AACjTAAArUwAALJMAADUTAAA7UwAAPVMAAD2TAAAg04AABppAAAcaQAAMWkAADdpAACwrQAA sa0AAKywAACusAAAF7MAACizAAAwswAAMbMAADazAABAswAASbMAAFyzAAC0uwAAvLsAAL27 AADauwAANbwAADm8AABVvAAAVrwAAFi8AABfvAAAYLwAAPy8AAAYvQAAKb0AAC+9AAAKwQAA DsEAAGTBAABtwQAAe8MAAHzDAAB9wwAAf8MAAJvDAAC1wwAA+MMAAPnDAAD8wwAAEMQAADPE AAA+xAAAQ8QAAETEAAB4xAAAecQAAHzEAAClxAAAwsQAADXKAAA5ygAAOsoAAETKAABFygAA TMoAAE/KAACPygAAlcoAAJbKAACjygAApMoAAKXKAACmygAAw8oAACfLAABuywAAd8sAAIDL AACCywAAg8sAAIXLAADGywAA/csAAP7LAAAFzAAAM8wAADTMAAC3zAAAvdEAAL7RAADB0QAA xtEAANvRAAA10gAARNUAAEfVAABh1QAAYtUAAGPVAABm1QAAYNcAAGPXAACq1wAAx9cAAMvX AADQ1wAA2dcAAGrYAABr2AAAbNgAAG3YAABw2AAAdNgAAL7YAAAN3gAAFd4AAMXhAADA4gAA teYAALbmAAC35gAA4OYAAA/nAAAr5wAAW+cAAIfnAACI5wAAsucAAMPnAADs5wAA7ecAAO/n AAAp6AAAMOoAADXqAABI6gAAXOoAABrrAAA/6wAAYusAAIntAACK7QAAi+0AAJPtAACl7QAA pu0AANv3AADc9wAA7fcAAO/3AAAI+AAACfgAAB34AAAx+AAAUfgAAFT4AABb+AAAXPgAAGT4 AAB9+AAAxfgAAMb4AADH+AAAMABwCwBAAAAxAACeAgAAADEAAp4CAAAAMQAEngIAAAAxAA6e AgAAADEAUp4CAAAAMQBkngIAAAAxAHyeAgAAADAAyJwAQAAAMQDOnABAAQAxAN6eAgAAADEA EKAAQAEAMQDqngIAAAAxAOyeAgAAADEA7p4CAAAAMQCInwIAAAAxAJKfAgAAADEAlJ8CAAAA MQCinwIAAAAxAM6fAgAAADEA6p8CAAAAMQAqoAIAAAAxACygAgAAADEAMqACAAAAMQBEoAIA AAAxALSgAgAAADEA+KACAAAAMQBioQIAAAAxAJahAgAAADEAqqECAAAAMQC4oQIAAAAxALyh AgAAADEA/qECAAAAMQASogIAAAAxACSiAgAAADEAmKICAAAAMQCaogIAAAAxAKKiAgAAADEA tqICAAAAMQDAogIAAAAxAASjAgAAADEANqMCAAAAMQBGowIAAAAwAFqiAEADADAAdKUAQAAA MQAeqAIAAAAxAKLaAEAAADEAIqgCAAAAMADM2gBAAAAxAB6CAgAAADAAvmMBQAAAMQAgggIA AAAwALhpAUAAADEALqgCAAAAMQBQqAIAAAAxAGCoAgAAADEAYqgCAAAAMQBsqAIAAAAxAICo AgAAADEAvm4BQAAAMADkbgFAAAAxAACOAgAAADEAEI4CAAAAMQASjgIAAAAxAEyOAgAAADEA Ao8CAAAAMQAKjwIAAAAxAEKPAgAAADEARI8CAAAAMQBIjwIAAAAxAFaPAgAAADEAWI8CAAAA MQCQkAIAAAAxAMiQAgAAADEA6pACAAAAMACafwFAAAAxACSCAgAAADEAUIcBQAAAMQAAhAIA AAAxAPyHAUAAADEAEoQCAAAAMQAUhAIAAAAxABaEAgAAADEAGoQCAAAAMQBShAIAAAAxAIaE AgAAADEADIUCAAAAMQAOhQIAAAAxABSFAgAAADEAPIUCAAAAMQCChQIAAAAxAJiFAgAAADEA ooUCAAAAMQCkhQIAAAAxAAyGAgAAADEADoYCAAAAMQAUhgIAAAAxAGaGAgAAADAAGIwBQAAA MQD2kAIAAAAxAP6QAgAAADEAAJECAAAAMQAUkQIAAAAxABaRAgAAADEAJJECAAAAMQAqkQIA AAAxAKqRAgAAADEAtpECAAAAMQC4kQIAAAAxANKRAgAAADEA1JECAAAAMQDWkQIAAAAxANiR AgAAADEA/pYBQAAAMQASkgIAAAAxAKCSAgAAADEAspICAAAAMQDEkgIAAAAxAMiSAgAAADEA ypICAAAAMQDOkgIAAAAxAFCTAgAAADEAvpMCAAAAMQDAkwIAAAAxAM6TAgAAADEAKpQCAAAA MQDGlwFAAAAwANiYAUAAADEAoIYCAAAAMQCihgIAAAAxAKiGAgAAADEAAIoCAAAAMQCyhgIA AAAwAOSiAUAAADEAZocCAAAAMQCSqAIAAAAxAKKHAgAAADEAxqgCAAAAMQCkhwIAAAAwAAKp AUAAADEAqocCAAAAMQD8rAFAAAAxACqKAgAAADEAZIoCAAAAMQBsigIAAAAxAHaKAgAAADEA iq0BQAAAMQCwhwIAAAAxALKHAgAAADEAtIcCAAAAMQC2hwIAAAAxALyHAgAAADEAxIcCAAAA MACsrgFAAAAxAIiKAgAAADAASrkBQAAAMQCqwAFAAAAwAKDCAUAAADEAAJYCAAAAMQAClgIA AAAxAASWAgAAADEAVpYCAAAAMQC0lgIAAAAxAOyWAgAAADEATJcCAAAAMQCklwIAAAAxAKaX AgAAADEA+pcCAAAAMQAAmgIAAAAxAFKaAgAAADEAVJoCAAAAMQBYmgIAAAAwAJLKAUAAADEA mIoCAAAAMQCgzgFAAAAxAKKKAgAAADEAxs4BQAAAMQDKigIAAAAxABSLAgAAADAAQtABQAAA MQBaiwIAAAAxAJLUAUAAADEAXIsCAAAAMQCa1AFAAAAxAGyLAgAAADAAvtQBQAAAMABuiwIA AAAxAHCLAgAAADEAAJwCAAAAMQCSiwIAAAAxAEijAgAAADEASqMCAAAAMQDIqAIAAAAxAPCo AgAAADEAMKkCAAAAMQC6owIAAAAxADapAgAAADEAyKMCAAAAMQDYowIAAAAxAAqkAgAAADAA 0FcDQAAAMADSVwNAAAAFAAAARwaQAQAAAgIGAwUEBQIDBAAAAAMAAAAAAAAAAAAAAAABAAAA AAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANQaQAQIAAgAFAAAAAAAAAAAA AAAQAAAAAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQAQAAAgsGBAICAgICBAAA AAMAAAAAAAAAAAAAAAABAAAAAAAAAEEAcgBpAGEAbAAAADMGkAEAAAIABQAAAAAAAAAAAAAD AAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAAAA/BpABAAACBwMJAgIFAgQEAAAAAwAA AAAAAAAAAAAAAAEAAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAIgAEAHGIiBgAANAC AABoAQAAAACrijymMqpBpgAAAAAzAIoBAACvIwAAa8sAABIAaAAAAAQAgxCxAQAAAAAAAAAA AAASAAEAAAABAAAAAAAAAOwDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAKUGwAe0ALQAgAAeMAAAEQAZAGQAAAAZAAAAz/kAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAA XQL//xIAAAAAAAAALQBcAGQAbwBjAHUAbQBlAG4AdABjAGwAYQBzAHMAWwBjAGgAYQBwAHQA ZQByAHAAYQBnAGUALAAxADIAcAB0AF0AewBjAG8AdQBuAHQAZQByAHAAYQBuAGUAfQAAAAAA AAAKAFMAdABlAHYAZQAgAEsAZQBuAHQACgBTAHQAZQB2AGUAIABLAGUAbgB0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAP7/AgABAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29m dCBXb3JkIERvY3VtZW50AP7///9OQjZXEAAAAFdvcmQuRG9jdW1lbnQuOAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAADCgEAAAAAAAAAAAAAAAAA AAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5oAQAAJAEAAAwA AAABAAAAaAAAAA8AAABwAAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAALAAAA rAAAABAAAAC0AAAAEwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAAYBAAACAAAAECcAAB4A AAARAAAAQkJOIFRlY2hub2xvZ2llcwBzAHMDAAAAsQEAAAMAAABoAAAAAwAAAM/5AAADAAAA YhYIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAuAAAAXGRvY3Vt ZW50Y2xhc3NbY2hhcHRlcnBhZ2UsMTJwdF17Y291bnRlcnBhbmV9AAwQAAACAAAAHgAAAAYA AABUaXRsZQADAAAAAQAAAJgAAAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIA AAAKAAAAX1BJRF9HVUlEAAIAAAAQJwAAQQAAAE4AAAB7AEIAMgAwADQAQwAxADAAMAAtAEIA NAA2AEMALQAxADEARAAzAC0AQgBGAEQARgAtADAAMAAwADUAMAAyADgANQAyAEYAMgA5AH0A AAAAAAAA/v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA hAEAABAAAAABAAAAiAAAAAIAAACQAAAAAwAAAMgAAAAEAAAA1AAAAAUAAADoAAAABwAAAPQA AAAIAAAABAEAAAkAAAAYAQAAEgAAACQBAAAKAAAAQAEAAAwAAABMAQAADQAAAFgBAAAOAAAA ZAEAAA8AAABsAQAAEAAAAHQBAAATAAAAfAEAAAIAAAAQJwAAHgAAAC4AAABcZG9jdW1lbnRj bGFzc1tjaGFwdGVycGFnZSwxMnB0XXtjb3VudGVycGFuZX0ALjAeAAAAAQAAAABkb2MeAAAA CwAAAFN0ZXZlIEtlbnQAYR4AAAABAAAAAHRldh4AAAAHAAAATm9ybWFsAGUeAAAACwAAAFN0 ZXZlIEtlbnQAYR4AAAADAAAANTEAdh4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAHRAAAAA ALyJCjcAAABAAAAAANqJZaVIvwFAAAAAADTNaBZkvwEDAAAAEgAAAAMAAACvIwAAAwAAAGvL AAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADspcEAcwAJBAAAxBK/AAAA AAABEQABAAEABAAA6qsBAA4AamJqYsAJwAkAAAAAAAAAAAAAAAAAAAAAAAAJBBYAAKoCAKpr AQCqawEAx/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAAAAAAAAAAAAugEAALoBAAAAAAAA ugEAAAAAAAC6AQAAAAAAALoBAAAAAAAAugEAABQAAAAAAAAAAAAAAD4DAABkDgAAcBgAAAAA AABwGAAAAAAAAHAYAAAAAAAAcBgAAHwAAADsGAAAxAAAAKIRAAAAAAAAyDUAACoBAAB8IwAA BAAAAIAjAAAAAAAAgCMAAAAAAACAIwAAAAAAAIAjAAAAAAAAgCMAAAAAAACAIwAAAAAAAIAj AAAAAAAACisAAAIAAAAMKwAAAAAAAAwrAAAAAAAADCsAAAAAAAAMKwAAAAAAAAwrAAAAAAAA DCsAACwAAADyNgAA9AEAAOY4AACsAAAAOCsAAJAKAAAAAAAAAAAAAAAAAAAAAAAAugEAAAAA AACAIwAAAAAAAAAAAAAAAAAAAAAAAAAAAACAIwAAAAAAAIAjAAAAAAAAgCMAAAAAAACAIwAA AAAAADgrAAAAAAAAnicAAAAAAAC6AQAAAAAAALoBAAAAAAAAgCMAAAAAAAAAAAAAAAAAAIAj AAAAAAAABBoAAHgJAACeJwAAAAAAAJ4nAAAAAAAAnicAAAAAAACAIwAAHgQAALoBAAAAAAAA gCMAAAAAAAC6AQAAAAAAAIAjAAAAAAAACisAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzgEAALgA AACGAgAAuAAAALoBAAAAAAAAugEAAAAAAAC6AQAAAAAAALoBAAAAAAAAgCMAAAAAAAAKKwAA AAAAAJ4nAABsAwAAnicAAAAAAAAAAAAAAAAAAAorAAAAAAAAugEAAAAAAAC6AQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CisAAAAAAAAAAAAAAAAAALAZAABUAAAAkBSutAAAAACiEQAAzgYAAHAYAAAAAAAAnicAAAAA AAAKKwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXGRvY3VtZW50Y2xhc3NbY2hh cHRlcnBhZ2UsMTJwdF17Y291bnRlcnBhbmV9DVx1c2VwYWNrYWdlW1QxXXtmb250ZW5jfQ1c dXNlcGFja2FnZXt4c3BhY2V9DVx1c2VwYWNrYWdle2Vwc2ZpZ30NDSVccmFnZ2VkYm90dG9t DQ1cdGl0bGV7QSBTZWN1cml0eSBFdmFsdWF0aW9uIG9mIElQc2VjfQ1cYXV0aG9ye05pZWxz IEZlcmd1c29uIGFuZCBCcnVjZSBTY2huZWllcn0NXGNvbnRhY3RlbWFpbHtce25pZWxzLHNj aG5laWVyXH1AY291bnRlcnBhbmUuY29tfQ1ccHVycG9zZXtUZWNobmljYWwgcmVwb3J0IDk5 LTEzfQ1cZG9jdW1lbnRkYXRlezE5OTkvMDIvMjd9ICUgQmV0aCwgdGhpcyBkYXRlIGZvcm1h dCBpcyBjb3JyZWN0Lg0JCQkgICUgVGhlIHN0eWxlIHNoZWV0IGNvbnZlcnRzIGl0IHRvIHNv bWV0aGluZyBuaWNlci4NDVxiZWdpbntkb2N1bWVudH0NXG1ha2V0aXRsZQ0NXGNoYXB0ZXIq e0V4ZWN1dGl2ZSBzdW1tYXJ5fQ1JUHNlYyBpcyBhIHNldCBvZiBwcm90b2NvbHMgdGhhdCBw cm92aWRlcyBjb21tdW5pY2F0aW9uIHNlY3VyaXR5IGZvciBjb21wdXRlcnMgdXNpbmcgSVAt YmFzZWQgY29tbXVuaWNhdGlvbiBuZXR3b3Jrcy4gSXQgcHJvdmlkZXMgYXV0aGVudGljYXRp b24gYW5kIGNvbmZpZGVudGlhbGl0eSBzZXJ2aWNlcyBvbiBhIHBhY2tldCBsZXZlbC4gVG8g c3VwcG9ydCB0aGUgSVBzZWMgc2VjdXJpdHksIGEga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wg Y2FsbGVkIElTQUtNUCBpcyB1c2VkLiBJU0FLTVAgdXNlcyBwdWJsaWMta2V5IGNyeXB0b2dy YXBoaWMgdGVjaG5pcXVlcyB0byBzZXQgdXAga2V5cyBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQg cGFydGllcyB0byBiZSB1c2VkIHdpdGggSVBzZWMuDQ1Cb3RoIElQc2VjIGFuZCBJU0FLTVAg YXJlIHRvbyBjb21wbGV4LiBbYSBwcm90b2NvbCBpcyB0b28gY29tcGxleCBvbmx5IHJlbGF0 aXZlIHRvIGEgc3BlY2lmaWVkIHNldCBvZiByZXF1aXJlbWVudHMgdGhhdCBhcmUgc2F0aXNm aWVkIGJ5IGEgc2ltcGxlciBwcm90b2NvbC4gVG8gc3Vic3RhbnRpYXRlIHRoaXMgb2JzZXJ2 YXRpb24sIG9uZSBvdWdodCB0byBkZWZpbmUgdGhlIHJlcXVpcmVtZW50cyB0aGF0IG9uZSBi ZWxpZXZlcyB0aGUgcHJvdG9jb2wgaXMgdHJ5aW5nIHRvcCBzYXRpc2Z5LCBhbmQgdGhlbiAg b2ZmZXIgYSBzaW1wbGVyIHByb3RvY29sLl0gVGhpcyBoaWdoIGNvbXBsZXhpdHkgbGVhZHMg dG8gZXJyb3JzLiBXZSBoYXZlIGZvdW5kIHNlY3VyaXR5IGZsYXdzIGluIGJvdGggSVBzZWMg YW5kIElTQUtNUCwgYW5kIGV4cGVjdCB0aGF0IHRoZXJlIGFyZSBtYW55IG1vcmUuIFdlIGV4 cGVjdCBhbnkgYWN0dWFsIGltcGxlbWVudGF0aW9uIHRvIGNvbnRhaW4gbWFueSBtb3JlIGVy cm9ycywgc29tZSBvZiB3aGljaCB3aWxsIGNhdXNlIHNlY3VyaXR5IHdlYWtuZXNzZXMuIFRo ZXNlIHByb3RvY29scyBnaXZlIHRoZSBpbXByZXNzaW9uIG9mIGhhdmluZyBiZWVuIGRlc2ln bmVkIGJ5IGEgY29tbWl0dGVlOiB0aGV5IHRyeSB0byBiZSBldmVyeXRoaW5nIGZvciBldmVy eWJvZHkgYXQgdGhlIGNvc3Qgb2YgY29tcGxleGl0eS4gRm9yIG5vcm1hbCBzdGFuZGFyZHMs IHRoYXQgaXMgYmFkIGVub3VnaDsgZm9yIHNlY3VyaXR5IHN5c3RlbXMsIGl0IGlzIGNhdGFz dHJvcGhpYy4gSW4gb3VyIG9waW5pb24sIHRoZSBjb21wbGV4aXR5IG9mIGJvdGggSVBzZWMg YW5kIElTQUtNUCBjYW4gYmUgcmVkdWNlZCBieSBhIGxhcmdlIGZhY3RvciB3aXRob3V0IGEg c2lnbmlmaWNhbnQgbG9zcyBvZiBmdW5jdGlvbmFsaXR5Lg0NSVBzZWMgaXMgaW4gYmV0dGVy IHNoYXBlIHRoYW4gSVNBS01QLiBUaGUgZGVzY3JpcHRpb24gYW5kIGRlZmluaXRpb25zIGFy ZSByZWFzb25hYmx5IGNsZWFyLiBBIGNhcmVmdWwgaW1wbGVtZW50YXRpb24gb2YgSVBzZWMg Y2FuIGFjaGlldmUgYSBnb29kIGxldmVsIG9mIHNlY3VyaXR5LiBVbmZvcnR1bmF0ZWx5LCBJ UHNlYyBieSBpdHNlbGYgaXMgbm90IGEgdmVyeSB1c2VmdWwgcHJvdG9jb2wuIFVzZSBvbiBh IGxhcmdlIHNjYWxlIHJlcXVpcmVzIHRoZSBrZXkgbWFuYWdlbWVudCBmdW5jdGlvbnMgb2Yg SVNBS01QLiBbd2hpbGUgSSB3b3VsZCB0ZW5kIHRvIGFncmVlIHdpdGggdGhpcyBvYnNlcnZh dGlvbiwgSSBzaG91bGQgbm90ZSB0aGF0IGEgbm9uLXRyaXZpYWwgbnVtYmVyIG9mIElQc2Vj IGltcGxlbWVudGF0aW9ucywgdXNlZCBpbiBjb25zdHJhaW5lZCBjb250ZXh0cywgYXJlIG1h bnVhbGx5IGtleWVkLl0NDUlTQUtNUCBpcyBjdXJyZW50bHkgbm90IGluIGEgc3VpdGFibGUg c3RhdGUgZm9yIGltcGxlbWVudGF0aW9uLiBNYWpvciB3b3JrIHdpbGwgYmUgcmVxdWlyZWQg dG8gZ2V0IGl0IHRvIHRoYXQgcG9pbnQuIFRoZXJlIGFyZSBtYW55IHNlY3VyaXR5LWNyaXRp Y2FsIGVycm9ycywgYXMgd2VsbCBhcyBtYW55IHVubmVjZXNzYXJ5IGNyb3NzLWRlcGVuZGVu Y2llcyB3aXRoaW4gdGhlIHByb3RvY29sLiBUaGVzZSBzaG91bGQgYWxsIGJlIGVsaW1pbmF0 ZWQgYmVmb3JlIGEgbmV3IGV2YWx1YXRpb24gaXMgZG9uZS4NDUJhc2VkIG9uIG91ciBhbmFs eXNpcywgd2UgcmVjb21tZW5kIHRoYXQgSVBzZWMgYW5kIElTQUtNUCBub3QgYmUgdXNlZCBm b3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBBdCB0aGUgbW9tZW50IHdlIGNhbm5vdCBy ZWNvbW1lbmQgYSBkaXJlY3QgYWx0ZXJuYXRpdmUuIFNvbWUgYXBwbGljYXRpb25zIG1pZ2h0 IGJlIGFibGUgdG8gdXNlIFNTTCBcY2l0ZXtTU0x2M05vdjk2fSwgd2hpY2ggaW4gb3VyIG9w aW5pb24gaXMgYSBtdWNoIGJldHRlciBwcm90b2NvbCB0aGF0IHByb3ZpZGVzIGEgbXVjaCBo aWdoZXIgbGV2ZWwgb2Ygc2VjdXJpdHkgd2hlbiB1c2VkIGFwcHJvcHJpYXRlbHkuDQ1cdGFi bGVvZmNvbnRlbnRzDQ1cY2hhcHRlcntJbnRyb2R1Y3Rpb259DQ1BdCB0aGUgcmVxdWVzdCBv ZiBOU0EsIENvdW50ZXJwYW5lIGhhcyBjb25kdWN0ZWQgYSBzZWN1cml0eSByZXZpZXcgb2Yg dGhlIElQc2VjIGFuZCBJU0FLTVAgc2VjdXJpdHkgcHJvdG9jb2xzLg0NVGhpcyBldmFsdWF0 aW9uIGlzIGJhc2VkIG9uIFJGQ3MgMjQwMS0tMjQx --------------C118C512B01573D8EDFA4DF1-- From owner-ipsec@lists.tislabs.com Mon Jan 24 11:56:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10165; Mon, 24 Jan 2000 11:55:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19852 Mon, 24 Jan 2000 13:23:58 -0500 (EST) Message-Id: <3.0.5.32.20000124180554.00a92e40@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Jan 2000 18:05:54 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Usage of IDs in IKE Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA19414 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As requested on the meeting during the San Diego bakeoffs, a short notice on the usage on ID payloads in IKE. It should be noted that these are my personal opinions, not a standard. typedef enum { /* IPSEC_ID_RESERVED = 0, */ IPSEC_ID_IPV4_ADDR = 1, IPSEC_ID_FQDN = 2, IPSEC_ID_USER_FQDN = 3, IPSEC_ID_IPV4_ADDR_SUBNET = 4, IPSEC_ID_IPV6_ADDR = 5, IPSEC_ID_IPV6_ADDR_SUBNET = 6, IPSEC_ID_IPV4_ADDR_RANGE = 7, IPSEC_ID_IPV6_ADDR_RANGE = 8, IPSEC_ID_DER_ASN1_DN = 9, IPSEC_ID_DER_ASN1_GN = 10, IPSEC_ID_KEY_ID = 11 } IkeIpsecIdentificationType; PHASE 1 using preshared keys ============================ The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and KEY_ID are recommended in a phase 1 exchange using preshared keys. In agressive mode, the values can be used for an immediate policy lookup. In main mode, the responder must retrieve the secret from the spd before it receives the ID, thus only IPV4_ADDR is useful in main mode. Is the responder has a "group" policy to allow several hosts with volatile IP addresses to connect, the use of aggressive mode and ID types USER_FQDN and KEY_ID is recommended. DER_ASN1_DN and DER_ASN1_GN are meaningful IDs as well, if an implementation chooses to store policy data indexed by these IDs. Address ranges and subnets are not allowed in Phase 1. An IKE implementation MUST at least implement IPV4_ADDR. However, USER_FQDN is a very useful ID because end users are able to understand and remember them. PHASE 1 using pk signatures =========================== The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and DER_ASN1_DN are recommended in a phase 1 exchange using signatures. In agressive mode, the values can be used for an immediate policy lookup. In main mode, only the initiator's IP address is available for the initial policy lookup of the responder. Therefore, the policy must contain (IP address, ID) or (IP address range, ID range) pairs. After receiving the 5th packet of MM, the responder has to do a second policy check. The responder must reject a MM where the IDV4_ADDR ID and the IP address does not match. Is the responder has a "group" policy to allow several hosts with volatile IP addresses to connect, the use of aggressive mode and ID types USER_FQDN and DER_ASN1_DN is recommended. It should be noted that these IDs, especially DER_ASN1_DN may contain valuable information which is not suitable to be transmitted in cleartext. In this case, I recommend public key encrytion. The alternative is having one policy entry (0.0.0.0/0, (list of all IDs)). The ID must show up in the certificate! E.g., if the ID is USER_FQDN, the subjectAltName must contain an email address. DER_ASN1_GN is may be used as an alternative to IPV4_ADDR, IPV6_ADDR, FQDN and USER_FQDN. The subjectAltNames in certificates are encoded as general names, so DER_ASN1_GN is a generic pointer to a subjectAltName. One could even argue that USER_FQDN is not a valid ID and that email addresses must be encoded using DER_ASN1_GN. I don't think so. Address ranges and subnets are not allowed in Phase 1. IPSEC_ID_KEY_ID is not useful. An IKE implementation MUST at least implement IPV4_ADDR and DER_ASN1_DN. PHASE 1 using pk encryption =========================== Same as signatures, but the ID is safe in agressive mode. Quick Mode ========== QM IDs act as selectors for packets. src and dst addresses of IP packets transmitted through the SA must match the negotiated IDs. While it is possible to not send IDs in QM, it is not recommended. IPV4_ADDR, IPV4_ADDR_SUBNET, IPV4_ADDR_RANGE, IPV6_ADDR, IPV6_ADDR_SUBNET, IPV6_ADDR_RANGE may be used in QM. IPv4 and IPv6 may not be mixed. ADDR, RANGE and SUBNET may be mixed. ============================================================================ ================ Do the current RFC have any MUST requirements for ID types? Jörn Sierwald From owner-ipsec@lists.tislabs.com Mon Jan 24 12:17:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10531; Mon, 24 Jan 2000 12:17:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19945 Mon, 24 Jan 2000 13:39:14 -0500 (EST) Date: Mon, 24 Jan 2000 13:44:03 -0500 Message-Id: <200001241844.NAA16433@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> <4.2.1.20000120173822.00b476f0@mail.vpnc.org> <38886529.E3D38477@bbn.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It appears that the document you annotated isn't the same as the version distributed on Bruce's web site. The arguments for why ESP without authentication is a valid option ignore the issue raised by Steve Bellovin -- that encryption without authentication fails to provide confidentiality in the presence of active attack. (I wonder why Bruce didn't mention that work...) So the scenario given (application layer integrity) doesn't fit, because you need integrity iff you have active attackers, but if you do then doing encryption-only at the IPSEC layer is insecure. Conversely, encryption-only is fine if you worry *only* about passive attack (in which case integrity of any kind is not needed). paul From owner-ipsec@lists.tislabs.com Mon Jan 24 13:12:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11250; Mon, 24 Jan 2000 13:12:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20327 Mon, 24 Jan 2000 14:34:01 -0500 (EST) Message-ID: <388CAA71.7F526473@storm.ca> Date: Mon, 24 Jan 2000 14:39:29 -0500 From: Sandy Harris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: <38874c9a0.2c38@databus.databus.com> <20000124111813.C2165@alcove.wittsend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Michael H. Warfield" wrote: > > On Thu, Jan 20, 2000 at 12:54:00PM -0500, Barney Wolff wrote: > > As long as we're responding to commentary, will some kind soul point out > > the convincing rebuttal to the vigorous assertion by the unperson (wjs) > > that IKE is subject to DoS attack. Surely there is one ... Failing that, how about a draft that includes a defense against it? > Similarly, can someone post a demonstration of said DoS attack? > I would like to examine it. The paper includes source code for at least one attack. It was posted to the linux-ipsec list and is in the archive at: http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00319.html From owner-ipsec@lists.tislabs.com Mon Jan 24 13:29:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11414; Mon, 24 Jan 2000 13:29:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20353 Mon, 24 Jan 2000 14:42:17 -0500 (EST) Message-ID: <004201bf66a3$6e6553e0$6f0909c0@duan.bjnet.edu.cn> From: "Duan Haixin" To: Subject: =?gb2312?B?u9i4tDogQnJ1Y2UgU2NobmVpZXIgb24gSVBzZWM=?= Date: Tue, 25 Jan 2000 03:44:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think the following paper is related to the issue you discussed: "Fixing of secuiryt flaw in IKE protocols " by J.Zhou presented in Electronics Letters , V.35,N.13, pp 1072-1073 . For I am just a newer of IPSec, I don't know whether the problems proposed are correct or not. Duan dhx@bjnet.edu.cn -----Original Message----- ·¢¼þÈË: Barney Wolff ÊÕ¼þÈË: ipsec@lists.tislabs.com ÈÕÆÚ: 2000Äê1ÔÂ25ÈÕ 1:59 Ö÷Ìâ: Re: Bruce Schneier on IPsec >As long as we're responding to commentary, will some kind soul point out >the convincing rebuttal to the vigorous assertion by the unperson (wjs) >that IKE is subject to DoS attack. Surely there is one ... > >Barney Wolff > > From owner-ipsec@lists.tislabs.com Mon Jan 24 14:24:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12140; Mon, 24 Jan 2000 14:24:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20525 Mon, 24 Jan 2000 15:28:02 -0500 (EST) Message-ID: <388CB690.6C4DCF76@ire-ma.com> Date: Mon, 24 Jan 2000 15:31:12 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Roy Pereira , ipsec Subject: Clarification proposal for Deflate RFC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Roy, all, Here are recommended changes to rfc1951 "DEFLATE Compressed Data Format Specification": Add the following statement at the very end of section 2, Compressed representation overview. "There must be no additional data sent beyond that described in section 3, Detailed specification. Specifically. neither the library header nor the Adler32 checksum generated by Zlib must be sent." Add a new section "Zlib interface recommendations" between the existing section 4. Compression algorithm details, and section 5. References, as follows: 5. Zlib interface recommendations The default initialization call to the Zlib implementation of Deflate produces an unnecessary wrapper consisting of a Zlib specific header and checksum. If this publicly available implementation of Deflate is used, then it should be initialized in a manner similar to the following: returnCode = deflateInit2_( &stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, -WINDOW_SIZE, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream)); The absolute value of the WINDOW_SIZE argument controls the size of the history buffer used by deflate, in powers of 2 bytes (i.e. WINDOW_SIZE = 11 configures a 2048 byte history buffer). Negating this argument will prevent Zlib from adding the Zlib header or Adler32 checksum. Likewise, the initialization of the Zlib decompression implementation Inflate should be invoked in a manner to the following: returnCode = inflateInit2_( &stream, -WINDOW_SIZE, ZLIB_VERSION, sizeof(z_stream)); In this case, WINDOW_SIZE should be 15, permitting the maximum history buffer of 32768. By setting the argument to -WINDOW_SIZE, or -32768, Zlib will be configured not to expect a Zlib header or Adler32 checksum. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Mon Jan 24 15:04:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12690; Mon, 24 Jan 2000 15:04:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20771 Mon, 24 Jan 2000 16:31:39 -0500 (EST) Date: Mon, 24 Jan 2000 16:36:23 -0500 From: "Michael H. Warfield" To: Sandy Harris Cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec Message-ID: <20000124163623.I2165@alcove.wittsend.com> References: <38874c9a0.2c38@databus.databus.com> <20000124111813.C2165@alcove.wittsend.com> <388CAA71.7F526473@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <388CAA71.7F526473@storm.ca>; from sandy@storm.ca on Mon, Jan 24, 2000 at 02:39:29PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Jan 24, 2000 at 02:39:29PM -0500, Sandy Harris wrote: > "Michael H. Warfield" wrote: > > On Thu, Jan 20, 2000 at 12:54:00PM -0500, Barney Wolff wrote: > > > As long as we're responding to commentary, will some kind soul point out > > > the convincing rebuttal to the vigorous assertion by the unperson (wjs) > > > that IKE is subject to DoS attack. Surely there is one ... > Failing that, how about a draft that includes a defense against it? > > Similarly, can someone post a demonstration of said DoS attack? > > I would like to examine it. > The paper includes source code for at least one attack. It was posted > to the linux-ipsec list and is in the archive at: > http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00319.html The code references a function, in 5 locations, I don't seem to have, arc4random(). I presume that this has something to do with some ARC4 (alleged RC4) libraries? I also presume that this is just a "better" random number generator, but I would hate to presume that I could just substitute something else only to have things not work. There doesn't seem to be an *rc4random type thing in the OpenSSL libraries I typically use. Any thoughts on "the missing piece", where I might find it, or what I might substitute? Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Mon Jan 24 15:08:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12741; Mon, 24 Jan 2000 15:08:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20725 Mon, 24 Jan 2000 16:18:29 -0500 (EST) Message-Id: <200001242120.NAA03290@potassium.network-alchemy.com> To: Barney Wolff cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-reply-to: Your message of "Thu, 20 Jan 2000 12:54:00 EST." <38874c9a0.2c38@databus.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3287.948748849.1@network-alchemy.com> Date: Mon, 24 Jan 2000 13:20:49 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As long as we're being sarcastic, why don't you write it yourself? Dan. On Thu, 20 Jan 2000 12:54:00 EST you wrote > As long as we're responding to commentary, will some kind soul point out > the convincing rebuttal to the vigorous assertion by the unperson (wjs) > that IKE is subject to DoS attack. Surely there is one ... > > Barney Wolff > From owner-ipsec@lists.tislabs.com Tue Jan 25 05:29:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA11152; Tue, 25 Jan 2000 05:29:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA23340 Tue, 25 Jan 2000 06:52:41 -0500 (EST) Date: Tue, 25 Jan 2000 11:38:16 +0100 (MET) From: "Hans v. Sommerfeld" Message-Id: <200001251038.LAA27913@charly.peanuts.local> To: lisa@baltimore.ie Subject: Once upon a time ... (Re: Remove) Cc: ipsec@lists.tislabs.com In-Reply-To: <000e01bf665b$30f93a00$aa15a8c0@lw_sat.baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-MD5: KUALB4STKnhB+rE0zwYEpw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id GAA23337 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello and Goodbye LadyWishBone, as I'm almost lurking the list I'd like to give you some helpful reply on you special topic. Just read below. > From: "Lisa Wilkinson" > To: > Subject: Remove > Date: Mon, 24 Jan 2000 03:07:22 -0800 > > Actually, > > How do I remove myself from this list...... anyone? > > Lisa Once upon a time ... you should have received something like: ------------- Begin Included Message ------------- Welcome to the ipsec mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe ipsec or from another account, besides lisa@baltimore.ie: unsubscribe ipsec lisa@baltimore.ie ------------- End Included Message ------------- Kind Regards, HvS :-) -------------- ------------------- 9th EICAR Annual Conference in Brussels, Belgium, EU. March 4th-7th, 2000. http://www.eicar.dk/ eicar-online: http://www.eicar.org/ -------------- ------------------- Hans von Sommerfeld, Freelance IT-Consultant snoopy@redbaron.bir.uunet.de Tel.: +49 30 65470891 Fax:+49 30 65470892 From owner-ipsec@lists.tislabs.com Tue Jan 25 06:25:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15484; Tue, 25 Jan 2000 06:25:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23866 Tue, 25 Jan 2000 08:01:36 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200001241844.NAA16433@tonga.xedia.com> References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> <4.2.1.20000120173822.00b476f0@mail.vpnc.org> <38886529.E3D38477@bbn.com> <200001241844.NAA16433@tonga.xedia.com> Date: Tue, 25 Jan 2000 08:07:10 -0500 To: Paul Koning From: Stephen Kent Subject: Re: Bruce Schneier on IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Yes, ESP w/o authentication is susceptible to certain forms of active attacks that can result in a breach of confidentiality, under certain circumstances. I think the easiest way to characterize such circumstances is that muxing multiple user data streams over a single SA provides the opportunity for such attacks. Since IPsec allows for fine grained SAs, it is possible to avoid such attacks and thus there are safe ways of using this option as well. The text of 2401 alludes to such concerns already. A stronger and more precise set of warnings could be added if necessary. Steve From owner-ipsec@lists.tislabs.com Tue Jan 25 07:02:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18553; Tue, 25 Jan 2000 07:02:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24143 Tue, 25 Jan 2000 08:33:12 -0500 (EST) Message-Id: <200001251333.IAA24139@lists.tislabs.com> From: Niels Provos To: "Michael H. Warfield" Cc: Sandy Harris , ipsec@lists.tislabs.com Date: Tue, 25 Jan 2000 08:37:15 -0500 Subject: Re: Bruce Schneier on IPsec In-Reply-To: "Michael H. Warfield", Mon, 24 Jan 2000 16:36:23 EST Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20000124163623.I2165@alcove.wittsend.com>, "Michael H. Warfield" wr ites: >On Mon, Jan 24, 2000 at 02:39:29PM -0500, Sandy Harris wrote: >> The paper includes source code for at least one attack. It was posted >> to the linux-ipsec list and is in the archive at: >> http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00319.html >(alleged RC4) libraries? I also presume that this is just a "better" >random number generator, but I would hate to presume that I could just arc4random() is the PRNG used in OpenBSD. Replacing it with random() should be fine in this case. Greetings, Niels. From owner-ipsec@lists.tislabs.com Tue Jan 25 09:37:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21337; Tue, 25 Jan 2000 09:37:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24556 Tue, 25 Jan 2000 10:47:22 -0500 (EST) Message-ID: <388DC721.1635A825@nue.et-inf.uni-siegen.de> Date: Tue, 25 Jan 2000 16:54:09 +0100 From: Michael Schmidt X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: de,en MIME-Version: 1.0 To: IP Security List CC: Sandy Harris Subject: Re: Bruce Schneier on IPsec References: <20000120071209.80026ACAE2@smb.research.att.com> <38870715.6A597851@storm.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Have I missed something, or are we still waiting for a reference to this (Steve Bellovin's) note? I'm really curious for it, too. Michael Schmidt Sandy Harris wrote: > > "Steven M. Bellovin" wrote: > > > On the other hand, the distinction between transport mode and tunnel mode is a > > vital matter of network architecture, and I don't think that that was properly > > understood by the authors. (I sent a long note to them on this topic quite > > some time ago.) I'm quite convinced that we made the right choice there, and > > see no reason to revisit it. > > Could you post the note here, or is it perchance in the archives? The reason > for having the two modes is far from obvious to me, and perhaps others. -- =================================================== Michael Schmidt --------------------------------------------------- Institute for Data Communications Systems University of Siegen, Germany www.nue.et-inf.uni-siegen.de --------------------------------------------------- The 'Thin Client Security Homepage': www.nue.et-inf.uni-siegen.de/~schmidt/tcsecurity/ --------------------------------------------------- http: www.nue.et-inf.uni-siegen.de/~schmidt e-mail: schmidt@nue.et-inf.uni-siegen.de phone: +49 271 740-2332 fax: +49 271 740-2536 mobile: +49 173 3789349 --------------------------------------------------- ### Siegen - The Arctic Rain Forest ### =================================================== From owner-ipsec@lists.tislabs.com Tue Jan 25 09:38:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21360; Tue, 25 Jan 2000 09:38:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24612 Tue, 25 Jan 2000 11:15:12 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Michael Schmidt Cc: IP Security List , Sandy Harris Subject: Re: Bruce Schneier on IPsec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jan 2000 11:19:44 -0500 Message-Id: <20000125161950.5F2A841F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <388DC721.1635A825@nue.et-inf.uni-siegen.de>, Michael Schmidt writes : > Have I missed something, or are we still waiting for a reference to > this (Steve Bellovin's) note? > > I'm really curious for it, too. I haven't managed to find my note, but I'm still looking... It was a private note to Bruce, and isn't in the archives. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Jan 25 10:32:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22615; Tue, 25 Jan 2000 10:32:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24770 Tue, 25 Jan 2000 12:02:45 -0500 (EST) Date: Tue, 25 Jan 2000 12:10:57 -0500 Message-Id: <200001251710.MAA01839@trampoline.thunk.org> To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: <38886529.E3D38477@bbn.com> (message from Steve Kent on Fri, 21 Jan 2000 08:54:50 -0500) Subject: Re: Bruce Schneier on IPsec From: tytso@mit.edu Phone: (781) 391-3464 References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> <4.2.1.20000120173822.00b476f0@mail.vpnc.org> <38886529.E3D38477@bbn.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve Kent wrote: [I tend to agree with this analysis. The argument for weak key checking was made by folks who don't understand the cryptographic issues involved, but who are persistent and loud, e.g., Bill Simpson. Ted T'so (co-chair of the WG) and I discussed this problem, and tried to explain it to the list, but were unsuccessful. Another flaw in the committee process.] Actually, I think we had gotten agreement to remove the weak key check, but it never made it into the document edit. So I believe it was an oversight, and I'd chalk this one up to the complexity of documents and overtaxed document editors. Other folks who argued quite strongly for removing the weak key check included Bill Sommerfeld, who noted that from a software engineering perspective, the weak key rejection case happened so rarely, that there was danger in it being an untested code path. Fortunately RFC 2405 lists this as a SHOULD, and so it's something we can adjust and remove in the next pass. - Ted From owner-ipsec@lists.tislabs.com Tue Jan 25 11:27:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23285; Tue, 25 Jan 2000 11:27:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25018 Tue, 25 Jan 2000 12:56:00 -0500 (EST) Date: Tue, 25 Jan 2000 13:00:42 -0500 Message-Id: <200001251800.NAA18061@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: tytso@mit.edu Cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> <4.2.1.20000120173822.00b476f0@mail.vpnc.org> <38886529.E3D38477@bbn.com> <200001251710.MAA01839@trampoline.thunk.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "tytso" == tytso writes: tytso> Steve Kent wrote: [I tend to agree with this analysis. The tytso> argument for weak key checking was made by folks who don't tytso> understand the cryptographic issues involved, but who are tytso> persistent and loud, e.g., Bill Simpson. Ted T'so (co-chair of tytso> the WG) and I discussed this problem, and tried to explain it tytso> to the list, but were unsuccessful. Another flaw in the tytso> committee process.] tytso> Actually, I think we had gotten agreement to remove the weak tytso> key check, but it never made it into the document edit. So I tytso> believe it was an oversight, and I'd chalk this one up to the tytso> complexity of documents and overtaxed document editors. Other tytso> folks who argued quite strongly for removing the weak key tytso> check included Bill Sommerfeld, who noted that from a software tytso> engineering perspective, the weak key rejection case happened tytso> so rarely, that there was danger in it being an untested code tytso> path. Fortunately RFC 2405 lists this as a SHOULD, and so tytso> it's something we can adjust and remove in the next pass. On the other hand, RFC 2409 says that you MUST do this. And unlike RFC 2405, the rule for deriving keying material is to use the first eight non-weak key bytes. So not only does 2409 require this, but it requires weak key checking in a way that affects the *protocol*! Removing the requirement from that document would make the two sides come to different conclusions in the case that the first 8 bytes of the key are weak. Interestingly enough, the only cipher for which this rule is given is DES, even though there are weak key checks defined for other ciphers. So presumably for the others the rule in 2405 governs instead. (That one can be changed unilaterally without breaking the protocol.) Perhaps a good answer is that the chances of tripping over the issue in 2409 is so low that it's not worth worrying about, and besides it's with DES which should be deprecated... paul From owner-ipsec@lists.tislabs.com Tue Jan 25 12:12:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23842; Tue, 25 Jan 2000 12:12:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25176 Tue, 25 Jan 2000 13:34:14 -0500 (EST) Date: Tue, 25 Jan 2000 10:39:24 -0800 (PST) From: Marc Hasson Message-Id: <200001251839.KAA04903@leo.mentat.com> To: ropereir@cisco.com, bkavsan@ire-ma.com Subject: Re: Clarification proposal for Deflate RFC Cc: ipsec@lists.tislabs.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava wrote: > Roy, all, > > Here are recommended changes to rfc1951 "DEFLATE Compressed Data Format > Specification": I support what Slava has suggested but rather than track down all other usage of rfc 1951 that changing it might effect I'd assume it would be more appropriate to make his changes to the IP Compression working group's own document, RFC 2394. So here's my suggestion. It would appear to me that his changes would fit into section 2, DEFLATE Algorithm Implementation, of RFC 2394 just fine. The current second paragraph in section 2 of RFC 2394: Compression and decompression algorithm details should be followed as outlined in [Deutsch96] or the use of a software library may be preferable. Since IPComp is a stateless protocol, history MUST be cleared between packets when either compressing or decompressing. could be modified to read: Compression and decompression algorithm details should be followed as outlined in [Deutsch96]. Specifically, the compression data elements transmitted MUST be confined to those defined in Section 3 of [Deutsch96]. The use of a software library, such as ZLIB which supports a superset of [Deutsch96], may be an appropriate implementation mechanism. See Appendix A for implementation suggestions for ZLIB. Since IPComp is a stateless protocol, history MUST be cleared between packets when either compressing or decompressing. Slava's Zlib recommendations would go into the new Appendix A. -- Marc -- > > Add the following statement at the very end of section 2, > Compressed representation overview. > > "There must be no additional data sent beyond that described in section > 3, > Detailed specification. Specifically. neither the library header nor the > > Adler32 checksum generated by Zlib must be sent." > > Add a new section "Zlib interface recommendations" > between the existing section 4. Compression algorithm details, and > section > 5. References, as follows: > > 5. Zlib interface recommendations > > The default initialization call to the Zlib implementation of Deflate > produces an unnecessary wrapper consisting of a Zlib specific header and > > checksum. If this publicly available implementation of Deflate is used, > > then it should be initialized in a manner similar to the following: > > returnCode = deflateInit2_( > &stream, > Z_DEFAULT_COMPRESSION, > Z_DEFLATED, > -WINDOW_SIZE, > DEF_MEM_LEVEL, > Z_DEFAULT_STRATEGY, > ZLIB_VERSION, > sizeof(z_stream)); > > The absolute value of the WINDOW_SIZE argument controls the size of the > history buffer used by deflate, in powers of 2 bytes (i.e. WINDOW_SIZE = > 11 > configures a 2048 byte history buffer). Negating this argument will > prevent Zlib from adding the Zlib header or Adler32 checksum. > > Likewise, the initialization of the Zlib decompression implementation > Inflate should be invoked in a manner to the following: > > returnCode = inflateInit2_( > &stream, > -WINDOW_SIZE, > ZLIB_VERSION, > sizeof(z_stream)); > > In this case, WINDOW_SIZE should be 15, permitting the maximum history > buffer of 32768. By setting the argument to -WINDOW_SIZE, or -32768, > Zlib > will be configured not to expect a Zlib header or Adler32 checksum. > > > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-539-4816 > http://www.ire.com > > > > From owner-ipsec@lists.tislabs.com Tue Jan 25 12:30:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24037; Tue, 25 Jan 2000 12:30:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25309 Tue, 25 Jan 2000 14:05:06 -0500 (EST) To: Marc Hasson cc: ropereir@cisco.com, bkavsan@ire-ma.com, ipsec@lists.tislabs.com In-reply-to: marc's message of Tue, 25 Jan 2000 10:39:24 PST. <200001251839.KAA04903@leo.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Clarification proposal for Deflate RFC From: itojun@iijlab.net Date: Wed, 26 Jan 2000 04:08:43 +0900 Message-ID: <376.948827323@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Here are recommended changes to rfc1951 "DEFLATE Compressed Data Format > > Specification": > > returnCode = deflateInit2_( > > &stream, > > Z_DEFAULT_COMPRESSION, > > Z_DEFLATED, > > -WINDOW_SIZE, > > DEF_MEM_LEVEL, > > Z_DEFAULT_STRATEGY, > > ZLIB_VERSION, > > sizeof(z_stream)); > > > > > > returnCode = inflateInit2_( > > &stream, > > -WINDOW_SIZE, > > ZLIB_VERSION, > > sizeof(z_stream)); From what I see in zlib.h, {de,in}flateInit2_() are not really externally visible API. We should be using {de,in}flateInit2() (without the last underbar), with the following arguments: It should also be noted that DEF_MEM_LEVEL is not declared in zlib.h, it seems. itojun returnCode = deflateInit2(&stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, -WINDOW_SIZE, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY); returnCode = inflateInit2(&stream, -WINDOW_SIZE); From owner-ipsec@lists.tislabs.com Tue Jan 25 22:29:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28930; Tue, 25 Jan 2000 22:29:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26935 Tue, 25 Jan 2000 23:47:22 -0500 (EST) From: Allen_Rochkind@3com.com X-Lotus-FromDomain: 3COM To: ipsec@lists.tislabs.com Message-ID: <88256872.001A83D8.00@hqoutbound.ops.3com.com> Date: Tue, 25 Jan 2000 20:52:37 -0800 Subject: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the recent VPN bakeoff, several vendors REQUIRED the peer to send a Certificate Request payload during the IKE main mode exchange (using signature authentication) in order for their system to send the peer its certificate (i.e. no Certificate Request payload received results in no certificate being sent back to the peer in the final main mode exchange). Looking at the ISAKMP spec (Section 3.10) it appears that only one Certificate Authority DER encoded distinguished name (for X.509 certificate type) can appear in the certificate request payload. Normally if the 2 systems in the exchange were in the same security domain governed by a single root CA, one peer would put the distinguished name of that CA's certificate subject in the payload and the other system would then choose to send back a chain of certs rooted on that CA. However, in the case of extranet interaction in which it is possible that a given system might interact with several different security domains (each with its own CA) it is unclear what certificate authority distinguished name should be put in the certificate request payload. E.g. it may be possible that the local system trusts several different roots to handle the diversity of different extranet security domains it wants to deal with. In any given IKE exchange it would not know in advance which certificate authority it should ask in the certificate payload to be the root of the returned certificate requested unless there is some elaborate policy mapping between identities and trusted root CAs at the other end. To maximize interoperability, should one send multiple certificate requests, each corresponding to a CA that is trusted, and hope that the responder will find in one of the certificate request payloads the distinguished name for the root certificate that its end entity certificate is based on? Alternatively ISAKMP says, "If there is no specific certificate authority requested, this field [the Certificate Authority field] SHOULD not be included." Then would it be safer to ensure interoperability to simply send one certificate request always with no "Certificate Authority" field entered in the certificate request payload? If that is so, what good does sending a certificate request payload do? What is the practice of the various vendors that send certificate request payloads or expect other vendors to send them in order to send back their own certificate chains in the IKE exchange? I would thank you for any clarification of this matter. From owner-ipsec@lists.tislabs.com Tue Jan 25 23:06:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02506; Tue, 25 Jan 2000 23:06:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26996 Wed, 26 Jan 2000 00:35:04 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 25 Jan 2000 21:39:14 -0800 (PST) From: Jan Vilhuber To: Allen_Rochkind@3com.com cc: ipsec@lists.tislabs.com Subject: Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability In-Reply-To: <88256872.001A83D8.00@hqoutbound.ops.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 25 Jan 2000 Allen_Rochkind@3com.com wrote: > > > At the recent VPN bakeoff, several vendors REQUIRED the peer to send a > Certificate Request payload during the IKE main mode exchange (using > signature authentication) in order for their system to send the peer its > certificate (i.e. no Certificate Request payload received results in no > certificate being sent back to the peer in the final main mode exchange). Makes sense to me. Certs can be large and I might have cached it the last time I asked you. If I don't ask you to send me one, don't send it. > Looking at the ISAKMP spec (Section 3.10) it appears that only one > Certificate Authority DER encoded distinguished name (for X.509 certificate > type) can appear in the certificate request payload. Normally if the 2 > systems in the exchange were in the same security domain governed by a > single root CA, one peer would put the distinguished name of that CA's > certificate subject in the payload and the other system would then choose > to send back a chain of certs rooted on that CA. Ahm.. not "choose to send back". The rfc says: "The responder to the Certificate Request payload MUST send its certificate, if certificates are supported...". > However, in the case of > extranet interaction in which it is possible that a given system might > interact with several different security domains (each with its own CA) it > is unclear what certificate authority distinguished name should be put in > the certificate request payload. E.g. it may be possible that the local > system trusts several different roots to handle the diversity of different > extranet security domains it wants to deal with. In any given IKE exchange > it would not know in advance which certificate authority it should ask in > the certificate payload to be the root of the returned certificate > requested unless there is some elaborate policy mapping between identities > and trusted root CAs at the other end. > > To maximize interoperability, should one send multiple certificate > requests, each corresponding to a CA that is trusted, and hope that the > responder will find in one of the certificate request payloads the > distinguished name for the root certificate that its end entity certificate > is based on? Yes. The rfc talks about 'Certificate Request payloads', i.e. plural, so I would assume it's perfectly legal to send multiples. We tested with a few vendors in San Diego that did this. > Alternatively ISAKMP says, "If there is no specific > certificate authority requested, this field [the Certificate Authority > field] SHOULD not be included." Then would it be safer to ensure > interoperability to simply send one certificate request always with no > "Certificate Authority" field entered in the certificate request payload? Depends on what you believe is right (see below). > If that is so, what good does sending a certificate request payload do? As was established by consensus at the bakeoff, an empty CERT_REQ payload means "send me any cert at all". See message: issues raised at VPN interoperability workshop, Dan Harkins , Tue, 18 Jan 2000 16:05:44 -0800 (PST) * What does an empty cert request payload mean? "give me a cert; any cert". Personally, I find that a bit hard to believe, since I might send you a certificate from CA FOOBAR, which you've never heard of, so I'm not sure what good an empty CERT_REQ will do you, but that was the consensus. I guess if you are willing to send empty CERT_REQs you are implying that you can handle EVERY possible known CA on the planet (and beyond!). > What is the practice of the various vendors that send certificate request > payloads or expect other vendors to send them in order to send back their > own certificate chains in the IKE exchange? > - If we don't get a CERT_REQ, we won't send a cert. - If we receive multiple cert-requests, we blue-screen. Just kidding: We go through them one by one and the first one we have a cert for, we send it (we might even send multiple, i.e. signature and key exchange, if you asked for both) - If we get an empty CERT_REQ, we won't honor it and fail the exchange (probably not the right thing to do either, in light of the consensus mentioned above). I'll probably change that to send you the first one on my list (for whatever that's worth). Maybe I'll even keep a counter of how many times a certain cert was requested and send you the one that was LEAST requested, just so it doesn't feel left out ;) jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Jan 26 01:12:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09494; Wed, 26 Jan 2000 01:12:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA27607 Wed, 26 Jan 2000 02:47:24 -0500 (EST) Message-ID: <388EA79A.EFE0275A@cyphers.net> Date: Tue, 25 Jan 2000 23:52:10 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jan Vilhuber CC: Allen_Rochkind@3com.com, ipsec@lists.tislabs.com Subject: Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Vilhuber wrote: > As was established by consensus at the bakeoff, an empty CERT_REQ > payload means "send me any cert at all". See message: > > issues raised at VPN interoperability workshop, Dan Harkins > , Tue, 18 Jan 2000 16:05:44 > -0800 (PST) > > * What does an empty cert request payload mean? > > "give me a cert; any cert". > > > Personally, I find that a bit hard to believe, since I might send > you a certificate from CA FOOBAR, which you've never heard of, so > I'm not sure what good an empty CERT_REQ will do you, but that was > the consensus. > > I guess if you are willing to send empty CERT_REQs you are implying > that you can handle EVERY possible known CA on the planet (and > beyond!). Not at all. It could also mean (as it does frequently in our case) that I have 300 valid keys on my keyring and thus 300 possible valid "CAs". Unless our user has specified they want a specific cert/CA for this gateway then any of those is valid. Given the choice of sending 300 cert reqs with DNs (eventually this logic overflows the maximum UDP packet size) or sending one empty one and crossing fingers, the latter seems the clear choice. It all depends on the context. If my goal is opportunistic encryption in a more web-of-trust like model, I'm willing to accept that anybody I have verified as valid has signed the cert. If I'm communicating with the corporate gateway, my goal is to receive certs signed by a specific CA or even a specific cert. > - If we get an empty CERT_REQ, we won't honor it and fail the > exchange >(probably not the right thing to do either, in light of the >consensus mentioned above). I'll probably change that to send you >the first one on my list (for whatever that's worth). Maybe I'll >even keep a counter of how many times a certain cert was requested >and send you the one that was LEAST requested, just so it doesn't >feel left out ;) That must be a recent change. I've been sending empty cert-reqs to Cisco IOS for at least a year on many different IOS versions and have never had a problem exchanging certs. If the two sides are configured correctly, there's little reason to provide the DN. I've never seen an implementation which handled certs and did not properly handle empty cert requests. - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0d21.120 iQA/AwUBOI6njqy7FkvPc+xMEQJP8ACg2d3ndOzHPydrS+/scjSR0BOMqzUAoKuV ITdfi0cD1MWXgqf4HN7R4ILq =XRb1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jan 26 07:55:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26653; Wed, 26 Jan 2000 07:55:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28937 Wed, 26 Jan 2000 09:17:52 -0500 (EST) Message-ID: <388CD3D4.8FC2D14D@attglobal.net> Date: Mon, 24 Jan 2000 17:36:04 -0500 From: Mike Williams X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec Subject: Connected Notification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk According to IKE , the commit bit in the ISAKMP header can be set to extend a Quick Mode by a single message from the Responder to the Initiator to delay use of the SAs created by the Quick Mode. The message will consist of an authenticated hash, using SKEYID_a as the key, of the message ID from the Quick Mode concatenated with a notify payload whose type is set to CONNECTED (16384). Does the CONNECTED notification contain SPI for the newly negotiated SA? If an SA bundle (AH + ESP) is negotiated, is it appropriate to send 2 notify payloads in the 4th message - one with the AH SPI and the other with the ESP SPI? If more than a single notify payload is sent, is HASH(4) constructed using the first or all notify payloads? Any information would be greatly appreciated. Thanks, Mike Williams From owner-ipsec@lists.tislabs.com Wed Jan 26 07:55:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26667; Wed, 26 Jan 2000 07:55:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28955 Wed, 26 Jan 2000 09:18:52 -0500 (EST) Message-ID: <388DDA33.71F97A83@attglobal.net> Date: Tue, 25 Jan 2000 12:15:31 -0500 From: Mike Williams X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPSec Subject: Connected Notify Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk According to IKE , the commit bit in the ISAKMP header can be set to extend a Quick Mode by a single message from the Responder to the Initiator to delay use of the SAs created by the Quick Mode. The message will consist of an authenticated hash, using SKEYID_a as the key, of the message ID from the Quick Mode concatenated with a notify payload whose type is set to CONNECTED (16384). Does the CONNECTED notification contain SPI for the newly negotiated SA? If an SA bundle (AH + ESP) is negotiated, is it appropriate to send 2 notify payloads in the 4th message - one with the AH SPI and the other with the ESP SPI? If more than a single notify payload is sent, is HASH(4) constructed using the first or all notify payloads? Any information would be greatly appreciated. Thanks, Mike Williams From owner-ipsec@lists.tislabs.com Wed Jan 26 07:58:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26717; Wed, 26 Jan 2000 07:58:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28941 Wed, 26 Jan 2000 09:17:57 -0500 (EST) Message-ID: <388E4C99.16E6AB85@vanb.com> Date: Tue, 25 Jan 2000 17:24:02 -0800 From: Audrey Van Belleghem Reply-To: audrey@vanb.com Organization: Van Belleghem Corporation X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: audrey@vanb.com Subject: Re: IPsec/IKE testing at Connectathon? References: <200001181843.KAA19909@kebe.eng.sun.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've received interest from Sun, SSH, IBM and Ennovate. If we get a couple more companies, I think it would be worthwhile to run IPsec/IKE testing at Connectathon. If you are interested, please respond by 1/31/00. Thank you! Audrey Van Belleghem Connectathon Manager Dan McDonald wrote: > I know we just finished a bakeoff in San Diego, but we would like to host > IPSec/IKE testing at Connectathon, the big interoperability event sponsored > by Sun. > > If you're interested, check out the Connectathon web page: > > http://www.connectathon.org/ > > And if you have further questions, reply to Audrey Van Bellhingham > (audrey@vanb.com). > > Thanks, > Dan From owner-ipsec@lists.tislabs.com Wed Jan 26 09:17:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27943; Wed, 26 Jan 2000 09:17:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28919 Wed, 26 Jan 2000 09:16:51 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200001241844.NAA16433@tonga.xedia.com> References: <4.2.1.20000120112510.00bfa600@mail.vpnc.org> <4.2.1.20000120173822.00b476f0@mail.vpnc.org> <38886529.E3D38477@bbn.com> <200001241844.NAA16433@tonga.xedia.com> Date: Tue, 25 Jan 2000 08:04:01 -0500 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Counterpane comments, ASCII version Content-Type: multipart/alternative; boundary="============_-1263317047==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1263317047==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable My annotations are in brackets. Steve ---------- \chapter*{Executive summary} IPsec is a set of protocols that provides communication security for compute= rs using IP-based communication networks. It provides authentication and confidentiality services on a packet level. To support the IPsec=20 security, a key management protocol called ISAKMP is used. ISAKMP uses public-key cryptograp= hic techniques to set up keys between the different parties to be used with IPse= c. Both IPsec and ISAKMP are too complex. [a protocol is too complex only relat= ive to a specified set of requirements that are satisfied by a simpler protocol.= To substantiate this observation, one ought to define the requirements that one believes the protocol is trying top satisfy, and then offer a simpler protocol.] This high complexity leads to errors. We have found=20 security flaws in both IPsec and ISAKMP, and expect that there are many more. We expect=20 any actual implementation to contain many more errors, some of which will cause securit= y weaknesses. These protocols give the impression of having been designed by a committee: they try to be everything for everybody at the cost of complexity= =2E =46or normal standards, that is bad enough; for security systems, it is catastrophic. In our opinion, the complexity of both IPsec and ISAKMP can be reduced by a large factor without a significant loss of functionality. IPsec is in better shape than ISAKMP. The description and definitions are reasonably clear. A careful implementation of IPsec can achieve a good level= of security. Unfortunately, IPsec by itself is not a very useful=20 protocol. Use on a large scale requires the key management functions of ISAKMP. [while I=20 would tend to agree with this observation, I should note that a non-trivial=20 number of IPsec implementations, used in constrained contexts, are manually keyed.] ISAKMP is currently not in a suitable state for implementation. Major work w= ill be required to get it to that point. There are many security-critical=20 errors, as well as many unnecessary cross-dependencies within the protocol. These shoul= d all be eliminated before a new evaluation is done. Based on our analysis, we recommend that IPsec and ISAKMP not be used for confidential information. At the moment we cannot recommend a direct alternative. Some applications might be able to use SSL=20 \cite{SSLv3Nov96}, which in our opinion is a much better protocol that provides a much higher level o= f security when used appropriately. \tableofcontents \chapter{Introduction} At the request of NSA, Counterpane has conducted a security review of the IP= sec and ISAKMP security protocols. This evaluation is based on RFCs 2401--2411 and RFC 2451 \cite{RFC2401,RFC2402,RFC2403,RFC2404,RFC2405,RFC2406,RFC2407,RFC2408,=20 RFC2409,RF C2410,RFC2411,RFC2451}. The Oakley protocol \cite{RFC2412} is only an informational RFC; it is not part of the standard and is not used in=20 ISAKMP. RFC documents are available from {\tt ftp:ftp.isi.edu\slash in-notes\slash rfc.txt}. As \cite{RFC2401} states: ``The suite of IPsec protocols and associated defa= ult algorithms are designed to provide high quality security for Internet traffi= c. However, the security offered by use of these protocols ultimately depends o= n the quality of the their implementation, which is outside the scope of this = set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is onl= y one part of an overall system security architecture.'' This evaluation only deals with the IPsec and ISAKMP specifications and is not directly concerned with any of the other factors. However, we do comment on aspects of the specifications that affect other security factors. IPsec and ISAKMP are highly complex systems. Unfortunately, we cannot give a sufficiently detailed description of these systems in this document=20 to allow the reader to understand our comments without being familiar with IPsec and ISAK= MP. Our comments frequently refer to specific places in the RFC documents for ea= se of reference. The rest of this report is structured as follows. Chapter~\ref{chap:general} gives some general comments. Chapter~\ref{chap:bulk} discusses the IPsec protocols that handle bulk data. Chapter~\ref{chap:ISAKMP} discusses the ISA= KMP generic definitions. Chapter~\ref{chap:IPsecDOI} talks about the=20 IPsec Domain of Interpretation which gives more details on how the generic ISAKMP structure applies to the IPsec protocols. Finally, chapter~\ref{chap:IKE} discusses th= e IKE protocol that is the default key management protocol used with ISAKMP. \chapter{General comments}\label{chap:general} \section{Complexity} Complexity is the biggest enemy of security. This might seem an odd=20 statement in the light of the many fielded systems that exhibit critical security failure= s for very simple reasons. It is true nonetheless. The simple failures are sim= ple to avoid, and often simple to fix. The problem is not that we do not=20 know how to solve them; it is that this knowledge is often not applied.=20 Complexity, however, is a different beast because we do not really know how to handle it. Designing any software system is always a matter of weighing various requirements. These include functionality, efficiency, political acceptabili= ty, security, backward compatibility, deadlines, flexibility, ease of use, and m= any more. The unspoken requirement is often the complexity. If the system gets t= oo complex, it becomes too difficult, and therefore too expensive, to make. As fulfilling more of the requirements usually involves a more complex=20 design, many systems end up with a design that is as complex as the designers and implementors can reasonably handle. Virtually all software is developed using a try-and-fix methodology. Small pieces are implemented, tested, fixed, and tested again.\footnote{Usually several iterations are required.} Several of these small pieces are combined into a larger module, and this module is tested, fixed, and tested again. Th= e end result is software that more or less functions as expected, although we = are all familiar with the high frequency of functional failures of=20 software systems. This process of making fairly complex systems and implementing them with a t= ry- and-fix methodology has a devastating effect on the security. The=20 central reason is that you cannot test for security. Therefore, security bugs are not detec= ted during the development process in the same way that functional bugs=20 are. Suppose a reasonably sized program is developed without any testing at all during development and quality control. We feel confident in stating that the resul= t will be a completely useless program; most likely it will not perform=20 any of the desired functions correctly. Yet this is exactly what we get from the try-an= d- fix methodology when we look at security. The only reasonable way to ``test'' the security of a security product is to perform security reviews on it.\footnote{A cracking contest can be seen as a cheap way of getting other people to do a security analysis. The big problem= is interpreting the results. If the prize is not claimed, it does not imply tha= t any competent analysis was done and came up empty.} A security review is a manual process; it is relatively expensive in terms of time and effort and i= t will never be able to show that the product is in fact secure. [this seems t= o ignore the approaches usually employed for high assurance system design and implementation , i.e., careful design and review coupled with rigid developm= ent procedures, all prior to testing.] The more complex the system is, the harder a security evaluation=20 becomes. A more complex system will have more security-related errors in the specification, design, and implementation. We claim that the number of errors and=20 difficulty of the evaluation are not linear functions of the complexity, but in=20 fact grow much faster. =46or the sake of simplicity, let us assume the system has $n$ different opt= ions, each with two possible choices.\footnote{We use $n$ as the measure of the complexity. This seems reasonable, as the length of the system=20 specification and the implementation is proportional to $n$.} Then there are $n(n-1)/2 =3D O(n= ^2)$ different pairs of options that could interact in unexpected ways, and $2^n$ different configurations altogether. Each possible interaction can lead to a security weakness, and the number of possible complex interactions that invo= lve several options is huge. As each interaction can produce a security=20 weakness, we expect that the number of actual security weaknesses grows very rapidly with increasing complexity. The same holds for the security evaluation. For a system with a moderate num= ber of options, checking all the interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thus the difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknesses = and a more difficult security analysis unavoidably results in insecure systems. In actual systems, the situation is not quite so bad; there are often option= s that are ``orthogonal'' in that they have no relation or interaction with ea= ch other. This occurs, for example, if the options are on different layers in t= he communication system, and the layers are separated by a well-defined interfa= ce that does not ``show'' the options on either side. For this very reason,= such a separation of a system into relatively independent modules with clearly defi= ned interfaces is a hallmark of good design. Good modularization can dramaticall= y reduce the ``effective'' complexity of a system without the need to eliminat= e important features. Options within a single module can of course still have interactions that need to be analyzed, so the number of options per module should be minimized. Modularization works well when used properly, but most actual systems still include cross-dependencies where options in different modules do affect each other. A more complex system loses on all fronts. It contains more weaknesses to st= art with, it is much harder to analyze, and it is much harder to implement witho= ut introducing security-critical errors in the implementation. Complexity not only makes it virtually impossible to create a secure implementation, it also makes the system extremely hard to manage. The peopl= e running the actual system typically do not have a thorough understanding of = the security issues involved. Configuration options should therefore be kept to = a minimum, and the options should provide a very simple model to the=20 user. Complex combinations of options are very likely to be configured erroneously, which results in a loss of security. The stories in \cite{TheCodebreakers} and \cite{A:WhyFail} illustrate how management of complex systems is often the weakest link. Both IPsec and ISAKMP are too complex to be secure. The design obviously tri= es to support many different situations with different options. We feel very strongly that the resulting system is well beyond the level of complexity th= at can be implemented securely with current methodologies. \section{Stating what is achieved} A security analysis evaluates the security aspects of a system. To be able t= o give any sensible answer, it should be clear what properties the system clai= ms to have. That is, the system documentation should clearly state what securit= y properties are achieved. This can be seen as the functional=20 specification of the security properties. This applies not only to the entire system, but=20 also to the individual modules. At each module or function, the security properties shou= ld be specified. A good comparison is the testing of a product. The testing verifies that the product performs according to the functional specifications. Without specifications, the testers might have some interesting comments, but they c= an never give a real answer. Without security specifications, the first task of the security analysis is = to create descriptions of the security properties achieved, based on the percei= ved intentions of the system designer. The subsequent evaluation might then turn= up problems of the form ``this function does not achieve the properties that we think it should have.'' The obvious answer will be: ``but that is not the properties that I designed it to have.'' Very quickly the discussion moves a= way from the actual security into what was meant. The overall result is a securi= ty evaluation that might point out some potential weaknesses, but that will har= dly help in improving the security. The IPsec and ISAKMP protocols do not specify clearly which security propert= ies they claim to achieve. [RFCs 2401, 2402, and 2406 clearly state the security services offered by the AH and ESP protocols.] The same holds for the module= s and functions. [modules are not specified by these standards; they are implementation artifacts.] We recommend that each function, module,=20 and protocol be extended to include clear specifications regarding the security-related functionality they achieve. We feel that unless this is done, it will not be possible to perform an adequate security evaluation on a system of this complexity. \chapter{Bulk data handling}\label{chap:bulk} In this chapter we discuss the methods used to handle the encryption and authentication of the bulk data, as specified in \cite{RFC2401,RFC2402,RFC2403,RFC2404,RFC2405,RFC2406,RFC2451,RFC2410,RFC241= 1}. Together these documents specify the IPsec protocol. They specify the actual encryption and authentication of packets, assuming that symmetric keys have already been exchanged. We refer the reader to \cite{RFC2401} sections 1--4.= 2 for an overview of this part of IPsec and the relevant terminology. \section{Functionality} IPsec is capable of providing authentication and confidentiality services on= a packet level. The security configuration of an IPsec implementation is done centrally, presumably by the system administrator. [In some environments, a single administrator might control the configuration of each IPsec implementation, or each user might have some control over it. The latter wo= uld tend to be characterized as a distributed management paradigm, not a central one. Also, two IPsec peers communicate ONLY if both agree on the security parameters for the SA, i.e., there is suitable overlap in the SPDs. In that sense too, security configuration is distributed.] IPsec is very suitable for creating a VPN over the Internet, improved securi= ty for dial-in connections to portables, restricting access to parts of a netwo= rk, etc. These are very much network-level functions. IPsec by itself does not supply application-level security. Authentication links the packet to the security gateway of the originating network, the originating host, or possib= ly the originating user, but not to the application in question or the data the application was handling when it sent the packet. [true, but for many applications, application layer security is not needed, and its implementati= on might well be accorded less assurance than the network layer security provid= ed by IPsec. This paragraph seems to suggest that there is some important benef= it to linking data to an application, through an application-specific security mechanism. There are good examples of where this is true, e.g., e-mail and directories. However, unless there are application-specific security semanti= cs that cannot be captured by use of an application security protocol, your own arguments about simplicity, as well as a number of arguments re=20 assurance, argue against proliferation of application security protocols.] The IPsec functionality can significantly increase the security of the netwo= rk. It is not a panacea for all security problems, and applications that require security services will typically have to use other security systems in addit= ion to IPsec. [I might disagree with the term "typically" here. A lot=20 depends on the application, where IPsec is implemented, etc.] \section{Complexity}\label{sec:complexity} Our biggest criticism is that IPsec is too complex. There are too many optio= ns that achieve the same or similar properties. [if they were completely=20 equivalent this would be a good basis for simplifying IPsec. However, there are subtle differences that have resulted in the proliferation of options you address below.] \subsection{Options} IPsec suffers from an abundance of options. For example, two hosts that want= to authenticate IP packets can use four different modes: transport/AH, tunnel/A= H, transport/ESP with NULL encryption, and tunnel/ESP with NULL encryption. The differences between these options, both in functionality and performance, ar= e minor. In particular, the following options seem to create a great deal of needless complexity: \begin{enumerate} \item There are two modes that can be used: transport mode and tunnel mode. = In transport mode, the IP header of the packet is left untouched. AH authentica= tes both the IP header and the packet payload. ESP encrypts and authenticates th= e payload, but not the header. The lack of header authentication in transport/= ESP is a real weakness, as it allows various manipulations to be performed. In tunnel mode, the full original IP packet (including headers) is used as the payload in a new IP packet with new headers. The same AH or ESP functions ar= e used. As the original header is now included in the ESP authentication, the transport/ESP authentication weakness no longer exists. Transport mode provides a subset of the functionality of tunnel mode. The on= ly advantage that we can see to transport mode is that it uses a somewhat small= er bandwidth. However, the tunnel mode could be extended in a straightforward w= ay with a specialized header-compression scheme that we will explain shortly. T= his would achieve virtually the same performance as transport mode without introducing an entirely new mode. We therefore recommend that the=20 transport mode be eliminated. [transport mode and tunnel mode address fundamentally differe= nt requirements, from a networking point of view. When security gateways are involved, the use of tunnel mode is an absolute requirement, whereas it is a minor (and rarely used) feature for communications between end systems. A proposal to make all traffic tunnel mode, and to try to offset the added overhead through compression, seems to ignore the IPCOMP facility that is already available to IPsec implementations. Today, transport mode is used primarily to carry L2TP traffic, although this is primarily an efficiency issue.] \item There are two protocols: AH and ESP. AH provides authentication, and E= SP provides encryption, authentication, or both. In transport mode, AH provides= a stronger authentication than ESP can provide, as it also authenticates the I= P header. One of the standard modes of operation would seem to be to use both = AH and ESP in transport mode. [although this mode is required to be supported, = it seems to be rarely used today. A plausible, near-term use for AH is to provi= de integrity and authenticity for IPsec traffic between an end system and a fir= st- hop intermediary. For example, AH can be used between a host inside an encl= ave and a security gateway at the perimeter, to allow the SG to control=20 what traffic leaves the enclave, without granting the SG access to plaintext traffic. Thi= s, and similar concatenated SA examples, motivate retention of AH. One could achieve a similar effect with (authentication-only) ESP tunnels, but with increased bandwidth and processing overhead.] In tunnel mode, the=20 authentication that ESP provides is good enough (it includes the IP header), and AH is typically not combined with ESP \cite[section 4.5]{RFC2401}. [the example ab= ove shows why one might wish to use AH for the outer header, but most likely wit= h ESP in transport mode.] (Implementations are not required to support nested tunnels that would allow ESP and AH to both be used.) The AH protocol \cite{RFC2402} authenticates the IP headers of the=20 lower layers. [AH authenticates the IP header at the SAME layer, in many respects. AH was originally described as an IP (v4) option. In IPv6, AH is viewed as=20 part of the AH header, and may appear before other header extensions (see section=20 4.1 of RFC 2401). I agree that AH represents ugly layering, but it's not as bad as you suggest here.] This creates all kind of problems, as some header fields chan= ge in transit. As a result, the AH protocol needs to be aware of all data forma= ts used at lower layers so that these mutable fields can be avoided. [this is a= n inaccurate characterization, especially given the status of AH re IPv6. Don'= t think of AH as a transport protocol. It isn't.] This is a very ugly construction, and one that will create more problems when future extensions = to the IP protocol are made that create new fields that the AH protocol is not aware of. [RFC 2402 explains how to deal with new IP header fields in v6 (se= e section 3.3.3.1.2.2). The existence of a mutability flag in such extensions makes processing relatively straightforward.] Also, as some header fields ar= e not authenticated, the receiving application still cannot rely on the entire packet. To fully understand the authentication provided by AH, an applicatio= n needs to take into account the same complex IP header parsing rules that AH uses. The complex definition of the functionality that AH provides can easil= y lead to security-relevant errors. The tunnel/ESP authentication avoids this problem, but uses more=20 bandwidth. [but it does not provide exactly the same features, as noted above, so the alternative is not quite equivalent.] The extra bandwidth requirement can be reduced by a simple specialized compression scheme: for some suitably=20 chosen set of IP header fields $X$, a single bit in the ESP header indicates whether th= e $X$ fields in the inner IP header are identical to the corresponding fields = in the outer header.\footnote{A trivial generalization is to have several flag bits, each controlling a set of IP header fields.} The fields in question ar= e then removed to reduce the payload size. This compression should be applied after computing the authentication but before any encryption. The=20 authentication is thus still computed on the entire original packet. The receiver=20 reconstitutes the original packet using the outer header fields, and verifies the authentication. A suitable choice of the set of header fields $X$ allows tunnel/ESP to achieve virtually the same low message expansion as transport/= AH. We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality. [counter examples provided above suggest that this claim is a bit overstated.] \item The standard defines two categories of machines: hosts and security gateways. Hosts can use transport mode, but security gateways must always us= e tunnel mode. Eliminating transport mode would also allow this distinction to= be eliminated. Various computers could of course still function as hosts or security gateways, but these different uses would no longer affect=20 the protocol. \item The ESP protocol allows the payload to be encrypted without being authenticated. In virtually all cases, encryption without authentication is = not useful. The only situation in which it makes sense not to use authentication= in the ESP protocol is when the authentication is provided by a subsequent application of the AH protocol (as is done in transport mode because ESP authentication in transport mode is not strong enough). [this is one example= of when one might not need authentication with ESP, but it is not the only one.= In general, if there is a higher layer integrity and/or authentication function= in place, providing integrity/authentication in IPsec is redundant, both in ter= ms of space and processing. The authentication field for ESP or AH is 12=20 bytes. For applications where packet sizes are quite small, and for some=20 environments where packet size is of critical importance, e.g., packet voice in a wireless environment, ESP w/o authentication may be appropriate. This is especially t= rue if the application protocol embodies an authentication mechanism. This might happen if the application protocol wants to offer uniform protection irrespective of the lower layers. Admittedly, this might also cause the application to offer confidentiality as well, but depending on the applicati= on, the choices of what security services are being offered may vary.] Without t= he transport mode to worry about, ESP should always provide its own=20 authentication. We recommend that ESP authentication always be used, and only=20 encryption be made optional. [the question of authentication as an intrinsic part of ESP is independent of mode, i.e., whether one choose to provide authentication as a part of ESP is not determined by the choice of transport vs. tunnel mode.] \end{enumerate} We can thus remove three of the four operational modes without any significa= nt loss of functionality. [sorry, can't agree, given the counter examples above= =2E] \subsection{Undesirable options} There are existing combinations of options that are undesirable. These pose = a problem when non-experts have to configure an IPsec installation.=20 Given the fact that experts are rare and usually have better things to do, most IPsec installations will be configured by non-experts. [yes, we were aware of this concern. However, there is always a tradeoff between adopting the "we know what's best for you" approach, vs. the "you can screw it up if you want to approach." We opted for a point somewhere along this spectrum, but=20 not at either end.] \begin{enumerate} \item In transport mode, use of ESP provides authentication of the=20 payload only. The authentication excludes the IP headers of the packet. The result is a da= ta stream that is advertised as ``authenticated'' for which critical pieces of information (such as the source and destination IP number) are not authenticated. Unless the system administrator is intimately familiar with t= he different forms of authentication used by IPsec, it is quite likely that the administrator will assume that the authentication protects the entire packet= =2E The combination of transport mode and the ESP protocol (without the=20 AH protocol) should therefore not be allowed. [The IP source and destination address are covered by the TCP checksum, which is covered by the ESP integrity check, so this does limit (a tiny bit) the ability to change these values without detection. A more significant observation is that transport mode IPsec SAs w= ill probably always use source and/or destination IP addresses as part of the selector set. In such cases, tampering with the either address will result= in a failed authentication check.] \item The standard allows ESP to be used with the NULL encryption, such that= it provides only authentication. The authentication provided by ESP in transpor= t mode is less functional than the authentication provided by AH, at a similar cost. If transport mode is retained, either the EPS ESP=20 authentication should be extended or the use of ESP with only authentication should be forbidden and replaced by the use of AH. [ESP authentication is more efficient to=20 compute than AH, because of the selective IP header coverage provided by AH. Thus there = is good reason to allow authentication-only ESP as an alternative to AH.=20 This point was debated by the group and, with implementation experience, vendors came t= o agree that this is true.] \item The ESP protocol can provide encryption without authentication. This d= oes not make much sense in an application. It protects the application against passive eavesdroppers, but provides no protection against active attacks tha= t are often far more devastating. Again, this mode can lure non-expert users i= nto using an unsafe configuration that they think is secure. Encryption without authentication should be forbidden. [as noted above, there are examples wher= e this feature set for ESP is attractive.] \end{enumerate} \subsection{Orthogonality} IPsec also suffers from a lack of orthogonality. The AH and ESP=20 protocols can be used together, but should only be used in one particular order. In transport mode, ESP by itself provides only partial authentication of the IP packet, a= nd using AH too is advisable. [not in most cases, as noted above.] In tunnel mo= de the ESP protocol authenticates the inner headers, so use of AH is no longer required. These interdependencies between the choices demonstrate that these options are not independent of each other. [true, but who says that this is = a critical criteria? TCP and IP are not orthogonal either, e.g., note the TCP checksum covering parts of the IP header.] \subsection{Compatibility} The IPsec protocols are also hampered by the compatibility requirements. A simple problem is the TOS field in the IP header \cite[p.\ 10]{RFC2402}. Although this is supposed to be unchanged during the transmission of a packe= t (according to the IP specifications), some routers are known to change this field. IPsec chose to exclude the TOS field from the authentication provided= by the AH protocol to avoid errors introduced by such rogue routers. The result= is that, in transport/AH packets that have an authenticated header, the TOS fie= ld is not authenticated. This is clearly unexpected from the application point = of view, which might want to rely on the correct value of the TOS field. This problem does not occur in tunnel mode. [it is unfortunate that cisco chose t= o not follow the specs here, and in several other places. I agree that an unenlightened system administrator might be surprised in this case. But, in practice, the effect is minimal. Your example cites transport mode,=20 which means that the TOS bits are being acted upon by the end system. If end systems rea= lly paid attention to these bits in the first place, cisco would not have been a= ble to corrupt them with impunity! The reason that these bits are being re-used = by the ECN folks is because hosts have never made use of them. Still, going forward, one should pay attention to this vulnerability.] A more complex compatibility problem is the interaction between fragmentatio= n and IPsec \cite[appendix B]{RFC2401}. This is a complex area, but a typical IPsec implementation has to perform specialized processing to facilitate the proper behavior of higher-level protocols in relation to=20 fragmentation. Strictly speaking, fragmentation is part of the communication layer below the IPsec layer, and in an ideal world it would be transparent to IPsec. Compatibility requirements with existing protocols (such as TCP) force IPsec to explicitly handle fragmentation issues, which adds significantly to the overall=20 complexity. Unfortunately, there does not seem to be an elegant solution to this problem= =2E [The requirement here is the same that arises whenever an intermediate syste= m adds info to a packet, or when a smaller MTU intermediate system is traverse= d. IPsec in an SG is doing what a router along a path would do if the "other si= de" network were smaller. IPsec in a host is doing what the NIC would do if the = LAN MTU changed. The real complexity arises when we wish to do this optimally,= at a security gateway or a BITS or BITW implementation, in cases where different = SAs use different combinations of AH and ESP, or different algorithms, etc.] \subsection{Conclusion} The overall result is that IPsec bulk data handing is overly complex. In our opinion it is possible to define an equivalent system that is far less compl= ex. \section{Order of operations} \subsection{Introduction} When both encryption and authentication are provided, IPsec performs the encryption first, and authenticates the ciphertext. In our opinion, this is = the wrong order. Going by the ``Horton principle'' \cite{WS:SSL30}, the protocol should authenticate what was meant, not what was said. The ``meaning'' of th= e ciphertext still depends on the decryption key used. Authentication should t= hus be applied to the plaintext (as it is in SSL \cite{SSLv3Nov96}), and not to = the ciphertext.[The order of processing is intentional. It is explicitly=20 designed to allow a receiver to discard a packet as quickly as possible, in the=20 event of DoS attacks, as you acknowledge below. The suggestion that this concern=20 be addressed by the addition of a secondary MAC seems to violate the spirit of simplicity that this document espouses so strongly, and the specific proposed fix is no= t strong enough to warrant its incorporation. Moreover, this ordering allows parallel processing at a receiver, as a means of increasing throughput and reducing delay.] This does not always lead to a direct security problem. In the case of the E= SP protocol, the encryption key and authentication key are part of a=20 single ESP key in the SA. A successful authentication shows that the packet was sent=20 by someone who knew the authentication key. The recipient trusts the sender to=20 encrypt that packet with the other half of the ESP key, so that the decrypted data=20 is in fact the same as the original data that was sent. The exact argument why this is secure gets to be very complicated, and requires special assumptions about t= he key agreement protocol. For example, suppose an attacker can manipulate the = key agreement protocol used to set up the SA in such a way that the two parties = get an agreement on the authentication key but a disagreement on the=20 encryption key. When this is done, the data transmitted will be authenticated successfully, = but decryption takes place with a different key than encryption, and all the plaintext data is still garbled. [The fundamental assumption is that an ESP = SA that employs both encryption and an HMAC will have the keys bound together, irrespective of the means by which they are generated. This assumption proba= bly could be better stated in the RFCs.] In other situations, the wrong order does lead to direct security weaknesses= =2E \subsection{An attack on IPsec} Suppose two hosts have a manually keyed transport-mode AH-protocol SA, which= we will call SAah. Due to the manual keying, the AH protocol does not provide a= ny replay protection. These two hosts now negotiate a transport-mode encryption= - only ESP SA (which we will call SAesp1) and use this to send information usi= ng both SAesp1 and SAah. The application can expect to get confidentiality and authentication on this channel, but no replay protection. When the immediate interaction is finished, SAesp1 is deleted. A few hours later, the two hosts again negotiate a transport-mode encryption-only ESP SA (SAesp2), and the receiver chooses the same SPI value for SAesp2 as was used for SAesp1. Again= , data is transmitted using both SAesp2 and SAah. The attacker now introduces = one of the packets from the first exchange. This packet was encrypted using SAes= p1 and authenticated using SAah. The receiver checks the authentication and fin= ds it valid. (As replay protection is not enabled, the sequence number field is ignored.) The receiver then proceeds to decrypt the packet using SAesp2, whi= ch presumably has a different decryption key then SAesp1. The end result is tha= t the receiver accepts the packet as valid, decrypts it with the wrong key, an= d presents the garbled data to the application. Clearly, the authentication property has been violated. [this attack is not a criticism of the=20 choice of ESP operation ordering, but rather the notion of applying AH and ESP (encryption only) in a particular order, as allowed by RFC 2401. The specific=20 combination of keying operations described here, though not prohibited by 2401, does not se= em likely to occur in practice. Specifically, if an IPsec implementation suppor= ts automated key management, as described above for the ESP SAs, then it is hig= hly unlikely that the AH SA would be manually keyed. The push to retain manual keying as a base facility for IPsec is waning, and most=20 implementations have IKE available. Under these circumstances, this vulnerability is unlikely to be realized.] \subsection{Other considerations} Doing the encryption first and authentication later allows the recipient to discard packets with erroneous authentication faster, without the overhead o= f the decryption. This helps the computer cope with denial-of-service attacks = in which a large number of fake packets eat up a lot of CPU time. We question whether this would be the preferred mode of attack against a TCP/IP-enabled computer. If this property is really important, a 1- or 2-byte MAC (Message Authentication Code) on the ciphertext could be added. The MAC code allows t= he recipient to rapidly discard virtually all bogus packets at the cost of an additional MAC computation per packet. [a one or two byte MAC=20 provides so little protection that this does not seem to be an attractive counter-proposal. Als= o, as noted above, it adds complexity =8A] \subsection{Conclusion} The ordering of encryption and authentication in IPsec is wrong. Authenticat= ion should be applied to the plaintext of the payload, and encryption should be applied after that. \section{Security Associations} A Security Association (SA) is a simplex ``connection' that affords security services to the traffic carried by it \cite[section 4]{RFC2401}. The two computers on either side of the SA store the mode, protocol, algorithms, and keys used in the SA. Each SA is used only in one direction; for bidirectiona= l communications two SAs are required. Each SA implements a single mode and protocol; if two protocols (such as AH and ESP) are to be applied to a singl= e packet, two SAs are required. Most of our aforementioned comments also affect the SA system; the use of tw= o modes and two protocols make the SA system more complex than necessary. There are very few (if any) situations in which a computer sends an=20 IP packet to a host, but no reply is ever sent. [we have a growing number of apps where t= his functionality may be appropriate. For example, broadcast packet video feeds = and secure time feeds are unidirectional.] There are also very few situations in which the traffic in one direction needs to be secured, but the traffic in t= he other direction does not need to be secured. It therefore seems that in virtually all practical situations, SAs occur in pairs to allow bidirectiona= l secured communications. In fact, the IKE protocol negotiates SAs in pairs. [= IKE has not always been well coordinated with IPsec, unfortunately. This is why = we have to have null encryption and null authentication algorithms. So, I don't think one should cite IKE behavior as a basis for making SAs bi-directional.= I agree that the vast majority of examples that we see now are full=20 duplex, but we have example where this may not apply, as noted above.] This would suggest that it is more logical to make an SA a bidirectional ``connection'' between two machines. This would halve the number of SAs in t= he overall system. It would also avoid asymmetric security=20 configurations, which we think are undesirable (see section~\ref{sec:SPD}). [The SPI that is used as = a primary de-multiplexing value, must be chosen locally, by the receiver, so having bi-directional SAs probably won't change the size of the SAD substantially. Specifically, how do you envision that a switch to bi- directionality would simplify implementations?] \section{Security policies}\label{sec:SPD} The security policies are stored in the SPD (Security Policy Database). For every packet that is to be sent out, the SPD is checked to find how the pack= et is to be processed. The SPD can specify three actions: discard the packet, l= et the packet bypass IPsec processing, or apply IPsec processing. In the=20 last case, the SPD also specifies which SAs should be used (if suitable SAs have alread= y been set up) or specifies with what parameters new SAs should be set up to b= e used. The SPD seems to be a very flexible control mechanism that allows a very fin= e- grained control over the security processing of each packet. Packets are classified according to a large number of selectors, and the SPD can match s= ome or all selectors to determine the appropriate action. Depending on=20 the SPD, this can result in either all traffic between two computers being carried=20 on a single SA, or a separate SA being used for each application, or even each TCP connection. Such a very fine granularity has disadvantages. There is a significantly increased overhead in setting up the required SAs, and more traffic analysis information is made available to the attacker. At=20 the same time we do not see any need for such a fine-grained control. [a lot of customers = for IPsec products disagree!] The SPD should specify whether a packet should be discarded, should bypass any IPsec processing, requires authentication, or requires authentication and encryption. Whether several packets are combined= on the same SA is not important. [yes it is. By allowing an administrator the ability to select the granularity of protection, one can control the level o= f partial traffic flow confidentiality offered between security gateways. Also= , fine-grained access control allows an admin to allow some forms of connectio= ns through the gateway, while rejecting others. Access control is often the primary, underlying motivation for using IPsec. A number of attacks become possible if one cannot tightly bind the authentication provided by IPsec to = the access control decision. Also, given the computational costs of SA=20 establishment via IKE, it is important to allow an administrator to select the granularity= of SAs.] The same holds for the exact choice of cryptographic algorithm: any go= od algorithm will do. There are two reasons for this. First of all, nobody ever attacks a system by cryptanalysis. Instead, attacks are made on the users, implementation, management, etc. Any reasonable cryptographic algorithm will provide adequate protection. The second reason is that there are very effici= ent and secure algorithms available. Two machines should negotiate the strongest algorithm that they are allowed. There is no reason to select individual algorithms on an application-by-application basis. [if one were to employ ES= P without authentication, because a specific higher layer protocol provided it= s own authentication, and maybe because the application employed FEC, then one might well imagine using different encryption algorithms, or different modes (e.g., block vs. stream) for different SAs. while I agree that the focus on algorithm agility may be overstated, it does allow communicating parties to select a higher quality algorithm, relative to the mandated default, if they both support that algorithm.] In our opinion, management of the IPsec protocols can be simplified by letti= ng the SPD contain policies formulated at such a higher level. As we argued in section~\ref{sec:complexity}, simplification will strengthen the actual syst= em. [examples provided above illustrate why fine-grained access control is important.] It would be nice if the same high-level approach could be done in relation t= o the choice of SA end-points. As there currently does not seem to be a reliab= le automatic method of detecting IPsec-enabled security gateways, we do not see= a practical alternative to manual configuration of these parameters. It is questionable whether automatic detection of IPsec-enabled gateways is possib= le at all. Without some initial knowledge of the other side, any detection and negotiation algorithm can be subverted by an active attacker. [the authors identify a good problem, but it is hardly an unsolvable one. A proposal was = put forth (by Bob Moscowtiz, over a year ago) to include records in the DNS analogous to MX records. When one tried to establish an SA to a host=20 "behind" an SG, fetching this record would direct the initiator to an appropriate SG. T= his solves the SG discovery problem. Other approaches have been put forth in the more recent BBN work on security policy management, which forms the basis= for a new IETF WG, chaired by Luis Sanchez. The fact that none of the approaches h= as been deployed says more about the priorities of IPsec vendors and=20 early adopters than about the intractability of the problem. The other part of the problem = is verifying that an SG is authorized to represent the SA target. Here=20 too, various approaches have been described on the IPsec mailing list.] \section{General comments} This section contains general comments that came up during our evaluation of IPsec. \begin{enumerate} \item In \cite[p.\ 22]{RFC2401}, several fields in the SAD are required for = all implementations, but only used in some of them. It does not make sense to require the presence of fields within an implementation. Only the external behavior of the system should be standardized. [the SAD defined in 2401 is nominal, as the text explains. An implementation is not required to implemen= t these fields, but must exhibit behavior consistent with the presence of thes= e fields. We were unable to specify external behavior without reference to a construct of this sort. The SPD has the same property.] \item According to \cite[p.\ 23]{RFC2401}, an SA can be either for transport mode, tunnel mode, or ``wildcard,'' in which case the sending application ca= n choose the mode on a packet-by-packet basis. Much of the rest of the text do= es not seem to take this possibility into account. It also appears to us to be needless complexity that will hardly every be used, and is never a=20 necessity. We have already argued that transport mode should be eliminated, which=20 implies that this option is removed too. If transport mode is to be retained, we would certainly get rid of this option. [I agree, but at least one knowledgeable W= G member was quite adamant about this. So, chalk it up to the committee proces= s!] \item IPsec does not allow replay protection on an SA that was=20 established using manual key management techniques. This is a strange requirement. We=20 realize that the replay protection limits the number of packets that can be transmitted w= ith the SA to $2^{32}-1$. Still, there are applications that have a low data rat= e where replay protection is important and manual keying is the easiest soluti= on. [elsewhere this critique argues for not presenting options in a standard tha= t can be misconfigured. Yet here, the authors make an argument for just such a= n option! The WG decided that there was too great a chance that a manually key= ed SA would fail to maintain counter state across key lifetime and thus made a value judgement to ban anti-replay in this context.] \item \cite[section 5.2.1, point 3]{RFC2401} suggests that an=20 implementation can find the matching SPD entry for a packet using back-pointers from the SAD entries. In general this will not work correctly. Suppose the SPD contains t= wo rules: the first one outlaws all packets to port $X$, and the second one all= ows all incoming packets that have been authenticated. An SA is set up for this second rule. The sender now sends a packet on this SA addressed to port $X$. This packet should be refused as it matches the first SPD rule. However, the backpointer from the SA points to the second rule in the SPD, which allows t= he packet. This shows that back-pointers from the SA do not always point to the appropriate rule, and that this is not a proper method of finding the releva= nt SPD entry. [this is point #3 and is applied only after points #1 and #2. Sin= ce point #1 calls for a liner search of the SPD, the packet would be rejected, = as required. Thus point #3 is not in error.] \item The handling of ICMP messages as described in \cite[section=20 6]{RFC2401} is unclear to us. It states that an ICMP message generated by a router must not= be forwarded over a transport-mode SA, but transport mode SAs can only occur in hosts. By definition, hosts do not forward packets, and a router never has access to a transport-mode SA. [the text in the beginning of section 6 is emphasizing that an SA from a router to a host or security gateway, must be = a tunnel mode SA, vs. a transport mode SA. If we didn't make this clear, someo= ne might choose to establish a transport mode SA from an intermediate system, a= nd this would cause the source address checks to fail under certain circumstanc= es, as noted by the text.] The text further suggests that unauthenticated ICMP messages should be disregarded. This creates problems. Let us envision two machines that are geographically far apart and have a tunnel-mode SA set up. There are= probably a dozen routers between these two machines that forward the packets.=20 None of these routers knows about the existence of the SA. Any ICMP messages relating to t= he packets that are sent will be unauthenticated and unencrypted. Simply=20 discarding these ICMP messages results in a loss of IP functionality. This problem is mentioned, but the text claims this is due to the routers not implementing IPsec. Even if the routers implement IPsec, they still cannot send=20 authenticated ICMP messages about the tunnel unless they themselves set up an SA with the tunnel end-point for the purpose of sending the ICMP packet. The tunnel end- point in turn wants to be sure the source is a real router. This requires a generic public-key infrastructure, which does not exist. [RFC 2401 clearly states the dangers associated with blindly accepting unauthenticated ICMP messages, and the functionality problems associated with discarding such messages. System administrators are provided with the ability to make this tradeoff locally. The first step to addressing this problem is the addition = of IPsec into routers, as stated in the RFC. Only then does one face the need t= o have a PKI that identifies routers. Yes, this second PKI does not exist, but= a subset of it (at BGP routers) might be established if the S-BGP technology i= s deployed. These are the routers most likely to issue ICMP PMTU=20 messages. So, the answer here is that the specifications allow site administrators to make security/functionality tradeoffs, locally. The longer term solution describe= d would require routers to implement IPsec, so that they can send authenticate= d ICMP messages. Yes, this would require a PKI, but such a PKI may=20 arise for other reasons.] As far as we understand this problem, this is a fundamental compatibility problem with the existing IP protocol that does not have a good solution. \item \cite[section 6.1.2.1]{RFC2401} lists a number of possible ways of handling ICMP PMTU messages. An option that is not mentioned is to keep a limited history of packets that were sent, and to match the header inside th= e PMTU packet to the history list. This can identify the host where the packet that was too large originated. [the approach suggested by the authors was rejected as imposing too much of a burden on an SG. section 6.1.2.1 offers options (not suggestions) for an SG to respond to ICMP PMTU messages, includ= ing heuristics to employ when not enough information is present in the returned header. These options may not as responsive as a strategy that caches=20 traffic on each SA, but they are modest in the overhead imposed. Also, an SA=20 that carries a wide range of traffic (not fine-grained) might not benefit from a limited traffic history, as the traffic that caused the ICMP might well be from a ho= st whose traffic has been flushed from the "limited history."] \item \cite[section 7]{RFC2401} mentions that each auditable event in=20 the AH and ESP specifications lists a minimum set of information that should be=20 included in the audit-log entry. Not all auditable events defined in \cite{RFC2406} incl= ude that information.[you're right. Exactly one auditable event in 2406 does not specify the list of data that SHOULD be audited. We'll fix that in the next pass. Furthermore, auditable events in \cite{RFC2401} do not specify such a minimum list of information. [there are exactly 3 events defined as=20 auditable in 2401, one of which overlaps with 2406. So, to be more precise, the other 2 auditable events defined in 2401 ought to have the minimum data requirements defined. Another good point that we will fix in the next pass.] The documentation should be reviewed to ensure that a minimum list of audit-log information is specified with each auditable event. \item Various algorithm specifications require the implementation to reject known weak keys. For example, the DES-CBC encryption algorithm specification= s \cite{RFC2405} requires that DES weak keys are rejected. It is questionable whether this actually increases security. It might very well be that the ext= ra code that this requires creates more security problems due to bugs than are solved by rejecting weak keys. Weak keys are not really a problem in most situations. For DES, it is far le= ss work for an attacker to do an exhaustive search over all possible keys than = to wait for an SA that happens to use a weak key. After all, the easiest way fo= r the attacker to detect the weak keys is to try them all. Weak-key rejection = is only required for algorithms where detecting the weak key class by the weak cipher properties is significantly less work than trying all the weak keys i= n question. We recommend that the weak-key elimination requirement be removed. Encryptio= n algorithms that have large classes of weak keys that introduce security weaknesses should simply not be used. [I tend to agree with this analysis. T= he argument for weak key checking was made by folks who don't understand the cryptographic issues involved, but who are persistent and loud, e.g., Bill Simpson. Ted T'so (co-chair of the WG) and I discussed this problem, and tri= ed to explain it to the list, but were unsuccessful. Another flaw in the commit= tee process.] \item The only mandatory encryption algorithm in ESP is DES-CBC. Due=20 to the very limited key length of DES, this cannot be considered to be very secure. We strongly urge that this algorithm not be standardized but be replaced by a stronger alternative. The most obvious candidate is triple-DES. Blowfish cou= ld be used as an interim high-speed solution.\footnote{On a Pentium CPU, Blowfi= sh is about six to seven times faster than triple-DES.} The upcoming AES standa= rd will presumably gain quick acceptance and probably become the default=20 encryption method for most systems. [DES as a default was mandated because of=20 pressure from vendors who, at the time, could not get export permission for 3DES. Triple D= ES or AES will certainly augment DES as additional, mandatory defaults, and may replace it in the future. ] \item The insistence on randomly selected IV values in \cite{RFC2405} seems = to be overkill. It is true that a counter would provide known low Hamming-weigh= t input differentials to the block cipher. All reasonable block ciphers=20 are secure enough against this type of attack. Use of a random generator results in an increased risk of an implementation error that will lead to low-entropy or constant IV values; such an error would typically not be found during testin= g. [In practice the IV is usually acquired from previous ciphertext output, as suggested in the text for CBC mode ciphers, which is easy to acquire and not likely to result in significant complexity. In hardware assisted environment= an RNG is usually available anyway. In a high assurance hardware implementation= , the crypto chip would generate the IV.] \item Use of a block cipher with a 64-bit block size should in general be limited to at most $2^{32}$ block encryptions per key. This is due to the birthday paradox. After $2^{32}$ blocks we can expect one=20 collision.\footnote{To get a $10^{-6}$ probability of a collision it should be limited to about $2^{22}$ blocks.} In CBC mode, two equal ciphertexts give the attacker the X= OR of two blocks of the plaintext. The specifications for the DES-CBC encryptio= n algorithm \cite{RFC2405} should mention this, and require that any SA=20 using such an algorithm limit the total amount of data encrypted by a single key to a suitable value. \item The preferred mode for using a block cipher in ESP seems to be CBC mod= e \cite{RFC2451}. This is probably the most widely used cipher mode, but it ha= s some disadvantages. As mentioned earlier, a collision gives direct informati= on about the relation of two plaintext blocks. Furthermore, in hardware implementations each of the encryptions has to be done in turn. This gives a limited parallelism, which hinders high-speed hardware implementations. [fir= st, this is not an intrinsic part of the architecture; one can define different modes for use with existing or different algorithms if the WG is so motivate= d. Second, current hardware is available at speeds higher than the associated packet processing capability of current IPsec devices, so this does not appe= ar to be a problem for the near term. Transition to AES will decrease the processing burden (relative to 3DES), which may render this concern less serious.] Although not used very often, the counter mode seems to be preferable. The ciphertext of block $i$ is formed as $C_i =3D P_i \oplus E_K( i )$, where= $i$ is the block number that needs to be sent at the start of the packet.\footnote{= If replay protection is always in use, then the starting $i$-value could be for= med as $2^{32}$ times the sequence number. This saves eight bytes per=20 packet.} After more than $2^{32}$ blocks counter mode also reveals some information about t= he plaintext, but this is less than what occurs in CBC. The big advantage of counter mode is that hardware implementations can parallelize the=20 encryption and decryption process, thus achieving a much higher throughput. [earlier the authors criticize IPsec for a lack of orthogonality, but introducing interdependence between the anti-replay counter and encryption would certain= ly violate the spirit of the earlier criticism! Counter mode versions of=20 algorithms can be added to the list easily if there is sufficient vendor support.] \item \cite[section 2.3]{RFC2451} states that Blowfish has weak keys, but th= at the likelihood of generating one is very small. We disagree with these statements. The likelihood of getting two equal 32-bit values in any one 256= - entry S-box is about ${256 \choose 2} \cdot 2^{-32} \approx 2^{-17}$.=20 This is an event that will certainly occur in practice. However, the Blowfish weak keys only lead to detectable weaknesses in reduced-round versions of the cipher. There are no known weak keys for the full Blowfish cipher. \item In \cite[section 2.5]{RFC2451}, it is suggested to negotiate=20 the number of rounds of a cipher. We consider this to be a very bad idea. The=20 number of rounds is integral to the cipher specifications and should not be changed at=20 will. Even for ciphers that are specified with a variable number of rounds, the determination of the number of rounds should not be left up to the individua= l system administrators. The IPsec standard should specify the number of round= s for those ciphers. [I agree that this algorithm spec ought not encourage negotiation of the number of rounds, without specifying a minimum for each cipher, although this gets us into the crypto strength value judgement arena again. Also, the inclusion of 3DES in this table is inappropriate as it is a= 48 round algorithm, period. So, yes, there is definite room for improvement in this RFC.] \item \cite[section 2.5]{RFC2451} proposes the use of RC5. We urge caution i= n the use of this cipher. It uses some new ideas that have not been=20 fully analyzed or understood by the cryptographic community. The original RC5 as=20 proposed (with 12 rounds) was broken, and in response to that the recommended number of rou= nds was increased to 16. We feel that further research into the use of data- dependent rotations is required before RC5 is used in fielded systems. [RC5 = is not required by IPsec implementations. In the IETF spirit of flexible parameterization of implementations, vendors are free to offer any additiona= l algorithms in addition to the required default. In general, the IETF is not prepared to make value judgements about these algorithms and so one=20 may see RFCs that specify a variety of additional algorithms.] \item \cite[section 2.4]{RFC2406} specifies that the ESP padding should pad = the plaintext to a length so that the overall ciphertext length is both a multip= le of the block size and a multiple of 4. If a block cipher of unusual block si= ze is used (e.g., 15 bytes), then this can require up to 59 bytes of padding. T= his padding rule works best for block sizes that are a multiple of 4, which fortunately is the case for most block ciphers. [this padding rule is based primarily on IP packet alignment considerations, not on common block cipher sizes! This is stated in the text.] \item \cite[p.\ 6, point a]{RFC2406} states that the padding=20 computations of the ESP payload with regard to the block size of the cipher apply to the payload data, excluding the IV (if present), Pad Length, and Next Header fields. Thi= s would imply that the Pad Length and Next Header fields are not being encrypt= ed. Yet the rest of the specification is clear that the Pad Length and Next Head= er field are to be encrypted, which is what should happen. The text of point a should be made consistent with the rest of the text. [The text says "=8Athe padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields." The comma after "IV" is meat to terminate t= he scope of the word "exclusive," and thus the intent is to include the pad len= gth and next header fields. The term "payload" in ESP applies to a set of data n= ot including the latter two fields, so the sentence is, technically, unambiguou= s, and it is consistent with the terms employed in the figure in section=20 2. But, I admit the wording could be improved.] \item There is a document that defines the NULL encryption algorithm=20 used in ESP \cite{RFC2410}, but no document that defines the NULL authentication algorit= hm, which is also used by ESP \cite[section 5]{RFC2406}. [good point. Another RF= C publication opportunity!] \item The NULL cipher specifies an IV length of zero \cite{RFC2410}. This wo= uld seem to imply that the NULL cipher is used in CBC mode, which is=20 clearly not the case. The NULL cipher is in fact used in ECB mode, which does not=20 require an IV. Therefore, no IV length should be specified. [use of the NULL cipher=20 in ECB mode would be inconsistent with the guidance in FIPS 82, and thus CBC mode is intended, to preserve the confidentiality characteristics inherent in this cipher :-).] \end{enumerate} \section{Conclusions} The IPsec system should be simplified significantly. This can be done withou= t loss of functionality or performance. There are also some security weaknesse= s that should be fixed. [the extensive comments above illustrate that=20 the proposed changes to IPsec would change the functionality, contrary to the claim made here. One might argue about the importance of some of this functionality, bu= t several examples have been provided to illustrate application contexts that = the authors of this report did not consider in their analysis. Several misunderstandings of some RFCs also were noted.] Due to its high complexity, we have not been able to analyze IPsec as=20 thoroughly as we would have liked. After simplification, a new security analysis should= be performed. I have not reviewed the ISAKMP/IKE comments. However, I agree that=20 this protocol is very complex. Much of the complexity results of incremental=20 enhancement and a reluctance on the part of developers to discard older versions of code. --============_-1263317047==_ma============ Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My annotations are in brackets. Steve ---------- \chapter*{Executive summary} IPsec is a set of protocols that provides communication security for computers=20 using IP-based communication networks. It provides authentication and=20 confidentiality services on a packet level. To support the IPsec security, a key=20 management protocol called ISAKMP is used. ISAKMP uses public-key cryptographic=20 techniques to set up keys between the different parties to be used with IPsec. Both IPsec and ISAKMP are too complex. [a protocol is too complex only relative=20 to a specified set of requirements that are satisfied by a simpler protocol. To=20 substantiate this observation, one ought to define the requirements that one=20 believes the protocol is trying top satisfy, and then offer a simpler protocol.] This high complexity leads to errors. We have found security flaws in=20 both IPsec and ISAKMP, and expect that there are many more. We expect any actual=20 implementation to contain many more errors, some of which will cause security=20 weaknesses. These protocols give the impression of having been designed by a=20 committee: they try to be everything for everybody at the cost of complexity.=20 =46or normal standards, that is bad enough; for security systems, it is=20 catastrophic. In our opinion, the complexity of both IPsec and ISAKMP can be=20 reduced by a large factor without a significant loss of functionality. IPsec is in better shape than ISAKMP. The description and definitions are=20 reasonably clear. A careful implementation of IPsec can achieve a good level of=20 security. Unfortunately, IPsec by itself is not a very useful protocol. Use on a=20 large scale requires the key management functions of ISAKMP. [while I would tend=20 to agree with this observation, I should note that a non-trivial number of IPsec=20 implementations, used in constrained contexts, are manually keyed.] ISAKMP is currently not in a suitable state for implementation. Major work will=20 be required to get it to that point. There are many security-critical errors, as=20 well as many unnecessary cross-dependencies within the protocol. These should=20 all be eliminated before a new evaluation is done. Based on our analysis, we recommend that IPsec and ISAKMP not be used for=20 confidential information. At the moment we cannot recommend a direct=20 alternative. Some applications might be able to use SSL \cite{SSLv3Nov96}, which=20 in our opinion is a much better protocol that provides a much higher level of=20 security when used appropriately. \tableofcontents \chapter{Introduction} At the request of NSA, Counterpane has conducted a security review of the IPsec=20 and ISAKMP security protocols. This evaluation is based on RFCs 2401--2411 and RFC 2451 =20 \cite{RFC2401,RFC2402,RFC2403,RFC2404,RFC2405,RFC2406,RFC2407,RFC2408,RFC240= 9,RF C2410,RFC2411,RFC2451}. The Oakley protocol \cite{RFC2412} is only an=20 informational RFC; it is not part of the standard and is not used in ISAKMP. RFC=20 documents are available from {\tt ftp:ftp.isi.edu\slash in-notes\slash rfc<.txt}.=20 As \cite{RFC2401} states: ``The suite of IPsec protocols and associated default=20 algorithms are designed to provide high quality security for Internet traffic.=20 However, the security offered by use of these protocols ultimately depends on=20 the quality of the their implementation, which is outside the scope of this set=20 of standards. Moreover, the security of a computer system or network is a=20 function of many factors, including personnel, physical, procedural,=20 compromising emanations, and computer security practices. Thus IPsec is only=20 one part of an overall system security architecture.'' This evaluation only=20 deals with the IPsec and ISAKMP specifications and is not directly concerned=20 with any of the other factors. However, we do comment on aspects of the specifications that affect other security factors. IPsec and ISAKMP are highly complex systems. Unfortunately, we cannot give a=20 sufficiently detailed description of these systems in this document to allow the=20 reader to understand our comments without being familiar with IPsec and ISAKMP.=20 Our comments frequently refer to specific places in the RFC documents for ease=20 of reference. The rest of this report is structured as follows. Chapter~\ref{chap:general}=20 gives some general comments. Chapter~\ref{chap:bulk} discusses the IPsec=20 protocols that handle bulk data. Chapter~\ref{chap:ISAKMP} discusses the ISAKMP=20 generic definitions. Chapter~\ref{chap:IPsecDOI} talks about the IPsec Domain of=20 Interpretation which gives more details on how the generic ISAKMP structure=20 applies to the IPsec protocols. Finally, chapter~\ref{chap:IKE} discusses the=20 IKE protocol that is the default key management protocol used with ISAKMP. \chapter{General comments}\label{chap:general} \section{Complexity} Complexity is the biggest enemy of security. This might seem an odd statement in=20 the light of the many fielded systems that exhibit critical security failures=20 for very simple reasons. It is true nonetheless. The simple failures are simple=20 to avoid, and often simple to fix. The problem is not that we do not know how to=20 solve them; it is that this knowledge is often not applied. Complexity, however,=20 is a different beast because we do not really know how to handle it. Designing any software system is always a matter of weighing various=20 requirements. These include functionality, efficiency, political acceptability,=20 security, backward compatibility, deadlines, flexibility, ease of use, and many=20 more. The unspoken requirement is often the complexity. If the system gets too=20 complex, it becomes too difficult, and therefore too expensive, to make. As=20 fulfilling more of the requirements usually involves a more complex design, many=20 systems end up with a design that is as complex as the designers and=20 implementors can reasonably handle.=20 Virtually all software is developed using a try-and-fix methodology. Small=20 pieces are implemented, tested, fixed, and tested again.\footnote{Usually=20 several iterations are required.} Several of these small pieces are combined=20 into a larger module, and this module is tested, fixed, and tested again. The=20 end result is software that more or less functions as expected, although we are=20 all familiar with the high frequency of functional failures of software systems. This process of making fairly complex systems and implementing them with a try- and-fix methodology has a devastating effect on the security. The central reason=20 is that you cannot test for security. Therefore, security bugs are not detected=20 during the development process in the same way that functional bugs are. Suppose=20 a reasonably sized program is developed without any testing at all during=20 development and quality control. We feel confident in stating that the result=20 will be a completely useless program; most likely it will not perform any of the=20 desired functions correctly. Yet this is exactly what we get from the try-and- fix methodology when we look at security.=20 The only reasonable way to ``test'' the security of a security product is to=20 perform security reviews on it.\footnote{A cracking contest can be seen as a=20 cheap way of getting other people to do a security analysis. The big problem is=20 interpreting the results. If the prize is not claimed, it does not imply that=20 any competent analysis was done and came up empty.} A security review is a=20 manual process; it is relatively expensive in terms of time and effort and it=20 will never be able to show that the product is in fact secure. [this seems to=20 ignore the approaches usually employed for high assurance system design and=20 implementation , i.e., careful design and review coupled with rigid development=20 procedures, all prior to testing.] The more complex the system is, the harder a security evaluation becomes. A more=20 complex system will have more security-related errors in the specification,=20 design, and implementation. We claim that the number of errors and difficulty of=20 the evaluation are not linear functions of the complexity, but in fact grow much=20 faster. =46or the sake of simplicity, let us assume the system has $n$ different options,=20 each with two possible choices.\footnote{We use $n$ as the measure of the=20 complexity. This seems reasonable, as the length of the system specification and=20 the implementation is proportional to $n$.} Then there are $n(n-1)/2 =3D O(n^2)$=20 different pairs of options that could interact in unexpected ways, and $2^n$=20 different configurations altogether. Each possible interaction can lead to a=20 security weakness, and the number of possible complex interactions that involve=20 several options is huge. As each interaction can produce a security weakness, we=20 expect that the number of actual security weaknesses grows very rapidly with=20 increasing complexity. The same holds for the security evaluation. For a system with a moderate number=20 of options, checking all the interactions becomes a huge amount of work.=20 Checking every possible configuration is effectively impossible. Thus the=20 difficulty of performing security evaluations also grows very rapidly with=20 increasing complexity. The combination of additional (potential) weaknesses and=20 a more difficult security analysis unavoidably results in insecure systems. In actual systems, the situation is not quite so bad; there are often options=20 that are ``orthogonal'' in that they have no relation or interaction with each=20 other. This occurs, for example, if the options are on different layers in the=20 communication system, and the layers are separated by a well-defined interface=20 that does not ``show'' the options on either side. For this very reason, such a=20 separation of a system into relatively independent modules with clearly defined=20 interfaces is a hallmark of good design. Good modularization can dramatically=20 reduce the ``effective'' complexity of a system without the need to eliminate=20 important features. Options within a single module can of course still have=20 interactions that need to be analyzed, so the number of options per module=20 should be minimized. Modularization works well when used properly, but most=20 actual systems still include cross-dependencies where options in different=20 modules do affect each other. A more complex system loses on all fronts. It contains more weaknesses to start=20 with, it is much harder to analyze, and it is much harder to implement without=20 introducing security-critical errors in the implementation. Complexity not only makes it virtually impossible to create a secure=20 implementation, it also makes the system extremely hard to manage. The people=20 running the actual system typically do not have a thorough understanding of the=20 security issues involved. Configuration options should therefore be kept to a=20 minimum, and the options should provide a very simple model to the user. Complex=20 combinations of options are very likely to be configured erroneously, which=20 results in a loss of security. The stories in \cite{TheCodebreakers} and=20 \cite{A:WhyFail} illustrate how management of complex systems is often the=20 weakest link. Both IPsec and ISAKMP are too complex to be secure. The design obviously tries=20 to support many different situations with different options. We feel very=20 strongly that the resulting system is well beyond the level of complexity that=20 can be implemented securely with current methodologies. \section{Stating what is achieved} A security analysis evaluates the security aspects of a system. To be able to=20 give any sensible answer, it should be clear what properties the system claims=20 to have. That is, the system documentation should clearly state what security=20 properties are achieved. This can be seen as the functional specification of the=20 security properties. This applies not only to the entire system, but also to the=20 individual modules. At each module or function, the security properties should=20 be specified.=20 A good comparison is the testing of a product. The testing verifies that the=20 product performs according to the functional specifications. Without=20 specifications, the testers might have some interesting comments, but they can=20 never give a real answer.=20 Without security specifications, the first task of the security analysis is to=20 create descriptions of the security properties achieved, based on the perceived=20 intentions of the system designer. The subsequent evaluation might then turn up=20 problems of the form ``this function does not achieve the properties that we=20 think it should have.'' The obvious answer will be: ``but that is not the=20 properties that I designed it to have.'' Very quickly the discussion moves away=20 from the actual security into what was meant. The overall result is a security=20 evaluation that might point out some potential weaknesses, but that will hardly=20 help in improving the security. The IPsec and ISAKMP protocols do not specify clearly which security properties=20 they claim to achieve. [RFCs 2401, 2402, and 2406 clearly state the security=20 services offered by the AH and ESP protocols.] The same holds for the modules=20 and functions. [modules are not specified by these standards; they are implementation artifacts.] We recommend that each function, module, and protocol=20 be extended to include clear specifications regarding the security-related=20 functionality they achieve. We feel that unless this is done, it will not be=20 possible to perform an adequate security evaluation on a system of this complexity. \chapter{Bulk data handling}\label{chap:bulk} In this chapter we discuss the methods used to handle the encryption and=20 authentication of the bulk data, as specified in=20 \cite{RFC2401,RFC2402,RFC2403,RFC2404,RFC2405,RFC2406,RFC2451,RFC2410,RFC241= 1}. Together these documents specify the IPsec protocol. They specify the actual=20 encryption and authentication of packets, assuming that symmetric keys have=20 already been exchanged. We refer the reader to \cite{RFC2401} sections 1--4.2=20 for an overview of this part of IPsec and the relevant terminology. \section{Functionality} IPsec is capable of providing authentication and confidentiality services on a=20 packet level. The security configuration of an IPsec implementation is done=20 centrally, presumably by the system administrator. [In some environments, a=20 single administrator might control the configuration of each IPsec=20 implementation, or each user might have some control over it. The latter would=20 tend to be characterized as a distributed management paradigm, not a central=20 one. Also, two IPsec peers communicate ONLY if both agree on the security=20 parameters for the SA, i.e., there is suitable overlap in the SPDs. In that=20 sense too, security configuration is distributed.] IPsec is very suitable for creating a VPN over the Internet, improved security=20 for dial-in connections to portables, restricting access to parts of a network,=20 etc. These are very much network-level functions. IPsec by itself does not=20 supply application-level security. Authentication links the packet to the=20 security gateway of the originating network, the originating host, or possibly=20 the originating user, but not to the application in question or the data the=20 application was handling when it sent the packet. [true, but for many=20 applications, application layer security is not needed, and its implementation=20 might well be accorded less assurance than the network layer security provided=20 by IPsec. This paragraph seems to suggest that there is some important benefit=20 to linking data to an application, through an application-specific security=20 mechanism. There are good examples of where this is true, e.g., e-mail and=20 directories. However, unless there are application-specific security semantics=20 that cannot be captured by use of an application security protocol, your own=20 arguments about simplicity, as well as a number of arguments re assurance, argue=20 against proliferation of application security protocols.] The IPsec functionality can significantly increase the security of the network.=20 It is not a panacea for all security problems, and applications that require=20 security services will typically have to use other security systems in addition=20 to IPsec. [I might disagree with the term "typically" here. A lot depends on the=20 application, where IPsec is implemented, etc.] \section{Complexity}\label{sec:complexity} Our biggest criticism is that IPsec is too complex. There are too many options=20 that achieve the same or similar properties. [if they were completely equivalent=20 this would be a good basis for simplifying IPsec. However, there are subtle=20 differences that have resulted in the proliferation of options you address=20 below.] \subsection{Options} IPsec suffers from an abundance of options. For example, two hosts that want to=20 authenticate IP packets can use four different modes: transport/AH, tunnel/AH,=20 transport/ESP with NULL encryption, and tunnel/ESP with NULL encryption. The=20 differences between these options, both in functionality and performance, are=20 minor.=20 In particular, the following options seem to create a great deal of needless=20 complexity: \begin{enumerate} \item There are two modes that can be used: transport mode and tunnel mode. In=20 transport mode, the IP header of the packet is left untouched. AH authenticates=20 both the IP header and the packet payload. ESP encrypts and authenticates the=20 payload, but not the header. The lack of header authentication in transport/ESP=20 is a real weakness, as it allows various manipulations to be performed. In=20 tunnel mode, the full original IP packet (including headers) is used as the=20 payload in a new IP packet with new headers. The same AH or ESP functions are=20 used. As the original header is now included in the ESP authentication, the=20 transport/ESP authentication weakness no longer exists. Transport mode provides a subset of the functionality of tunnel mode. The only=20 advantage that we can see to transport mode is that it uses a somewhat smaller=20 bandwidth. However, the tunnel mode could be extended in a straightforward way=20 with a specialized header-compression scheme that we will explain shortly. This=20 would achieve virtually the same performance as transport mode without introducing an entirely new mode. We therefore recommend that the transport mode=20 be eliminated. [transport mode and tunnel mode address fundamentally different=20 requirements, from a networking point of view. When security gateways are=20 involved, the use of tunnel mode is an absolute requirement, whereas it is a=20 minor (and rarely used) feature for communications between end systems. A=20 proposal to make all traffic tunnel mode, and to try to offset the added=20 overhead through compression, seems to ignore the IPCOMP facility that is=20 already available to IPsec implementations. Today, transport mode is used=20 primarily to carry L2TP traffic, although this is primarily an efficiency=20 issue.] \item There are two protocols: AH and ESP. AH provides authentication, and ESP=20 provides encryption, authentication, or both. In transport mode, AH provides a=20 stronger authentication than ESP can provide, as it also authenticates the IP=20 header. One of the standard modes of operation would seem to be to use both AH=20 and ESP in transport mode. [although this mode is required to be supported, it=20 seems to be rarely used today. A plausible, near-term use for AH is to provide=20 integrity and authenticity for IPsec traffic between an end system and a first- hop intermediary. For example, AH can be used between a host inside an enclave=20 and a security gateway at the perimeter, to allow the SG to control what traffic=20 leaves the enclave, without granting the SG access to plaintext traffic. This,=20 and similar concatenated SA examples, motivate retention of AH. One could=20 achieve a similar effect with (authentication-only) ESP tunnels, but with=20 increased bandwidth and processing overhead.] In tunnel mode, the authentication=20 that ESP provides is good enough (it includes the IP header), and AH is typically not combined with ESP \cite[section 4.5]{RFC2401}. [the example above=20 shows why one might wish to use AH for the outer header, but most likely with=20 ESP in transport mode.] (Implementations are not required to support nested=20 tunnels that would allow ESP and AH to both be used.) The AH protocol \cite{RFC2402} authenticates the IP headers of the lower layers.=20 [AH authenticates the IP header at the SAME layer, in many respects. AH was=20 originally described as an IP (v4) option. In IPv6, AH is viewed as=20 part of the=20 AH header, and may appear before other header extensions (see section 4.1 of RFC=20 2401). I agree that AH represents ugly layering, but it's not as bad as you=20 suggest here.] This creates all kind of problems, as some header fields change=20 in transit. As a result, the AH protocol needs to be aware of all data formats=20 used at lower layers so that these mutable fields can be avoided. [this is an=20 inaccurate characterization, especially given the status of AH re IPv6. Don't=20 think of AH as a transport protocol. It isn't.] This is a very ugly=20 construction, and one that will create more problems when future extensions to=20 the IP protocol are made that create new fields that the AH protocol is not=20 aware of. [RFC 2402 explains how to deal with new IP header fields in v6 (see=20 section 3.3.3.1.2.2). The existence of a mutability flag in such extensions=20 makes processing relatively straightforward.] Also, as some header fields are=20 not authenticated, the receiving application still cannot rely on the entire=20 packet. To fully understand the authentication provided by AH, an application=20 needs to take into account the same complex IP header parsing rules that AH=20 uses. The complex definition of the functionality that AH provides can easily=20 lead to security-relevant errors. The tunnel/ESP authentication avoids this problem, but uses more bandwidth. [but=20 it does not provide exactly the same features, as noted above, so the=20 alternative is not quite equivalent.] The extra bandwidth requirement can be=20 reduced by a simple specialized compression scheme: for some suitably chosen set=20 of IP header fields $X$, a single bit in the ESP header indicates whether the=20 $X$ fields in the inner IP header are identical to the corresponding fields in=20 the outer header.\footnote{A trivial generalization is to have several flag=20 bits, each controlling a set of IP header fields.} The fields in question are=20 then removed to reduce the payload size. This compression should be applied=20 after computing the authentication but before any encryption. The authentication=20 is thus still computed on the entire original packet. The receiver reconstitutes=20 the original packet using the outer header fields, and verifies the=20 authentication. A suitable choice of the set of header fields $X$ allows=20 tunnel/ESP to achieve virtually the same low message expansion as transport/AH. We conclude that eliminating transport mode allows the elimination of the AH=20 protocol as well, without loss of functionality. [counter examples provided=20 above suggest that this claim is a bit overstated.] \item The standard defines two categories of machines: hosts and security=20 gateways. Hosts can use transport mode, but security gateways must always use=20 tunnel mode. Eliminating transport mode would also allow this distinction to be=20 eliminated. Various computers could of course still function as hosts or=20 security gateways, but these different uses would no longer affect the protocol. \item The ESP protocol allows the payload to be encrypted without being authenticated. In virtually all cases, encryption without authentication is not=20 useful. The only situation in which it makes sense not to use authentication in=20 the ESP protocol is when the authentication is provided by a subsequent application of the AH protocol (as is done in transport mode because ESP=20 authentication in transport mode is not strong enough). [this is one example of=20 when one might not need authentication with ESP, but it is not the only one. In=20 general, if there is a higher layer integrity and/or authentication function in=20 place, providing integrity/authentication in IPsec is redundant, both in terms=20 of space and processing. The authentication field for ESP or AH is 12 bytes. For=20 applications where packet sizes are quite small, and for some environments where=20 packet size is of critical importance, e.g., packet voice in a wireless environment, ESP w/o authentication may be appropriate. This is especially true=20 if the application protocol embodies an authentication mechanism. This might=20 happen if the application protocol wants to offer uniform protection=20 irrespective of the lower layers. Admittedly, this might also cause the=20 application to offer confidentiality as well, but depending on the application,=20 the choices of what security services are being offered may vary.] Without the=20 transport mode to worry about, ESP should always provide its own authentication.=20 We recommend that ESP authentication always be used, and only encryption be made=20 optional. [the question of authentication as an intrinsic part of ESP is=20 independent of mode, i.e., whether one choose to provide authentication as a=20 part of ESP is not determined by the choice of transport vs. tunnel mode.]=20 \end{enumerate} We can thus remove three of the four operational modes without any significant=20 loss of functionality. [sorry, can't agree, given the counter examples above.] \subsection{Undesirable options} There are existing combinations of options that are undesirable. These pose a=20 problem when non-experts have to configure an IPsec installation. Given the fact=20 that experts are rare and usually have better things to do, most IPsec installations will be configured by non-experts. [yes, we were aware of this=20 concern. However, there is always a tradeoff between adopting the "we know=20 what's best for you" approach, vs. the "you can screw it up if you want to=20 approach." We opted for a point somewhere along this spectrum, but not at either=20 end.] \begin{enumerate} \item In transport mode, use of ESP provides authentication of the payload only.=20 The authentication excludes the IP headers of the packet. The result is a data=20 stream that is advertised as ``authenticated'' for which critical pieces of=20 information (such as the source and destination IP number) are not=20 authenticated. Unless the system administrator is intimately familiar with the=20 different forms of authentication used by IPsec, it is quite likely that the=20 administrator will assume that the authentication protects the entire packet.=20 The combination of transport mode and the ESP protocol (without the AH protocol)=20 should therefore not be allowed. [The IP source and destination address are=20 covered by the TCP checksum, which is covered by the ESP integrity check, so=20 this does limit (a tiny bit) the ability to change these values without detection. A more significant observation is that transport mode IPsec SAs will=20 probably always use source and/or destination IP addresses as part of the=20 selector set. In such cases, tampering with the either address will result in a=20 failed authentication check.] \item The standard allows ESP to be used with the NULL encryption, such that it=20 provides only authentication. The authentication provided by ESP in transport=20 mode is less functional than the authentication provided by AH, at a similar=20 cost. If transport mode is retained, either the EPS ESP authentication should be=20 extended or the use of ESP with only authentication should be forbidden and=20 replaced by the use of AH. [ESP authentication is more efficient to compute than=20 AH, because of the selective IP header coverage provided by AH. Thus there is=20 good reason to allow authentication-only ESP as an alternative to AH. This point=20 was debated by the group and, with implementation experience, vendors came to=20 agree that this is true.] \item The ESP protocol can provide encryption without authentication. This does=20 not make much sense in an application. It protects the application against=20 passive eavesdroppers, but provides no protection against active attacks that=20 are often far more devastating. Again, this mode can lure non-expert users into=20 using an unsafe configuration that they think is secure. Encryption without=20 authentication should be forbidden. [as noted above, there are examples where=20 this feature set for ESP is attractive.] \end{enumerate} \subsection{Orthogonality} IPsec also suffers from a lack of orthogonality. The AH and ESP protocols can be=20 used together, but should only be used in one particular order. In transport=20 mode, ESP by itself provides only partial authentication of the IP packet, and=20 using AH too is advisable. [not in most cases, as noted above.] In tunnel mode=20 the ESP protocol authenticates the inner headers, so use of AH is no longer=20 required. These interdependencies between the choices demonstrate that these=20 options are not independent of each other. [true, but who says that this is a=20 critical criteria? TCP and IP are not orthogonal either, e.g., note the TCP=20 checksum covering parts of the IP header.] \subsection{Compatibility} The IPsec protocols are also hampered by the compatibility requirements. A=20 simple problem is the TOS field in the IP header \cite[p.\ 10]{RFC2402}.=20 Although this is supposed to be unchanged during the transmission of a packet=20 (according to the IP specifications), some routers are known to change this=20 field. IPsec chose to exclude the TOS field from the authentication provided by=20 the AH protocol to avoid errors introduced by such rogue routers. The result is=20 that, in transport/AH packets that have an authenticated header, the TOS field=20 is not authenticated. This is clearly unexpected from the application point of=20 view, which might want to rely on the correct value of the TOS field. This=20 problem does not occur in tunnel mode. [it is unfortunate that cisco chose to=20 not follow the specs here, and in several other places. I agree that an unenlightened system administrator might be surprised in this case. But, in=20 practice, the effect is minimal. Your example cites transport mode, which means=20 that the TOS bits are being acted upon by the end system. If end systems really=20 paid attention to these bits in the first place, cisco would not have been able=20 to corrupt them with impunity! The reason that these bits are being re-used by=20 the ECN folks is because hosts have never made use of them. Still, going=20 forward, one should pay attention to this vulnerability.] A more complex compatibility problem is the interaction between fragmentation=20 and IPsec \cite[appendix B]{RFC2401}. This is a complex area, but a typical=20 IPsec implementation has to perform specialized processing to facilitate the=20 proper behavior of higher-level protocols in relation to fragmentation. Strictly=20 speaking, fragmentation is part of the communication layer below the IPsec=20 layer, and in an ideal world it would be transparent to IPsec. Compatibility=20 requirements with existing protocols (such as TCP) force IPsec to explicitly=20 handle fragmentation issues, which adds significantly to the overall complexity.=20 Unfortunately, there does not seem to be an elegant solution to this problem.=20 [The requirement here is the same that arises whenever an intermediate system=20 adds info to a packet, or when a smaller MTU intermediate system is traversed.=20 IPsec in an SG is doing what a router along a path would do if the "other side"=20 network were smaller. IPsec in a host is doing what the NIC would do if the LAN=20 MTU changed. The real complexity arises when we wish to do this optimally, at a=20 security gateway or a BITS or BITW implementation, in cases where different SAs=20 use different combinations of AH and ESP, or different algorithms, etc.] \subsection{Conclusion} The overall result is that IPsec bulk data handing is overly complex. In our=20 opinion it is possible to define an equivalent system that is far less complex.=20 \section{Order of operations} \subsection{Introduction} When both encryption and authentication are provided, IPsec performs the=20 encryption first, and authenticates the ciphertext. In our opinion, this is the=20 wrong order. Going by the ``Horton principle'' \cite{WS:SSL30}, the protocol=20 should authenticate what was meant, not what was said. The ``meaning'' of the=20 ciphertext still depends on the decryption key used. Authentication should thus=20 be applied to the plaintext (as it is in SSL \cite{SSLv3Nov96}), and not to the=20 ciphertext.[The order of processing is intentional. It is explicitly designed to=20 allow a receiver to discard a packet as quickly as possible, in the event of DoS=20 attacks, as you acknowledge below. The suggestion that this concern be addressed=20 by the addition of a secondary MAC seems to violate the spirit of simplicity=20 that this document espouses so strongly, and the specific proposed fix is not=20 strong enough to warrant its incorporation. Moreover, this ordering allows=20 parallel processing at a receiver, as a means of increasing throughput and=20 reducing delay.]=20 This does not always lead to a direct security problem. In the case of the ESP=20 protocol, the encryption key and authentication key are part of a single ESP key=20 in the SA. A successful authentication shows that the packet was sent by someone=20 who knew the authentication key. The recipient trusts the sender to encrypt that=20 packet with the other half of the ESP key, so that the decrypted data is in fact=20 the same as the original data that was sent. The exact argument why this is=20 secure gets to be very complicated, and requires special assumptions about the=20 key agreement protocol. For example, suppose an attacker can manipulate the key=20 agreement protocol used to set up the SA in such a way that the two parties get=20 an agreement on the authentication key but a disagreement on the encryption key.=20 When this is done, the data transmitted will be authenticated successfully, but=20 decryption takes place with a different key than encryption, and all the=20 plaintext data is still garbled. [The fundamental assumption is that an ESP SA=20 that employs both encryption and an HMAC will have the keys bound together,=20 irrespective of the means by which they are generated. This assumption probably=20 could be better stated in the RFCs.] In other situations, the wrong order does lead to direct security weaknesses. \subsection{An attack on IPsec} Suppose two hosts have a manually keyed transport-mode AH-protocol SA, which we=20 will call SAah. Due to the manual keying, the AH protocol does not provide any=20 replay protection. These two hosts now negotiate a transport-mode encryption- only ESP SA (which we will call SAesp1) and use this to send information using=20 both SAesp1 and SAah. The application can expect to get confidentiality and=20 authentication on this channel, but no replay protection. When the immediate=20 interaction is finished, SAesp1 is deleted. A few hours later, the two hosts=20 again negotiate a transport-mode encryption-only ESP SA (SAesp2), and the=20 receiver chooses the same SPI value for SAesp2 as was used for SAesp1. Again,=20 data is transmitted using both SAesp2 and SAah. The attacker now introduces one=20 of the packets from the first exchange. This packet was encrypted using SAesp1=20 and authenticated using SAah. The receiver checks the authentication and finds=20 it valid. (As replay protection is not enabled, the sequence number field is=20 ignored.) The receiver then proceeds to decrypt the packet using SAesp2, which=20 presumably has a different decryption key then SAesp1. The end result is that=20 the receiver accepts the packet as valid, decrypts it with the wrong key, and=20 presents the garbled data to the application. Clearly, the authentication=20 property has been violated. [this attack is not a criticism of the choice of ESP=20 operation ordering, but rather the notion of applying AH and ESP (encryption=20 only) in a particular order, as allowed by RFC 2401. The specific combination of=20 keying operations described here, though not prohibited by 2401, does not seem=20 likely to occur in practice. Specifically, if an IPsec implementation supports=20 automated key management, as described above for the ESP SAs, then it is highly=20 unlikely that the AH SA would be manually keyed. The push to retain manual=20 keying as a base facility for IPsec is waning, and most implementations have IKE=20 available. Under these circumstances, this vulnerability is unlikely to be=20 realized.]=20 \subsection{Other considerations} Doing the encryption first and authentication later allows the recipient to=20 discard packets with erroneous authentication faster, without the overhead of=20 the decryption. This helps the computer cope with denial-of-service attacks in=20 which a large number of fake packets eat up a lot of CPU time. We question=20 whether this would be the preferred mode of attack against a TCP/IP-enabled=20 computer. If this property is really important, a 1- or 2-byte MAC (Message=20 Authentication Code) on the ciphertext could be added. The MAC code allows the=20 recipient to rapidly discard virtually all bogus packets at the cost of an=20 additional MAC computation per packet. [a one or two byte MAC provides so little=20 protection that this does not seem to be an attractive counter-proposal. Also,=20 as noted above, it adds complexity =8A] \subsection{Conclusion} The ordering of encryption and authentication in IPsec is wrong. Authentication=20 should be applied to the plaintext of the payload, and encryption should be=20 applied after that. \section{Security Associations} A Security Association (SA) is a simplex ``connection' that affords security=20 services to the traffic carried by it \cite[section 4]{RFC2401}. The two=20 computers on either side of the SA store the mode, protocol, algorithms, and=20 keys used in the SA. Each SA is used only in one direction; for bidirectional=20 communications two SAs are required. Each SA implements a single mode and=20 protocol; if two protocols (such as AH and ESP) are to be applied to a single=20 packet, two SAs are required. Most of our aforementioned comments also affect the SA system; the use of two=20 modes and two protocols make the SA system more complex than necessary. There are very few (if any) situations in which a computer sends an IP packet to=20 a host, but no reply is ever sent. [we have a growing number of apps where this=20 functionality may be appropriate. For example, broadcast packet video feeds and=20 secure time feeds are unidirectional.] There are also very few situations in=20 which the traffic in one direction needs to be secured, but the traffic in the=20 other direction does not need to be secured. It therefore seems that in virtually all practical situations, SAs occur in pairs to allow bidirectional=20 secured communications. In fact, the IKE protocol negotiates SAs in pairs. [IKE=20 has not always been well coordinated with IPsec, unfortunately. This is why we=20 have to have null encryption and null authentication algorithms. So, I don't=20 think one should cite IKE behavior as a basis for making SAs bi-directional. I=20 agree that the vast majority of examples that we see now are full duplex, but we=20 have example where this may not apply, as noted above.] This would suggest that it is more logical to make an SA a bidirectional=20 ``connection'' between two machines. This would halve the number of SAs in the=20 overall system. It would also avoid asymmetric security configurations, which we=20 think are undesirable (see section~\ref{sec:SPD}). [The SPI that is used as a=20 primary de-multiplexing value, must be chosen locally, by the receiver, so=20 having bi-directional SAs probably won't change the size of the SAD=20 substantially. Specifically, how do you envision that a switch to bi- directionality would simplify implementations?] \section{Security policies}\label{sec:SPD} The security policies are stored in the SPD (Security Policy Database). =46or=20 every packet that is to be sent out, the SPD is checked to find how the packet=20 is to be processed. The SPD can specify three actions: discard the packet, let=20 the packet bypass IPsec processing, or apply IPsec processing. In the last case,=20 the SPD also specifies which SAs should be used (if suitable SAs have already=20 been set up) or specifies with what parameters new SAs should be set up to be=20 used. The SPD seems to be a very flexible control mechanism that allows a very fine- grained control over the security processing of each packet. Packets are=20 classified according to a large number of selectors, and the SPD can match some=20 or all selectors to determine the appropriate action. Depending on the SPD, this=20 can result in either all traffic between two computers being carried on a single=20 SA, or a separate SA being used for each application, or even each TCP connection. Such a very fine granularity has disadvantages. There is a significantly increased overhead in setting up the required SAs, and more=20 traffic analysis information is made available to the attacker. At the same time=20 we do not see any need for such a fine-grained control. [a lot of customers for=20 IPsec products disagree!] The SPD should specify whether a packet should be=20 discarded, should bypass any IPsec processing, requires authentication, or=20 requires authentication and encryption. Whether several packets are combined on=20 the same SA is not important. [yes it is. By allowing an administrator the=20 ability to select the granularity of protection, one can control the level of=20 partial traffic flow confidentiality offered between security gateways. Also,=20 fine-grained access control allows an admin to allow some forms of connections=20 through the gateway, while rejecting others. Access control is often the=20 primary, underlying motivation for using IPsec. A number of attacks become=20 possible if one cannot tightly bind the authentication provided by IPsec to the=20 access control decision. Also, given the computational costs of SA establishment=20 via IKE, it is important to allow an administrator to select the granularity of=20 SAs.] The same holds for the exact choice of cryptographic algorithm: any good=20 algorithm will do. There are two reasons for this. First of all, nobody ever=20 attacks a system by cryptanalysis. Instead, attacks are made on the users,=20 implementation, management, etc. Any reasonable cryptographic algorithm will=20 provide adequate protection. The second reason is that there are very efficient=20 and secure algorithms available. Two machines should negotiate the strongest=20 algorithm that they are allowed. There is no reason to select individual=20 algorithms on an application-by-application basis. [if one were to employ ESP=20 without authentication, because a specific higher layer protocol provided its=20 own authentication, and maybe because the application employed FEC, then one=20 might well imagine using different encryption algorithms, or different modes=20 (e.g., block vs. stream) for different SAs. while I agree that the focus on=20 algorithm agility may be overstated, it does allow communicating parties to=20 select a higher quality algorithm, relative to the mandated default, if they=20 both support that algorithm.]=20 In our opinion, management of the IPsec protocols can be simplified by letting=20 the SPD contain policies formulated at such a higher level. As we argued in=20 section~\ref{sec:complexity}, simplification will strengthen the actual system.=20 [examples provided above illustrate why fine-grained access control is important.] It would be nice if the same high-level approach could be done in relation to=20 the choice of SA end-points. As there currently does not seem to be a reliable=20 automatic method of detecting IPsec-enabled security gateways, we do not see a=20 practical alternative to manual configuration of these parameters. It is=20 questionable whether automatic detection of IPsec-enabled gateways is possible=20 at all. Without some initial knowledge of the other side, any detection and=20 negotiation algorithm can be subverted by an active attacker. [the authors=20 identify a good problem, but it is hardly an unsolvable one. A proposal was put=20 forth (by Bob Moscowtiz, over a year ago) to include records in the DNS analogous to MX records. When one tried to establish an SA to a host "behind" an=20 SG, fetching this record would direct the initiator to an appropriate SG. This=20 solves the SG discovery problem. Other approaches have been put forth in the=20 more recent BBN work on security policy management, which forms the basis for a=20 new IETF WG, chaired by Luis Sanchez. The fact that none of the approaches has=20 been deployed says more about the priorities of IPsec vendors and early adopters=20 than about the intractability of the problem. The other part of the problem is=20 verifying that an SG is authorized to represent the SA target. Here too, various=20 approaches have been described on the IPsec mailing list.] \section{General comments} This section contains general comments that came up during our evaluation of=20 IPsec.=20 \begin{enumerate} \item In \cite[p.\ 22]{RFC2401}, several fields in the SAD are required for all=20 implementations, but only used in some of them. It does not make sense to=20 require the presence of fields within an implementation. Only the external=20 behavior of the system should be standardized. [the SAD defined in 2401 is=20 nominal, as the text explains. An implementation is not required to implement=20 these fields, but must exhibit behavior consistent with the presence of these=20 fields. We were unable to specify external behavior without reference to a=20 construct of this sort. The SPD has the same property.] \item According to \cite[p.\ 23]{RFC2401}, an SA can be either for transport=20 mode, tunnel mode, or ``wildcard,'' in which case the sending application can=20 choose the mode on a packet-by-packet basis. Much of the rest of the text does=20 not seem to take this possibility into account. It also appears to us to be=20 needless complexity that will hardly every be used, and is never a necessity. We=20 have already argued that transport mode should be eliminated, which implies that=20 this option is removed too. If transport mode is to be retained, we would=20 certainly get rid of this option. [I agree, but at least one knowledgeable WG=20 member was quite adamant about this. So, chalk it up to the committee process!] \item IPsec does not allow replay protection on an SA that was established using=20 manual key management techniques. This is a strange requirement. We realize that=20 the replay protection limits the number of packets that can be transmitted with=20 the SA to $2^{32}-1$. Still, there are applications that have a low data rate=20 where replay protection is important and manual keying is the easiest solution.=20 [elsewhere this critique argues for not presenting options in a standard that=20 can be misconfigured. Yet here, the authors make an argument for just such an=20 option! The WG decided that there was too great a chance that a manually keyed=20 SA would fail to maintain counter state across key lifetime and thus made a=20 value judgement to ban anti-replay in this context.] \item \cite[section 5.2.1, point 3]{RFC2401} suggests that an implementation can=20 find the matching SPD entry for a packet using back-pointers from the SAD=20 entries. In general this will not work correctly. Suppose the SPD contains two=20 rules: the first one outlaws all packets to port $X$, and the second one allows=20 all incoming packets that have been authenticated. An SA is set up for this=20 second rule. The sender now sends a packet on this SA addressed to port $X$.=20 This packet should be refused as it matches the first SPD rule. However, the=20 backpointer from the SA points to the second rule in the SPD, which allows the=20 packet. This shows that back-pointers from the SA do not always point to the=20 appropriate rule, and that this is not a proper method of finding the relevant=20 SPD entry. [this is point #3 and is applied only after points #1 and #2. Since=20 point #1 calls for a liner search of the SPD, the packet would be rejected, as=20 required. Thus point #3 is not in error.] \item The handling of ICMP messages as described in \cite[section 6]{RFC2401} is=20 unclear to us. It states that an ICMP message generated by a router must not be=20 forwarded over a transport-mode SA, but transport mode SAs can only occur in=20 hosts. By definition, hosts do not forward packets, and a router never has=20 access to a transport-mode SA. [the text in the beginning of section 6 is=20 emphasizing that an SA from a router to a host or security gateway, must be a=20 tunnel mode SA, vs. a transport mode SA. If we didn't make this clear, someone=20 might choose to establish a transport mode SA from an intermediate system, and=20 this would cause the source address checks to fail under certain circumstances,=20 as noted by the text.]=20 The text further suggests that unauthenticated ICMP messages should be disregarded. This creates problems. Let us envision two machines that are=20 geographically far apart and have a tunnel-mode SA set up. There are probably a=20 dozen routers between these two machines that forward the packets. None of these=20 routers knows about the existence of the SA. Any ICMP messages relating to the=20 packets that are sent will be unauthenticated and unencrypted. Simply discarding=20 these ICMP messages results in a loss of IP functionality. This problem is=20 mentioned, but the text claims this is due to the routers not implementing=20 IPsec. Even if the routers implement IPsec, they still cannot send authenticated=20 ICMP messages about the tunnel unless they themselves set up an SA with the=20 tunnel end-point for the purpose of sending the ICMP packet. The tunnel end- point in turn wants to be sure the source is a real router. This requires a=20 generic public-key infrastructure, which does not exist. [RFC 2401 clearly=20 states the dangers associated with blindly accepting unauthenticated ICMP=20 messages, and the functionality problems associated with discarding such=20 messages. System administrators are provided with the ability to make this=20 tradeoff locally. The first step to addressing this problem is the addition of=20 IPsec into routers, as stated in the RFC. Only then does one face the need to=20 have a PKI that identifies routers. Yes, this second PKI does not exist, but a=20 subset of it (at BGP routers) might be established if the S-BGP technology is=20 deployed. These are the routers most likely to issue ICMP PMTU messages. So, the=20 answer here is that the specifications allow site administrators to make=20 security/functionality tradeoffs, locally. The longer term solution described=20 would require routers to implement IPsec, so that they can send authenticated=20 ICMP messages. Yes, this would require a PKI, but such a PKI may arise for other=20 reasons.] As far as we understand this problem, this is a fundamental compatibility=20 problem with the existing IP protocol that does not have a good solution.=20 \item \cite[section 6.1.2.1]{RFC2401} lists a number of possible ways of=20 handling ICMP PMTU messages. An option that is not mentioned is to keep a=20 limited history of packets that were sent, and to match the header inside the=20 PMTU packet to the history list. This can identify the host where the packet=20 that was too large originated. [the approach suggested by the authors was=20 rejected as imposing too much of a burden on an SG. section 6.1.2.1 offers=20 options (not suggestions) for an SG to respond to ICMP PMTU messages, including=20 heuristics to employ when not enough information is present in the returned=20 header. These options may not as responsive as a strategy that caches traffic on=20 each SA, but they are modest in the overhead imposed. Also, an SA that carries a=20 wide range of traffic (not fine-grained) might not benefit from a limited=20 traffic history, as the traffic that caused the ICMP might well be from a host=20 whose traffic has been flushed from the "limited history."] \item \cite[section 7]{RFC2401} mentions that each auditable event in the AH and=20 ESP specifications lists a minimum set of information that should be included in=20 the audit-log entry. Not all auditable events defined in \cite{RFC2406} include=20 that information.[you're right. Exactly one auditable event in 2406 does not=20 specify the list of data that SHOULD be audited. We'll fix that in the next=20 pass. Furthermore, auditable events in \cite{RFC2401} do not specify such a=20 minimum list of information. [there are exactly 3 events defined as auditable in=20 2401, one of which overlaps with 2406. So, to be more precise, the other 2=20 auditable events defined in 2401 ought to have the minimum data requirements=20 defined. Another good point that we will fix in the next pass.] The=20 documentation should be reviewed to ensure that a minimum list of audit-log=20 information is specified with each auditable event. \item Various algorithm specifications require the implementation to reject=20 known weak keys. For example, the DES-CBC encryption algorithm specifications=20 \cite{RFC2405} requires that DES weak keys are rejected. It is questionable=20 whether this actually increases security. It might very well be that the extra=20 code that this requires creates more security problems due to bugs than are=20 solved by rejecting weak keys. Weak keys are not really a problem in most situations. For DES, it is far less=20 work for an attacker to do an exhaustive search over all possible keys than to=20 wait for an SA that happens to use a weak key. After all, the easiest way for=20 the attacker to detect the weak keys is to try them all. Weak-key rejection is=20 only required for algorithms where detecting the weak key class by the weak=20 cipher properties is significantly less work than trying all the weak keys in=20 question. We recommend that the weak-key elimination requirement be removed. Encryption=20 algorithms that have large classes of weak keys that introduce security weaknesses should simply not be used. [I tend to agree with this analysis. The=20 argument for weak key checking was made by folks who don't understand the=20 cryptographic issues involved, but who are persistent and loud, e.g., Bill=20 Simpson. Ted T'so (co-chair of the WG) and I discussed this problem, and tried=20 to explain it to the list, but were unsuccessful. Another flaw in the committee=20 process.] \item The only mandatory encryption algorithm in ESP is DES-CBC. Due to the very=20 limited key length of DES, this cannot be considered to be very secure. We=20 strongly urge that this algorithm not be standardized but be replaced by a=20 stronger alternative. The most obvious candidate is triple-DES. Blowfish could=20 be used as an interim high-speed solution.\footnote{On a Pentium CPU, Blowfish=20 is about six to seven times faster than triple-DES.} The upcoming AES standard=20 will presumably gain quick acceptance and probably become the default encryption=20 method for most systems. [DES as a default was mandated because of pressure from=20 vendors who, at the time, could not get export permission for 3DES. Triple DES=20 or AES will certainly augment DES as additional, mandatory defaults, and may=20 replace it in the future. ] \item The insistence on randomly selected IV values in \cite{RFC2405} seems to=20 be overkill. It is true that a counter would provide known low Hamming-weight=20 input differentials to the block cipher. All reasonable block ciphers are secure=20 enough against this type of attack. Use of a random generator results in an=20 increased risk of an implementation error that will lead to low-entropy or=20 constant IV values; such an error would typically not be found during testing.=20 [In practice the IV is usually acquired from previous ciphertext output, as=20 suggested in the text for CBC mode ciphers, which is easy to acquire and not=20 likely to result in significant complexity. In hardware assisted environment an=20 RNG is usually available anyway. In a high assurance hardware implementation,=20 the crypto chip would generate the IV.] \item Use of a block cipher with a 64-bit block size should in general be=20 limited to at most $2^{32}$ block encryptions per key. This is due to the=20 birthday paradox. After $2^{32}$ blocks we can expect one collision.\footnote{To=20 get a $10^{-6}$ probability of a collision it should be limited to about=20 $2^{22}$ blocks.} In CBC mode, two equal ciphertexts give the attacker the XOR=20 of two blocks of the plaintext. The specifications for the DES-CBC encryption=20 algorithm \cite{RFC2405} should mention this, and require that any SA using such=20 an algorithm limit the total amount of data encrypted by a single key to a=20 suitable value.=20 \item The preferred mode for using a block cipher in ESP seems to be CBC mode=20 \cite{RFC2451}. This is probably the most widely used cipher mode, but it has=20 some disadvantages. As mentioned earlier, a collision gives direct information=20 about the relation of two plaintext blocks. Furthermore, in hardware=20 implementations each of the encryptions has to be done in turn. This gives a=20 limited parallelism, which hinders high-speed hardware implementations. [first,=20 this is not an intrinsic part of the architecture; one can define different=20 modes for use with existing or different algorithms if the WG is so motivated.=20 Second, current hardware is available at speeds higher than the associated=20 packet processing capability of current IPsec devices, so this does not appear=20 to be a problem for the near term. Transition to AES will decrease the processing burden (relative to 3DES), which may render this concern less=20 serious.] Although not used very often, the counter mode seems to be preferable. The=20 ciphertext of block $i$ is formed as $C_i =3D P_i \oplus E_K( i )$, where $i$ is=20 the block number that needs to be sent at the start of the packet.\footnote{If=20 replay protection is always in use, then the starting $i$-value could be formed=20 as $2^{32}$ times the sequence number. This saves eight bytes per packet.} After=20 more than $2^{32}$ blocks counter mode also reveals some information about the=20 plaintext, but this is less than what occurs in CBC. The big advantage of=20 counter mode is that hardware implementations can parallelize the encryption and=20 decryption process, thus achieving a much higher throughput. [earlier the=20 authors criticize IPsec for a lack of orthogonality, but introducing=20 interdependence between the anti-replay counter and encryption would certainly=20 violate the spirit of the earlier criticism! Counter mode versions of algorithms=20 can be added to the list easily if there is sufficient vendor support.] \item \cite[section 2.3]{RFC2451} states that Blowfish has weak keys, but that=20 the likelihood of generating one is very small. We disagree with these statements. The likelihood of getting two equal 32-bit values in any one 256- entry S-box is about ${256 \choose 2} \cdot 2^{-32} \approx 2^{-17}$. This is an=20 event that will certainly occur in practice. However, the Blowfish weak keys=20 only lead to detectable weaknesses in reduced-round versions of the cipher.=20 There are no known weak keys for the full Blowfish cipher.=20 \item In \cite[section 2.5]{RFC2451}, it is suggested to negotiate the number of=20 rounds of a cipher. We consider this to be a very bad idea. The number of rounds=20 is integral to the cipher specifications and should not be changed at will. Even=20 for ciphers that are specified with a variable number of rounds, the=20 determination of the number of rounds should not be left up to the individual=20 system administrators. The IPsec standard should specify the number of rounds=20 for those ciphers. [I agree that this algorithm spec ought not encourage=20 negotiation of the number of rounds, without specifying a minimum for each=20 cipher, although this gets us into the crypto strength value judgement arena=20 again. Also, the inclusion of 3DES in this table is inappropriate as it is a 48=20 round algorithm, period. So, yes, there is definite room for improvement in=20 this RFC.] \item \cite[section 2.5]{RFC2451} proposes the use of RC5. We urge caution in=20 the use of this cipher. It uses some new ideas that have not been fully analyzed=20 or understood by the cryptographic community. The original RC5 as proposed (with=20 12 rounds) was broken, and in response to that the recommended number of rounds=20 was increased to 16. We feel that further research into the use of data- dependent rotations is required before RC5 is used in fielded systems. [RC5 is=20 not required by IPsec implementations. In the IETF spirit of flexible=20 parameterization of implementations, vendors are free to offer any additional=20 algorithms in addition to the required default. In general, the IETF is not=20 prepared to make value judgements about these algorithms and so one may see RFCs=20 that specify a variety of additional algorithms.] \item \cite[section 2.4]{RFC2406} specifies that the ESP padding should pad the=20 plaintext to a length so that the overall ciphertext length is both a multiple=20 of the block size and a multiple of 4. If a block cipher of unusual block size=20 is used (e.g., 15 bytes), then this can require up to 59 bytes of padding. This=20 padding rule works best for block sizes that are a multiple of 4, which fortunately is the case for most block ciphers. [this padding rule is based=20 primarily on IP packet alignment considerations, not on common block cipher=20 sizes! This is stated in the text.] \item \cite[p.\ 6, point a]{RFC2406} states that the padding computations of the=20 ESP payload with regard to the block size of the cipher apply to the payload=20 data, excluding the IV (if present), Pad Length, and Next Header fields. This=20 would imply that the Pad Length and Next Header fields are not being encrypted.=20 Yet the rest of the specification is clear that the Pad Length and Next Header=20 field are to be encrypted, which is what should happen. The text of point a=20 should be made consistent with the rest of the text. [The text says "=8Athe=20 padding computation applies to the Payload Data exclusive of the IV, the Pad=20 Length, and Next Header fields." The comma after "IV" is meat to terminate the=20 scope of the word "exclusive," and thus the intent is to include the pad length=20 and next header fields. The term "payload" in ESP applies to a set of data not=20 including the latter two fields, so the sentence is, technically, unambiguous,=20 and it is consistent with the terms employed in the figure in section 2. But, I=20 admit the wording could be improved.] \item There is a document that defines the NULL encryption algorithm used in ESP=20 \cite{RFC2410}, but no document that defines the NULL authentication algorithm,=20 which is also used by ESP \cite[section 5]{RFC2406}. [good point. Another RFC=20 publication opportunity!] \item The NULL cipher specifies an IV length of zero \cite{RFC2410}. This would=20 seem to imply that the NULL cipher is used in CBC mode, which is clearly not the=20 case. The NULL cipher is in fact used in ECB mode, which does not require an IV.=20 Therefore, no IV length should be specified. [use of the NULL cipher in ECB mode=20 would be inconsistent with the guidance in FIPS 82, and thus CBC mode is=20 intended, to preserve the confidentiality characteristics inherent in this=20 cipher :-).] \end{enumerate} \section{Conclusions} The IPsec system should be simplified significantly. This can be done without=20 loss of functionality or performance. There are also some security weaknesses=20 that should be fixed. [the extensive comments above illustrate that the proposed=20 changes to IPsec would change the functionality, contrary to the claim made=20 here. One might argue about the importance of some of this functionality, but=20 several examples have been provided to illustrate application contexts that the=20 authors of this report did not consider in their analysis. Several=20 misunderstandings of some RFCs also were noted.]=20 Due to its high complexity, we have not been able to analyze IPsec as thoroughly=20 as we would have liked. After simplification, a new security analysis should be=20 performed. I have not reviewed the ISAKMP/IKE comments. However, I agree that this protocol=20 is very complex. Much of the complexity results of incremental enhancement and a=20 reluctance on the part of developers to discard older versions of code. --============_-1263317047==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jan 26 09:59:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03593; Wed, 26 Jan 2000 09:59:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29298 Wed, 26 Jan 2000 11:02:27 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14479.7023.285342.512075@thomasm-u1.cisco.com> Date: Wed, 26 Jan 2000 08:06:07 -0800 (PST) To: Jan Vilhuber Cc: Allen_Rochkind@3com.com, ipsec@lists.tislabs.com Subject: Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability In-Reply-To: References: <88256872.001A83D8.00@hqoutbound.ops.3com.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > On Tue, 25 Jan 2000 Allen_Rochkind@3com.com wrote: > > > > > > At the recent VPN bakeoff, several vendors REQUIRED the peer to send a > > Certificate Request payload during the IKE main mode exchange (using > > signature authentication) in order for their system to send the peer its > > certificate (i.e. no Certificate Request payload received results in no > > certificate being sent back to the peer in the final main mode exchange). > > Makes sense to me. Certs can be large and I might have cached it the last > time I asked you. If I don't ask you to send me one, don't send it. Would this not potentially be a security hole on the side that didn't request the certificate? Say, the cert was password protected, or came from a smart card or something like that, the cached cert would be stale. I'm not necessarily disagreeing with the conclusion, except that maybe if it's allowed, that the potential holes should be pointed out. > issues raised at VPN interoperability workshop, Dan Harkins > , Tue, 18 Jan 2000 16:05:44 -0800 (PST) > > * What does an empty cert request payload mean? > > "give me a cert; any cert". > > > Personally, I find that a bit hard to believe, since I might send you a > certificate from CA FOOBAR, which you've never heard of, so I'm not sure what > good an empty CERT_REQ will do you, but that was the consensus. > > I guess if you are willing to send empty CERT_REQs you are implying that you > can handle EVERY possible known CA on the planet (and beyond!). One possible use is where the distinguished name and the signing CA are basically just for human consumption. Take for example two IP Phones which want to do end to end crypto, but where there isn't an agreed upon authority to name the phones or the user of the phone. The calling phone may want to say: "give me cert x, cert y, or if all else fails whatever you think is appropriate." In the latter case, the phone would display the "whatever" certificate to the user and they could make their own decision -- sort of a glorified caller ID. Mike From owner-ipsec@lists.tislabs.com Wed Jan 26 12:28:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11228; Wed, 26 Jan 2000 12:28:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29875 Wed, 26 Jan 2000 13:30:31 -0500 (EST) Message-ID: <4A957E026DFED211B6D00060081FE03858FB47@scratchy.int.alli.com> From: "Eorgoff, Michael" To: "'IPsec'" Subject: IPsec & SNMP Date: Wed, 26 Jan 2000 12:34:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there any reason to implement an SNMP interface to IPsec? Would this be opening the door to too many security problems? Mike Eorgoff AEG Server Development MDSI Mobile Data Solutions One Pierce Place, Suite 1300W Itasca, IL 60143 USA Phone: 630-875-8644 Fax: 630-775-1552 mailto:meorgoff@mdsi-usa.com http://www.mdsi-advantex.com From owner-ipsec@lists.tislabs.com Wed Jan 26 12:52:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11891; Wed, 26 Jan 2000 12:52:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00131 Wed, 26 Jan 2000 14:11:27 -0500 (EST) Message-Id: <4.2.1.20000126111136.00bd9af0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 26 Jan 2000 11:17:30 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability In-Reply-To: <14479.7023.285342.512075@thomasm-u1.cisco.com> References: <88256872.001A83D8.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:06 AM 1/26/00 -0800, Michael Thomas wrote: > Would this not potentially be a security hole on > the side that didn't request the certificate? Say, > the cert was password protected, or came from a > smart card or something like that, the cached cert > would be stale. PKIX certs are not password-protected. They are also designed to be full cacheable: they have a start and end date. The cert can, of course, be revoked, but that has nothing to do with its freshness. > One possible use is where the distinguished name > and the signing CA are basically just for human > consumption. Take for example two IP Phones which > want to do end to end crypto, but where there isn't > an agreed upon authority to name the phones or the > user of the phone. The calling phone may want to > say: "give me cert x, cert y, or if all else fails > whatever you think is appropriate." In the latter > case, the phone would display the "whatever" > certificate to the user and they could make their > own decision -- sort of a glorified caller ID. Not really. A certificate that doesn't chain to a root you trust is inherently useless for identity. It would be trivial to forge them. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jan 26 13:45:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12619; Wed, 26 Jan 2000 13:45:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00226 Wed, 26 Jan 2000 14:46:17 -0500 (EST) Message-Id: <388F502A.BDB20030@lucent.com> Date: Wed, 26 Jan 2000 14:51:06 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: "Eorgoff, Michael" Cc: "'IPsec'" Subject: Re: IPsec & SNMP References: <4A957E026DFED211B6D00060081FE03858FB47@scratchy.int.alli.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sure. SNMP V3 is somewhat secure. Authentication with DES only encryption. With additional access and firewall policies, it can be made more secure. Another alternative is SNMP over IPSec Transport mode. Eric "Eorgoff, Michael" wrote: > Is there any reason to implement an SNMP interface to IPsec? Would this be > opening the door to too many security problems? > > Mike Eorgoff > AEG Server Development > MDSI Mobile Data Solutions > One Pierce Place, Suite 1300W > Itasca, IL 60143 USA > Phone: 630-875-8644 > Fax: 630-775-1552 > mailto:meorgoff@mdsi-usa.com > http://www.mdsi-advantex.com From owner-ipsec@lists.tislabs.com Wed Jan 26 13:50:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12768; Wed, 26 Jan 2000 13:50:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00349 Wed, 26 Jan 2000 15:20:00 -0500 (EST) From: Allen_Rochkind@3com.com X-Lotus-FromDomain: 3COM To: Jan Vilhuber cc: ipsec@lists.tislabs.com Message-ID: <88256872.006FE9B2.00@hqoutbound.ops.3com.com> Date: Wed, 26 Jan 2000 12:25:23 -0800 Subject: Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you so much for your clear response. I am glad you interpret receiving multiple cert request payloads as an opportunity to scan for one until you find in your own cert cache one which has a root that matches the info in one of the cert payloads. I am concerned that some of the other vendors might not interpret multiple cert requests received in that way due to the verbage in ISAKMP, Section 3.10: "If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted". This gives me the wrong impression on the use of multiple cert requests. I would want to send multiple cert request payloads NOT because I necessarily want multiple certificates. I would send them because I support multiple roots and hope that one of the roots is supported by the peer and so I give you the list of roots I support so that you can choose an entity cert (or certificate chain) to send me rooted on one of these. Probably ISAKMP should rather say something like this: "If multiple root certificate authority certificates are supported by a device, then it SHOULD send a separate certificate payload for each of these certificate authority roots. On receiving multiple certificate request payloads, the responder MUST send at least one end entity certificate (or certificate chain) that is rooted on one of these certificate authorities if it is available." At the VPN bakeoff group meeting, I even questioned the utility of certificate request payloads. This mostly seems like an optimization. If vendors, having negotiated the use of certificates for IKE authentication, were to always send a certificate regardless of receiving a certificate request payload, then the worst that can happen is that there is additional certificate content in the IKE messages exchanged (when it might not be necessary) and that a certificate selected by one side does not have a corresponding root recognized by the peer and the negotiation fails. The certificate request payloads streamlines the protocol by preventing long certificate content being sent when: 1. As you mentioned, one side has already cached the other side's certificate information 2. When repositories are available (like LDAP directories) that can store certificates, which can be fetched directly without asking for them from the peer. The question arises in this case as to how a device knows how to fetch from the repository the peer's certificate (e.g. what distinguished name to use in the directory READ request). Probably some policy configuration would be needed to correlate peer identity with the repository fetching info (like distinguished name). Using an empty certificate request (i.e. with no "certificate authority" field) as agreed upon by the VPN bakeoff group runs the same risk as not sending a certificate request payload and having the vendor just interpret this as to return some certificate. If the certificate returned matches a root maintained by the device, then fine (with everything else being validated) the certificate is validated. If the cert returned happens not to have a root that is trusted by the device, then the negotiation will fail. So what difference is there between sending empty certificate requests and not sending any and requiring that the peer always respond with some certificate outside of the optimization of preventing unnecessary long IKE message (with unneeded cert content)? The only other place where certificate requests may have utility is if the peer receiving the request actually has multiple end entity certificates, each one issued by a different root. In that case a device should issue the cert request payload so that the peer can choose the right one to improve chances of interoperability. However, what I questioned is whether a device having multiple end entity certs, each issued by a different root, is realistic. Each device belongs in general to one security domain, with some administrator managing the security attributes of that device. Generally the certificate issued to the device authenticates the keys generated for use minimally within that domain. If there was another certificate issued by another CA to that device, then we would have 2 security domains authenticating the single device. (This is different than the valid situation in which one CA issues multiple certs to the device, say, for different keys or different applications with different extensions for the same keys.) So I was questioning whether having a single device authenticated by 2 domains makes sense. If it does, I would appreciate someone giving me a realistic scenario and where this applies. If such a scenario exists, this will ease my concerns considerably about the utility of certificate request payloads. I thank anyone who can help me in this matter. Jan Vilhuber on 01/25/2000 09:39:14 PM Sent by: Jan Vilhuber To: Allen Rochkind/HQ/3Com cc: ipsec@lists.tislabs.com Subject: Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability On Tue, 25 Jan 2000 Allen_Rochkind@3com.com wrote: > > > At the recent VPN bakeoff, several vendors REQUIRED the peer to send a > Certificate Request payload during the IKE main mode exchange (using > signature authentication) in order for their system to send the peer its > certificate (i.e. no Certificate Request payload received results in no > certificate being sent back to the peer in the final main mode exchange). Makes sense to me. Certs can be large and I might have cached it the last time I asked you. If I don't ask you to send me one, don't send it. > Looking at the ISAKMP spec (Section 3.10) it appears that only one > Certificate Authority DER encoded distinguished name (for X.509 certificate > type) can appear in the certificate request payload. Normally if the 2 > systems in the exchange were in the same security domain governed by a > single root CA, one peer would put the distinguished name of that CA's > certificate subject in the payload and the other system would then choose > to send back a chain of certs rooted on that CA. Ahm.. not "choose to send back". The rfc says: "The responder to the Certificate Request payload MUST send its certificate, if certificates are supported...". > However, in the case of > extranet interaction in which it is possible that a given system might > interact with several different security domains (each with its own CA) it > is unclear what certificate authority distinguished name should be put in > the certificate request payload. E.g. it may be possible that the local > system trusts several different roots to handle the diversity of different > extranet security domains it wants to deal with. In any given IKE exchange > it would not know in advance which certificate authority it should ask in > the certificate payload to be the root of the returned certificate > requested unless there is some elaborate policy mapping between identities > and trusted root CAs at the other end. > > To maximize interoperability, should one send multiple certificate > requests, each corresponding to a CA that is trusted, and hope that the > responder will find in one of the certificate request payloads the > distinguished name for the root certificate that its end entity certificate > is based on? Yes. The rfc talks about 'Certificate Request payloads', i.e. plural, so I would assume it's perfectly legal to send multiples. We tested with a few vendors in San Diego that did this. > Alternatively ISAKMP says, "If there is no specific > certificate authority requested, this field [the Certificate Authority > field] SHOULD not be included." Then would it be safer to ensure > interoperability to simply send one certificate request always with no > "Certificate Authority" field entered in the certificate request payload? Depends on what you believe is right (see below). > If that is so, what good does sending a certificate request payload do? As was established by consensus at the bakeoff, an empty CERT_REQ payload means "send me any cert at all". See message: issues raised at VPN interoperability workshop, Dan Harkins , Tue, 18 Jan 2000 16:05:44 -0800 (PST) * What does an empty cert request payload mean? "give me a cert; any cert". Personally, I find that a bit hard to believe, since I might send you a certificate from CA FOOBAR, which you've never heard of, so I'm not sure what good an empty CERT_REQ will do you, but that was the consensus. I guess if you are willing to send empty CERT_REQs you are implying that you can handle EVERY possible known CA on the planet (and beyond!). > What is the practice of the various vendors that send certificate request > payloads or expect other vendors to send them in order to send back their > own certificate chains in the IKE exchange? > - If we don't get a CERT_REQ, we won't send a cert. - If we receive multiple cert-requests, we blue-screen. Just kidding: We go through them one by one and the first one we have a cert for, we send it (we might even send multiple, i.e. signature and key exchange, if you asked for both) - If we get an empty CERT_REQ, we won't honor it and fail the exchange (probably not the right thing to do either, in light of the consensus mentioned above). I'll probably change that to send you the first one on my list (for whatever that's worth). Maybe I'll even keep a counter of how many times a certain cert was requested and send you the one that was LEAST requested, just so it doesn't feel left out ;) jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Jan 26 15:30:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15041; Wed, 26 Jan 2000 15:30:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00517 Wed, 26 Jan 2000 15:58:05 -0500 (EST) Message-ID: <388F6146.2D9000E8@redcreek.com> Date: Wed, 26 Jan 2000 13:04:06 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Eorgoff, Michael" CC: "'IPsec'" Subject: Re: IPsec & SNMP References: <4A957E026DFED211B6D00060081FE03858FB47@scratchy.int.alli.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Eorgoff, Michael" wrote: > > Is there any reason to implement an SNMP interface to IPsec? Would this be > opening the door to too many security problems? > What do you mean by "an SNMP interface to IPsec"? From owner-ipsec@lists.tislabs.com Wed Jan 26 15:51:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15295; Wed, 26 Jan 2000 15:51:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00856 Wed, 26 Jan 2000 17:31:59 -0500 (EST) Message-Id: <4.2.1.20000126143212.04f11af0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 26 Jan 2000 14:37:47 -0800 To: Allen_Rochkind@3com.com, Jan Vilhuber From: Paul Hoffman Subject: Re: Request for Clarification of Usage of Certificate Request Payload to Maximimze Interoperability Cc: ipsec@lists.tislabs.com In-Reply-To: <88256872.006FE9B2.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:25 PM 1/26/00 -0800, Allen_Rochkind@3com.com wrote: >However, what I questioned is whether a device having >multiple end entity certs, each issued by a different root, is realistic. And many people responded that it was. Think extranets where each security gateway trusts only a CA controlled by the company that owns the gateway. Think VPN clients that are used by people who talk to more than one security gateway at different companies. > Each >device belongs in general to one security domain, with some administrator >managing the security attributes of that device. I do not think this matches the business model of many companies in the VPN business. There is a wide expectation that companies will use IPsec-and-firewall boxes for controlling ingress of trusted outsiders to their resources. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jan 27 07:52:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22442; Thu, 27 Jan 2000 07:52:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03325 Thu, 27 Jan 2000 09:05:12 -0500 (EST) Date: Thu, 27 Jan 2000 15:42:02 +0200 (EET) Message-Id: <200001271342.PAA14537@lmf3ws53.lmf.ericsson.se> To: ipsec@lists.tislabs.com From: jari.arkko@ericsson.com Cc: jari.arkko@ericsson.com Subject: Notify SPI field specifications Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. In the San Diego bakeoff I was studying the RFCs with somebody and we noticed some strange descriptions for the Notify SPI field. Here's what RFC 2408 says in section "3.14 Notification Payload": > o SPI (variable length) - Security Parameter Index. The receiving > entity's SPI. The use of the SPI field is described in section And RFC 2407 says in section "4.6.3.1 RESPONDER-LIFETIME": > o SPI - set to the two ISAKMP cookies or to the sender's inbound > IPSEC SP I find the latter description quite clear. But the one in RFC 2408 is quite unclear and possibly even contradictory to it. In the RFC 2408 description, what is "receiving entity"? Is it the one receiving the notification? If so, then which SPI does it have? The incoming? If so, the RFC 2408 proposes the use of Notification-Receivers-Inbound-SPI i.e. Notification-Senders-Outbound-SPI which is not the same as Notification-Senders-Inbound-SPI in RFC 2407... Even if I'm to ignore the SPI value for phase 1, the specifications also disagree, I think, upon the value that should be put to the SPI field for phase 1. Again from the same sections in these two RFCs: RFC 2408: > The Protocol Identifier, in this case, is > ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP > Header identifies the ISAKMP SA. RFC 2407: > o SPI - set to the two ISAKMP cookies or to the sender's inbound > IPSEC SPI That is, RFC 2408 proposes zero and RFC 2407 the cookies. Also, I found it quite funny for RFC 2407 to say in the description of the SPI Size field that "If the SPI Size is non-zero, the content of the SPI field MUST be ignored.". If the SPI Size is zero, I am expected to check the SPI field! If I understood this right, the specification should have said perhaps "The SPI Size and SPI fields MUST be ignored for phase 1." Jari Arkko Ericsson From owner-ipsec@lists.tislabs.com Thu Jan 27 07:53:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22478; Thu, 27 Jan 2000 07:53:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03326 Thu, 27 Jan 2000 09:05:13 -0500 (EST) Message-ID: From: P A Centre Visitor Subject: RE: IEEE ICON' 2000 Conference - Call for Papers, Tutorials ... Date: Thu, 27 Jan 2000 15:48:17 +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 Dear All >The 8th IEEE International Conference On Networks will be held from >September 5- 8, 2000 in Singapore. ]The aim of the conference is to >provide >an international forum for experts to promote, share and discuss various >>issues and developments in the broad field of computer and communication networks. >>We thus seek and solicit your contributions >in the form of original/unpublished papers, tutorials, and topics for >special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can >>>be obtained at this web site : http://www.comp.nus.edu.sg/~icon/ > >We look forward to your participation. Thank you. > >Icon 2000 organizing Committee Best Regards Catherine Kua (Mrs) ICON Secretariat c/o Professional Activities Centre Faculty of Engineering Tel: (65) 8745113 Fax: (65) 8745097 Email: engpac@nus.edu.sg From owner-ipsec@lists.tislabs.com Thu Jan 27 07:54:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22498; Thu, 27 Jan 2000 07:54:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03327 Thu, 27 Jan 2000 09:05:13 -0500 (EST) Date: Thu, 27 Jan 2000 15:07:27 +0200 (EET) Message-Id: <200001271307.PAA14461@lmf3ws53.lmf.ericsson.se> To: ipsec@lists.tislabs.com Cc: jari.arkko@ericsson.com From: jari.arkko@ericsson.com Subject: Simultaneous connection attempts Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. I'm trying to understand the ISAKMP/IKE specifications with respect to what happens when, for some reason, both hosts start initiating a connection at the same time. My first concern when I started looking at this was a system where something - memory, CPU, or user interface - places limits on the number of SAs open to a particular host. In such a system it would not be desireable to hold open two ISAKMP SAs. Rather, it would be nice if the other SA creation could simply be refused. However, it is not clear to me if this is possible. If both ends implement a scheme where they e.g. refuse another incoming ISAKMP connection from a host they have themselves just started negotiating with, then both attempts will fail. That is, if both hosts start their initiating-side negotiations at the same time or within end-to-end delay time, then both think they were the first. I would appreciate pointers or comments from the members of this list regarding how such situations should be handled, if they can be handled. It is also necessary that any mechanism for this purpose allows renegotiation of expiring SAs, and works both for phase 1 and phase 2. Secondly, it is not clear to me how INITIAL-CONTACT works in this particular case. If both sides think they are the first, then they must include INITIAL-CONTACT as a part of the phase 1 negotiation. Wouldn't this mean that both sides will delete their own connection as they receive the final packets from the connection initiated by the other host? Here's the sequence of events (assuming main mode and INITIAL-CONTACT as a part of the last message): Time What ------------ t+0 A initiates SA0 by sending the first request packet B initiates SA1 by sending the first request packet t+1 B receives first packet of request for SA0 A receives first packet of request for SA1 t+2 ... (negotiations proceed) ... t+3 B is ready with SA0, sends A the last message, and deletes SA1 because A said INITIAL-CONTACT A is ready with SA1, sends B the last message, and deletes SA0 because B said INITIAL-CONTACT t+4 A receives the final packet for already deleted SA0 B receives the final packet for already deleted SA1 In the end both hosts have one side of an SA ready, but not matching sides of the same SA! Is this a problem or have I missed something? Jari Arkko Ericsson From owner-ipsec@lists.tislabs.com Thu Jan 27 10:18:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25605; Thu, 27 Jan 2000 10:18:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03987 Thu, 27 Jan 2000 11:15:42 -0500 (EST) Message-ID: <392A357CE6FFD111AC3E00A0C99848B001F04166@hdsmsx31.hd.intel.com> From: "Georgescu, Cristina" To: ipsec@lists.tislabs.com Subject: Config mode questions Date: Thu, 27 Jan 2000 08:20:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For a Request/Reply exchange in Config mode: 1. If the gateway wants to send its response to an INTERNAL_IP4_SUBNET attribute request how the response will be sent for both subnet and mask if the attribute length is mentioned into RFC to be 0 or 4 octets for this attribute. How do you specify the mask for the subnet protected? 2. APPLICATION_VERSION attribute can be 0 length or more. Is this one required to be multiple of 2 or 4 octets? If not, when someone request SUPPORTED_ATTRIBUTES, the result should be multiple of 2 (which might not be in case your APPLICATION_VERSION is 7 bytes length for example) 3. Are the attributes required to be aligned at 4 bytes? Thanks in advance. From owner-ipsec@lists.tislabs.com Thu Jan 27 10:25:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25691; Thu, 27 Jan 2000 10:25:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04075 Thu, 27 Jan 2000 11:39:24 -0500 (EST) Date: Thu, 27 Jan 2000 11:29:54 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <4479.000127@lucent.com> To: ipsec@lists.tislabs.com Subject: Very quick, very basic Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please excuse the silliness. The next header field in ESP contains an 8-bit value to represent the header contained within the encrypted payload. So, this is how I read it, please verify the following for me: ESP used in tunnel mode -next header = 4 for IP-in-IP ESP used in transport mode -next header = 6 for TCP. True or false? Or is it reversed? A very grateful thank you in advance. -jim From owner-ipsec@lists.tislabs.com Thu Jan 27 11:57:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27878; Thu, 27 Jan 2000 11:57:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04314 Thu, 27 Jan 2000 12:50:14 -0500 (EST) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B4B6@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Jim Tiller'" , ipsec@lists.tislabs.com Subject: RE: Very quick, very basic Date: Thu, 27 Jan 2000 09:55:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well assuming that you are sending TCP (and not UDP or ICMP) you are correct... Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Jim Tiller [mailto:jtiller@lucent.com] > Sent: Thursday, January 27, 2000 8:30 AM > To: ipsec@lists.tislabs.com > Subject: Very quick, very basic > > > Please excuse the silliness. > > The next header field in ESP contains an 8-bit value to represent the > header contained within the encrypted payload. > So, this is how I read it, please verify the > following for me: > > ESP used in tunnel mode -next header = 4 for IP-in-IP > ESP used in transport mode -next header = 6 for TCP. > > True or false? Or is it reversed? > > A very grateful thank you in advance. > > -jim > > > > From owner-ipsec@lists.tislabs.com Thu Jan 27 11:57:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27895; Thu, 27 Jan 2000 11:57:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04519 Thu, 27 Jan 2000 13:20:35 -0500 (EST) Date: Thu, 27 Jan 2000 13:09:02 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <14547.000127@lucent.com> To: "Strahm, Bill" CC: ipsec@lists.tislabs.com Subject: Re[2]: Very quick, very basic In-reply-To: <7DAA70BEB463D211AC3E00A0C96B7AB20344B4B6@orsmsx41.jf.intel.com> References: <7DAA70BEB463D211AC3E00A0C96B7AB20344B4B6@orsmsx41.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk oops, excellent observation:) Thank you. I was assuming TCP. thnx Thursday, January 27, 2000, 12:55:00 PM, you wrote: SB> Well assuming that you are sending TCP (and not UDP or ICMP) you are SB> correct... SB> Bill SB> ______________________________________________ SB> Bill Strahm Programming today is a race between SB> bill.strahm@ software engineers striving to build SB> intel.com bigger and better idiot-proof programs, SB> (503) 264-4632 and the Universe trying to produce SB> bigger and better idiots. So far, the SB> Universe is winning.--Rich Cook SB> I am not speaking for Intel. And Intel rarely speaks for me >> -----Original Message----- >> From: Jim Tiller [mailto:jtiller@lucent.com] >> Sent: Thursday, January 27, 2000 8:30 AM >> To: ipsec@lists.tislabs.com >> Subject: Very quick, very basic >> >> >> Please excuse the silliness. >> >> The next header field in ESP contains an 8-bit value to represent the >> header contained within the encrypted payload. >> So, this is how I read it, please verify the >> following for me: >> >> ESP used in tunnel mode -next header = 4 for IP-in-IP >> ESP used in transport mode -next header = 6 for TCP. >> >> True or false? Or is it reversed? >> >> A very grateful thank you in advance. >> >> -jim >> >> >> >> From owner-ipsec@lists.tislabs.com Thu Jan 27 12:01:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28025; Thu, 27 Jan 2000 12:01:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04455 Thu, 27 Jan 2000 13:15:00 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0113AF11@exchange> From: Stephane Beaulieu To: "Georgescu, Cristina" , ipsec@lists.tislabs.com Subject: RE: Config mode questions Date: Thu, 27 Jan 2000 13:20:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > For a Request/Reply exchange in Config mode: > > 1. If the gateway wants to send its response to an INTERNAL_IP4_SUBNET > attribute request how the response will be sent for both > subnet and mask if > the attribute length is mentioned into RFC to be 0 or 4 > octets for this > attribute. How do you specify the mask for the subnet protected? The Reply message will contain 2 attributes: INTERNAL_IP4_SUBNET and INTERNAL_IP4_NETMASK. > > 2. APPLICATION_VERSION attribute can be 0 length or more. Is this one > required to be multiple of 2 or 4 octets? If not, when someone request > SUPPORTED_ATTRIBUTES, the result should be multiple of 2 > (which might not be > in case your APPLICATION_VERSION is 7 bytes length for example) > I think you misunderstood the text describing SUPPORTED_ATTRIBUTES. The length of the SUPPORTED_ATTRIBUTES has nothing to do with the lengths of other attributes. The length of SUPPORTED_ATTRIBUTES = # of supported attributes / 2; because the data portion of SUPPORTED_ATTRIBUTES is a list of identifiers, each 2 octets in length. > 3. Are the attributes required to be aligned at 4 bytes? > I think IKE-Cfg follows the general rules of any attribute payload. I don't believe there is any such requirement, but I could be wrong. > Thanks in advance. > From owner-ipsec@lists.tislabs.com Thu Jan 27 12:25:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28560; Thu, 27 Jan 2000 12:25:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04703 Thu, 27 Jan 2000 13:55:28 -0500 (EST) From: "Roy Pereira" To: "Stephane Beaulieu" , "Georgescu, Cristina" , Subject: RE: Config mode questions Date: Thu, 27 Jan 2000 10:57:57 -0800 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) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0113AF3A@exchange> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, it is an ip4 address followed by an ip4 subnet (8 bytes). -----Original Message----- From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] Sent: Thursday, January 27, 2000 10:51 AM To: Stephane Beaulieu; Georgescu, Cristina; ipsec@lists.tislabs.com Cc: Roy Pereira (E-mail) Subject: RE: Config mode questions > > For a Request/Reply exchange in Config mode: > > > > 1. If the gateway wants to send its response to an > INTERNAL_IP4_SUBNET > > attribute request how the response will be sent for both > > subnet and mask if > > the attribute length is mentioned into RFC to be 0 or 4 > > octets for this > > attribute. How do you specify the mask for the subnet protected? > > The Reply message will contain 2 attributes: INTERNAL_IP4_SUBNET and > INTERNAL_IP4_NETMASK. Sorry, a co-worker just pointed out to me that I was answering a completely different question... (even at that I typed IP4_SUBNET instead of IP4_ADDRESS). My brain must be on vacation today :) If your question was how do you represent the subnet and netmask using only 4 bytes, the answer is... you don't. I think Roy is fixing this in the next rev, to be 0 or 8 bytes. Regards, Stephane. From owner-ipsec@lists.tislabs.com Thu Jan 27 12:30:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28627; Thu, 27 Jan 2000 12:30:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04633 Thu, 27 Jan 2000 13:45:18 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0113AF3A@exchange> From: Stephane Beaulieu To: Stephane Beaulieu , "Georgescu, Cristina" , ipsec@lists.tislabs.com Cc: "Roy Pereira (E-mail)" Subject: RE: Config mode questions Date: Thu, 27 Jan 2000 13:51:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > For a Request/Reply exchange in Config mode: > > > > 1. If the gateway wants to send its response to an > INTERNAL_IP4_SUBNET > > attribute request how the response will be sent for both > > subnet and mask if > > the attribute length is mentioned into RFC to be 0 or 4 > > octets for this > > attribute. How do you specify the mask for the subnet protected? > > The Reply message will contain 2 attributes: INTERNAL_IP4_SUBNET and > INTERNAL_IP4_NETMASK. Sorry, a co-worker just pointed out to me that I was answering a completely different question... (even at that I typed IP4_SUBNET instead of IP4_ADDRESS). My brain must be on vacation today :) If your question was how do you represent the subnet and netmask using only 4 bytes, the answer is... you don't. I think Roy is fixing this in the next rev, to be 0 or 8 bytes. Regards, Stephane. From owner-ipsec@lists.tislabs.com Thu Jan 27 13:39:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29656; Thu, 27 Jan 2000 13:39:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04988 Thu, 27 Jan 2000 14:53:29 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0113AFB5@exchange> From: Stephane Beaulieu To: "Mason, David" , Stephane Beaulieu , "Georgescu, Cristina" , ipsec@lists.tislabs.com Subject: RE: Config mode questions Date: Thu, 27 Jan 2000 15:00:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, sorry. I was reading and typing INTERNAL_IP4_SUBNET, but my brain was thinking INTERNAL_IP4_ADDRESS. I later posted a correction. Sorry for the confusion. Stephane. > -----Original Message----- > From: Mason, David [mailto:David_Mason@NAI.com] > Sent: Thursday, January 27, 2000 2:51 PM > To: 'Stephane Beaulieu'; Georgescu, Cristina; ipsec@lists.tislabs.com > Subject: RE: Config mode questions > > > From discussions with you and Roy at the bakeoff I was under > the impression that in Section 3.4 of mode-cfg.05 it was > supposed to be as follows. > > INTERNAL_IP4_SUBNET ............ 0 or 8 octets > > > o INTERNAL_IP4_SUBNET ..... 4 octets for the sub-network > address followed by 4 octets for the sub-network netmask ..... > > > Under INTERNAL_IPX_NETMASK it states that only one netmask > is allowed in the reply - having the SUBNET attribute contain > both the address and mask simplifies matching subnets with > masks when there are multiple internal subnets. > > > NB: data attributes having to be 4 byte multiples was dropped > in ISAKMP ID version 9 or 10. Since the 4 byte multiple wording > does not exist in the RFC I would take that to mean that variable > length attributes MUST NOT be padded to 4 byte multiples (which > makes sense seeing as none of the other payloads have any > alignment requirements that I'm aware of). > > -dave > > -----Original Message----- > From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] > Sent: Thursday, January 27, 2000 1:21 PM > To: Georgescu, Cristina; ipsec@lists.tislabs.com > Subject: RE: Config mode questions > > > > > > For a Request/Reply exchange in Config mode: > > > > 1. If the gateway wants to send its response to an > INTERNAL_IP4_SUBNET > > attribute request how the response will be sent for both > > subnet and mask if > > the attribute length is mentioned into RFC to be 0 or 4 > > octets for this > > attribute. How do you specify the mask for the subnet protected? > > The Reply message will contain 2 attributes: INTERNAL_IP4_SUBNET and > INTERNAL_IP4_NETMASK. > > > > > 2. APPLICATION_VERSION attribute can be 0 length or more. > Is this one > > required to be multiple of 2 or 4 octets? If not, when > someone request > > SUPPORTED_ATTRIBUTES, the result should be multiple of 2 > > (which might not be > > in case your APPLICATION_VERSION is 7 bytes length for example) > > > > I think you misunderstood the text describing > SUPPORTED_ATTRIBUTES. The > length of the SUPPORTED_ATTRIBUTES has nothing to do with the > lengths of > other attributes. The length of SUPPORTED_ATTRIBUTES = # of supported > attributes / 2; because the data portion of > SUPPORTED_ATTRIBUTES is a list > of identifiers, each 2 octets in length. > > > > 3. Are the attributes required to be aligned at 4 bytes? > > > > I think IKE-Cfg follows the general rules of any attribute > payload. I don't > believe there is any such requirement, but I could be wrong. > > > Thanks in advance. > > > From owner-ipsec@lists.tislabs.com Thu Jan 27 13:45:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29732; Thu, 27 Jan 2000 13:45:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04959 Thu, 27 Jan 2000 14:48:20 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B788F0F@md-exchange1.nai.com> From: "Mason, David" To: "'Stephane Beaulieu'" , "Georgescu, Cristina" , ipsec@lists.tislabs.com Subject: RE: Config mode questions Date: Thu, 27 Jan 2000 11:50:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From discussions with you and Roy at the bakeoff I was under the impression that in Section 3.4 of mode-cfg.05 it was supposed to be as follows. INTERNAL_IP4_SUBNET ............ 0 or 8 octets o INTERNAL_IP4_SUBNET ..... 4 octets for the sub-network address followed by 4 octets for the sub-network netmask ..... Under INTERNAL_IPX_NETMASK it states that only one netmask is allowed in the reply - having the SUBNET attribute contain both the address and mask simplifies matching subnets with masks when there are multiple internal subnets. NB: data attributes having to be 4 byte multiples was dropped in ISAKMP ID version 9 or 10. Since the 4 byte multiple wording does not exist in the RFC I would take that to mean that variable length attributes MUST NOT be padded to 4 byte multiples (which makes sense seeing as none of the other payloads have any alignment requirements that I'm aware of). -dave -----Original Message----- From: Stephane Beaulieu [mailto:sbeaulieu@TimeStep.com] Sent: Thursday, January 27, 2000 1:21 PM To: Georgescu, Cristina; ipsec@lists.tislabs.com Subject: RE: Config mode questions > > For a Request/Reply exchange in Config mode: > > 1. If the gateway wants to send its response to an INTERNAL_IP4_SUBNET > attribute request how the response will be sent for both > subnet and mask if > the attribute length is mentioned into RFC to be 0 or 4 > octets for this > attribute. How do you specify the mask for the subnet protected? The Reply message will contain 2 attributes: INTERNAL_IP4_SUBNET and INTERNAL_IP4_NETMASK. > > 2. APPLICATION_VERSION attribute can be 0 length or more. Is this one > required to be multiple of 2 or 4 octets? If not, when someone request > SUPPORTED_ATTRIBUTES, the result should be multiple of 2 > (which might not be > in case your APPLICATION_VERSION is 7 bytes length for example) > I think you misunderstood the text describing SUPPORTED_ATTRIBUTES. The length of the SUPPORTED_ATTRIBUTES has nothing to do with the lengths of other attributes. The length of SUPPORTED_ATTRIBUTES = # of supported attributes / 2; because the data portion of SUPPORTED_ATTRIBUTES is a list of identifiers, each 2 octets in length. > 3. Are the attributes required to be aligned at 4 bytes? > I think IKE-Cfg follows the general rules of any attribute payload. I don't believe there is any such requirement, but I could be wrong. > Thanks in advance. > From owner-ipsec@lists.tislabs.com Thu Jan 27 13:47:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29780; Thu, 27 Jan 2000 13:47:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05172 Thu, 27 Jan 2000 15:26:41 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B788F13@md-exchange1.nai.com> From: "Mason, David" To: "'ipsec@lists.tislabs.com'" Subject: Was RE: Config mode questions Date: Thu, 27 Jan 2000 12:28:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >NB: data attributes having to be 4 byte multiples was dropped >in ISAKMP ID version 9 or 10. Since the 4 byte multiple wording >does not exist in the RFC I would take that to mean that variable >length attributes MUST NOT be padded to 4 byte multiples (which >makes sense seeing as none of the other payloads have any >alignment requirements that I'm aware of). Actually the MUST NOT might be a little too strong since when you have a Life Duration value that could be expressed in three octets I think it's reasonable to use 4 octets with the first octet being 0x00. -dave From owner-ipsec@lists.tislabs.com Thu Jan 27 13:47:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29799; Thu, 27 Jan 2000 13:47:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04949 Thu, 27 Jan 2000 14:46:48 -0500 (EST) From: "Fabio" To: Subject: new user Date: Thu, 27 Jan 2000 17:53:41 -0300 Message-ID: <001101bf6908$97a60d00$690100c0@trt20.intra> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01BF68EF.7258D500" 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 V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0012_01BF68EF.7258D500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello, I´m new in the list and i want to take a work about IPSEC. Could anynone send me explanations abou it? Thanks Fábio Bispo ------=_NextPart_000_0012_01BF68EF.7258D500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
 I=B4m new in the=20 list and i want to take a work about IPSEC. Could anynone send me = explanations=20 abou it?
 
Thanks
 
F=E1bio = Bispo
------=_NextPart_000_0012_01BF68EF.7258D500-- From owner-ipsec@lists.tislabs.com Thu Jan 27 13:47:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29813; Thu, 27 Jan 2000 13:47:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05065 Thu, 27 Jan 2000 15:19:20 -0500 (EST) Date: Thu, 27 Jan 2000 14:24:05 -0600 From: Will Fiveash To: ipsec@lists.tislabs.com Subject: Re: issues raised at VPN interoperability workshop Message-ID: <20000127142405.A41146@austin.ibm.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <319A1C5F94C8D11192DE00805FBBADDF0110A1BD@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0110A1BD@exchange>; from tjenkins@TimeStep.com on Wed, Jan 19, 2000 at 09:00:33AM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Regarding the Commit Bit in Quick Mode: See my comments below. On Wed, Jan 19, 2000 at 09:00:33AM -0500, Tim Jenkins wrote: > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > > Sent: January 18, 2000 5:38 PM > > To: ipsec@lists.tislabs.com > > Subject: issues raised at VPN interoperability workshop > > > ... > > > > > Commit Bit > > > > * Can you clear the commit bit during phase 2? > > > > Yes. > > > > What does this mean? > > Is this asking "Can the commit bit be set to 0 in quick mode?" > (This is normal operation, so I doubt this was the question.) > Is this asking "Can the commit bit be set to 0 in the third quick mode > message by the initiator if set in the second by the responder?" > (Probably not supposed to be. One vendor interpreted this as rejection of > the bit, another ignored it. Maybe this should be clarified as well.) I implemented Commit Bit (CB) in Quick Mode (QM) with the following logic. Regardless of whether the AIX IKE daemon is initiator or responder, the administrator can configure it such that the IKE daemon turns CB on in QM only. If the CB is reflected (i.e. turned on) back by the other side then the IKE daemon will assume that the other side will honor the CB and process the QM according to draft-ieft-ipsec-ike-01.txt. If the CB is not reflected back (set to 0) then the IKE daemon will assume that the other side is not processing the CB and will proceed as though the CB was not set (The AIX initiator will not wait for the connect-notify before passing the P2 SA to IPSec. The AIX responder will send a connect-notify just in case but I assume this should not cause a problem if the initiator is not expecting a connect-notify). This logic obviously depends upon the other implementations reflecting (or not) the CB in a consistent manner. I spoke with several developers at the San Diego Bakeoff who felt that this is a reasonable approach allowing implementors to either support or not support the CB without impacting interoperability. If everyone agrees that this is a "good thing" then I think the wording in the draft-ieft-ipsec-ike-02.txt should state the reflecting behavior as a MUST. > Additionally, there was talk about allowing the initiator of a quick mode > exchange to set the commit bit. I'd like to propose that this be explicitly > disallowed, and that it explicitly stated that only the responder of a quick > mode exchange may set the commit bit. > > Reasons: > 1) The benefit is minimal, if any. > 2) It increases complexity. > > Does anyone do this? Does anyone support this case as responder? As I stated above, my implementation can turn on the CB as initiator. I am assuming that if the admin decided they wanted the connect notify sent as additional P2 SA use synchronization they should be able to request that of the responder regardless of whether the responder has CB turned on in their security policy. Again, if the responder chooses not to honor the CB from the initiator the responder can just perform the QM as though the CB was not set (and not reflect the CB). -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec@lists.tislabs.com Thu Jan 27 14:51:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00813; Thu, 27 Jan 2000 14:51:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06085 Thu, 27 Jan 2000 16:13:12 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0113B09E@exchange> From: Andrew Krywaniuk To: Will Fiveash , ipsec@lists.tislabs.com Subject: RE: issues raised at VPN interoperability workshop Date: Thu, 27 Jan 2000 16:19:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If > the CB is not > reflected back (set to 0) then the IKE daemon will assume > that the other > side is not processing the CB and will proceed as though the > CB was not set > (The AIX initiator will not wait for the connect-notify > before passing the > P2 SA to IPSec. The AIX responder will send a connect-notify > just in case > but I assume this should not cause a problem if the initiator is not > expecting a connect-notify). I don't think this is a fair assumption. If I am not expecting a NOTIFY_CONNECTED then I will most likely delete my quick mode object soon after sending QM3. (I will keep it around for a little while in case I need to retransmit.) This creates a race conditions: If your spurious NOTIFY_CONNECTED arrives after I have deleted my quick mode object then I will not know what to do with it. (In fact, I will most likely think that it is a malformed QM1.) > As I stated above, my implementation can turn on the CB as > initiator. I am > assuming that if the admin decided they wanted the connect > notify sent as > additional P2 SA use synchronization they should be able to > request that of > the responder regardless of whether the responder has CB > turned on in their > security policy. Aside from the fact that the CB doesn't really accomplish much unless the peer's implementation queues packets (I suspect that most sgws don't) and yours doesn't... 1. The initiator has ample opportunity to setup his SA before the responder uses it. 2. The initiator was the one who decided to initiate the SA. Therefore, one can conclude that he will also be the first one to use it. The commit bit fixes a race condition that only affects the responder. If the responder wants to send the connected notify then he should set the bit himself. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Jan 27 18:00:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04194; Thu, 27 Jan 2000 18:00:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11587 Thu, 27 Jan 2000 19:23:30 -0500 (EST) Message-ID: <51C0AF25889FD211AC3F00A0C984090D02D30C24@orsmsx50.jf.intel.com> From: "Saint-Hilaire, Ylian" To: "'Andrew Krywaniuk'" , Will Fiveash , ipsec@lists.tislabs.com Subject: RE: issues raised at VPN interoperability workshop Date: Thu, 27 Jan 2000 16:23:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I got a bunch of questions about the Commit bit, it seems it does not make much sense to have the initiator of phase 1 raise CB. If he does, It is not clear what should be done. ---------- If I am the phase 2 responder, and I see the initiator raising CB on the first packet, is it ok for me to voluntarily not echo it back? As a responder, if I wanted to use CB to get the SA in my driver first... by having the initiator raise CB first, I lost my chance to use the CB as intended. Is it correct to assume that generally, the responder of a phase 2 will be the first to raise it? If the initiator raises CB first, the conversation will look like this: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> HDR*, HASH, CONNECT --> What do I do if I get the CONNECT notify before HASH(3)? Do ignore it, get the Quick mode message than retry again till I get the CONNECT again? or can I simply not echo CB and forget about this case? If the initiator raised CB first and gets HASH(2) more than once, should he replay both HDR, HASH(3) and CONNECT notify? Ylian Saint-Hilaire INTEL - Communication Architecture Labs > Aside from the fact that the CB doesn't really accomplish much unless the > peer's implementation queues packets (I suspect that most sgws don't) and > yours doesn't... > 1. The initiator has ample opportunity to setup his SA before the responder > uses it. > 2. The initiator was the one who decided to initiate the SA. Therefore, one > can conclude that he will also be the first one to use it. > The commit bit fixes a race condition that only affects the responder. If > the responder wants to send the connected notify then he should set the bit > himself. From owner-ipsec@lists.tislabs.com Thu Jan 27 19:08:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10977; Thu, 27 Jan 2000 19:08:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15815 Thu, 27 Jan 2000 20:54:13 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE93B@new-exc1.ctron.com> From: "Waters, Stephen" To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: Bruce Schneier on IPsec Date: Fri, 28 Jan 2000 01:58:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some comments Steve: 1) Compression. Van Jacobson-style compression could be used on TCP/IP (and other prots now), and is far more efficient that LZS would be on these headers. Perhaps the IPCOMP header need to allow of a marker to tell the receiver that Van-J has been used, and this should be added to the IPCOMP negotiation in IKE? 2) Tunnel v Transport. In the mood of simplification, there may be a counter arguement to drop 'tunnel-mode' and keep just transport! In the same way that L2TP tunnel traffic is transport-mode protected, IPIP tunnel traffic can be transport-mode protected. This separates IPSEC from 'tunneling' altogether - a good idea in my mind, since IPIP tunnels have a use in their own right. I know this presents a different model, but it is the one we use for LAN-LAN tunnels (L2TP and IPIP) for simplicity. It allows tunnel details (like the fun with MTU) to be left out of the IPSEC specs - apart from mentioning security aspects. Transport-mode protection of IPIP tunnel packets = 'IPSEC Tunnel Mode'. 3) Using AH makes NAT (and Tos mapping) a little difficult. Perhaps 'RSIP' will help here. If not for the NAT issues, I think IPIP tunnel traffic should be protected with AH+ESP transport mode. With NAT as a problem, just ESP transport mode. 4) Fragmentation - leave this issue to IPIP tunnel specification. IPSEC-overhead calculation and be included the MTU maths via a 'system service' call, but not needed as part of the IPSEC spec. Regards, Steve -----Original Message----- From: Steve Kent [mailto:kent@bbn.com] Sent: Friday, January 21, 2000 1:55 PM To: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec Folks, Since there has been so much mail recently re Bruce's comments, I thought it appropriate to post my annotated comments on the evaluation. I apologize to Bruce, in advance, for not supplying these to him privately first. He kindly sent a copy of his analysis a while ago, but I was able to find time to review it only recently. I was planning to send him this document, but I feel that it is appropriate to reply to the list now, given the growing volume of comments. The attached document is in MS Word, because I use the change control features to make the annotations. An ASCII version can be made available later, if necessary. Steve From owner-ipsec@lists.tislabs.com Thu Jan 27 23:17:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29499; Thu, 27 Jan 2000 23:17:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA25108 Fri, 28 Jan 2000 00:20:35 -0500 (EST) Date: Fri, 28 Jan 2000 16:13:03 +0530 (IST) From: Shamik Ganguly To: ipsec@lists.tislabs.com Subject: Re: from Lotus Notes In-Reply-To: <65256873.00730CD5.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jim, For transport mode you just copy the 'Protocol' field in the IP Packet to the 'Next Header' field of ESP header. It can be anything from TCP/UDP/ICMP to IP to ESP to AH. -Shamik > > > Jim Tiller on 27/01/2000 23:39:02 > > Please respond to Jim Tiller > > > To: "Strahm, Bill" > cc: ipsec@lists.tislabs.com (bcc: Shamik Ganguly/HSS) > > > Subject: Re[2]: Very quick, very basic > > > > > oops, excellent observation:) Thank you. I was assuming TCP. thnx > > Thursday, January 27, 2000, 12:55:00 PM, you wrote: > > SB> Well assuming that you are sending TCP (and not UDP or ICMP) you are > SB> correct... > > SB> Bill > > SB> ______________________________________________ > SB> Bill Strahm Programming today is a race between > SB> bill.strahm@ software engineers striving to build > SB> intel.com bigger and better idiot-proof programs, > SB> (503) 264-4632 and the Universe trying to produce > SB> bigger and better idiots. So far, the > SB> Universe is winning.--Rich Cook > SB> I am not speaking for Intel. And Intel rarely speaks for me > > > >> -----Original Message----- > >> From: Jim Tiller [mailto:jtiller@lucent.com] > >> Sent: Thursday, January 27, 2000 8:30 AM > >> To: ipsec@lists.tislabs.com > >> Subject: Very quick, very basic > >> > >> > >> Please excuse the silliness. > >> > >> The next header field in ESP contains an 8-bit value to represent the > >> header contained within the encrypted payload. > >> So, this is how I read it, please verify the > >> following for me: > >> > >> ESP used in tunnel mode -next header = 4 for IP-in-IP > >> ESP used in transport mode -next header = 6 for TCP. > >> > >> True or false? Or is it reversed? > >> > >> A very grateful thank you in advance. > >> > >> -jim > >> > >> > >> > >> > > > > From owner-ipsec@lists.tislabs.com Fri Jan 28 02:40:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18098; Fri, 28 Jan 2000 02:40:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08600 Fri, 28 Jan 2000 04:09:23 -0500 (EST) Message-ID: <38915DCA.794B886F@cisco.com> Date: Fri, 28 Jan 2000 10:13:46 +0100 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@ericsson.com CC: ipsec@lists.tislabs.com Subject: Re: Simultaneous connection attempts References: <200001271307.PAA14461@lmf3ws53.lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, I believe the case is rather common (at least, I've met that several times). As long as both systems keep both SA's, that does not matter. Regarding initial contact, RFC 2407 says (4.6.3.3 INITIAL-CONTACT) [...] The receiver of this Notification Message might then elect to delete any existing SA's it has for the sending system under the assumption that the sending system has rebooted and no longer has access to the original SA's and their associated keying material.[...] notice the _might_ delete (stronger than "may"). And a heuristic tells the hosts that the other side has always been alive (at least from time t) since (taking the names in your example) host A received packets from B regarding SA0 _after_ some non-(CKi,0) (i.e. non initial phase 1) packets from B regarding SA1 were received. (converse is true for B). If B had died somewhere, it would have forgotten about SA0 and stopped responding to SA0 related exchanges for ever. This works since the notification is done under the protection of a phase 1 SA. There are different cases but I think for any situation, both peers _can_ realize they are under a "Simultaneous connection" situation. I do not know a standard "workaround" (provided this is seen as a problem, which it is not really). As far as resource efficiency is concerned, I agree it would be nice to discard one of the SA's at that point. regards, Frederic Detienne jari.arkko@ericsson.com wrote: > > Hi. I'm trying to understand the ISAKMP/IKE specifications with > respect to what happens when, for some reason, both hosts start > initiating a connection at the same time. > > My first concern when I started looking at this was a system where > something - memory, CPU, or user interface - places limits on the > number of SAs open to a particular host. In such a system it would not > be desireable to hold open two ISAKMP SAs. Rather, it would be nice if > the other SA creation could simply be refused. However, it is not > clear to me if this is possible. If both ends implement a scheme where > they e.g. refuse another incoming ISAKMP connection from a host they > have themselves just started negotiating with, then both attempts will > fail. That is, if both hosts start their initiating-side negotiations > at the same time or within end-to-end delay time, then both think they > were the first. I would appreciate pointers or comments from the > members of this list regarding how such situations should be handled, > if they can be handled. It is also necessary that any mechanism for > this purpose allows renegotiation of expiring SAs, and works both > for phase 1 and phase 2. > > Secondly, it is not clear to me how INITIAL-CONTACT works in this > particular case. If both sides think they are the first, then they > must include INITIAL-CONTACT as a part of the phase 1 negotiation. > Wouldn't this mean that both sides will delete their own connection > as they receive the final packets from the connection initiated by > the other host? Here's the sequence of events (assuming main mode > and INITIAL-CONTACT as a part of the last message): > > Time What > ------------ > t+0 A initiates SA0 by sending the first request packet > B initiates SA1 by sending the first request packet > > t+1 B receives first packet of request for SA0 > A receives first packet of request for SA1 > > t+2 ... (negotiations proceed) ... > > t+3 B is ready with SA0, sends A the last message, > and deletes SA1 because A said INITIAL-CONTACT > A is ready with SA1, sends B the last message, > and deletes SA0 because B said INITIAL-CONTACT > > t+4 A receives the final packet for already deleted SA0 > B receives the final packet for already deleted SA1 > > In the end both hosts have one side of an SA ready, but not matching > sides of the same SA! Is this a problem or have I missed something? > > Jari Arkko > Ericsson -- ------------------------- * oOo * ------------------------- CiscoSystems Frederic Detienne, CDE Security & Network Services Tel 32 2 705 55 55 From owner-ipsec@lists.tislabs.com Fri Jan 28 09:05:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08553; Fri, 28 Jan 2000 09:05:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13755 Fri, 28 Jan 2000 10:14:39 -0500 (EST) Message-Id: <3.0.5.32.20000128142538.00ab9af0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 28 Jan 2000 14:25:38 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Public key encryption Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA12144 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When using public key encryption and agressive mode, the initiator has to send its certificate as a PKCS#7 (encrypted) message, CERT payload encoding 1. Does anybody actually support that? Jörn From owner-ipsec@lists.tislabs.com Fri Jan 28 20:02:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA25472; Fri, 28 Jan 2000 20:02:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20187 Fri, 28 Jan 2000 20:55:41 -0500 (EST) Message-ID: <051601bf69fc$d238dc00$a62df0d0@TIMSADMIN_NTD.rampnet.com> From: "Sathya Perla" To: Subject: DOI field in ISAKMP Date: Fri, 28 Jan 2000 18:01:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0513_01BF69B9.C40F8180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0513_01BF69B9.C40F8180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The ISAKMP rfc says that the DOI identifier field of a Notification = payload can be either 0 (for ISAKMP) or 1 (for IPSEC DOI).=20 When is the value 0 (ISAKMP) used? As I understand it the value 1 means that current ISAKMP instantiation = is IPSec. What would value 0 mean? Thanks, -Sathya ------=_NextPart_000_0513_01BF69B9.C40F8180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The ISAKMP rfc says that the DOI = identifier=20 field of a Notification payload can be either 0 (for ISAKMP) or 1 (for = IPSEC=20 DOI).
 
When is the value 0 (ISAKMP) = used?
 
As I understand it the value 1 means that current = ISAKMP=20 instantiation is IPSec. What would value 0 mean?
 
Thanks,
-Sathya
------=_NextPart_000_0513_01BF69B9.C40F8180-- From owner-ipsec@lists.tislabs.com Sun Jan 30 11:51:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13288; Sun, 30 Jan 2000 11:51:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24131 Sun, 30 Jan 2000 12:45:52 -0500 (EST) Message-Id: <200001301750.JAA14489@gallium.network-alchemy.com> To: "Sathya Perla" cc: ipsec@lists.tislabs.com Subject: Re: DOI field in ISAKMP In-reply-to: Your message of "Fri, 28 Jan 2000 18:01:56 PST." <051601bf69fc$d238dc00$a62df0d0@TIMSADMIN_NTD.rampnet.com> Date: Sun, 30 Jan 2000 09:50:22 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >As I understand it the value 1 means that current ISAKMP instantiation = >is IPSec. What would value 0 mean? ISAKMP theoretically allows you to negotiate SA's under multiple DOI's in a single negotiation. One might, it was argued, want to use a value of zero when you're using ISAKMP in this manner. The idea would be that the ISAKMP Notify isn't necessarily tied to any of the underlying DOI's being negotiated. In practice, most everyone uses the IPSEC DOI in their Notify messages, though I do know of one vendor who sends zero, and I recently fixed my implementation to accept zero. If you do accept zero, you should ensure that whatever message is received with zero cannot affect any of the IPSEC SA's. If you want to target something negotiated under the IPSEC DOI than you MUST use the IPSEC DOI in the Notify message. Derrell From owner-ipsec@lists.tislabs.com Sun Jan 30 13:05:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13889; Sun, 30 Jan 2000 13:05:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24433 Sun, 30 Jan 2000 14:46:32 -0500 (EST) From: "Mr. Anderson" Message-Id: <200001301951.OAA28092@linux.silkroad.com> Subject: Future ISAKMP Denial of Service Vulnerablity Needs Addressing To: ipsec@lists.tislabs.com Date: Sun, 30 Jan 100 14:51:28 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk WG Members: We are hearing more and more concerns in the enterprise community that ISAKMP will be vulnerable to UDP denial of service attacks in the future. This is a widely known and serious flaw, IMHO. ---------------------------------------------------------- FYI Review of RFC 2408: ISAKMP ---------------------------------------------------------- 2.5.1 Transport Protocol ISAKMP can be implemented over any transport protocol or over IP itself. Implementations MUST include send and receive capability for ISAKMP using the User Datagram Protocol (UDP) on port 500. ---------------------------------------------------------- The specification above means that most vendors who read this will build ISAKMP on 500/UDP; which means that any malicious person with a clue as to how UDP DoS attacks can be done will be able to create chaos with the ISAKMP process during SA setup, etc. Vendors with a clue will build an alternate mechanism which allows ISAKMP to play using a more robust transport mechanism, at least TCP based, which raises the bar against simple UDP DoS attacks. I suggest the ISAKMP RFC address this vulnerability more directly because IPSEC and ISAKMP security issues such as this could be treated more openly in the RFC, perhaps even an ISAKMP protocol risk-analysis should be documented in the IETF process. Finest Regards, Neo From owner-ipsec@lists.tislabs.com Sun Jan 30 17:47:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18083; Sun, 30 Jan 2000 17:47:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25008 Sun, 30 Jan 2000 18:26:01 -0500 (EST) Message-Id: <200001302330.SAA17310@solidum.com> To: ipsec@lists.tislabs.com CC: "Mr. Anderson" Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing In-Reply-To: Your message of "Sun, 30 Jan 0100 14:51:28 EST." <200001301951.OAA28092@linux.silkroad.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 30 Jan 2000 18:30:57 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Anderson" == Anderson writes: Anderson> WG Members: Anderson> We are hearing more and more concerns in the enterprise community Anderson> that ISAKMP will be vulnerable to UDP denial of service attacks Anderson> in the future. This is a widely known and serious flaw, IMHO. Yes, it is widely known. It is not a serious flaw, it is a fact of life. Switching to TCP does nothing. If you naively implement ISAKMP on top of TCP, then you must include TCP SYN spoof protection, which is much more difficult to deploy and hard to provide different levels of protection for, say, HTTP servers vs ISAKMP daemons. If you look at TCP SYN spoof protection, you'll discover that it involves the use of cookies as non-predictable sequence numbers, and thus is identically equivalent to what ISAKMP has. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Sun Jan 30 19:15:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24772; Sun, 30 Jan 2000 19:15:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25394 Sun, 30 Jan 2000 21:03:08 -0500 (EST) Date: Sun, 30 Jan 2000 21:08:05 -0500 From: "Michael H. Warfield" To: Michael Richardson Cc: ipsec@lists.tislabs.com, "Mr. Anderson" Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Message-ID: <20000130210805.A1744@alcove.wittsend.com> References: <200001301951.OAA28092@linux.silkroad.com> <200001302330.SAA17310@solidum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <200001302330.SAA17310@solidum.com>; from mcr@solidum.com on Sun, Jan 30, 2000 at 06:30:57PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, Jan 30, 2000 at 06:30:57PM -0500, Michael Richardson wrote: > Yes, it is widely known. It is not a serious flaw, it is a fact of life. If you are referring to "cookie_crumb", yes it is "somewhat" known (in some circles) and it seems to be moderately effective. I'm still looking into how effective. As far as it being "a fact of life", that is another question. There are arguements that there are ways to have avoided it. When it comes down to brass tacks, when I publish a security advisory saying this protocol is flawed and it could have been avoided, we are not going to have a pretty sight. It remains particularly disturbing that in spite of all the retoric at the IETF conferences about security being built into protocols and standards, we still ended up with a SECURITY protocol with potentially serious security flaws in it. > Switching to TCP does nothing. If you naively implement ISAKMP on top > of TCP, then you must include TCP SYN spoof protection, which is much more > difficult to deploy and hard to provide different levels of protection for, > say, HTTP servers vs ISAKMP daemons. I believe the arguement was that the problem with creating state due to spoofed packets could have been avoided. It has nothing to do with tcp vs udp. I'm not at the bottom of it yet, but it appears that some bad choices may have been made and some issues were not been given the serious consideration they deserved. > If you look at TCP SYN spoof protection, you'll discover that it involves > the use of cookies as non-predictable sequence numbers, and thus is > identically equivalent to what ISAKMP has. Again... Not a tcp vs udp issue. Tcp spoof protection relies fundamentally on the unpredicability of the sequence numbers, hence the Kevin Mitnick style tcp spoofing attacks. The same thing could have been done with ISAKMP cookies. It, aparently, was not. The failure to deal with this possiblity (what Bruce Schneier describes as programming Satan's computer - or designing in the face of active hostile intent) will force us to correct this flaw in the long term. It would have been better if the choice had not been to expose us to such security embarassments. Unfortunately, we don't always have that luxury. Equally unfortunate is all the vendors who are about to be dumped on due to "cookie_crumb". > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com > Michael Richardson |For a better connected world,where data flows faster > Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Sun Jan 30 20:06:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28533; Sun, 30 Jan 2000 20:06:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25491 Sun, 30 Jan 2000 21:53:08 -0500 (EST) From: "Mr. Anderson" Message-Id: <200001310255.VAA32377@linux.silkroad.com> Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing To: mhw@wittsend.com (Michael H. Warfield) Date: Sun, 30 Jan 100 21:55:47 -0500 (EST) Cc: mcr@solidum.com, ipsec@lists.tislabs.com, neo@silkroad.com In-Reply-To: <20000130210805.A1744@alcove.wittsend.com> from "Michael H. Warfield" at Jan 30, 0 09:08:05 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk snipped... > computer - or designing in the face of active hostile intent) will force us > to correct this flaw in the long term. It would have been better if the > choice had not been to expose us to such security embarassments. > Unfortunately, we don't always have that luxury. Equally unfortunate is > all the vendors who are about to be dumped on due to "cookie_crumb". Concur with your reply. It is ironic that the ISAKMP protocol specification, which is widely being deployed for IPSEC key management has such a basic security flaw. It (helps) magnify Bruce's comments in their IPSEC paper about how the IETF/IPSEC process does not work (well) for security-centric developments. Again, my gut feeling is that vendors will be driven to offer a special version of ISAKMP using a proprietary (a more secure) transport protocol as allowed in the ISAKMP RFC. As you will recall: ---------------------------------------------------------- >From RFC 2408: ISAKMP ---------------------------------------------------------- 2.5.1 Transport Protocol ISAKMP can be implemented over any transport protocol or over IP itself. ..... ---------------------------------------------------------- This was the original intent of my original post, to show how a flaw in the specification plus a 'do it anyway you can get-out- of-requirement-free card' for suppliers, will lead to interoperability problems. Vendors will simply be forced to offer ISAKMP services 'securely' which is not an IETF standard, using their 'super-duper' secure ISAKMP method. BTW: My original post was not meant to be a TCP vs. UDP discussion because we surely know that both protocols have vulnerabilities which can be exploited during ISAKMP operations. TCP does 'raise the bar just a little', IMHO, but not enough to be considered a "compensating control" in risk-analysis jargon. However, the straight UDP/500 approach is a large hole, IMHO. One of my biggest concerns it the fact that organizations, both large and very large, are under great pressure to field VPN solutions by users who have no concept of the vulnerabilities in the protocol specification. Organizations will field systems, spending large dollars, thinking the are getting 'a secure system'; when in fact, the operational criteria and specification, as currently being fielded, are far from secure from an operational perspective. -Neo From owner-ipsec@lists.tislabs.com Sun Jan 30 23:06:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03638; Sun, 30 Jan 2000 23:06:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA25763 Mon, 31 Jan 2000 00:26:33 -0500 (EST) Date: Mon, 31 Jan 2000 00:28:37 -0500 From: "Michael H. Warfield" To: "Mr. Anderson" Cc: "Michael H. Warfield" , mcr@solidum.com, ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Message-ID: <20000131002837.A2497@alcove.wittsend.com> References: <20000130210805.A1744@alcove.wittsend.com> <200001310255.VAA32377@linux.silkroad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <200001310255.VAA32377@linux.silkroad.com>; from neo@silkroad.com on Sun, Jan 30, 2000 at 09:55:47PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, Jan 30, 2000 at 09:55:47PM -0500, Mr. Anderson wrote: [...] > Concur with your reply. It is ironic that the ISAKMP protocol > specification, which is widely being deployed for IPSEC key management > has such a basic security flaw. It (helps) magnify Bruce's comments > in their IPSEC paper about how the IETF/IPSEC process does not work > (well) for security-centric developments. I will agree with you and, respectfully, disagree with you. The idea that the process has failed for ISAKMP is in our face. If any of the various security holes are valid (and cookie_crumb is an unfortunate given at this point) then the fact that the process has failed to prevent such problems is proven. How, then, did we let this HAPPEN? Was the process designed to prevent such things? No. The process was designed (and is evolving) to develop - NOT TO PREVENT. That is a CRITICAL distinction. It's objectives is to develop protocols and standards. Lately, the IETF has the proviso that those standards should be secure, as best we can accomplish given the state of the art, (remember the stupidities that resulted in things like the FTP bounce attack that still means you violate the standards to prohibit the attack). It is a false assumption, however, that the "IETF process does not work". The process does work! It fulfills the objectives to which it is presented! We can't fault it for that. We may fault the objectives or the premises on which those objectives are based, but the process DOES work. I would refer to you Heinlein's remarks (in a "A Time to Love, the Diaries of Larzarus Long") of "An oligarcy assumes that the minority knows more than the majority... Who decides? A democracy assumes that the majority knows more than the minority... Come again..." His point, IMNSHO, is to look at the fundamental processes driving the decision making, no whether it is one, many or majority who are making the decision. Single sources have come up with ideas and have, time and time again, have orphaned them to death. Look at IBM and MCA. Look at the broohaha with DVD and the DeCSS debackle that is going on. Is a focused industry monopoly like the CSS consortium the answer? I think NOT! That mess is a testimate to the fact that standards developed by a closed industry consorium is going to result in an embarassment to all the guilty parties involved! As a cryptographer, I would hang my head in shame to be associated with that debacle (other than its undoing). > Again, my gut feeling is that vendors will be driven to offer a special > version of ISAKMP using a proprietary (a more secure) transport > protocol as allowed in the ISAKMP RFC. As you will recall: In the "Brave New World" with open source nipping at their heels, homogenous networks with single source vendors is going the way of the dinosaurs. Darwinism is taking its toll. If you do not interoperate, you will not flourish. Note... I did NOT say you would not survive. Even those without the traits to dominate, do survive. Darwinism contrary to popular myth, is not an on/off switch - it's probabilites over long periods of time. Even those who do not have "survival characteristists" do survive and do propagate, just not as well. We just haven't thrown an astroid at them yet! :-) WE DON'T WANT AN ASTROID THROWN AS US! So... We have a balance... Vendors offering "proprietary" solutions (which is a negative) against open standards with a potential negative (the potential DoS problems noted). Will there be sufficient penetration of the open standard and the vulnerabilities to attract the sort of attention that shut down Portal? I hope not! Or I hope we find a solution to prevent it before it makes the headlines of CNN! [...] > BTW: My original post was not meant to be a TCP vs. UDP discussion > because we surely know that both protocols have vulnerabilities which > can be exploited during ISAKMP operations. TCP does 'raise the > bar just a little', IMHO, but not enough to be considered > a "compensating control" in risk-analysis jargon. However, the > straight UDP/500 approach is a large hole, IMHO. Agreed here, somewhat. Not sure on the details... > One of my biggest concerns it the fact that organizations, both > large and very large, are under great pressure to field VPN > solutions by users who have no concept of the vulnerabilities > in the protocol specification. Organizations will field > systems, spending large dollars, thinking the are getting > 'a secure system'; when in fact, the operational criteria > and specification, as currently being fielded, are far from > secure from an operational perspective. When we see one or more large organizations shut down due to things like "cookie crumb" much like Portal was such down due to SYN flooding, then we will see people wake up to some fundamental flaws. Then, they are going to be PISSED. We need to have answers before they need to have scaples. But the process is not at fault. The premise and the objectives, maybe. The open discussion process beats the closed committee and the, even more closed, private enterprise/consorsium process hands down. I haven't seen a better PROCESS, even when the premise and the objectives are misguided. It makes little sense to attack the process when it's the information and the goals that are really at fault. Understand this... I'm the Senior Researcher and Fellow at Internet Security Systems. There are people who consider me "white hat". There are people who consider me "grey hat". I hope there aren't TOO many people who consider me to be "black hat" (there are a few). I don't think my "hat" is as dark as Mudge or E-eye or a few others, but I AM THE DEVIL IN THE DETAILS. When protocols and implimenations screw up, I am the asshole that makes life miserable on a lot of people. I've got too much to do now, as it is. I'm currently tasked with looking at these potential IKE problems. I don't need more work! I would seriously rather prevent these problems BEFORE I write up security advisories on them! I'm in that rare occupation where it is more self satisfying to fail (unable to find a security hole) and be unrecognized than it is to succeed (rack some poor chump over the coals) and have CNN asking for my interview. My reputation does not require that I rape, piliage, or burn. But I have and I will.... > -Neo Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Mon Jan 31 06:38:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12268; Mon, 31 Jan 2000 06:38:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27244 Mon, 31 Jan 2000 08:14:31 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: "Michael H. Warfield" cc: Michael Richardson , ipsec@lists.tislabs.com, "Mr. Anderson" Message-ID: <86256877.00493B1F.00@mwgate02.mw.3com.com> Date: Mon, 31 Jan 2000 07:16:32 -0600 Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can anybody provide a description of or a pointer to this attack? -Mike "Michael H. Warfield" on 01/30/2000 08:08:05 PM Sent by: "Michael H. Warfield" To: Michael Richardson cc: ipsec@lists.tislabs.com, "Mr. Anderson" (Mike Borella/MW/US/3Com) Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing On Sun, Jan 30, 2000 at 06:30:57PM -0500, Michael Richardson wrote: > Yes, it is widely known. It is not a serious flaw, it is a fact of life. If you are referring to "cookie_crumb", yes it is "somewhat" known (in some circles) and it seems to be moderately effective. I'm still looking into how effective. As far as it being "a fact of life", that is another question. There are arguements that there are ways to have avoided it. When it comes down to brass tacks, when I publish a security advisory saying this protocol is flawed and it could have been avoided, we are not going to have a pretty sight. It remains particularly disturbing that in spite of all the retoric at the IETF conferences about security being built into protocols and standards, we still ended up with a SECURITY protocol with potentially serious security flaws in it. > Switching to TCP does nothing. If you naively implement ISAKMP on top > of TCP, then you must include TCP SYN spoof protection, which is much more > difficult to deploy and hard to provide different levels of protection for, > say, HTTP servers vs ISAKMP daemons. I believe the arguement was that the problem with creating state due to spoofed packets could have been avoided. It has nothing to do with tcp vs udp. I'm not at the bottom of it yet, but it appears that some bad choices may have been made and some issues were not been given the serious consideration they deserved. > If you look at TCP SYN spoof protection, you'll discover that it involves > the use of cookies as non-predictable sequence numbers, and thus is > identically equivalent to what ISAKMP has. Again... Not a tcp vs udp issue. Tcp spoof protection relies fundamentally on the unpredicability of the sequence numbers, hence the Kevin Mitnick style tcp spoofing attacks. The same thing could have been done with ISAKMP cookies. It, aparently, was not. The failure to deal with this possiblity (what Bruce Schneier describes as programming Satan's computer - or designing in the face of active hostile intent) will force us to correct this flaw in the long term. It would have been better if the choice had not been to expose us to such security embarassments. Unfortunately, we don't always have that luxury. Equally unfortunate is all the vendors who are about to be dumped on due to "cookie_crumb". > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com > Michael Richardson |For a better connected world,where data flows faster > Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Mon Jan 31 07:43:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13790; Mon, 31 Jan 2000 07:43:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27427 Mon, 31 Jan 2000 09:16:38 -0500 (EST) Message-ID: <38952701.AB0562DE@F-Secure.com> Date: Mon, 31 Jan 2000 08:09:05 +0200 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael H. Warfield" CC: Michael Richardson , ipsec@lists.tislabs.com, "Mr. Anderson" Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <200001301951.OAA28092@linux.silkroad.com> <200001302330.SAA17310@solidum.com> <20000130210805.A1744@alcove.wittsend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Michael H. Warfield" wrote: > > On Sun, Jan 30, 2000 at 06:30:57PM -0500, Michael Richardson wrote: > > > Switching to TCP does nothing. If you naively implement ISAKMP on top > > of TCP, then you must include TCP SYN spoof protection, which is much more > > difficult to deploy and hard to provide different levels of protection for, > > say, HTTP servers vs ISAKMP daemons. > > I believe the arguement was that the problem with creating state > due to spoofed packets could have been avoided. It has nothing to do with > tcp vs udp. I'm not at the bottom of it yet, but it appears that some > bad choices may have been made and some issues were not been given the > serious consideration they deserved. The problem of creating state, or 'cookie crumbs' can be successfully avoided in at least some of the cases. The basic idea is for the entity that normally would hold the state to encapsulate the state in a "state payload", and send that back to to the other entity. The "state payload" would be unforgeable by the peer, because it has been signed by the entity that created it (using private key crypto.) When the next protocol message is to be processed, the entity uses the state in the "state payload" and the other fields contained in the message to process the message. Only the information needed to verify the signing on the "state payload" needs to be retained, and that can be shared with all the connections. The idea is from the paper: Tuomas Aura and Pekka Nikander, "Stateless connections", in proceedings of International Conference on Information and Communications Security ICICS'97, Beijing, November 1997, pp. 87-97, Lecture Notes in Computer Science 1334, Springer Verlag 1997. http://www.tcm.hut.fi/~pnr/publications/index.html This "state payload" is about the same idea that I've written about in my previous postings about the DoS attack, but at that time I didn't use the same terminology or encapsulate the information in one place. The "state payload" can be used by only some of the entities in the Internet if we give it the following rule: - If a "state payload" is received in message N by entity A, entity A must include the "state payload" in message N+1 sent by entity A, without any modifications to its contents. This puts all of the responsibility for the security properties of the "state payload" to the entity that uses it. (And ultimately to IETF to specify safe usages for it.) If there's interest for the "state payload", I can write it in the form of a draft. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Jan 31 07:47:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13869; Mon, 31 Jan 2000 07:47:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27490 Mon, 31 Jan 2000 09:32:43 -0500 (EST) Date: Mon, 31 Jan 2000 09:37:38 -0500 From: "Michael H. Warfield" To: Mike Borella Cc: "Michael H. Warfield" , Michael Richardson , ipsec@lists.tislabs.com, "Mr. Anderson" Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Message-ID: <20000131093738.B2497@alcove.wittsend.com> References: <86256877.00493B1F.00@mwgate02.mw.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <86256877.00493B1F.00@mwgate02.mw.3com.com>; from Mike_Borella@mw.3com.com on Mon, Jan 31, 2000 at 07:16:32AM -0600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Jan 31, 2000 at 07:16:32AM -0600, Mike Borella wrote: > Can anybody provide a description of or a pointer to this attack? One pointer that was provided to me is this paper: http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00319.html It's not the most objective paper that I've read (hostile and political are two terms that come immediately to mind), but it does contain the source to "cookie_crumb". The source takes a little effort to get to work. You have to change some port numbers and (if you are not on BSD) change a function call from arc4random to random. Once it's compiled for the correct port number (500 instead of 5000), it's pretty effective at knocking IKE on its butt. It doesn't seem to be as bad as the original author made it out to be. I didn't see any of the "100% CPU utilization" reported by the author and as soon as the attack stops the system recovers. It doesn't seem to radically slow the operating system itself, beyond sucking up some significant bandwidth, but it does shut down your ability to key or rekey. This was Pluto on Linux that I was initially testing against. I'm going after other implimentations next and looking at some of the other issues raised in this paper. > -Mike [...] Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Mon Jan 31 08:17:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14247; Mon, 31 Jan 2000 08:17:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27408 Mon, 31 Jan 2000 09:14:38 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: ipsec@lists.tislabs.com Message-ID: <86256875.0048A580.00@mwgate02.mw.3com.com> Date: Sat, 29 Jan 2000 07:10:08 -0600 Subject: RSIP/IPSEC integration Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=qwT0fhjqvwgWmK9DmdnBkUta9eVm2wny6iT1Pc5vRV2XOPCzMLBkPwm3" Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0__=qwT0fhjqvwgWmK9DmdnBkUta9eVm2wny6iT1Pc5vRV2XOPCzMLBkPwm3 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Folks, As some of you know, we've been working on integrating IPSEC with RSIP, so that end-to-end security can exist in the presence of shared IP addresses. Our latest draft appears below. We'd appreciate any and all comments the IPSEC WG has regarding this draft. For background, you may want to read http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-protocol-05.txt Thanks, Mike --0__=qwT0fhjqvwgWmK9DmdnBkUta9eVm2wny6iT1Pc5vRV2XOPCzMLBkPwm3 Content-type: application/octet-stream; name="draft-ietf-nat-rsip-ipsec-02.txt" Content-Disposition: attachment; filename="draft-ietf-nat-rsip-ipsec-02.txt" Content-transfer-encoding: base64 Content-Description: Text - character set unknown DQoNCg0KDQoNCg0KSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAgICAgICAgICAgICAg ICAgICAgICAgICAgICBHLiBNb250ZW5lZ3JvDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFN1biBNaWNyb3N5c3RlbXMsIEluYy4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gQm9y ZWxsYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAzQ29tIENvcnBvcmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMDANCg0KICAgICAgICAgICAgICAg ICAgIFJTSVAgU3VwcG9ydCBmb3IgRW5kLXRvLWVuZCBJUHNlYw0KICAgICAgICAgICAgICAgICAg ICBkcmFmdC1pZXRmLW5hdC1yc2lwLWlwc2VjLTAyLnR4dA0KDQpTdGF0dXMgb2YgVGhpcyBNZW1v DQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwg Y29uZm9ybWFuY2UNCiAgIHdpdGggYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMy MDI2Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldA0KICAgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5k IGl0cyB3b3JraW5nDQogICBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNv IGRpc3RyaWJ1dGUgd29ya2luZw0KICAgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZg0KICAgc2l4IG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXINCiAgIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LQ0KICAgRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBv ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcw0KICAgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQN CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dA0KDQogICBUaGUg bGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2Vk DQogICBhdCBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQpBYnN0cmFjdA0KDQog ICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIG1lY2hhbmlzbXMgdGhhdCBlbmFibGUgIlJlYWxtLVNw ZWNpZmljDQogICBJUCIgKFJTSVApIHRvIGhhbmRsZSBlbmQtdG8tZW5kIElQc2VjLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpFeHBpcmVzIEp1bmUgMjAwMCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCklOVEVSTkVUIERS QUZUICAgICBSU0lQIFN1cHBvcnQgZm9yIEVuZC10by1lbmQgSVBzZWMgICAgICAgRmVicnVhcnkg MjAwMA0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCjEuIEludHJvZHVjdGlvbiAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gICAgMw0KMi4gTW9kZWwg Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LiAgICAzDQozLiBJbXBsZW1lbnRhdGlvbiBOb3RlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uICAgIDQNCjQuIElLRSBIYW5kbGluZyBhbmQgRGVtdWx0aXBsZXhp bmcgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gICAgNQ0KNS4gSVBzZWMgSGFuZGxp bmcgYW5kIERlbXVsdGlwbGV4aW5nIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgICA2 DQo2LiBSU0lQIFByb3RvY29sIEV4dGVuc2lvbnMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uICAgIDYNCiAgIDYuMSBJS0UgU3VwcG9ydCBpbiBSU0lQIC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gICAgNw0KICAgNi4yIElQc2VjIFN1cHBvcnQg aW4gUlNJUCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgICA4DQo3LiBJ QU5BIENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uICAgMTANCjguIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gICAxMA0KOS4gQWNrbm93bGVkZ2VtZW50cyAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDExDQpBcHBlbmRpeCBB OiBPbiBPcHRpb25hbCBQb3J0IEFsbG9jYXRpb24gdG8gUlNJUCBDbGllbnRzIC4uLi4uLi4uLi4u ICAgMTENCkFwcGVuZGl4IEI6IFJTSVAgRXJyb3IgTnVtYmVycyBmb3IgSUtFIGFuZCBJUHNlYyBT dXBwb3J0IC4uLi4uLi4uLi4gICAxMg0KQXBwZW5kaXggQzogTWVzc2FnZSBUeXBlIFZhbHVlcyBm b3IgSVBzZWMgU3VwcG9ydCAuLi4uLi4uLi4uLi4uLi4uLiAgIDEyDQpBcHBlbmRpeCBEOiBBIE5v dGUgb24gRmxvdyBQb2xpY3kgRW5mb3JjZW1lbnQgLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgMTMN CkFwcGVuZGl4IEU6IFJlbW90ZSBIb3N0IFJla2V5aW5nIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4gICAxMw0KQXBwZW5kaXggRjogRXhhbXBsZSBBcHBsaWNhdGlvbiBTY2VuYXJp b3MgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDE0DQpBcHBlbmRpeCBHOiBUaG91Z2h0cyBv biBTdXBwb3J0aW5nIEluY29taW5nIENvbm5lY3Rpb25zIC4uLi4uLi4uLi4uICAgMTUNClJlZmVy ZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gICAxNw0KQXV0aG9yIGFkZHJlc3NlcyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgIDE4DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRXhwaXJlcyBKdW5lIDIwMDAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJTlRFUk5F VCBEUkFGVCAgICAgUlNJUCBTdXBwb3J0IGZvciBFbmQtdG8tZW5kIElQc2VjICAgICAgIEZlYnJ1 YXJ5IDIwMDANCg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgUlNJUCBleHRlbnNpb25zIHRvIGVuYWJsZSBlbmQtdG8tZW5kDQogICBJUHNlYy4gIEl0IGFz c3VtZXMgdGhlIFJTSVAgZnJhbWV3b3JrIGFzIHByZXNlbnRlZCBpbiBbUlNJUC1GV10sDQogICBh bmQgc3BlY2lmaWVzIGV4dGVuc2lvbnMgdG8gdGhlIFJTSVAgcHJvdG9jb2wgZGVmaW5lZCBpbg0K ICAgW1JTSVAtUF0uIE90aGVyIHRlcm1pbm9sb2d5IGZvbGxvd3MgW05BVC1URVJNU10uDQoNCiAg IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAi U0hBTEwNCiAgIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAi TUFZIiwgYW5kDQogICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVy cHJldGVkIGFzIGRlc2NyaWJlZA0KICAgaW4gUkZDIDIxMTkuDQoNCg0KMi4gTW9kZWwNCg0KICAg Rm9yIGNsYXJpdHksIHRoZSBkaXNjdXNzaW9uIGJlbG93IGFzc3VtZXMgdGhpcyBtb2RlbDoNCg0K ICAgUlNJUCBjbGllbnQgICAgICAgICAgICAgIFJTSVAgc2VydmVyICAgICAgICAgICAgICAgICAg IEhvc3QNCg0KICAgICAgWGEgICAgICAgICAgICAgICAgICAgIE5hICAgTmIgICAgICAgICAgICAg ICAgICAgICAgIFliDQogICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAgICAgICBOYjEgICstLS0t LS0tLS0tLS0rDQogICBbWF0tLS0tLS18IEFkZHIgc3BhY2UgfC0tLS1bTl0tLS0tLXwgQWRkciBz cGFjZSB8LS0tLS0tLVtZXQ0KICAgICAgICAgICAgfCAgQSAgICAgICAgIHwgICAgICAgTmIyICB8 ICBCICAgICAgICAgfA0KICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgLi4uICArLS0t LS0tLS0tLS0tKw0KDQogICBIb3N0cyBYIGFuZCBZIGJlbG9uZyB0byBkaWZmZXJlbnQgYWRkcmVz cyBzcGFjZXMgQSBhbmQgQiwNCiAgIHJlc3BlY3RpdmVseSwgYW5kIE4gaXMgYW4gUlNJUCBzZXJ2 ZXIuICBOIGhhcyB0d28gYWRkcmVzc2VzOiAgTmENCiAgIG9uIGFkZHJlc3Mgc3BhY2UgQSwgYW5k IE5iIG9uIGFkZHJlc3Mgc3BhY2UgQi4gRm9yIGV4YW1wbGUsIEENCiAgIGNvdWxkIGJlIGEgcHJp dmF0ZSBhZGRyZXNzIHNwYWNlLCBhbmQgQiB0aGUgcHVibGljIGFkZHJlc3Mgc3BhY2UNCiAgIG9m IHRoZSBnZW5lcmFsIEludGVybmV0LiAgQWRkaXRpb25hbGx5LCBOIG1heSBoYXZlIGEgcG9vbCBv Zg0KICAgYWRkcmVzc2VzIGluIGFkZHJlc3Mgc3BhY2UgQiB3aGljaCBpdCBjYW4gYXNzaWduIHRv IG9yIGxlbmQgdG8NCiAgIFguDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgUlNJUCBleHRl bnNpb25zIGFuZCBtZWNoYW5pc21zIHRvIGVuYWJsZQ0KICAgYW4gUlNJUCBjbGllbnQgWCB0byBp bml0aWF0ZSBJS0UgYW5kIElQc2VjIHNlc3Npb25zIHRvIGEgbGVnYWN5DQogICBJS0UgYW5kIElQ c2VjIG5vZGUgWS4gSW4gb3JkZXIgdG8gZG8gc28sIFggZXhjaGFuZ2VzIFJTSVANCiAgIHByb3Rv Y29sIG1lc3NhZ2VzIHdpdGggdGhlIFJTSVAgc2VydmVyIE4uIFRoaXMgZG9jdW1lbnQgZG9lcyBu b3QNCiAgIHlldCBhZGRyZXNzIElLRS9JUHNlYyBzZXNzaW9uIGluaXRpYXRpb24gZnJvbSBZIHRv IGFuIFJTSVANCiAgIGNsaWVudCBYLiBGb3Igc29tZSB0aG91Z2h0cyBvbiB0aGlzIG1hdHRlciBz ZWUgQXBwZW5kaXggRy4NCg0KICAgVGhlIGRpc2N1c3Npb24gYmVsb3cgYXNzdW1lcyB0aGF0IHRo ZSBSU0lQIHNlcnZlciBOIGlzIGV4YW1pbmluZw0KICAgYSBwYWNrZXQgc2VudCBieSBZLCBkZXN0 aW5lZCBmb3IgWC4gVGhpcyBpbXBsaWVzIHRoYXQgInNvdXJjZSINCiAgIHJlZmVycyB0byBZIGFu ZCAiZGVzdGluYXRpb24iIHJlZmVycyB0byBZJ3MgcGVlciwgbmFtZWx5LCBYJ3MNCiAgIHByZXNl bmNlIGF0IE4uDQoNCiAgIFRoaXMgZG9jdW1lbnQgYXNzdW1lcyB0aGUgdXNlIG9mIHRoZSBSU0FQ LUlQIGZsYXZvciBvZiBSU0lQDQogICAoZXhjZXB0IHRoYXQgcG9ydCBudW1iZXIgYXNzaWdubWVu dHMgYXJlIG9wdGlvbmFsKSwgb24gdG9wIG9mDQogICB3aGljaCBTUEkgdmFsdWVzIGFyZSB1c2Vk IGZvciBkZW11bHRpcGxleGluZy4gQmVjYXVzZSBvZiB0aGlzLA0KDQoNCg0KRXhwaXJlcyBKdW5l IDIwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDNdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgUlNJUCBTdXBwb3J0IGZvciBFbmQtdG8tZW5kIElQ c2VjICAgICAgIEZlYnJ1YXJ5IDIwMDANCg0KDQogICBtb3JlIHRoYW4gb25lIFJTSVAgY2xpZW50 IG1heSBzaGFyZSB0aGUgc2FtZSBnbG9iYWwgSVAgYWRkcmVzcy4NCg0KDQozLiBJbXBsZW1lbnRh dGlvbiBOb3Rlcw0KDQogICBUaGUgUlNJUCBzZXJ2ZXIgTiBpcyBub3QgcmVxdWlyZWQgdG8gaGF2 ZSBtb3JlIHRoYW4gb25lIGFkZHJlc3MNCiAgIG9uIGFkZHJlc3Mgc3BhY2UgQi4gIFJTSVAgYWxs b3dzIFggKGFuZCBhbnkgb3RoZXIgaG9zdHMgb24NCiAgIGFkZHJlc3Mgc3BhY2UgQSkgdG8gcmV1 c2UgTmIuIEJlY2F1c2Ugb2YgdGhpcywgWSdzIFNQRCBTSE9VTEQNCiAgIE5PVCBiZSBjb25maWd1 cmVkIHRvIHN1cHBvcnQgYWRkcmVzcy1iYXNlZCBrZXlpbmcuIEFkZHJlc3MtYmFzZWQNCiAgIGtl eWluZyBpbXBsaWVzIHRoYXQgb25seSBvbmUgUlNJUCBjbGllbnQgbWF5LCBhdCBhbnkgZ2l2ZW4g cG9pbnQNCiAgIGluIHRpbWUsIHVzZSBhZGRyZXNzIE5iIHdoZW4gZXhjaGFuZ2luZyBJUHNlYyBw YWNrZXRzIHdpdGggWS4NCiAgIEluc3RlYWQsIFkncyBTUEQgU0hPVUxEIGJlIGNvbmZpZ3VyZWQg dG8gc3VwcG9ydA0KICAgc2Vzc2lvbi1vcmllbnRlZCBrZXlpbmcsIG9yIHVzZXItb3JpZW50ZWQg a2V5aW5nIFtLZW50OThjXS4gSW4NCiAgIGFkZGl0aW9uIHRvIHVzZXItb3JpZW50ZWQga2V5aW5n LCBvdGhlciB0eXBlcyBvZiBpZGVudGlmaWNhdGlvbnMNCiAgIHdpdGhpbiB0aGUgSUtFIElkZW50 aWZpY2F0aW9uIFBheWxvYWQgYXJlIGVxdWFsbHkgZWZmZWN0aXZlIGF0DQogICBkaXNhbWJpZ3Vh dGluZyB3aG8gaXMgdGhlIHJlYWwgY2xpZW50IGJlaGluZCB0aGUgc2luZ2xlIGFkZHJlc3MNCiAg IE5iIFtQaXBlcjk4XS4NCg0KICAgQmVjYXVzZSBpdCBjYW5ub3QgcmVseSBvbiBhZGRyZXNzLWJh c2VkIGtleWluZywgUlNJUCBzdXBwb3J0IGZvcg0KICAgSVBzZWMgaXMgc2ltaWxhciB0byB0aGUg YXBwbGljYXRpb24gb2YgSVBzZWMgZm9yIHJlbW90ZSBhY2Nlc3MNCiAgIHVzaW5nIGR5bmFtaWNh bGx5IGFzc2lnbmVkIGFkZHJlc3Nlcy4gQm90aCBjYXNlcyBpbXBvc2UNCiAgIGFkZGl0aW9uYWwg cmVxdWlyZW1lbnRzIHdoaWNoIGFyZSBub3QgbWV0IGJ5IG1pbmltYWxseSBjb21wbGlhbnQNCiAg IElQc2VjIGltcGxlbWVudGF0aW9ucyBbR3VwdGFdOg0KDQogICAgICBOb3RlIHRoYXQgYSBtaW5p bWFsbHktY29tcGxpYW50IElLRSBpbXBsZW1lbnRhdGlvbiAod2hpY2gNCiAgICAgIG9ubHkgaW1w bGVtZW50cyBNYWluIG1vZGUgd2l0aCBQcmUtc2hhcmVkIGtleXMgZm9yIFBoYXNlIEkNCiAgICAg IGF1dGhlbnRpY2F0aW9uKSBjYW5ub3QgYmUgdXNlZCBvbiBhIHJlbW90ZSBob3N0IHdpdGggYQ0K ICAgICAgZHluYW1pY2FsbHkgYXNzaWduZWQgYWRkcmVzcy4gVGhlIElLRSByZXNwb25kZXIgKGdh dGV3YXkpDQogICAgICBuZWVkcyB0byBsb29rIHVwIHRoZSBpbml0aWF0b3IncyAobW9iaWxlIG5v ZGUncykgcHJlLXNoYXJlZA0KICAgICAga2V5IGJlZm9yZSBpdCBjYW4gZGVjcnlwdCB0aGUgbGF0 dGVyJ3MgdGhpcmQgbWFpbiBtb2RlDQogICAgICBtZXNzYWdlIChmaWZ0aCBvdmVyYWxsIGluIFBo YXNlIEkpLiBTaW5jZSB0aGUgaW5pdGlhdG9yJ3MNCiAgICAgIGlkZW50aXR5IGlzIGNvbnRhaW5l ZCBpbiB0aGUgZW5jcnlwdGVkIG1lc3NhZ2UsIG9ubHkgaXRzIElQDQogICAgICBhZGRyZXNzIGlz IGF2YWlsYWJsZSBmb3IgbG9va3VwIGFuZCBtdXN0IGJlIHByZWRpY3RhYmxlLg0KICAgICAgT3Ro ZXIgb3B0aW9ucywgc3VjaCBhcyBNYWluIG1vZGUgd2l0aCBkaWdpdGFsIHNpZ25hdHVyZXMvUlNB DQogICAgICBlbmNyeXB0aW9uIGFuZCBBZ2dyZXNzaXZlIG1vZGUsIGNhbiBhY2NvbW9kYXRlIElL RSBwZWVycyB3aXRoDQogICAgICBkeW5hbWljYWxseSBhc3NpZ25lZCBhZGRyZXNzZXMuDQoNCiAg IElLRSBwYWNrZXRzIGFyZSB0eXBpY2FsbHkgY2FycmllZCBvbiBVRFAgcG9ydCA1MDAgZm9yIGJv dGgNCiAgIHNvdXJjZSBhbmQgZGVzdGluYXRpb24sIGFsdGhvdWdoIHRoZSB1c2Ugb2YgZXBoZW1l cmFsIHNvdXJjZQ0KICAgcG9ydHMgaXMgbm90IHByZWNsdWRlZCBbSVNBS01QXS4gIElLRSBpbXBs ZW1lbnRhdGlvbnMgZm9yIHVzZQ0KICAgd2l0aCBSU0lQIFNIT1VMRCBlbXBsb3kgZXBoZW1lcmFs IHBvcnRzLCBhbmQgc2hvdWxkIGhhbmRsZQ0KICAgdGhlbSBhcyBmb2xsb3dzIFtJUFNFQy1NU0dd Og0KDQogICAgICAgIElLRSBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IFVEUCBwb3J0IDUw MCBmb3IgYm90aA0KICAgICAgICBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uLCBidXQgb3RoZXIgcG9y dCBudW1iZXJzIGFyZSBhbHNvDQogICAgICAgIGFsbG93ZWQuICBJZiBhbiBpbXBsZW1lbnRhdGlv biBhbGxvd3Mgb3RoZXItdGhhbi1wb3J0LTUwMA0KICAgICAgICBmb3IgSUtFLCBpdCBzZXRzIHRo ZSB2YWx1ZSBvZiB0aGUgcG9ydCBudW1iZXJzIGFzIHJlcG9ydGVkDQogICAgICAgIGluIHRoZSBJ RCBwYXlsb2FkIHRvIDAgKG1lYW5pbmcgImFueSBwb3J0IiksIGluc3RlYWQgb2YNCg0KDQoNCkV4 cGlyZXMgSnVuZSAyMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA0XQ0KDA0KSU5URVJORVQgRFJBRlQgICAgIFJTSVAgU3VwcG9ydCBmb3IgRW5k LXRvLWVuZCBJUHNlYyAgICAgICBGZWJydWFyeSAyMDAwDQoNCg0KICAgICAgICA1MDAuIFVEUCBw b3J0IG51bWJlcnMgKDUwMCBvciBub3QpIGFyZSBoYW5kbGVkIGJ5IHRoZQ0KICAgICAgICBjb21t b24gInN3YXAgc3JjL2RzdCBwb3J0IGFuZCByZXBseSIgbWV0aG9kLg0KDQogICBJdCBpcyBpbXBv cnRhbnQgdG8gbm90ZSB0aGF0IElQc2VjIGltcGxlbWVudGF0aW9ucyBNVVNUIGJlIGF3YXJlDQog ICBvZiBSU0lQLCBhdCBsZWFzdCBpbiBzb21lIHBlcmlwaGVyYWwgc2Vuc2UsIGluIG9yZGVyIHRv IHJlY2VpdmUNCiAgIGFzc2lnbmVkIFNQSXMgYW5kIHBlcmhhcHMgb3RoZXIgcGFyYW1ldGVycyBm cm9tIGFuIFJTSVAgY2xpZW50Lg0KICAgVGhlcmVmb3JlLCBidW1wLWluLXRoZS1zdGFjayAoQklU UykgaW1wbGVtZW50YXRpb25zIG9mIElQc2VjIGFyZQ0KICAgbm90IGV4cGVjdGVkIHRvIHdvcmsg Im91dCBvZiB0aGUgYm94IiB3aXRoIFJTSVAuDQoNCg0KNC4gSUtFIEhhbmRsaW5nIGFuZCBEZW11 bHRpcGxleGluZw0KDQogICBJZiBhbiBSU0lQIGNsaWVudCByZXF1aXJlcyB0aGUgdXNlIG9mIHBv cnQgNTAwIGFzIGl0cyBJS0UNCiAgIHNvdXJjZSwgdGhpcyBwcmV2ZW50cyB0aGF0IGZpZWxkIGJl aW5nIHVzZWQgZm9yIGRlbXVsdGlwbGV4aW5nLg0KICAgSW5zdGVhZCwgdGhlICJJbml0aWF0b3Ig Q29va2llIiBmaWVsZCBpbiB0aGUgSUtFIGhlYWRlciBmaWVsZHMNCiAgIG11c3QgYmUgdXNlZCBm b3IgdGhpcyBwdXJwb3NlLiBUaGlzIGZpZWxkIGlzIGFwcHJvcHJpYXRlIGFzDQogICBpdCBpcyBn dWFyYW50ZWVkIHRvIGJlIHByZXNlbnQgaW4gZXZlcnkgSUtFIGV4Y2hhbmdlIChQaGFzZQ0KICAg MSBhbmQgUGhhc2UgMiksIGFuZCBpcyBndWFyYW50ZWVkIHRvIGJlIGluIHRoZSBjbGVhciAoZXZl bg0KICAgaWYgc3Vic2VxdWVudCBJS0UgcGF5bG9hZHMgYXJlIGVuY3J5cHRlZCkuICBIb3dldmVy LCBpdCBpcw0KICAgcHJvdGVjdGVkIGJ5IHRoZSBIYXNoIHBheWxvYWQgaW4gSUtFIFtJS0VdLiAg QmVjYXVzZSBvZiB0aGlzLA0KICAgYW4gUlNJUCBjbGllbnQgYW5kIHNlcnZlciBtdXN0IGFncmVl IHVwb24gYSB2YWxpZCB2YWx1ZSBmb3INCiAgIHRoZSBJbml0aWF0b3IgQ29va2llLg0KDQogICBP bmNlIFggYW5kIE4gYXJyaXZlIGF0IGEgbXV0dWFsbHkgYWdyZWVhYmxlIHZhbHVlIGZvciB0aGUN CiAgIEluaXRpYXRvciBDb29raWUsIFggdXNlcyBpdCB0byBjcmVhdGUgYW4gSUtFIHBhY2tldCBh bmQgdHVubmVscw0KICAgaXQgdGhlIFJTSVAgc2VydmVyIE4uICBOIGRlY2Fwc3VsYXRlcyB0aGUg SUtFIHBhY2tldCBhbmQgc2VuZHMNCiAgIGl0IG9uIGFkZHJlc3Mgc3BhY2UgQi4NCg0KICAgVGhl IG1pbmltdW0gdHVwbGUgbmVnb3RpYXRlZCB2aWEgUlNJUCwgYW5kIHVzZWQgZm9yDQogICBkZW11 bHRpcGxleGluZyBpbmNvbWluZyBJS0UgcmVzcG9uc2VzIGZyb20gWSBhdCB0aGUgUlNJUCBzZXJ2 ZXINCiAgIE4sIGlzOg0KDQogICAgICAtIElLRSBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcg0KDQog ICAgICAtIEluaXRpYXRvciBDb29raWUNCg0KICAgICAgLSBEZXN0aW5hdGlvbiBJUCBhZGRyZXNz DQoNCiAgIE9uZSBwcm9ibGVtIHN0aWxsIHJlbWFpbnM6IGhvdyBkb2VzIFkga25vdyB0aGF0IGl0 IGlzIHN1cHBvc2VkDQogICB0byBzZW5kIHBhY2tldHMgdG8gWCB2aWEgTmI/IFkgaXMgbm90IFJT SVAtYXdhcmUsIGJ1dCBpdCBpcw0KICAgZGVmaW5pdGVseSBJS0UtYXdhcmUuIFkgc2VlcyBJS0Ug cGFja2V0cyBjb21pbmcgZnJvbSBhZGRyZXNzIE5iLg0KICAgVG8gcHJldmVudCBZIGZyb20gbWlz dGFrZW5seSBkZXJpdmluZyB0aGUgaWRlbnRpdHkgb2YgaXRzIElLRQ0KICAgcGVlciBiYXNlZCBv biB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHBhY2tldHMgKE5iKSwgWCBNVVNUDQogICBleGNo YW5nZSBjbGllbnQgaWRlbnRpZmllcnMgd2l0aCBZOg0KDQogICAgICAtIElEaWksIElEaXIgaWYg aW4gUGhhc2UgMSwgYW5kDQoNCiAgICAgIC0gSURjaSwgSURjciBpZiBpbiBQaGFzZSAyLg0KDQoN Cg0KRXhwaXJlcyBKdW5lIDIwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDVdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgUlNJUCBTdXBwb3J0IGZv ciBFbmQtdG8tZW5kIElQc2VjICAgICAgIEZlYnJ1YXJ5IDIwMDANCg0KDQogICBUaGUgcHJvcGVy IHVzZSBvZiBpZGVudGlmaWVycyBhbGxvd3MgdGhlIGNsZWFyIHNlcGFyYXRpb24NCiAgIGJldHdl ZW4gdGhvc2UgaWRlbnRpdGllcyBhbmQgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIG9mIHRoZQ0KICAg cGFja2V0cy4NCg0KDQo1LiBJUHNlYyBIYW5kbGluZyBhbmQgRGVtdWx0aXBsZXhpbmcNCg0KICAg VGhlIFJTSVAgY2xpZW50IFggYW5kIHNlcnZlciBOIG11c3QgYXJyaXZlIGF0IGFuIFNQSSB2YWx1 ZSB0bw0KICAgZGVub3RlIHRoZSBpbmNvbWluZyBJUHNlYyBzZWN1cml0eSBhc3NvY2lhdGlvbiBm cm9tIFkgdG8gWC4NCiAgIE9uY2UgTiBhbmQgWCBtYWtlIHN1cmUgdGhhdCB0aGUgU1BJIGlzIHVu aXF1ZSB3aXRoaW4gYm90aCBvZg0KICAgdGhlaXIgU1BJIHNwYWNlcywgWCBjb21tdW5pY2F0ZXMg aXRzIHZhbHVlIHRvIFkgYXMgcGFydCBvZg0KICAgdGhlIElQc2VjIHNlY3VyaXR5IGFzc29jaWF0 aW9uIGVzdGFibGlzaG1lbnQgcHJvY2VzcywgbmFtZWx5LA0KICAgUXVpY2sgTW9kZSBpbiBJS0Ug W0lLRV0gb3IgbWFudWFsIGFzc2lnbm1lbnQuDQoNCiAgIFRoaXMgZW5zdXJlcyB0aGF0IFkgc2Vu ZHMgSVBzZWMgcGFja2V0cyAocHJvdG9jb2xzIDUxIGFuZA0KICAgNTAgZm9yIEFIIGFuZCBFU1As IHJlc3BlY3RpdmVseSkgW0tlbnQ5OGEsS2VudDk4Yl0gdG8gWCB2aWENCiAgIGFkZHJlc3MgTmIg dXNpbmcgdGhlIG5lZ290aWF0ZWQgU1BJLg0KDQogICBJUHNlYyBwYWNrZXRzIGZyb20gWSBkZXN0 aW5lZCBmb3IgWCBhcnJpdmUgYXQgUlNJUCBzZXJ2ZXIgTi4NCiAgIFRoZXkgYXJlIGRlbXVsdGlw bGV4ZWQgYmFzZWQgb24gdGhlIGZvbGxvd2luZyBtaW5pbXVtIHR1cGxlDQogICBvZiBkZW11bHRp cGxleGluZyBmaWVsZHM6DQoNCiAgICAgIC0gcHJvdG9jb2wgKDUwIG9yIDUxKQ0KDQogICAgICAt IFNQSQ0KDQogICAgICAtIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MNCg0KICAgSWYgTiBpcyBhYmxl IHRvIGZpbmQgYSBtYXRjaGluZyBtYXBwaW5nLCBpdCB0dW5uZWxzIHRoZSBwYWNrZXQNCiAgIHRv IFggYWNjb3JkaW5nIHRvIHRoZSB0dW5uZWxpbmcgbW9kZSBpbiBlZmZlY3QuICBJZiBOIGNhbm5v dA0KICAgZmluZCBhbiBhcHByb3ByaWF0ZSBtYXBwaW5nLCBpdCBNVVNUIGRpc2NhcmQgdGhlIHBh Y2tldC4NCg0KDQo2LiBSU0lQIFByb3RvY29sIEV4dGVuc2lvbnMNCg0KICAgVGhlIG5leHQgdHdv IHNlY3Rpb25zIHNwZWNpZnkgaG93IHRoZSBSU0lQIHByb3RvY29sIFtSU0lQLVBdIGlzDQogICBl eHRlbmRlZCB0byBzdXBwb3J0IGJvdGggSUtFIChhIFVEUCBhcHBsaWNhdGlvbikgYW5kIHRoZQ0K ICAgSVBzZWMtZGVmaW5lZCBBSCBhbmQgRVNQIGhlYWRlcnMgKGxheWVyZWQgZGlyZWN0bHkgb3Zl ciBJUCB3aXRoDQogICB0aGVpciBvd24gcHJvdG9jb2wgbnVtYmVycykuDQoNCiAgIElmIGEgc2Vy dmVyIGltcGxlbWVudHMgUlNJUCBzdXBwb3J0IGZvciBJS0UgYW5kIElQc2VjIGFzIGRlZmluZWQN CiAgIGluIHRoaXMgZG9jdW1lbnQsIGl0IE1BWSBpbmNsdWRlIHRoZSBSU0lQIE1ldGhvZCBwYXJh bWV0ZXIgZm9yDQogICBSU0lQIHdpdGggSVBzZWMgaW4gdGhlIFJFR0lTVEVSX1JFU1BPTlNFIG1l dGhvZCBzZW50IHRvIHRoZSBjbGllbnQuDQogICBUaGlzIG1ldGhvZCBpcyBhc3NpZ25lZCBhIHZh bHVlIG9mIDM6DQoNCiAgIDMgICBSU0lQIHdpdGggSVBzZWMgKFJTSVBTRUMpDQoNCiAgIFVubGVz cyBvdGhlcndpc2Ugc3BlY2lmaWVkLCByZXF1aXJlbWVudHMgb2YgbWljcm8gYW5kIG1hY3JvDQoN Cg0KDQpFeHBpcmVzIEp1bmUgMjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCklOVEVSTkVUIERSQUZUICAgICBSU0lQIFN1cHBvcnQg Zm9yIEVuZC10by1lbmQgSVBzZWMgICAgICAgRmVicnVhcnkgMjAwMA0KDQoNCiAgIGZsb3ctYmFz ZWQgcG9saWN5IGFyZSBoYW5kbGVkIGFjY29yZGluZyB0byBbUlNJUC1QXS4NCg0KDQo2LjEgSUtF IFN1cHBvcnQgaW4gUlNJUA0KDQogICBBcyBkaXNjdXNzZWQgYWJvdmUsIGlmIFgncyBJUHNlYyBp bXBsZW1lbnRhdGlvbiBhbGxvd3MgdXNlIG9mDQogICBhbiBlcGhlbWVyYWwgc291cmNlIHBvcnQg Zm9yIElLRSwgdGhlbiBpbmNvbWluZyBJS0UgdHJhZmZpYw0KICAgY2FuIGJlIGRlbXVsdGlwbGV4 ZWQgYnkgTiBiYXNlZCBvbiB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBhbmQNCiAgIHBvcnQgdHVw bGUuICBUaGlzIGlzIHRoZSBzaW1wbGVzdCBhbmQgbW9zdCBkZXNpcmFibGUgd2F5IG9mDQogICBz dXBwb3J0aW5nIElLRSwgYW5kIElQc2VjIGltcGxlbWVudGF0aW9ucyB0aGF0IGludGVyYWN0IHdp dGgNCiAgIFJTSVAgU0hPVUxEIGFsbG93IGl0Lg0KDQogICBIb3dldmVyLCBpZiBYIG11c3QgdXNl IHNvdXJjZSBwb3J0IDUwMCBmb3IgSUtFLCB0aGVyZSBhcmUgdHdvDQogICB0ZWNobmlxdWVzIHdp dGggd2hpY2ggWCBhbmQgTiBjYW4gYXJyaXZlIGF0IGEgbXV0dWFsbHkgdW5pcXVlDQogICBJbml0 aWF0b3IgQ29va2llLg0KDQogICAgICAtIFRyaWFsIGFuZCBlcnJvci4NCg0KICAgICAgLSBOZWdv dGlhdGlvbiB2aWEgYW4gZXh0ZW5zaW9uIG9mIHRoZSBSU0lQIHByb3RvY29sLg0KDQogICBUaGUg dHJpYWwgYW5kIGVycm9yIHRlY2huaXF1ZSBjb25zaXN0cyBvZiBYIGZpcnN0IG9idGFpbmluZw0K ICAgcmVzb3VyY2VzIHdpdGggd2hpY2ggdG8gdXNlIElQc2VjICh2aWEgQVNTSUdOX1JFUVVFU1Rf UlNJUFNFQywNCiAgIGRlZmluZWQgYmVsb3cpLCBhbmQgdGhlbiByYW5kb21seSBjaG9vc2luZyBh biBJbml0aWF0b3IgQ29va2llDQogICBhbmQgdHJhbnNtaXR0aW5nIHRoZSBmaXJzdCBwYWNrZXQg dG8gWS4gIFVwb24gYXJyaXZhbCBhdCBOLA0KICAgdGhlIFJTSVAgc2VydmVyIGV4YW1pbmVzIHRo ZSBJbml0aWF0b3IgQ29va2llIGZvciB1bmlxdWVuZXNzDQogICBwZXIgWCdzIGFzc2lnbmVkIGFk ZHJlc3MgKE5iKS4gIElmIHRoZSBjb29raWUgaXMgdW5pcXVlLA0KICAgTiBhbGxvd3MgdGhlIHVz ZSBvZiB0aGlzIGNvb2tpZSBmb3IgdGhpcyBhbiBhbGwgc3Vic2VxdWVudA0KICAgcGFja2V0cyBi ZXR3ZWVuIFggYW5kIFkgb24gdGhpcyBSU0lQIGJpbmRpbmcuICBJZiB0aGUgY29va2llDQogICBp cyBub3QgdW5pcXVlLCBOIGRyb3BzIHRoZSBwYWNrZXQuDQoNCiAgIFdoZW4gYW4gSUtFIHBhY2tl dCBpcyBkZXRlcm1pbmVkIHRvIGJlIGxvc3QsIHRoZSBJS0UgY2xpZW50IHdpbGwNCiAgIGF0dGVt cHQgdG8gcmV0cmFuc21pdCBhdCBsZWFzdCB0aHJlZSB0aW1lcyBbSUtFXS4gIEFuIFJTSVAtYXdh cmUNCiAgIElLRSBjbGllbnQgU0hPVUxEIHVzZSBkaWZmZXJlbnQgSW5pdGlhdG9yIENvb2tpZXMg Zm9yIGVhY2ggb2YNCiAgIHRoZXNlIHJldHJhbnNtaXNzaW9ucy4NCg0KICAgVGhlIHByb2JhYmls aXR5IG9mIGFuIEluaXRpYXRvciBDb29raWUgY29sbGlzaW9uIGF0IE4gYW5kDQogICBzdWJzZXF1 ZW50IHJldHJhbnNtaXNzaW9ucyBieSBYLCBpcyBpbmZpbml0ZXNzaW1hbCBnaXZlbiB0aGUNCiAg IDY0LWJpdCBjb29raWUgc3BhY2UuIEFjY29yZGluZyB0byB0aGUgYmlydGhkYXkgcGFyYWRveCwg aW4gYQ0KICAgcG9wdWxhdGlvbiBvZiA2NDAgbWlsbGlvbiBSU0lQIGNsaWVudHMgZ29pbmcgdGhy b3VnaCB0aGUgc2FtZQ0KICAgUlNJUCBzZXJ2ZXIsIHRoZSBjaGFuY2VzIG9mIGEgZmlyc3QgY29s bGlzaW9uIGlzIGp1c3QgMSUuICBUaHVzLA0KICAgaXQgaXMgZGVzaXJhYmxlIHRvIHVzZSB0aGUg dHJpYWwgYW5kIGVycm9yIG1ldGhvZCBvdmVyDQogICBuZWdvdGlhdGlvbiwgZm9yIHRoZXNlIHJl YXNvbnM6DQoNCiAgICAgIC0gU2ltcGxlciBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudHMNCg0K ICAgICAgLSBJdCBpcyBoaWdobHkgdW5saWtlbHkgdGhhdCBtb3JlIHRoYW4gb25lIHJvdW5kIHRy aXANCiAgICAgICAgYmV0d2VlbiBYIGFuZCBOIHdpbGwgYmUgbmVjZXNzYXJ5Lg0KDQoNCg0KDQpF eHBpcmVzIEp1bmUgMjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgN10NCgwNCklOVEVSTkVUIERSQUZUICAgICBSU0lQIFN1cHBvcnQgZm9yIEVu ZC10by1lbmQgSVBzZWMgICAgICAgRmVicnVhcnkgMjAwMA0KDQoNCjYuMiBJUHNlYyBTdXBwb3J0 IGluIFJTSVANCg0KICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHByb3RvY29sIGV4dGVuc2lv bnMgcmVxdWlyZWQgZm9yDQogICBSU0lQIHRvIHN1cHBvcnQgQUggYW5kIEVTUC4gVGhlIHJlcXVp cmVkIG1lc3NhZ2UgdHlwZXMgYXJlDQogICBBU1NJR05fUkVRVUVTVF9SU0lQU0VDIGFuZCBBU1NJ R05fUkVTUE9OU0VfUlNJUFNFQzoNCg0KICAgQVNTSUdOX1JFUVVFU1RfUlNJUFNFQw0KDQogICAg ICBUaGUgQVNTSUdOX1JFUVVFU1RfUlNJUFNFQyBtZXNzYWdlIGlzIHVzZWQgYnkgYW4gUlNJUCBj bGllbnQNCiAgICAgIHRvIHJlcXVlc3QgSVBzZWMgcGFyYW1ldGVyIGFzc2lnbm1lbnRzLiBBbiBS U0lQIGNsaWVudCBNVVNUDQogICAgICByZXF1ZXN0IGFuIElQIGFkZHJlc3MgYW5kIFNQSXMgaW4g b25lIG1lc3NhZ2UuDQoNCiAgICAgIElmIHRoZSBSU0lQIGNsaWVudCB3aXNoZXMgdG8gdXNlIElQ c2VjIHRvIHByb3RlY3QgYSBUQ1Agb3INCiAgICAgIFVEUCBhcHBsaWNhdGlvbiwgaXQgTVVTVCB1 c2UgdGhlIHBvcnQgcmFuZ2UgcGFyYW1ldGVyIChzZWUNCiAgICAgIEFwcGVuZGl4IEEpLiBPdGhl cndpc2UsIGl0IE1VU1Qgc2V0IHRoZSBwb3J0IHBhcmFtZXRlcnMgdG8NCiAgICAgIHRoZSAiZG9u J3QgbmVlZCIgdmFsdWUuICBUaGlzIGlzIGFjY29tcGxpc2hlZCBieSBzZXR0aW5nIHRoZQ0KICAg ICAgbGVuZ3RoIGZpZWxkIHRvIDAsIGFuZCBieSBvbWl0dGluZyBib3RoIHRoZSBudW1iZXIgZmll bGQgYW5kDQogICAgICB0aGUgcG9ydCBmaWVsZC4gIFRoaXMgaW5mb3JtcyB0aGUgc2VydmVyIHRo YXQgdGhlIGNsaWVudCBkb2VzDQogICAgICBub3QgYWN0dWFsbHkgbmVlZCBhbnkgcG9ydCBhc3Np Z25tZW50cy4NCg0KICAgICAgVGhlIGNsaWVudCBtYXkgaW5pdGlhbGl6ZSB0aGUgU1BJIHBhcmFt ZXRlciB0byB0aGUgImRvbid0DQogICAgICBjYXJlIiB2YWx1ZSAoc2VlIGJlbG93KS4gSW4gdGhp cyBjYXNlLCBpdCBpcyByZXF1ZXN0aW5nDQogICAgICB0aGUgc2VydmVyIHRvIGFzc2lnbiBpdCBh IHZhbGlkIFNQSSB2YWx1ZSB0byB1c2UuDQoNCiAgICAgIEFsdGVybmF0aXZlbHksIHRoZSBjbGll bnQgbWF5IGluaXRpYWxpemUgdGhlIFNQSSBwYXJhbWV0ZXIgdG8NCiAgICAgIGEgdmFsdWUgaXQg Y29uc2lkZXJzIHZhbGlkLiBJbiB0aGlzIGNhc2UsIGl0IGlzIHN1Z2dlc3RpbmcNCiAgICAgIHRo YXQgdmFsdWUgdG8gdGhlIHNlcnZlci4gT2YgY291cnNlLCB0aGUgc2VydmVyIG1heSBjaG9vc2UN CiAgICAgIHRvIHJlamVjdCB0aGF0IHN1Z2dlc3Rpb24gYW5kIHJldHVybiBhbiBhcHByb3ByaWF0 ZSBlcnJvcg0KICAgICAgbWVzc2FnZS4NCg0KICAgICAgVGhlIGZvcm1hdCBvZiB0aGlzIG1lc3Nh Z2UgaXM6DQoNCiAgICAgIDxBU1NJR05fUkVRVUVTVF9SU0lQU0VDPiA6Oj0gPFZlcnNpb24+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxNZXNzYWdlIFR5cGU+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxDbGllbnQgSUQ+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxBZGRyZXNzIChsb2NhbCk+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxQb3J0cyAobG9jYWwpPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8QWRkcmVzcyAocmVtb3RlKT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPFBvcnRzIChyZW1vdGUpPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8U1BJPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbTGVhc2UgVGlt ZV0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1R1bm5lbCBUeXBlXQ0KDQoN CiAgICAgIFRoZSBmb2xsb3dpbmcgbWVzc2FnZS1zcGVjaWZpYyBlcnJvciBjb25kaXRpb25zIGV4 aXN0LiBUaGUNCiAgICAgIGVycm9yIGJlaGF2aW9yIG9mIEFTU0lHTl9SRVFVRVNUX1JTSVBfSVBT RUMgZm9sbG93cyB0aGF0DQogICAgICBvZiBBU1NJR05fUkVRVUVTVF9SU0FQLUlQIGZvciBhbGwg bm9uLUlQc2VjIGVycm9ycy4NCg0KDQoNCg0KRXhwaXJlcyBKdW5lIDIwMDAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJTlRFUk5FVCBE UkFGVCAgICAgUlNJUCBTdXBwb3J0IGZvciBFbmQtdG8tZW5kIElQc2VjICAgICAgIEZlYnJ1YXJ5 IDIwMDANCg0KDQogICAgICAgICAtIElmIHRoZSBjbGllbnQgaXMgbm90IGFsbG93ZWQgdG8gdXNl IElQc2VjIHRocm91Z2ggdGhlDQogICAgICAgICAgIHNlcnZlciwgdGhlIHNlcnZlciBNVVNUIHJl c3BvbmQgd2l0aCBhbiBFUlJPUl9SRVNQT05TRQ0KICAgICAgICAgICBjb250YWluaW5nIHRoZSBJ UFNFQ19VTkFMTE9XRUQgcGFyYW1ldGVyLg0KDQogICAgICAgICAtIElmIHRoZSBTUEkgcGFyYW1l dGVyIGlzIGEgImRvbid0IGNhcmUiIHZhbHVlIGFuZCB0aGUNCiAgICAgICAgICAgUlNJUCBzZXJ2 ZXIgY2Fubm90IGFsbG9jYXRlIEFOWSBTUElzLCB0aGUgUlNJUCBzZXJ2ZXINCiAgICAgICAgICAg TVVTVCByZXNwb25kIHdpdGggYW4gRVJST1JfUkVTUE9OU0UgY29udGFpbmluZyB0aGUNCiAgICAg ICAgICAgSVBTRUNfU1BJX1VOQVZBSUxBQkxFIGVycm9yLg0KDQogICAgICAgICAtIElmIGFuIFNQ SSBwYXJhbWV0ZXIgaXMgbm90IGEgImRvbid0IGNhcmUiIHZhbHVlDQogICAgICAgICAgIGFuZCB0 aGUgUlNJUCBzZXJ2ZXIgY2Fubm90IGFsbG9jYXRlIGl0IGJlY2F1c2UgdGhlDQogICAgICAgICAg IHJlcXVlc3RlZCBhZGRyZXNzIGFuZCBTUEkgdHVwbGUgaXMgaW4gdXNlLCB0aGUgUlNJUA0KICAg ICAgICAgICBzZXJ2ZXIgTVVTVCByZXNwb25kIHdpdGggYW4gRVJST1JfUkVTUE9OU0UgY29udGFp bmluZw0KICAgICAgICAgICB0aGUgSVBTRUNfU1BJX0lOVVNFIGVycm9yLg0KDQogICBBU1NJR05f UkVTUE9OU0VfUlNJUFNFQw0KDQogICAgICBUaGUgQVNTSUdOX1JFU1BPTlNFX1JTSVBTRUMgbWVz c2FnZSBpcyB1c2VkIGJ5IGFuIFJTSVANCiAgICAgIHNlcnZlciB0byBhc3NpZ24gcGFyYW1ldGVy cyB0byBhbiBJUHNlYy1lbmFibGVkIFJTSVAgY2xpZW50Lg0KDQogICAgICBUaGUgZm9ybWF0IG9m IHRoaXMgbWVzc2FnZSBpczoNCg0KICAgICAgPEFTU0lHTl9SRVNQT05TRV9SU0lQU0VDPiA6Oj0g PFZlcnNpb24+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8TWVzc2FnZSBU eXBlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPENsaWVudCBJRD4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxCaW5kIElEPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPEFkZHJlc3MgKGxvY2FsKT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxQb3J0cyAobG9jYWwpPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPEFkZHJlc3MgKHJlbW90ZSk+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8UG9ydHMgKHJlbW90ZSk+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8U1BJPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PExlYXNlIFRpbWU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8VHVubmVs IFR5cGU+DQoNCiAgICAgIElmIHRoZSBwb3J0IHBhcmFtZXRlcnMgd2VyZSBzZXQgdG8gdGhlICJk b24ndCBuZWVkIiB2YWx1ZQ0KICAgICAgaW4gdGhlIHJlcXVlc3QgKHNlZSBhYm92ZSksIHRoZSBS U0lQIHNlcnZlciBtdXN0IGRvIHRoZQ0KICAgICAgc2FtZSBpbiB0aGUgcmVzcG9uc2UuDQoNCiAg IEFkZGl0aW9uYWxseSwgUlNJUCBzdXBwb3J0IGZvciBJUHNlYyByZXF1aXJlcyB0aGUgZm9sbG93 aW5nDQogICBuZXcgcGFyYW1ldGVyOg0KDQogICBTUEkNCiAgICAgICAgQ29kZSAgIExlbmd0aCAg ICBOdW1iZXIgICAgU1BJICAgICAgICAgICAgIFNQSQ0KICAgICAgKy0tLS0tLSstLS0tLS0tLSst LS0tLS0tLS0rLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLSsNCiAgICAgIHwgIDIyICB8ICAgIDIg ICB8IDIgYnl0ZXMgfCA0IGJ5dGVzIHwgLi4uIHwgNCBieXRlcyB8DQogICAgICArLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rICAgICArLS0tLS0tLS0tKw0KDQogICBTZW50IGJ5 IHRoZSBSU0lQIGNsaWVudCBpbiBBU1NJR05fUkVRVUVTVF9SU0lQU0VDIG1lc3NhZ2VzIHRvDQoN Cg0KDQpFeHBpcmVzIEp1bmUgMjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCklOVEVSTkVUIERSQUZUICAgICBSU0lQIFN1cHBvcnQg Zm9yIEVuZC10by1lbmQgSVBzZWMgICAgICAgRmVicnVhcnkgMjAwMA0KDQoNCiAgIGFzayBmb3Ig YSBwYXJ0aWN1bGFyIG51bWJlciBvZiBTUElzIHRvIGJlIGFzc2lnbmVkLiAgQWxzbyBzZW50DQog ICBieSB0aGUgUlNJUCBzZXJ2ZXIgdG8gdGhlIGNsaWVudCBpbiBBU1NJR05fUkVTUE9OU0VfUlNJ UFNFQw0KICAgbWVzc2FnZXMuDQoNCiAgIFRoZSAiU1BJIiBmaWVsZHMgZW5jb2RlIG9uZSBvciBt b3JlIFNQSXMuICBXaGVuIGEgc2luZ2xlIFNQSSBpcw0KICAgc3BlY2lmaWVkLCB0aGUgdmFsdWUg b2YgdGhlIG51bWJlciBmaWVsZCBpcyAxIGFuZCB0aGVyZSBpcyBvbmUNCiAgIFNQSSBmaWVsZCBm b2xsb3dpbmcgdGhlIG51bWJlciBmaWVsZC4gIFdoZW4gbW9yZSB0aGFuIG9uZSBTUEkNCiAgIGlz IHNwZWNpZmllZCwgdGhlIHZhbHVlIG9mIHRoZSBudW1iZXIgZmllbGQgd2lsbCBpbmRpY2F0ZSB0 aGUNCiAgIHRvdGFsIG51bWJlciBvZiBTUElzIGNvbnRhaW5lZCwgYW5kIHRoZSBwYXJhbWV0ZXIg bWF5IHRha2Ugb25lDQogICBvZiB0d28gZm9ybXMuICBJZiB0aGVyZSBpcyBvbmUgU1BJIGZpZWxk LCB0aGUgU1BJcyBzcGVjaWZpZWQgYXJlDQogICBjb25zaWRlcmVkIHRvIGJlIGNvbnRpZ3VvdXMg c3RhcnRpbmcgYXQgdGhlIFNQSSBudW1iZXIgc3BlY2lmaWVkDQogICBpbiB0aGUgU1BJIGZpZWxk LiAgQWx0ZXJuYXRpdmVseSwgdGhlcmUgbWF5IGJlIGEgbnVtYmVyIG9mIFNQSQ0KICAgZmllbGRz IGVxdWFsIHRvIHRoZSB2YWx1ZSBvZiB0aGUgbnVtYmVyIGZpZWxkLiAgVGhlIG51bWJlciBvZg0K ICAgU1BJIGZpZWxkcyBjYW4gYmUgZXh0cmFwb2xhdGVkIGZyb20gdGhlIHZhbHVlIG9mIHRoZSBs ZW5ndGgNCiAgIGZpZWxkLg0KDQogICBJbiBzb21lIGNhc2VzLCBpdCBpcyBuZWNlc3NhcnkgdG8g c3BlY2lmeSBhICJkb24ndCBjYXJlIg0KICAgdmFsdWUgZm9yIG9uZSBvciBtb3JlIFNQSXMuICBU aGlzIGlzIGFjY29tcGxpc2hlZCBieSBzZXR0aW5nDQogICB0aGUgbGVuZ3RoIGZpZWxkIHRvIDIg KHRvIGFjY291bnQgZm9yIHRoZSAyIGJ5dGVzIGluIHRoZQ0KICAgTnVtYmVyIGZpZWxkKSwgc2V0 dGluZyB0aGUgbnVtYmVyIGZpZWxkIHRvIHRoZSBudW1iZXIgb2YgU1BJcw0KICAgbmVjZXNzYXJ5 LCBhbmQgb21pdHRpbmcgYWxsIFNQSSBmaWVsZHMuICBUaGUgdmFsdWUgb2YgdGhlDQogICBudW1i ZXIgZmllbGQgTVVTVCBiZSBncmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8gb25lLg0KDQoNCjcuIElB TkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgQWxsIG9mIHRoZSBkZXNpZ25hdGlvbnMgYmVsb3cgYXJl IHRlbnRhdGl2ZS4NCg0KICAgICAgLSBSU0lQIElQc2VjIGVycm9yIGNvZGVzIChzZWUgYmVsb3cp Lg0KDQogICAgICAtIEFTU0lHTl9SRVFVRVNUX1JTSVBfSVBTRUMgbWVzc2FnZSB0eXBlIGNvZGUu DQoNCiAgICAgIC0gU1BJIHBhcmFtZXRlciBjb2RlLg0KDQoNCjguIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgYWRkIGFueSBzZWN1cml0eSBpc3N1 ZXMgdG8gdGhvc2UgYWxyZWFkeQ0KICAgcG9zZWQgYnkgTkFULCBvciBub3JtYWwgcm91dGluZyBv cGVyYXRpb25zLiBDdXJyZW50IHJvdXRpbmcNCiAgIGRlY2lzaW9ucyB0eXBpY2FsbHkgYXJlIGJh c2VkIG9uIGEgdHVwbGUgd2l0aCBvbmx5IG9uZSBlbGVtZW50Og0KICAgZGVzdGluYXRpb24gSVAg YWRkcmVzcy4gIFRoaXMgZG9jdW1lbnQganVzdCBhZGRzIG1vcmUgZWxlbWVudHMNCiAgIHRvIHRo ZSB0dXBsZS4gIEZ1cnRoZXJtb3JlLCBieSBhbGxvd2luZyBhbiBlbmQtdG8tZW5kIG1vZGUgb2YN CiAgIG9wZXJhdGlvbiBhbmQgYnkgaW50cm9kdWNpbmcgYSBuZWdvdGlhdGlvbiBwaGFzZSB0byBh ZGRyZXNzDQogICByZXVzZSwgdGhlIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGhlcmUgYXJlIG1vcmUg c2VjdXJlIGFuZCBsZXNzDQogICBhcmJpdHJhcnkgdGhhbiBOQVQuDQoNCiAgIEEgd29yZCBvZiBj YXV0aW9uIGlzIGluIG9yZGVyOiBTUEkgdmFsdWVzIGFyZSBtZWFudCB0byBiZQ0KICAgc2VtaS1y YW5kb20sIGFuZCwgdGh1cyBzZXJ2ZSBhbHNvIGFzIGFudGktY2xvZ2dpbmcgdG9rZW5zDQoNCg0K DQpFeHBpcmVzIEp1bmUgMjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxMF0NCgwNCklOVEVSTkVUIERSQUZUICAgICBSU0lQIFN1cHBvcnQgZm9y IEVuZC10by1lbmQgSVBzZWMgICAgICAgRmVicnVhcnkgMjAwMA0KDQoNCiAgIHRvIHJlZHVjZSBv ZmYtdGhlLXBhdGggZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrcy4gIEhvd2V2ZXIsDQogICBSU0lQ IHN1cHBvcnQgZm9yIElQc2VjLCByZW5kZXJzIFNQSSdzIGEgbmVnb3RpYXRlZCBpdGVtOiBpbg0K ICAgYWRkaXRpb24gdG8gYmVpbmcgdW5pcXVlIHZhbHVlcyBhdCB0aGUgcmVjZWl2ZXIgWCwgdGhl eSBtdXN0DQogICBhbHNvIGJlIHVuaXF1ZSBhdCB0aGUgUlNJUCBzZXJ2ZXIsIE4uICBMaW1pdGlu ZyB0aGUgcmFuZ2Ugb2YNCiAgIHRoZSBTUEkgdmFsdWVzIGF2YWlsYWJsZSB0byB0aGUgUlNJUCBj bGllbnRzIHJlZHVjZXMgdGhlaXINCiAgIGVudHJvcHkgc2xpZ2h0bHkuDQoNCg0KOS4gQWNrbm93 bGVkZ2VtZW50cw0KDQogICBNYW55IHRoYW5rcyB0byBCZXJuYXJkIEFib2JhLCBWaXB1bCBHdXB0 YSwgSmVmZnJleSBMbywgRGFuDQogICBOZXNzZXR0IGFuZCBHYXJ5IEphc3pld3NraSBmb3IgaGVs cGZ1bCBkaXNjdXNzaW9ucy4NCg0KDQpBcHBlbmRpeCBBOiBPbiBPcHRpb25hbCBQb3J0IEFsbG9j YXRpb24gdG8gUlNJUCBDbGllbnRzDQoNCiAgIERlc3BpdGUgdGhlIGZhY3QgdGhhdCBTUElzIHJh dGhlciB0aGFuIHBvcnRzIGFyZSB1c2VkIHRvDQogICBkZW11bHRpcGxleCBwYWNrZXRzIGF0IHRo ZSBSU0lQIHNlcnZlciwgdGhlIFJTSVAgc2VydmVyIG1heQ0KICAgc3RpbGwgYWxsb2NhdGUgbXV0 dWFsbHkgZXhjbHVzaXZlIHBvcnQgbnVtYmVycyB0byB0aGUgUlNJUA0KICAgY2xpZW50cy4gSWYg dGhpcyBkb2VzIG5vdCBoYXBwZW4sIHRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSB0aGF0DQogICB0 d28gUlNJUCBjbGllbnRzIHVzaW5nIHRoZSBzYW1lIElQIGFkZHJlc3MgYXR0ZW1wdCBhbiBJUHNl Yw0KICAgc2Vzc2lvbiB3aXRoIHRoZSBzYW1lIHNlcnZlciB1c2luZyB0aGUgc2FtZSBzb3VyY2Ug cG9ydA0KICAgbnVtYmVycy4NCg0KICAgKy0tLS0tLS0tLS0tLS0rDQogICB8IFJTSVAgY2xpZW50 IHwNCiAgIHwgICAgICBYMSAgICAgKy0tKw0KICAgfCAgICAgICAgICAgICB8ICB8ICAgICAgICAg Ky0tLS0tLS0tLS0tLS0rDQogICArLS0tLS0tLS0tLS0tLSsgIHwgICAgICAgICB8ICAgICAgICAg ICAgIHxOYg0KICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKyBSU0lQIHNlcnZlciArLS0t LS0tLS0tLS0tLS0tLQ0KICAgKy0tLS0tLS0tLS0tLS0rICB8ICAgICAgICAgfCAgICAgIE4gICAg ICB8DQogICB8IFJTSVAgY2xpZW50IHwgIHwgICAgICAgICArLS0tLS0tLS0tLS0tLSsNCiAgIHwg ICAgICBYMiAgICAgKy0tKyBwcml2YXRlICAgICAgICAgICAgICAgICAgICAgcHVibGljDQogICB8 ICAgICAgICAgICAgIHwgIHwgbmV0d29yayAgICAgICAgICAgICAgICAgICAgIG5ldHdvcmsNCiAg ICstLS0tLS0tLS0tLS0tKyAgfA0KICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICAgIHwNCg0KICAgRm9yIGV4YW1wbGUsIGNvbnNpZGVyIGhvc3RzIFgxIGFuZCBYMiBkZXBp Y3RlZCBhYm92ZS4gIEFzc3VtZQ0KICAgdGhhdCB0aGV5IGJvdGggYXJlIHVzaW5nIHB1YmxpYyBh ZGRyZXNzIE5iLCBhbmQgYm90aCBhcmUNCiAgIGNvbnRhY3RpbmcgYW4gZXh0ZXJuYWwgc2VydmVy IFkgYXQgcG9ydCA4MC4gIElmIHRoZXkgYXJlIHVzaW5nDQogICBJUHNlYyBidXQgYXJlIG5vdCBh bGxvY2F0ZWQgbXV0dWFsbHkgZXhjbHVzaXZlIHBvcnQgbnVtYmVycywNCiAgIHRoZXkgbWF5IGJv dGggY2hvb3NlIHRoZSBzYW1lIGVwaGVtZXJhbCBwb3J0IG51bWJlciB0byB1c2Ugd2hlbg0KICAg Y29udGFjdGluZyBZIGF0IHBvcnQgODAuICBBc3N1bWUgY2xpZW50IFgxIGRvZXMgc28gZmlyc3Qs IGFuZA0KICAgYWZ0ZXIgZW5nYWdpbmcgaW4gYW4gSUtFIG5lZ290aWF0aW9uIGJlZ2lucyBjb21t dW5pY2F0aW5nIHdpdGgNCiAgIHRoZSBwdWJsaWMgc2VydmVyIHVzaW5nIElQc2VjLg0KDQogICBX aGVuIENsaWVudCBYMiBzdGFydHMgaXRzIElLRSBzZXNzaW9uLCBpdCBzZW5kcyBpdHMNCg0KDQoN CkV4cGlyZXMgSnVuZSAyMDAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDExXQ0KDA0KSU5URVJORVQgRFJBRlQgICAgIFJTSVAgU3VwcG9ydCBmb3Ig RW5kLXRvLWVuZCBJUHNlYyAgICAgICBGZWJydWFyeSAyMDAwDQoNCg0KICAgaWRlbnRpZmljYXRp b24gdG8gdGhlIHB1YmxpYyBzZXJ2ZXIuIFRoZSBsYXR0ZXIncyBTUEQgcmVxdWlyZXMNCiAgIHRo YXQgZGlmZmVyZW50IGlkZW50aXRpZXMgdXNlIGRpZmZlcmVudCBmbG93cyAocG9ydCBudW1iZXJz KS4NCiAgIEJlY2F1c2Ugb2YgdGhpcywgdGhlIElLRSBuZWdvdGlhdGlvbiB3aWxsIGZhaWwuIENs aWVudCBYMiB3aWxsDQogICBiZSBmb3JjZWQgdG8gdHJ5IGFub3RoZXIgZXBoZW1lcmFsIHBvcnQg dW50aWwgaXQgc3VjY2VlZHMgaW4NCiAgIG9idGFpbmluZyBvbmUgd2hpY2ggaXMgY3VycmVudGx5 IG5vdCBpbiB1c2UgYnkgYW55IG90aGVyDQogICBzZWN1cml0eSBhc3NvY2lhdGlvbiBiZXR3ZWVu IHRoZSBwdWJsaWMgc2VydmVyIGFuZCBhbnkgb2YgdGhlDQogICBSU0lQIGNsaWVudHMgaW4gdGhl IHByaXZhdGUgbmV0d29yay4NCg0KICAgRWFjaCBzdWNoIGl0ZXJhdGlvbiBpcyBjb3N0bHkgaW4g dGVybXMgb2Ygcm91bmQtdHJpcCB0aW1lcyBhbmQNCiAgIENQVSB1c2FnZS4gIEhlbmNlIC0tYW5k IGFzIGEgY29udmVuaWVuY2UgdG8gaXRzIFJTSVAgY2xpZW50cy0tLA0KICAgYW4gUlNJUCBzZXJ2 ZXIgbWF5IGFsc28gYXNzaWduIG11dHVhbGx5IGV4Y2x1c2l2ZSBwb3J0IG51bWJlcnMNCiAgIHRv IGl0cyBJUHNlYyBSU0lQIGNsaWVudHMuDQoNCiAgIERlc3BpdGUgcHJvcGVyIGFsbG9jYXRpb24g b2YgcG9ydCBudW1iZXJzLCBhbiBSU0lQIHNlcnZlciBjYW5ub3QNCiAgIHByZXZlbnQgdGhlaXIg bWlzdXNlIGJlY2F1c2UgaXQgY2Fubm90IGV4YW1pbmUgdGhlIHBvcnQgZmllbGRzDQogICBpbiBw YWNrZXRzIHRoYXQgaGF2ZSBiZWVuIGVuY3J5cHRlZCBieSB0aGUgUlNJUCBjbGllbnRzLg0KICAg UHJlc3VtYWJseSwgaWYgdGhlIFJTSVAgY2xpZW50cyBoYXZlIGdvbmUgdGhyb3VnaCB0aGUgdHJv dWJsZSBvZg0KICAgbmVnb3RpYXRpbmcgcG9ydHMgbnVtYmVycywgaXQgaXMgaW4gdGhlaXIgYmVz dCBpbnRlcmVzdCB0bw0KICAgYWRoZXJlIHRvIHRoZXNlIGFzc2lnbm1lbnRzLg0KDQoNCkFwcGVu ZGl4IEI6IFJTSVAgRXJyb3IgTnVtYmVycyBmb3IgSUtFIGFuZCBJUHNlYyBTdXBwb3J0DQoNCiAg IFRoaXMgc2VjdGlvbiBwcm92aWRlcyBkZXNjcmlwdGlvbnMgZm9yIHRoZSBlcnJvciB2YWx1ZXMg aW4NCiAgIHRoZSBSU0lQIGVycm9yIHBhcmFtZXRlciBiZXlvbmQgdGhvc2UgZGVmaW5lZCBpbiBb UlNJUC1QXS4NCg0KICAgNDAxOiBJUFNFQ19VTkFMTE9XRUQuICBUaGUgc2VydmVyIHdpbGwgbm90 IGFsbG93IHRoZSBjbGllbnQNCiAgICAgICAgdG8gdXNlIGVuZC10by1lbmQgSVBzZWMuDQoNCiAg IDQwMjogSVBTRUNfU1BJX1VOQVZBSUxBQkxFLiBUaGUgc2VydmVyIGRvZXMgbm90IGhhdmUgYW4g U1BJDQogICAgICAgIGF2YWlsYWJsZSBmb3IgY2xpZW50IHVzZS4NCg0KICAgNDAzOiBJUFNFQ19T UElfSU5VU0UuICBUaGUgY2xpZW50IGhhcyByZXF1ZXN0ZWQgYW4gU1BJIHRoYXQNCiAgICAgICAg YW5vdGhlciBjbGllbnQgaXMgY3VycmVudGx5IHVzaW5nLg0KDQoNCkFwcGVuZGl4IEM6IE1lc3Nh Z2UgVHlwZSBWYWx1ZXMgZm9yIElQc2VjIFN1cHBvcnQNCg0KICAgVGhpcyBzZWN0aW9uIGRlZmlu ZXMgdGhlIHZhbHVlcyBhc3NpZ25lZCB0byBSU0lQIG1lc3NhZ2UgdHlwZXMNCiAgIGJleW9uZCB0 aG9zZSBkZWZpbmVkIGluIFtSU0lQLVBdLg0KDQogICAyMiAgQVNTSUdOX1JFUVVFU1RfUlNJUFNF Qw0KDQogICAyMyAgQVNTSUdOX1JFU1BPTlNFX1JTSVBTRUMNCg0KDQoNCg0KDQoNCg0KRXhwaXJl cyBKdW5lIDIwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgMTJdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgUlNJUCBTdXBwb3J0IGZvciBFbmQtdG8t ZW5kIElQc2VjICAgICAgIEZlYnJ1YXJ5IDIwMDANCg0KDQpBcHBlbmRpeCBEOiBBIE5vdGUgb24g RmxvdyBQb2xpY3kgRW5mb3JjZW1lbnQNCg0KICAgQW4gUlNJUCBzZXJ2ZXIgbWF5IG5vdCBiZSBh YmxlIHRvIGVuZm9yY2UgbG9jYWwgb3IgcmVtb3RlDQogICBtaWNyby1mbG93IHBvbGljeSB3aGVu IGEgY2xpZW50IHVzZXMgRVNQIGZvciBlbmQtdG8tZW5kDQogICBlbmNyeXB0aW9uLCBzaW5jZSBh bGwgVENQL1VEUCBwb3J0IG51bWJlcnMgd2lsbCBiZSBlbmNyeXB0ZWQuDQogICBIb3dldmVyLCBp ZiBBSCB3aXRob3V0IEVTUCBpcyB1c2VkLCBtaWNyby1mbG93IHBvbGljeSBpcw0KICAgZW5mb3Jj ZWFibGUuICBNYWNyby1mbG93IHBvbGljeSB3aWxsIGFsd2F5cyBiZSBlbmZvcmNlYWJsZS4NCg0K DQpBcHBlbmRpeCBFOiBSZW1vdGUgSG9zdCBSZWtleWluZw0KDQogICBPY2Nhc2lvbmFsbHksIGEg cmVtb3RlIGhvc3Qgd2l0aCB3aGljaCBhbiBSU0lQIGNsaWVudCBoYXMNCiAgIGVzdGFibGlzaGVk IGFuIElQc2VjIHNlY3VyaXR5IGFzc29jaWF0aW9uIChTQSkgd2lsbCByZWtleQ0KICAgW0plbmtp bnNdLiBTQSByZWtleWluZyBpcyBvbmx5IGFuIGlzc3VlIGZvciBSU0lQIHdoZW4gSUtFIHBvcnQN CiAgIDUwMCBpcyB1c2VkIGJ5IHRoZSBjbGllbnQgYW5kIHRoZSByZWtleSBpcyBvZiBJU0FLTVAg cGhhc2UgMQ0KICAgKHRoZSBJU0FLTVAgU0EpLiAgVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgcmVt b3RlIGhvc3Qgd2lsbA0KICAgdHJhbnNtaXQgSUtFIHBhY2tldHMgdG8gcG9ydCA1MDAgd2l0aCBh IG5ldyBpbml0aWF0b3IgY29va2llLg0KICAgVGhlIFJTSVAgc2VydmVyIHdpbGwgbm90IGhhdmUg YSBtYXBwaW5nIGZvciB0aGUgY29va2llLCBhbmQNCiAgIFNIT1VMRCBkcm9wIHRoZSB0aGUgcGFj a2V0cy4gIFRoaXMgd2lsbCBjYXVzZSB0aGUgSVNBS01QIFNBDQogICBiZXR3ZWVuIHRoZSBSU0lQ IGNsaWVudCBhbmQgcmVtb3RlIGhvc3QgdG8gYmUgZGVsZXRlZCwgYW5kIG1heQ0KICAgbGVhZCB0 byB1bmRlZmluZWQgYmVoYXZpb3IgZ2l2ZW4gdGhhdCBjdXJyZW50IGltcGxlbWVudGF0aW9ucw0K ICAgaGFuZGxlIHJla2V5aW5nIGluIGEgbnVtYmVyIG9mIGRpZmZlcmVudCB3YXlzLg0KDQogICBJ ZiB0aGUgUlNJUCBjbGllbnQgdXNlcyBhbiBlcGhlbWVyYWwgc291cmNlIHBvcnQsIHJla2V5aW5n DQogICB3aWxsIG5vdCBiZSBhbiBpc3N1ZSBmb3IgUlNJUC4gIElmIHRoaXMgY2Fubm90IGJlIGRv bmUsIHRoZXJlDQogICBhcmUgYSBudW1iZXIgb2YgUlNJUCBjbGllbnQgYmVoYXZpb3JzIHRoYXQg bWF5IHJlZHVjZSB0aGUNCiAgIG51bWJlciBvZiBvY2N1cmFuY2VzIG9mIHRoaXMgcHJvYmxlbSwg YnV0IGFyZSBub3QgZ3VhcmFudGVlZA0KICAgdG8gZWxpbWluYXRlIGl0Lg0KDQogICAgICAtIFRo ZSBSU0lQIGNsaWVudCdzIElLRSBpbXBsZW1lbnRhdGlvbiBpcyBnaXZlbiBhIHNtYWxsZXINCiAg ICAgICAgSVNBS01QIFNBIGxpZmV0aW1lIHRoYW4gaXMgdHlwaWNhbGx5IGltcGxlbWVudGVkLg0K ICAgICAgICBUaGlzIHdvdWxkIGxpa2VseSBjYXVzZSB0aGUgUlNJUCBjbGllbnQgdG8gcmVrZXkg dGhlDQogICAgICAgIElTQUtNUCBTQSBiZWZvcmUgdGhlIHJlbW90ZSBob3N0LiBTaW5jZSB0aGUg UlNJUCBjbGllbnQNCiAgICAgICAgY2hvb3NlcyB0aGUgSW5pdGlhdG9yIENvb2tpZSwgdGhlcmUg d2lsbCBiZSBubyBwcm9ibGVtDQogICAgICAgIHJvdXRpbmcgaW5jb21pbmcgdHJhZmZpYyBhdCB0 aGUgUlNJUCBzZXJ2ZXIuDQoNCiAgICAgIC0gVGhlIFJTSVAgY2xpZW50IHRlcm1pbmF0ZXMgdGhl IElTQUtNUCBTQSBhcyBzb29uIGFzIHRoZQ0KICAgICAgICBmaXJzdCBJUHNlYyBTQSBpcyBlc3Rh Ymxpc2hlZC4gIFRoaXMgbWF5IGFsbGV2aWF0ZSB0aGUNCiAgICAgICAgc2l0dWF0aW9uIHRvIHNv bWUgZGVncmVlIGlmIHRoZSBTQSBpcyBjb2Fyc2UtZ3JhaW5lZC4gT24NCiAgICAgICAgdGhlIG90 aGVyIGhhbmQsIHRoaXMgZXhhY2VyYmF0ZXMgdGhlIHByb2JsZW0gaWYgdGhlIFNBDQogICAgICAg IGlzIGZpbmUtZ3JhaW5lZCAoc3VjaCB0aGF0IGl0IGNhbm5vdCBiZSByZXVzZWQgYnkgb3RoZXIN CiAgICAgICAgYXBwbGljYXRpb24tbGV2ZWwgY29ubmVjdGlvbnMpLCBhbmQgdGhlIHJlbW90ZSBo b3N0IG5lZWRzDQogICAgICAgIHRvIGluaXRpYWxpemUgc29ja2V0cyBiYWNrIHRvIHRoZSBSU0lQ IGNsaWVudC4NCg0KICAgTm90ZSB0aGF0IHRoZSB1bnJlbGlhYmlsaXR5IG9mIFVEUCBlc3NlbnRp YWxseSBtYWtlcyB0aGUNCiAgIGVwaGVtZXJhbCBzb3VyY2UgYXBwcm9hY2ggdGhlIG9ubHkgcm9i dXN0IHNvbHV0aW9uLg0KDQoNCg0KDQoNCkV4cGlyZXMgSnVuZSAyMDAwICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSU5URVJORVQgRFJB RlQgICAgIFJTSVAgU3VwcG9ydCBmb3IgRW5kLXRvLWVuZCBJUHNlYyAgICAgICBGZWJydWFyeSAy MDAwDQoNCg0KQXBwZW5kaXggRjogRXhhbXBsZSBBcHBsaWNhdGlvbiBTY2VuYXJpb3MNCg0KICAg VGhpcyBzZWN0aW9uIGJyaWVmbHkgZGVzY3JpYmVzIHNvbWUgZXhhbXBsZXMgb2YgaG93IFJTSVAg bWF5IGJlDQogICB1c2VkIHRvIGVuYWJsZSBhcHBsaWNhdGlvbnMgb2YgSVBzZWMgdGhhdCBhcmUg b3RoZXJ3aXNlIG5vdA0KICAgcG9zc2libGUuDQoNCiAgIFRoZSBTT0hPIChzbWFsbCBvZmZpY2Us IGhvbWUgb2ZmaWNlKSBzY2VuYXJpbw0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCiAgICstLS0tLS0tLS0tKw0KICAgfFJTSVAgICAgICB8DQogICB8 Y2xpZW50IFgxICstLSsNCiAgIHwgICAgICAgICAgfCAgfCAgKy0tLS0tLS0tLS0tLS0rICAgICAg ICAgICAgKy0tLS0tLS0rDQogICArLS0tLS0tLS0tLSsgIHwgIHxOQVBUIGdhdGV3YXkgfCAgICAg ICAgICAgIHxwdWJsaWMgfA0KICAgICAgICAgICAgICAgICArLS0rIGFuZCAgICAgICAgICstLS4u Li4uLi4tLS0rSVBzZWMgIHwNCiAgICstLS0tLS0tLS0tKyAgfCAgfFJTSVAgc2VydmVyICB8ICAg ICAgICAgICAgfHBlZXIgWSB8DQogICB8UlNJUCAgICAgIHwgIHwgICstLS0tLS0tLS0tLS0tKyAg ICAgICAgICAgICstLS0tLS0tKw0KICAgfGNsaWVudCBYMiArLS0rIHByaXZhdGUgICAgICAgICAg ICAgcHVibGljDQogICB8ICAgICAgICAgIHwgIHwgImhvbWUiICAgICAgICAgICAgIEludGVybmV0 DQogICArLS0tLS0tLS0tLSsgIHwgbmV0d29yaw0KICAgICAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgIHwNCg0KICAgU3VwcG9zZSB0aGUgcHJpdmF0ZSAiaG9tZSIgbmV0d29yayBpcyBh IHNtYWxsIGluc3RhbGxhdGlvbiBpbg0KICAgc29tZWJvZHkncyBob21lLCBhbmQgdGhhdCB0aGUg UlNJUCBjbGllbnRzIFgxIGFuZCBYMiBtdXN0IHVzZQ0KICAgdGhlIFJTSVAgc2VydmVyIE4gYXMg YSBnYXRld2F5IHRvIHRoZSBvdXRzaWRlIHdvcmxkLiBOIGlzDQogICBjb25uZWN0ZWQgdmlhIGFu IElTUCBhbmQgb2J0YWlucyBhIHNpbmdsZSBhZGRyZXNzIHdoaWNoIG11c3QgYmUNCiAgIHNoYXJl ZCBieSBpdHMgY2xpZW50cy4gQmVjYXVzZSBvZiB0aGlzLCBOIGhhcyBOQVBULA0KICAgZnVuY3Rp b25hbGl0eS4gIE5vdywgWDEgd2lzaGVzIHRvIGVzdGFibGlzaCBhbiBJUHNlYyBTQSB3aXRoDQog ICBwZWVyIFkuIFRoaXMgaXMgcG9zc2libGUgYmVjYXVzZSBOIGlzIGFsc28gYW4gUlNJUCBzZXJ2 ZXINCiAgIGF1Z21lbnRlZCB3aXRoIHRoZSBJUHNlYyBzdXBwb3J0IGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudC4gIFkgaXMNCiAgIElQc2VjLWNhcGFibGUsIGJ1dCBpcyBub3QgUlNJUCBhd2FyZS4g VGhpcyBpcyBwZXJoYXBzIHRoZSBtb3N0DQogICB0eXBpY2FsIGFwcGxpY2F0aW9uIHNjZW5hcmlv Lg0KDQogICBUaGUgYWJvdmUgaXMgZXF1YWxseSBhcHBsaWNhYmxlIGluIHRoZSBST0JPIChyZW1v dGUgb2ZmaWNlLA0KICAgYnJhbmNoIG9mZmljZSkgc2NlbmFyaW8uDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpFeHBpcmVzIEp1bmUgMjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCklOVEVSTkVUIERSQUZUICAgICBSU0lQ IFN1cHBvcnQgZm9yIEVuZC10by1lbmQgSVBzZWMgICAgICAgRmVicnVhcnkgMjAwMA0KDQoNCiAg IFRoZSBSb2Fkd2FycmlvciBzY2VuYXJpbw0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CiAgICstLS0tLS0tLS0rICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0t Kw0KICAgfFJTSVAgICAgIHwgICAgICAgICAgICAgIHxDb3Jwb3JhdGUgICB8ICAgfCBJUHNlYyAg ICB8DQogICB8Y2xpZW50IFggKy0tLi4uLi4uLi4uLi0tK0ZpcmV3YWxsICAgICstLS0rIHBlZXIg WSAgIHwNCiAgIHwgICAgICAgICB8ICAgIHB1YmxpYyAgICB8IGFuZCAgICAgICAgfCAgIHwgKHVz ZXIncyAgfA0KICAgKy0tLS0tLS0tLSsgICBJbnRlcm5ldCAgIHxSU0lQIHNlcnZlciB8ICAgfCBk ZXNrdG9wKSB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBOICAgICAgICAgIHwgICB8 ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAg ICstLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaXZhdGUg Y29ycG9yYXRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV0d29yaw0KDQog ICBJbiB0aGlzIGV4YW1wbGUsIGEgcmVtb3RlIHVzZXIgd2l0aCBhIGxhcHRvcCBnYWlucyBhY2Nl c3MgdG8gdGhlDQogICBJbnRlcm5ldCwgcGVyaGFwcyBieSB1c2luZyBQUFAgb3IgREhDUC4gVGhl IHVzZXIgd2FudHMgdG8gYWNjZXNzDQogICBpdHMgY29ycG9yYXRpb24gcHJpdmF0ZSBuZXR3b3Jr LiAgVXNpbmcgbWVjaGFuaXNtcyBub3Qgc3BlY2lmaWVkDQogICBpbiB0aGlzIGRvY3VtZW50LCB0 aGUgUlNJUCBjbGllbnQgaW4gdGhlIGxhcHRvcCBlbmdhZ2VzIGluIGFuDQogICBSU0lQIGF1dGhl bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHBoYXNlIHdpdGggdGhlIFJTSVAgc2VydmVyDQog ICBhdCB0aGUgZmlyZXdhbGwuIEFmdGVyIHRoYXQgcGhhc2UgaXMgY29tcGxldGVkLCB0aGUgSVBz ZWMNCiAgIGV4dGVuc2lvbnMgdG8gUlNJUCBkZWZpbmVkIGhlcmUgYXJlIHVzZWQgdG8gZXN0YWJs aXNoIGFuIElQc2VjDQogICBzZXNzaW9uIHdpdGggYSBwZWVyLCBZLCB0aGF0IHJlc2lkZXMgd2l0 aGluIHRoZSBjb3Jwb3JhdGlvbidzDQogICBuZXR3b3JrLiBZIGNvdWxkIGJlLCBmb3IgZXhhbXBs ZSwgdGhlIHJlbW90ZSB1c2VyJ3MgdXN1YWwNCiAgIGRlc2t0b3Agd2hlbiBhdCB0aGUgb2ZmaWNl LiBUaGUgY29ycG9yYXRlIGZpcmV3YWxsIGNvbXBsZXggd291bGQNCiAgIHVzZSBSU0lQIHRvIHNl bGVjdGl2ZWx5IGVuYWJsZSBJUHNlYyB0cmFmZmljIGJldHdlZW4gaW50ZXJuYWwNCiAgIGFuZCBl eHRlcm5hbCBzeXN0ZW1zLg0KDQogICBOb3RlIHRoYXQgdGhpcyBzY2VuYXJpbyBjb3VsZCBhbHNv IGJlIHJldmVyc2VkIGluIG9yZGVyIHRvIGFsbG93DQogICBhbiBpbnRlcm5hbCBzeXN0ZW0gKFkp IHRvIGluaXRpYXRlIGFuZCBlc3RhYmxpc2ggYW4gSVBzZWMNCiAgIHNlc3Npb24gd2l0aCBhbiBl eHRlcm5hbCBJUHNlYyBwZWVyIChYKS4NCg0KDQpBcHBlbmRpeCBHOiBUaG91Z2h0cyBvbiBTdXBw b3J0aW5nIEluY29taW5nIENvbm5lY3Rpb25zDQoNCiAgIEluY29taW5nIElLRSBjb25uZWN0aW9u cyBhcmUgbXVjaCBlYXNpZXIgdG8gc3VwcG9ydCBpZiB0aGUNCiAgIHBlZXIgWSBjYW4gaW5pdGlh dGUgSUtFIGV4Y2hhbmdlcyB0byBhIHBvcnQgb3RoZXIgdGhhbiA1MDAuDQogICBJbiB0aGlzIGNh c2UsIHRoZSBSU0lQIGNsaWVudCB3b3VsZCBhbGxvY2F0ZSB0aGF0IHBvcnQgYXQNCiAgIHRoZSBS U0lQIGNsaWVudCB2aWEgQVNTSUdOX1JFUVVFU1RfUlNBUC1JUC4gIEFsdGVybmF0aXZlbHksDQog ICBpZiB0aGUgUlNJUCBjbGllbnQgaXMgYWJsZSB0byBhbGxvY2F0ZSBhbiBJUCBhZGRyZXNzIGF0 IHRoZQ0KICAgUlNJUCBzZXJ2ZXIgdmlhIEFTU0lHTl9SRVFVRVNUX1JTQS1JUCwgWSBjb3VsZCBz aW1wbHkgaW5pdGlhdGUNCiAgIHRoZSBJS0UgZXhjaGFuZ2UgdG8gcG9ydCA1MDAgYXQgdGhhdCBh ZGRyZXNzLg0KDQogICBJZiB0aGVyZSBpcyBvbmx5IG9uZSBhZGRyZXNzIE5iIHRoYXQgbXVzdCBi ZSBzaGFyZWQgYnkgdGhlIFJTSVANCiAgIHNlcnZlciBhbmQgYWxsIGl0cyBjbGllbnRzLCBhbmQg aWYgWSBjYW4gb25seSBzZW5kIHRvIHBvcnQNCiAgIDUwMCwgdGhlIHByb2JsZW0gaXMgbXVjaCBt b3JlIGRpZmZpY3VsdC4gQXQgYW55IGdpdmVuIHRpbWUsDQogICB0aGUgY29tYmluYXRpb24gb2Yg YWRkcmVzcyBOYiBhbmQgVURQIHBvcnQgNTAwIG1heSBvbmx5IGJlDQogICByZWdpc3RlcmVkIGFu ZCB1c2VkIGJ5IG9ubHkgb25lIFJTSVAgc3lzdGVtIChpbmNsdWRpbmcgY2xpZW50cw0KICAgYW5k IHNlcnZlcikuDQoNCg0KDQoNCkV4cGlyZXMgSnVuZSAyMDAwICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSU5URVJORVQgRFJBRlQgICAg IFJTSVAgU3VwcG9ydCBmb3IgRW5kLXRvLWVuZCBJUHNlYyAgICAgICBGZWJydWFyeSAyMDAwDQoN Cg0KICAgU29sdmluZyB0aGlzIGlzc3VlIHdvdWxkIHJlcXVpcmUgZGVtdWx0aXBsZXhpbmcgdGhl IGluY29taW5nDQogICBJS0UgY29ubmVjdGlvbiByZXF1ZXN0IGJhc2VkIG9uIHNvbWV0aGluZyBv dGhlciB0aGFuIHRoZQ0KICAgcG9ydCBhbmQgYWRkcmVzcyBjb21iaW5hdGlvbi4gSXQgbWF5IGJl IHBvc3NpYmxlIHRvIGRvIHNvDQogICBieSBmaXJzdCByZWdpc3RlcmluZyBhbiBpZGVudGl0eSB3 aXRoIGEgbmV3IFJTSVAgY29tbWFuZCBvZg0KICAgTElTVEVOX1JTSVBfSUtFLiBOb3RlIHRoYXQg dGhlIGlkZW50aXR5IGNvdWxkIG5vdCBiZSB0aGF0IG9mDQogICB0aGUgSUtFIHJlc3BvbmRlciAo dGhlIFJTSVAgY2xpZW50KSwgYnV0IHRoYXQgb2YgdGhlIGluaXRpYXRvcg0KICAgKFkpLiBUaGUg cmVhc29uIGlzIHRoYXQgdGhlIFBoYXNlIDEgb25seSBhbGxvd3MgdGhlIHNlbmRlciB0bw0KICAg aW5jbHVkZSBpdHMgb3duIGlkZW50aXR5LCBub3QgdGhhdCBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50DQogICAoYm90aCwgYnkgdGhlIHdheSwgYXJlIGFsbG93ZWQgaW4gUGhhc2UgMikuIEZ1cnRo ZXJtb3JlLCB0aGUNCiAgIGlkZW50aXR5IG11c3QgYmUgaW4gdGhlIGNsZWFyIGluIHRoZSBmaXJz dCBpbmNvbWluZyBwYWNrZXQgZm9yDQogICB0aGUgUlNJUCBzZXJ2ZXIgdG8gYmUgYWJsZSB0byB1 c2UgaXQgYXMgYSBkZW11bHRpcGxleG9yLiBUaGlzDQogICBydWxlcyBvdXQgYWxsIHZhcmlhbnRz IG9mIE1haW4gTW9kZSBhbmQgQWdncmVzc2l2ZSBNb2RlDQogICB3aXRoIFB1YmxpYyBLZXkgRW5j cnlwdGlvbiAoYW5kIFJldmlzZWQgTW9kZSBvZiBQdWJsaWMgS2V5DQogICBFbmNyeXB0aW9uKSwg c2luY2UgdGhlc2UgZW5jcnlwdCB0aGUgSUQgcGF5bG9hZC4NCg0KICAgVGhlIG9ubHkgUGhhc2Ug MSB2YXJpYW50cyB3aGljaCBlbmFibGUgaW5jb21pbmcgSUtFIHNlc3Npb25zDQogICBhcmUgQWdn cmVzc2l2ZSBNb2RlIHdpdGggc2lnbmF0dXJlcyBvciB3aXRoIHByZS1zaGFyZWQga2V5cy4NCiAg IEJlY2F1c2UgdGhpcyBzY2hlbWUgaW52b2x2ZXMgdGhlIFJTSVAgc2VydmVyIGRlbXVsdGlwbGV4 aW5nDQogICBiYXNlZCBvbiB0aGUgaWRlbnRpdHkgb2YgdGhlIElLRSBpbml0aWF0b3IsIGl0IGlz IGNvbmNlaXZhYmxlDQogICB0aGF0IG9ubHkgb25lIFJTSVAgY2xpZW50IGF0IGEgdGltZSBtYXkg cmVnaXN0ZXIgaW50ZXJlc3QgaW4NCiAgIGZpZWxkaW5nIHJlcXVlc3RzIGZyb20gYW55IGdpdmVu IHBlZXIgWS4gRnVydGhlcm1vcmUsIHRoaXMNCiAgIHByZWNsdWRlcyBtb3JlIHRoYW4gb25lIFJT SVAgY2xpZW50J3MgYmVpbmcgYXZhaWxhYmxlIHRvIGFueQ0KICAgdW5zcGVjaWZpZWQgcGVlciBZ Lg0KDQogICBPbmNlIHRoZSBJS0Ugc2Vzc2lvbiBpcyBpbiBwbGFjZSwgSVBzZWMgaXMgc2V0IHVw IGFzIGRpc2N1c3NlZA0KICAgaW4gdGhpcyBkb2N1bWVudCwgbmFtZWx5LCBieSB0aGUgUlNJUCBj bGllbnQgYW5kIHRoZSBSU0lQIHNlcnZlcg0KICAgYWdyZWVpbmcgb24gYW4gaW5jb21pbmcgU1BJ IHZhbHVlLCB3aGljaCBpcyB0aGVuIGNvbW11bmljYXRlZA0KICAgdG8gdGhlIHBlZXIgWSBhcyBw YXJ0IG9mIFF1aWNrIE1vZGUuDQoNCiAgIFRoZSBhbHRlcm5hdGUgYWRkcmVzcyBhbmQgcG9ydCBj b21iaW5hdGlvbiBtdXN0IGJlIGRpc2NvdmVyZWQNCiAgIGJ5IHRoZSByZW1vdGUgcGVlciB1c2lu ZyBtZXRob2RzIHN1Y2ggYXMgbWFudWFsIGNvbmZpZ3VyYXRpb24sDQogICBvciB0aGUgdXNlIG9m IEtYIChSRkMyMjMwKSBvciBTUlYgKFJGQzIwNTIpIHJlY29yZHMuICBJdCBtYXkNCiAgIGV2ZW4g YmUgcG9zc2libGUgZm9yIHRoZSBETlMgcXVlcnkgdG8gdHJpZ2dlciB0aGUgYWJvdmUNCiAgIG1l Y2hhbmlzbXMgdG8gcHJlcGFyZSBmb3IgdGhlIGluY29taW5nIGFuZCBpbXBlbmRpbmcgSUtFDQog ICBzZXNzaW9uIGluaXRpYXRpb24uIFN1Y2ggYSBtZWNoYW5pc20gd291bGQgYWxsb3cgbW9yZSB0 aGFuDQogICBvbmUgUlNJUCBjbGllbnQgdG8gYmUgYXZhaWxhYmxlIGF0IGFueSBnaXZlbiB0aW1l LCBhbmQgd291bGQNCiAgIGFsc28gZW5hYmxlIGVhY2ggb2YgdGhlbSB0byByZXNwb25kIHRvIElL RSBpbml0aWF0aW9ucyBmcm9tDQogICB1bnNwZWNpZmllZCBwZWVycy4gU3VjaCBhIEROUyBxdWVy eSwgaG93ZXZlciwgaXMgbm90IGd1YXJhbnRlZWQNCiAgIHRvIG9jY3VyLiBGb3IgZXhhbXBsZSwg dGhlIHJlc3VsdCBvZiB0aGUgcXVlcnkgY291bGQgYmUgY2FjaGVkDQogICBhbmQgcmV1c2VkIGFm dGVyIHRoZSBSU0lQIHNlcnZlciBpcyBubyBsb25nZXIgbGlzdGVuaW5nIGZvcg0KICAgYSBnaXZl biBJS0UgcGVlcidzIGlkZW50aXR5Lg0KDQogICBCZWNhdXNlIG9mIHRoZSBsaW1pdGF0aW9ucyBp bXBsaWVkIGJ5IGhhdmluZyB0byByZWx5IG9uIHRoZQ0KICAgaWRlbnRpdHkgb2YgdGhlIElLRSBp bml0aWF0b3IsIHRoZSBvbmx5IHByYWN0aWNhbCB3YXkgb2YNCiAgIHN1cHBvcnRpbmcgaW5jb21p bmcgY29ubmVjdGlvbnMgaXMgZm9yIHRoZSBwZWVyIFkgdG8gaW5pdGlhdGUNCiAgIHRoZSBJS0Ug c2Vzc2lvbiBhdCBhIHBvcnQgb3RoZXIgdGhhbiA1MDAuDQoNCg0KDQoNCg0KRXhwaXJlcyBKdW5l IDIwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MTZdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgUlNJUCBTdXBwb3J0IGZvciBFbmQtdG8tZW5kIElQ c2VjICAgICAgIEZlYnJ1YXJ5IDIwMDANCg0KDQpSZWZlcmVuY2VzDQoNCiAgICBbR3VwdGFdICAg ICAgICBHdXB0YSwgVi4sICJTZWN1cmUgUmVtb3RlIEFjY2VzcyBvdmVyIHRoZQ0KICAgICAgICAg ICAgICAgICAgIEludGVybmV0IHVzaW5nIElQU2VjLCIgLS0gd29yayBpbiBwcm9ncmVzcywNCiAg ICAgICAgICAgICAgICAgICBkcmFmdC1ndXB0YS1pcHNlYy1yZW1vdGUtYWNjZXNzLTAzLnR4dCwN CiAgICAgICAgICAgICAgICAgICBPY3QsIDE5OTkuDQoNCiAgICBbSUtFXSAgICAgICAgICBIYXJr aW5zLCBELiwgQ2FycmVsLCBELiwgIlRoZSBJbnRlcm5ldCBLZXkNCiAgICAgICAgICAgICAgICAg ICBFeGNoYW5nZSAoSUtFKSwiIFJGQyAyNDA5LCBOb3ZlbWJlciAxOTk4Lg0KDQogICAgW0lTQUtN UF0gICAgICAgTWF1Z2hhbiwgRC4sIFNjaGVydGxlciwgTS4sIFNjaG5laWRlciwgTS4sDQogICAg ICAgICAgICAgICAgICAgYW5kIFR1cm5lciwgSi4sICJJbnRlcm5ldCBTZWN1cml0eSBBc3NvY2lh dGlvbg0KICAgICAgICAgICAgICAgICAgIGFuZCBLZXkgTWFuYWdlbWVudCBQcm90b2NvbCAoSVNB S01QKSwiIFJGQyAyNDA4LA0KICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDE5OTguDQoNCiAg ICBbSVBTRUMtTVNHXSAgICBUZWQgVHMnbywgbWVzc2FnZSAgdG8gdGhlIElFVEYncw0KICAgICAg ICAgICAgICAgICAgIElQc2VjIG1haWxpbmcgbGlzdCwgTWVzc2FnZS1JZDoNCiAgICAgICAgICAg ICAgICAgICA8MTk5OTExMjMyMjE2LlJBQTAxOTMyQHRyYW1wb2xpbmUudGh1bmsub3JnPiwNCiAg ICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMywgMTk5OS4NCg0KICAgIFtKZW5raW5zXSAgICAg IFQuIEplbmtpbnMsICJJUHNlYyBSZWtleWluZyBJc3N1ZXMsIiAtLSB3b3JrIGluDQogICAgICAg ICAgICAgICAgICAgcHJvZ3Jlc3MsIGRyYWZ0LWplbmtpbnMtaXBzZWMtcmVrZXlpbmctMDMudHh0 LA0KICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAwMC4NCg0KICAgIFtLZW50OThhXSAgICAg IFMuIEtlbnQsIFIuIEF0a2luc29uLCAiSVAgRW5jYXBzdWxhdGluZw0KICAgICAgICAgICAgICAg ICAgIFBheWxvYWQsIiBSRkMgMjQwNiwgTm92ZW1iZXIgMTk5OCAob2Jzb2xldGVzDQogICAgICAg ICAgICAgICAgICAgUkZDIDE4MjcsIEF1Z3VzdCAxOTk1KS4NCg0KICAgIFtLZW50OThiXSAgICAg IFMuIEtlbnQsIFIuIEF0a2luc29uLCAiSVAgQXV0aGVudGljYXRpb24NCiAgICAgICAgICAgICAg ICAgICBIZWFkZXIsIiBSRkMgMjQwMiwgTm92ZW1iZXIgMTk5OCAob2Jzb2xldGVzDQogICAgICAg ICAgICAgICAgICAgUkZDIDE4MjYsIEF1Z3VzdCAxOTk1KS4NCg0KICAgIFtLZW50OThjXSAgICAg IFMuIEtlbnQsIFIuIEF0a2luc29uLCAiU2VjdXJpdHkgQXJjaGl0ZWN0dXJlDQogICAgICAgICAg ICAgICAgICAgZm9yIHRoZSBJbnRlcm5ldCBQcm90b2NvbCwiIFJGQyAyNDAxLCBOb3ZlbWJlcg0K ICAgICAgICAgICAgICAgICAgIDE5OTggKG9ic29sZXRlcyBSRkMgMTgyNywgQXVndXN0IDE5OTUp Lg0KDQogICAgW1BpcGVyOThdICAgICAgRC4gUGlwZXIsICJUaGUgSW50ZXJuZXQgSVAgU2VjdXJp dHkgRG9tYWluDQogICAgICAgICAgICAgICAgICAgb2YgSW50ZXJwcmV0YXRpb24gZm9yIElTQUtN UCwiIFJGQyAyNDA3LA0KICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDE5OTguDQoNCiAgICBb TkFQVF0gICAgICAgICBQLiBTcmlzdXJlc2ggYW5kIEsuIEVnZXZhbmcsDQogICAgICAgICAgICAg ICAgICAgIlRyYWRpdGlvbmFsIElQIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdG9yDQogICAgICAg ICAgICAgICAgICAgKFRyYWRpdGlvbmFsIE5BVCkiIC0tIHdvcmsgaW4gcHJvZ3Jlc3MsDQogICAg ICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1uYXQtdHJhZGl0aW9uYWwtMDMudHh0LCBTZXB0ZW1i ZXINCiAgICAgICAgICAgICAgICAgICAxOTk5Lg0KDQogICAgW05BVC1URVJNU10gICAgUC4gU3Jp c3VyZXNoIGFuZCBNLiBIb2xkcmVkZ2UsICJJUCBOZXR3b3JrDQogICAgICAgICAgICAgICAgICAg QWRkcmVzcyBUcmFuc2xhdG9yIChOQVQpIFRlcm1pbm9sb2d5IGFuZA0KDQoNCg0KRXhwaXJlcyBK dW5lIDIwMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMTddDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgUlNJUCBTdXBwb3J0IGZvciBFbmQtdG8tZW5k IElQc2VjICAgICAgIEZlYnJ1YXJ5IDIwMDANCg0KDQogICAgICAgICAgICAgICAgICAgQ29uc2lk ZXJhdGlvbnMsIiBSRkMgMjY2MywgQXVndXN0IDE5OTkuDQoNCiAgICBbUlNJUC1GV10gICAgICBN LiBCb3JlbGxhLCBKLiBMbywgRC4gR3JhYmVsc2t5DQogICAgICAgICAgICAgICAgICAgYW5kIEcu ICBNb250ZW5lZ3JvLCAiUmVhbG0gU3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICBJUDogQSBG cmFtZXdvcmsiIC0tIHdvcmsgaW4gcHJvZ3Jlc3MsDQogICAgICAgICAgICAgICAgICAgZHJhZnQt aWV0Zi1uYXQtcnNpcC1mcmFtZXdvcmstMDMudHh0LA0KICAgICAgICAgICAgICAgICAgIERlY2Vt YmVyIDE5OTkuDQoNCiAgICBbUlNJUC1QXSAgICAgICBNLiBCb3JlbGxhLCBELiBHcmFiZWxza3ks IEouIExvLA0KICAgICAgICAgICAgICAgICAgIEsuIFRhbmlndWNoaSwgIlJlYWxtIFNwZWNpZmlj IElQOiBQcm90b2NvbA0KICAgICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iIC0tIHdvcmsg aW4gcHJvZ3Jlc3MsDQogICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1uYXQtcnNpcC1wcm90 b2NvbC0wNS50eHQsIEphbnVhcnkNCiAgICAgICAgICAgICAgICAgICAyMDAwLg0KDQoNCkF1dGhv ciBhZGRyZXNzZXMNCg0KICAgUXVlc3Rpb25zIGFib3V0IHRoaXMgZG9jdW1lbnQgbWF5IGJlIGRp cmVjdGVkIGF0Og0KDQoNCiAgICAgICAgICBHYWJyaWVsIEUuIE1vbnRlbmVncm8NCiAgICAgICAg ICBTdW4gTGFicyBOZXR3b3JraW5nIGFuZCBTZWN1cml0eSBDZW50ZXINCiAgICAgICAgICBTdW4g TWljcm9zeXN0ZW1zLCBJbmMuDQogICAgICAgICAgOTAxIFNhbiBBbnRvbmlvIFJvYWQNCiAgICAg ICAgICBNYWlsc3RvcCBVTVBLIDE1LTIxNA0KICAgICAgICAgIE1vdW50YWluIFZpZXcsIENhbGlm b3JuaWEgOTQzMDMNCg0KICAgICAgICAgIFZvaWNlOiAgKzEtNDE1LTc4Ni02Mjg4DQogICAgICAg ICAgRmF4OiAgICArMS00MTUtNzg2LTY0NDUNCg0KICAgICAgICAgIEUtTWFpbDogZ2FiQHN1bi5j b20NCg0KDQogICAgICAgICAgTWljaGFlbCBCb3JlbGxhDQogICAgICAgICAgM0NvbSBDb3JwLg0K ICAgICAgICAgIDE4MDAgVy4gQ2VudHJhbCBSZC4NCiAgICAgICAgICBNb3VudCBQcm9zcGVjdCBJ TCA2MDA1Ng0KICAgICAgICAgIFZvaWNlOiAgKzEtODQ3IDM0Mi02MDkzDQoNCiAgICAgICAgICBF LU1haWw6IG1pa2VfYm9yZWxsYUAzY29tLmNvbQ0KDQoNCkNvcHlyaWdodCAoYykgVGhlIEludGVy bmV0IFNvY2lldHkgKDIwMDApLiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQogICBUaGlzIGRvY3Vt ZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRv DQogICBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhl cndpc2UgZXhwbGFpbiBpdA0KICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkg YmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdo b2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55DQoNCg0KDQpFeHBpcmVz IEp1bmUgMjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAxOF0NCgwNCklOVEVSTkVUIERSQUZUICAgICBSU0lQIFN1cHBvcnQgZm9yIEVuZC10by1l bmQgSVBzZWMgICAgICAgRmVicnVhcnkgMjAwMA0KDQoNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQg dGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZQ0KICAgaW5j bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0 aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBz dWNoIGFzIGJ5IHJlbW92aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2Vz IHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBvcmdhbml6YXRp b25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZg0KICAgZGV2ZWxvcGluZyBJ bnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNv cHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBi ZQ0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1 YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9u cyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2Vk IGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuDQoN CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlz IHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVU WSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBB TEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJVVCBOT1Qg TElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTg0K ICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FS UkFOVElFUyBPRg0KICAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB UiBQVVJQT1NFLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCkV4cGlyZXMgSnVuZSAyMDAwICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDQo= --0__=qwT0fhjqvwgWmK9DmdnBkUta9eVm2wny6iT1Pc5vRV2XOPCzMLBkPwm3-- From owner-ipsec@lists.tislabs.com Mon Jan 31 08:59:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14785; Mon, 31 Jan 2000 08:59:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27774 Mon, 31 Jan 2000 10:33:46 -0500 (EST) Message-Id: <3.0.5.32.20000131161452.00c73100@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 31 Jan 2000 16:14:52 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing In-Reply-To: <200001301951.OAA28092@linux.silkroad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA27631 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:51 30.1.2000 -0500, you wrote: > >WG Members: > >We are hearing more and more concerns in the enterprise community >that ISAKMP will be vulnerable to UDP denial of service attacks >in the future. This is a widely known and serious flaw, IMHO. > >---------------------------------------------------------- >FYI Review of RFC 2408: ISAKMP >---------------------------------------------------------- > >2.5.1 Transport Protocol > >ISAKMP can be implemented over any transport protocol or over IP >itself. Implementations MUST include send and receive capability for >ISAKMP using the User Datagram Protocol (UDP) on port 500. >---------------------------------------------------------- > >The specification above means that most vendors who read this >will build ISAKMP on 500/UDP; which means that any malicious >person with a clue as to how UDP DoS attacks can be done will >be able to create chaos with the ISAKMP process during SA >setup, etc. > >Vendors with a clue will build an alternate mechanism which allows >ISAKMP to play using a more robust transport mechanism, at least >TCP based, which raises the bar against simple UDP DoS attacks. > >I suggest the ISAKMP RFC address this vulnerability more directly because >IPSEC and ISAKMP security issues such as this could be treated more >openly in the RFC, perhaps even an ISAKMP protocol risk-analysis should be >documented in the IETF process. > >Finest Regards, >Neo > Folks, let me rephrase the problem to check if we're talking about the same problem here: The problem is that ISAKMP implementation do policy lookups, create state and even do RSA or DH before the IP address of the sender is verified. An attacker could send packets with random source IP address and keep the ISAKMP machine very busy. This could be solved by using another transport layer. For instance, here's my antispoofing protocol: - use UDP port 55555 instead of 500. - a header with a ticket field is used (var length), after that a normal ISAKMP packet. Compare that ticket with Ari Huttunen's state payload. - before doing phase 1 ISAKMP exchange, the initiator requests a ticket from the responder. Like, Initiator sends empty packet, Responder returns ticket (some array of bytes, opaque for the initiator, very much like ISAKMP cookies). If the sender uses wrong source addresses, he never gets my ticket and can't attack my ISAKMP engine. That antispoofing protocol looks too simple. Can somebody check whether this would work? Question is, why wasn't this build into ISAKMP? The normal ISAKMP cookies could have been exchanged before sending the SA payload. Would have taken an extra round-trip, of course. Jörn Sierwald From owner-ipsec@lists.tislabs.com Mon Jan 31 09:05:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14891; Mon, 31 Jan 2000 09:05:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27890 Mon, 31 Jan 2000 10:47:57 -0500 (EST) Date: Mon, 31 Jan 2000 10:52:40 -0500 From: "Michael H. Warfield" To: Ari Huttunen Cc: "Michael H. Warfield" , Michael Richardson , ipsec@lists.tislabs.com, "Mr. Anderson" Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Message-ID: <20000131105240.B9337@alcove.wittsend.com> References: <200001301951.OAA28092@linux.silkroad.com> <200001302330.SAA17310@solidum.com> <20000130210805.A1744@alcove.wittsend.com> <38952701.AB0562DE@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <38952701.AB0562DE@F-Secure.com>; from Ari.Huttunen@F-Secure.com on Mon, Jan 31, 2000 at 08:09:05AM +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Jan 31, 2000 at 08:09:05AM +0200, Ari Huttunen wrote: > "Michael H. Warfield" wrote: > > On Sun, Jan 30, 2000 at 06:30:57PM -0500, Michael Richardson wrote: > > > Switching to TCP does nothing. If you naively implement ISAKMP on top > > > of TCP, then you must include TCP SYN spoof protection, which is much more > > > difficult to deploy and hard to provide different levels of protection for, > > > say, HTTP servers vs ISAKMP daemons. > > I believe the arguement was that the problem with creating state > > due to spoofed packets could have been avoided. It has nothing to do with > > tcp vs udp. I'm not at the bottom of it yet, but it appears that some > > bad choices may have been made and some issues were not been given the > > serious consideration they deserved. > The problem of creating state, or 'cookie crumbs' can be successfully avoided > in at least some of the cases. The basic idea is for the entity that normally > would hold the state to encapsulate the state in a "state payload", and send > that back to to the other entity. The "state payload" would be unforgeable by > the peer, because it has been signed by the entity that created it (using > private key crypto.) When the next protocol message is to be processed, the > entity uses the state in the "state payload" and the other fields contained > in the message to process the message. Only the information needed to verify > the signing on the "state payload" needs to be retained, and that can be shared > with all the connections. This is good... We have a working DoS exploit, so now we need a way to address the problem. This should be incorporated into the standard, since there are vulnerable implimentations being fielded right now. If we can avoid this one, lets do it and get it out of the way. The things that disturb me are "can be successfully avoided in at least some of the cases". If it could have been avoided it should have been and I wonder why it wasn't in the first place. If you say "at least in some of the cases", does that mean that there are some cases where it can not be avoided. If so, then we haven't eliminated the problem, we've merely made it more difficult to exploit. I'm not totally sure that's much of a gain. > The idea is from the paper: > Tuomas Aura and Pekka Nikander, "Stateless connections", in proceedings of > International Conference on Information and Communications Security > ICICS'97, Beijing, November 1997, pp. 87-97, Lecture Notes in Computer Science 1334, > Springer Verlag 1997. > http://www.tcm.hut.fi/~pnr/publications/index.html > This "state payload" is about the same idea that I've written about in > my previous postings about the DoS attack, but at that time I didn't use > the same terminology or encapsulate the information in one place. > The "state payload" can be used by only some of the entities in the > Internet if we give it the following rule: > - If a "state payload" is received in message N by entity A, entity > A must include the "state payload" in message N+1 sent by entity A, > without any modifications to its contents. > This puts all of the responsibility for the security properties of > the "state payload" to the entity that uses it. (And ultimately to > IETF to specify safe usages for it.) > If there's interest for the "state payload", I can write it in the > form of a draft. I would personally say so... I would like to see if this could be implemented and effectively nullify this attack. > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > F-Secure Corporation http://www.F-Secure.com > F-Secure products: Integrated Solutions for Enterprise Security Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Mon Jan 31 13:26:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19988; Mon, 31 Jan 2000 13:26:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28699 Mon, 31 Jan 2000 14:18:32 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0113B6AC@exchange> From: Andrew Krywaniuk To: Joern Sierwald , ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Mon, 31 Jan 2000 14:25:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joern: Question is, why wasn't this build into ISAKMP? The normal ISAKMP cookies could have been exchanged before sending the SA payload. Would have taken an extra round-trip, of course. Andrew: I don't know. Maybe we need to go back and scavenge a few ideas from Photuris. Although Photuris does seem to be vulnerable to modular exponentiation attacks (which is typical of identity protection exchanges), the cookie request exchange is similar to what you proposed. Ari's comment about using public-key crypto to sign the info seems like overkill. Cookies can be encrypted based on local secret info using a fast algorithm. (Why sacrifice CPU consumption to save memory consumption?) The other interesting aspect of Photuris' design is the technique by which the state is stored exclusively by the initiator. This makes it more resistant to cookie crumb attacks. For example, in all the current ISAKMP exchanges, the SA proposal list is generated by the initiator and the responder must choose and remember one. This means that the responder must create a state (for the SA proposal AND for the cookie). In Photuris, the responder generates the SA proposal list. Therefore, he does not need to keep a state (since the proposal list is presumably static or, at the very least, easy to regenerate from policy). Also, all the information needed to generate the keys is sent simultaneously, allowing the responder to make a sudden transition from entirely stateless to fully stateful. Note that we could accomplish the same thing in IKE (a bit less elegantly) by having the initiator resend the selected SA proposal later in the exchange. The same could presumably be done with all the other fields, allowing the responder to make a transition from stateless to stateful immediately after authenticating the peer. Of course, because of the "tragedy of the commons" principle, none of us are going to do anything about DoS until our customers ask for it, and our customers aren't going to ask for it until there are highly-publicized attacks. I mean, mathematicians have been publishing reports for years saying that DES can be cracked. They will usually state that it will take X amount of CPU power (which is equivalent to Y PCs working in parallel for Z hours). It's not really even a debatable analysis, but the mainstream media ignores the result until someone actually goes and does it. Some day they'll publish a newspaper story... "Mathematicians have long suspected that two to the power of a googaplex was even, but now John Doe has given them conclusive proof. An array of 10000 Cray supercomputers, the largest ever chained worked tirelessly to compute the exponent..." Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. -----Original Message----- From: Joern Sierwald [mailto:joern.sierwald@f-secure.com] Sent: Monday, January 31, 2000 10:15 AM To: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing At 14:51 30.1.2000 -0500, you wrote: > >WG Members: > >We are hearing more and more concerns in the enterprise community >that ISAKMP will be vulnerable to UDP denial of service attacks >in the future. This is a widely known and serious flaw, IMHO. > >---------------------------------------------------------- >FYI Review of RFC 2408: ISAKMP >---------------------------------------------------------- > >2.5.1 Transport Protocol > >ISAKMP can be implemented over any transport protocol or over IP >itself. Implementations MUST include send and receive capability for >ISAKMP using the User Datagram Protocol (UDP) on port 500. >---------------------------------------------------------- > >The specification above means that most vendors who read this >will build ISAKMP on 500/UDP; which means that any malicious >person with a clue as to how UDP DoS attacks can be done will >be able to create chaos with the ISAKMP process during SA >setup, etc. > >Vendors with a clue will build an alternate mechanism which allows >ISAKMP to play using a more robust transport mechanism, at least >TCP based, which raises the bar against simple UDP DoS attacks. > >I suggest the ISAKMP RFC address this vulnerability more directly because >IPSEC and ISAKMP security issues such as this could be treated more >openly in the RFC, perhaps even an ISAKMP protocol risk-analysis should be >documented in the IETF process. > >Finest Regards, >Neo > Folks, let me rephrase the problem to check if we're talking about the same problem here: The problem is that ISAKMP implementation do policy lookups, create state and even do RSA or DH before the IP address of the sender is verified. An attacker could send packets with random source IP address and keep the ISAKMP machine very busy. This could be solved by using another transport layer. For instance, here's my antispoofing protocol: - use UDP port 55555 instead of 500. - a header with a ticket field is used (var length), after that a normal ISAKMP packet. Compare that ticket with Ari Huttunen's state payload. - before doing phase 1 ISAKMP exchange, the initiator requests a ticket from the responder. Like, Initiator sends empty packet, Responder returns ticket (some array of bytes, opaque for the initiator, very much like ISAKMP cookies). If the sender uses wrong source addresses, he never gets my ticket and can't attack my ISAKMP engine. That antispoofing protocol looks too simple. Can somebody check whether this would work? Question is, why wasn't this build into ISAKMP? The normal ISAKMP cookies could have been exchanged before sending the SA payload. Would have taken an extra round-trip, of course. Jörn Sierwald From owner-ipsec@lists.tislabs.com Mon Jan 31 14:36:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20978; Mon, 31 Jan 2000 14:36:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28995 Mon, 31 Jan 2000 15:53:25 -0500 (EST) Date: Mon, 31 Jan 2000 15:55:27 -0500 Message-Id: <200001312055.PAA13055@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "Mr. Anderson" CC: mhw@wittsend.com, mcr@solidum.com, ipsec@lists.tislabs.com, neo@silkroad.com In-reply-to: Mr. Anderson's message of Sun, 30 Jan 100 21:55:47 -0500 (EST), <200001310255.VAA32377@linux.silkroad.com> Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me make a couple of observations here. A lot of people have been getting all excited about the "cookie crumb" attack, thinking that it's something new, or something super serious. First of all, it should be recognized that the designers of ISAKMP made an engineering trade-off. In Photuris, a cookie exchange was done at the beginning before anything else was done. This allowed the responder to know that the initiator was coming from a valid IP address before having to create *any* state. However, this was done at the cost of an extra round-trip. In ISAKMP, some state does need to be created, but no heavy-weight crypto operations need to be done until the second packet from the initiator is received, at which point the initiator knows the initiator is coming from a valid IP address. The fact that this state needs to be garbage collected is explicitly mentioned in RFC 2409: It should be noted that in the exchanges shown in section 4, the anticlogging mechanism should be used in conjuction with a garbage- state collection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created. Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti- clogging only phase, as was done in [Karn]. Now, was this a bad decision? It depends on how much you value minimization of round-trips, and how bad you believe the resulting DoS possibilities are as a result. As regards to the latter question, it should be noted that most of the TCP/IP infrastructure is subject to the same problem; to wit, the SYN attack --- and there are defenses against it. It's interesting to note that defenses that worked well towards prventing the SYN attack, such as random drop, also work just as well on the so-called "cookie crumb" attack. Furthermore, it's not true that the cookie prevents all DoS attacks. It simply prevents DoS attacks that come from spoofed IP address such that it is hard to track down from whence they came. In the TCP SYN attack, part of the problem was that with the listen queue depth set at 5, it was possible for a very low-bandwidth attack to completely paralyze a host, and if an attack only required sending a packet or two per minute, it was hard to identify the source, both to block it and to implement out-of-band-corrective-measures (i.e., a smackdown). But in the case of the "exploit" provided by Simpson, the IKE implementation is flooded by cookies as fast as the receiver can send them. True, the IP addresses were masked so you couldn't trace it back via the IP address. But the packet flow is big enough that it should be fairly easy to track it back simply by looking at the packet statistics at various router interfaces. This makes it very much unlike the TCP Syn attack, and therefore much less of an issue. True, Simpson's program could modified to slow down the rate at which cookies were issued, in an attempt to evade detection. However, this also slows the rate at which state needs to kept, and assuming that the recommendation in RFC 2409 is followed to have a good garbage collection mechanism (and a random drop technique when huge number of initial cookies are found in the system should do the trick quite nicely --- see discussions regarding the SYN attack about why this works), it's hard for me to see why this is such a huge problem as some people make it out to be. Fundamentally, it is extremely hard to defend against all denial of service attacks. If an attacker is willing to give away their location (or at least their IP address), the cookie doesn't save you. A large part of the defense against DoS attacks is the knowledge that if it is attempted that the problem can be easily traced back to the perpetrator. This doesn't have to be by IP address, however. If it involves a very heavy packet flow, it can be just as easily traced back. Hence, all that is necessary is to harden an implementation to such a point that in order to carry out such a clogging attack, the attacker is forced to use a heavy enough flow that the flow can be easily traced back to the source. - Ted From owner-ipsec@lists.tislabs.com Mon Jan 31 15:48:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22046; Mon, 31 Jan 2000 15:48:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29220 Mon, 31 Jan 2000 17:14:08 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DCCDE93B@new-exc1.ctron.com> References: <29752A74B6C5D211A4920090273CA3DCCDE93B@new-exc1.ctron.com> Date: Mon, 31 Jan 2000 17:18:33 -0500 To: "Waters, Stephen" From: Stephen Kent Subject: RE: Bruce Schneier on IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, > >1) Compression. Van Jacobson-style compression could be used on TCP/IP (and >other prots now), and is far more efficient that LZS would be on these >headers. Perhaps the IPCOMP header need to allow of a marker to tell the >receiver that Van-J has been used, and this should be added to the IPCOMP >negotiation in IKE? maybe. >2) Tunnel v Transport. In the mood of simplification, there may be a >counter arguement to drop 'tunnel-mode' and keep just transport! In the >same way that L2TP tunnel traffic is transport-mode protected, IPIP tunnel >traffic can be transport-mode protected. This separates IPSEC from >'tunneling' altogether - a good idea in my mind, since IPIP tunnels have a >use in their own right. I know this presents a different model, but it is >the one we use for LAN-LAN tunnels (L2TP and IPIP) for simplicity. It >allows tunnel details (like the fun with MTU) to be left out of the IPSEC >specs - apart from mentioning security aspects. Transport-mode protection >of IPIP tunnel packets = 'IPSEC Tunnel Mode'. I don't think this works, for several reasons. First, a critical feature of IPsec is the access control provided by comparing the "appropriate" headers of traffic to the SA selectors, not only at the sender but at the receiver, after decryption. This feature is lost if one uses transport mode even when tunneling, one of the shortcomings of L2TP's use of transport mode. You can't do as good a job of access control outside of IPsec, because by then you have lost the header info that tells you on which SA a packet was received. Also, tunneling imposes problems due to MTU changes, in any case. With IPsec,a returned packet may not have enough header data available to make it useful to pass to a completely separate IPIP tunneling protocol implementation, but IPsec has access to some of its header info, which can help in the process. So, I think that trying to use transport mode, with IPIP tunneling above it, will not be a suitable alternative to tunnel mode. >3) Using AH makes NAT (and Tos mapping) a little difficult. Perhaps 'RSIP' >will help here. If not for the NAT issues, I think IPIP tunnel traffic >should be protected with AH+ESP transport mode. With NAT as a problem, just >ESP transport mode. Even ESP transport mode fails with NAT, under the current design because the TCP header encompasses the IP pseudo header. I have yet to look at RSIP, so it may help solve the problem. >4) Fragmentation - leave this issue to IPIP tunnel specification. >IPSEC-overhead calculation and be included the MTU maths via a 'system >service' call, but not >needed as part of the IPSEC spec. See comments above re the problems of divorcing fragmentation and MUT issues from IPsec. Steve From owner-ipsec@lists.tislabs.com Mon Jan 31 17:44:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA23281; Mon, 31 Jan 2000 17:44:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29788 Mon, 31 Jan 2000 19:38:30 -0500 (EST) Date: Mon, 31 Jan 2000 18:35:42 -0600 From: Will Fiveash To: IETF IPSEC Subject: Re: issues raised at VPN interoperability workshop Message-ID: <20000131183542.B64874@austin.ibm.com> References: <51C0AF25889FD211AC3F00A0C984090D02D30C24@orsmsx50.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <51C0AF25889FD211AC3F00A0C984090D02D30C24@orsmsx50.jf.intel.com>; from ylian.saint-hilaire@intel.com on Thu, Jan 27, 2000 at 04:23:14PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jan 27, 2000 at 04:23:14PM -0800, Saint-Hilaire, Ylian wrote: > > I got a bunch of questions about the Commit bit, it seems it does not make > much sense to have the initiator of phase 1 raise CB. If he does, It is not > clear what should be done. > > ---------- > > If I am the phase 2 responder, and I see the initiator raising CB on the > first packet, is it ok for me to voluntarily not echo it back? Yes. > As a responder, if I wanted to use CB to get the SA in my driver first... by > having the initiator raise CB first, I lost my chance to use the CB as > intended. No, see below. > Is it correct to assume that generally, the responder of a phase 2 will be > the first to raise it? Not necessarily. > If the initiator raises CB first, the conversation will look like this: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDci, IDcr ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDci, IDcr ] > HDR*, HASH(3) --> > HDR*, HASH, CONNECT --> Not if you follow draft-ieft-ipsec-ike-01.txt. It states: The commit bit in the ISAKMP header ([MSST98]) can be used to extend a Quick Mode by a single message from the Responder to the Initiator to delay use of the SAs created by the Quick Mode. This message will It does not say that the Initiator can send a connect-notify to the responder. > What do I do if I get the CONNECT notify before HASH(3)? Do ignore it, get > the Quick mode message than retry again till I get the CONNECT again? or can > I simply not echo CB and forget about this case? The responder should not get a connect-notify from the initiator regardless of who set the CB. -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 From owner-ipsec@lists.tislabs.com Mon Jan 31 17:49:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA23332; Mon, 31 Jan 2000 17:49:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29750 Mon, 31 Jan 2000 19:21:41 -0500 (EST) Date: Mon, 31 Jan 2000 18:26:43 -0600 From: Will Fiveash To: ipsec@lists.tislabs.com Subject: Re: issues raised at VPN interoperability workshop Message-ID: <20000131182643.A64874@austin.ibm.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <319A1C5F94C8D11192DE00805FBBADDF0113B09E@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0113B09E@exchange>; from akrywaniuk@TimeStep.com on Thu, Jan 27, 2000 at 04:19:39PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Jan 27, 2000 at 04:19:39PM -0500, Andrew Krywaniuk wrote: > I don't think this is a fair assumption. If I am not expecting a > NOTIFY_CONNECTED then I will most likely delete my quick mode object soon > after sending QM3. (I will keep it around for a little while in case I need > to retransmit.) This creates a race conditions: If your spurious > NOTIFY_CONNECTED arrives after I have deleted my quick mode object then I > will not know what to do with it. (In fact, I will most likely think that it > is a malformed QM1.) If your implementation receives a spurious connect-notify will it affect (i.e. delete) the previously negotiated P2 SA? I hope it won't. The reason I implemented the responder sending the connect-notify (C-N) if commit bit (CB) was turned off by the initiator is that during the San Diego bakeoff I encountered an implementation where as the initiator it did not reflect the CB yet expected the C-N. Yes, I know the implementation was broken but I thought that sending a C-N would not really hurt even if the initiator was not expecting it and should increase the likelihood successful IPSec tunnel creation. If we can all agree that an implementation MUST reflect the CB if they intend to honor it otherwise they should not reflect the CB then I would not send the C-N as a responder if the initiator did not reflect it. > Aside from the fact that the CB doesn't really accomplish much unless the > peer's implementation queues packets (I suspect that most sgws don't) and > yours doesn't... > > 1. The initiator has ample opportunity to setup his SA before the responder > uses it. > 2. The initiator was the one who decided to initiate the SA. Therefore, one > can conclude that he will also be the first one to use it. I'm not sure this is true. Let's say Host A initiates the 1st QM negotiation for a IPSec tunnel between Host A and Host B then Host B initiates the next QM negotiation that will refresh the P2 SA for the IPSec tunnel between them because Host B's P2 SA lifetime was shorter than Host A's. Which host will be the first to use the new P2 SA? > The commit bit fixes a race condition that only affects the responder. If > the responder wants to send the connected notify then he should set the bit > himself. But isn't it possible that whomever is initiating may want the responder to have its P2 SA in place so that it is less likely to drop the initiator's packets? -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904