From gregory.ietf@gmail.com Wed Nov 4 09:45:31 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117753A67E5 for ; Wed, 4 Nov 2009 09:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ35-7PxCfbk for ; Wed, 4 Nov 2009 09:45:29 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 8EB663A691D for ; Wed, 4 Nov 2009 09:45:29 -0800 (PST) Received: by mail-ew0-f207.google.com with SMTP id 3so3351836ewy.37 for ; Wed, 04 Nov 2009 09:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=p+LMjd11Az4DTO8R4PaOEVbUtQ+RL3EcwiKOOB2IOXc=; b=q73u1Nz5OqX6bEQ9dreg/YrvHQdGu5Z9SUw07V6abpwFnxRKEqOcDk8VlXgYcFlbdR AgDk1BDTJ/sdaz2ntsdeMKg5a33R20LIJFl3hLOHAz0u6/lTRQXUKX4svzoQ7PMqwIXs iRk4w3yXhO1Rmz9kYnbH0XlFfrhGaef27ciwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=kiiyLTSDsaY5Lk1o0EVSCucCEKjZ+iejT4mQosSqc/lEAsMze3cQCTiBWomizjKeA0 4UgjlHt05GmEG2JUPwXMwmqF5zxaE73VJZ6gV0hd+zWzJHnsIeo0mSMJSudZ0kyin7xd 6L3Giu/0HxBVwttPqTHeFcL6/hHfDkgB4KIAI= Received: by 10.216.86.211 with SMTP id w61mr620612wee.6.1257356751229; Wed, 04 Nov 2009 09:45:51 -0800 (PST) Received: from Gregory-T60.gmail.com ([58.187.119.136]) by mx.google.com with ESMTPS id j8sm3715177gvb.19.2009.11.04.09.45.48 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 09:45:50 -0800 (PST) Message-ID: <4af1bdce.0856100a.6cba.ffffcafc@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Nov 2009 02:07:00 -0800 To: Sean Shen ,karp@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: <042501c9a876$e42e59e0$800c6f0a@china.huawei.com> References: <042501c9a876$e42e59e0$800c6f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_439280765==.ALT" Subject: Re: [karp] Shen review, draft-lebovitz-kmart-roadmap-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:45:31 -0000 --=====================_439280765==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hey Sean, Thanks for the review. I'm not sure how it slipped through the cracks, but I just came across it in my inbox today, while updating the document. See comments below... (and note: I'm cc'ing the new list "KARP", because we moved away from the name "kmart"P At 01:41 AM 3/19/2009, Sean Shen wrote: >Hi, Gregory, >I found the draft content is rich and valuable. I have not finished >reading all details and have some questions/comments so far, >hopefully will fire out more soon. > > >#1. >The first paragraph of section 3 gives me the feeling that the >classification for KMP purpose. I am not sure my understanding is correct. We do the categorization to try to group problem spaces / solutions. This is partly for KMP purpose, but also for how the keys and message transactions will need to occur. Did you have proposed text changes? > >#2. >The classification in Section 3.1. What's the difference between >"one-to-one" and "client-server" (in KMP point of view?)? Plan to >use out-of-band KMP for one-to-one and in-line KMP for client-server? You know, I'm not really sure that the distinction is clear enough to last. When we originally brainstormed it (we = me, sec AD's, rtg AD's, Danny McPherson) we thought of BGP as a clear example of one-to-one. And we thought of end-point discovery protocols as examples of client-server, or perhaps something like BGP route reflector as client-server. One reason they could be different is because if one is clearly the client (i.e. a BGP router) and one is clearly a server (the route reflector), then a client-server model for authentication could be used, where each of the clients is configured with the credentials for the server, and the server is configured with the credentials of the clients, but not all the clients know of each other apriori. Just thinking outlout. We definitely need more discussiona dn work on these definitions. > >#3 >The requrements for Phase1 update in section 4.2 is critical, are >there any priority order? not really, no. >Defining what elements should be protected might be done first, This might well be different for each Routing Protocol. >some of the work (like what are strong algorithms) are fairly >independent of routing protocols themselfs , agreed. > some (like rekeying) are not, agreed, that the exact mechanism will be different per protcol, but that the basic way one does this should be pretty consistent, i.e. something connection specific used in a KDF along with the Master Key which yields a connection specific Traffic Key, and some indication of keyID so that each knows which key is being used. Were you thinking there needs to be text in the document associated with these questions? Or are these just clarification for yourself? Please feel free to propose text. > overall, will there be a schedule? what type of schedule? There will be milestones associated with the WG, once formed. Is that what you meant? > >#4. >For all the keying work in section 4.2, are you refering to >currently used keying? Namely, one single manual key, from the >survey info in section 1.2.4? Yes, the requirements there are for Phase 1, which is enhancing the Routing Protocol's manual key mechanism so that it can do the things listed in 4.2. Once that is done, we can get to work on layering on a KMP. Please let me know if you think the answers above should in some way generate new/different text for the draft. Thanks again for the review, Gregory. > >Best, > >Sean > > > > > > > > > >---------- >From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >Behalf Of Gregory Lebovitz >Sent: Tuesday, March 17, 2009 4:12 AM >To: kmart@ietf.org; saag@ietf.org; rtgwg@ietf.org >Cc: Ross Callon; Tim Polk; Pasi Eronen; Danny McPherson >Subject: Pls review draft-lebovitz-kmart-roadmap-01.txt > >Hey all, > >The -01 draft that captures the goals, definition of work, and order >of priorities for securing routing protocol transports is here: > >http://www.ietf.org/internet-drafts/draft-lebovitz-kmart-roadmap-01.txt > > >This represents joint work of the IAB, RTG and SAAG areas, under the >guidance of the ADs of both. > >This document will be presented in IETF74 at: > - RTG WG > - SAAG > - SIDR (brief advertisement) > - Others ? (pls let me know) > >Pls respond with comments to me, and cc the >kmart@ietf.org mail list. > >Gregory. > >-- >---- >IETF related email from >Gregory M. Lebovitz >Juniper Networks --=====================_439280765==.ALT Content-Type: text/html; charset="us-ascii" Hey Sean,

Thanks for the review. I'm not sure how it slipped through the cracks, but I just came across it in my inbox today, while updating the document.  See comments below...
(and note:  I'm cc'ing the new list "KARP", because we moved away from the name "kmart"P

At 01:41 AM 3/19/2009, Sean Shen wrote:
Hi, Gregory,
I found the draft content is rich and valuable. I have not finished reading all details and have some questions/comments so far, hopefully will fire out more soon.
 
 
#1.
The first paragraph of section 3 gives me the feeling that the classification for KMP purpose. I am not sure my understanding is correct.

We do the categorization to try to group problem spaces / solutions. This is partly for KMP purpose, but also for how the keys and message transactions will need to occur.  Did you have proposed text changes?

 
#2.
The classification in Section 3.1. What's the difference between "one-to-one" and "client-server" (in KMP point of view?)? Plan to use out-of-band KMP for one-to-one and in-line KMP for client-server?

You know, I'm not really sure that the distinction is clear enough to last. When we originally brainstormed it (we = me, sec AD's, rtg AD's, Danny McPherson) we thought of BGP as a clear example of one-to-one. And we thought of end-point discovery protocols as examples of client-server, or perhaps something like BGP route reflector as client-server. One reason they could be different is because if one is clearly the client (i.e. a BGP router) and one is clearly a server (the route reflector), then a client-server model for authentication could be used, where each of the clients is configured with the credentials for the server, and the server is configured with the credentials of the clients, but not all the clients know of each other apriori. Just thinking outlout. We definitely need more discussiona dn work on these definitions.

 
#3
The requrements for Phase1 update in section 4.2 is critical, are there any priority order?

not really, no.

Defining what elements should be protected might be done first,

This might well be different for each Routing Protocol.

some of the work (like what are strong algorithms) are  fairly independent of routing protocols themselfs ,

agreed.

 some (like rekeying) are not,

agreed, that the exact mechanism will be different per protcol, but that the basic way one does this should be pretty consistent, i.e. something connection specific used in a KDF along with the Master Key which yields a connection specific Traffic Key, and some indication of keyID so that each knows which key is being used.

Were you thinking there needs to be text in the document associated with these questions? Or are these just clarification for yourself? Please feel free to propose text.

 overall, will there be a schedule?

what type of schedule? There will be milestones associated with the WG, once formed. Is that what you meant?

 
#4.
For all the keying work in section 4.2, are you refering to currently used keying? Namely, one single manual key, from the survey info in section 1.2.4?

Yes, the requirements there are for Phase 1, which is enhancing the Routing Protocol's manual key mechanism so that it can do the things listed in 4.2. Once that is done, we can get to work on layering on a KMP.

Please let me know if you think the answers above should in some way generate new/different text for the draft.

Thanks again for the review,
Gregory.

 
Best,
 
Sean 
 
 
 

 
 
 

From: rtgwg-bounces@ietf.org [ mailto:rtgwg-bounces@ietf.org] On Behalf Of Gregory Lebovitz
Sent: Tuesday, March 17, 2009 4:12 AM
To: kmart@ietf.org; saag@ietf.org; rtgwg@ietf.org
Cc: Ross Callon; Tim Polk; Pasi Eronen; Danny McPherson
Subject: Pls review draft-lebovitz-kmart-roadmap-01.txt

Hey all,
 
The -01 draft that captures the goals, definition of work, and order of priorities for securing routing protocol transports is here:
   http://www.ietf.org/internet-drafts/draft-lebovitz-kmart-roadmap-01.txt
 
This represents joint work of the IAB, RTG and SAAG areas, under the guidance of the ADs of both.
 
This document will be presented in IETF74 at:
 - RTG WG
 - SAAG
 - SIDR (brief advertisement)
 - Others ? (pls let me know)
 
Pls respond with comments to me, and cc the kmart@ietf.org mail list.
 
Gregory.

--
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks
--=====================_439280765==.ALT-- From gregory.ietf@gmail.com Wed Nov 4 09:45:32 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26CC3A69E2 for ; Wed, 4 Nov 2009 09:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+sXbm0RbCRr for ; Wed, 4 Nov 2009 09:45:27 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id F30E63A6832 for ; Wed, 4 Nov 2009 09:45:25 -0800 (PST) Received: by ewy3 with SMTP id 3so3351836ewy.37 for ; Wed, 04 Nov 2009 09:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=UPsu3SWxU7LE0p+ccabR2SXHbGfEq5LS5LG+smuI8p4=; b=RdMacRo0Plqdp+zcDFaE+zx99u0L6ZeI1QLnJOPL2gxuIQiuzwo6giBeDpTeAi/eq3 BmriyQVGVk7EWWJpoqydMpMsR6uMGPzEC3xuB1wDdPkATiqcQ1PkWN+ng3pxepL8h6wY 3Bs5xsUMsXau/H8opKQC1X/8tqSOKyB6smgdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=EGEc+8/upvu11CV0YTwHpSi2T4RpPjJD/ewAVEQQkHdUbhIg9KPzfmigGHx6dPY9mU p+C4LBxPZkn4J6U1429Y8bzJCSVXZg9e+UlrHFY8vusBDmQpWVvUMg1tSVRuqnZn8pfs FQtOFNFayJZwB7R6kuZ+uiJFkIeGqMa7+I06E= Received: by 10.216.91.67 with SMTP id g45mr531678wef.190.1257356744132; Wed, 04 Nov 2009 09:45:44 -0800 (PST) Received: from Gregory-T60.gmail.com ([58.187.119.136]) by mx.google.com with ESMTPS id j8sm3715177gvb.19.2009.11.04.09.45.05 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 09:45:41 -0800 (PST) Message-ID: <4af1bdc5.0856100a.6cba.ffffcae8@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Nov 2009 00:08:09 -0800 To: Danny McPherson From: "Gregory M. Lebovitz" In-Reply-To: <7CEEE531-71C3-46E5-B9B5-2FF17AFDD856@tcb.net> References: <7CEEE531-71C3-46E5-B9B5-2FF17AFDD856@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IAB IAB , karp@ietf.org Subject: Re: [karp] [IAB] Fwd: Attached: draft-lebovitz-kmart-roadmap-01-00.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:45:33 -0000 Danny, the lastest version of the document contains changes based on your feedback. Thanks a ton for the thorough review. See comments below... At 02:14 PM 3/18/2009, Danny McPherson wrote: >Comments inline.. > >- >Seems this document is a framework, requirements, and >in part, solutions draft, and this tends to muddy the >objectives considerably. Agree. It's a catch-all at present. I put in a paragraph in the intro stating as much, and suggesting how it might be broken up into smaller, more focused docs. We will break it up into more focused docs once the BoF is over, and the WG starts. Ideally we would have done it before, but I just didn't have the cycles. >- >I agree with Ward about per AF and even AF/SAF password >pairs, as folks setup discrete sessions based on these >today, and his other comments as well. > >-danny > > >On Mar 11, 2009, at 1:19 AM, Gregory Lebovitz wrote: >> >>Internet-Draft >>Juniper >>Intended status: Informational March 10, >>2009 >>Expires: September 11, 2009 >> >>Roadmap for Cryptographic Authentication of Routing Protocol Packets >>on >> the Wire >> draft-lebovitz-kmart-roadmap-01 >.... > >>Internet-Draft KMART Roadmap March >>2009 >> >>1. Introduction >> In March 2006 the Internet Architecture Board (IAB) held a workshop >> on the topic of "Unwanted Internet Traffic". The report from that >> workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that >> document states that "A simple risk analysis would suggest that an >> ideal attack target of minimal cost but maximal disruption is the >> core routing infrastructure." Section 8.2 calls for "[t]ightening >> the security of the core routing infrastructure." Four main steps >> were identified for that tightening: >> o More secure mechanisms and practices for operating routers. >>This >> work is being addressed in the OpSec Working Group. > >I believe it's 'OPSEC' from a capitalization perspective. done. >> o Cleaning up the Internet Routing Registry repository [IRR], and >> securing both the database and the access, so that it can be >>used >> for routing verifications. This work is being conducted through >> liaisons with the RIR's globally. > >The RIRs don't own most of the IRRs, and this is a bit confusing >in this context. I'm not sure this work is really happening, >actually. done. >> o Specifications for cryptographic validation of routing message >> content. This work is being done in the SIDR Working Group. > >Actually, the only thing SIDR has really done to date is define >the repository structure for the RPKI. They have not done anything >with actual use of this information in the operational routing >system itself. made it a future reference, "this work will likely be done in the SIDR WG" >> o Securing the routing protocols' packets on the wire >> This document addresses the last bullet, securing the packets on >>the >> wire of the routing protocol exchanges. > >It might be nice if you define in the introduction where the >term 'KMART' came from. Done. Now called KARP. >>1.1. Terminology >> [to be filled out later] >> Base RP >> key_store >> KMP >> session keys This whole sesssion filled in now. >>1.2. Requirements Language >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >>this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >>1.3. Scope >> Four basic tactics may be employed in order to secure any piece of >> data as it is transmitted over the wire: privacy (or encryption), >> authentication, message integrity, and non-repudiation. The focus >> for this effort, and the scope for this roadmap document, will be >> >>Lebovitz & Expires September 11, 2009 >>[Page 4] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> message authentication and packet integrity only. This work >> explicitly excludes, at this point in time, the other two tactics: >> privacy and non-repudiation. Since the objective of most routing >> protocols is to broadly advertise the routing topology, routing >> messages are commonly sent in the clear; confidentiality is not >> normally required for routing protocols. However, ensuring that >> routing peers truly are the trusted peers expected, and that no >>roque >> peers or messages can compromise the stability of the routing >> environment is critical, and thus our focus. The other two >> explicitly excluded tactics, privacy and non-repudiation, may be >> addressed in future work. >> It is possible for routing protocol packets to be transmitted >> employing all four security tactics mentioned above using existing >> standards. For example, one could run unicast, layer 3 or above >> routing protocol packets through IPsec ESP [RFC4303]. This would >> provide the added benefit of privacy, and non-repudiation. >>However, >> routing products have been fine tuned over the years for the >>specific > >"routing products" reads a bit odd. Either say "routers" or >"routing protocols". I used "router platforms and systems" >> processing necessary for these routing protocols non-encapsulated >> formats. > >That last bit reads a bit odd, or is perhaps overly redundant >given the earlier part of the text. cleaned it a bit. >>Operators are, therefore, quite unwilling to explore new > >s/unwilling/reluctant/ done. >> packet encapsulations for these tried and true protocols. >> In addition, at least in the case of BGP and LDP, these protocols >> already have existing mechanisms for cryptographically >>authenticating >> and integrity checking the packets on the wire. Products with >>these >> mechanisms have already been produced, code has already been >>written >> and both have been optimized for the existing mechanisms. Rather >> than turn away from these mechanisms, we want to enhance them, >> updating them to modern and secure levels. > >What's a "modern and secure level"? > >> There are two main work phases for this roadmap, and for any BaseRP > >What's "BaseRP"? You use both it and "Base RP" throughout. Also, >RP, as you're likely aware, is commonly used to compress 'Relying >Party" in PKI realms, so it might be confused when used in this >context -- unless explicitly pre-defined. I've replaced "RP" and "BaseRP" with Routing Protocol throughout the document, and I defined the capitalized version in the terminology section to mean "Routing Protocol for which work is being done to provide or enhance its peer authentication mechanisms." >> work undertaken as part of this roadmap (discussed further in the >> Work Phases (Section 4.1) section). The first is to enhance the >>Base >> RP's current authentication mechanism, ensuring it employs modern > >So "RP" is "routing protocol"? You might want to define that >above, as I've not seen that employed in other places within the >IETF as such. > >> cryptographic algorithms and methods for its basic operational >>model, >> fulfillling the requirements defined in the Requirements > >s/fulfillling/fulfilling/ done. >> (Section 4.2) section, and protecting against as many of the >>threats >> as possible as defined in the Threats (Section 2.1)section. Many >>of > >s/Section 2.1)section/Section 2.1( section/ done. >> the BaseRPs' current mechanisms use manual keys, so the first phase >> updates will focus on shoring up the manual key mechanisms that >> exist. >> The second work phase is to define the use of a key management >> protocol (KMP) for creating and managing session keys used in the >> BaseRPs' message authentication and data integrity functions. It >>is >> hoped that a general KMP framework -- or a small number of >>frameworks >s/hoped/intended/ done >You also need to expand KMP and all the other acronyms >upon first use here. done in the terminology section, which is now filled out in the most recent version. >> -- can be defined and leveraged for many BaseRPs. >> >> >>Lebovitz & Expires September 11, 2009 >>[Page 5] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> Therefore, the scope of this roadmap of work includes: >> o Making use of existing routing protocol security protocols, >>where >> they exist, and enhancing or updating them as necessary for >>modern >> cryptographic best practices, >> o Developing a framework for using automatic key management in >>order >> to ease deployment, lower cost of operation, and allow for rapid >> responses to security breaches, and > >> o Specifying the automated key management protocol that may be >> combined with the bits-on-the-wire mechanisms. >> The work also serves as an agreement between the Routing Area and >>the >> Security Area about the priorities and work plan for incrementally >> delivering the above work. This point is important. There will be >> times when the best-security-possible will give way to vastly- >> improved-over-current-security-but-admittedly-not-yet-best- security- >> possible, in order that incremental progress toward a more secure >> Internet may be achieved. As such, this document will call out >> places where agreement has been reached on such trade offs. > > >> This document does not contain protocol specifications. Instead, >>it >> defines the areas where protocol specification work is needed and >> sets a direction, a set of requirements, and a relative priority >>for >> addressing that specification work. >> There are a set of threats to routing protocols that are considered >> in-scope for this document/roadmap, and a set considered out-of- >> scope. These are described in detail in the Threats (Section 2) >> section below. >>1.4. Goals >> The goals and general guidance for this work roadmap follow: >> 1. Provide authentication and integrity protection for packets on >>the >> wire of existing routing protocols >> 2. Deliver a path to incrementally improve security of the routing >> infrastructure. The principle of crawl, walk, run will be in >> place. Routing protocol authentication mechanisms may not go >> immediately from their current state to a state containing the >> best possible, most modern security practices. Incremental >>steps >> will need to be taken for a few very practical reasons. First, >> there is a great deal of deployed routing devices in operating > >s/is a great deal of/are a considerable number of/ done. >> networks that will not be able to run the most modern >> cryptographic mechanisms without significant and unacceptable >> >>Lebovitz & Expires September 11, 2009 >>[Page 6] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> performance penalties. The roadmap for any one routing protocol >> MUST allow for incremental improvements on existing operational >> devices. Second, current routing protocol performance on >>deployed >> devices has been achieved over the last 20 years through >>extensive >> tuning of software and hardware elements, and is a constant >>focus >> for improvement by vendors and operators alike. The >>introduction >> of new security mechanisms affects this performance balance. >>The >> performance impact of any incremental step of security >>improvement >> will need to be weighed by the community, and introduced in >>such a >> way that allows the vendor and operator community a path to >> adoption that upholds reasonable performance metrics. >>Therefore, >> certain specification elements may be introduced carrying the >> "SHOULD" guidance, with the intention that the same mechanism >>will >> carry a "MUST" in the next release of the specification. This >> gives the vendors and implementors the guidance they need to >>tune >> their software and hardware appropriately over time. Last, some >> security mechanisms require the build out of other operational >> support systems, and this will take time. An example where >>these >> three reasons are at play in an incremental improvement >>roadmap is >> seen in the improvement of BGP's [RFC4271] security via the >>update >> of the TCP Authentication Option (TCP-AO) >> [I-D.ietf-tcpm-tcp-auth-opt] effort. It would be ideal, and >> reflect best common security practice, to have a fully specified >> key management protocol for negotiating TCP-AO's authentication >> material, using certificates for peer authentication in the >> keying. However, in the spirit of incremental deployment, we >>will >> first address issues like cryptographic algorithm agility, >>replay >> attacks, TCP session resetting in the base TCP-AO protocol >>before >> we layer key management on top of it. > > >> 3. The deploy-ability of the improved security solutions on >>currently >> running routing infrastructure equipment. This begs the >> consideration of the current state of processing power available >> on routers in the network today. > >While this is certainly a consideration, I'm not sure why it's >outlined in the Goals so explicitly, or even captured in the >#2 bullet point as well. so, what's your suggestion for how to change the text? >> 4. Operational deploy-ability - A solutions acceptability will also >> be measured by how deployable the solution is by common operator >> teams using common deployment processes and infrastructures. >>I.e. >> We will try to make these solutions fit as well as possible into >> current operational practices or router deployment. This will >>be >> heavily influenced by operator input, to ensure that what we >> specify can -- and, more importantly, will -- be deployed once >> specified and implemented by vendors. Deployment of >>incrementally >> more secure routing infrastructure in the Internet is the final >> measure of success. > >What's the actual Goal here and how do we measure and >manage to deliver on that goal? How about this text: "Measurably, we would like to see an increase in the number of surveyed respondents who report deploying the improved security mechanisms across their routers, both in any usage within the network, as well as the total number of routers enabled with the updated authentication mechanisms." >>Lebovitz & Expires September 11, 2009 >>[Page 7] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> Interviews with operators show several points about routing >> security. First, only about 25% of operators have deployed >> security in their routing protocols [REF???, Danny, you got >>one?]. > >It's slightly better than that, but not much, depending on >whether or not what you call security is strictly transport >connection protection, or something more. If you're referring >to IRR and prefix filtering functions, it's much worse. Both >vary considerably inter-domain v. intra-domain. > >[ISR2008] http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf, >which you can download for the raw numbers. Got it. Thx. >> Of those who have deployed, only about [25% ??] of their routers >> are deployed with the authentication enabled. Most report >> deploying with one single manual key throughout the entire >> network. > >Most? All that use standard TCP MD5 Signature Option stuff. Well, for the one person that I didn't actually speak to who may have used a few different keys, I didn't want to be too extreme. But we agree, it's abismal. ;-) >One or two still reported IPSEC for transport connection >protection, as illustrated. added that fact. >> These same operators report that the one single key has >> not been changed since it was originally installed, sometimes >>five >> or more years ago. When asked why, particularly for the case of >> BGP using TCP MD5, the following reasons are often given: >> >> A. Changing the keys brings down the links/adjacencies, >> undermining Service Level Agreements (SLAs). > >Might be useful to say "triggers TCP session reset" v. >"brings down links". done. >> B. For external peers, difficulty of coordination with the >>other >> organization. They often don't know who the contact is at >>the >> other organization, so they don't know where to start, and >> doing so takes a lot of time in research. > >Nah, that's not the issue. They have the peering coordinators >contact information, it's just that the coordination function >is serialized and on a per peer/AS basis, and very cumbersome >and tedious to execute in practice. ok. I clarified that, and softened the "finding the contact" issue, which I did hear from several of the people that I interviewed. >> C. Keys must be changed at precisely the same time in order to >> limit connectivity outage duration. This is incredibly >> difficult to do, operationally, especially between different >> organizations. > >Or within some very small window (e.g., 60 seconds), which >I believe at least the two primary vendors support. added. >> D. Relatively low priority compared to other operatoinal >>issues. > >Yes! > >> E. Lack of staff to implement the changes device by device. >> F. One operator reported that the same key is used for all >> customer premise equipment. The same operator reported that >> if the customer mandated, a unique key could be created, >> although the last time this occurred it created such an >> operational headache that the administrators now usually >>tell >> customers that the option doesn't even exist, to avoid the >> difficulties. These customer-uniqe keys are never changed, >> unless the customer demands so. > >So you've got three areas of concern: peers and interconnection >with other ISPs, Internal BGP and other routing sessions, and >customer and CPE devices. All three have very different properties. added. >> The main threat at play here is that a terminated employee from >> such an operator who had access to the one (or few) keys used >>for >> authentication in these environments could easily wage an attack >> -- or offer the keys to others who would wage the attack -- and >> bring down many of the adjacencies, causing destabilization to >>the >> routing system. >> Whatever mechanisms we specify need to be easier than the >>current >> methods to deploy, and should provide obvious operational >> efficiency gains along with significantly better security and >> threat protection. This combination of value may be enough to >> drive much broader adoption. > >Sure.. > >> >>Lebovitz & Expires September 11, 2009 >>[Page 8] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> 5. Address the threats enumerated above in the "Threats" section >> (Section 2) for each routing protocol, along a roadmap. Not all >> threats may be able to be addressed in the first specification >> update for any one protocol. Roadmaps will be defined so that >> both the security area and the routing area agree on how the >> threats will be addressed completely over time. > >In practice, it will be interesting to see how we gauge >whether the IETF "Security Area" and "Routing Area" agree. >I hope the ADs can help here with best determining how to >accomplish such a goal. I think we are well on the way. The KARP BoF seems to be coming along quite well, with good cooperation between routing and Sec. This has a lot to do with the personalities currently seated in the roles. I'm hopeful for the future as well. >> 6. Reuse common mechanisms across routing protocols whenever >>possible >> - For example, designers should aim to re-use the key management >> protocol that will be defined for BGP's TCP-AO key establishment >> for as many other routing protocols as possible. This is but >>one >> example. > >I think the is the crux of the KMART work, and that framework >we define needs to be employed and common to all the relevant >protocols here. added. >> 7. Bridge any gaps between routing and security engineers by >> recording agreements on work items, roadmaps, and guidance from >> the Area leads and Internet Architecture Board (IAB, >>www.iab.org). > >s/engineers/areas/ done. >Also, I'm not sure conveying that an IAB pivot function will >service and identify all gaps, so we should exercise caution >here. Don't disagree, but also clear that IAB can help. Suggested new text? >> 8. Create a re-usable architecture and guidelines for various IETF >> working teams who will address these security improvements for >> various protocols > >I like this, and see it's concise overlap with item 6 above. >Should they not be one item? Yeah, I think so. Done. >>1.5. Non-Goals >> The following two goals are considered out-of-scope for this >>effort: >> o Privacy of the packets on the wire, at this point in time. Once >> this roadmap is realized, we may revisit work on privacy. >> o Message content security. This work is being deal with in other >> areas, like SIDR. > >s/deal/dealt/ s/deal/addressed >>1.6. Audience >> The audience for this roadmap includes: >> o Routing Area working group chairs and members - These people >>are > >s/members/participants/ done. >> charged with updates to the routing protocol specifications. >> Any and all cryptographic authentication work on these >> specifications will occur in Routing Area working groups. > >But if there's a common model to be employed across multiple >routing protocols, what "Routing Area working groups" and not >THE "routing area WG"? Not sure. I think in order to update OSPF we need the OSPF WG to update their specs, no? >> o Security Area reviewers of routing area documents - These >>people >> are delegated by the Security Area Directors to perform >>reviews >> on routing protocol specifications as they pass through >>working >> group last call or IESG review. They will pay particular >> attention to the use of cryptographic authentication and >> corresponding security mechanisms for the routing protocols. >> They will ensure that incremental security improvements are >> >>Lebovitz & Expires September 11, 2009 >>[Page 9] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> being made, in line with this roadmap. >> o Security Area engineers - These people partner with routing >>area >> authors/designers on the security mechanisms in routing >>protocol >> specifications. Some of these security area engineers will be >> assigned by the Security Area Directors, while others will be >> interested parties. > >s/parties./parties in the relevant working groups./ done. >> o Operators - The operators are a key audience for this work, as >> the work is considered to have succeeded if the operators >>deploy >> the technology, presumably due to a perception of >>significantly >> improved security value coupled with relative similarity to >> deployment complexity and cost. Conversely, the work will be >> considered a failure if the operators do not care to deploy >>it, >> either due to lack of value or perceived (or real) over- >> complexity of operations. > >And as such, the GROW and OPSEC WGs should be kept squarely >in the loop as well. ack. Added the text. >>2. Threats >> In RFC2828[RFC2828], a threat is defined as a potential for >>violation >> of security, which exists when there is a circumstance, capability, >> action, or event that could breach security and cause harm. This >> section defines the threats that are in scope for this roadmap, and >> those that are explicitly out of scope. This document leverages >>the >> "Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] , >> capitalizes terms from that document, and offers a terse definition >> of those terms. (More thorough description of routing protocol >> threats sources, motivations, consequences and actions can be found >> in RFC 4593 [RFC4593] itself). The threat listings below expand >>upon >> these threat definitions. >>2.1. Threats In Scope >> The threats that will be addressed in this roadmap are those from >> OUTSIDERS, attackers that may reside anywhere in the Internet, have >> the ability to send IP traffic to the router, may be able to >>observe >> the router's replies, and may even control the path for a >>legitimate >> peer's traffic. These are not legitimate participants in the >>routing >> protocol. Message authentication and integrity protection >> specifically aims to identify messages originating from OUTSIDERS. >> The concept of OUTSIDERS can be further refined to include >>attackers >> who are terminated employees, and those sitting on-path. >> >> >> >>Lebovitz & Expires September 11, 2009 [Page >>10] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> o On-Path - attackers with control of a network resource or a tap >> along the path of packets between two routers. An on-path >> outsider can attempt a man-in-the-middle attack, in addition to >> several other attack actions. > >s/actions/classes/ done. >> A man-in-the-middle (MitM) attack >> occurs when an attacker who has access to packets flowing >>between >> two peers tampers with those packets in such a way that both >>peers >> think they are talking to each other directly, when in fact they >> are actually talking to the attacker only. Protocols conforming >> to this roadmap will use cryptographic mechanisms to prevent a >> man-in-the-middle attacker from situating himself undetected. >> o Terminated Employees - in this context, those who had access >> router configuration that included keys or keying material like >> pre-shared keys used in securing the routing protocol. Using >>this >> material, the attacker could attempt to impersonate a legitimate >> router. > >I don't understand the vector you're conveying here? What >does "impersonate" mean in this context? added text to clarify it, as follows: "... the attacker could send properly MAC'd spoofed packets appearing to come from router A to a router B, and thus impersonate a legitimate peer. The attacker could then send false traffic that changes the network from its operator's design." >>The goal of addressing this source specifically is to >> call out the case where new keys or keying material becomes >> necessary very quickly, with little operational expense, upon >>the >> termination of such an employee. This grouping could also refer >> to any attacker who somehow managed to gain access to keying >> material, and said access had been detected by the operators >>such >> that the operators have an opportunity to move to new keys in >> order to prevent attack. > >s/attack/[an|the] attack/ done. >> These ATTACK ACTIONS are in scope for this roadmap: >> o SPOOFING - when an illegitimate device assumes the identity of a > >What's an "illegitimate device"? A "legitimate one"? A device born out of wedlock, duh!! JK. Will change to "an unauthorized device" >> legitimate one. Spoofing can be used, for example, to inject >> unrealistic routing information that causes the disruption of > >s/unrealistic/malicious/ done. >> network services. Spoofing can also be used to cause a neighbor >> relationship to form that subsequently denies the formation of >>the >> relationship with the legitimate router. > >Can you explain this vector to me? Can a router configured to form an adjacency with routerA actually for two adjacencies with two router A's, simultanously? If an adjacency is formed with a spoofed/impersonated routerA, will a second adjacency be able to form with the real router A? >> o FALSIFICATION - an action whereby an attacker sends false >>routing >> information. To falsify the routing information, an attacker >>has >> to be either the originator or a forwarder of the routing >> information. Falsification may occur by an ORIGINATOR, or a >> FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or >> MISTATEMENT of network resource reachability. > >What's the difference between "MISCLAIMING" and "MISTATEMENT"? >Also, is the latter spelled as you intended? Honestly, I don't recall. And I'm 10k meters in the air, w/o Internet connection, as I work through these edits. From the intro paragraph to Sect 2: This document leverages the "Generic Threats to Routing Protocols" model, RFC 4593 , capitalizes terms from that document, and offers a terse definition of those terms. (More thorough description of routing protocol threats sources, motivations, consequences and actions can be found in RFC 4593 itself). >> We must be careful >> to remember that in this work we are only targeting >>falsification >> from outsiders as may occur from tampering with packets in >>flight. >> Falsification from BYZANTINES (see the Threats Out of Scope >> section (Section 2.2) below) are not addressed by this roadmap, >> but by other work in the IETF. > >REF in order here to this "other work"? Good point. Preventing a router from becoming a BYZANTINE is the work of OPSEC, but I don't think I'll go into that in this paragraph. s/this roadmap, but by other work in the IETF/the KARP effort. >>Lebovitz & Expires September 11, 2009 [Page >>11] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> o INTERFERENCE - when an attacker inhibits the exchanges by >> legitimate routers. The types of interference addressed by this >> work include: >> * ADDING NOISE >> * REPLAYING OUT-DATED PACKETS >> * INSERTING MESSAGES >> * CORRUPTING MESSAGES >> * BREAKING SYNCHRONIZATION >> * Changing message content >> o DoS attacks on transport sub-systems - This includes any other >>DoS >> attacks specifically based on the above attack types. This is >> when an attacker sends packets aimed at halting or preventing >>the >> underlying protocol over which the routing protocol runs, for >> example halting a BGP session by sending a TCP FIN packet. >> Another example is sending packets which confuse or overwhelm a >> security mechanism itself, for example initiating an >>overwhelming >> load of keying protocol initiations from bogus sources. > >This example, can you explain that in the context of routing >protocols today? It would be the case for something like MSEC today, and for any KMP that we put into place. >> All other >> possible DoS attacks are out of scope (see next section). >>2.2. Threats Out of Scope >> Threats from BYZANTINE sources -- faulty, misconfigured, or >>subverted >> routers, i.e., legitimate participants in the routing protocol -- >>are >> out of scope for this roadmap. Any of the attacks described in the >> above section (Section 2.1) that may be levied by a BYZANTINE >>source >> are therefore also out of scope. >> In addition, these other attack actions are out of scope for this >> work: >> o SNIFFING - passive observation of route message contents in >>flight >> o FALSIFICATION by BYZANTINE sources - unauthorized message >>content >> by a legitimate source. >> o INTERFERENCE due to: >> * NOT FORWARDING PACKETS - cannot be prevented with >>cryptographic >> authentication >> * DELAYING MESSAGES - cannot be prevented with cryptographic >> authentication >> * DENIAL OF RECEIPT - cannot be prevented with cryptographic >> authentication >> * UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR >> working group >> grouphttp://www.ietf.org/html.charters/sidr-charter.html). > >s/grouphttp/group http/ done >> * Any other type of DoS attack. For example, a flood of >>traffic >> that fills the link ahead of the router, so that the router >>is >> rendered unusable and unreachable by valid packets is NOT an >> >>Lebovitz & Expires September 11, 2009 [Page >>12] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> attack that this work will address. Many other such examples >> could be contrived. > >It may be worth citing DS or related QoS functions to enable >better response to these sorts of threats .. or not. possibly DSCP could help, but then again the spoof-ing attacker sending junk to fill the pipe could just as easily set DSCP markings. So it's probably not worth going into the whole discussion at this spot in the paper. >>3. Categorizing Routing Protocols >> For the purpose of this security roadmap definition, we will >> categorize the routing protocols into groups and have design teams >> focus on the specification work within those groupings. It is >> believed that the groupings will have like requirements for their >> authentication mechanisms, and that reuse of authentication >> mechanisms will be greatest within these grouping. The work items >> placed on the roadmap will be defined and assigned based on these >> categorizations. It is also hoped that, down the road in the >>Phase 2 >> work, we can create one KMP per category (if not for several >> categories) so that the work can be easily leveraged by the various >> RP teams. KMPs are useful for allowing simple, automated updates >>of >> the traffic keys used in a base protocol. KMPs replace the need >>for >> humans, or OSS routines, to periodically replace keys on running >> systems. It also removes the need for a chain of manual keys to be >> chosen or configured. When configured properly, a KMP will enforce >> the key freshness policy of two peers by keeping track of the key >> lifetime and negotiating a new key at the defined interval. > >Sure, but the inter-domain aspects make this rosy goal considerably >more challenging. I don't see it. Could you clarify? Today the two domains need to exchange manual keys. In the case where KMP is used, they simply exchange a PSK, or SHA1 fingerprints of their self-signed certs (or whatever) and from then on the KMP takes care of traffic key lifetimes, renewals, etc. Did you mean something else? >>3.1. Category: Messaging Transaction Type >> The first categorization defines four types of messaging >>transactions >> used on the wire by the base routing protocol, the Base RP. They >> are: >> >> One-to-One One peer router directly and intentionally >>delivers a >> route update specifically to one other peer router. >> Examples are BGP and LDP. [question to reviewers: >> Should we list all protocols into these categories >> right here, or just give a few examples?] > >IS-IS and OSPF have P-P modes, both on traditional PtP >link layers, and multi-access layers. I'm not sure this >captures the distinction succinctly enough. Good point. I'll site them as examples, saying: "Point-to-point modes of both IS-IS and OSPF, when sent over both traditional point-to-point links and when using multi-access layers, may both also fall into this category. >> One-to-Many A router peers with multiple other routers on a >>single >> network segment -- i.e. on link local -- such that >>it >> creates and sends one route update message which is >> intended for consumption by multiple peers. >>Examples >> would be OSPF and IS-IS. > >See above comment. ack. >> Client-Server A client-server routing protocol is one where one >> router initiates a request for route information >>from >> another router, who then formulates a response to >>that >> request, and replies with the requested data. >> Examples are a BGP Route Reflector and [???? Are >> >>Lebovitz & Expires September 11, 2009 [Page >>13] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> there other examples? Is this the right example?]. > >BGP Route Reflection is _exactly the same as BGP without >route reflection from a transport connection and message >process perspective. The only differences that exist occur >at the protocol application layer. So, you think we (a) should not have "Client-Server" category, (b) should have "Client-Server" category but use another example other than BGP, (c) something else? Pls provide text. >> Multicast Multicast protocols have unique security properties >> because of the fact that they are inherently group- >> based protocols and thus have group keying >> requirements at the routing level where link-local >> routing messages are multicasted. Also, at least in >> the case of PIM-SM, some messages are are sent >>unicast >> to a given peer(s), as is the case with router- close- >> to-sender and the "Rendezvous Point". Some work for >> application layer message security has been done in >> the Multicast Security working group (MSEC, >> http://www.ietf.org/html.charters/msec-charter.html) >> and may be helpful to review, but is not directly >> applicable. >> [author's note: I think the above definitions need clean up. >>Routing >> area folks, especially ADs, PLEASE suggest new text.] > >Let's chat about this in SFO if you'd like, I agree. Let's make some time to review these in Hiroshima. (Dang, it's taken a long time to processes this review.) I'll send you a separate email. >>3.2. Category: Peer vs. Group Keying >> The second axis of categorization groups protocols by the keying >> mechanism that will be necessary for distributing session keys to >>the >> actual routing protocol transports. They are: >> >> Peer keying One router sends the keying messages directly and >>only >> to one other router, such that a one-to-one, unique >> keying security association (SA) is established >> between the two routers >> Group Keying One router creates and distributes a single keying >> message to multiple peers. In this case an group SA >> will be established and used between multiple peers >> simultaneously. Group keying exists for protocols >> like OSPF [RFC2328] , and also for multicast >>protocols >> like PIM-SM [RFC4601]. > >How about the case where multiple sessions exist between >inter-domain peers and the same keys are used on every >session during a given instant? can you give me an example of when this happens? >Also, customers, where it >may or may not be the same for managed and unmanaged CPE >devices? Sorry, not following you here. Could you try clarifying? >>3.3. Security Characterization Vectors >> A few more considerations must be made about the protocol and its >>use >> when initially categorizing the protocol and scoping the >> authentication work. >> >> >> >>Lebovitz & Expires September 11, 2009 [Page >>14] >> >>Internet-Draft KMART Roadmap March >>2009 >> >>3.3.1. Internal vs. External Operation >> The designers must consider whether the protocol is an internal >> routing protocol or an external one, i.e. Does it primarily run >> between peers within a single domain of control or between two >> different domains of control? Some protocols may be used in both >> cases, internally and externally, and as such various modes of >> authentication operation may be required for the same protocol. >> While it is preferred that all routing exchanges run with the >>utmost >> security mechanisms enabled in all deployments, the exhortation is >> greater for those protocols running at a peering point between two >> domains of control, and greatest for those on public exchange point >> links, because the volume of attackers are greater from the >>outside. > >You might want to use more technical language here to be >clear. E.g., inter-domain PtP links versus shared access >interconnection link layers, or something to that effect. done >> Note however that the consequences of internal attacks maybe no >>less >> severe -- in fact they may be quite a bit more sever > >s/sever/severe/ - unless you indeed meant sever :-) done >>-- than an >> external attack. An example of this internal versus external >> consideration is BGP which has both EBGP and IBGP modes. Another >> example is a multicast protocol where the neighbors are sometimes >> within a domain of control and sometimes external, like at an >> exchange link. > >Are you referring to a protocol such as PIM here, or something >more akin to MSDP? I guess it could be either, no? Think I should say, "examples would be both PIM and MSDP."? >> It would be more acceptable to give up some security >> to get some convenience by using a group key on large broadcast >> networks > >I think you're mixing layers here and it's confusing. The >link layer types are orthogonal of the routing adjacencies. >E.g., "It would be more acceptable to give up some security >to gain some efficiencies by using a group key within internal >BGP speakers under a single administrative control...". I >don't think the example of "exchange links" make sense in this >context, as there are many bi-lateral agreements for inter- >domain interconnection and each will most certainly employ a >unique set of keys per peer, or at least per peer AS. I'm trying to get at the point that, when on an external multi-access link layer -- at say a NAP -- and exchanging PIM, parties may want to use peer-wise unique keys, even though it's less efficient. However, on an internal multi-access link layer where PIM is exchanged, they would be well within reason to use a single group key for all peers on the link. It's this distinction between security vs convenience that I'm trying to draw out. I tried to clear the text up. >>within your domain, whereas operators may favor security >> over convenience and use unique keying on peering links. In this >> case again, designers must consider both modes of operation and >> ensure the authentication mechanisms fit both. >> Operators are encouraged to run cryptographic authentication on all >> their adjacencies, but to work from the outside in, i.e. The EBGP >> links are a higher priority than the IBGP links because they are >> externally facing. > >s/./and as a result, more difficult to secure from external >attacks./ good point. How about: s/./, and, as a result, more likely to be targeted in an attack. Is that pretty much what you meant? >>3.3.2. Unique versus Shared Keys >> This section discusses security considerations of when it is > >s/of when/regarding when/ done. >> appropriate to use the same authentication key inputs for multiple >> peers and when it is not. This is largely a debate of convenience >> versus security. It is often the case that the best secured >> mechanism is also the least convenient mechanism. For example, an >> air gap between a host and the network absolutely prevents remote >> attacks on the host, but having to copy and carry files using the >> "sneaker net" is quite inconvenient and unscalable. > >Indeed! Conficker USB stick-enabled attacks appear to >be much more effective today that the intial Conficker >vectors that were enabled by the wormable MS08-067 :-) >File shares are the other primary propagation vector >today. > >> Operators have erred on the side of convenience when it comes to >> securing routing protocols with cryptographic authentication. Many >> do not use it at all. Some use it only on external links, but >>not on >> internal links. > >and some the inverse! > >> Those that do use it often use the same key for all >> peers across their entire network. It is common to see the same >>key >> in use for years, and that being the same key that was entered when >> >>Lebovitz & Expires September 11, 2009 [Page >>15] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> authentication was originally configured. > >s/configured/configured or routing gear deployed/ done. >> The goal for designers is to create authentication mechanisms that >> are easy for the operators to deploy, and still use unique keys. > >Unique keys where, per session? and between peers. I clarified the text. >> Operators have the impression that they NEED shared keys, when in >> fact they do not. What they need is the relative convenience they >> experience from deploying cryptographic authentication with shared >> keys, compared to the inconvenience they would experience if they >> deployed the same authentication mechanism using unique keys per >> pair. An example is BGP Route Reflectors. Here operators often >>use >> the same authentication key between each client and the route >> reflector. The roadmaps defined from this guidance document will >> allow for unique keys to be used between each client and the peer, > >Don't use of confuse client/peer terminology in this context, it's >no different mechanically than non-RR BGP. agreed. >> without sacrificing much convenience. Designers should strive to >> deliver unique keying mechanisms with similar ease-of-deployment >> properties as today's shared keys. >> Operators must understand the consequences of using shared keys >> across many peers. Unique keys are more secure than shared keys >> because the reduce both the attack target size and the attack >> consequence size. > >Perhaps the former, not necessarily the latter, depending on >the attack vector. ok. not sure there is new text needed? >>In this context, the attack target size represents >> the number of unique routing exchanges across a network that an >> attacker may be able to observe in order to gain security >>association >> credentials, i.e. Crack the keys. If a shared key is used across >> the entire internal domain of control, then the attack target >>size is >> very large. The larger the attack target, the easier it is for the >> attacker to gain access to analysis data, and greater the volume of >> analysis data he can access, both of which make his job easier. > >This is a refutable argument. One could submit that it's >the same cost for an attacker to gain access to one device >and data analysis set as it is to gain access to the whole. >I think the key issue here is that a common shared key >makes the attack vulnerability surface more penetrable than >unique keys. Yes. AND, cryptogrpahically, the more protected data an attacker gets to analyze, the better for him. if he has access to the transactions of 1000 exchanges vs 1, then he will gain more data more quickly. That's the difference between the two points. I like your last sentence, and have edited the paragraph to use it. >> In >> this context, the attack consequence size represents the amount of >> routing adjacencies that can be negatively affected once a breach >>has >> occurred, i.e. Once the keys have been acquired by the attacker. >> Again, if a shared key is used across the internal domain, then the >> consequence size is the whole network. Ideally, unique key pairs >> would be used for each adjacency. > >Given that most of these are routing 'link' local, this is >entirely dependent on the attack vector. agreed. >> In some cases designers may need to use shared keys in order to >>solve >> the given problem space. For example, a multicast packet is sent >> once but then observed and consumed by several routing >>neighbors. If >> unique keys were used per neighbor, the benefit of multicast >>would be >> erased because the casting peer would have to create a different >> announcement packet/stream for each listening peer. Though this >>may >> be desired and acceptable in some small amount of use cases, it is >> not the norm. Shared group keys are an acceptable solution here, >>and >> much work has been done already in this area (see MSEC working >> group). >> >> >> >>Lebovitz & Expires September 11, 2009 [Page >>16] >> >>Internet-Draft KMART Roadmap March >>2009 >> >>3.3.3. Out-of-Band vs. In-line Key Management >> This section discusses the security and use case considerations for >> keys placed on devices through out-of-band configurations versus >> through one routing peer-to-peer key management protocol exchanges. >> Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to >> the RP. Instead, we mean that the exchange occurs in-line, over >>IP, >> between the two routing peers directly. In in-line KMP the peers >> themselves handle the key and security association negotiation >> between themselves directly, whereas in an out-of-band system the >> keys are placed onto the device through some other configuration or >> management method or interface. >> An example of an out-of-band mechanism could be an administrator >>who >> makes a remote management connection (e.g. using SSH) to a router >>and >> manually enters the keying information -- like the algorithm, the >> key(s), the lifetimes, etc. Another example could be an OSS system >> which inputs the same information via a script over an SSH >> connection, or by pushing configuration through some other >>management >> connection, standard (Netconf-based) or proprietary. >> The drawbacks of an out-of-band mechanism include: lack of scale- >> ability, complexity and speed of changing if breech is suspected. > >s/breech/breach/ done. >> For example, if an employee who had access to keys was was >> terminated, or if a machine holding those keys was belived >> compromised, then the system would be considered insecure and >> vulnerable until new keys were defined by a human. Those keys then >> need to be placed into the OSS system, manually, and the OSS system >> then needs to push the change -- often during a very limited change >> window -- into the relevant devices. If there are multiple >> organizations involved in these connections, this process is >>greatly >> complicated. >> The benefits of out-of-band mechanism is that once the new keys/ >> parameters are set in OSS system they can be pushed automatically >>to >> all devices within the OSS's domain of control. Operators have >> mechanisms in place for this already. In small environments with >>few >> routers, a manual system is not difficult to employ. >> We further define an in-line key exchange as using cryptographicly >> protected identity verification, session key negotiation, and >> security association parameter negotiation between the two routing >> peers. The KMP between the two peers may also include the >> negotiation of parameters, like algorithms, cryptographic inputs >> (e.g. initialization vectors), key life-times, etc. >> The benefits an in-line KMP are several. An in-line KMP results in >> key(s) that are privately generated, and not recorded permanently >> >>Lebovitz & Expires September 11, 2009 [Page >>17] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> anywhere. Since the traffic keys used in a particular connection >>are >> not a fixed part of a device configuration no steal-able data >>exists >> anywhere else in the operator's systems which can be stolen, e.g. >>in >> the case of a terminated or turned employee. If a server or other >> data store is stolen or compromised, the thieves gain no access to >> current traffic keys. They may gain access to key derivation >> material, like a PSK, but not current traffic keys in use. In this >> example, these PSKs can be updated into the device configurations >> (either manually or through an OSS) without bouncing or impacting >>the >> existing session at all. In the case of using raw assymetric >>keys or >> certificates, instead of PSKs, the data theft would likely not even >> result in any compromise, as the key pairs would have been >>generated >> on the routers, and never leave those routers. In such a case no >> changes are needed on the routers; the connections will continue to >> be secure, non-compromised. > >s/non-/un. done >> Additoinally, with a KMP regular re-keys > >s/Additoinally/Additionally/ done >> operations occur without any operator involvement or oversight. >>This >> keeps keys fresh. >> The drawbacks to using a KMP are few. First, a KMP requires more >> cryptographic processing for the router at the very beginning of a >> connection. This will add some minor start-up time to connection >> establishment versus a purely manual key approach. Once a >>connection >> with traffic keys have been established via a KMP, the >>performance is >> the same in the KMP and the out-of-band case. KMPs also add >>another >> layer of protocol and configuration complexity which can fail or be >> misconfigured. This was more of an issue when these KMPs were >>first >> deployed, but less so as these implementaitons and operational >> experience with them has matured. >> The desired end goal is in-line KMPs. >> >>4. The Roadmap >>4.1. Work Phases on any Particular Protocol >> The desired endstate for the KMART work contains several items. >> First, the people desiring to deploy securely authenticated and >> integrity validated packets between routing peers have the tools >> specified, implemented and shipping in order to deploy. These >>tools >> should be fairly simple to implement, and not more complex than the >> security mechanisms to which the operators are already accustomed. >> (Examples of security mechanisms to which router operators are >> accustomed include: the use of assymetric keys for authentication >>in >> SSH for router configuration, the use of pre-shared keys (PSKs) in >> TCP MD5 for BGP protection, the use of self-signed certificates for >> HTTPS access to device Web-based user interfaces, the use of >>strongly >> constructed passwords and/or identity tokens for user >>identification >> >>Lebovitz & Expires September 11, 2009 [Page >>18] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> when logging into routers and management systems.) While the tools >> that we intend to specify may not be able to stop a deployment from >> using "foobar" as an input key for every device across their entire >> routing domain, we intend to make a solid, modern security system >> that is not too much more difficult than that. In other words, >> simplicity and deployability are keys to success. The Base RP's >>will >> specify modern cryptographic algorithms and security mechanisms. >> Routing peers will be able to employ unique, pair-wise keys per >> peering instance, with reasonable key lifetimes, and updating those >> keys on a somewhat regular basis will be operationally easy, >>causing >> no service interruption. >> The reach the above described end-state using manual keys may >>only be > >s/The reach the/???/ s/The reach/Achieving/ >> pragmatic in very small deployments. In larger deployments, this >>end >> state will be much more operationally difficult to reach with only >> manual keys. Thus, there will be a need for key lifecycle > >s/lifecycle/life cycle/ done. >> management, in the form of a key management protocol, or KMP. We >> expect that the two forms, manual key usage and KMP usage, will co- >> exist in the real world. For example, a provider's edge router >>at a >> public exchange peering point will want to use a KMP for ensuring >> unique and fresh keys with external peers, while a manual key may >>be >> used between a provider's access edge router and each of the same >> provider's customer premise routers with which it peers. >> In accordance with the desired end state just described, we define >> two main work phases for each Base RP: >> 1. Enhance the Base RP's current authentication mechanism. This >> work involves enhancing a Base RP's current security mechanisms >> in order to achieve a consistent, modern level of security >> functionality within its existing keying framework. It is >> understood and accepted that the existing keying frameworks are >> largely based on manual keys. Since many operators have >>already >> built operational support systems (OSS) around these manual key >> implementations, there is some automation available for an >> operator to leverage in that way, if the underlying mechanisms >> are themselves secure. In this phase, we explicitly exclude >> embedding or creating a KMP. A list of the requirements for >> Phase 1 work are below in the section "Requirements for Phase 1 >> BaseRPs' Security Updates (Section 4.2). >> 2. Develop an automated keying framework. The second phase will >> focus on the development of an automated keying framework to >> faciliate unique pair-wise (or perhaps group-wise, where >> applicable) keys per peering isntance. > >s/isntance/instance/ done >>This involves the use of >> a KMP. A KMP is helpful because [will add a more full >> description here, sorry, ran out of time]. > >Nice :-) filled this out with: "A KMP is helpful because it negotiates unique, pair wise, random keys without administrator involvement. It also negotiates several of the SA parameters required for the secure connection, including key life times. It keeps track of those lifetimes using counters, and negotiates new keys and parameters before they expire, again, without administrator interaction. Additionally, in the event of a breach, changing the KMP key will immediately cause a rekey to occur for the Traffic Key on the connection. >>The framework for any >> one BaseRP will fall under, and be able to leverage, the >>generic >> >>Lebovitz & Expires September 11, 2009 [Page >>19] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> framework described below in section Section 4.3. >>4.2. Requirements for Phase 1 BaseRPs' Security Update >> Here is a proposed list of requirements that SHOULD be addressed by >> Phase 1 (according to "1." above) security updates to Base RPs >>[to be >> reviewed after -01 is released]: >> 1. Clear definitions of which elements of the transmission >>(frame, >> packet, segment, etc.) are protected by the authentication >> mechanism >> 2. Strong algorithms, and defined and accepted by the security >> community, MUST be specified. The option should use >>algorithms >> considered accepted by the security community, which are >> considered appropriately safe. The use of non-standard or >> unpublished algorithms SHOULD BE avoided. >> 3. Algorithm agility for the cryptograhpic algorithms used in the >> authentication MUST be specified, i.e. more than one algorithm >> MUST be specified and it is clear how new algorithms MAY be >> specified and used. > >Why must more than one algorithm be specified? Great question. In case one gets broken suddenly. The security community has learned this the hard way. Research on how to break crypto is always going on. Breaking a cipher isn't a matter of if, but when. But it's highly unlikely that two different algo's will be broken simultaneously. So, if two are supported, and once gets broken, we can use the other until we get a new one in place. Having the ability within the protocols to allow for such an event, called crypto agility, is essential. Forcing two algos provides both a redundancy, and a mechanism for getting to that redundancy. I placed an explanation in the text. >> 4. Secure use of simple PSKs, offering both operational >>convenience >> as well as building something of a fence around stupidity, >>MUST >> be specified. >> 5. Inter-connection replay protection. Packets captured from one >> connection MUST NOT be able to be re-sent and accepted >>during a >> later connection. >> 6. Intra-connection replay protection. Packets captured during a >> connection MUST NOT be able to be re-sent and accepted during >> that same connection, to deal with long-lived connections. >> 7. A change of security parameters REQUIRES, and even forces, a >> change of session traffic keys >> 8. Intra-connection re-keying which occurs without a break or >> interruption to the current peering session, and, if possible, >> without data loss, MUST be specified. >> 9. Efficient re-keying SHOULD be provided. The specificaion >>SHOULD >> support rekeying during a connection without the need to >>expend >> undue computational resources. In particular, the >>specification >> SHOULD avoid the need to try/compute multiple keys on a given >> packet. >> 10. Prevent DoS attacks as those described as in-scope in the >> threats section Section 2.1above > >s/1above/1 above/ done. >> 11. Default mechanisms and algorithms specified and defined as >> REQUIRED for all implementations >> 12. Manual keying MUST be supported. >> 13. Architecture of the specification MUST consider and allows for >> future use of a KMP. >> >> >>Lebovitz & Expires September 11, 2009 [Page >>20] >> >>Internet-Draft KMART Roadmap March >>2009 >> >>4.3. Common Framework >> Each of the categories of routing protocols above will require >>unique >> designs for authenticating and integrity checking their protocols. >> However, a single underlying framework for delivering automatic >> keying to those solutions will be pursued. Providing such a single >> framework will significantly reduce the complexity of each step of >> the overall roadmap. For example, if each Base RP needed to define >> it's own key management protocol this would balloon the total >>amount >> of different sockets that needed > >s/that needed/that are needed/ done. >>to be opened and processes that >> needed to be simultaneously running on an implementation. It would >> also significantly increase the run-time complexity and memory >> requirements of such systems running multiple Base RPs, causing >> perhaps slower performance of such systems. However, if we can >>land >> on a very small set (perhaps one or two) of automatic key >>management >> protocols, KMPs, that the various Base RP's can use, then we can >> reduce this implementation and run-time complexity. We can also >> decrease the total amount of time implementers need to deliver the >> KMPs for the Base RPs that will provide better threat protection. >> The components for the framework are listed here, and described >> below: >> o BaseRP security mechanism >> o KMP >> o KeyStore >> o BaseRP-to-KMP API >> o BaseRP-to-KeyStore API >> o KMP-to-KeyStore API >> o Common Base RP mechanisms >> o Identifiers >> o Proof of identity >> o Profiles >> The framework is modularized for how keys and security association >> (SA) parameters generally get passed from a KMP to a transport >> protocol. It contains three main blocks and APIs. >> >> >>Lebovitz & Expires September 11, 2009 [Page >>21] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> +------------+ +--------------------+ >> | | | | Check +-----------+ >> | Identifier +-->| +---------->| | >> | | | KMP Function | | Identity | >> +----------- + | |<----------+ Proof | >> | | Approve | | >> +-+--------------+---+ +-----------+ >> | | >> KMP-to-KeyStore | | >> API | | >> \|/ | >> +-------+-------+ | >> | | | KMP-to-BaseRP >> | Session | | API >> | KeyStore | | >> | | | >> +-------+-------+ | >> | | >> | | >> KeyStore-to- | | >> BaseRP API | | >> | \|/ >> +--------------------------+-------------+ >> | | | >> | \|/ Common BaseRP | >> | +-------+-------+ Authentication | >> | | | Mechanisms | >> +---| Transport |-----+--------------+ >> | | Key(s) | | >> | | | | >> | +---------------+ Specific BaseRP | >> | Authentication | >> | Security | >> | Mechanism | >> | | >> +----------------------------------------+ >> >> Figure 1: Automatic Key Management Framework >> Each element of the framework is described here: >> >> o Base RP - Base RP security mechanism - In each case, the Base >>RP >> will contain a mechanism for using session keys in their >> security option. > >But what if that option is a function of the transport >substrate employed by the RP? E.g., TCP MD5 Signature >Option for MSDP, LDP, BGP. clarification placed in the text. >>Lebovitz & Expires September 11, 2009 [Page >>22] >> >>Internet-Draft KMART Roadmap March >>2009 > >> >> o KeyStore - Each implementation will also contain a protocol >> independent mechanism for storing keys, called KeyStore. >>The >> key_store will have multiple different logical containers, >> one container for each session key that any given Base RP >> will need. >> o RP-KeyStore API - There will be an API for Base RP to retrieve >> the keys from the KeyStore. This will enable >>implementers to >> reuse the same API calls for all their Base RPs. The API >> will necessarily include facility to retrieve other >> parameters required for the construction of the BaseRP's >> packets, like key IDs or key lifetimes, etc. > >Are these other parameters contained in the KeyStore as well, >and if so, it should be indicated as such above. I think the >word "parameters" should be in that definition. added "here may also be associated parameters as required by the SA for any given Routing Protocol." to the KeyStore definition. >> o KMP - There will be an automated key management protocol, KMP. >> This KMP will run between the peers. The KMP serves as a >> protected channel between the peers, through which they can >> negotiate and pass important data required to exchange >>proof >> of key identifiers, derive session keys, determine re- keying, >> synchronize their keying state, signal various keying >>events, >> notify with error messages, etc. As an analogy, in the >>IPsec >> protocol [RFC 4301, 4303 and 4306] IKEv2 is the KMP that >>runs >> between the two peers, while AH and ESP are two different >> base protocols that take session keys from IKEv2 and use >>them >> in their transmissions. In the analogy, the Base RP, say >>BGP >> and LDP, are analogous to ESP and AH, while the KMP is >> analogous to IKEv2 itself. > >I don't like this decoupling as it should be employing the >facilities of the RP, if possible. However, the Routing Protocols don't have KMP's, and they weren't designed to be KMPs. KMPs are VERY tricky things to get right, security wise. Look at IKE. We've been working for 15 yrs to get that right, and IKEv2 is very good, strong and secure, having undergone tremendous peer review, implementation and use. We want to leverage that goodness, not attempt to start over from scratch, one-by-one, in each routing protocol. > New sessions and a much >larger attack surface are a primary reason no one uses this >stuff today for infrastructure protocols. not really. Everyone uses SSH today for managing their infrastructure. It's really no different. In fact, the same ID and Identity proof could be re-used as that used in SSH already. >Also, this seems >to assume solely two peers, versus multi-access networks >and RP mechanisms. There are keying protocols for multi-access situations, and they involve a GDOI model, where a key server exists, each peer uses IKE to get to the key server in 1:1 connections, then the key server delivers a group key. It's kind of like a route reflector for keying. At least that's one model. But the basic priniciple holds true: create a secure channel for keying and session specifics, and run the actual secured connection on its own. >> o RP-KMP API - There will be an API for the Base RP to request a >> session key of the KMP, and be notified when the keys are >> available for it. The API will also contain a mechanism >>for >> the KMP to notify the Base RP that there are new keys >>that it >> must now use, even if it didn't request those keys. The >>API >> will also include a mechanism for the KMP to receive >>requests >> for session keys and other parameters from the routing >> protocol. The KMP will also be aware of the various Base >>RPs >> and each of their unique parameters that need to be >> negotiated and returned. >> o KMP-KeyStore API - There will be an API for the KMP to place >> keys and parameters into the KeyStore after their >>negotiation >> and derivation with the other peer. This will enable the >> implementers to reuse the same calls for multiple KMPs that >> may be needed to address the various categories of RPs as >> described in the section definingcategories (Section 3). > >s/definingcategories/defining categories/ done. >>Lebovitz & Expires September 11, 2009 [Page >>23] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> >> [after writing this all up, I'm not sure we really need the >>key_store >> in the middle. As long as we standardize fully all the calls >>needed >> from any RP to any KMP, then there can be a generic hand-down >> function from the KMP to the RP when the key and parameters are >> ready. Let's sleep on it.] >> [will need state machines and function calls for these APIs, as one >> of the work items. In essence, there is a need for a core team to >> develop the APIs out completely in order for the RP teams to use >> them. Need to get this team going asap.] > >This should be a guiding document, not a solutions document. >Lots of concern here. sorry, didn't quite catch that. Could you say more? Are you against the idea of a design team spinning up to draft these APIs? >> o Identifiers - A KMP is fed by identities. The identities are >> text strings used by the peers to indicate to each other >>that >> each are known to the other, and authorized to establish >> connections. Those identities must be represented in some >> standard string format, e.g. an IP address -- either v4 or >> v6, an FQDN, an RFC 822 email address, a Common Name [RFC >> PKI], etc. Note that even though routers do not normally >> have email addresses, one could use an RFC 822 email >>address >> string as a formatted identifier for a router. They >>would do >> so simply by putting the router's reference number or name- >> code as the "NAME" part of the address, left of the "@" >> symbol. They would then place some locational context in >>the >> "DOMAIN" part of the string, right of the "@" symbol. An >> example would be "rtr0210@sf.ca.us.company.com". This >> document does not suggest this string value at all. > >In the weeds... > >> Instead, >> the concept is used only to clarify that the type of string >> employed does not matter. It also does not matter what >> specific text you chose to place in that string type. It >> only matters that the type of string -- and it's format -- >> must be agreed upon by the two endpoints. > >Is that a provisioning or dynamic function? Something >else that has to be specified manually to make things >dynamic. you have to decide what identity type and value you are using. Right now we do this implicitly; we use the IP address as the identity, and we use the manual key as the proof. All this is saying is that we could use something else, like a SubjAltName from an x.509 certificate, or a CN, and a value appropriately structured for that ID type. >>Further, the >> string can be used as an identifier in this context, even >>if >> the string is not actually provisioned in it's source >>domain. >> For example, the email address "rtr0210@sf.ca.us.company.com " >> may not actually exist as an email address in that domain, >> but that string of characters may still be used as an >> identifier type(s) in the routing protocol security >>context. >> What is important is that the community decide on a small >>but >> flexible set of Identifiers they will all support, and that >> they decide on the exact format of those string. The >>formats >> that will be used must be standardized and must be sensible >> for the routing infrastructure. > >We're way in the weeds here, IMO. Probably. The last sentence is the key. The other stuff above it was just examples. My point is that routing people get freaked out because they think KMP's means we have to use certs and PKI. But it doesn't. You could use whatever id type (or handful of them) we care to specify. For example, in IKE using PSK, we call out these 6: FQDN, RFC822name (email addr), IPaddr_v6, IPaddr_v4, X.509-Subject, X.509.SubjAltName. We could do the same or some subset for KARP. But it doesn't have to be certs. >>Lebovitz & Expires September 11, 2009 [Page >>24] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> o Identity Proof - Once the form of identity is decided, then >> there must be a cryptographic proof of that identity, that >> the peer really is who they assert themselves to be. Proof >> of identity can be arranged between the peers in a few >>ways, >> for example pre-shared keys, raw assymetric keys, or a more >> user-friendly representation of assymetric keys, like a >> certificate. Certificates can be used in a way requiring >>no >> additional supporting systems -- e.g. public keys for each >> peer can be maintained locally for verification upon >>contant. > >s/contant/contact/ done. >> Certificate management can be made more simple and scalable >> with the use minor additional supporting systems, as is the >> case with self-signed certificates and a flat file list of >> "approved thumbprints". Self-signed certificates will have >> somewhat lower security properties than Certificate >>Authority >> signed certificates [RFC Certs]. The use of these >>different >> identity proofs vary in ease of deployment, ease of ongoing >> management, startup effort, ongoing effort and management, >> security strength, and consequences from loss of secrets >>from >> one part of the system to the rest of the system. For >> example, they differ in resistance to a security breach, >>and >> the effort required to remediate the whole system in the >> event of such a breach. The point here is that there are >> options, many of which are quite simple to employ and >>deploy. > >Sure, and this is in the weeds as well, IMO. Need to uplevel a >few... We could, but I've found this exact point to be a place of misunderstanding for many routing folks. Once they hear the above, they say, "oh, ok. I guess it's not so bad as I imagined; we already do that for SSH anyway..." And one more objection is lowered. >> o Profiles - Once the KMP, Identifiers and Proofs mechanisms are >> converged upon, they must be clearly profiled for each Base >> RP, so that implementors and deployers alike understand the >> different pieces of the solution, and can have similar >> configurations and interoperability across multiple >>vendors' >> devices, so as to reduce management difficulty. The >>profiles >> SHOULD also provide guidance on when to use which various >> combinations of options. This will, again, simplify use >>and >> interoperability. >> Common Mechanisms - In as much as they exist, the framework will >> capture mechanisms that can be used commonly not only within a >> particular category of Base RP and Base RP to KMP, but also between >> Base RP categories. Again, the goal here is simplifying the >> implementations and runtime code and resource requirements. >>There is >> also a goal here of favoring well vetted, reviewed, operationally >> proven security mechanisms over newly brewed mechanisms that are >>less >> well tried in the wild. >> >> >> >> >>Lebovitz & Expires September 11, 2009 [Page >>25] >> >>Internet-Draft KMART Roadmap March >>2009 >> >>4.4. Work Items Per Routing Protocol >> Each Base RP will have a team (the [RP]-KMART team) working on >> incrementally improving their Base RP's security, These teams will >> have the following main work items: > >I'm not sure what we're attempting in this section, or >if these teams are design teams or JWTs, or something >else, but I don't think this should be in the draft, although >it SHOULD be specified external to the draft. The IETF >has facilities and mechanics to enable this, we need to >strictly employ those. What are they; what are the best ways to capture this agreement about how to do the work? Yes, agreed, this sort of statement about how the work will get done really is its own draft, or a charter or something. For now, I'm just using this doc as a catch all and recording the agreements to date between the ADs and ourselves. >> PHASE 1: >> Characterize the RP >> Assess the Base RP to see what authentication mechanisms it has >> today. Does it needs significant improvement to its existing >> mechanisms or not? This will include determining if modern, >> strong security algorithms and parameters are present. >> Define Optimal State >> List the requirements for the Base RP's session key usage and >> format to contain to modern, strong security algorithms and >> mechanisms, per the Requirements (Section 4.2)section above. > >s/)section/) section/ done. >>The >> goal here is to determine what is needed for they BaseRP alone >>to >> be used securely with at least manual keys. >> Gap Analysis >> Enumerate the requirements for this protocol to move from its >> current security state, the first bullet, to its optimal state, >> bullet two above. > >"Above" where? just above. Clarified in the text. >> Define, Assign, Design >> Create a deliverables list of the design and specification work, >> with milestones. Define owners. Release a document(s) >> >> PHASE 2: >> KMP Analysis >> Review requirements for KMPs [RFC????]. Identify any nuances >>for >> this particular protocol's needs and its use cases for KMP. >>List >> the requirements that this RP has for being able to be use in >> conjunctions with a KMP. Define the optimal state. >> Gap Analysis >> Enumerate the requirements for this protocol to move from its >> current security state to its optimal state. >> Define, Assign, Design >> >> >> >>Lebovitz & Expires September 11, 2009 [Page >>26] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> Create a deliverabels list of the design and specification work, >> with miletsones. Define owners. Do the design and document >>work >> for a KMP to be able to generate the Base RP's session keys for >> the packets on the wire. These will be the arguments passed in >> the API to the KMP in order to bootstrap the session keys to the >> Base RP. > >Isn't this a WG chartering or WG charter update sort of thing >that should take place, to the point above? There exists clear >framework for this today. Yeah, I think so too. Once the WG gets chartered, this whole doc becomes multiple more focused docs... as stated above a few times. >> There will also be a team formed to work on the base framework >> mechanisms for each of the main categories, i.e. the blocks and >>API's >> represented in figure 1 (Figure 1). >>4.5. Protocols in Categories >> This section groups the Base RPs into like categories, according to >> attributes set forth in Categories Section (Section 3). Each group >> will have a design team tasked with improving the security of the >> Base RP mechanisms and defining the KMP requirements for their >>group, >> then rolling both into a roadmap document upon which they will >> execute. > >Again, we need to avoid mechanics of how the work should be >carried out within the IETF, and focus on the problems and >goals of the framework document here. The other stuff needs >to be captured, but that should happen as a management function >external to this. agreed. >> BGP, LDP and MSDP >> The Base RP's that fall into the category of the one-to-one >> peering messages, and will use peer keying protocols, AND are >>all >> transmitted over TCP include BGP RFC 4271 [RFC4271], LDP >> [RFC3036] and MSDP [RFC3618]. A team will work on one >>mechanism >> to cover these three protocols. Much of the work on the BaseRP >> update for its existing authentication mechanism is already >> occuring in the TCPM Working Group, on the TCP-AO >> [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its >> cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto]. >>The >> exception is the mode where LDP is used directly on the LAN >> [RFC????]. The work for this may go into the Group keying >> category (w/ OSPF) mentioned below. >> OSPF, ISIS, and RIP >> The Base RPs that fall into the category Group keying with one- >> to-many peering messages includes OSPF [RFC2328], ISIS >>[RFC1195] >> and RIP [RFC2453]. Not surprisingly, all these routing >>protocols >> have two other things in common. First, they are run on a >> combination of the OSI datalink layer 2, and the OSI network >> layer 3. > >What? IS-IS over the datalink layer, and RIP and OSPF over >IP. The statement above confuses me. They all have specification for something that happens at layer 2, i.e. they aren't simply Layer 3 and Layer 3 alone. Their operation has specification in layer 2. Can you think of a better way to say this? >>Second, they are all internal gateway protocols, or >> IGPs. The keying mechanisms and use will be much more >> complicated to define for these. > >Depends, not if it's group keying and static :-) > >>Lebovitz & Expires September 11, 2009 [Page >>27] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> BFD >> Because it is less of a routing protocol, per se, and more of a >> peer aliveness detection mechanism, Bidirectional Forwarding >> Detection (BFD) [RFC????] will have its own team. >> RSVP [RFC????], RSVP-TE [RFC????], and PCE >> These three protocols will be handled together. [what more >> characterisation should we give here? Routing AD's, provide >>text >> pls?] > >Heh, I'd drop the first RSVP, I think.. PCE, be interesting >to see where that lands. Any explanation for why? >> PIM-SM and PIM-DM >> Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM >> [RFC3973] will be handled together. PIM-SM multicasts routing >> information (Hello, Join/Prune, Assert) on a link-local basis, >> using a defined multicast address. In addition, it specifies >> unicast communication for exchange of information (Register, >> Register-Stop) between the router closest to a group sender and >> the "rendezvous point" (RP). The RP is typically not "on-link" >> for a particular router. While much work has been done on >> multicast security for application-layer groups, little has >>been >> done to address the problem of managing hundreds or thousands >>of >> small one-to-many groups with link-local scope. This will be >> necessary if we are to have unique keys per speaking router >>in a >> PIM chain. > >Did we decide somewhere that unique keys are a requirement >here? I missed that? I guess you are right. I pushed a certain solution type into the wording. I deleted that sentence. >>Such an authentication mechanism should be considered >> along with the router-to-Rendezvous Point authentication >> mechanism. The most important issue is ensuring that only the >> "legitimate neighbors" s/legitimate/authorized/ >>get the keys for (S,G), so that rogue >> routers cannot participate in the exchanges. Another issue is >> that some of the communication may occur intra-domain, e.g. the >> link-local messages in an enterprise, while others for the same >> (*,G) may occur inter-domain, e.g. the router-to-Rendezvous >>Point >> messges may be from one enterprise's router to another. One >> possible solution proposes a region-wide "master" key server >> (possibly replicated), and one "local" key server per speaking >> router. There is no issue with propagating the messages >>outside >> the link, because link-local messages, by definition, are not >> forwarded. This solution is offered only as an example of how >> work may progress; further discussion should occur in this work >> team. Specification of a link-local protection mechanism for >> PIM-SM occurred in RFC 4601 [RFC4601], and this work is being >> updated in PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal]. >> However, the KMP part is completely unspecified, and will >>require >> work outside the expertise of the PIM working group to >> accomplish, which is why this roadmap is being created. >> >> >> >>Lebovitz & Expires September 11, 2009 [Page >>28] >> >>Internet-Draft KMART Roadmap March >>2009 >> >> These protocols are deemed out-of-scope for this current >>iteration of >> the work roadmap. Once all of the protocols listed above have had >> their work completed, or are clearly within site of completion, >>then >> the community will revisit the need and interest for working on >> these: >> o MANET >> o FORCES >> [need text from routing ADs on why these are out of scope] >>4.6. Priorites >> Resources from both the routing area and the security area will be >> applied to work on these problem spaces as quickly as possible. >> Realizing that such resources are far from unlimited, a rank order >> priority for addressing the work of incrementally securing these >> groups of routing protocols is provided: >> o Priority 1 - BGP / LDP / MSDP >> o Priority 2 - BFD >> o Priority 3 - OSPF / ISIS / RIP >> o Priority 4 - RSVP and RSVP-TE >> By far the most important group is the Priority 1 group as these >>are >> the protocols used on the most public and exposed segments of the >> networks, at the peering points between operators and between >> operators and their customers. BFD, as a detection mechanism >> underlying the Priority 1 protocols is therefore second. > >Again, we need to structure this under IETF mechanics and >ensure that the work and model are aligned, not invent a >new one. >>5. Security Considerations >> This entire document focuses on improving the security of routing >> protocols by improving or implementing cryptographic authentication >> for each routing protocol. Security considerations are largely >> contained within the body text of the document. >> The mechanisms that will be defined under this roadmap aim to >>improve >> the security, better protect against more threats, and provider far >> greater operational efficiencies than the state of things at the >>time >> of this writing. > >These comments are sorta rolling thoughts, please don't >take any of them to harshly and discard at will (mostly :-) Thanks for the great and thorough review, Danny. It's taken me hours to pour through it, respond and make the appropriate changes in the text. I think that time has been well spent. Pls excuse the fact that it has taken me SOOO LONG to get this done. On we go... Gregory. >-danny From gregory.ietf@gmail.com Wed Nov 4 10:27:51 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10FE28C0FF for ; Wed, 4 Nov 2009 10:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPK7QYqCa-ba for ; Wed, 4 Nov 2009 10:27:50 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id B544A28C0DB for ; Wed, 4 Nov 2009 10:27:49 -0800 (PST) Received: by ewy3 with SMTP id 3so3398557ewy.37 for ; Wed, 04 Nov 2009 10:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:mime-version:content-type; bh=9RHsZ10S4hNdoUIFqJ9NumUZYLRiC18/WMDGjnLvrLM=; b=eRE84ZZ9i2keP9V5vh2lycFZ5RJWZSUfGYwY8WXDd0D1PavVZjXrKywrZ1YYMoeznQ WJhl6tKT2dJBUKbOxbuYvo+R+YKw/OeQhWtEKG6Ma0FuwBqwKvhmiZASzga9Vieo/Aed OCZgieIYfmeGw15eNNzz8ZZiqAtFdel2a+sHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:mime-version:content-type; b=B7CBUeMijlOSsWrWKmARgYA2prWtWvYNDyl/fEbWvjDfMpEykG6KqR7MzSgaVGz70n iGkA29XpgutuhVDe2FHFeVyg6kBhc9FHgi0AKTRh7O7kyqk4zvVWiPK//5gKUvzwrynh 45szi3VJ2728pu/FaQdqWbFvY4PnBU3yLDSmI= Received: by 10.216.85.136 with SMTP id u8mr590005wee.79.1257359287056; Wed, 04 Nov 2009 10:28:07 -0800 (PST) Received: from Gregory-T60.gmail.com ([58.187.119.136]) by mx.google.com with ESMTPS id q9sm3811059gve.0.2009.11.04.10.28.02 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 10:28:05 -0800 (PST) Message-ID: <4af1c7b5.09a8100a.220d.ffffe6b8@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Nov 2009 10:27:56 -0800 To: Brian Weis ,karp@ietf.org, "Thomas Hardjono" From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [karp] Fwd: RE: [kmart] Draft Charter for KMART BoF X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:27:51 -0000 Thomas, Thanks for the review. I just re-read this and realized that Brian Weis was not on the "To:", though he may have picked it up via the kmart (now defunct, replaced by KARP) list. Brian is updating the charter going forward, as part of the role of chairing the BoF. I just want to make sure Brian saw it when he did his charter re-write. Can you confirm that, Brian? Comments below... >From: "Thomas Hardjono" >To: "'Gregory M. Lebovitz'" , > , > "'Adrian Farrel'" >References: <4aa1886e.171bf30a.5017.4fb0@mx.google.com> >In-Reply-To: <4aa1886e.171bf30a.5017.4fb0@mx.google.com> >Subject: RE: [kmart] Draft Charter for KMART BoF >Date: Tue, 8 Sep 2009 16:39:20 -0400 > >Hi Gregory, > >Comments in-line below. > > > -----Original Message----- > > From: kmart-bounces@ietf.org [mailto:kmart-bounces@ietf.org] On Behalf > > Of Gregory M. Lebovitz > > Sent: Friday, September 04, 2009 2:09 PM > > To: kmart@ietf.org; Adrian Farrel > > Subject: [kmart] Draft Charter for KMART BoF > > > > Team, > > Below is -00 for the KMART charter. Pls review and send > > debate/comment/edit to list. > > > > At this point I'd like to step out of the editor role for the > > charter. The AD's are looking for BoF chairs, and a charter editor. > > Pls let them know if you are interested. I will continue actively as > > a participant, document editor/author and Liaison to IABs Secure > > Routing work item. > > > > Gregory. > > > > ===== BEGIN KMART-CHARTER-00 ===== > > This working group will focus on securing routing protocols' > > packets-on-the-wire by the use of cryptographic authentication modern > > cryptographic algorithms to provide > >I think KMART is a good idea, though some clarifications are still needed >for the Charter: > >- Packets-on-the-wire: some readers may not be aware of the exact meaning >for this term (e.g. versus a point to point secure-channel, ala SSL/TLS). >Thus, some clarifications may be needed (e.g. use of keyed hash on a per >packet basis). makes sense. >- Intra/Inter domain: does this KMART address only intra-domain (intra-AS) >routing protocols, or also inter-domain protocols. both. In fact, the work has really started with TCP for BGP, with mostly EBGP in mind (but it works the same for IBGP). There seems to be a lot of demand for PIM-SM too, since it is often crossing domain boundaries these days. There is less demand for interior-gateway protocols at present, i.e. OSPF and IS-IS. -- snip -- > > > > Many routing protocols (or groups of protocols) already have some > > method for accomplishing > > cryptographic message authentication. In most cases the > > existing methods are dated, vulnerable to known attack, and/or employ > > cryptographic algorithms that have been deprecated. Internet security > > practices have progressed in the last 10 years when many of the first > > generation routing authentication mechanisms were created. It is time > > to review and update those mechanisms to use modern security practices. > >TH: Calling out some examples may be a good idea in this paragraph to >clarify. >For example, explain that some intra-domain routing protocols (eg. RIP2, >OSPF, etc) >may still be using hash algorithms that are deemed "weak". agreed. Can't recall if that is covered in the most recent charter update or not. Brian? >I would even go so far as adding "Algorithm Agility" as a goal or >requirement of the framework/architectures and solutions coming out of >KMART. I agree. It's in the roadmap document as a very clear requirement, under the requirements section. > > MISSON & OBJECTIVES > > > > Misson: > > Deliver specifications that empower an incrementally secure > > routing infrastructure for the Internet by delivering cryptographic > > authentication and message integrity for packets transmitted between > > routing protocol peers. > >TH: Did you mean "specifications" only, or does it include also a >"framework" document (as is alluded further below). Both. Good catch. The Framework is a key starting point, esp if we want to get to KMPs for these things. -- snip -- > > Work Blocks/Phases: > > 1) Enahance Existing Mechanisms - The first step is to enhance the > > routing protocols' (groups') authentication mechanism, ensuring it > > employs modern cryptographic algorithms and methods for its basic > > operational model. Ideally the updated mechanism will protect against > > as many threats as possible. Many of the protocols' use manual keys > > currently, so the first phase will focus on shoring up the manual key > > mechanisms that exist. > >TH: Perhaps the term "mechanisms" also need some clarification. Does it >mean cryptographic algorithms, 2-party key establishment protocols, >group key establishment protocols etc. etc. It refers to what's needed in a RoutingProtocol in order to provide the basic requirements (see Requirements section of draft-lebovitz-kmart-roadmap). In TCP-AO's case for BGP, this meant adding a KeyID for key/algo agility w/o killing the connection, adding the connection specific info into the hash function for replay protection, and specification of new algos. In step 1 it is NOT 2-party key establishment or group key establishment, that is expilictly part of step 2 (below). First step: clean up the Routing PRotocol for manual key usage. Second Step: add in Key negotiations, and to it in a re-usable way. > > 2) A framework (DOI?) will be defined for common elements and their > > use, such that implementation on systems with many routing protocols > > can easily re-use common structures and functions. The framework will > > account for the future use of a key management protocol (KMP) that > > can be layered onto a protocl's manual key mechanism. > >TH: The term "DOI" could also to be confusing (ever since ISAKMP >was supplanted by IKE). It also narrows down the vocabulary (and thus >available solutions) to IPsec and IKE. Probably right. I meant DOI in the generic sense, not in the IKE specific sense. >Also, the term "Key Management Protocol" when used within the IETF >typically means a 2-party key establishment/agreement protocol >(ala IKE and SSL). That's what I intended. >Within the broader standards world of IEEE1619.3 >and the OASIS KMIP working group, the phrase means a proper lifecycle >for managing keys following that defined by NIST 800-56 and 800-57. I'm not as familiar w/ that work. Could you point us, the WG-to-be, to the documents OASIS that you find germaine? We can take a look at IEEE1619.3 and the NIST specs. Thanks for the pointers. Would you recommend that we bring those in and make RFCs out of them? >I think KMART could make a *huge* contribution to the IT Management >industry (which includes IP network management) by providing >an API (specific to cryptographic keys management) that allow >instrumentation systems to provide a unified management experience >to the IT Admin. Me too. It would be HUGELY HELPFUL. > > 3) Layer in KMP - The second work phase is to define the use of an > > existing KMP (e.g. IKE) for generating keys and security association > > parameters for use any routing protocol (group). It is hoped that a > > general KMP framework -- or a small number of frameworks -- can be > > defined and leveraged for many routing protcols (groups). > >TH: Again, I would serious look at existing protocols (outside the IETF) assuming you mean the IEEE and OASIS references you gave above? >which has already been deployed for managing cryptographic keys. >The problem of lifecycle management of crypto keys at routers is not >much different than that in storage controllers (really). Agreed. Good point. Thx again for the review, GRegory. >cheers, > >/thomas/ > > > > > > > > > > > SCOPE > > > > The scope of this roadmap of work includes: > > > > o Making use of existing routing protocol security protocols, > > where > > they exist, and enhancing or updating them as necessary for > > modern cryptographic best practices and expanded threat protection. > > > > o Specifying authentication mechanisms in routing protocols > > where they do not currently exist. > > > > o Developing a framework that will be able to layer in use of > > KMP in order to ease deployment, lower cost of operation, and allow for > > rapid > > responses to security breaches, and > > > > o Specifying the automated KMP that may be > > combined with the bits-on-the-wire mechanisms. > > > > > > o [List of routing protocols we will work on]. These are the > > priorities at the moment. The WG may re-charter later to take on > > additional protocols. > > > > > > OUT OF SCOPE > > > > o Protection of route message content or payload. > > - Route orignation authorization (ROAs). This is being addressed > > in SIDR WG. > > - Route path validation. > > o Route message privacy. > > o Authentication for anything but routing protcols. > > o [List of routing protocols we will not work on]. The WG may > > re-charter later to address these, once current work items are > > completed. > > > > > > > > SPECIFIC WORK ITEMS > > > > o Grouping the routing protocols with like transports/requirements > > o Prioritize the the work of addressing the groups > > o General requirements document for cryptographic authentication of > > routing protocols. This document will start with a threat model which > > will then drive the requirements. > > o Framework document describing the common elements for modern > > authentication in routing protcols. This will include a framework > > "manual" key modes for routing protocols, but done in a way that > > allows for the future layering-on of an automated key management > > protocol (KMP). > > o Security review of existing groups of routing protocols, resulting > > in a requirements document for each protocol group detailing what is > > needed to modernize (or provide) authentication for that protocol group > > o Specification document for each routing protocol updating how each > > will employ modern authentication. > > o General KMP usage - specification document(s) defining a KMP and > > its use for generating keys and security association parameters for > > any routing protocol (group). > > o Specification document for the use of KMP with each routing protocol. > > > > > > MILESTONES (TBD) > > > > TBD - BoF > > TBD - WG formed > > TBD - separate current roadmap document (a place holder document) > > into General Framework, General Requirements, Priorities/Work-Plan > > documents > > TBD - Requirements document for each protocol group > > TBD - Specification document for each protocol > > > > > > WG LOCATION & OPERATION > > > > By suggestion of the Routing and Security AD's, this work will be > > housed in the Routing Area, but will have an explicit Security Area > > advisor assigned. In addition, members of the security community will > > be recruited to participate in the truly cross-area WG effort. This > > sort of authentication work has proven to be very tedious and > > experience has shown it easily overwhelms a WG's available air time > > for other topics (i.e. this topic can DoS a routing protocol's WG). > > Therefore the AD's suggest that authentication work on the routing > > protos (groups) will be done in one WG just for that purpose, instead > > of in each routing protocol's WG themselves, but with committed > > participation from that (those) routing protocols' working groups' > > members, and with frequent status updates being liaised between this > > WG and the protocols WGs. > > > > > > > > +++++++++++++++++++++++ > > IETF-related email from > > Gregory M. Lebovitz > > Juniper Networks > > g r e go r y d o t i e tf a t g m a i l do t c o m > > > > _______________________________________________ > > kmart mailing list > > kmart@ietf.org > > https://www.ietf.org/mailman/listinfo/kmart +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m From gregory.ietf@gmail.com Wed Nov 4 12:19:25 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6103A63D3 for ; Wed, 4 Nov 2009 12:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMYbcVQ+IqDQ for ; Wed, 4 Nov 2009 12:19:24 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id ED5C53A68E5 for ; Wed, 4 Nov 2009 12:19:21 -0800 (PST) Received: by mail-ew0-f207.google.com with SMTP id 3so3524135ewy.37 for ; Wed, 04 Nov 2009 12:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer :x-priority:date:to:from:subject:mime-version:content-type; bh=RH+yMdBwJNrFOjYDWwabc60dJIwVS0/E1hUv2zbJNaI=; b=Fl/azzVz5KiYqVckh7Q6iyT3Fs332XpQCC/XkkqU0mv5siQCulsaA19GdSt7SchBur KldthZm9jZUshhfStp5+QELWyj1fHMcvVUe3E5SBMhnO1xeTmxAJM2WdXZijgT5F3g4D hPLDSODToPks2al4ZDlBy0iaBzqCuz4zCNDzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:x-priority:date:to:from:subject:mime-version :content-type; b=E3QJ6aAMyhRvCNXxqT8nBbKTyTVKEUr3PW3tMKVbCQ4jMpNQkQvU6hMAAryk6rAdty eZJsbm2M69E5MG0T6gB/+lHd+H+1KyVGDWPSWfJEnmQuvN/MXK4iztH9Hu4jsYR1ahs9 GfYsNXrqM0sTFQLXDp8Ir30E8AsEWVV6tVo5s= Received: by 10.216.93.15 with SMTP id k15mr714128wef.103.1257365983508; Wed, 04 Nov 2009 12:19:43 -0800 (PST) Received: from Gregory-T60.gmail.com ([58.187.119.136]) by mx.google.com with ESMTPS id j8sm249073gvb.19.2009.11.04.12.18.43 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 12:19:41 -0800 (PST) Message-ID: <4af1e1dd.0856100a.2f8b.58b3@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 X-Priority: 1 (Highest) Date: Wed, 04 Nov 2009 12:13:09 -0800 To: karp@ietf.org,Ross Callon , "Joel M. Halpern" ,Brian Weis , tim Polk From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_448520890==_" Subject: [karp] draft-lebovitz-kmart-roadmap-03.txt attached X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:19:25 -0000 --=====================_448520890==_ Content-Type: multipart/alternative; boundary="=====================_448520953==.ALT" --=====================_448520953==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hey all, I just finished an update to the document. It is attached, and pasted below. The Chairs will put the link to the email archive page of this message in the BoF page, and BoF Agenda page too, so that people can find the document easily. We'll get it posted to I-D repository as soon as the window opens on Monday. Editor's Note on "KMART" vs "KARP": The first few versions of this document were called "draft-lebovitz-kmart-roadmap-xx". Upon the creation of the BoF for IETF76, the IESG requested the name of the effort change so as to avoid any potential trademark issues. The new name of the effort is KARP. Version -03 will go out titled with the old KMART "draft-lebovitz-kmart-roadmap-03", so as to avoid confusion, but within the document text you'll find s/kmart/karp/. As soon as the I-D editor queue opens again (Monday, 09 Nov) the document will be submitted with s/kmart/karp/ in the title too. Also, we are well aware that the current draft is very much a catch-all. That was by design. We will be breaking up this document into a few smaller docs, post Hiroshima, something like: - Guidance to Routing Protocol Authentication Design Teams - Threats - Requirements (maybe combined with threats?) - Framework So please be thinking as you review it if you would like to co-author any of those documents. I'll probably keep lead editor role on the Framework document, and maybe one other, but invite co-editors even on those. See you soon, Gregory. = = = = BEGIN PASTE OF DOCUMENT = = = = KARP G. Lebovitz Internet-Draft Juniper Intended status: Informational November 05, 2009 Expires: May 9, 2010 Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire draft-lebovitz-kmart-roadmap-03 Abstract In the March of 2006 the IAB held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for "[t]ightening the security of the core routing infrastructure." Four main steps were identified for improving the security of the routing infrastructure. One of those steps was "securing the routing protocols' packets on the wire." One mechanism for securing routing protocol packets on the wire is the use of per-packet cryptographic message authentication, providing both peer authentication and message integrity. Many different routing protocols exist and they employ a range of different transport subsystems. Therefore there must necessarily be various methods defined for applying cryptographic authentication to these varying protocols. Many routing protocols already have some method for accomplishing cryptographic message authentication. However, in many cases the existing methods are dated, vulnerable to attack, and/or employ cryptographic algorithms that have been deprecated. This document creates a roadmap of protocol specification work for the use of modern cryptogrpahic mechanisms and algorithms for message authentication in routing protocols. It also defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This roadmap reflects the input of both the security area and routing area in order to form a jointly agreed upon and prioritized work list for the effort. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Lebovitz & Expires May 9, 2010 [Page 1] Internet-Draft KARP Roadmap November 2009 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 9, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Lebovitz & Expires May 9, 2010 [Page 2] Internet-Draft KARP Roadmap November 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 1.6. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Threats In Scope . . . . . . . . . . . . . . . . . . . . . 13 2.2. Threats Out of Scope . . . . . . . . . . . . . . . . . . . 15 3. Categorizing Routing Protocols . . . . . . . . . . . . . . . . 16 3.1. Category: Messaging Transaction Type . . . . . . . . . . . 16 3.2. Category: Peer vs. Group Keying . . . . . . . . . . . . . 17 3.3. Category: Update vs. Discovery Protocol . . . . . . . . . 18 3.4. Security Characterization Vectors . . . . . . . . . . . . 18 3.4.1. Internal vs. External Operation . . . . . . . . . . . 18 3.4.2. Unique versus Shared Keys . . . . . . . . . . . . . . 19 3.4.3. Out-of-Band vs. In-line Key Management . . . . . . . . 20 4. The Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Work Phases on any Particular Protocol . . . . . . . . . . 22 4.2. Requirements for Phase 1 Routing Protocols' Security Update . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3. Common Framework . . . . . . . . . . . . . . . . . . . . . 25 4.4. Work Items Per Routing Protocol . . . . . . . . . . . . . 31 4.5. Protocols in Categories . . . . . . . . . . . . . . . . . 33 4.6. Priorites . . . . . . . . . . . . . . . . . . . . . . . . 35 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 8. Change History (RFC Editor: Delete Before Publishing) . . . . 37 9. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 10.1. Normative References . . . . . . . . . . . . . . . . . . . 41 10.2. Informative References . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Lebovitz & Expires May 9, 2010 [Page 3] Internet-Draft KARP Roadmap November 2009 1. Introduction In March 2006 the Internet Architecture Board (IAB) held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that document states that "A simple risk analysis would suggest that an ideal attack target of minimal cost but maximal disruption is the core routing infrastructure." Section 8.2 calls for "[t]ightening the security of the core routing infrastructure." Four main steps were identified for that tightening: o More secure mechanisms and practices for operating routers. This work is being addressed in the OPSEC Working Group. o Cleaning up the Internet Routing Registry repository [IRR], and securing both the database and the access, so that it can be used for routing verifications. This work should be addressed through liaisons with those running the IRR's globally. o Specifications for cryptographic validation of routing message content. This work will likely be addressed in the SIDR Working Group. o Securing the routing protocols' packets on the wire This document addresses the last bullet, securing the packets on the wire of the routing protocol exchanges. The document addresses Keying and Authentication for Routing Protocols, aka "KARP". It is unlikely that this document, in its current form, will become an RFC. More likely is that this document will be split up into several smaller documents which may look something like: o Scope & Goals sections will likely become part of the KARP WG charter o Threat document o Requirements document (may be combined with Threat document) o Framework document o RoutingProtocol Design Team Work Plan document. This would include sections like Work Phases, Priorities, Security Considerations, etc. For now, the document serves as the catch all for the set of thoughts around the KARP effort. As a working group is formed, decisions will be made about the creation of specific documents. Editor's Note on "KMART" vs "KARP": The first few versions of this document were called "draft-lebovitz-kmart-roadmap-xx". Upon the creation of the BoF for IETF76, the IESG requested the name of the effort change so as to avoid any potential trademark issues. The new name of the effort is KARP. Version -03 will go out titled "draft-lebovitz-kmart-roadmap-03", so as to avoid confusion. As soon Lebovitz & Expires May 9, 2010 [Page 4] Internet-Draft KARP Roadmap November 2009 as the I-D editor queue opens again (Monday, 09 Nov) the document will be submitted with s/kmart/karp/ in the title. 1.1. Terminology Within the scope of this document, the following words, when beginning with a capital letter, or spelled in all capitals, hold the meanings described to the right of each term. If the same word is used uncapitalized, then it is intended to have its common english definition. PSK Pre-Shared Key. A key used by both peers in a secure configuration. Usually exchanged out-of-band prior to a first connection. Routing Protocol When used with capital "R" and "P" in this document the term refers the Routing Protocol for which work is being done to provide or enhance its peer authentication mechanisms. PRF Pseudorandom number function, or sometimes called pseudorandom number generator (PRNG). An algorithm for generating a sequence of numbers that approximates the properties of random numbers. The sequence is not truly random, in that it is completely determined by a relatively small set of initial values that are passed into the function. An exmaple is SHA-256. KDF Key derivation function. A particular specified use of a PRF that takes a PSK, combines it with other inputs to the PRF, and produces a result that is suitable for use as a Traffic Key. Identifier The type and value used by one peer of an authenticated message exchange to signify to the other peer who they are. The Identifier is used by the receiver as a lookup index into a table containing further information about the peer that is required to continue processing the message, for example a Security Association (SA) or keys. Identity Proof A cryptographic proof for an asserted identity, that the peer really is who they assert themselves to be. Proof of identity can be arranged between the peers in a few ways, for example PSK, raw assymetric keys, or a more user-friendly representation of assymetric keys, like a certificate. Lebovitz & Expires May 9, 2010 [Page 5] Internet-Draft KARP Roadmap November 2009 Security Association or SA The parameters and keys that together form the required information for processing secure sessions between peers. Examples of items that may exist in an SA include: Identifier, PSK, Traffic Key, cryptographic algorithms, key lifetimes. KMP Key Management Protocol. A protocol used between peers to exchange SA parameters and Traffic Keys. Examples of KMPs include IKE, TLS, and SSH. KMP Function Any actual KMP used in the general KARP solution framework Peer Key Keys that are used between peers as the identity proof. These keys may or may not be connection specific, depending on who they were established, and what form of identity and identity proof is being used in the system. Traffic Key The actual key used on each packet of a message. Definitions of items specific to the general KARP framework are described in more detail in the Framework section Section 4.3. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. 1.3. Scope Four basic tactics may be employed in order to secure any piece of data as it is transmitted over the wire: privacy (or encryption), authentication, message integrity, and non-repudiation. The focus for this effort, and the scope for this roadmap document, will be message authentication and packet integrity only. This work explicitly excludes, at this point in time, the other two tactics: privacy and non-repudiation. Since the objective of most routing protocols is to broadly advertise the routing topology, routing messages are commonly sent in the clear; confidentiality is not normally required for routing protocols. However, ensuring that routing peers truly are the trusted peers expected, and that no roque Lebovitz & Expires May 9, 2010 [Page 6] Internet-Draft KARP Roadmap November 2009 peers or messages can compromise the stability of the routing environment is critical, and thus our focus. The other two explicitly excluded tactics, privacy and non-repudiation, may be addressed in future work. It is possible for routing protocol packets to be transmitted employing all four security tactics mentioned above using existing standards. For example, one could run unicast, layer 3 or above routing protocol packets through IPsec ESP [RFC4303]. This would provide the added benefit of privacy, and non-repudiation. However, router platforms and systems have been fine tuned over the years for the specific processing necessary for routing protocols' non- encapsulated formats. Operators are, therefore, quite reluctant to explore new packet encapsulations for these tried and true protocols. In addition, at least in the case of BGP and LDP, these protocols already have existing mechanisms for cryptographically authenticating and integrity checking the packets on the wire. Products with these mechanisms have already been produced, code has already been written and both have been optimized for the existing mechanisms. Rather than turn away from these mechanisms, we want to enhance them, updating them to modern and secure levels. There are two main work phases for this roadmap, and for any Routing Protocol work undertaken as part of this roadmap (discussed further in the Work Phases (Section 4.1) section). The first is to enhance the Routing Protocol's current authentication mechanism, ensuring it employs modern cryptographic algorithms and methods for its basic operational model, fulfilling the requirements defined in the Requirements (Section 4.2) section, and protecting against as many of the threats as possible as defined in the Threats (Section 2.1) section. Many of the Routing Protocols' current mechanisms use manual keys, so the first phase updates will focus on shoring up the manual key mechanisms that exist. The second work phase is to define the use of a key management protocol (KMP) for creating and managing session keys used in the Routing Protocols' message authentication and data integrity functions. It is intended that a general KMP framework -- or a small number of frameworks -- can be defined and leveraged for many Routing Protocols. Therefore, the scope of this roadmap of work includes: Lebovitz & Expires May 9, 2010 [Page 7] Internet-Draft KARP Roadmap November 2009 o Making use of existing routing protocol security protocols, where they exist, and enhancing or updating them as necessary for modern cryptographic best practices, o Developing a framework for using automatic key management in order to ease deployment, lower cost of operation, and allow for rapid responses to security breaches, and o Specifying the automated key management protocol that may be combined with the bits-on-the-wire mechanisms. The work also serves as an agreement between the Routing Area and the Security Area about the priorities and work plan for incrementally delivering the above work. This point is important. There will be times when the best-security-possible will give way to vastly- improved-over-current-security-but-admittedly-not-yet-best-security- possible, in order that incremental progress toward a more secure Internet may be achieved. As such, this document will call out places where agreement has been reached on such trade offs. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and sets a direction, a set of requirements, and a relative priority for addressing that specification work. There are a set of threats to routing protocols that are considered in-scope for this document/roadmap, and a set considered out-of- scope. These are described in detail in the Threats (Section 2) section below. 1.4. Goals The goals and general guidance for this work roadmap follow: 1. Provide authentication and integrity protection for packets on the wire of existing routing protocols 2. Deliver a path to incrementally improve security of the routing infrastructure. The principle of crawl, walk, run will be in place. Routing protocol authentication mechanisms may not go immediately from their current state to a state containing the best possible, most modern security practices. Incremental steps will need to be taken for a few very practical reasons. First, there are a considerable number of deployed routing devices in operating networks that will not be able to run the most modern cryptographic mechanisms without significant and unacceptable performance penalties. The roadmap for any one routing protocol MUST allow for incremental improvements on existing operational Lebovitz & Expires May 9, 2010 [Page 8] Internet-Draft KARP Roadmap November 2009 devices. Second, current routing protocol performance on deployed devices has been achieved over the last 20 years through extensive tuning of software and hardware elements, and is a constant focus for improvement by vendors and operators alike. The introduction of new security mechanisms affects this performance balance. The performance impact of any incremental step of security improvement will need to be weighed by the community, and introduced in such a way that allows the vendor and operator community a path to adoption that upholds reasonable performance metrics. Therefore, certain specification elements may be introduced carrying the "SHOULD" guidance, with the intention that the same mechanism will carry a "MUST" in the next release of the specification. This gives the vendors and implementors the guidance they need to tune their software and hardware appropriately over time. Last, some security mechanisms require the build out of other operational support systems, and this will take time. An example where these three reasons are at play in an incremental improvement roadmap is seen in the improvement of BGP's [RFC4271] security via the update of the TCP Authentication Option (TCP-AO) [I-D.ietf-tcpm-tcp-auth-opt] effort. It would be ideal, and reflect best common security practice, to have a fully specified key management protocol for negotiating TCP-AO's authentication material, using certificates for peer authentication in the keying. However, in the spirit of incremental deployment, we will first address issues like cryptographic algorithm agility, replay attacks, TCP session resetting in the base TCP-AO protocol before we layer key management on top of it. 3. The deploy-ability of the improved security solutions on currently running routing infrastructure equipment. This begs the consideration of the current state of processing power available on routers in the network today. 4. Operational deploy-ability - A solutions acceptability will also be measured by how deployable the solution is by common operator teams using common deployment processes and infrastructures. I.e. We will try to make these solutions fit as well as possible into current operational practices or router deployment. This will be heavily influenced by operator input, to ensure that what we specify can -- and, more importantly, will -- be deployed once specified and implemented by vendors. Deployment of incrementally more secure routing infrastructure in the Internet is the final measure of success. Measurably, we would like to see an increase in the number of surveyed respondents who report deploying the updated authentication mechanisms anywhere across their network, as well as a sharp rise in usage for the total percentage of their network's routers. Lebovitz & Expires May 9, 2010 [Page 9] Internet-Draft KARP Roadmap November 2009 Interviews with operators show several points about routing security. First, over 70% of operators have deployed transport connection protection via TCP-MD5 on their EBGP [ISR2008] . Over 55% also deploy MD5 on their IBGP connections, and 50% deploy MD5 on some other IGP. The survey states that "a considerable increase was observed over previous editions of the survey for use of TCP MD5 with external peers (eBGP), internal peers (iBGP) and MD5 extensions for IGPs." Though the data is not captured in the report, the authors believe anecdotally that of those who have deployed MD5 somewhere in their network, only about 25-30% of the routers in their network are deployed with the authentication enabled. None report using IPsec to protect the routing protocol, and this was a decline from the few that reported doing so in the previous year's report. From my personal conversations with operators, of those using MD5, almost all report deploying with one single manual key throughout the entire network. These same operators report that the one single key has not been changed since it was originally installed, sometimes five or more years ago. When asked why, particularly for the case of BGP using TCP MD5, the following reasons are often given: A. Changing the keys triggers a TCP reset, and thus bounces the links/adjacencies, undermining Service Level Agreements (SLAs). B. For external peers, difficulty of coordination with the other organization is an issue. Once they find the correct contact at the other organization (not always so easy), the coordination function is serialized and on a per peer/AS basis. The coordination is very cumbersome and tedious to execute in practice. C. Keys must be changed at precisely the same time, or at least within 60 seconds (as supported by two major vendors) in order to limit connectivity outage duration. This is incredibly difficult to do, operationally, especially between different organizations. D. Relatively low priority compared to other operatoinal issues. E. Lack of staff to implement the changes device by device. F. There are three use cases for operational peering at play here: peers and interconnection with other operators, Internal BGP and other routing sessions within a single operator, and operator-to-customer-CPE devices. All three have very different properties, and all are reported as cumbersome. One operator reported that the same key is used for all customer premise equipment. The same operator reported that if the customer mandated, a unique key could be created, although the Lebovitz & Expires May 9, 2010 [Page 10] Internet-Draft KARP Roadmap November 2009 last time this occurred it created such an operational headache that the administrators now usually tell customers that the option doesn't even exist, to avoid the difficulties. These customer-uniqe keys are never changed, unless the customer demands so. The main threat at play here is that a terminated employee from such an operator who had access to the one (or few) keys used for authentication in these environments could easily wage an attack -- or offer the keys to others who would wage the attack -- and bring down many of the adjacencies, causing destabilization to the routing system. Whatever mechanisms we specify need to be easier than the current methods to deploy, and should provide obvious operational efficiency gains along with significantly better security and threat protection. This combination of value may be enough to drive much broader adoption. 5. Address the threats enumerated above in the "Threats" section (Section 2) for each routing protocol, along a roadmap. Not all threats may be able to be addressed in the first specification update for any one protocol. Roadmaps will be defined so that both the security area and the routing area agree on how the threats will be addressed completely over time. 6. Create a re-usable architecture, framework, and guidelines for various IETF working teams who will address these security improvements for various Routing Protocols. The crux of the KARP work is to re-use that framework as much as possible across relevant Routing Protocols. For example, designers should aim to re-use the key management protocol that will be defined for BGP's TCP-AO key establishment for as many other routing protocols as possible. This is but one example. 7. Bridge any gaps between IETF's Routing and Security Areas by recording agreements on work items, roadmaps, and guidance from the Area leads and Internet Architecture Board (IAB, www.iab.org). 1.5. Non-Goals The following two goals are considered out-of-scope for this effort: o Privacy of the packets on the wire, at this point in time. Once this roadmap is realized, we may revisit work on privacy. Lebovitz & Expires May 9, 2010 [Page 11] Internet-Draft KARP Roadmap November 2009 o Message content security. This work is being addressed in other IETF efforts, like SIDR. 1.6. Audience The audience for this roadmap includes: o Routing Area working group chairs and participants - These people are charged with updates to the Routing Protocol specifications. Any and all cryptographic authentication work on these specifications will occur in Routing Area working groups, with close partnership with the Security Area. Co- advisors from Security Area may often be named for these partnership efforts. o Security Area reviewers of routing area documents - These people are delegated by the Security Area Directors to perform reviews on routing protocol specifications as they pass through working group last call or IESG review. They will pay particular attention to the use of cryptographic authentication and corresponding security mechanisms for the routing protocols. They will ensure that incremental security improvements are being made, in line with this roadmap. o Security Area engineers - These people partner with routing area authors/designers on the security mechanisms in routing protocol specifications. Some of these security area engineers will be assigned by the Security Area Directors, while others will be interested parties in the relevant working groups. o Operators - The operators are a key audience for this work, as the work is considered to have succeeded if the operators deploy the technology, presumably due to a perception of significantly improved security value coupled with relative similarity to deployment complexity and cost. Conversely, the work will be considered a failure if the operators do not care to deploy it, either due to lack of value or perceived (or real) over- complexity of operations. And as such, the GROW and OPSEC WGs should be kept squarely in the loop as well. 2. Threats In RFC4949[RFC4949], a threat is defined as a potential for violation of security, which exists when there is a circumstance, capability, Lebovitz & Expires May 9, 2010 [Page 12] Internet-Draft KARP Roadmap November 2009 action, or event that could breach security and cause harm. This section defines the threats that are in scope for this roadmap, and those that are explicitly out of scope. This document leverages the "Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] , capitalizes terms from that document, and offers a terse definition of those terms. (More thorough description of routing protocol threats sources, motivations, consequences and actions can be found in RFC 4593 [RFC4593] itself). The threat listings below expand upon these threat definitions. 2.1. Threats In Scope The threats that will be addressed in this roadmap are those from OUTSIDERS, attackers that may reside anywhere in the Internet, have the ability to send IP traffic to the router, may be able to observe the router's replies, and may even control the path for a legitimate peer's traffic. These are not legitimate participants in the routing protocol. Message authentication and integrity protection specifically aims to identify messages originating from OUTSIDERS. The concept of OUTSIDERS can be further refined to include attackers who are terminated employees, and those sitting on-path. o On-Path - attackers with control of a network resource or a tap along the path of packets between two routers. An on-path outsider can attempt a man-in-the-middle attack, in addition to several other attack classes. A man-in-the-middle (MitM) attack occurs when an attacker who has access to packets flowing between two peers tampers with those packets in such a way that both peers think they are talking to each other directly, when in fact they are actually talking to the attacker only. Protocols conforming to this roadmap will use cryptographic mechanisms to prevent a man-in-the-middle attacker from situating himself undetected. o Terminated Employees - in this context, those who had access router configuration that included keys or keying material like pre-shared keys used in securing the routing protocol. Using this material, the attacker could send properly MAC'd spoofed packets appearing to come from router A to router B, and thus impersonate an authorized peer. The attacker could then send false traffic that changes the network behavior from its operator's design. The goal of addressing this source specifically is to call out the case where new keys or keying material becomes necessary very quickly, with little operational expense, upon the termination of such an employee. This grouping could also refer to any attacker who somehow managed to gain access to keying material, and said access had been detected by the operators such that the operators have an opportunity to move to new keys in order to prevent an Lebovitz & Expires May 9, 2010 [Page 13] Internet-Draft KARP Roadmap November 2009 attack. These ATTACK ACTIONS are in scope for this roadmap: o SPOOFING - when an unauthorized device assumes the identity of an authorized one. Spoofing can be used, for example, to inject malicious routing information that causes the disruption of network services. Spoofing can also be used to cause a neighbor relationship to form that subsequently denies the formation of the relationship with the legitimate router. o FALSIFICATION - an action whereby an attacker sends false routing information. To falsify the routing information, an attacker has to be either the originator or a forwarder of the routing information. Falsification may occur by an ORIGINATOR, or a FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or MISTATEMENT of network resource reachability. We must be careful to remember that in this work we are only targeting falsification from outsiders as may occur from tampering with packets in flight. Falsification from BYZANTINES (see the Threats Out of Scope section (Section 2.2) below) are not addressed by the KARP effort. o INTERFERENCE - when an attacker inhibits the exchanges by legitimate routers. The types of interference addressed by this work include: * ADDING NOISE * REPLAYING OUT-DATED PACKETS * INSERTING MESSAGES * CORRUPTING MESSAGES * BREAKING SYNCHRONIZATION * Changing message content o DoS attacks on transport sub-systems - This includes any other DoS attacks specifically based on the above attack types. This is when an attacker sends spoofed packets aimed at halting or preventing the underlying protocol over which the routing protocol runs, for example halting a BGP session by sending a TCP FIN or RST packet. Since this attack depends on spoofing, operators are encouraged to deploy o DoS attacks using the authentication mechanism - This includes an attacker sending packets which confuse or overwhelm a security mechanism itself. An example is initiating an overwhelming load of spoofed authenticated route messages so that the receiver needs to process the MAC check, only to discard the packet, sending CPU levels rising. Another example is when an attacker sends an overwhelming load of keying protocol initiations from bogus sources. All other possible DoS attacks are out of scope (see Lebovitz & Expires May 9, 2010 [Page 14] Internet-Draft KARP Roadmap November 2009 next section). o Brute Foce Attacks Against Password/Keys - This includes either online or offline attacks where attempts are made repeatedly using different keys/passwords until a match is found. While it is impossible to make brute force attacks on keys completely unsuccessful, proper design can make such attacks much harder to succeed. For exmaple, the key length should be sufficiently long so that covering the entire space of possible keys is improbable using computational power expected to be available 10 years out or more. Also, frequently changing the keys may render useless a successful guess some time in the future, as those keys may no longer be in use. 2.2. Threats Out of Scope Threats from BYZANTINE sources -- faulty, misconfigured, or subverted routers, i.e., legitimate participants in the routing protocol -- are out of scope for this roadmap. Any of the attacks described in the above section (Section 2.1) that may be levied by a BYZANTINE source are therefore also out of scope. In addition, these other attack actions are out of scope for this work: o SNIFFING - passive observation of route message contents in flight o FALSIFICATION by BYZANTINE sources - unauthorized message content by a legitimate authorized source. o INTERFERENCE due to: * NOT FORWARDING PACKETS - cannot be prevented with cryptographic authentication * DELAYING MESSAGES - cannot be prevented with cryptographic authentication * DENIAL OF RECEIPT - cannot be prevented with cryptographic authentication * UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR working group (http://www.ietf.org/html.charters/sidr-charter.html). * Any other type of DoS attack. For example, a flood of traffic that fills the link ahead of the router, so that the router is rendered unusable and unreachable by valid packets is NOT an attack that this work will address. Many other such examples could be contrived. Lebovitz & Expires May 9, 2010 [Page 15] Internet-Draft KARP Roadmap November 2009 3. Categorizing Routing Protocols For the purpose of this security roadmap definition, we will categorize the routing protocols into groups and have design teams focus on the specification work within those groupings. It is believed that the groupings will have like requirements for their authentication mechanisms, and that reuse of authentication mechanisms will be greatest within these grouping. The work items placed on the roadmap will be defined and assigned based on these categorizations. It is also hoped that, down the road in the Phase 2 work, we can create one KMP per category (if not for several categories) so that the work can be easily leveraged by the various Routing Protocol teams. KMPs are useful for allowing simple, automated updates of the traffic keys used in a base protocol. KMPs replace the need for humans, or OSS routines, to periodically replace keys on running systems. It also removes the need for a chain of manual keys to be chosen or configured. When configured properly, a KMP will enforce the key freshness policy of two peers by keeping track of the key lifetime and negotiating a new key at the defined interval. 3.1. Category: Messaging Transaction Type The first categorization defines four types of messaging transactions used on the wire by the base Routing Protocol. They are: One-to-One One peer router directly and intentionally delivers a route update specifically to one other peer router. Examples are BGP and LDP. Point-to-point modes of both IS-IS and OSPF, when sent over both traditional point-to-point links and when using multi-access layers, may both also fall into this category. [question to reviewers: Should we list all protocols into these categories right here, or just give a few examples?] One-to-Many A router peers with multiple other routers on a single network segment -- i.e. on link local -- such that it creates and sends one route update message which is intended for consumption by multiple peers. Examples would be OSPF and IS-IS in their broadcast, non-point- to-point modes. Lebovitz & Expires May 9, 2010 [Page 16] Internet-Draft KARP Roadmap November 2009 Client-Server A client-server routing protocol is one where one router initiates a request for route information from another router, who then formulates a response to that request, and replies with the requested data. Examples are a BGP Route Reflector and [???? Are there other examples? Is this the right example? Do discovery protocols fall under this category?]. Multicast Multicast protocols have unique security properties because of the fact that they are inherently group- based protocols and thus have group keying requirements at the routing level where link-local routing messages are multicasted. Also, at least in the case of PIM-SM, some messages are are sent unicast to a given peer(s), as is the case with router-close- to-sender and the "Rendezvous Point". Some work for application layer message security has been done in the Multicast Security working group (MSEC, http://www.ietf.org/html.charters/msec-charter.html) and may be helpful to review, but is not directly applicable. [author's note: I think the above definitions need clean up. Routing area folks, especially ADs, PLEASE suggest new text.] 3.2. Category: Peer vs. Group Keying The second axis of categorization groups protocols by the keying mechanism that will be necessary for distributing session keys to the actual Routing Protocol transports. They are: Peer keying One router sends the keying messages directly and only to one other router, such that a one-to-one, unique keying security association (SA) is established between the two routers Group Keying One router creates and distributes a single keying message to multiple peers. In this case an group SA will be established and used between multiple peers simultaneously. Group keying exists for protocols like OSPF [RFC2328] , and also for multicast protocols like PIM-SM [RFC4601]. Lebovitz & Expires May 9, 2010 [Page 17] Internet-Draft KARP Roadmap November 2009 3.3. Category: Update vs. Discovery Protocol The third category group considers protocols by the contents of the messages being exchanged in the Routing Protocol. They are: Updates Messages that carry route advertisements or update information from peer to peer Discovery Messages sent as part of a policy, peer, or service discovery process. These messages are normally exchanged prior to any adjacency being formed, and before any updates are sent. For example, end-point discovery mechanisms are common in L2VPN and L3VPN solutions. [QUESTION TO REVIEWERS: is this really just what's described in 3.1 as "Client-Server" and/or "One-to-One"? Is there really such a different in discovery protocols that they need their own category to figure out how to authenticate them? Can someone provide a few examples? 3.4. Security Characterization Vectors A few more considerations must be made about the protocol and its use when initially categorizing the protocol and scoping the authentication work. 3.4.1. Internal vs. External Operation The designers must consider whether the protocol is an internal routing protocol or an external one, i.e. Does it primarily run between peers within a single domain of control or between two different domains of control? Some protocols may be used in both cases, internally and externally, and as such various modes of authentication operation may be required for the same protocol. While it is preferred that all routing exchanges run with the utmost security mechanisms enabled in all deployments, this exhortation is greater for those protocols running on inter-domain point-to-point links, and greatest for those on shared access link layers with several different domains interchanging together, because the volume of attackers are greater from the outside. Note however that the consequences of internal attacks maybe no less severe -- in fact they may be quite a bit more severe -- than an external attack. An example of this internal versus external consideration is BGP which has both EBGP and IBGP modes. Another example is a multicast protocol where the neighbors are sometimes within a domain of control and sometimes at an inter-domain exchange point. In the case of Lebovitz & Expires May 9, 2010 [Page 18] Internet-Draft KARP Roadmap November 2009 PIM-SM running on an internal multi-access link, It would be acceptable to give up some security to get some convenience by using a group key between the peers on the link. On the other hand, in the case of PIM-SM running over a multi-access link at a public exchange point, operators may favor security over convenience by using unique pair-wise keys for every peer. Designers must consider both modes of operation and ensure the authentication mechanisms fit both. Operators are encouraged to run cryptographic authentication on all their adjacencies, but to work from the outside in, i.e. The EBGP links are a higher priority than the IBGP links because they are externally facing, and, as a result, more likely to be targeted in an attack. 3.4.2. Unique versus Shared Keys This section discusses security considerations regarding when it is appropriate to use the same authentication key inputs for multiple peers and when it is not. This is largely a debate of convenience versus security. It is often the case that the best secured mechanism is also the least convenient mechanism. For example, an air gap between a host and the network absolutely prevents remote attacks on the host, but having to copy and carry files using the "sneaker net" is quite inconvenient and unscalable. Operators have erred on the side of convenience when it comes to securing routing protocols with cryptographic authentication. Many do not use it at all. Some use it only on external links, but not on internal links. Those that do use it often use the same key for all peers across their entire network. It is common to see the same key in use for years, and that being the same key that was entered when authentication was originally configured, or the routing gear deployed. The goal for designers is to create authentication mechanisms that are easy for the operators to deploy and manage, and still use unique keys between peers (or small groups on multi-access links), and within between sessions. Operators have the impression that they NEED one key shared across the network, when in fact they do not. What they need is the relative convenience they experience from deploying cryptographic authentication with one (or few) key, compared to the inconvenience they would experience if they deployed the same authentication mechanism using unique pair-wise keys. An example is BGP Route Reflectors. Here operators often use the same authentication key between each client and the route reflector. The roadmaps defined from this guidance document will allow for unique keys to be used between each client and the peer, without sacrificing much convenience. Designers should strive to deliver peer-wise Lebovitz & Expires May 9, 2010 [Page 19] Internet-Draft KARP Roadmap November 2009 unique keying mechanisms with similar ease-of-deployment properties as today's one-key method. Operators must understand the consequences of using the same keys across many peers. Unique keys are more secure than shared keys because they reduce both the attack target size and the attack consequence size. In this context, the attack target size represents the number of unique routing exchanges across a network that an attacker may be able to observe in order to gain security association credentials, i.e. crack the keys. If a shared key is used across the entire internal domain of control, then the attack target size is very large. The larger the attack target, the easier it is for the attacker to gain access to analysis data, and greater the volume of analysis data he can access in a given time frame, both of which make his job easier. Using the same key across the network makes the attack vulnerability surface more penetrable than unique keys. Consider also the attack consequence size, the amount of routing adjacencies that can be negatively affected once a breach has occurred, i.e. once the keys have been acquired by the attacker. Again, if a shared key is used across the internal domain, then the consequence size is the whole network. Ideally, unique key pairs would be used for each adjacency. In some cases designers may need to use shared keys in order to solve the given problem space. For example, a multicast packet is sent once but then observed and consumed by several routing neighbors. If unique keys were used per neighbor, the benefit of multicast would be erased because the casting peer would have to create a different announcement packet/stream for each listening peer. Though this may be desired and acceptable in some small amount of use cases, it is not the norm. Shared group keys are an acceptable solution here, and much work has been done already in this area (see MSEC working group). 3.4.3. Out-of-Band vs. In-line Key Management This section discusses the security and use case considerations for keys placed on devices through out-of-band configurations versus through one routing peer-to-peer key management protocol exchanges. Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to the Routing Protocol. Instead, we mean that the exchange occurs in- line, over IP, between the two routing peers directly. In in-line KMP the peers themselves handle the key and security association negotiation between themselves directly, whereas in an out-of-band system the keys are placed onto the device through some other configuration or management method or interface. An example of an out-of-band mechanism could be an administrator who Lebovitz & Expires May 9, 2010 [Page 20] Internet-Draft KARP Roadmap November 2009 makes a remote management connection (e.g. using SSH) to a router and manually enters the keying information -- like the algorithm, the key(s), the lifetimes, etc. Another example could be an OSS system which inputs the same information via a script over an SSH connection, or by pushing configuration through some other management connection, standard (Netconf-based) or proprietary. The drawbacks of an out-of-band mechanism include: lack of scale- ability, complexity and speed of changing if a breach is suspected. For example, if an employee who had access to keys was was terminated, or if a machine holding those keys was belived compromised, then the system would be considered insecure and vulnerable until new keys were defined by a human. Those keys then need to be placed into the OSS system, manually, and the OSS system then needs to push the change -- often during a very limited change window -- into the relevant devices. If there are multiple organizations involved in these connections, this process is greatly complicated. The benefits of out-of-band mechanism is that once the new keys/ parameters are set in OSS system they can be pushed automatically to all devices within the OSS's domain of control. Operators have mechanisms in place for this already. In small environments with few routers, a manual system is not difficult to employ. We further define an in-line key exchange as using cryptographicly protected identity verification, session key negotiation, and security association parameter negotiation between the two routing peers. The KMP between the two peers may also include the negotiation of parameters, like algorithms, cryptographic inputs (e.g. initialization vectors), key life-times, etc. The benefits an in-line KMP are several. An in-line KMP results in key(s) that are privately generated, and not recorded permanently anywhere. Since the traffic keys used in a particular connection are not a fixed part of a device configuration no steal-able data exists anywhere else in the operator's systems which can be stolen, e.g. in the case of a terminated or turned employee. If a server or other data store is stolen or compromised, the thieves gain no access to current traffic keys. They may gain access to key derivation material, like a PSK, but not current traffic keys in use. In this example, these PSKs can be updated into the device configurations (either manually or through an OSS) without bouncing or impacting the existing session at all. In the case of using raw assymetric keys or certificates, instead of PSKs, the data theft would likely not even result in any compromise, as the key pairs would have been generated on the routers, and never leave those routers. In such a case no changes are needed on the routers; the connections will continue to Lebovitz & Expires May 9, 2010 [Page 21] Internet-Draft KARP Roadmap November 2009 be secure, uncompromised. Additionally, with a KMP regular re-keys operations occur without any operator involvement or oversight. This keeps keys fresh. The drawbacks to using a KMP are few. First, a KMP requires more cryptographic processing for the router at the very beginning of a connection. This will add some minor start-up time to connection establishment versus a purely manual key approach. Once a connection with traffic keys have been established via a KMP, the performance is the same in the KMP and the out-of-band case. KMPs also add another layer of protocol and configuration complexity which can fail or be misconfigured. This was more of an issue when these KMPs were first deployed, but less so as these implementaitons and operational experience with them has matured. The desired end goal is in-line KMPs. 4. The Roadmap 4.1. Work Phases on any Particular Protocol The desired endstate for the KARP work contains several items. First, the people desiring to deploy securely authenticated and integrity validated packets between routing peers have the tools specified, implemented and shipping in order to deploy. These tools should be fairly simple to implement, and not more complex than the security mechanisms to which the operators are already accustomed. (Examples of security mechanisms to which router operators are accustomed include: the use of assymetric keys for authentication in SSH for router configuration, the use of pre-shared keys (PSKs) in TCP MD5 for BGP protection, the use of self-signed certificates for HTTPS access to device Web-based user interfaces, the use of strongly constructed passwords and/or identity tokens for user identification when logging into routers and management systems.) While the tools that we intend to specify may not be able to stop a deployment from using "foobar" as an input key for every device across their entire routing domain, we intend to make a solid, modern security system that is not too much more difficult than that. In other words, simplicity and deployability are keys to success. The Routing Protocols will specify modern cryptographic algorithms and security mechanisms. Routing peers will be able to employ unique, pair-wise keys per peering instance, with reasonable key lifetimes, and updating those keys on a somewhat regular basis will be operationally easy, causing no service interruption. Achieving the above described end-state using manual keys may only be pragmatic in very small deployments. In larger deployments, this end Lebovitz & Expires May 9, 2010 [Page 22] Internet-Draft KARP Roadmap November 2009 state will be much more operationally difficult to reach with only manual keys. Thus, there will be a need for key life cycle management, in the form of a key management protocol, or KMP. We expect that the two forms, manual key usage and KMP usage, will co- exist in the real world. For example, a provider's edge router at a public exchange peering point will want to use a KMP for ensuring unique and fresh keys with external peers, while a manual key may be used between a provider's access edge router and each of the same provider's customer premise routers with which it peers. In accordance with the desired end state just described, we define two main work phases for each Routing Protocol: 1. Enhance the Routing Protocol's current authentication mechanism. This work involves enhancing a Routing Protocol's current security mechanisms in order to achieve a consistent, modern level of security functionality within its existing keying framework. It is understood and accepted that the existing keying frameworks are largely based on manual keys. Since many operators have already built operational support systems (OSS) around these manual key implementations, there is some automation available for an operator to leverage in that way, if the underlying mechanisms are themselves secure. In this phase, we explicitly exclude embedding or creating a KMP. A list of the requirements for Phase 1 work are below in the section "Requirements for Phase 1 Routing Protocols' Security Updates (Section 4.2). 2. Develop an automated keying framework. The second phase will focus on the development of an automated keying framework to faciliate unique pair-wise (or perhaps group-wise, where applicable) keys per peering instance. This involves the use of a KMP. A KMP is helpful because it negotiates unique, pair wise, random keys without administrator involvement. It also negotiates several of the SA parameters required for the secure connection, including key life times. It keeps track of those lifetimes using counters, and negotiates new keys and parameters before they expire, again, without administrator interaction. Additionally, in the event of a breach, changing the KMP key will immediately cause a rekey to occur for the Traffic Key, and those new Traffic Keys will be installed and used in the current connection. In summary, a KMP provides a protected channel between the peers through which they can negotiate and pass important data required to exchange proof of key identifiers, derive Traffic Keys, determine re-keying, synchronize their keying state, signal various keying events, notify with error messages, etc. To address brute force attacks [RFC3562] recommends a key management practice to minimize the possibility Lebovitz & Expires May 9, 2010 [Page 23] Internet-Draft KARP Roadmap November 2009 of successful attack-- frequent key rotation, limited key sharing, key length restrictions, etc. Advances in computational power due to Moore's law are making that management burden untenable-- keys must be of a size and composition that makes configuration and maintance difficult or keys must be rotated with an unreasonable frequency. A KMP will help immensely with this growing problem. The framework for any one Routing Protocol will fall under, and be able to leverage, the generic framework described below in section Section 4.3. 4.2. Requirements for Phase 1 Routing Protocols' Security Update Here is a proposed list of requirements that SHOULD be addressed by Phase 1 (according to "1." above) security updates to Routing Protocols [to be reviewed after -01 is released]: 1. Clear definitions of which elements of the transmission (frame, packet, segment, etc.) are protected by the authentication mechanism 2. Strong algorithms, and defined and accepted by the security community, MUST be specified. The option should use algorithms considered accepted by the security community, which are considered appropriately safe. The use of non-standard or unpublished algorithms SHOULD BE avoided. 3. Algorithm agility for the cryptograhpic algorithms used in the authentication MUST be specified, i.e. more than one algorithm MUST be specified and it MUST be clear how new algorithms MAY be specified and used within the protocol. This requirement exists in case one algorithm gets broken suddenly. Research to identify weakness in algorithms is constant. Breaking a cipher isn't a matter of if, but when it will occur. t's highly unlikely that two different algorithms will be broken simultaneously. So, if two are supported, and one gets broken, we can use the other until we get a new one in place. Having the ability within the protocol specification to support such an event, having algorithm agility, is essential. Mandating two algorithms provides both a redundancy, and a mechanism for enacting that redundancy when needed. 4. Secure use of simple PSKs, offering both operational convenience as well as building something of a fence around stupidity, MUST be specified. 5. Inter-connection replay protection. Packets captured from one connection MUST NOT be able to be re-sent and accepted during a later connection. Lebovitz & Expires May 9, 2010 [Page 24] Internet-Draft KARP Roadmap November 2009 6. Intra-connection replay protection. Packets captured during a connection MUST NOT be able to be re-sent and accepted during that same connection, to deal with long-lived connections. 7. A change of security parameters REQUIRES, and even forces, a change of session traffic keys 8. Intra-connection re-keying which occurs without a break or interruption to the current peering session, and, if possible, without data loss, MUST be specified. 9. Efficient re-keying SHOULD be provided. The specificaion SHOULD support rekeying during a connection without the need to expend undue computational resources. In particular, the specification SHOULD avoid the need to try/compute multiple keys on a given packet. 10. Prevent DoS attacks as those described as in-scope in the threats section Section 2.1 above. 11. Default mechanisms and algorithms specified and defined as REQUIRED for all implementations 12. Manual keying MUST be supported. 13. Convergence times of the Routing Protocols SHOULD NOT be materially affected. Materially here is defined as anything greater than a 5% convergence time increase. Note that convergence is different than boot time. Also note that convergence time has a lot to do with the speed of processors used on individual routing peers, and this increases by Moore's law over time. Therefore, this requirement should be considered only in terms of total number of messages that must be exchanged, and less for the computational intensity of processing any one message. 14. The changes or addition of security mechanisms SHOULD NOT cause a refresh of route updates or cause additional route updates to be generated 15. Architecture of the specification MUST consider and allow for future use of a KMP. 4.3. Common Framework Each of the categories of routing protocols above will require unique designs for authenticating and integrity checking their protocols. However, a single underlying framework for delivering automatic keying to those solutions will be pursued. Providing such a single framework will significantly reduce the complexity of each step of the overall roadmap. For example, if each Routing Protocol needed to define it's own key management protocol this would balloon the total amount of different sockets that are needed to be opened and processes that are needed to be simultaneously running on an implementation. It would also significantly increase the run-time complexity and memory requirements of such systems running multiple Routing Protocols, causing perhaps slower performance of such Lebovitz & Expires May 9, 2010 [Page 25] Internet-Draft KARP Roadmap November 2009 systems. However, if we can land on a very small set (perhaps one or two) of automatic key management protocols, KMPs, that the various Routing Protocols can use, then we can reduce this implementation and run-time complexity. We can also decrease the total amount of time implementers need to deliver the KMPs for the Routing Protocols that will provide better threat protection. The components for the framework are listed here, and described below: o Routing Protocol security mechanism o KMP o KeyStore o Traffic Key o RoutingProtocol-to-KMP API o RoutingProtocol-to-KeyStore API o KMP-to-KeyStore API o Common Routing Protocol mechanisms o Identifiers o Proof of identity o Profiles The framework is modularized for how keys and security association (SA) parameters generally get passed from a KMP to a transport protocol. It contains three main blocks and APIs. Lebovitz & Expires May 9, 2010 [Page 26] Internet-Draft KARP Roadmap November 2009 +------------+ +--------------------+ | | | | Check +-----------+ | Identifier +-->| +---------->| | | | | KMP Function | | Identity | +----------- + | |<----------+ Proof | | | Approve | | +-+--------------+---+ +-----------+ | | KMP-to-KeyStore | | API | | \|/ | +-------+-------+ | | | | KMP-to-RoutingProtocol | | | API | KeyStore | | | | | +-------+-------+ | | | | | KeyStore-to- | | RoutingProtocol API | | | \|/ +--------------------------+-------------+ | | | | \|/ Common RtgProto | | +-------+-------+ Authentication | | | | Mechanisms | +---| Traffic |-----+--------------+ | | Key(s) | | | | | | | +---------------+ Specific | | RoutingProtocol | | Authentication | | Security | | Mechanism | +----------------------------------------+ Figure 1: Automatic Key Management Framework Each element of the framework is described here: o Routing Protocol - Routing protocol security mechanism - In each case, the Routing Protocol will contain a mechanism for using session keys in their security option. When the Routing Protocol uses a transport substrate, e.g. the way BGP, LDP and MSDP use TCP, then this applies to the security mechanism Lebovitz & Expires May 9, 2010 [Page 27] Internet-Draft KARP Roadmap November 2009 the includes that substrate. o KeyStore - Each implementation will also contain a protocol independent mechanism for storing keys, called KeyStore. The KeyStore will have multiple different logical containers, one container for each session key that any given Routing Protocol will need. Keys stored here may be a Peer Key or a Traffic Key. There may also be associated parameters as required by the SA for any given Routing Protocol. o Peer Key A key used between peers from which a traffic key is derived. An example is a PSK. o Traffic Key The actual key used on each packet of a message. This key may be derived from the key existing in the KeyStore. This will depend on whether the key in KeyStore was a manual PSK for the peers, or whether a connection-aware KMP created the key. Further, it will be connection specific, so as to provide inter- and intra-connection replay protection. o RoutingProtocol-KeyStore API - There will be an API for Routing Protocol to retrieve (or receive; it could be a push or a pull) the keys from the KeyStore. This will enable implementers to reuse the same API calls for all their Routing Protocols. The API will necessarily include facility to retrieve other SA parameters required for the construction of the Routing Protocol's packets, like key IDs or key lifetimes, etc. o KMP - There will be an automated key management protocol, KMP. This KMP will run between the peers. The KMP serves as a protected channel between the peers, through which they can negotiate and pass important data required to exchange proof of key identifiers, derive session keys, determine re-keying, synchronize their keying state, signal various keying events, notify with error messages, etc. As an analogy, in the IPsec protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306 [RFC4306]) IKEv2 is the KMP that runs between the two peers, while AH and ESP are two different base protocols that take session keys from IKEv2 and use them in their transmissions. In the analogy, the Routing Protocol, say BGP and LDP, are analogous to ESP and AH, while the KMP is analogous to IKEv2 itself. Lebovitz & Expires May 9, 2010 [Page 28] Internet-Draft KARP Roadmap November 2009 o RoutingProtocol-KMP API - There will be an API for the Routing Protocol to request a session key of the KMP, and be notified when the keys are available for it. The API will also contain a mechanism for the KMP to notify the Routing Protocol that there are new keys that it must now use, even if it didn't request those keys. The API will also include a mechanism for the KMP to receive requests for session keys and other parameters from the routing protocol. The KMP will also be aware of the various Routing Protocols and each of their unique parameters that need to be negotiated and returned. o KMP-KeyStore API - There will be an API for the KMP to place keys and parameters into the KeyStore after their negotiation and derivation with the other peer. This will enable the implementers to reuse the same calls for multiple KMPs that may be needed to address the various categories of Routing Protocols as described in the section definingcategories (Section 3). [after writing this all up, I'm not sure we really need the key_store in the middle. As long as we standardize fully all the calls needed from any Routing Protocol to any KMP, then there can be a generic hand-down function from the KMP to the Routing Protocol when the key and parameters are ready. Let's sleep on it.] [will need state machines and function calls for these APIs, as one of the work items. In essence, there is a need for a core team to develop the APIs out completely in order for the Routing Protocol teams to use them. Need to get this team going asap.] o Identifiers - A KMP is fed by identities. The identities are text strings used by the peers to indicate to each other that each are known to the other, and authorized to establish connections. Those identities must be represented in some standard string format, e.g. an IP address -- either v4 or v6, an FQDN, an RFC 822 email address, a Common Name [RFC PKI], etc. Note that even though routers do not normally have email addresses, one could use an RFC 822 email address string as a formatted identifier for a router. They would do so simply by putting the router's reference number or name- code as the "NAME" part of the address, left of the "@" symbol. They would then place some locational context in the "DOMAIN" part of the string, right of the "@" symbol. An example would be "rtr0210@sf.ca.us.company.com". This Lebovitz & Expires May 9, 2010 [Page 29] Internet-Draft KARP Roadmap November 2009 document does not suggest this string value at all. Instead, the concept is used only to clarify that the type of string employed does not matter. It also does not matter what specific text you chose to place in that string type. It only matters that the type of string -- and it's format -- must be agreed upon by the two endpoints. Further, the string can be used as an identifier in this context, even if the string is not actually provisioned in it's source domain. For example, the email address "rtr0210@sf.ca.us.company.com" may not actually exist as an email address in that domain, but that string of characters may still be used as an identifier type(s) in the routing protocol security context. What is important is that the community decide on a small but flexible set of Identifiers they will all support, and that they decide on the exact format of those string. The formats that will be used must be standardized and must be sensible for the routing infrastructure. o Identity Proof - Once the form of identity is decided, then there must be a cryptographic proof of that identity, that the peer really is who they assert themselves to be. Proof of identity can be arranged between the peers in a few ways, for example pre-shared keys, raw assymetric keys, or a more user-friendly representation of assymetric keys, like a certificate. Certificates can be used in a way requiring no additional supporting systems -- e.g. public keys for each peer can be maintained locally for verification upon contact. Certificate management can be made more simple and scalable with the use minor additional supporting systems, as is the case with self-signed certificates and a flat file list of "approved thumbprints". Self-signed certificates will have somewhat lower security properties than Certificate Authority signed certificates [RFC Certs]. The use of these different identity proofs vary in ease of deployment, ease of ongoing management, startup effort, ongoing effort and management, security strength, and consequences from loss of secrets from one part of the system to the rest of the system. For example, they differ in resistance to a security breach, and the effort required to remediate the whole system in the event of such a breach. The point here is that there are options, many of which are quite simple to employ and deploy. o Profiles - Once the KMP, Identifiers and Proofs mechanisms are converged upon, they must be clearly profiled for each Routing Protocol, so that implementors and deployers alike understand the different pieces of the solution, and can have similar configurations and interoperability across multiple vendors' devices, so as to reduce management difficulty. The Lebovitz & Expires May 9, 2010 [Page 30] Internet-Draft KARP Roadmap November 2009 profiles SHOULD also provide guidance on when to use which various combinations of options. This will, again, simplify use and interoperability. In addition to other business, administrative, and operational terms they must already exchange prior to forming first adjacencies, it is assumed that two parties deploying message authentication on their routing protocol will also need to decide upon acceptable security parameters for the connection. This will include the form and content of the identity each use to represent the other. It will also include the type of keys to be used, e.g. PSK, raw assymetric keys, certificate. And it will include the acceptable cryptographic algorithms, or algorithm suite. This agreement is necessary in order for each to properly configure the connection on their respective devices. The manner in which they agree upon and exchange this policy information is normally via phone call or written exchange, and is outside the scope of the KARP effort, but assumed to have occured. We take as a given that each party knows the identity types and values, key types and values, and acceptable cryptographic algorithms for both their own device and the peer that form the security policy for configuration on their device. Common Mechanisms - In as much as they exist, the framework will capture mechanisms that can be used commonly not only within a particular category of Routing Protocol and Routing Protocol to KMP, but also between Routing Protocol categories. Again, the goal here is simplifying the implementations and runtime code and resource requirements. There is also a goal here of favoring well vetted, reviewed, operationally proven security mechanisms over newly brewed mechanisms that are less well tried in the wild. 4.4. Work Items Per Routing Protocol Each Routing Protocol will have a team (the [Routing_Protocol]-KARP team) working on incrementally improving their Routing Protocol's security, These teams will have the following main work items: PHASE 1: Characterize the RP Assess the Routing Protocol to see what authentication mechanisms it has today. Does it needs significant improvement to its existing mechanisms or not? This will include determining if modern, strong security algorithms and parameters are present. Lebovitz & Expires May 9, 2010 [Page 31] Internet-Draft KARP Roadmap November 2009 Define Optimal State List the requirements for the Routing Protocol's session key usage and format to contain to modern, strong security algorithms and mechanisms, per the Requirements (Section 4.2) section above. The goal here is to determine what is needed for they Routing Protocol alone to be used securely with at least manual keys. Gap Analysis Enumerate the requirements for this protocol to move from its current security state, the first bullet, to its optimal state, as listed just above. Transition and Deployment Considerations Document the operational transition plan for moving from the old to the new security mechanism. Will adjacencies need to bounce? What new elements/ servers/services in the infrastructure will be required? What is an example work flow that an operator will take? The best possible case is if the adjacency does not break, but this may not always be possible. Define, Assign, Design Create a deliverables list of the design and specification work, with milestones. Define owners. Release a document(s) PHASE 2: KMP Analysis Review requirements for KMPs [RFC????]. Identify any nuances for this particular protocol's needs and its use cases for KMP. List the requirements that this Routing Protocol has for being able to be use in conjunctions with a KMP. Define the optimal state. Gap Analysis Enumerate the requirements for this protocol to move from its current security state to its optimal state. Define, Assign, Design Create a deliverabels list of the design and specification work, with miletsones. Define owners. Do the design and document work for a KMP to be able to generate the Routing Protocol's session keys for the packets on the wire. These will be the arguments passed in the API to the KMP in order to bootstrap the session keys to the Routing Protocol. There will also be a team formed to work on the base framework mechanisms for each of the main categories, i.e. the blocks and API's Lebovitz & Expires May 9, 2010 [Page 32] Internet-Draft KARP Roadmap November 2009 represented in figure 1 (Figure 1). 4.5. Protocols in Categories This section groups the Routing Protocols into like categories, according to attributes set forth in Categories Section (Section 3). Each group will have a design team tasked with improving the security of the Routing Protocol mechanisms and defining the KMP requirements for their group, then rolling both into a roadmap document upon which they will execute. BGP, LDP and MSDP The Routing Protocol's that fall into the category of the one-to- one peering messages, and will use peer keying protocols, AND are all transmitted over TCP include BGP RFC 4271 [RFC4271], LDP [RFC5036] and MSDP [RFC3618]. A team will work on one mechanism to cover these three protocols. Much of the work on the Routing Protocol update for its existing authentication mechanism is already occuring in the TCPM Working Group, on the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto]. The exception is the mode where LDP is used directly on the LAN [RFC????]. The work for this may go into the Group keying category (w/ OSPF) mentioned below. OSPF, ISIS, and RIP The Routing Protocols that fall into the category Group keying with one-to-many peering messages includes OSPF [RFC2328], ISIS [RFC1195] and RIP [RFC2453]. Not surprisingly, all these routing protocols have two other things in common. First, they are run on a combination of the OSI datalink layer 2, and the OSI network layer 3. By this we mean that they have a component of how the routing protocol works which is specified in Layer 2 as well as in Layer 3. Second, they are all internal gateway protocols, or IGPs. The keying mechanisms and use will be much more complicated to define for these than for a one-to-one messaging protocol. BFD Because it is less of a routing protocol, per se, and more of a peer aliveness detection mechanism, Bidirectional Forwarding Detection (BFD) [RFC????] will have its own team. RSVP [RFC????], RSVP-TE [RFC????], and PCE Lebovitz & Expires May 9, 2010 [Page 33] Internet-Draft KARP Roadmap November 2009 These three protocols will be handled together. [what more characterisation should we give here? Routing AD's, provide text pls?] PIM-SM and PIM-DM Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM [RFC3973] will be handled together. PIM-SM multicasts routing information (Hello, Join/Prune, Assert) on a link-local basis, using a defined multicast address. In addition, it specifies unicast communication for exchange of information (Register, Register-Stop) between the router closest to a group sender and the "rendezvous point" (RP). The RP is typically not "on-link" for a particular router. While much work has been done on multicast security for application-layer groups, little has been done to address the problem of managing hundreds or thousands of small one-to-many groups with link-local scope. Such an authentication mechanism should be considered along with the router-to-Rendezvous Point authentication mechanism. The most important issue is ensuring that only the "authorized neighbors" get the keys for (S,G), so that rogue routers cannot participate in the exchanges. Another issue is that some of the communication may occur intra-domain, e.g. the link-local messages in an enterprise, while others for the same (*,G) may occur inter-domain, e.g. the router-to-Rendezvous Point messges may be from one enterprise's router to another. One possible solution proposes a region-wide "master" key server (possibly replicated), and one "local" key server per speaking router. There is no issue with propagating the messages outside the link, because link-local messages, by definition, are not forwarded. This solution is offered only as an example of how work may progress; further discussion should occur in this work team. Specification of a link-local protection mechanism for PIM-SM occurred in RFC 4601 [RFC4601], and this work is being updated in PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal]. However, the KMP part is completely unspecified, and will require work outside the expertise of the PIM working group to accomplish, which is why this roadmap is being created. These protocols are deemed out-of-scope for this current iteration of the work roadmap. Once all of the protocols listed above have had their work completed, or are clearly within site of completion, then the community will revisit the need and interest for working on these: o MANET o FORCES [need text from routing ADs on why these are out of scope] Lebovitz & Expires May 9, 2010 [Page 34] Internet-Draft KARP Roadmap November 2009 4.6. Priorites Resources from both the routing area and the security area will be applied to work on these problem spaces as quickly as possible. Realizing that such resources are far from unlimited, a rank order priority for addressing the work of incrementally securing these groups of routing protocols is provided: o Priority 1 - BGP / LDP / MSDP - almost done with Phase 1 on these, via TCP-AO [I-D.ietf-tcpm-tcp-auth-opt] . o Priority 2 - PIM-SM o Priority 3 - OSPF / ISIS / RIP o Priority 4 - BFD o Priority 5 - RSVP and RSVP-TE By far the most important group is the Priority 1 group as these are the protocols used on the most public and exposed segments of the networks, at the peering points between operators and between operators and their customers. BFD, as a detection mechanism underlying the Priority 1 protocols is therefore second. 5. Security Considerations As mentioned in the Introduction , RFC4948 identifies additional steps needed to achieve the overall goal of improving the security of the core routing infrastructure. Those include validation of route origin announcements, path validation, cleaning up the IRR databases for accuracy, and operational security practicies that prevent routers from being compromised devices. The KARP work is but one step in a necessary system of security improvements. The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness. In addition to using a stong key/PSK of appropriate length and randomness, deployers of KARP protocols SHOULD use different keys between different routing peers whenever operationally possible. RFC3562 [RFC3562] provides some very sound guidance. It was meant Lebovitz & Expires May 9, 2010 [Page 35] Internet-Draft KARP Roadmap November 2009 specifically for the use of TCP MD5 for BGP, but it is more or less applicable to Routing Protocol authentication work that would result from KARP. It states three main points: (1) key lengths SHOULD be between 12 and 24 bytes (this will vary depending on the MAC/KDF in use), with larger keys having effectively zero additional computational costs when compared to shorter keys, (2) key sharing SHOULD be limited so that keys aren't shared among multiple BGP peering arrangements, and (3) Keys SHOULD be changed at least every 90 days (this could be longer for stronger MAC algorithms, but it is generally a wise idea). This is especially true when the Routing Protocol takes a static Traffic Key as opposed to a Traffic Key derived per-connection by a KDF. The burdon for doing so is understandable much higher than for using the same static Traffic Key across all peering routers. This is why use of a KMP network-wide increases peer-wise security so greatly, because now each set of peers can enjoys a unique Traffic Key, and if an attacker sitting between two routers learns or guesses the Traffic Key for that connection, she doesn't gain access to all the other connections as well. However, whenever using manual keys, it is best to design a system where a given PSK will be used in a KDF, mixed with connection specific material, in order to generate session unique -- and therefore peer-wise -- Traffic Keys. Doing so has the following advantages: the Traffic Keys used in the per-message MAC operation are peer-wise unique, it provides inter-connection replay protection, and, if the per-message MAC covers some connection counter, intra- connection replay protection. Note that in the composition of certain key derivation functions (e.g. KDF_AES_128_CMAC, as used in TCP-AO [I-D.ao-crypto]), the pseudorandom function (PRF) used in the KDF may require a key of a certain fixed size as an input. For example, AES_128_CMAC requires a 128 bit (16 byte) key as the seed. However, for convenience to the administrators/deployers, a specification may not want to force the deployer to enter a PSK of exactly 16 bytes. Instead, a specification may call for a sub-key routine that could handle a variable length PSK, one that might be less than 16 bytes (see [RFC4615], section 3, as an example). That sub-key routine would act as a key extractor to derive a second key of exactly the required length, and thus suitable as a seed to the PRF. This does NOT mean that administrators are safe to use weak keys. Administrators are encouraged to follow [RFC4086] as listed above. We simply attempted to "put a fence around stupidity", in as much as possible. A better option, from a security perspective, is to use some representation of a device-specific assymetric key pair as the Lebovitz & Expires May 9, 2010 [Page 36] Internet-Draft KARP Roadmap November 2009 identity proof, as described in Section 3.4.2. When it comes time for the KARP WG to design the re-usable model for a KMP, The Guidelines for Cryptographic Key Management, RFC4107 [RFC4107] should be will be consulted. [[QUESTION TO REVIEWERS: it may be worthwhile to pull the last few paragraphs, along with some guidance along the same lines, into section 4, in a new sub-section with a title something like "Security tips for KARP design teams working on Routing Protocol reviews and updates". Or maybe even into its own info document, "Security Guidelines for KARP Design Teams".Thoughts?]] The mechanisms that will be defined under this roadmap aim to improve the security, better protect against more threats, and provider far greater operational efficiencies than the state of things at the time of this writing. However, none of these changes will improve Internet security unless they are implemented and deployed. Other influences must be brought to bare upon operators and organizations to create incentives for deployment. Such incentives may take the form of PCI-like industry compliance/certifications, well advertised BCPs profiling the use of this roadmap's output, end-user demand or insistance. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements The outline for this draft was created from discussions and agreements with Routing AD's Ross Callon and Dave Ward, Security AD's Tim Polk and Pasi Eronen, and IAB members Danny McPherson and Gregory Lebovitz. Mat Ford and Bill Atwood provided reviews to -00. Danny McPherson provided an extremely detailed and useful review of -01. 8. Change History (RFC Editor: Delete Before Publishing) [NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.] Lebovitz & Expires May 9, 2010 [Page 37] Internet-Draft KARP Roadmap November 2009 -00-00 original rough rough rough draft for review by routing and security AD's -00- original submission o adds new category = multicast protocols in category section and mentions mcast in group keying category description. o add a lot of references where they did not exist before, or where there were only place holders. Still more work needed on this. o abstract filled in o changed from standards track to informational (this was an oversight in last draft). o filled out threats section with detailed descriptions, and linked to RPsec threats RFC o made ascii art for the basic KMP framework o added section on internal versus external peering and the requirements decisions for them o added security characterization section in sect 2, added sections discussing internal vs external protocols, shared vs unique keys, oob vs in-band keying o incorporates all D Ward's feedback from his initial skim of the document. -01- o Updated framework (Figure 1) diagram to include all listed and described elements. Needs review and honing. Gregory Lebovitz (GL). o Added comment in protocols (Section 4.5) section that much of the BGP/LDP Phase 1 work is already being done in tcp-ao and ao- crypto. GL. o Updated Scope making the 2 work phases more clear earlier in the document. GL. o Broke work items (Section 4.4) section into two Phases, 1 for manual key update, and second for KMP work. GL. o Re-org'd doc. Brought Threats (Section 2) section out into its own top-level section. Did same with Categorization (Section 3) section, leaving Roadmap section more focused. Moved ToDo list and Change History to end of doc, after Acknowledgements. GL. o added new sect 2.3 (Section 4.1) on main roadmap phases. Previous section Common Framework (Section 4.3) moved to 2.4. Tim Polk (TP). o Added Section 2.3.1 Requirements for Phase 1 Routing Protocols' Security Update (Section 4.2). This provides a nice starter set of requirements for any work team. GL. o Filled out text for Out vs In-band Key Mgmt (Section 3.4.3) section, significantly. Changed the term from "in-band" to "in- line". Lebovitz & Expires May 9, 2010 [Page 38] Internet-Draft KARP Roadmap November 2009 o Section Threats (Section 2) Clarified DoS threats in and out of scope better. We are not preventing all DoS attacks. Just those we can reasonably via authentication. TP. o Sect In-band vs Out-of-Band (Section 3.4.3)clarified that In-band does not mean in-band to Routing Protocol, but rather over IP between the Routing Protocols, rather than pushed down by some external management entity. TP. o In roadmap (Section 3) section, added "it is also hoped that we can create one kmp per category..." Also explained value of a KMP. TP. o Added "operators" to audience (Section 1.6) list. Matt Ford (MF). o Described why BGP (and LDP) security is not deployed very often. Added this Scope (Section 1.3) section, point 4. If mechanisms aren't being deployed, why is that? What, if anything, could be done to improve deployment? Tried to address these. Need references (see To Do list below). MF. o Added some text to security section to address this from MF: say something here about the limitations of this approach, if any - and refer back to the need for other pieces of the puzzle. May need more work. o Cleaned up text for multicast part of Message Type (Section 3.1) section and Protocols (Section 4.5) section, clarifying PIM's two message types, mcast and unicast, in both places. Bill Atwood (BA). o In section Protocols (Section 4.5), added references to 4601 and PIM-SM-LINKLOCAL. BA. o Editorial changes pointed out various folks. -02- o Re-submitted due to expiration. Text did not change. Substantive update coming shortly. o o - 03 - o changed "BaseRP" to "Routing Protocol" throughout the doc - man o filled out the Terminology section o changed "KMART" to "KARP" in everything but the title, since the -00 deadline had long since passed. Will change the title of the doc to KARP as soon as the window re-opens. o priorities in sect 4.6 changed. Added PIM-SM. Lowered OSPF and BFD, based on feedback by a few people. o many edits resulting from Danny McPherson's review. o added "Brute Foce Attacks Against Password/Keys" to Threats Section 2.1 section. Lebovitz & Expires May 9, 2010 [Page 39] Internet-Draft KARP Roadmap November 2009 o Significant updates to Security Considerations section o Added a few references throughout to RFC3562 o 4.3 2nd to last P - added a comment to clarify that two parties (or an org) must discuss ahead of time what they want their connections' secruity properties to be. - dward o added to 4.4 Phase 1 - New Section: Transition and Deployment Considerations. ea wg must call out the operational transition plan from old to new security. Best if don't bounce link. - dward o added 3.3 (but not sure if this is right)- endpoint discovery mechanisms? endpoint discovery mechanism (L2VPN, L3VPN, etc). Discovery is much different security properties than passing Routing updates. - dward o More requirements: Added to 4.2: X - convergence SHOULD not be affected by what we choose; adding security SHOULD not cause a refresh of route updates or cause additional route updates to be generated; adding auth should not be an attack vector itself. AKA, the use of MD5 is so expensive that spoofing BGP packets w/ MD5 causes the control plane to be attacked because CPU went to 100% - dward o updated stats on MD5 usage, and cited [ISR2008]. - mchpherson 9. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) [NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.] List of stuff that still needs work o RTG AD's or delegates: clean up the three definitions of route message type categories. Need RTG Area folks input on this. o More clarity on the work items for those defining and specifying the framework elements and API's themselves. o RTG AD's or delegates: text justifying RSVP and RSVP-TE and what we think solving that problem may look like o RTG AD's or delegates: more justification for why MANET and FORCES are out of scope. Need ref for those RFCs. o Danny McPherson: Get reference for BGP auth usage stats in Scope (Section 1.3) section, item 4. o o security section: pull out security guidance to routing protocol design teams stuff and place into its own section? o o 10. References Lebovitz & Expires May 9, 2010 [Page 40] Internet-Draft KARP Roadmap November 2009 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007. 10.2. Informative References [I-D.ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use and Implementation Requirements for TCP Authentication Option", March 2009, . [I-D.ietf-pim-sm-linklocal] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in PIM-SM Link-local Messages", draft-ietf-pim-sm-linklocal-09 (work in progress), October 2009. [I-D.ietf-tcpm-tcp-auth-opt] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08 (work in progress), October 2009. [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure Security Report", October 2008, . [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. Lebovitz & Expires May 9, 2010 [Page 41] Internet-Draft KARP Roadmap November 2009 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC- PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Lebovitz & Expires May 9, 2010 [Page 42] Internet-Draft KARP Roadmap November 2009 Authors' Addresses Gregory Lebovitz Juniper Networks, Inc. 1194 North Mathilda Ave. Sunnyvale, CA 94089-1206 US Phone: Email: gregory.ietf@gmail.com Phone: Email: Lebovitz & Expires May 9, 2010 [Page 43] discovery process. These messages are normally exchanged prior to any adjacency being formed, and before any updates are sent. For example, end-point discovery mechanisms are common in L2VPN and L3VPN solutions. [QUESTION TO REVIEWERS: is this really just what's described in 3.1 as "Client-Server" and/or "One-to-One"? Is there really such a different in discovery protocols that they need their own category to figure out how to authenticate them? Can someone provide a few examples? 3.4. Security Characterization Vectors A few more considerations must be made about the protocol and its use when initially categorizing the protocol and scoping the authentication work. 3.4.1. Internal vs. External Operation The designers must consider whether the protocol is an internal routing protocol or an external one, i.e. Does it primarily run between peers within a single domain of control or between two different domains of control? Some protocols may be used in both cases, internally and externally, and as such various modes of authentication operation may be required for the same protocol. While it is preferred that all routing exchanges run with the utmost security mechanisms enabled in all deployments, this exhortation is greater for those protocols running on inter-domain point-to-point links, and greatest for those on shared access link layers with several different domains interchanging together, because the volume of attackers are greater from the outside. Note however that the consequences of internal attacks maybe no less severe -- in fact they may be quite a bit more severe -- than an external attack. An example of this internal versus external consideration is BGP which has both EBGP and IBGP modes. Another example is a multicast protocol where the neighbors are sometimes within a domain of control and sometimes at an inter-domain exchange point. In the case of Lebovitz & Expires May 9, 2010 [Page 18] Internet-Draft KARP Roadmap November 2009 PIM-SM running on an internal multi-access link, It would be acceptable to give up some security to get some convenience by using a group key between the peers on the link. On the other hand, in the case of PIM-SM running over a multi-access link at a public exchange point, operators may favor security over convenience by using unique pair-wise keys for every peer. Designers must consider both modes of operation and ensure the authentication mechanisms fit both. Operators are encouraged to run cryptographic authentication on all their adjacencies, but to work from the outside in, i.e. The EBGP links are a higher priority than the IBGP links because they are externally facing, and, as a result, more likely to be targeted in an attack. 3.4.2. Unique versus Shared Keys This section discusses security considerations regarding when it is appropriate to use the same authentication key inputs for multiple peers and when it is not. This is largely a debate of convenience versus security. It is often the case that the best secured mechanism is also the least convenient mechanism. For example, an air gap between a host and the network absolutely prevents remote attacks on the host, but having to copy and carry files using the "sneaker net" is quite inconvenient and unscalable. Operators have erred on the side of convenience when it comes to securing routing protocols with cryptographic authentication. Many do not use it at all. Some use it only on external links, but not on internal links. Those that do use it often use the same key for all peers across their entire network. It is common to see the same key in use for years, and that being the same key that was entered when authentication was originally configured, or the routing gear deployed. The goal for designers is to create authentication mechanisms that are easy for the operators to deploy and manage, and still use unique keys between peers (or small groups on multi-access links), and within between sessions. Operators have the impression that they NEED one key shared across the network, when in fact they do not. What they need is the relative convenience they experience from deploying cryptographic authentication with one (or few) key, compared to the inconvenience they would experience if they deployed the same authentication mechanism using unique pair-wise keys. An example is BGP Route Reflectors. Here operators often use the same authentication key between each client and the route reflector. The roadmaps defined from this guidance document will allow for unique keys to be used between each client and the peer, without sacrificing much convenience. Designers should strive to deliver peer-wise Lebovitz & Expires May 9, 2010 [Page 19] Internet-Draft KARP Roadmap November 2009 unique keying mechanisms with similar ease-of-deployment properties as today's one-key method. Operators must understand the consequences of using the same keys across many peers. Unique keys are more secure than shared keys because they reduce both the attack target size and the attack consequence size. In this context, the attack target size represents the number of unique routing exchanges across a network that an attacker may be able to observe in order to gain security association credentials, i.e. crack the keys. If a shared key is used across the entire internal domain of control, then the attack target size is very large. The larger the attack target, the easier it is for the attacker to gain access to analysis data, and greater the volume of analysis data he can access in a given time frame, both of which make his job easier. Using the same key across the network makes the attack vulnerability surface more penetrable than unique keys. Consider also the attack consequence size, the amount of routing adjacencies that can be negatively affected once a breach has occurred, i.e. once the keys have been acquired by the attacker. Again, if a shared key is used across the internal domain, then the consequence size is the whole network. Ideally, unique key pairs would be used for each adjacency. In some cases designers may need to use shared keys in order to solve the given problem space. For example, a multicast packet is sent once but then observed and consumed by several routing neighbors. If unique keys were used per neighbor, the benefit of multicast would be erased because the casting peer would have to create a different announcement packet/stream for each listening peer. Though this may be desired and acceptable in some small amount of use cases, it is not the norm. Shared group keys are an acceptable solution here, and much work has been done already in this area (see MSEC working group). 3.4.3. Out-of-Band vs. In-line Key Management This section discusses the security and use case considerations for keys placed on devices through out-of-band configurations versus through one routing peer-to-peer key management protocol exchanges. Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to the Routing Protocol. Instead, we mean that the exchange occurs in- line, over IP, between the two routing peers directly. In in-line KMP the peers themselves handle the key and security association negotiation between themselves directly, whereas in an out-of-band system the keys are placed onto the device through some other configuration or management method or interface. An example of an out-of-band mechanism could be an administrator who Lebovitz & Expires May 9, 2010 [Page 20] Internet-Draft KARP Roadmap November 2009 makes a remote management connection (e.g. using SSH) to a router and manually enters the keying information -- like the algorithm, the key(s), the lifetimes, etc. Another example could be an OSS system which inputs the same information via a script over an SSH connection, or by pushing configuration through some other management connection, standard (Netconf-based) or proprietary. The drawbacks of an out-of-band mechanism include: lack of scale- ability, complexity and speed of changing if a breach is suspected. For example, if an employee who had access to keys was was terminated, or if a machine holding those keys was belived compromised, then the system would be considered insecure and vulnerable until new keys were defined by a human. Those keys then need to be placed into the OSS system, manually, and the OSS system then needs to push the change -- often during a very limited change window -- into the relevant devices. If there are multiple organizations involved in these connections, this process is greatly complicated. The benefits of out-of-band mechanism is that once the new keys/ parameters are set in OSS system they can be pushed automatically to all devices within the OSS's domain of control. Operators have mechanisms in place for this already. In small environments with few routers, a manual system is not difficult to employ. We further define an in-line key exchange as using cryptographicly protected identity verification, session key negotiation, and security association parameter negotiation between the two routing peers. The KMP between the two peers may also include the negotiation of parameters, like algorithms, cryptographic inputs (e.g. initialization vectors), key life-times, etc. The benefits an in-line KMP are several. An in-line KMP results in key(s) that are privately generated, and not recorded permanently anywhere. Since the traffic keys used in a particular connection are not a fixed part of a device configuration no steal-able data exists anywhere else in the operator's systems which can be stolen, e.g. in the case of a terminated or turned employee. If a server or other data store is stolen or compromised, the thieves gain no access to current traffic keys. They may gain access to key derivation material, like a PSK, but not current traffic keys in use. In this example, these PSKs can be updated into the device configurations (either manually or through an OSS) without bouncing or impacting the existing session at all. In the case of using raw assymetric keys or certificates, instead of PSKs, the data theft would likely not even result in any compromise, as the key pairs would have been generated on the routers, and never leave those routers. In such a case no changes are needed on the routers; the connections will continue to Lebovitz & Expires May 9, 2010 [Page 21] Internet-Draft KARP Roadmap November 2009 be secure, uncompromised. Additionally, with a KMP regular re-keys operations occur without any operator involvement or oversight. This keeps keys fresh. The drawbacks to using a KMP are few. First, a KMP requires more cryptographic processing for the router at the very beginning of a connection. This will add some minor start-up time to connection establishment versus a purely manual key approach. Once a connection with traffic keys have been established via a KMP, the performance is the same in the KMP and the out-of-band case. KMPs also add another layer of protocol and configuration complexity which can fail or be misconfigured. This was more of an issue when these KMPs were first deployed, but less so as these implementaitons and operational experience with them has matured. The desired end goal is in-line KMPs. 4. The Roadmap 4.1. Work Phases on any Particular Protocol The desired endstate for the KARP work contains several items. First, the people desiring to deploy securely authenticated and integrity validated packets between routing peers have the tools specified, implemented and shipping in order to deploy. These tools should be fairly simple to implement, and not more complex than the security mechanisms to which the operators are already accustomed. (Examples of security mechanisms to which router operators are accustomed include: the use of assymetric keys for authentication in SSH for router configuration, the use of pre-shared keys (PSKs) in TCP MD5 for BGP protection, the use of self-signed certificates for HTTPS access to device Web-based user interfaces, the use of strongly constructed passwords and/or identity tokens for user identification when logging into routers and management systems.) While the tools that we intend to specify may not be able to stop a deployment from using "foobar" as an input key for every device across their entire routing domain, we intend to make a solid, modern security system that is not too much more difficult than that. In other words, simplicity and deployability are keys to success. The Routing Protocols will specify modern cryptographic algorithms and security mechanisms. Routing peers will be able to employ unique, pair-wise keys per peering instance, with reasonable key lifetimes, and updating those keys on a somewhat regular basis will be operationally easy, causing no service interruption. Achieving the above described end-state using manual keys may only be pragmatic in very small deployments. In larger deployments, this end Lebovitz & Expires May 9, 2010 [Page 22] Internet-Draft KARP Roadmap November 2009 state will be much more operationally difficult to reach with only manual keys. Thus, there will be a need for key life cycle management, in the form of a key management protocol, or KMP. We expect that the two forms, manual key usage and KMP usage, will co- exist in the real world. For example, a provider's edge router at a public exchange peering point will want to use a KMP for ensuring unique and fresh keys with external peers, while a manual key may be used between a provider's access edge router and each of the same provider's customer premise routers with which it peers. In accordance with the desired end state just described, we define two main work phases for each Routing Protocol: 1. Enhance the Routing Protocol's current authentication mechanism. This work involves enhancing a Routing Protocol's current security mechanisms in order to achieve a consistent, modern level of security functionality within its existing keying framework. It is understood and accepted that the existing keying frameworks are largely based on manual keys. Since many operators have already built operational support systems (OSS) around these manual key implementations, there is some automation available for an operator to leverage in that way, if the underlying mechanisms are themselves secure. In this phase, we explicitly exclude embedding or creating a KMP. A list of the requirements for Phase 1 work are below in the section "Requirements for Phase 1 Routing Protocols' Security Updates (Section 4.2). 2. Develop an automated keying framework. The second phase will focus on the development of an automated keying framework to faciliate unique pair-wise (or perhaps group-wise, where applicable) keys per peering instance. This involves the use of a KMP. A KMP is helpful because it negotiates unique, pair wise, random keys without administrator involvement. It also negotiates several of the SA parameters required for the secure connection, including key life times. It keeps track of those lifetimes using counters, and negotiates new keys and parameters before they expire, again, without administrator interaction. Additionally, in the event of a breach, changing the KMP key will immediately cause a rekey to occur for the Traffic Key, and those new Traffic Keys will be installed and used in the current connection. In summary, a KMP provides a protected channel between the peers through which they can negotiate and pass important data required to exchange proof of key identifiers, derive Traffic Keys, determine re-keying, synchronize their keying state, signal various keying events, notify with error messages, etc. To address brute force attacks [RFC3562] recommends a key management practice to minimize the possibility Lebovitz & Expires May 9, 2010 [Page 23] Internet-Draft KARP Roadmap November 2009 of successful attack-- frequent key rotation, limited key sharing, key length restrictions, etc. Advances in computational power due to Moore's law are making that management burden untenable-- keys must be of a size and composition that makes configuration and maintance difficult or keys must be rotated with an unreasonable frequency. A KMP will help immensely with this growing problem. The framework for any one Routing Protocol will fall under, and be able to leverage, the generic framework described below in section Section 4.3. 4.2. Requirements for Phase 1 Routing Protocols' Security Update Here is a proposed list of requirements that SHOULD be addressed by Phase 1 (according to "1." above) security updates to Routing Protocols [to be reviewed after -01 is released]: 1. Clear definitions of which elements of the transmission (frame, packet, segment, etc.) are protected by the authentication mechanism 2. Strong algorithms, and defined and accepted by the security community, MUST be specified. The option should use algorithms considered accepted by the security community, which are considered appropriately safe. The use of non-standard or unpublished algorithms SHOULD BE avoided. 3. Algorithm agility for the cryptograhpic algorithms used in the authentication MUST be specified, i.e. more than one algorithm MUST be specified and it MUST be clear how new algorithms MAY be specified and used within the protocol. This requirement exists in case one algorithm gets broken suddenly. Research to identify weakness in algorithms is constant. Breaking a cipher isn't a matter of if, but when it will occur. t's highly unlikely that two different algorithms will be broken simultaneously. So, if two are supported, and one gets broken, we can use the other until we get a new one in place. Having the ability within the protocol specification to support such an event, having algorithm agility, is essential. Mandating two algorithms provides both a redundancy, and a mechanism for enacting that redundancy when needed. 4. Secure use of simple PSKs, offering both operational convenience as well as building something of a fence around stupidity, MUST be specified. 5. Inter-connection replay protection. Packets captured from one connection MUST NOT be able to be re-sent and accepted during a later connection. Lebovitz & Expires May 9, 2010 [Page 24] Internet-Draft KARP Roadmap November 2009 6. Intra-connection replay protection. Packets captured during a connection MUST NOT be able to be re-sent and accepted during that same connection, to deal with long-lived connections. 7. A change of security parameters REQUIRES, and even forces, a change of session traffic keys 8. Intra-connection re-keying which occurs without a break or interruption to the current peering session, and, if possible, without data loss, MUST be specified. 9. Efficient re-keying SHOULD be provided. The specificaion SHOULD support rekeying during a connection without the need to expend undue computational resources. In particular, the specification SHOULD avoid the need to try/compute multiple keys on a given packet. 10. Prevent DoS attacks as those described as in-scope in the threats section Section 2.1 above. 11. Default mechanisms and algorithms specified and defined as REQUIRED for all implementations 12. Manual keying MUST be supported. 13. Convergence times of the Routing Protocols SHOULD NOT be materially affected. Materially here is defined as anything greater than a 5% convergence time increase. Note that convergence is different than boot time. Also note that convergence time has a lot to do with the speed of processors used on individual routing peers, and this increases by Moore's law over time. Therefore, this requirement should be considered only in terms of total number of messages that must be exchanged, and less for the computational intensity of processing any one message. 14. The changes or addition of security mechanisms SHOULD NOT cause a refresh of route updates or cause additional route updates to be generated 15. Architecture of the specification MUST consider and allow for future use of a KMP. 4.3. Common Framework Each of the categories of routing protocols above will require unique designs for authenticating and integrity checking their protocols. However, a single underlying framework for delivering automatic keying to those solutions will be pursued. Providing such a single framework will significantly reduce the complexity of each step of the overall roadmap. For example, if each Routing Protocol needed to define it's own key management protocol this would balloon the total amount of different sockets that are needed to be opened and processes that are needed to be simultaneously running on an implementation. It would also significantly increase the run-time complexity and memory requirements of such systems running multiple Routing Protocols, causing perhaps slower performance of such Lebovitz & Expires May 9, 2010 [Page 25] Internet-Draft KARP Roadmap November 2009 systems. However, if we can land on a very small set (perhaps one or two) of automatic key management protocols, KMPs, that the various Routing Protocols can use, then we can reduce this implementation and run-time complexity. We can also decrease the total amount of time implementers need to deliver the KMPs for the Routing Protocols that will provide better threat protection. The components for the framework are listed here, and described below: o Routing Protocol security mechanism o KMP o KeyStore o Traffic Key o RoutingProtocol-to-KMP API o RoutingProtocol-to-KeyStore API o KMP-to-KeyStore API o Common Routing Protocol mechanisms o Identifiers o Proof of identity o Profiles The framework is modularized for how keys and security association (SA) parameters generally get passed from a KMP to a transport protocol. It contains three main blocks and APIs. Lebovitz & Expires May 9, 2010 [Page 26] Internet-Draft KARP Roadmap November 2009 +------------+ +--------------------+ | | | | Check +-----------+ | Identifier +-->| +---------->| | | | | KMP Function | | Identity | +----------- + | |<----------+ Proof | | | Approve | | +-+--------------+---+ +-----------+ | | KMP-to-KeyStore | | API | | \|/ | +-------+-------+ | | | | KMP-to-RoutingProtocol | | | API | KeyStore | | | | | +-------+-------+ | | | | | KeyStore-to- | | RoutingProtocol API | | | \|/ +--------------------------+-------------+ | | | | \|/ Common RtgProto | | +-------+-------+ Authentication | | | | Mechanisms | +---| Traffic |-----+--------------+ | | Key(s) | | | | | | | +---------------+ Specific | | RoutingProtocol | | Authentication | | Security | | Mechanism | +----------------------------------------+ Figure 1: Automatic Key Management Framework Each element of the framework is described here: o Routing Protocol - Routing protocol security mechanism - In each case, the Routing Protocol will contain a mechanism for using session keys in their security option. When the Routing Protocol uses a transport substrate, e.g. the way BGP, LDP and MSDP use TCP, then this applies to the security mechanism Lebovitz & Expires May 9, 2010 [Page 27] Internet-Draft KARP Roadmap November 2009 the includes that substrate. o KeyStore - Each implementation will also contain a protocol independent mechanism for storing keys, called KeyStore. The KeyStore will have multiple different logical containers, one container for each session key that any given Routing Protocol will need. Keys stored here may be a Peer Key or a Traffic Key. There may also be associated parameters as required by the SA for any given Routing Protocol. o Peer Key A key used between peers from which a traffic key is derived. An example is a PSK. o Traffic Key The actual key used on each packet of a message. This key may be derived from the key existing in the KeyStore. This will depend on whether the key in KeyStore was a manual PSK for the peers, or whether a connection-aware KMP created the key. Further, it will be connection specific, so as to provide inter- and intra-connection replay protection. o RoutingProtocol-KeyStore API - There will be an API for Routing Protocol to retrieve (or receive; it could be a push or a pull) the keys from the KeyStore. This will enable implementers to reuse the same API calls for all their Routing Protocols. The API will necessarily include facility to retrieve other SA parameters required for the construction of the Routing Protocol's packets, like key IDs or key lifetimes, etc. o KMP - There will be an automated key management protocol, KMP. This KMP will run between the peers. The KMP serves as a protected channel between the peers, through which they can negotiate and pass important data required to exchange proof of key identifiers, derive session keys, determine re-keying, synchronize their keying state, signal various keying events, notify with error messages, etc. As an analogy, in the IPsec protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306 [RFC4306]) IKEv2 is the KMP that runs between the two peers, while AH and ESP are two different base protocols that take session keys from IKEv2 and use them in their transmissions. In the analogy, the Routing Protocol, say BGP and LDP, are analogous to ESP and AH, while the KMP is analogous to IKEv2 itself. Lebovitz & Expires May 9, 2010 [Page 28] Internet-Draft KARP Roadmap November 2009 o RoutingProtocol-KMP API - There will be an API for the Routing Protocol to request a session key of the KMP, and be notified when the keys are available for it. The API will also contain a mechanism for the KMP to notify the Routing Protocol that there are new keys that it must now use, even if it didn't request those keys. The API will also include a mechanism for the KMP to receive requests for session keys and other parameters from the routing protocol. The KMP will also be aware of the various Routing Protocols and each of their unique parameters that need to be negotiated and returned. o KMP-KeyStore API - There will be an API for the KMP to place keys and parameters into the KeyStore after their negotiation and derivation with the other peer. This will enable the implementers to reuse the same calls for multiple KMPs that may be needed to address the various categories of Routing Protocols as described in the section definingcategories (Section 3). [after writing this all up, I'm not sure we really need the key_store in the middle. As long as we standardize fully all the calls needed from any Routing Protocol to any KMP, then there can be a generic hand-down function from the KMP to the Routing Protocol when the key and parameters are ready. Let's sleep on it.] [will need state machines and function calls for these APIs, as one of the work items. In essence, there is a need for a core team to develop the APIs out completely in order for the Routing Protocol teams to use them. Need to get this team going asap.] o Identifiers - A KMP is fed by identities. The identities are text strings used by the peers to indicate to each other that each are known to the other, and authorized to establish connections. Those identities must be represented in some standard string format, e.g. an IP address -- either v4 or v6, an FQDN, an RFC 822 email address, a Common Name [RFC PKI], etc. Note that even though routers do not normally have email addresses, one could use an RFC 822 email address string as a formatted identifier for a router. They would do so simply by putting the router's reference number or name- code as the "NAME" part of the address, left of the "@" symbol. They would then place some locational context in the "DOMAIN" part of the string, right of the "@" symbol. An example would be "rtr0210@sf.ca.us.company.com". This Lebovitz & Expires May 9, 2010 [Page 29] Internet-Draft KARP Roadmap November 2009 document does not suggest this string value at all. Instead, the concept is used only to clarify that the type of string employed does not matter. It also does not matter what specific text you chose to place in that string type. It only matters that the type of string -- and it's format -- must be agreed upon by the two endpoints. Further, the string can be used as an identifier in this context, even if the string is not actually provisioned in it's source domain. For example, the email address "rtr0210@sf.ca.us.company.com" may not actually exist as an email address in that domain, but that string of characters may still be used as an identifier type(s) in the routing protocol security context. What is important is that the community decide on a small but flexible set of Identifiers they will all support, and that they decide on the exact format of those string. The formats that will be used must be standardized and must be sensible for the routing infrastructure. o Identity Proof - Once the form of identity is decided, then there must be a cryptographic proof of that identity, that the peer really is who they assert themselves to be. Proof of identity can be arranged between the peers in a few ways, for example pre-shared keys, raw assymetric keys, or a more user-friendly representation of assymetric keys, like a certificate. Certificates can be used in a way requiring no additional supporting systems -- e.g. public keys for each peer can be maintained locally for verification upon contact. Certificate management can be made more simple and scalable with the use minor additional supporting systems, as is the case with self-signed certificates and a flat file list of "approved thumbprints". Self-signed certificates will have somewhat lower security properties than Certificate Authority signed certificates [RFC Certs]. The use of these different identity proofs vary in ease of deployment, ease of ongoing management, startup effort, ongoing effort and management, security strength, and consequences from loss of secrets from one part of the system to the rest of the system. For example, they differ in resistance to a security breach, and the effort required to remediate the whole system in the event of such a breach. The point here is that there are options, many of which are quite simple to employ and deploy. o Profiles - Once the KMP, Identifiers and Proofs mechanisms are converged upon, they must be clearly profiled for each Routing Protocol, so that implementors and deployers alike understand the different pieces of the solution, and can have similar configurations and interoperability across multiple vendors' devices, so as to reduce management difficulty. The Lebovitz & Expires May 9, 2010 [Page 30] Internet-Draft KARP Roadmap November 2009 profiles SHOULD also provide guidance on when to use which various combinations of options. This will, again, simplify use and interoperability. In addition to other business, administrative, and operational terms they must already exchange prior to forming first adjacencies, it is assumed that two parties deploying message authentication on their routing protocol will also need to decide upon acceptable security parameters for the connection. This will include the form and content of the identity each use to represent the other. It will also include the type of keys to be used, e.g. PSK, raw assymetric keys, certificate. And it will include the acceptable cryptographic algorithms, or algorithm suite. This agreement is necessary in order for each to properly configure the connection on their respective devices. The manner in which they agree upon and exchange this policy information is normally via phone call or written exchange, and is outside the scope of the KARP effort, but assumed to have occured. We take as a given that each party knows the identity types and values, key types and values, and acceptable cryptographic algorithms for both their own device and the peer that form the security policy for configuration on their device. Common Mechanisms - In as much as they exist, the framework will capture mechanisms that can be used commonly not only within a particular category of Routing Protocol and Routing Protocol to KMP, but also between Routing Protocol categories. Again, the goal here is simplifying the implementations and runtime code and resource requirements. There is also a goal here of favoring well vetted, reviewed, operationally proven security mechanisms over newly brewed mechanisms that are less well tried in the wild. 4.4. Work Items Per Routing Protocol Each Routing Protocol will have a team (the [Routing_Protocol]-KARP team) working on incrementally improving their Routing Protocol's security, These teams will have the following main work items: PHASE 1: Characterize the RP Assess the Routing Protocol to see what authentication mechanisms it has today. Does it needs significant improvement to its existing mechanisms or not? This will include determining if modern, strong security algorithms and parameters are present. Lebovitz & Expires May 9, 2010 [Page 31] Internet-Draft KARP Roadmap November 2009 Define Optimal State List the requirements for the Routing Protocol's session key usage and format to contain to modern, strong security algorithms and mechanisms, per the Requirements (Section 4.2) section above. The goal here is to determine what is needed for they Routing Protocol alone to be used securely with at least manual keys. Gap Analysis Enumerate the requirements for this protocol to move from its current security state, the first bullet, to its optimal state, as listed just above. Transition and Deployment Considerations Document the operational transition plan for moving from the old to the new security mechanism. Will adjacencies need to bounce? What new elements/ servers/services in the infrastructure will be required? What is an example work flow that an operator will take? The best possible case is if the adjacency does not break, but this may not always be possible. Define, Assign, Design Create a deliverables list of the design and specification work, with milestones. Define owners. Release a document(s) PHASE 2: KMP Analysis Review requirements for KMPs [RFC????]. Identify any nuances for this particular protocol's needs and its use cases for KMP. List the requirements that this Routing Protocol has for being able to be use in conjunctions with a KMP. Define the optimal state. Gap Analysis Enumerate the requirements for this protocol to move from its current security state to its optimal state. Define, Assign, Design Create a deliverabels list of the design and specification work, with miletsones. Define owners. Do the design and document work for a KMP to be able to generate the Routing Protocol's session keys for the packets on the wire. These will be the arguments passed in the API to the KMP in order to bootstrap the session keys to the Routing Protocol. There will also be a team formed to work on the base framework mechanisms for each of the main categories, i.e. the blocks and API's Lebovitz & Expires May 9, 2010 [Page 32] Internet-Draft KARP Roadmap November 2009 represented in figure 1 (Figure 1). 4.5. Protocols in Categories This section groups the Routing Protocols into like categories, according to attributes set forth in Categories Section (Section 3). Each group will have a design team tasked with improving the security of the Routing Protocol mechanisms and defining the KMP requirements for their group, then rolling both into a roadmap document upon which they will execute. BGP, LDP and MSDP The Routing Protocol's that fall into the category of the one-to- one peering messages, and will use peer keying protocols, AND are all transmitted over TCP include BGP RFC 4271 [RFC4271], LDP [RFC5036] and MSDP [RFC3618]. A team will work on one mechanism to cover these three protocols. Much of the work on the Routing Protocol update for its existing authentication mechanism is already occuring in the TCPM Working Group, on the TCP-AO [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto]. The exception is the mode where LDP is used directly on the LAN [RFC????]. The work for this may go into the Group keying category (w/ OSPF) mentioned below. OSPF, ISIS, and RIP The Routing Protocols that fall into the category Group keying with one-to-many peering messages includes OSPF [RFC2328], ISIS [RFC1195] and RIP [RFC2453]. Not surprisingly, all these routing protocols have two other things in common. First, they are run on a combination of the OSI datalink layer 2, and the OSI network layer 3. By this we mean that they have a component of how the routing protocol works which is specified in Layer 2 as well as in Layer 3. Second, they are all internal gateway protocols, or IGPs. The keying mechanisms and use will be much more complicated to define for these than for a one-to-one messaging protocol. BFD Because it is less of a routing protocol, per se, and more of a peer aliveness detection mechanism, Bidirectional Forwarding Detection (BFD) [RFC????] will have its own team. RSVP [RFC????], RSVP-TE [RFC????], and PCE Lebovitz & Expires May 9, 2010 [Page 33] Internet-Draft KARP Roadmap November 2009 These three protocols will be handled together. [what more characterisation should we give here? Routing AD's, provide text pls?] PIM-SM and PIM-DM Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM [RFC3973] will be handled together. PIM-SM multicasts routing information (Hello, Join/Prune, Assert) on a link-local basis, using a defined multicast address. In addition, it specifies unicast communication for exchange of information (Register, Register-Stop) between the router closest to a group sender and the "rendezvous point" (RP). The RP is typically not "on-link" for a particular router. While much work has been done on multicast security for application-layer groups, little has been done to address the problem of managing hundreds or thousands of small one-to-many groups with link-local scope. Such an authentication mechanism should be considered along with the router-to-Rendezvous Point authentication mechanism. The most important issue is ensuring that only the "authorized neighbors" get the keys for (S,G), so that rogue routers cannot participate in the exchanges. Another issue is that some of the communication may occur intra-domain, e.g. the link-local messages in an enterprise, while others for the same (*,G) may occur inter-domain, e.g. the router-to-Rendezvous Point messges may be from one enterprise's router to another. One possible solution proposes a region-wide "master" key server (possibly replicated), and one "local" key server per speaking router. There is no issue with propagating the messages outside the link, because link-local messages, by definition, are not forwarded. This solution is offered only as an example of how work may progress; further discussion should occur in this work team. Specification of a link-local protection mechanism for PIM-SM occurred in RFC 4601 [RFC4601], and this work is being updated in PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal]. However, the KMP part is completely unspecified, and will require work outside the expertise of the PIM working group to accomplish, which is why this roadmap is being created. These protocols are deemed out-of-scope for this current iteration of the work roadmap. Once all of the protocols listed above have had their work completed, or are clearly within site of completion, then the community will revisit the need and interest for working on these: o MANET o FORCES [need text from routing ADs on why these are out of scope] Lebovitz & Expires May 9, 2010 [Page 34] Internet-Draft KARP Roadmap November 2009 4.6. Priorites Resources from both the routing area and the security area will be applied to work on these problem spaces as quickly as possible. Realizing that such resources are far from unlimited, a rank order priority for addressing the work of incrementally securing these groups of routing protocols is provided: o Priority 1 - BGP / LDP / MSDP - almost done with Phase 1 on these, via TCP-AO [I-D.ietf-tcpm-tcp-auth-opt] . o Priority 2 - PIM-SM o Priority 3 - OSPF / ISIS / RIP o Priority 4 - BFD o Priority 5 - RSVP and RSVP-TE By far the most important group is the Priority 1 group as these are the protocols used on the most public and exposed segments of the networks, at the peering points between operators and between operators and their customers. BFD, as a detection mechanism underlying the Priority 1 protocols is therefore second. 5. Security Considerations As mentioned in the Introduction , RFC4948 identifies additional steps needed to achieve the overall goal of improving the security of the core routing infrastructure. Those include validation of route origin announcements, path validation, cleaning up the IRR databases for accuracy, and operational security practicies that prevent routers from being compromised devices. The KARP work is but one step in a necessary system of security improvements. The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness. In addition to using a stong key/PSK of appropriate length and randomness, deployers of KARP protocols SHOULD use different keys between different routing peers whenever operationally possible. RFC3562 [RFC3562] provides some very sound guidance. It was meant Lebovitz & Expires May 9, 2010 [Page 35] Internet-Draft KARP Roadmap November 2009 specifically for the use of TCP MD5 for BGP, but it is more or less applicable to Routing Protocol authentication work that would result from KARP. It states three main points: (1) key lengths SHOULD be between 12 and 24 bytes (this will vary depending on the MAC/KDF in use), with larger keys having effectively zero additional computational costs when compared to shorter keys, (2) key sharing SHOULD be limited so that keys aren't shared among multiple BGP peering arrangements, and (3) Keys SHOULD be changed at least every 90 days (this could be longer for stronger MAC algorithms, but it is generally a wise idea). This is especially true when the Routing Protocol takes a static Traffic Key as opposed to a Traffic Key derived per-connection by a KDF. The burdon for doing so is understandable much higher than for using the same static Traffic Key across all peering routers. This is why use of a KMP network-wide increases peer-wise security so greatly, because now each set of peers can enjoys a unique Traffic Key, and if an attacker sitting between two routers learns or guesses the Traffic Key for that connection, she doesn't gain access to all the other connections as well. However, whenever using manual keys, it is best to design a system where a given PSK will be used in a KDF, mixed with connection specific material, in order to generate session unique -- and therefore peer-wise -- Traffic Keys. Doing so has the following advantages: the Traffic Keys used in the per-message MAC operation are peer-wise unique, it provides inter-connection replay protection, and, if the per-message MAC covers some connection counter, intra- connection replay protection. Note that in the composition of certain key derivation functions (e.g. KDF_AES_128_CMAC, as used in TCP-AO [I-D.ao-crypto]), the pseudorandom function (PRF) used in the KDF may require a key of a certain fixed size as an input. For example, AES_128_CMAC requires a 128 bit (16 byte) key as the seed. However, for convenience to the administrators/deployers, a specification may not want to force the deployer to enter a PSK of exactly 16 bytes. Instead, a specification may call for a sub-key routine that could handle a variable length PSK, one that might be less than 16 bytes (see [RFC4615], section 3, as an example). That sub-key routine would act as a key extractor to derive a second key of exactly the required length, and thus suitable as a seed to the PRF. This does NOT mean that administrators are safe to use weak keys. Administrators are encouraged to follow [RFC4086] as listed above. We simply attempted to "put a fence around stupidity", in as much as possible. A better option, from a security perspective, is to use some representation of a device-specific assymetric key pair as the Lebovitz & Expires May 9, 2010 [Page 36] Internet-Draft KARP Roadmap November 2009 identity proof, as described in Section 3.4.2. When it comes time for the KARP WG to design the re-usable model for a KMP, The Guidelines for Cryptographic Key Management, RFC4107 [RFC4107] should be will be consulted. [[QUESTION TO REVIEWERS: it may be worthwhile to pull the last few paragraphs, along with some guidance along the same lines, into section 4, in a new sub-section with a title something like "Security tips for KARP design teams working on Routing Protocol reviews and updates". Or maybe even into its own info document, "Security Guidelines for KARP Design Teams".Thoughts?]] The mechanisms that will be defined under this roadmap aim to improve the security, better protect against more threats, and provider far greater operational efficiencies than the state of things at the time of this writing. However, none of these changes will improve Internet security unless they are implemented and deployed. Other influences must be brought to bare upon operators and organizations to create incentives for deployment. Such incentives may take the form of PCI-like industry compliance/certifications, well advertised BCPs profiling the use of this roadmap's output, end-user demand or insistance. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements The outline for this draft was created from discussions and agreements with Routing AD's Ross Callon and Dave Ward, Security AD's Tim Polk and Pasi Eronen, and IAB members Danny McPherson and Gregory Lebovitz. Mat Ford and Bill Atwood provided reviews to -00. Danny McPherson provided an extremely detailed and useful review of -01. 8. Change History (RFC Editor: Delete Before Publishing) [NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.] Lebovitz & Expires May 9, 2010 [Page 37] Internet-Draft KARP Roadmap November 2009 -00-00 original rough rough rough draft for review by routing and security AD's -00- original submission o adds new category = multicast protocols in category section and mentions mcast in group keying category description. o add a lot of references where they did not exist before, or where there were only place holders. Still more work needed on this. o abstract filled in o changed from standards track to informational (this was an oversight in last draft). o filled out threats section with detailed descriptions, and linked to RPsec threats RFC o made ascii art for the basic KMP framework o added section on internal versus external peering and the requirements decisions for them o added security characterization section in sect 2, added sections discussing internal vs external protocols, shared vs unique keys, oob vs in-band keying o incorporates all D Ward's feedback from his initial skim of the document. -01- o Updated framework (Figure 1) diagram to include all listed and described elements. Needs review and honing. Gregory Lebovitz (GL). o Added comment in protocols (Section 4.5) section that much of the BGP/LDP Phase 1 work is already being done in tcp-ao and ao- crypto. GL. o Updated Scope making the 2 work phases more clear earlier in the document. GL. o Broke work items (Section 4.4) section into two Phases, 1 for manual key update, and second for KMP work. GL. o Re-org'd doc. Brought Threats (Section 2) section out into its own top-level section. Did same with Categorization (Section 3) section, leaving Roadmap section more focused. Moved ToDo list and Change History to end of doc, after Acknowledgements. GL. o added new sect 2.3 (Section 4.1) on main roadmap phases. Previous section Common Framework (Section 4.3) moved to 2.4. Tim Polk (TP). o Added Section 2.3.1 Requirements for Phase 1 Routing Protocols' Security Update (Section 4.2). This provides a nice starter set of requirements for any work team. GL. o Filled out text for Out vs In-band Key Mgmt (Section 3.4.3) section, significantly. Changed the term from "in-band" to "in- line". Lebovitz & Expires May 9, 2010 [Page 38] Internet-Draft KARP Roadmap November 2009 o Section Threats (Section 2) Clarified DoS threats in and out of scope better. We are not preventing all DoS attacks. Just those we can reasonably via authentication. TP. o Sect In-band vs Out-of-Band (Section 3.4.3)clarified that In-band does not mean in-band to Routing Protocol, but rather over IP between the Routing Protocols, rather than pushed down by some external management entity. TP. o In roadmap (Section 3) section, added "it is also hoped that we can create one kmp per category..." Also explained value of a KMP. TP. o Added "operators" to audience (Section 1.6) list. Matt Ford (MF). o Described why BGP (and LDP) security is not deployed very often. Added this Scope (Section 1.3) section, point 4. If mechanisms aren't being deployed, why is that? What, if anything, could be done to improve deployment? Tried to address these. Need references (see To Do list below). MF. o Added some text to security section to address this from MF: say something here about the limitations of this approach, if any - and refer back to the need for other pieces of the puzzle. May need more work. o Cleaned up text for multicast part of Message Type (Section 3.1) section and Protocols (Section 4.5) section, clarifying PIM's two message types, mcast and unicast, in both places. Bill Atwood (BA). o In section Protocols (Section 4.5), added references to 4601 and PIM-SM-LINKLOCAL. BA. o Editorial changes pointed out various folks. -02- o Re-submitted due to expiration. Text did not change. Substantive update coming shortly. o o - 03 - o changed "BaseRP" to "Routing Protocol" throughout the doc - man o filled out the Terminology section o changed "KMART" to "KARP" in everything but the title, since the -00 deadline had long since passed. Will change the title of the doc to KARP as soon as the window re-opens. o priorities in sect 4.6 changed. Added PIM-SM. Lowered OSPF and BFD, based on feedback by a few people. o many edits resulting from Danny McPherson's review. o added "Brute Foce Attacks Against Password/Keys" to Threats Section 2.1 section. Lebovitz & Expires May 9, 2010 [Page 39] Internet-Draft KARP Roadmap November 2009 o Significant updates to Security Considerations section o Added a few references throughout to RFC3562 o 4.3 2nd to last P - added a comment to clarify that two parties (or an org) must discuss ahead of time what they want their connections' secruity properties to be. - dward o added to 4.4 Phase 1 - New Section: Transition and Deployment Considerations. ea wg must call out the operational transition plan from old to new security. Best if don't bounce link. - dward o added 3.3 (but not sure if this is right)- endpoint discovery mechanisms? endpoint discovery mechanism (L2VPN, L3VPN, etc). Discovery is much different security properties than passing Routing updates. - dward o More requirements: Added to 4.2: X - convergence SHOULD not be affected by what we choose; adding security SHOULD not cause a refresh of route updates or cause additional route updates to be generated; adding auth should not be an attack vector itself. AKA, the use of MD5 is so expensive that spoofing BGP packets w/ MD5 causes the control plane to be attacked because CPU went to 100% - dward o updated stats on MD5 usage, and cited [ISR2008]. - mchpherson 9. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) [NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.] List of stuff that still needs work o RTG AD's or delegates: clean up the three definitions of route message type categories. Need RTG Area folks input on this. o More clarity on the work items for those defining and specifying the framework elements and API's themselves. o RTG AD's or delegates: text justifying RSVP and RSVP-TE and what we think solving that problem may look like o RTG AD's or delegates: more justification for why MANET and FORCES are out of scope. Need ref for those RFCs. o Danny McPherson: Get reference for BGP auth usage stats in Scope (Section 1.3) section, item 4. o o security section: pull out security guidance to routing protocol design teams stuff and place into its own section? o o 10. References Lebovitz & Expires May 9, 2010 [Page 40] Internet-Draft KARP Roadmap November 2009 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007. 10.2. Informative References [I-D.ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use and Implementation Requirements for TCP Authentication Option", March 2009, . [I-D.ietf-pim-sm-linklocal] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in PIM-SM Link-local Messages", draft-ietf-pim-sm-linklocal-09 (work in progress), October 2009. [I-D.ietf-tcpm-tcp-auth-opt] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08 (work in progress), October 2009. [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure Security Report", October 2008, . [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. Lebovitz & Expires May 9, 2010 [Page 41] Internet-Draft KARP Roadmap November 2009 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC- PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Lebovitz & Expires May 9, 2010 [Page 42] Internet-Draft KARP Roadmap November 2009 Authors' Addresses Gregory Lebovitz Juniper Networks, Inc. 1194 North Mathilda Ave. Sunnyvale, CA 94089-1206 US Phone: Email: gregory.ietf@gmail.com Phone: Email: Lebovitz & Expires May 9, 2010 [Page 43] +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_448520953==.ALT Content-Type: text/html; charset="us-ascii" Hey all,
I just finished an update to the document. It is attached, and pasted below.

The Chairs will put the link to the email archive page of this message in the BoF page, and BoF Agenda page too, so that people can find the document easily. We'll get it posted to I-D repository as soon as the window opens on Monday.

Editor's Note on "KMART" vs "KARP": The first few versions of this document were called "draft-lebovitz-kmart-roadmap-xx".  Upon the creation of the BoF for IETF76, the IESG requested the name of the effort change so as to avoid any potential trademark issues.  The new name of the effort is KARP.  Version -03 will go out titled with the old KMART "draft-lebovitz-kmart-roadmap-03", so as to avoid confusion, but within the document text you'll find s/kmart/karp/.  As soon as the I-D editor queue opens again (Monday, 09 Nov) the document will be submitted with s/kmart/karp/ in the title too.

Also, we are well aware that the current draft is very much a catch-all. That was by design. We will be breaking up this document into a few smaller docs, post Hiroshima, something like:

  - Guidance to Routing Protocol Authentication Design Teams
  - Threats
  - Requirements (maybe combined with threats?)
  - Framework

So please be thinking as you review it if you would like to co-author any of those documents. I'll probably keep lead editor role on the Framework document, and maybe one other, but invite co-editors even on those.

See you soon,
Gregory.
= = = = BEGIN PASTE OF DOCUMENT = = = =



KARP                                                         G. Lebovitz
Internet-Draft                                                   Juniper
Intended status: Informational                         November 05, 2009
Expires: May 9, 2010


Roadmap for Cryptographic Authentication of Routing Protocol Packets on
                                the Wire
                    draft-lebovitz-kmart-roadmap-03

Abstract

   In the March of 2006 the IAB held a workshop on the topic of
   "Unwanted Internet Traffic".  The report from that workshop is
   documented in RFC 4948 [RFC4948].  Section 8.2 of RFC 4948 calls for
   "[t]ightening the security of the core routing infrastructure."  Four
   main steps were identified for improving the security of the routing
   infrastructure.  One of those steps was "securing the routing
   protocols' packets on the wire."  One mechanism for securing routing
   protocol packets on the wire is the use of per-packet cryptographic
   message authentication, providing both peer authentication and
   message integrity.  Many different routing protocols exist and they
   employ a range of different transport subsystems.  Therefore there
   must necessarily be various methods defined for applying
   cryptographic authentication to these varying protocols.  Many
   routing protocols already have some method for accomplishing
   cryptographic message authentication.  However, in many cases the
   existing methods are dated, vulnerable to attack, and/or employ
   cryptographic algorithms that have been deprecated.  This document
   creates a roadmap of protocol specification work for the use of
   modern cryptogrpahic mechanisms and algorithms for message
   authentication in routing protocols.  It also defines the framework
   for a key management protocol that may be used to create and manage
   session keys for message authentication and integrity.  This roadmap
   reflects the input of both the security area and routing area in
   order to form a jointly agreed upon and prioritized work list for the
   effort.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.




Lebovitz &                 Expires May 9, 2010                  [Page 1]

Internet-Draft                KARP Roadmap                 November 2009


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 9, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.
























Lebovitz &                 Expires May 9, 2010                  [Page 2]

Internet-Draft                KARP Roadmap                 November 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.4.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     1.5.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . . 11
     1.6.  Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12
   2.  Threats  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     2.1.  Threats In Scope . . . . . . . . . . . . . . . . . . . . . 13
     2.2.  Threats Out of Scope . . . . . . . . . . . . . . . . . . . 15
   3.  Categorizing Routing Protocols . . . . . . . . . . . . . . . . 16
     3.1.  Category: Messaging Transaction Type . . . . . . . . . . . 16
     3.2.  Category: Peer vs. Group Keying  . . . . . . . . . . . . . 17
     3.3.  Category:  Update vs. Discovery Protocol . . . . . . . . . 18
     3.4.  Security Characterization Vectors  . . . . . . . . . . . . 18
       3.4.1.  Internal vs. External Operation  . . . . . . . . . . . 18
       3.4.2.  Unique versus Shared Keys  . . . . . . . . . . . . . . 19
       3.4.3.  Out-of-Band vs. In-line Key Management . . . . . . . . 20
   4.  The Roadmap  . . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.1.  Work Phases on any Particular Protocol . . . . . . . . . . 22
     4.2.  Requirements for Phase 1 Routing Protocols' Security
           Update . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     4.3.  Common Framework . . . . . . . . . . . . . . . . . . . . . 25
     4.4.  Work Items Per Routing Protocol  . . . . . . . . . . . . . 31
     4.5.  Protocols in Categories  . . . . . . . . . . . . . . . . . 33
     4.6.  Priorites  . . . . . . . . . . . . . . . . . . . . . . . . 35
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
   8.  Change History (RFC Editor: Delete Before Publishing)  . . . . 37
   9.  Needs Work in Next Draft (RFC Editor: Delete Before
       Publishing)  . . . . . . . . . . . . . . . . . . . . . . . . . 40
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 41
     10.2. Informative References . . . . . . . . . . . . . . . . . . 41
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42













Lebovitz &                 Expires May 9, 2010                  [Page 3]

Internet-Draft                KARP Roadmap                 November 2009


1.  Introduction

   In March 2006 the Internet Architecture Board (IAB) held a workshop
   on the topic of "Unwanted Internet Traffic".  The report from that
   workshop is documented in RFC 4948 [RFC4948].  Section 8.1 of that
   document states that "A simple risk analysis would suggest that an
   ideal attack target of minimal cost but maximal disruption is the
   core routing infrastructure."  Section 8.2 calls for "[t]ightening
   the security of the core routing infrastructure."  Four main steps
   were identified for that tightening:

   o  More secure mechanisms and practices for operating routers.  This
      work is being addressed in the OPSEC Working Group.
   o  Cleaning up the Internet Routing Registry repository [IRR], and
      securing both the database and the access, so that it can be used
      for routing verifications.  This work should be addressed through
      liaisons with those running the IRR's globally.
   o  Specifications for cryptographic validation of routing message
      content.  This work will likely be addressed in the SIDR Working
      Group.
   o  Securing the routing protocols' packets on the wire

   This document addresses the last bullet, securing the packets on the
   wire of the routing protocol exchanges.  The document addresses
   Keying and Authentication for Routing Protocols, aka "KARP".

   It is unlikely that this document, in its current form, will become
   an RFC.  More likely is that this document will be split up into
   several smaller documents which may look something like:

   o  Scope & Goals sections will likely become part of the KARP WG
      charter
   o  Threat document
   o  Requirements document (may be combined with Threat document)
   o  Framework document
   o  RoutingProtocol Design Team Work Plan document.  This would
      include sections like Work Phases, Priorities, Security
      Considerations, etc.
   For now, the document serves as the catch all for the set of thoughts
   around the KARP effort.  As a working group is formed, decisions will
   be made about the creation of specific documents.

   Editor's Note on "KMART" vs "KARP": The first few versions of this
   document were called "draft-lebovitz-kmart-roadmap-xx".  Upon the
   creation of the BoF for IETF76, the IESG requested the name of the
   effort change so as to avoid any potential trademark issues.  The new
   name of the effort is KARP.  Version -03 will go out titled
   "draft-lebovitz-kmart-roadmap-03", so as to avoid confusion.  As soon



Lebovitz &                 Expires May 9, 2010                  [Page 4]

Internet-Draft                KARP Roadmap                 November 2009


   as the I-D editor queue opens again (Monday, 09 Nov) the document
   will be submitted with s/kmart/karp/ in the title.

1.1.  Terminology

   Within the scope of this document, the following words, when
   beginning with a capital letter, or spelled in all capitals, hold the
   meanings described to the right of each term.  If the same word is
   used uncapitalized, then it is intended to have its common english
   definition.

   PSK            Pre-Shared Key. A key used by both peers in a secure
                  configuration.  Usually exchanged out-of-band prior to
                  a first connection.

   Routing Protocol  When used with capital "R" and "P" in this document
                  the term refers the Routing Protocol for which work is
                  being done to provide or enhance its peer
                  authentication mechanisms.

   PRF            Pseudorandom number function, or sometimes called
                  pseudorandom number generator (PRNG).  An algorithm
                  for generating a sequence of numbers that approximates
                  the properties of random numbers.  The sequence is not
                  truly random, in that it is completely determined by a
                  relatively small set of initial values that are passed
                  into the function.  An exmaple is SHA-256.

   KDF            Key derivation function.  A particular specified use
                  of a PRF that takes a PSK, combines it with other
                  inputs to the PRF, and produces a result that is
                  suitable for use as a Traffic Key.

   Identifier     The type and value used by one peer of an
                  authenticated message exchange to signify to the other
                  peer who they are.  The Identifier is used by the
                  receiver as a lookup index into a table containing
                  further information about the peer that is required to
                  continue processing the message, for example a
                  Security Association (SA) or keys.

   Identity Proof A cryptographic proof for an asserted identity, that
                  the peer really is who they assert themselves to be.
                  Proof of identity can be arranged between the peers in
                  a few ways, for example PSK, raw assymetric keys, or a
                  more user-friendly representation of assymetric keys,
                  like a certificate.




Lebovitz &                 Expires May 9, 2010                  [Page 5]

Internet-Draft                KARP Roadmap                 November 2009



   Security Association or SA  The parameters and keys that together
                  form the required information for processing secure
                  sessions between peers.  Examples of items that may
                  exist in an SA include: Identifier, PSK, Traffic Key,
                  cryptographic algorithms, key lifetimes.

   KMP            Key Management Protocol.  A protocol used between
                  peers to exchange SA parameters and Traffic Keys.
                  Examples of KMPs include IKE, TLS, and SSH.

   KMP Function   Any actual KMP used in the general KARP solution
                  framework

   Peer Key       Keys that are used between peers as the identity
                  proof.  These keys may or may not be connection
                  specific, depending on who they were established, and
                  what form of identity and identity proof is being used
                  in the system.

   Traffic Key    The actual key used on each packet of a message.

   Definitions of items specific to the general KARP framework are
   described in more detail in the Framework section Section 4.3.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119 [RFC2119].

1.3.  Scope

   Four basic tactics may be employed in order to secure any piece of
   data as it is transmitted over the wire: privacy (or encryption),
   authentication, message integrity, and non-repudiation.  The focus
   for this effort, and the scope for this roadmap document, will be
   message authentication and packet integrity only.  This work
   explicitly excludes, at this point in time, the other two tactics:
   privacy and non-repudiation.  Since the objective of most routing
   protocols is to broadly advertise the routing topology, routing
   messages are commonly sent in the clear; confidentiality is not
   normally required for routing protocols.  However, ensuring that
   routing peers truly are the trusted peers expected, and that no roque



Lebovitz &                 Expires May 9, 2010                  [Page 6]

Internet-Draft                KARP Roadmap                 November 2009


   peers or messages can compromise the stability of the routing
   environment is critical, and thus our focus.  The other two
   explicitly excluded tactics, privacy and non-repudiation, may be
   addressed in future work.

   It is possible for routing protocol packets to be transmitted
   employing all four security tactics mentioned above using existing
   standards.  For example, one could run unicast, layer 3 or above
   routing protocol packets through IPsec ESP [RFC4303].  This would
   provide the added benefit of privacy, and non-repudiation.  However,
   router platforms and systems have been fine tuned over the years for
   the specific processing necessary for routing protocols' non-
   encapsulated formats.  Operators are, therefore, quite reluctant to
   explore new packet encapsulations for these tried and true protocols.

   In addition, at least in the case of BGP and LDP, these protocols
   already have existing mechanisms for cryptographically authenticating
   and integrity checking the packets on the wire.  Products with these
   mechanisms have already been produced, code has already been written
   and both have been optimized for the existing mechanisms.  Rather
   than turn away from these mechanisms, we want to enhance them,
   updating them to modern and secure levels.

   There are two main work phases for this roadmap, and for any Routing
   Protocol work undertaken as part of this roadmap (discussed further
   in the Work Phases (Section 4.1) section).  The first is to enhance
   the Routing Protocol's current authentication mechanism, ensuring it
   employs modern cryptographic algorithms and methods for its basic
   operational model, fulfilling the requirements defined in the
   Requirements (Section 4.2) section, and protecting against as many of
   the threats as possible as defined in the Threats (Section 2.1)
   section.  Many of the Routing Protocols' current mechanisms use
   manual keys, so the first phase updates will focus on shoring up the
   manual key mechanisms that exist.

   The second work phase is to define the use of a key management
   protocol (KMP) for creating and managing session keys used in the
   Routing Protocols' message authentication and data integrity
   functions.  It is intended that a general KMP framework -- or a small
   number of frameworks -- can be defined and leveraged for many Routing
   Protocols.

   Therefore, the scope of this roadmap of work includes:








Lebovitz &                 Expires May 9, 2010                  [Page 7]

Internet-Draft                KARP Roadmap                 November 2009


   o  Making use of existing routing protocol security protocols, where
      they exist, and enhancing or updating them as necessary for modern
      cryptographic best practices,

   o  Developing a framework for using automatic key management in order
      to ease deployment, lower cost of operation, and allow for rapid
      responses to security breaches, and

   o  Specifying the automated key management protocol that may be
      combined with the bits-on-the-wire mechanisms.

   The work also serves as an agreement between the Routing Area and the
   Security Area about the priorities and work plan for incrementally
   delivering the above work.  This point is important.  There will be
   times when the best-security-possible will give way to vastly-
   improved-over-current-security-but-admittedly-not-yet-best-security-
   possible, in order that incremental progress toward a more secure
   Internet may be achieved.  As such, this document will call out
   places where agreement has been reached on such trade offs.

   This document does not contain protocol specifications.  Instead, it
   defines the areas where protocol specification work is needed and
   sets a direction, a set of requirements, and a relative priority for
   addressing that specification work.

   There are a set of threats to routing protocols that are considered
   in-scope for this document/roadmap, and a set considered out-of-
   scope.  These are described in detail in the Threats (Section 2)
   section below.

1.4.  Goals

   The goals and general guidance for this work roadmap follow:

   1. Provide authentication and integrity protection for packets on the
      wire of existing routing protocols

   2. Deliver a path to incrementally improve security of the routing
      infrastructure.  The principle of crawl, walk, run will be in
      place.  Routing protocol authentication mechanisms may not go
      immediately from their current state to a state containing the
      best possible, most modern security practices.  Incremental steps
      will need to be taken for a few very practical reasons.  First,
      there are a considerable number of deployed routing devices in
      operating networks that will not be able to run the most modern
      cryptographic mechanisms without significant and unacceptable
      performance penalties.  The roadmap for any one routing protocol
      MUST allow for incremental improvements on existing operational



Lebovitz &                 Expires May 9, 2010                  [Page 8]

Internet-Draft                KARP Roadmap                 November 2009


      devices.  Second, current routing protocol performance on deployed
      devices has been achieved over the last 20 years through extensive
      tuning of software and hardware elements, and is a constant focus
      for improvement by vendors and operators alike.  The introduction
      of new security mechanisms affects this performance balance.  The
      performance impact of any incremental step of security improvement
      will need to be weighed by the community, and introduced in such a
      way that allows the vendor and operator community a path to
      adoption that upholds reasonable performance metrics.  Therefore,
      certain specification elements may be introduced carrying the
      "SHOULD" guidance, with the intention that the same mechanism will
      carry a "MUST" in the next release of the specification.  This
      gives the vendors and implementors the guidance they need to tune
      their software and hardware appropriately over time.  Last, some
      security mechanisms require the build out of other operational
      support systems, and this will take time.  An example where these
      three reasons are at play in an incremental improvement roadmap is
      seen in the improvement of BGP's [RFC4271] security via the update
      of the TCP Authentication Option (TCP-AO)
      [I-D.ietf-tcpm-tcp-auth-opt] effort.  It would be ideal, and
      reflect best common security practice, to have a fully specified
      key management protocol for negotiating TCP-AO's authentication
      material, using certificates for peer authentication in the
      keying.  However, in the spirit of incremental deployment, we will
      first address issues like cryptographic algorithm agility, replay
      attacks, TCP session resetting in the base TCP-AO protocol before
      we layer key management on top of it.

   3. The deploy-ability of the improved security solutions on currently
      running routing infrastructure equipment.  This begs the
      consideration of the current state of processing power available
      on routers in the network today.

   4. Operational deploy-ability - A solutions acceptability will also
      be measured by how deployable the solution is by common operator
      teams using common deployment processes and infrastructures.  I.e.
      We will try to make these solutions fit as well as possible into
      current operational practices or router deployment.  This will be
      heavily influenced by operator input, to ensure that what we
      specify can -- and, more importantly, will -- be deployed once
      specified and implemented by vendors.  Deployment of incrementally
      more secure routing infrastructure in the Internet is the final
      measure of success.  Measurably, we would like to see an increase
      in the number of surveyed respondents who report deploying the
      updated authentication mechanisms anywhere across their network,
      as well as a sharp rise in usage for the total percentage of their
      network's routers.




Lebovitz &                 Expires May 9, 2010                  [Page 9]

Internet-Draft                KARP Roadmap                 November 2009



      Interviews with operators show several points about routing
      security.  First, over 70% of operators have deployed transport
      connection protection via TCP-MD5 on their EBGP [ISR2008] .  Over
      55% also deploy MD5 on their IBGP connections, and 50% deploy MD5
      on some other IGP.  The survey states that "a considerable
      increase was observed over previous editions of the survey for use
      of TCP MD5 with external peers (eBGP), internal peers (iBGP) and
      MD5 extensions for IGPs."  Though the data is not captured in the
      report, the authors believe anecdotally that of those who have
      deployed MD5 somewhere in their network, only about 25-30% of the
      routers in their network are deployed with the authentication
      enabled.  None report using IPsec to protect the routing protocol,
      and this was a decline from the few that reported doing so in the
      previous year's report.
      From my personal conversations with operators, of those using MD5,
      almost all report deploying with one single manual key throughout
      the entire network.  These same operators report that the one
      single key has not been changed since it was originally installed,
      sometimes five or more years ago.  When asked why, particularly
      for the case of BGP using TCP MD5, the following reasons are often
      given:


      A.  Changing the keys triggers a TCP reset, and thus bounces the
          links/adjacencies, undermining Service Level Agreements
          (SLAs).
      B.  For external peers, difficulty of coordination with the other
          organization is an issue.  Once they find the correct contact
          at the other organization (not always so easy), the
          coordination function is serialized and on a per peer/AS
          basis.  The coordination is very cumbersome and tedious to
          execute in practice.
      C.  Keys must be changed at precisely the same time, or at least
          within 60 seconds (as supported by two major vendors) in order
          to limit connectivity outage duration.  This is incredibly
          difficult to do, operationally, especially between different
          organizations.
      D.  Relatively low priority compared to other operatoinal issues.
      E.  Lack of staff to implement the changes device by device.
      F.  There are three use cases for operational peering at play
          here: peers and interconnection with other operators, Internal
          BGP and other routing sessions within a single operator, and
          operator-to-customer-CPE devices.  All three have very
          different properties, and all are reported as cumbersome.  One
          operator reported that the same key is used for all customer
          premise equipment.  The same operator reported that if the
          customer mandated, a unique key could be created, although the



Lebovitz &                 Expires May 9, 2010                 [Page 10]

Internet-Draft                KARP Roadmap                 November 2009


          last time this occurred it created such an operational
          headache that the administrators now usually tell customers
          that the option doesn't even exist, to avoid the difficulties.
          These customer-uniqe keys are never changed, unless the
          customer demands so.
      The main threat at play here is that a terminated employee from
      such an operator who had access to the one (or few) keys used for
      authentication in these environments could easily wage an attack
      -- or offer the keys to others who would wage the attack -- and
      bring down many of the adjacencies, causing destabilization to the
      routing system.

      Whatever mechanisms we specify need to be easier than the current
      methods to deploy, and should provide obvious operational
      efficiency gains along with significantly better security and
      threat protection.  This combination of value may be enough to
      drive much broader adoption.

   5. Address the threats enumerated above in the "Threats" section
      (Section 2) for each routing protocol, along a roadmap.  Not all
      threats may be able to be addressed in the first specification
      update for any one protocol.  Roadmaps will be defined so that
      both the security area and the routing area agree on how the
      threats will be addressed completely over time.

   6. Create a re-usable architecture, framework, and guidelines for
      various IETF working teams who will address these security
      improvements for various Routing Protocols.  The crux of the KARP
      work is to re-use that framework as much as possible across
      relevant Routing Protocols.  For example, designers should aim to
      re-use the key management protocol that will be defined for BGP's
      TCP-AO key establishment for as many other routing protocols as
      possible.  This is but one example.

   7. Bridge any gaps between IETF's Routing and Security Areas by
      recording agreements on work items, roadmaps, and guidance from
      the Area leads and Internet Architecture Board (IAB, www.iab.org).


1.5.  Non-Goals

   The following two goals are considered out-of-scope for this effort:

   o  Privacy of the packets on the wire, at this point in time.  Once
      this roadmap is realized, we may revisit work on privacy.






Lebovitz &                 Expires May 9, 2010                 [Page 11]

Internet-Draft                KARP Roadmap                 November 2009



   o  Message content security.  This work is being addressed in other
      IETF efforts, like SIDR.

1.6.  Audience

   The audience for this roadmap includes:

   o  Routing Area working group chairs and participants -   These
        people are charged with updates to the Routing Protocol
        specifications.  Any and all cryptographic authentication work
        on these specifications will occur in Routing Area working
        groups, with close partnership with the Security Area.  Co-
        advisors from Security Area may often be named for these
        partnership efforts.

   o  Security Area reviewers of routing area documents -   These people
        are delegated by the Security Area Directors to perform reviews
        on routing protocol specifications as they pass through working
        group last call or IESG review.  They will pay particular
        attention to the use of cryptographic authentication and
        corresponding security mechanisms for the routing protocols.
        They will ensure that incremental security improvements are
        being made, in line with this roadmap.

   o  Security Area engineers -   These people partner with routing area
        authors/designers on the security mechanisms in routing protocol
        specifications.  Some of these security area engineers will be
        assigned by the Security Area Directors, while others will be
        interested parties in the relevant working groups.

   o  Operators -   The operators are a key audience for this work, as
        the work is considered to have succeeded if the operators deploy
        the technology, presumably due to a perception of significantly
        improved security value coupled with relative similarity to
        deployment complexity and cost.  Conversely, the work will be
        considered a failure if the operators do not care to deploy it,
        either due to lack of value or perceived (or real) over-
        complexity of operations.  And as such, the GROW and OPSEC WGs
        should be kept squarely in the loop as well.




2.  Threats

   In RFC4949[RFC4949], a threat is defined as a potential for violation
   of security, which exists when there is a circumstance, capability,



Lebovitz &                 Expires May 9, 2010                 [Page 12]

Internet-Draft                KARP Roadmap                 November 2009


   action, or event that could breach security and cause harm.  This
   section defines the threats that are in scope for this roadmap, and
   those that are explicitly out of scope.  This document leverages the
   "Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] ,
   capitalizes terms from that document, and offers a terse definition
   of those terms.  (More thorough description of routing protocol
   threats sources, motivations, consequences and actions can be found
   in RFC 4593 [RFC4593] itself).  The threat listings below expand upon
   these threat definitions.

2.1.  Threats In Scope

   The threats that will be addressed in this roadmap are those from
   OUTSIDERS, attackers that may reside anywhere in the Internet, have
   the ability to send IP traffic to the router, may be able to observe
   the router's replies, and may even control the path for a legitimate
   peer's traffic.  These are not legitimate participants in the routing
   protocol.  Message authentication and integrity protection
   specifically aims to identify messages originating from OUTSIDERS.

   The concept of OUTSIDERS can be further refined to include attackers
   who are terminated employees, and those sitting on-path.

   o  On-Path - attackers with control of a network resource or a tap
      along the path of packets between two routers.  An on-path
      outsider can attempt a man-in-the-middle attack, in addition to
      several other attack classes.  A man-in-the-middle (MitM) attack
      occurs when an attacker who has access to packets flowing between
      two peers tampers with those packets in such a way that both peers
      think they are talking to each other directly, when in fact they
      are actually talking to the attacker only.  Protocols conforming
      to this roadmap will use cryptographic mechanisms to prevent a
      man-in-the-middle attacker from situating himself undetected.

   o  Terminated Employees - in this context, those who had access
      router configuration that included keys or keying material like
      pre-shared keys used in securing the routing protocol.  Using this
      material, the attacker could send properly MAC'd spoofed packets
      appearing to come from router A to router B, and thus impersonate
      an authorized peer.  The attacker could then send false traffic
      that changes the network behavior from its operator's design.  The
      goal of addressing this source specifically is to call out the
      case where new keys or keying material becomes necessary very
      quickly, with little operational expense, upon the termination of
      such an employee.  This grouping could also refer to any attacker
      who somehow managed to gain access to keying material, and said
      access had been detected by the operators such that the operators
      have an opportunity to move to new keys in order to prevent an



Lebovitz &                 Expires May 9, 2010                 [Page 13]

Internet-Draft                KARP Roadmap                 November 2009


      attack.

   These ATTACK ACTIONS are in scope for this roadmap:

   o  SPOOFING - when an unauthorized device assumes the identity of an
      authorized one.  Spoofing can be used, for example, to inject
      malicious routing information that causes the disruption of
      network services.  Spoofing can also be used to cause a neighbor
      relationship to form that subsequently denies the formation of the
      relationship with the legitimate router.

   o  FALSIFICATION - an action whereby an attacker sends false routing
      information.  To falsify the routing information, an attacker has
      to be either the originator or a forwarder of the routing
      information.  Falsification may occur by an ORIGINATOR, or a
      FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or
      MISTATEMENT of network resource reachability.  We must be careful
      to remember that in this work we are only targeting falsification
      from outsiders as may occur from tampering with packets in flight.
      Falsification from BYZANTINES (see the Threats Out of Scope
      section (Section 2.2) below) are not addressed by the KARP effort.

   o  INTERFERENCE - when an attacker inhibits the exchanges by
      legitimate routers.  The types of interference addressed by this
      work include:
      *  ADDING NOISE
      *  REPLAYING OUT-DATED PACKETS
      *  INSERTING MESSAGES
      *  CORRUPTING MESSAGES
      *  BREAKING SYNCHRONIZATION
      *  Changing message content

   o  DoS attacks on transport sub-systems - This includes any other DoS
      attacks specifically based on the above attack types.  This is
      when an attacker sends spoofed packets aimed at halting or
      preventing the underlying protocol over which the routing protocol
      runs, for example halting a BGP session by sending a TCP FIN or
      RST packet.  Since this attack depends on spoofing, operators are
      encouraged to deploy

   o  DoS attacks using the authentication mechanism - This includes an
      attacker sending packets which confuse or overwhelm a security
      mechanism itself.  An example is initiating an overwhelming load
      of spoofed authenticated route messages so that the receiver needs
      to process the MAC check, only to discard the packet, sending CPU
      levels rising.  Another example is when an attacker sends an
      overwhelming load of keying protocol initiations from bogus
      sources.  All other possible DoS attacks are out of scope (see



Lebovitz &                 Expires May 9, 2010                 [Page 14]

Internet-Draft                KARP Roadmap                 November 2009


      next section).

   o  Brute Foce Attacks Against Password/Keys - This includes either
      online or offline attacks where attempts are made repeatedly using
      different keys/passwords until a match is found.  While it is
      impossible to make brute force attacks on keys completely
      unsuccessful, proper design can make such attacks much harder to
      succeed.  For exmaple, the key length should be sufficiently long
      so that covering the entire space of possible keys is improbable
      using computational power expected to be available 10 years out or
      more.  Also, frequently changing the keys may render useless a
      successful guess some time in the future, as those keys may no
      longer be in use.

2.2.  Threats Out of Scope

   Threats from BYZANTINE sources -- faulty, misconfigured, or subverted
   routers, i.e., legitimate participants in the routing protocol -- are
   out of scope for this roadmap.  Any of the attacks described in the
   above section (Section 2.1) that may be levied by a BYZANTINE source
   are therefore also out of scope.

   In addition, these other attack actions are out of scope for this
   work:

   o  SNIFFING - passive observation of route message contents in flight
   o  FALSIFICATION by BYZANTINE sources - unauthorized message content
      by a legitimate authorized source.
   o  INTERFERENCE due to:
      *  NOT FORWARDING PACKETS - cannot be prevented with cryptographic
         authentication
      *  DELAYING MESSAGES - cannot be prevented with cryptographic
         authentication
      *  DENIAL OF RECEIPT - cannot be prevented with cryptographic
         authentication
      *  UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR
         working group
         ( http://www.ietf.org/html.charters/sidr-charter.html).
      *  Any other type of DoS attack.  For example, a flood of traffic
         that fills the link ahead of the router, so that the router is
         rendered unusable and unreachable by valid packets is NOT an
         attack that this work will address.  Many other such examples
         could be contrived.








Lebovitz &                 Expires May 9, 2010                 [Page 15]

Internet-Draft                KARP Roadmap                 November 2009


3.  Categorizing Routing Protocols

   For the purpose of this security roadmap definition, we will
   categorize the routing protocols into groups and have design teams
   focus on the specification work within those groupings.  It is
   believed that the groupings will have like requirements for their
   authentication mechanisms, and that reuse of authentication
   mechanisms will be greatest within these grouping.  The work items
   placed on the roadmap will be defined and assigned based on these
   categorizations.  It is also hoped that, down the road in the Phase 2
   work, we can create one KMP per category (if not for several
   categories) so that the work can be easily leveraged by the various
   Routing Protocol teams.  KMPs are useful for allowing simple,
   automated updates of the traffic keys used in a base protocol.  KMPs
   replace the need for humans, or OSS routines, to periodically replace
   keys on running systems.  It also removes the need for a chain of
   manual keys to be chosen or configured.  When configured properly, a
   KMP will enforce the key freshness policy of two peers by keeping
   track of the key lifetime and negotiating a new key at the defined
   interval.

3.1.  Category: Messaging Transaction Type

   The first categorization defines four types of messaging transactions
   used on the wire by the base Routing Protocol.  They are:


   One-to-One     One peer router directly and intentionally delivers a
                  route update specifically to one other peer router.
                  Examples are BGP and LDP.  Point-to-point modes of
                  both IS-IS and OSPF, when sent over both traditional
                  point-to-point links and when using multi-access
                  layers, may both also fall into this category.
                  [question to reviewers: Should we list all protocols
                  into these categories right here, or just give a few
                  examples?]

   One-to-Many    A router peers with multiple other routers on a single
                  network segment -- i.e. on link local -- such that it
                  creates and sends one route update message which is
                  intended for consumption by multiple peers.  Examples
                  would be OSPF and IS-IS in their broadcast, non-point-
                  to-point modes.








Lebovitz &                 Expires May 9, 2010                 [Page 16]

Internet-Draft                KARP Roadmap                 November 2009


   Client-Server  A client-server routing protocol is one where one
                  router initiates a request for route information from
                  another router, who then formulates a response to that
                  request, and replies with the requested data.
                  Examples are a BGP Route Reflector and [????  Are
                  there other examples?  Is this the right example?  Do
                  discovery protocols fall under this category?].

   Multicast      Multicast protocols have unique security properties
                  because of the fact that they are inherently group-
                  based protocols and thus have group keying
                  requirements at the routing level where link-local
                  routing messages are multicasted.  Also, at least in
                  the case of PIM-SM, some messages are are sent unicast
                  to a given peer(s), as is the case with router-close-
                  to-sender and the "Rendezvous Point".  Some work for
                  application layer message security has been done in
                  the Multicast Security working group (MSEC,
                  http://www.ietf.org/html.charters/msec-charter.html)
                  and may be helpful to review, but is not directly
                  applicable.

   [author's note: I think the above definitions need clean up.  Routing
   area folks, especially ADs, PLEASE suggest new text.]

3.2.  Category: Peer vs. Group Keying

   The second axis of categorization groups protocols by the keying
   mechanism that will be necessary for distributing session keys to the
   actual Routing Protocol transports.  They are:


   Peer keying    One router sends the keying messages directly and only
                  to one other router, such that a one-to-one, unique
                  keying security association (SA) is established
                  between the two routers

   Group Keying   One router creates and distributes a single keying
                  message to multiple peers.  In this case an group SA
                  will be established and used between multiple peers
                  simultaneously.  Group keying exists for protocols
                  like OSPF [RFC2328] , and also for multicast protocols
                  like PIM-SM [RFC4601].








Lebovitz &                 Expires May 9, 2010                 [Page 17]

Internet-Draft                KARP Roadmap                 November 2009


3.3.  Category:  Update vs. Discovery Protocol

   The third category group considers protocols by the contents of the
   messages being exchanged in the Routing Protocol.  They are:


   Updates        Messages that carry route advertisements or update
                  information from peer to peer

   Discovery      Messages sent as part of a policy, peer, or service
                  discovery process.  These messages are normally
                  exchanged prior to any adjacency being formed, and
                  before any updates are sent.  For example, end-point
                  discovery mechanisms are common in L2VPN and L3VPN
                  solutions.

   [QUESTION TO REVIEWERS: is this really just what's described in 3.1
   as "Client-Server" and/or "One-to-One"?  Is there really such a
   different in discovery protocols that they need their own category to
   figure out how to authenticate them?  Can someone provide a few
   examples?

3.4.  Security Characterization Vectors

   A few more considerations must be made about the protocol and its use
   when initially categorizing the protocol and scoping the
   authentication work.

3.4.1.  Internal vs. External Operation

   The designers must consider whether the protocol is an internal
   routing protocol or an external one, i.e.  Does it primarily run
   between peers within a single domain of control or between two
   different domains of control?  Some protocols may be used in both
   cases, internally and externally, and as such various modes of
   authentication operation may be required for the same protocol.
   While it is preferred that all routing exchanges run with the utmost
   security mechanisms enabled in all deployments, this exhortation is
   greater for those protocols running on inter-domain point-to-point
   links, and greatest for those on shared access link layers with
   several different domains interchanging together, because the volume
   of attackers are greater from the outside.  Note however that the
   consequences of internal attacks maybe no less severe -- in fact they
   may be quite a bit more severe -- than an external attack.  An
   example of this internal versus external consideration is BGP which
   has both EBGP and IBGP modes.  Another example is a multicast
   protocol where the neighbors are sometimes within a domain of control
   and sometimes at an inter-domain exchange point.  In the case of



Lebovitz &                 Expires May 9, 2010                 [Page 18]

Internet-Draft                KARP Roadmap                 November 2009


   PIM-SM running on an internal multi-access link, It would be
   acceptable to give up some security to get some convenience by using
   a group key between the peers on the link.  On the other hand, in the
   case of PIM-SM running over a multi-access link at a public exchange
   point, operators may favor security over convenience by using unique
   pair-wise keys for every peer.  Designers must consider both modes of
   operation and ensure the authentication mechanisms fit both.

   Operators are encouraged to run cryptographic authentication on all
   their adjacencies, but to work from the outside in, i.e.  The EBGP
   links are a higher priority than the IBGP links because they are
   externally facing, and, as a result, more likely to be targeted in an
   attack.

3.4.2.  Unique versus Shared Keys

   This section discusses security considerations regarding when it is
   appropriate to use the same authentication key inputs for multiple
   peers and when it is not.  This is largely a debate of convenience
   versus security.  It is often the case that the best secured
   mechanism is also the least convenient mechanism.  For example, an
   air gap between a host and the network absolutely prevents remote
   attacks on the host, but having to copy and carry files using the
   "sneaker net" is quite inconvenient and unscalable.

   Operators have erred on the side of convenience when it comes to
   securing routing protocols with cryptographic authentication.  Many
   do not use it at all.  Some use it only on external links, but not on
   internal links.  Those that do use it often use the same key for all
   peers across their entire network.  It is common to see the same key
   in use for years, and that being the same key that was entered when
   authentication was originally configured, or the routing gear
   deployed.

   The goal for designers is to create authentication mechanisms that
   are easy for the operators to deploy and manage, and still use unique
   keys between peers (or small groups on multi-access links), and
   within between sessions.  Operators have the impression that they
   NEED one key shared across the network, when in fact they do not.
   What they need is the relative convenience they experience from
   deploying cryptographic authentication with one (or few) key,
   compared to the inconvenience they would experience if they deployed
   the same authentication mechanism using unique pair-wise keys.  An
   example is BGP Route Reflectors.  Here operators often use the same
   authentication key between each client and the route reflector.  The
   roadmaps defined from this guidance document will allow for unique
   keys to be used between each client and the peer, without sacrificing
   much convenience.  Designers should strive to deliver peer-wise



Lebovitz &                 Expires May 9, 2010                 [Page 19]

Internet-Draft                KARP Roadmap                 November 2009


   unique keying mechanisms with similar ease-of-deployment properties
   as today's one-key method.

   Operators must understand the consequences of using the same keys
   across many peers.  Unique keys are more secure than shared keys
   because they reduce both the attack target size and the attack
   consequence size.  In this context, the attack target size represents
   the number of unique routing exchanges across a network that an
   attacker may be able to observe in order to gain security association
   credentials, i.e. crack the keys.  If a shared key is used across the
   entire internal domain of control, then the attack target size is
   very large.  The larger the attack target, the easier it is for the
   attacker to gain access to analysis data, and greater the volume of
   analysis data he can access in a given time frame, both of which make
   his job easier.  Using the same key across the network makes the
   attack vulnerability surface more penetrable than unique keys.
   Consider also the attack consequence size, the amount of routing
   adjacencies that can be negatively affected once a breach has
   occurred, i.e. once the keys have been acquired by the attacker.
   Again, if a shared key is used across the internal domain, then the
   consequence size is the whole network.  Ideally, unique key pairs
   would be used for each adjacency.

   In some cases designers may need to use shared keys in order to solve
   the given problem space.  For example, a multicast packet is sent
   once but then observed and consumed by several routing neighbors.  If
   unique keys were used per neighbor, the benefit of multicast would be
   erased because the casting peer would have to create a different
   announcement packet/stream for each listening peer.  Though this may
   be desired and acceptable in some small amount of use cases, it is
   not the norm.  Shared group keys are an acceptable solution here, and
   much work has been done already in this area (see MSEC working
   group).

3.4.3.  Out-of-Band vs. In-line Key Management

   This section discusses the security and use case considerations for
   keys placed on devices through out-of-band configurations versus
   through one routing peer-to-peer key management protocol exchanges.
   Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to
   the Routing Protocol.  Instead, we mean that the exchange occurs in-
   line, over IP, between the two routing peers directly.  In in-line
   KMP the peers themselves handle the key and security association
   negotiation between themselves directly, whereas in an out-of-band
   system the keys are placed onto the device through some other
   configuration or management method or interface.

   An example of an out-of-band mechanism could be an administrator who



Lebovitz &                 Expires May 9, 2010                 [Page 20]

Internet-Draft                KARP Roadmap                 November 2009


   makes a remote management connection (e.g. using SSH) to a router and
   manually enters the keying information -- like the algorithm, the
   key(s), the lifetimes, etc.  Another example could be an OSS system
   which inputs the same information via a script over an SSH
   connection, or by pushing configuration through some other management
   connection, standard (Netconf-based) or proprietary.

   The drawbacks of an out-of-band mechanism include: lack of scale-
   ability, complexity and speed of changing if a breach is suspected.
   For example, if an employee who had access to keys was was
   terminated, or if a machine holding those keys was belived
   compromised, then the system would be considered insecure and
   vulnerable until new keys were defined by a human.  Those keys then
   need to be placed into the OSS system, manually, and the OSS system
   then needs to push the change -- often during a very limited change
   window -- into the relevant devices.  If there are multiple
   organizations involved in these connections, this process is greatly
   complicated.

   The benefits of out-of-band mechanism is that once the new keys/
   parameters are set in OSS system they can be pushed automatically to
   all devices within the OSS's domain of control.  Operators have
   mechanisms in place for this already.  In small environments with few
   routers, a manual system is not difficult to employ.

   We further define an in-line key exchange as using cryptographicly
   protected identity verification, session key negotiation, and
   security association parameter negotiation between the two routing
   peers.  The KMP between the two peers may also include the
   negotiation of parameters, like algorithms, cryptographic inputs
   (e.g. initialization vectors), key life-times, etc.

   The benefits an in-line KMP are several.  An in-line KMP results in
   key(s) that are privately generated, and not recorded permanently
   anywhere.  Since the traffic keys used in a particular connection are
   not a fixed part of a device configuration no steal-able data exists
   anywhere else in the operator's systems which can be stolen, e.g. in
   the case of a terminated or turned employee.  If a server or other
   data store is stolen or compromised, the thieves gain no access to
   current traffic keys.  They may gain access to key derivation
   material, like a PSK, but not current traffic keys in use.  In this
   example, these PSKs can be updated into the device configurations
   (either manually or through an OSS) without bouncing or impacting the
   existing session at all.  In the case of using raw assymetric keys or
   certificates, instead of PSKs, the data theft would likely not even
   result in any compromise, as the key pairs would have been generated
   on the routers, and never leave those routers.  In such a case no
   changes are needed on the routers; the connections will continue to



Lebovitz &                 Expires May 9, 2010                 [Page 21]

Internet-Draft                KARP Roadmap                 November 2009


   be secure, uncompromised.  Additionally, with a KMP regular re-keys
   operations occur without any operator involvement or oversight.  This
   keeps keys fresh.

   The drawbacks to using a KMP are few.  First, a KMP requires more
   cryptographic processing for the router at the very beginning of a
   connection.  This will add some minor start-up time to connection
   establishment versus a purely manual key approach.  Once a connection
   with traffic keys have been established via a KMP, the performance is
   the same in the KMP and the out-of-band case.  KMPs also add another
   layer of protocol and configuration complexity which can fail or be
   misconfigured.  This was more of an issue when these KMPs were first
   deployed, but less so as these implementaitons and operational
   experience with them has matured.

   The desired end goal is in-line KMPs.


4.  The Roadmap

4.1.  Work Phases on any Particular Protocol

   The desired endstate for the KARP work contains several items.
   First, the people desiring to deploy securely authenticated and
   integrity validated packets between routing peers have the tools
   specified, implemented and shipping in order to deploy.  These tools
   should be fairly simple to implement, and not more complex than the
   security mechanisms to which the operators are already accustomed.
   (Examples of security mechanisms to which router operators are
   accustomed include: the use of assymetric keys for authentication in
   SSH for router configuration, the use of pre-shared keys (PSKs) in
   TCP MD5 for BGP protection, the use of self-signed certificates for
   HTTPS access to device Web-based user interfaces, the use of strongly
   constructed passwords and/or identity tokens for user identification
   when logging into routers and management systems.)  While the tools
   that we intend to specify may not be able to stop a deployment from
   using "foobar" as an input key for every device across their entire
   routing domain, we intend to make a solid, modern security system
   that is not too much more difficult than that.  In other words,
   simplicity and deployability are keys to success.  The Routing
   Protocols will specify modern cryptographic algorithms and security
   mechanisms.  Routing peers will be able to employ unique, pair-wise
   keys per peering instance, with reasonable key lifetimes, and
   updating those keys on a somewhat regular basis will be operationally
   easy, causing no service interruption.

   Achieving the above described end-state using manual keys may only be
   pragmatic in very small deployments.  In larger deployments, this end



Lebovitz &                 Expires May 9, 2010                 [Page 22]

Internet-Draft                KARP Roadmap                 November 2009


   state will be much more operationally difficult to reach with only
   manual keys.  Thus, there will be a need for key life cycle
   management, in the form of a key management protocol, or KMP.  We
   expect that the two forms, manual key usage and KMP usage, will co-
   exist in the real world.  For example, a provider's edge router at a
   public exchange peering point will want to use a KMP for ensuring
   unique and fresh keys with external peers, while a manual key may be
   used between a provider's access edge router and each of the same
   provider's customer premise routers with which it peers.

   In accordance with the desired end state just described, we define
   two main work phases for each Routing Protocol:

   1.  Enhance the Routing Protocol's current authentication mechanism.
       This work involves enhancing a Routing Protocol's current
       security mechanisms in order to achieve a consistent, modern
       level of security functionality within its existing keying
       framework.  It is understood and accepted that the existing
       keying frameworks are largely based on manual keys.  Since many
       operators have already built operational support systems (OSS)
       around these manual key implementations, there is some automation
       available for an operator to leverage in that way, if the
       underlying mechanisms are themselves secure.  In this phase, we
       explicitly exclude embedding or creating a KMP.  A list of the
       requirements for Phase 1 work are below in the section
       "Requirements for Phase 1 Routing Protocols' Security Updates
       (Section 4.2).

   2.  Develop an automated keying framework.  The second phase will
       focus on the development of an automated keying framework to
       faciliate unique pair-wise (or perhaps group-wise, where
       applicable) keys per peering instance.  This involves the use of
       a KMP.  A KMP is helpful because it negotiates unique, pair wise,
       random keys without administrator involvement.  It also
       negotiates several of the SA parameters required for the secure
       connection, including key life times.  It keeps track of those
       lifetimes using counters, and negotiates new keys and parameters
       before they expire, again, without administrator interaction.
       Additionally, in the event of a breach, changing the KMP key will
       immediately cause a rekey to occur for the Traffic Key, and those
       new Traffic Keys will be installed and used in the current
       connection.  In summary, a KMP provides a protected channel
       between the peers through which they can negotiate and pass
       important data required to exchange proof of key identifiers,
       derive Traffic Keys, determine re-keying, synchronize their
       keying state, signal various keying events, notify with error
       messages, etc.  To address brute force attacks [RFC3562]
       recommends a key management practice to minimize the possibility



Lebovitz &                 Expires May 9, 2010                 [Page 23]

Internet-Draft                KARP Roadmap                 November 2009


       of successful attack-- frequent key rotation, limited key
       sharing, key length restrictions, etc.  Advances in computational
       power due to Moore's law are making that management burden
       untenable-- keys must be of a size and composition that makes
       configuration and maintance difficult or keys must be rotated
       with an unreasonable frequency.  A KMP will help immensely with
       this growing problem.

       The framework for any one Routing Protocol will fall under, and
       be able to leverage, the generic framework described below in
       section Section 4.3.

4.2.  Requirements for Phase 1 Routing Protocols' Security Update

   Here is a proposed list of requirements that SHOULD be addressed by
   Phase 1 (according to "1." above) security updates to Routing
   Protocols [to be reviewed after -01 is released]:

   1.   Clear definitions of which elements of the transmission (frame,
        packet, segment, etc.) are protected by the authentication
        mechanism
   2.   Strong algorithms, and defined and accepted by the security
        community, MUST be specified.  The option should use algorithms
        considered accepted by the security community, which are
        considered appropriately safe.  The use of non-standard or
        unpublished algorithms SHOULD BE avoided.
   3.   Algorithm agility for the cryptograhpic algorithms used in the
        authentication MUST be specified, i.e. more than one algorithm
        MUST be specified and it MUST be clear how new algorithms MAY be
        specified and used within the protocol.  This requirement exists
        in case one algorithm gets broken suddenly.  Research to
        identify weakness in algorithms is constant.  Breaking a cipher
        isn't a matter of if, but when it will occur. t's highly
        unlikely that two different algorithms will be broken
        simultaneously.  So, if two are supported, and one gets broken,
        we can use the other until we get a new one in place.  Having
        the ability within the protocol specification to support such an
        event, having algorithm agility, is essential.  Mandating two
        algorithms provides both a redundancy, and a mechanism for
        enacting that redundancy when needed.
   4.   Secure use of simple PSKs, offering both operational convenience
        as well as building something of a fence around stupidity, MUST
        be specified.
   5.   Inter-connection replay protection.  Packets captured from one
        connection MUST NOT be able to be re-sent and accepted during a
        later connection.





Lebovitz &                 Expires May 9, 2010                 [Page 24]

Internet-Draft                KARP Roadmap                 November 2009


   6.   Intra-connection replay protection.  Packets captured during a
        connection MUST NOT be able to be re-sent and accepted during
        that same connection, to deal with long-lived connections.
   7.   A change of security parameters REQUIRES, and even forces, a
        change of session traffic keys
   8.   Intra-connection re-keying which occurs without a break or
        interruption to the current peering session, and, if possible,
        without data loss, MUST be specified.
   9.   Efficient re-keying SHOULD be provided.  The specificaion SHOULD
        support rekeying during a connection without the need to expend
        undue computational resources.  In particular, the specification
        SHOULD avoid the need to try/compute multiple keys on a given
        packet.
   10.  Prevent DoS attacks as those described as in-scope in the
        threats section Section 2.1 above.
   11.  Default mechanisms and algorithms specified and defined as
        REQUIRED for all implementations
   12.  Manual keying MUST be supported.
   13.  Convergence times of the Routing Protocols SHOULD NOT be
        materially affected.  Materially here is defined as anything
        greater than a 5% convergence time increase.  Note that
        convergence is different than boot time.  Also note that
        convergence time has a lot to do with the speed of processors
        used on individual routing peers, and this increases by Moore's
        law over time.  Therefore, this requirement should be considered
        only in terms of total number of messages that must be
        exchanged, and less for the computational intensity of
        processing any one message.
   14.  The changes or addition of security mechanisms SHOULD NOT cause
        a refresh of route updates or cause additional route updates to
        be generated
   15.  Architecture of the specification MUST consider and allow for
        future use of a KMP.

4.3.  Common Framework

   Each of the categories of routing protocols above will require unique
   designs for authenticating and integrity checking their protocols.
   However, a single underlying framework for delivering automatic
   keying to those solutions will be pursued.  Providing such a single
   framework will significantly reduce the complexity of each step of
   the overall roadmap.  For example, if each Routing Protocol needed to
   define it's own key management protocol this would balloon the total
   amount of different sockets that are needed to be opened and
   processes that are needed to be simultaneously running on an
   implementation.  It would also significantly increase the run-time
   complexity and memory requirements of such systems running multiple
   Routing Protocols, causing perhaps slower performance of such



Lebovitz &                 Expires May 9, 2010                 [Page 25]

Internet-Draft                KARP Roadmap                 November 2009


   systems.  However, if we can land on a very small set (perhaps one or
   two) of automatic key management protocols, KMPs, that the various
   Routing Protocols can use, then we can reduce this implementation and
   run-time complexity.  We can also decrease the total amount of time
   implementers need to deliver the KMPs for the Routing Protocols that
   will provide better threat protection.

   The components for the framework are listed here, and described
   below:

   o  Routing Protocol security mechanism
   o  KMP
   o  KeyStore
   o  Traffic Key
   o  RoutingProtocol-to-KMP API
   o  RoutingProtocol-to-KeyStore API
   o  KMP-to-KeyStore API
   o  Common Routing Protocol mechanisms
   o  Identifiers
   o  Proof of identity
   o  Profiles

   The framework is modularized for how keys and security association
   (SA) parameters generally get passed from a KMP to a transport
   protocol.  It contains three main blocks and APIs.


























Lebovitz &                 Expires May 9, 2010                 [Page 26]

Internet-Draft                KARP Roadmap                 November 2009


      +------------+   +--------------------+
      |            |   |                    | Check     +-----------+
      | Identifier +-->|                    +---------->|           |
      |            |   |    KMP Function    |           |  Identity |
      +----------- +   |                    |<----------+   Proof   |
                       |                    |  Approve  |           |
                       +-+--------------+---+           +-----------+
                         |              |
         KMP-to-KeyStore |              |
            API          |              |
                        \|/             |
                 +-------+-------+      |
                 |               |      | KMP-to-RoutingProtocol
                 |               |      |  API
                 |    KeyStore   |      |
                 |               |      |
                 +-------+-------+      |
                         |              |
                         |              |
           KeyStore-to-  |              |
    RoutingProtocol API  |              |
                         |             \|/
             +--------------------------+-------------+
             |           |                            |
             |          \|/          Common RtgProto  |
             |   +-------+-------+   Authentication   |
             |   |               |   Mechanisms       |
             +---|  Traffic      |-----+--------------+
             |   |   Key(s)      |                    |
             |   |               |                    |
             |   +---------------+   Specific         |
             |                       RoutingProtocol  |
             |                       Authentication   |
             |                       Security         |
             |                       Mechanism        |
             +----------------------------------------+


               Figure 1: Automatic Key Management Framework

   Each element of the framework is described here:


   o  Routing Protocol -  Routing protocol security mechanism - In each
           case, the Routing Protocol will contain a mechanism for using
           session keys in their security option.  When the Routing
           Protocol uses a transport substrate, e.g. the way BGP, LDP
           and MSDP use TCP, then this applies to the security mechanism



Lebovitz &                 Expires May 9, 2010                 [Page 27]

Internet-Draft                KARP Roadmap                 November 2009


           the includes that substrate.

   o  KeyStore -   Each implementation will also contain a protocol
           independent mechanism for storing keys, called KeyStore.  The
           KeyStore will have multiple different logical containers, one
           container for each session key that any given Routing
           Protocol will need.  Keys stored here may be a Peer Key or a
           Traffic Key. There may also be associated parameters as
           required by the SA for any given Routing Protocol.

   o  Peer Key  A key used between peers from which a traffic key is
           derived.  An example is a PSK.

   o  Traffic Key  The actual key used on each packet of a message.
           This key may be derived from the key existing in the
           KeyStore.  This will depend on whether the key in KeyStore
           was a manual PSK for the peers, or whether a connection-aware
           KMP created the key.  Further, it will be connection
           specific, so as to provide inter- and intra-connection replay
           protection.

   o  RoutingProtocol-KeyStore API -   There will be an API for Routing
           Protocol to retrieve (or receive; it could be a push or a
           pull) the keys from the KeyStore.  This will enable
           implementers to reuse the same API calls for all their
           Routing Protocols.  The API will necessarily include facility
           to retrieve other SA parameters required for the construction
           of the Routing Protocol's packets, like key IDs or key
           lifetimes, etc.

   o  KMP -   There will be an automated key management protocol, KMP.
           This KMP will run between the peers.  The KMP serves as a
           protected channel between the peers, through which they can
           negotiate and pass important data required to exchange proof
           of key identifiers, derive session keys, determine re-keying,
           synchronize their keying state, signal various keying events,
           notify with error messages, etc.  As an analogy, in the IPsec
           protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306
           [RFC4306]) IKEv2 is the KMP that runs between the two peers,
           while AH and ESP are two different base protocols that take
           session keys from IKEv2 and use them in their transmissions.
           In the analogy, the Routing Protocol, say BGP and LDP, are
           analogous to ESP and AH, while the KMP is analogous to IKEv2
           itself.







Lebovitz &                 Expires May 9, 2010                 [Page 28]

Internet-Draft                KARP Roadmap                 November 2009



   o  RoutingProtocol-KMP API -   There will be an API for the Routing
           Protocol to request a session key of the KMP, and be notified
           when the keys are available for it.  The API will also
           contain a mechanism for the KMP to notify the Routing
           Protocol that there are new keys that it must now use, even
           if it didn't request those keys.  The API will also include a
           mechanism for the KMP to receive requests for session keys
           and other parameters from the routing protocol.  The KMP will
           also be aware of the various Routing Protocols and each of
           their unique parameters that need to be negotiated and
           returned.

   o  KMP-KeyStore API -   There will be an API for the KMP to place
           keys and parameters into the KeyStore after their negotiation
           and derivation with the other peer.  This will enable the
           implementers to reuse the same calls for multiple KMPs that
           may be needed to address the various categories of Routing
           Protocols as described in the section definingcategories
           (Section 3).


   [after writing this all up, I'm not sure we really need the key_store
   in the middle.  As long as we standardize fully all the calls needed
   from any Routing Protocol to any KMP, then there can be a generic
   hand-down function from the KMP to the Routing Protocol when the key
   and parameters are ready.  Let's sleep on it.]

   [will need state machines and function calls for these APIs, as one
   of the work items.  In essence, there is a need for a core team to
   develop the APIs out completely in order for the Routing Protocol
   teams to use them.  Need to get this team going asap.]


   o Identifiers -   A KMP is fed by identities.  The identities are
           text strings used by the peers to indicate to each other that
           each are known to the other, and authorized to establish
           connections.  Those identities must be represented in some
           standard string format, e.g. an IP address -- either v4 or
           v6, an FQDN, an RFC 822 email address, a Common Name [RFC
           PKI], etc.  Note that even though routers do not normally
           have email addresses, one could use an RFC 822 email address
           string as a formatted identifier for a router.  They would do
           so simply by putting the router's reference number or name-
           code as the "NAME" part of the address, left of the "@"
           symbol.  They would then place some locational context in the
           "DOMAIN" part of the string, right of the "@" symbol.  An
           example would be "rtr0210@sf.ca.us.company.com".  This



Lebovitz &                 Expires May 9, 2010                 [Page 29]

Internet-Draft                KARP Roadmap                 November 2009


           document does not suggest this string value at all.  Instead,
           the concept is used only to clarify that the type of string
           employed does not matter.  It also does not matter what
           specific text you chose to place in that string type.  It
           only matters that the type of string -- and it's format --
           must be agreed upon by the two endpoints.  Further, the
           string can be used as an identifier in this context, even if
           the string is not actually provisioned in it's source domain.
           For example, the email address "rtr0210@sf.ca.us.company.com"
           may not actually exist as an email address in that domain,
           but that string of characters may still be used as an
           identifier type(s) in the routing protocol security context.
           What is important is that the community decide on a small but
           flexible set of Identifiers they will all support, and that
           they decide on the exact format of those string.  The formats
           that will be used must be standardized and must be sensible
           for the routing infrastructure.

   o  Identity Proof -   Once the form of identity is decided, then
           there must be a cryptographic proof of that identity, that
           the peer really is who they assert themselves to be.  Proof
           of identity can be arranged between the peers in a few ways,
           for example pre-shared keys, raw assymetric keys, or a more
           user-friendly representation of assymetric keys, like a
           certificate.  Certificates can be used in a way requiring no
           additional supporting systems -- e.g. public keys for each
           peer can be maintained locally for verification upon contact.
           Certificate management can be made more simple and scalable
           with the use minor additional supporting systems, as is the
           case with self-signed certificates and a flat file list of
           "approved thumbprints".  Self-signed certificates will have
           somewhat lower security properties than Certificate Authority
           signed certificates [RFC Certs].  The use of these different
           identity proofs vary in ease of deployment, ease of ongoing
           management, startup effort, ongoing effort and management,
           security strength, and consequences from loss of secrets from
           one part of the system to the rest of the system.  For
           example, they differ in resistance to a security breach, and
           the effort required to remediate the whole system in the
           event of such a breach.  The point here is that there are
           options, many of which are quite simple to employ and deploy.

   o  Profiles -   Once the KMP, Identifiers and Proofs mechanisms are
           converged upon, they must be clearly profiled for each
           Routing Protocol, so that implementors and deployers alike
           understand the different pieces of the solution, and can have
           similar configurations and interoperability across multiple
           vendors' devices, so as to reduce management difficulty.  The



Lebovitz &                 Expires May 9, 2010                 [Page 30]

Internet-Draft                KARP Roadmap                 November 2009


           profiles SHOULD also provide guidance on when to use which
           various combinations of options.  This will, again, simplify
           use and interoperability.

   In addition to other business, administrative, and operational terms
   they must already exchange prior to forming first adjacencies, it is
   assumed that two parties deploying message authentication on their
   routing protocol will also need to decide upon acceptable security
   parameters for the connection.  This will include the form and
   content of the identity each use to represent the other.  It will
   also include the type of keys to be used, e.g.  PSK, raw assymetric
   keys, certificate.  And it will include the acceptable cryptographic
   algorithms, or algorithm suite.  This agreement is necessary in order
   for each to properly configure the connection on their respective
   devices.  The manner in which they agree upon and exchange this
   policy information is normally via phone call or written exchange,
   and is outside the scope of the KARP effort, but assumed to have
   occured.  We take as a given that each party knows the identity types
   and values, key types and values, and acceptable cryptographic
   algorithms for both their own device and the peer that form the
   security policy for configuration on their device.

   Common Mechanisms - In as much as they exist, the framework will
   capture mechanisms that can be used commonly not only within a
   particular category of Routing Protocol and Routing Protocol to KMP,
   but also between Routing Protocol categories.  Again, the goal here
   is simplifying the implementations and runtime code and resource
   requirements.  There is also a goal here of favoring well vetted,
   reviewed, operationally proven security mechanisms over newly brewed
   mechanisms that are less well tried in the wild.

4.4.  Work Items Per Routing Protocol

   Each Routing Protocol will have a team (the [Routing_Protocol]-KARP
   team) working on incrementally improving their Routing Protocol's
   security, These teams will have the following main work items:

   PHASE 1:

   Characterize the RP
      Assess the Routing Protocol to see what authentication mechanisms
      it has today.  Does it needs significant improvement to its
      existing mechanisms or not?  This will include determining if
      modern, strong security algorithms and parameters are present.







Lebovitz &                 Expires May 9, 2010                 [Page 31]

Internet-Draft                KARP Roadmap                 November 2009



   Define Optimal State
      List the requirements for the Routing Protocol's session key usage
      and format to contain to modern, strong security algorithms and
      mechanisms, per the Requirements (Section 4.2) section above.  The
      goal here is to determine what is needed for they Routing Protocol
      alone to be used securely with at least manual keys.

   Gap Analysis
      Enumerate the requirements for this protocol to move from its
      current security state, the first bullet, to its optimal state, as
      listed just above.

   Transition and Deployment Considerations  Document the operational
      transition plan for moving from the old to the new security
      mechanism.  Will adjacencies need to bounce?  What new elements/
      servers/services in the infrastructure will be required?  What is
      an example work flow that an operator will take?  The best
      possible case is if the adjacency does not break, but this may not
      always be possible.

   Define, Assign, Design
      Create a deliverables list of the design and specification work,
      with milestones.  Define owners.  Release a document(s)


   PHASE 2:

   KMP Analysis
      Review requirements for KMPs [RFC????].  Identify any nuances for
      this particular protocol's needs and its use cases for KMP.  List
      the requirements that this Routing Protocol has for being able to
      be use in conjunctions with a KMP.  Define the optimal state.

   Gap Analysis
      Enumerate the requirements for this protocol to move from its
      current security state to its optimal state.

   Define, Assign, Design
      Create a deliverabels list of the design and specification work,
      with miletsones.  Define owners.  Do the design and document work
      for a KMP to be able to generate the Routing Protocol's session
      keys for the packets on the wire.  These will be the arguments
      passed in the API to the KMP in order to bootstrap the session
      keys to the Routing Protocol.

   There will also be a team formed to work on the base framework
   mechanisms for each of the main categories, i.e. the blocks and API's



Lebovitz &                 Expires May 9, 2010                 [Page 32]

Internet-Draft                KARP Roadmap                 November 2009


   represented in figure 1 (Figure 1).

4.5.  Protocols in Categories

   This section groups the Routing Protocols into like categories,
   according to attributes set forth in Categories Section (Section 3).
   Each group will have a design team tasked with improving the security
   of the Routing Protocol mechanisms and defining the KMP requirements
   for their group, then rolling both into a roadmap document upon which
   they will execute.

   BGP, LDP and MSDP
       The Routing Protocol's that fall into the category of the one-to-
       one peering messages, and will use peer keying protocols, AND are
       all transmitted over TCP include BGP RFC 4271 [RFC4271], LDP
       [RFC5036] and MSDP [RFC3618].  A team will work on one mechanism
       to cover these three protocols.  Much of the work on the Routing
       Protocol update for its existing authentication mechanism is
       already occuring in the TCPM Working Group, on the TCP-AO
       [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its
       cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto].  The
       exception is the mode where LDP is used directly on the LAN
       [RFC????].  The work for this may go into the Group keying
       category (w/ OSPF) mentioned below.

   OSPF, ISIS, and RIP
       The Routing Protocols that fall into the category Group keying
       with one-to-many peering messages includes OSPF [RFC2328], ISIS
       [RFC1195] and RIP [RFC2453].  Not surprisingly, all these routing
       protocols have two other things in common.  First, they are run
       on a combination of the OSI datalink layer 2, and the OSI network
       layer 3.  By this we mean that they have a component of how the
       routing protocol works which is specified in Layer 2 as well as
       in Layer 3.  Second, they are all internal gateway protocols, or
       IGPs.  The keying mechanisms and use will be much more
       complicated to define for these than for a one-to-one messaging
       protocol.

   BFD
       Because it is less of a routing protocol, per se, and more of a
       peer aliveness detection mechanism, Bidirectional Forwarding
       Detection (BFD) [RFC????] will have its own team.

   RSVP [RFC????], RSVP-TE [RFC????], and PCE







Lebovitz &                 Expires May 9, 2010                 [Page 33]

Internet-Draft                KARP Roadmap                 November 2009


       These three protocols will be handled together. [what more
       characterisation should we give here?  Routing AD's, provide text
       pls?]

   PIM-SM and PIM-DM
       Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM
       [RFC3973] will be handled together.  PIM-SM multicasts routing
       information (Hello, Join/Prune, Assert) on a link-local basis,
       using a defined multicast address.  In addition, it specifies
       unicast communication for exchange of information (Register,
       Register-Stop) between the router closest to a group sender and
       the "rendezvous point" (RP).  The RP is typically not "on-link"
       for a particular router.  While much work has been done on
       multicast security for application-layer groups, little has been
       done to address the problem of managing hundreds or thousands of
       small one-to-many groups with link-local scope.  Such an
       authentication mechanism should be considered along with the
       router-to-Rendezvous Point authentication mechanism.  The most
       important issue is ensuring that only the "authorized neighbors"
       get the keys for (S,G), so that rogue routers cannot participate
       in the exchanges.  Another issue is that some of the
       communication may occur intra-domain, e.g. the link-local
       messages in an enterprise, while others for the same (*,G) may
       occur inter-domain, e.g. the router-to-Rendezvous Point messges
       may be from one enterprise's router to another.  One possible
       solution proposes a region-wide "master" key server (possibly
       replicated), and one "local" key server per speaking router.
       There is no issue with propagating the messages outside the link,
       because link-local messages, by definition, are not forwarded.
       This solution is offered only as an example of how work may
       progress; further discussion should occur in this work team.
       Specification of a link-local protection mechanism for PIM-SM
       occurred in RFC 4601 [RFC4601], and this work is being updated in
       PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal].  However, the KMP
       part is completely unspecified, and will require work outside the
       expertise of the PIM working group to accomplish, which is why
       this roadmap is being created.

   These protocols are deemed out-of-scope for this current iteration of
   the work roadmap.  Once all of the protocols listed above have had
   their work completed, or are clearly within site of completion, then
   the community will revisit the need and interest for working on
   these:

   o  MANET
   o  FORCES

   [need text from routing ADs on why these are out of scope]



Lebovitz &                 Expires May 9, 2010                 [Page 34]

Internet-Draft                KARP Roadmap                 November 2009


4.6.  Priorites

   Resources from both the routing area and the security area will be
   applied to work on these problem spaces as quickly as possible.
   Realizing that such resources are far from unlimited, a rank order
   priority for addressing the work of incrementally securing these
   groups of routing protocols is provided:

   o  Priority 1 - BGP / LDP / MSDP - almost done with Phase 1 on these,
      via TCP-AO [I-D.ietf-tcpm-tcp-auth-opt] .
   o  Priority 2 - PIM-SM
   o  Priority 3 - OSPF / ISIS / RIP
   o  Priority 4 - BFD
   o  Priority 5 - RSVP and RSVP-TE

   By far the most important group is the Priority 1 group as these are
   the protocols used on the most public and exposed segments of the
   networks, at the peering points between operators and between
   operators and their customers.  BFD, as a detection mechanism
   underlying the Priority 1 protocols is therefore second.


5.  Security Considerations

   As mentioned in the Introduction , RFC4948 identifies additional
   steps needed to achieve the overall goal of improving the security of
   the core routing infrastructure.  Those include validation of route
   origin announcements, path validation, cleaning up the IRR databases
   for accuracy, and operational security practicies that prevent
   routers from being compromised devices.  The KARP work is but one
   step in a necessary system of security improvements.

   The security of cryptographic-based systems depends on both the
   strength of the cryptographic algorithms chosen and the strength of
   the keys used with those algorithms.  The security also depends on
   the engineering of the protocol used by the system to ensure that
   there are no non-cryptographic ways to bypass the security of the
   overall system.

   Care should also be taken to ensure that the selected key is
   unpredictable, avoiding any keys known to be weak for the algorithm
   in use.  [RFC4086] contains helpful information on both key
   generation techniques and cryptographic randomness.

   In addition to using a stong key/PSK of appropriate length and
   randomness, deployers of KARP protocols SHOULD use different keys
   between different routing peers whenever operationally possible.
   RFC3562 [RFC3562] provides some very sound guidance.  It was meant



Lebovitz &                 Expires May 9, 2010                 [Page 35]

Internet-Draft                KARP Roadmap                 November 2009


   specifically for the use of TCP MD5 for BGP, but it is more or less
   applicable to Routing Protocol authentication work that would result
   from KARP.  It states three main points: (1) key lengths SHOULD be
   between 12 and 24 bytes (this will vary depending on the MAC/KDF in
   use), with larger keys having effectively zero additional
   computational costs when compared to shorter keys, (2) key sharing
   SHOULD be limited so that keys aren't shared among multiple BGP
   peering arrangements, and (3) Keys SHOULD be changed at least every
   90 days (this could be longer for stronger MAC algorithms, but it is
   generally a wise idea).

   This is especially true when the Routing Protocol takes a static
   Traffic Key as opposed to a Traffic Key derived per-connection by a
   KDF.  The burdon for doing so is understandable much higher than for
   using the same static Traffic Key across all peering routers.  This
   is why use of a KMP network-wide increases peer-wise security so
   greatly, because now each set of peers can enjoys a unique Traffic
   Key, and if an attacker sitting between two routers learns or guesses
   the Traffic Key for that connection, she doesn't gain access to all
   the other connections as well.

   However, whenever using manual keys, it is best to design a system
   where a given PSK will be used in a KDF, mixed with connection
   specific material, in order to generate session unique -- and
   therefore peer-wise -- Traffic Keys.  Doing so has the following
   advantages: the Traffic Keys used in the per-message MAC operation
   are peer-wise unique, it provides inter-connection replay protection,
   and, if the per-message MAC covers some connection counter, intra-
   connection replay protection.

   Note that in the composition of certain key derivation functions
   (e.g.  KDF_AES_128_CMAC, as used in TCP-AO [I-D.ao-crypto]), the
   pseudorandom function (PRF) used in the KDF may require a key of a
   certain fixed size as an input.  For example, AES_128_CMAC requires a
   128 bit (16 byte) key as the seed.  However, for convenience to the
   administrators/deployers, a specification may not want to force the
   deployer to enter a PSK of exactly 16 bytes.  Instead, a
   specification may call for a sub-key routine that could handle a
   variable length PSK, one that might be less than 16 bytes (see
   [RFC4615], section 3, as an example).  That sub-key routine would act
   as a key extractor to derive a second key of exactly the required
   length, and thus suitable as a seed to the PRF.  This does NOT mean
   that administrators are safe to use weak keys.  Administrators are
   encouraged to follow [RFC4086] as listed above.  We simply attempted
   to "put a fence around stupidity", in as much as possible.

   A better option, from a security perspective, is to use some
   representation of a device-specific assymetric key pair as the



Lebovitz &                 Expires May 9, 2010                 [Page 36]

Internet-Draft                KARP Roadmap                 November 2009


   identity proof, as described in Section 3.4.2.

   When it comes time for the KARP WG to design the re-usable model for
   a KMP, The Guidelines for Cryptographic Key Management, RFC4107
   [RFC4107] should be will be consulted.

   [[QUESTION TO REVIEWERS: it may be worthwhile to pull the last few
   paragraphs, along with some guidance along the same lines, into
   section 4, in a new sub-section with a title something like "Security
   tips for KARP design teams working on Routing Protocol reviews and
   updates".  Or maybe even into its own info document, "Security
   Guidelines for KARP Design Teams".Thoughts?]]

   The mechanisms that will be defined under this roadmap aim to improve
   the security, better protect against more threats, and provider far
   greater operational efficiencies than the state of things at the time
   of this writing.  However, none of these changes will improve
   Internet security unless they are implemented and deployed.  Other
   influences must be brought to bare upon operators and organizations
   to create incentives for deployment.  Such incentives may take the
   form of PCI-like industry compliance/certifications, well advertised
   BCPs profiling the use of this roadmap's output, end-user demand or
   insistance.


6.  IANA Considerations

   This document has no actions for IANA.


7.  Acknowledgements

   The outline for this draft was created from discussions and
   agreements with Routing AD's Ross Callon and Dave Ward, Security AD's
   Tim Polk and Pasi Eronen, and IAB members Danny McPherson and Gregory
   Lebovitz.

   Mat Ford and Bill Atwood provided reviews to -00.

   Danny McPherson provided an extremely detailed and useful review of
   -01.


8.  Change History (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]




Lebovitz &                 Expires May 9, 2010                 [Page 37]

Internet-Draft                KARP Roadmap                 November 2009


   -00-00 original rough rough rough draft for review by routing and
   security AD's

   -00- original submission

   o  adds new category = multicast protocols in category section and
      mentions mcast in group keying category description.
   o  add a lot of references where they did not exist before, or where
      there were only place holders.  Still more work needed on this.
   o  abstract filled in
   o  changed from standards track to informational (this was an
      oversight in last draft).
   o  filled out threats section with detailed descriptions, and linked
      to RPsec threats RFC
   o  made ascii art for the basic KMP framework
   o  added section on internal versus external peering and the
      requirements decisions for them
   o  added security characterization section in sect 2, added sections
      discussing internal vs external protocols, shared vs unique keys,
      oob vs in-band keying
   o  incorporates all D Ward's feedback from his initial skim of the
      document.

   -01-

   o  Updated framework (Figure 1) diagram to include all listed and
      described elements.  Needs review and honing.  Gregory Lebovitz
      (GL).
   o  Added comment in protocols (Section 4.5) section that much of the
      BGP/LDP Phase 1 work is already being done in tcp-ao and ao-
      crypto.  GL.
   o  Updated Scope making the 2 work phases more clear earlier in the
      document.  GL.
   o  Broke work items (Section 4.4) section into two Phases, 1 for
      manual key update, and second for KMP work.  GL.
   o  Re-org'd doc.  Brought Threats (Section 2) section out into its
      own top-level section.  Did same with Categorization (Section 3)
      section, leaving Roadmap section more focused.  Moved ToDo list
      and Change History to end of doc, after Acknowledgements.  GL.
   o  added new sect 2.3 (Section 4.1) on main roadmap phases.  Previous
      section Common Framework (Section 4.3) moved to 2.4.  Tim Polk
      (TP).
   o  Added Section 2.3.1 Requirements for Phase 1 Routing Protocols'
      Security Update (Section 4.2).  This provides a nice starter set
      of requirements for any work team.  GL.
   o  Filled out text for Out vs In-band Key Mgmt (Section 3.4.3)
      section, significantly.  Changed the term from "in-band" to "in-
      line".



Lebovitz &                 Expires May 9, 2010                 [Page 38]

Internet-Draft                KARP Roadmap                 November 2009


   o  Section Threats (Section 2) Clarified DoS threats in and out of
      scope better.  We are not preventing all DoS attacks.  Just those
      we can reasonably via authentication.  TP.
   o  Sect In-band vs Out-of-Band (Section 3.4.3)clarified that In-band
      does not mean in-band to Routing Protocol, but rather over IP
      between the Routing Protocols, rather than pushed down by some
      external management entity.  TP.
   o  In roadmap (Section 3) section, added "it is also hoped that we
      can create one kmp per category..."  Also explained value of a
      KMP.  TP.
   o  Added "operators" to audience (Section 1.6) list.  Matt Ford (MF).
   o  Described why BGP (and LDP) security is not deployed very often.
      Added this Scope (Section 1.3) section, point 4.  If mechanisms
      aren't being deployed, why is that?  What, if anything, could be
      done to improve deployment?  Tried to address these.  Need
      references (see To Do list below).  MF.
   o  Added some text to security section to address this from MF: say
      something here about the limitations of this approach, if any -
      and refer back to the need for other pieces of the puzzle.  May
      need more work.
   o  Cleaned up text for multicast part of Message Type (Section 3.1)
      section and Protocols (Section 4.5) section, clarifying PIM's two
      message types, mcast and unicast, in both places.  Bill Atwood
      (BA).
   o  In section Protocols (Section 4.5), added references to 4601 and
      PIM-SM-LINKLOCAL.  BA.
   o  Editorial changes pointed out various folks.

   -02-

   o  Re-submitted due to expiration.  Text did not change.  Substantive
      update coming shortly.
   o
   o

   - 03 -

   o  changed "BaseRP" to "Routing Protocol" throughout the doc - man
   o  filled out the Terminology section
   o  changed "KMART" to "KARP" in everything but the title, since the
      -00 deadline had long since passed.  Will change the title of the
      doc to KARP as soon as the window re-opens.
   o  priorities in sect 4.6 changed.  Added PIM-SM.  Lowered OSPF and
      BFD, based on feedback by a few people.
   o  many edits resulting from Danny McPherson's review.
   o  added "Brute Foce Attacks Against Password/Keys" to Threats
      Section 2.1 section.




Lebovitz &                 Expires May 9, 2010                 [Page 39]

Internet-Draft                KARP Roadmap                 November 2009


   o  Significant updates to Security Considerations section
   o  Added a few references throughout to RFC3562
   o  4.3 2nd to last P - added a comment to clarify that two parties
      (or an org) must discuss ahead of time what they want their
      connections' secruity properties to be. - dward
   o  added to 4.4 Phase 1 - New Section: Transition and Deployment
      Considerations. ea wg must call out the operational transition
      plan from old to new security.  Best if don't bounce link. - dward
   o  added 3.3 (but not sure if this is right)- endpoint discovery
      mechanisms? endpoint discovery mechanism (L2VPN, L3VPN, etc).
      Discovery is much different security properties than passing
      Routing updates. - dward
   o  More requirements: Added to 4.2: X - convergence SHOULD not be
      affected by what we choose; adding security SHOULD not cause a
      refresh of route updates or cause additional route updates to be
      generated; adding auth should not be an attack vector itself.
      AKA, the use of MD5 is so expensive that spoofing BGP packets w/
      MD5 causes the control plane to be attacked because CPU went to
      100% - dward
   o  updated stats on MD5 usage, and cited [ISR2008]. - mchpherson


9.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   List of stuff that still needs work
   o  RTG AD's or delegates: clean up the three definitions of route
      message type categories.  Need RTG Area folks input on this.
   o  More clarity on the work items for those defining and specifying
      the framework elements and API's themselves.
   o  RTG AD's or delegates: text justifying RSVP and RSVP-TE and what
      we think solving that problem may look like
   o  RTG AD's or delegates: more justification for why MANET and FORCES
      are out of scope.  Need ref for those RFCs.
   o  Danny McPherson: Get reference for BGP auth usage stats in Scope
      (Section 1.3) section, item 4.
   o
   o  security section: pull out security guidance to routing protocol
      design teams stuff and place into its own section?
   o
   o


10.  References





Lebovitz &                 Expires May 9, 2010                 [Page 40]

Internet-Draft                KARP Roadmap                 November 2009


10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

   [RFC4948]  Andersson, L., Davies, E., and L. Zhang, "Report from the
              IAB workshop on Unwanted Traffic March 9-10, 2006",
              RFC 4948, August 2007.

10.2.  Informative References

   [I-D.ao-crypto]
              Lebovitz, G., "Cryptographic Algorithms, Use and
              Implementation Requirements for TCP Authentication
              Option", March 2009, <http://tools.ietf.org/html/
              draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00>.

   [I-D.ietf-pim-sm-linklocal]
              Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in PIM-SM Link-local Messages",
              draft-ietf-pim-sm-linklocal-09 (work in progress),
              October 2009.

   [I-D.ietf-tcpm-tcp-auth-opt]
              Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08
              (work in progress), October 2009.

   [ISR2008]  McPherson, D. and C. Labovitz, "Worldwide Infrastructure
              Security Report", October 2008,
              < http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf>.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453,
              November 1998.

   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
              Signature Option", RFC 3562, July 2003.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.



Lebovitz &                 Expires May 9, 2010                 [Page 41]

Internet-Draft                KARP Roadmap                 November 2009


   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, June 2005.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4615]  Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
              PRF-128) Algorithm for the Internet Key Exchange Protocol
              (IKE)", RFC 4615, August 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.










Lebovitz &                 Expires May 9, 2010                 [Page 42]

Internet-Draft                KARP Roadmap                 November 2009


Authors' Addresses

   Gregory Lebovitz
   Juniper Networks, Inc.
   1194 North Mathilda Ave.
   Sunnyvale, CA  94089-1206
   US

   Phone:
   Email: gregory.ietf@gmail.com




   Phone:
   Email:



































Lebovitz &                 Expires May 9, 2010                 [Page 43]


                  discovery process.  These messages are normally
                  exchanged prior to any adjacency being formed, and
                  before any updates are sent.  For example, end-point
                  discovery mechanisms are common in L2VPN and L3VPN
                  solutions.

   [QUESTION TO REVIEWERS: is this really just what's described in 3.1
   as "Client-Server" and/or "One-to-One"?  Is there really such a
   different in discovery protocols that they need their own category to
   figure out how to authenticate them?  Can someone provide a few
   examples?

3.4.  Security Characterization Vectors

   A few more considerations must be made about the protocol and its use
   when initially categorizing the protocol and scoping the
   authentication work.

3.4.1.  Internal vs. External Operation

   The designers must consider whether the protocol is an internal
   routing protocol or an external one, i.e.  Does it primarily run
   between peers within a single domain of control or between two
   different domains of control?  Some protocols may be used in both
   cases, internally and externally, and as such various modes of
   authentication operation may be required for the same protocol.
   While it is preferred that all routing exchanges run with the utmost
   security mechanisms enabled in all deployments, this exhortation is
   greater for those protocols running on inter-domain point-to-point
   links, and greatest for those on shared access link layers with
   several different domains interchanging together, because the volume
   of attackers are greater from the outside.  Note however that the
   consequences of internal attacks maybe no less severe -- in fact they
   may be quite a bit more severe -- than an external attack.  An
   example of this internal versus external consideration is BGP which
   has both EBGP and IBGP modes.  Another example is a multicast
   protocol where the neighbors are sometimes within a domain of control
   and sometimes at an inter-domain exchange point.  In the case of



Lebovitz &                 Expires May 9, 2010                 [Page 18]

Internet-Draft                KARP Roadmap                 November 2009


   PIM-SM running on an internal multi-access link, It would be
   acceptable to give up some security to get some convenience by using
   a group key between the peers on the link.  On the other hand, in the
   case of PIM-SM running over a multi-access link at a public exchange
   point, operators may favor security over convenience by using unique
   pair-wise keys for every peer.  Designers must consider both modes of
   operation and ensure the authentication mechanisms fit both.

   Operators are encouraged to run cryptographic authentication on all
   their adjacencies, but to work from the outside in, i.e.  The EBGP
   links are a higher priority than the IBGP links because they are
   externally facing, and, as a result, more likely to be targeted in an
   attack.

3.4.2.  Unique versus Shared Keys

   This section discusses security considerations regarding when it is
   appropriate to use the same authentication key inputs for multiple
   peers and when it is not.  This is largely a debate of convenience
   versus security.  It is often the case that the best secured
   mechanism is also the least convenient mechanism.  For example, an
   air gap between a host and the network absolutely prevents remote
   attacks on the host, but having to copy and carry files using the
   "sneaker net" is quite inconvenient and unscalable.

   Operators have erred on the side of convenience when it comes to
   securing routing protocols with cryptographic authentication.  Many
   do not use it at all.  Some use it only on external links, but not on
   internal links.  Those that do use it often use the same key for all
   peers across their entire network.  It is common to see the same key
   in use for years, and that being the same key that was entered when
   authentication was originally configured, or the routing gear
   deployed.

   The goal for designers is to create authentication mechanisms that
   are easy for the operators to deploy and manage, and still use unique
   keys between peers (or small groups on multi-access links), and
   within between sessions.  Operators have the impression that they
   NEED one key shared across the network, when in fact they do not.
   What they need is the relative convenience they experience from
   deploying cryptographic authentication with one (or few) key,
   compared to the inconvenience they would experience if they deployed
   the same authentication mechanism using unique pair-wise keys.  An
   example is BGP Route Reflectors.  Here operators often use the same
   authentication key between each client and the route reflector.  The
   roadmaps defined from this guidance document will allow for unique
   keys to be used between each client and the peer, without sacrificing
   much convenience.  Designers should strive to deliver peer-wise



Lebovitz &                 Expires May 9, 2010                 [Page 19]

Internet-Draft                KARP Roadmap                 November 2009


   unique keying mechanisms with similar ease-of-deployment properties
   as today's one-key method.

   Operators must understand the consequences of using the same keys
   across many peers.  Unique keys are more secure than shared keys
   because they reduce both the attack target size and the attack
   consequence size.  In this context, the attack target size represents
   the number of unique routing exchanges across a network that an
   attacker may be able to observe in order to gain security association
   credentials, i.e. crack the keys.  If a shared key is used across the
   entire internal domain of control, then the attack target size is
   very large.  The larger the attack target, the easier it is for the
   attacker to gain access to analysis data, and greater the volume of
   analysis data he can access in a given time frame, both of which make
   his job easier.  Using the same key across the network makes the
   attack vulnerability surface more penetrable than unique keys.
   Consider also the attack consequence size, the amount of routing
   adjacencies that can be negatively affected once a breach has
   occurred, i.e. once the keys have been acquired by the attacker.
   Again, if a shared key is used across the internal domain, then the
   consequence size is the whole network.  Ideally, unique key pairs
   would be used for each adjacency.

   In some cases designers may need to use shared keys in order to solve
   the given problem space.  For example, a multicast packet is sent
   once but then observed and consumed by several routing neighbors.  If
   unique keys were used per neighbor, the benefit of multicast would be
   erased because the casting peer would have to create a different
   announcement packet/stream for each listening peer.  Though this may
   be desired and acceptable in some small amount of use cases, it is
   not the norm.  Shared group keys are an acceptable solution here, and
   much work has been done already in this area (see MSEC working
   group).

3.4.3.  Out-of-Band vs. In-line Key Management

   This section discusses the security and use case considerations for
   keys placed on devices through out-of-band configurations versus
   through one routing peer-to-peer key management protocol exchanges.
   Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to
   the Routing Protocol.  Instead, we mean that the exchange occurs in-
   line, over IP, between the two routing peers directly.  In in-line
   KMP the peers themselves handle the key and security association
   negotiation between themselves directly, whereas in an out-of-band
   system the keys are placed onto the device through some other
   configuration or management method or interface.

   An example of an out-of-band mechanism could be an administrator who



Lebovitz &                 Expires May 9, 2010                 [Page 20]

Internet-Draft                KARP Roadmap                 November 2009


   makes a remote management connection (e.g. using SSH) to a router and
   manually enters the keying information -- like the algorithm, the
   key(s), the lifetimes, etc.  Another example could be an OSS system
   which inputs the same information via a script over an SSH
   connection, or by pushing configuration through some other management
   connection, standard (Netconf-based) or proprietary.

   The drawbacks of an out-of-band mechanism include: lack of scale-
   ability, complexity and speed of changing if a breach is suspected.
   For example, if an employee who had access to keys was was
   terminated, or if a machine holding those keys was belived
   compromised, then the system would be considered insecure and
   vulnerable until new keys were defined by a human.  Those keys then
   need to be placed into the OSS system, manually, and the OSS system
   then needs to push the change -- often during a very limited change
   window -- into the relevant devices.  If there are multiple
   organizations involved in these connections, this process is greatly
   complicated.

   The benefits of out-of-band mechanism is that once the new keys/
   parameters are set in OSS system they can be pushed automatically to
   all devices within the OSS's domain of control.  Operators have
   mechanisms in place for this already.  In small environments with few
   routers, a manual system is not difficult to employ.

   We further define an in-line key exchange as using cryptographicly
   protected identity verification, session key negotiation, and
   security association parameter negotiation between the two routing
   peers.  The KMP between the two peers may also include the
   negotiation of parameters, like algorithms, cryptographic inputs
   (e.g. initialization vectors), key life-times, etc.

   The benefits an in-line KMP are several.  An in-line KMP results in
   key(s) that are privately generated, and not recorded permanently
   anywhere.  Since the traffic keys used in a particular connection are
   not a fixed part of a device configuration no steal-able data exists
   anywhere else in the operator's systems which can be stolen, e.g. in
   the case of a terminated or turned employee.  If a server or other
   data store is stolen or compromised, the thieves gain no access to
   current traffic keys.  They may gain access to key derivation
   material, like a PSK, but not current traffic keys in use.  In this
   example, these PSKs can be updated into the device configurations
   (either manually or through an OSS) without bouncing or impacting the
   existing session at all.  In the case of using raw assymetric keys or
   certificates, instead of PSKs, the data theft would likely not even
   result in any compromise, as the key pairs would have been generated
   on the routers, and never leave those routers.  In such a case no
   changes are needed on the routers; the connections will continue to



Lebovitz &                 Expires May 9, 2010                 [Page 21]

Internet-Draft                KARP Roadmap                 November 2009


   be secure, uncompromised.  Additionally, with a KMP regular re-keys
   operations occur without any operator involvement or oversight.  This
   keeps keys fresh.

   The drawbacks to using a KMP are few.  First, a KMP requires more
   cryptographic processing for the router at the very beginning of a
   connection.  This will add some minor start-up time to connection
   establishment versus a purely manual key approach.  Once a connection
   with traffic keys have been established via a KMP, the performance is
   the same in the KMP and the out-of-band case.  KMPs also add another
   layer of protocol and configuration complexity which can fail or be
   misconfigured.  This was more of an issue when these KMPs were first
   deployed, but less so as these implementaitons and operational
   experience with them has matured.

   The desired end goal is in-line KMPs.


4.  The Roadmap

4.1.  Work Phases on any Particular Protocol

   The desired endstate for the KARP work contains several items.
   First, the people desiring to deploy securely authenticated and
   integrity validated packets between routing peers have the tools
   specified, implemented and shipping in order to deploy.  These tools
   should be fairly simple to implement, and not more complex than the
   security mechanisms to which the operators are already accustomed.
   (Examples of security mechanisms to which router operators are
   accustomed include: the use of assymetric keys for authentication in
   SSH for router configuration, the use of pre-shared keys (PSKs) in
   TCP MD5 for BGP protection, the use of self-signed certificates for
   HTTPS access to device Web-based user interfaces, the use of strongly
   constructed passwords and/or identity tokens for user identification
   when logging into routers and management systems.)  While the tools
   that we intend to specify may not be able to stop a deployment from
   using "foobar" as an input key for every device across their entire
   routing domain, we intend to make a solid, modern security system
   that is not too much more difficult than that.  In other words,
   simplicity and deployability are keys to success.  The Routing
   Protocols will specify modern cryptographic algorithms and security
   mechanisms.  Routing peers will be able to employ unique, pair-wise
   keys per peering instance, with reasonable key lifetimes, and
   updating those keys on a somewhat regular basis will be operationally
   easy, causing no service interruption.

   Achieving the above described end-state using manual keys may only be
   pragmatic in very small deployments.  In larger deployments, this end



Lebovitz &                 Expires May 9, 2010                 [Page 22]

Internet-Draft                KARP Roadmap                 November 2009


   state will be much more operationally difficult to reach with only
   manual keys.  Thus, there will be a need for key life cycle
   management, in the form of a key management protocol, or KMP.  We
   expect that the two forms, manual key usage and KMP usage, will co-
   exist in the real world.  For example, a provider's edge router at a
   public exchange peering point will want to use a KMP for ensuring
   unique and fresh keys with external peers, while a manual key may be
   used between a provider's access edge router and each of the same
   provider's customer premise routers with which it peers.

   In accordance with the desired end state just described, we define
   two main work phases for each Routing Protocol:

   1.  Enhance the Routing Protocol's current authentication mechanism.
       This work involves enhancing a Routing Protocol's current
       security mechanisms in order to achieve a consistent, modern
       level of security functionality within its existing keying
       framework.  It is understood and accepted that the existing
       keying frameworks are largely based on manual keys.  Since many
       operators have already built operational support systems (OSS)
       around these manual key implementations, there is some automation
       available for an operator to leverage in that way, if the
       underlying mechanisms are themselves secure.  In this phase, we
       explicitly exclude embedding or creating a KMP.  A list of the
       requirements for Phase 1 work are below in the section
       "Requirements for Phase 1 Routing Protocols' Security Updates
       (Section 4.2).

   2.  Develop an automated keying framework.  The second phase will
       focus on the development of an automated keying framework to
       faciliate unique pair-wise (or perhaps group-wise, where
       applicable) keys per peering instance.  This involves the use of
       a KMP.  A KMP is helpful because it negotiates unique, pair wise,
       random keys without administrator involvement.  It also
       negotiates several of the SA parameters required for the secure
       connection, including key life times.  It keeps track of those
       lifetimes using counters, and negotiates new keys and parameters
       before they expire, again, without administrator interaction.
       Additionally, in the event of a breach, changing the KMP key will
       immediately cause a rekey to occur for the Traffic Key, and those
       new Traffic Keys will be installed and used in the current
       connection.  In summary, a KMP provides a protected channel
       between the peers through which they can negotiate and pass
       important data required to exchange proof of key identifiers,
       derive Traffic Keys, determine re-keying, synchronize their
       keying state, signal various keying events, notify with error
       messages, etc.  To address brute force attacks [RFC3562]
       recommends a key management practice to minimize the possibility



Lebovitz &                 Expires May 9, 2010                 [Page 23]

Internet-Draft                KARP Roadmap                 November 2009


       of successful attack-- frequent key rotation, limited key
       sharing, key length restrictions, etc.  Advances in computational
       power due to Moore's law are making that management burden
       untenable-- keys must be of a size and composition that makes
       configuration and maintance difficult or keys must be rotated
       with an unreasonable frequency.  A KMP will help immensely with
       this growing problem.

       The framework for any one Routing Protocol will fall under, and
       be able to leverage, the generic framework described below in
       section Section 4.3.

4.2.  Requirements for Phase 1 Routing Protocols' Security Update

   Here is a proposed list of requirements that SHOULD be addressed by
   Phase 1 (according to "1." above) security updates to Routing
   Protocols [to be reviewed after -01 is released]:

   1.   Clear definitions of which elements of the transmission (frame,
        packet, segment, etc.) are protected by the authentication
        mechanism
   2.   Strong algorithms, and defined and accepted by the security
        community, MUST be specified.  The option should use algorithms
        considered accepted by the security community, which are
        considered appropriately safe.  The use of non-standard or
        unpublished algorithms SHOULD BE avoided.
   3.   Algorithm agility for the cryptograhpic algorithms used in the
        authentication MUST be specified, i.e. more than one algorithm
        MUST be specified and it MUST be clear how new algorithms MAY be
        specified and used within the protocol.  This requirement exists
        in case one algorithm gets broken suddenly.  Research to
        identify weakness in algorithms is constant.  Breaking a cipher
        isn't a matter of if, but when it will occur. t's highly
        unlikely that two different algorithms will be broken
        simultaneously.  So, if two are supported, and one gets broken,
        we can use the other until we get a new one in place.  Having
        the ability within the protocol specification to support such an
        event, having algorithm agility, is essential.  Mandating two
        algorithms provides both a redundancy, and a mechanism for
        enacting that redundancy when needed.
   4.   Secure use of simple PSKs, offering both operational convenience
        as well as building something of a fence around stupidity, MUST
        be specified.
   5.   Inter-connection replay protection.  Packets captured from one
        connection MUST NOT be able to be re-sent and accepted during a
        later connection.





Lebovitz &                 Expires May 9, 2010                 [Page 24]

Internet-Draft                KARP Roadmap                 November 2009


   6.   Intra-connection replay protection.  Packets captured during a
        connection MUST NOT be able to be re-sent and accepted during
        that same connection, to deal with long-lived connections.
   7.   A change of security parameters REQUIRES, and even forces, a
        change of session traffic keys
   8.   Intra-connection re-keying which occurs without a break or
        interruption to the current peering session, and, if possible,
        without data loss, MUST be specified.
   9.   Efficient re-keying SHOULD be provided.  The specificaion SHOULD
        support rekeying during a connection without the need to expend
        undue computational resources.  In particular, the specification
        SHOULD avoid the need to try/compute multiple keys on a given
        packet.
   10.  Prevent DoS attacks as those described as in-scope in the
        threats section Section 2.1 above.
   11.  Default mechanisms and algorithms specified and defined as
        REQUIRED for all implementations
   12.  Manual keying MUST be supported.
   13.  Convergence times of the Routing Protocols SHOULD NOT be
        materially affected.  Materially here is defined as anything
        greater than a 5% convergence time increase.  Note that
        convergence is different than boot time.  Also note that
        convergence time has a lot to do with the speed of processors
        used on individual routing peers, and this increases by Moore's
        law over time.  Therefore, this requirement should be considered
        only in terms of total number of messages that must be
        exchanged, and less for the computational intensity of
        processing any one message.
   14.  The changes or addition of security mechanisms SHOULD NOT cause
        a refresh of route updates or cause additional route updates to
        be generated
   15.  Architecture of the specification MUST consider and allow for
        future use of a KMP.

4.3.  Common Framework

   Each of the categories of routing protocols above will require unique
   designs for authenticating and integrity checking their protocols.
   However, a single underlying framework for delivering automatic
   keying to those solutions will be pursued.  Providing such a single
   framework will significantly reduce the complexity of each step of
   the overall roadmap.  For example, if each Routing Protocol needed to
   define it's own key management protocol this would balloon the total
   amount of different sockets that are needed to be opened and
   processes that are needed to be simultaneously running on an
   implementation.  It would also significantly increase the run-time
   complexity and memory requirements of such systems running multiple
   Routing Protocols, causing perhaps slower performance of such



Lebovitz &                 Expires May 9, 2010                 [Page 25]

Internet-Draft                KARP Roadmap                 November 2009


   systems.  However, if we can land on a very small set (perhaps one or
   two) of automatic key management protocols, KMPs, that the various
   Routing Protocols can use, then we can reduce this implementation and
   run-time complexity.  We can also decrease the total amount of time
   implementers need to deliver the KMPs for the Routing Protocols that
   will provide better threat protection.

   The components for the framework are listed here, and described
   below:

   o  Routing Protocol security mechanism
   o  KMP
   o  KeyStore
   o  Traffic Key
   o  RoutingProtocol-to-KMP API
   o  RoutingProtocol-to-KeyStore API
   o  KMP-to-KeyStore API
   o  Common Routing Protocol mechanisms
   o  Identifiers
   o  Proof of identity
   o  Profiles

   The framework is modularized for how keys and security association
   (SA) parameters generally get passed from a KMP to a transport
   protocol.  It contains three main blocks and APIs.


























Lebovitz &                 Expires May 9, 2010                 [Page 26]

Internet-Draft                KARP Roadmap                 November 2009


      +------------+   +--------------------+
      |            |   |                    | Check     +-----------+
      | Identifier +-->|                    +---------->|           |
      |            |   |    KMP Function    |           |  Identity |
      +----------- +   |                    |<----------+   Proof   |
                       |                    |  Approve  |           |
                       +-+--------------+---+           +-----------+
                         |              |
         KMP-to-KeyStore |              |
            API          |              |
                        \|/             |
                 +-------+-------+      |
                 |               |      | KMP-to-RoutingProtocol
                 |               |      |  API
                 |    KeyStore   |      |
                 |               |      |
                 +-------+-------+      |
                         |              |
                         |              |
           KeyStore-to-  |              |
    RoutingProtocol API  |              |
                         |             \|/
             +--------------------------+-------------+
             |           |                            |
             |          \|/          Common RtgProto  |
             |   +-------+-------+   Authentication   |
             |   |               |   Mechanisms       |
             +---|  Traffic      |-----+--------------+
             |   |   Key(s)      |                    |
             |   |               |                    |
             |   +---------------+   Specific         |
             |                       RoutingProtocol  |
             |                       Authentication   |
             |                       Security         |
             |                       Mechanism        |
             +----------------------------------------+


               Figure 1: Automatic Key Management Framework

   Each element of the framework is described here:


   o  Routing Protocol -  Routing protocol security mechanism - In each
           case, the Routing Protocol will contain a mechanism for using
           session keys in their security option.  When the Routing
           Protocol uses a transport substrate, e.g. the way BGP, LDP
           and MSDP use TCP, then this applies to the security mechanism



Lebovitz &                 Expires May 9, 2010                 [Page 27]

Internet-Draft                KARP Roadmap                 November 2009


           the includes that substrate.

   o  KeyStore -   Each implementation will also contain a protocol
           independent mechanism for storing keys, called KeyStore.  The
           KeyStore will have multiple different logical containers, one
           container for each session key that any given Routing
           Protocol will need.  Keys stored here may be a Peer Key or a
           Traffic Key. There may also be associated parameters as
           required by the SA for any given Routing Protocol.

   o  Peer Key  A key used between peers from which a traffic key is
           derived.  An example is a PSK.

   o  Traffic Key  The actual key used on each packet of a message.
           This key may be derived from the key existing in the
           KeyStore.  This will depend on whether the key in KeyStore
           was a manual PSK for the peers, or whether a connection-aware
           KMP created the key.  Further, it will be connection
           specific, so as to provide inter- and intra-connection replay
           protection.

   o  RoutingProtocol-KeyStore API -   There will be an API for Routing
           Protocol to retrieve (or receive; it could be a push or a
           pull) the keys from the KeyStore.  This will enable
           implementers to reuse the same API calls for all their
           Routing Protocols.  The API will necessarily include facility
           to retrieve other SA parameters required for the construction
           of the Routing Protocol's packets, like key IDs or key
           lifetimes, etc.

   o  KMP -   There will be an automated key management protocol, KMP.
           This KMP will run between the peers.  The KMP serves as a
           protected channel between the peers, through which they can
           negotiate and pass important data required to exchange proof
           of key identifiers, derive session keys, determine re-keying,
           synchronize their keying state, signal various keying events,
           notify with error messages, etc.  As an analogy, in the IPsec
           protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306
           [RFC4306]) IKEv2 is the KMP that runs between the two peers,
           while AH and ESP are two different base protocols that take
           session keys from IKEv2 and use them in their transmissions.
           In the analogy, the Routing Protocol, say BGP and LDP, are
           analogous to ESP and AH, while the KMP is analogous to IKEv2
           itself.







Lebovitz &                 Expires May 9, 2010                 [Page 28]

Internet-Draft                KARP Roadmap                 November 2009



   o  RoutingProtocol-KMP API -   There will be an API for the Routing
           Protocol to request a session key of the KMP, and be notified
           when the keys are available for it.  The API will also
           contain a mechanism for the KMP to notify the Routing
           Protocol that there are new keys that it must now use, even
           if it didn't request those keys.  The API will also include a
           mechanism for the KMP to receive requests for session keys
           and other parameters from the routing protocol.  The KMP will
           also be aware of the various Routing Protocols and each of
           their unique parameters that need to be negotiated and
           returned.

   o  KMP-KeyStore API -   There will be an API for the KMP to place
           keys and parameters into the KeyStore after their negotiation
           and derivation with the other peer.  This will enable the
           implementers to reuse the same calls for multiple KMPs that
           may be needed to address the various categories of Routing
           Protocols as described in the section definingcategories
           (Section 3).


   [after writing this all up, I'm not sure we really need the key_store
   in the middle.  As long as we standardize fully all the calls needed
   from any Routing Protocol to any KMP, then there can be a generic
   hand-down function from the KMP to the Routing Protocol when the key
   and parameters are ready.  Let's sleep on it.]

   [will need state machines and function calls for these APIs, as one
   of the work items.  In essence, there is a need for a core team to
   develop the APIs out completely in order for the Routing Protocol
   teams to use them.  Need to get this team going asap.]


   o Identifiers -   A KMP is fed by identities.  The identities are
           text strings used by the peers to indicate to each other that
           each are known to the other, and authorized to establish
           connections.  Those identities must be represented in some
           standard string format, e.g. an IP address -- either v4 or
           v6, an FQDN, an RFC 822 email address, a Common Name [RFC
           PKI], etc.  Note that even though routers do not normally
           have email addresses, one could use an RFC 822 email address
           string as a formatted identifier for a router.  They would do
           so simply by putting the router's reference number or name-
           code as the "NAME" part of the address, left of the "@"
           symbol.  They would then place some locational context in the
           "DOMAIN" part of the string, right of the "@" symbol.  An
           example would be "rtr0210@sf.ca.us.company.com".  This



Lebovitz &                 Expires May 9, 2010                 [Page 29]

Internet-Draft                KARP Roadmap                 November 2009


           document does not suggest this string value at all.  Instead,
           the concept is used only to clarify that the type of string
           employed does not matter.  It also does not matter what
           specific text you chose to place in that string type.  It
           only matters that the type of string -- and it's format --
           must be agreed upon by the two endpoints.  Further, the
           string can be used as an identifier in this context, even if
           the string is not actually provisioned in it's source domain.
           For example, the email address "rtr0210@sf.ca.us.company.com"
           may not actually exist as an email address in that domain,
           but that string of characters may still be used as an
           identifier type(s) in the routing protocol security context.
           What is important is that the community decide on a small but
           flexible set of Identifiers they will all support, and that
           they decide on the exact format of those string.  The formats
           that will be used must be standardized and must be sensible
           for the routing infrastructure.

   o  Identity Proof -   Once the form of identity is decided, then
           there must be a cryptographic proof of that identity, that
           the peer really is who they assert themselves to be.  Proof
           of identity can be arranged between the peers in a few ways,
           for example pre-shared keys, raw assymetric keys, or a more
           user-friendly representation of assymetric keys, like a
           certificate.  Certificates can be used in a way requiring no
           additional supporting systems -- e.g. public keys for each
           peer can be maintained locally for verification upon contact.
           Certificate management can be made more simple and scalable
           with the use minor additional supporting systems, as is the
           case with self-signed certificates and a flat file list of
           "approved thumbprints".  Self-signed certificates will have
           somewhat lower security properties than Certificate Authority
           signed certificates [RFC Certs].  The use of these different
           identity proofs vary in ease of deployment, ease of ongoing
           management, startup effort, ongoing effort and management,
           security strength, and consequences from loss of secrets from
           one part of the system to the rest of the system.  For
           example, they differ in resistance to a security breach, and
           the effort required to remediate the whole system in the
           event of such a breach.  The point here is that there are
           options, many of which are quite simple to employ and deploy.

   o  Profiles -   Once the KMP, Identifiers and Proofs mechanisms are
           converged upon, they must be clearly profiled for each
           Routing Protocol, so that implementors and deployers alike
           understand the different pieces of the solution, and can have
           similar configurations and interoperability across multiple
           vendors' devices, so as to reduce management difficulty.  The



Lebovitz &                 Expires May 9, 2010                 [Page 30]

Internet-Draft                KARP Roadmap                 November 2009


           profiles SHOULD also provide guidance on when to use which
           various combinations of options.  This will, again, simplify
           use and interoperability.

   In addition to other business, administrative, and operational terms
   they must already exchange prior to forming first adjacencies, it is
   assumed that two parties deploying message authentication on their
   routing protocol will also need to decide upon acceptable security
   parameters for the connection.  This will include the form and
   content of the identity each use to represent the other.  It will
   also include the type of keys to be used, e.g.  PSK, raw assymetric
   keys, certificate.  And it will include the acceptable cryptographic
   algorithms, or algorithm suite.  This agreement is necessary in order
   for each to properly configure the connection on their respective
   devices.  The manner in which they agree upon and exchange this
   policy information is normally via phone call or written exchange,
   and is outside the scope of the KARP effort, but assumed to have
   occured.  We take as a given that each party knows the identity types
   and values, key types and values, and acceptable cryptographic
   algorithms for both their own device and the peer that form the
   security policy for configuration on their device.

   Common Mechanisms - In as much as they exist, the framework will
   capture mechanisms that can be used commonly not only within a
   particular category of Routing Protocol and Routing Protocol to KMP,
   but also between Routing Protocol categories.  Again, the goal here
   is simplifying the implementations and runtime code and resource
   requirements.  There is also a goal here of favoring well vetted,
   reviewed, operationally proven security mechanisms over newly brewed
   mechanisms that are less well tried in the wild.

4.4.  Work Items Per Routing Protocol

   Each Routing Protocol will have a team (the [Routing_Protocol]-KARP
   team) working on incrementally improving their Routing Protocol's
   security, These teams will have the following main work items:

   PHASE 1:

   Characterize the RP
      Assess the Routing Protocol to see what authentication mechanisms
      it has today.  Does it needs significant improvement to its
      existing mechanisms or not?  This will include determining if
      modern, strong security algorithms and parameters are present.







Lebovitz &                 Expires May 9, 2010                 [Page 31]

Internet-Draft                KARP Roadmap                 November 2009



   Define Optimal State
      List the requirements for the Routing Protocol's session key usage
      and format to contain to modern, strong security algorithms and
      mechanisms, per the Requirements (Section 4.2) section above.  The
      goal here is to determine what is needed for they Routing Protocol
      alone to be used securely with at least manual keys.

   Gap Analysis
      Enumerate the requirements for this protocol to move from its
      current security state, the first bullet, to its optimal state, as
      listed just above.

   Transition and Deployment Considerations  Document the operational
      transition plan for moving from the old to the new security
      mechanism.  Will adjacencies need to bounce?  What new elements/
      servers/services in the infrastructure will be required?  What is
      an example work flow that an operator will take?  The best
      possible case is if the adjacency does not break, but this may not
      always be possible.

   Define, Assign, Design
      Create a deliverables list of the design and specification work,
      with milestones.  Define owners.  Release a document(s)


   PHASE 2:

   KMP Analysis
      Review requirements for KMPs [RFC????].  Identify any nuances for
      this particular protocol's needs and its use cases for KMP.  List
      the requirements that this Routing Protocol has for being able to
      be use in conjunctions with a KMP.  Define the optimal state.

   Gap Analysis
      Enumerate the requirements for this protocol to move from its
      current security state to its optimal state.

   Define, Assign, Design
      Create a deliverabels list of the design and specification work,
      with miletsones.  Define owners.  Do the design and document work
      for a KMP to be able to generate the Routing Protocol's session
      keys for the packets on the wire.  These will be the arguments
      passed in the API to the KMP in order to bootstrap the session
      keys to the Routing Protocol.

   There will also be a team formed to work on the base framework
   mechanisms for each of the main categories, i.e. the blocks and API's



Lebovitz &                 Expires May 9, 2010                 [Page 32]

Internet-Draft                KARP Roadmap                 November 2009


   represented in figure 1 (Figure 1).

4.5.  Protocols in Categories

   This section groups the Routing Protocols into like categories,
   according to attributes set forth in Categories Section (Section 3).
   Each group will have a design team tasked with improving the security
   of the Routing Protocol mechanisms and defining the KMP requirements
   for their group, then rolling both into a roadmap document upon which
   they will execute.

   BGP, LDP and MSDP
       The Routing Protocol's that fall into the category of the one-to-
       one peering messages, and will use peer keying protocols, AND are
       all transmitted over TCP include BGP RFC 4271 [RFC4271], LDP
       [RFC5036] and MSDP [RFC3618].  A team will work on one mechanism
       to cover these three protocols.  Much of the work on the Routing
       Protocol update for its existing authentication mechanism is
       already occuring in the TCPM Working Group, on the TCP-AO
       [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its
       cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto].  The
       exception is the mode where LDP is used directly on the LAN
       [RFC????].  The work for this may go into the Group keying
       category (w/ OSPF) mentioned below.

   OSPF, ISIS, and RIP
       The Routing Protocols that fall into the category Group keying
       with one-to-many peering messages includes OSPF [RFC2328], ISIS
       [RFC1195] and RIP [RFC2453].  Not surprisingly, all these routing
       protocols have two other things in common.  First, they are run
       on a combination of the OSI datalink layer 2, and the OSI network
       layer 3.  By this we mean that they have a component of how the
       routing protocol works which is specified in Layer 2 as well as
       in Layer 3.  Second, they are all internal gateway protocols, or
       IGPs.  The keying mechanisms and use will be much more
       complicated to define for these than for a one-to-one messaging
       protocol.

   BFD
       Because it is less of a routing protocol, per se, and more of a
       peer aliveness detection mechanism, Bidirectional Forwarding
       Detection (BFD) [RFC????] will have its own team.

   RSVP [RFC????], RSVP-TE [RFC????], and PCE







Lebovitz &                 Expires May 9, 2010                 [Page 33]

Internet-Draft                KARP Roadmap                 November 2009


       These three protocols will be handled together. [what more
       characterisation should we give here?  Routing AD's, provide text
       pls?]

   PIM-SM and PIM-DM
       Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM
       [RFC3973] will be handled together.  PIM-SM multicasts routing
       information (Hello, Join/Prune, Assert) on a link-local basis,
       using a defined multicast address.  In addition, it specifies
       unicast communication for exchange of information (Register,
       Register-Stop) between the router closest to a group sender and
       the "rendezvous point" (RP).  The RP is typically not "on-link"
       for a particular router.  While much work has been done on
       multicast security for application-layer groups, little has been
       done to address the problem of managing hundreds or thousands of
       small one-to-many groups with link-local scope.  Such an
       authentication mechanism should be considered along with the
       router-to-Rendezvous Point authentication mechanism.  The most
       important issue is ensuring that only the "authorized neighbors"
       get the keys for (S,G), so that rogue routers cannot participate
       in the exchanges.  Another issue is that some of the
       communication may occur intra-domain, e.g. the link-local
       messages in an enterprise, while others for the same (*,G) may
       occur inter-domain, e.g. the router-to-Rendezvous Point messges
       may be from one enterprise's router to another.  One possible
       solution proposes a region-wide "master" key server (possibly
       replicated), and one "local" key server per speaking router.
       There is no issue with propagating the messages outside the link,
       because link-local messages, by definition, are not forwarded.
       This solution is offered only as an example of how work may
       progress; further discussion should occur in this work team.
       Specification of a link-local protection mechanism for PIM-SM
       occurred in RFC 4601 [RFC4601], and this work is being updated in
       PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal].  However, the KMP
       part is completely unspecified, and will require work outside the
       expertise of the PIM working group to accomplish, which is why
       this roadmap is being created.

   These protocols are deemed out-of-scope for this current iteration of
   the work roadmap.  Once all of the protocols listed above have had
   their work completed, or are clearly within site of completion, then
   the community will revisit the need and interest for working on
   these:

   o  MANET
   o  FORCES

   [need text from routing ADs on why these are out of scope]



Lebovitz &                 Expires May 9, 2010                 [Page 34]

Internet-Draft                KARP Roadmap                 November 2009


4.6.  Priorites

   Resources from both the routing area and the security area will be
   applied to work on these problem spaces as quickly as possible.
   Realizing that such resources are far from unlimited, a rank order
   priority for addressing the work of incrementally securing these
   groups of routing protocols is provided:

   o  Priority 1 - BGP / LDP / MSDP - almost done with Phase 1 on these,
      via TCP-AO [I-D.ietf-tcpm-tcp-auth-opt] .
   o  Priority 2 - PIM-SM
   o  Priority 3 - OSPF / ISIS / RIP
   o  Priority 4 - BFD
   o  Priority 5 - RSVP and RSVP-TE

   By far the most important group is the Priority 1 group as these are
   the protocols used on the most public and exposed segments of the
   networks, at the peering points between operators and between
   operators and their customers.  BFD, as a detection mechanism
   underlying the Priority 1 protocols is therefore second.


5.  Security Considerations

   As mentioned in the Introduction , RFC4948 identifies additional
   steps needed to achieve the overall goal of improving the security of
   the core routing infrastructure.  Those include validation of route
   origin announcements, path validation, cleaning up the IRR databases
   for accuracy, and operational security practicies that prevent
   routers from being compromised devices.  The KARP work is but one
   step in a necessary system of security improvements.

   The security of cryptographic-based systems depends on both the
   strength of the cryptographic algorithms chosen and the strength of
   the keys used with those algorithms.  The security also depends on
   the engineering of the protocol used by the system to ensure that
   there are no non-cryptographic ways to bypass the security of the
   overall system.

   Care should also be taken to ensure that the selected key is
   unpredictable, avoiding any keys known to be weak for the algorithm
   in use.  [RFC4086] contains helpful information on both key
   generation techniques and cryptographic randomness.

   In addition to using a stong key/PSK of appropriate length and
   randomness, deployers of KARP protocols SHOULD use different keys
   between different routing peers whenever operationally possible.
   RFC3562 [RFC3562] provides some very sound guidance.  It was meant



Lebovitz &                 Expires May 9, 2010                 [Page 35]

Internet-Draft                KARP Roadmap                 November 2009


   specifically for the use of TCP MD5 for BGP, but it is more or less
   applicable to Routing Protocol authentication work that would result
   from KARP.  It states three main points: (1) key lengths SHOULD be
   between 12 and 24 bytes (this will vary depending on the MAC/KDF in
   use), with larger keys having effectively zero additional
   computational costs when compared to shorter keys, (2) key sharing
   SHOULD be limited so that keys aren't shared among multiple BGP
   peering arrangements, and (3) Keys SHOULD be changed at least every
   90 days (this could be longer for stronger MAC algorithms, but it is
   generally a wise idea).

   This is especially true when the Routing Protocol takes a static
   Traffic Key as opposed to a Traffic Key derived per-connection by a
   KDF.  The burdon for doing so is understandable much higher than for
   using the same static Traffic Key across all peering routers.  This
   is why use of a KMP network-wide increases peer-wise security so
   greatly, because now each set of peers can enjoys a unique Traffic
   Key, and if an attacker sitting between two routers learns or guesses
   the Traffic Key for that connection, she doesn't gain access to all
   the other connections as well.

   However, whenever using manual keys, it is best to design a system
   where a given PSK will be used in a KDF, mixed with connection
   specific material, in order to generate session unique -- and
   therefore peer-wise -- Traffic Keys.  Doing so has the following
   advantages: the Traffic Keys used in the per-message MAC operation
   are peer-wise unique, it provides inter-connection replay protection,
   and, if the per-message MAC covers some connection counter, intra-
   connection replay protection.

   Note that in the composition of certain key derivation functions
   (e.g.  KDF_AES_128_CMAC, as used in TCP-AO [I-D.ao-crypto]), the
   pseudorandom function (PRF) used in the KDF may require a key of a
   certain fixed size as an input.  For example, AES_128_CMAC requires a
   128 bit (16 byte) key as the seed.  However, for convenience to the
   administrators/deployers, a specification may not want to force the
   deployer to enter a PSK of exactly 16 bytes.  Instead, a
   specification may call for a sub-key routine that could handle a
   variable length PSK, one that might be less than 16 bytes (see
   [RFC4615], section 3, as an example).  That sub-key routine would act
   as a key extractor to derive a second key of exactly the required
   length, and thus suitable as a seed to the PRF.  This does NOT mean
   that administrators are safe to use weak keys.  Administrators are
   encouraged to follow [RFC4086] as listed above.  We simply attempted
   to "put a fence around stupidity", in as much as possible.

   A better option, from a security perspective, is to use some
   representation of a device-specific assymetric key pair as the



Lebovitz &                 Expires May 9, 2010                 [Page 36]

Internet-Draft                KARP Roadmap                 November 2009


   identity proof, as described in Section 3.4.2.

   When it comes time for the KARP WG to design the re-usable model for
   a KMP, The Guidelines for Cryptographic Key Management, RFC4107
   [RFC4107] should be will be consulted.

   [[QUESTION TO REVIEWERS: it may be worthwhile to pull the last few
   paragraphs, along with some guidance along the same lines, into
   section 4, in a new sub-section with a title something like "Security
   tips for KARP design teams working on Routing Protocol reviews and
   updates".  Or maybe even into its own info document, "Security
   Guidelines for KARP Design Teams".Thoughts?]]

   The mechanisms that will be defined under this roadmap aim to improve
   the security, better protect against more threats, and provider far
   greater operational efficiencies than the state of things at the time
   of this writing.  However, none of these changes will improve
   Internet security unless they are implemented and deployed.  Other
   influences must be brought to bare upon operators and organizations
   to create incentives for deployment.  Such incentives may take the
   form of PCI-like industry compliance/certifications, well advertised
   BCPs profiling the use of this roadmap's output, end-user demand or
   insistance.


6.  IANA Considerations

   This document has no actions for IANA.


7.  Acknowledgements

   The outline for this draft was created from discussions and
   agreements with Routing AD's Ross Callon and Dave Ward, Security AD's
   Tim Polk and Pasi Eronen, and IAB members Danny McPherson and Gregory
   Lebovitz.

   Mat Ford and Bill Atwood provided reviews to -00.

   Danny McPherson provided an extremely detailed and useful review of
   -01.


8.  Change History (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]




Lebovitz &                 Expires May 9, 2010                 [Page 37]

Internet-Draft                KARP Roadmap                 November 2009


   -00-00 original rough rough rough draft for review by routing and
   security AD's

   -00- original submission

   o  adds new category = multicast protocols in category section and
      mentions mcast in group keying category description.
   o  add a lot of references where they did not exist before, or where
      there were only place holders.  Still more work needed on this.
   o  abstract filled in
   o  changed from standards track to informational (this was an
      oversight in last draft).
   o  filled out threats section with detailed descriptions, and linked
      to RPsec threats RFC
   o  made ascii art for the basic KMP framework
   o  added section on internal versus external peering and the
      requirements decisions for them
   o  added security characterization section in sect 2, added sections
      discussing internal vs external protocols, shared vs unique keys,
      oob vs in-band keying
   o  incorporates all D Ward's feedback from his initial skim of the
      document.

   -01-

   o  Updated framework (Figure 1) diagram to include all listed and
      described elements.  Needs review and honing.  Gregory Lebovitz
      (GL).
   o  Added comment in protocols (Section 4.5) section that much of the
      BGP/LDP Phase 1 work is already being done in tcp-ao and ao-
      crypto.  GL.
   o  Updated Scope making the 2 work phases more clear earlier in the
      document.  GL.
   o  Broke work items (Section 4.4) section into two Phases, 1 for
      manual key update, and second for KMP work.  GL.
   o  Re-org'd doc.  Brought Threats (Section 2) section out into its
      own top-level section.  Did same with Categorization (Section 3)
      section, leaving Roadmap section more focused.  Moved ToDo list
      and Change History to end of doc, after Acknowledgements.  GL.
   o  added new sect 2.3 (Section 4.1) on main roadmap phases.  Previous
      section Common Framework (Section 4.3) moved to 2.4.  Tim Polk
      (TP).
   o  Added Section 2.3.1 Requirements for Phase 1 Routing Protocols'
      Security Update (Section 4.2).  This provides a nice starter set
      of requirements for any work team.  GL.
   o  Filled out text for Out vs In-band Key Mgmt (Section 3.4.3)
      section, significantly.  Changed the term from "in-band" to "in-
      line".



Lebovitz &                 Expires May 9, 2010                 [Page 38]

Internet-Draft                KARP Roadmap                 November 2009


   o  Section Threats (Section 2) Clarified DoS threats in and out of
      scope better.  We are not preventing all DoS attacks.  Just those
      we can reasonably via authentication.  TP.
   o  Sect In-band vs Out-of-Band (Section 3.4.3)clarified that In-band
      does not mean in-band to Routing Protocol, but rather over IP
      between the Routing Protocols, rather than pushed down by some
      external management entity.  TP.
   o  In roadmap (Section 3) section, added "it is also hoped that we
      can create one kmp per category..."  Also explained value of a
      KMP.  TP.
   o  Added "operators" to audience (Section 1.6) list.  Matt Ford (MF).
   o  Described why BGP (and LDP) security is not deployed very often.
      Added this Scope (Section 1.3) section, point 4.  If mechanisms
      aren't being deployed, why is that?  What, if anything, could be
      done to improve deployment?  Tried to address these.  Need
      references (see To Do list below).  MF.
   o  Added some text to security section to address this from MF: say
      something here about the limitations of this approach, if any -
      and refer back to the need for other pieces of the puzzle.  May
      need more work.
   o  Cleaned up text for multicast part of Message Type (Section 3.1)
      section and Protocols (Section 4.5) section, clarifying PIM's two
      message types, mcast and unicast, in both places.  Bill Atwood
      (BA).
   o  In section Protocols (Section 4.5), added references to 4601 and
      PIM-SM-LINKLOCAL.  BA.
   o  Editorial changes pointed out various folks.

   -02-

   o  Re-submitted due to expiration.  Text did not change.  Substantive
      update coming shortly.
   o
   o

   - 03 -

   o  changed "BaseRP" to "Routing Protocol" throughout the doc - man
   o  filled out the Terminology section
   o  changed "KMART" to "KARP" in everything but the title, since the
      -00 deadline had long since passed.  Will change the title of the
      doc to KARP as soon as the window re-opens.
   o  priorities in sect 4.6 changed.  Added PIM-SM.  Lowered OSPF and
      BFD, based on feedback by a few people.
   o  many edits resulting from Danny McPherson's review.
   o  added "Brute Foce Attacks Against Password/Keys" to Threats
      Section 2.1 section.




Lebovitz &                 Expires May 9, 2010                 [Page 39]

Internet-Draft                KARP Roadmap                 November 2009


   o  Significant updates to Security Considerations section
   o  Added a few references throughout to RFC3562
   o  4.3 2nd to last P - added a comment to clarify that two parties
      (or an org) must discuss ahead of time what they want their
      connections' secruity properties to be. - dward
   o  added to 4.4 Phase 1 - New Section: Transition and Deployment
      Considerations. ea wg must call out the operational transition
      plan from old to new security.  Best if don't bounce link. - dward
   o  added 3.3 (but not sure if this is right)- endpoint discovery
      mechanisms? endpoint discovery mechanism (L2VPN, L3VPN, etc).
      Discovery is much different security properties than passing
      Routing updates. - dward
   o  More requirements: Added to 4.2: X - convergence SHOULD not be
      affected by what we choose; adding security SHOULD not cause a
      refresh of route updates or cause additional route updates to be
      generated; adding auth should not be an attack vector itself.
      AKA, the use of MD5 is so expensive that spoofing BGP packets w/
      MD5 causes the control plane to be attacked because CPU went to
      100% - dward
   o  updated stats on MD5 usage, and cited [ISR2008]. - mchpherson


9.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   List of stuff that still needs work
   o  RTG AD's or delegates: clean up the three definitions of route
      message type categories.  Need RTG Area folks input on this.
   o  More clarity on the work items for those defining and specifying
      the framework elements and API's themselves.
   o  RTG AD's or delegates: text justifying RSVP and RSVP-TE and what
      we think solving that problem may look like
   o  RTG AD's or delegates: more justification for why MANET and FORCES
      are out of scope.  Need ref for those RFCs.
   o  Danny McPherson: Get reference for BGP auth usage stats in Scope
      (Section 1.3) section, item 4.
   o
   o  security section: pull out security guidance to routing protocol
      design teams stuff and place into its own section?
   o
   o


10.  References





Lebovitz &                 Expires May 9, 2010                 [Page 40]

Internet-Draft                KARP Roadmap                 November 2009


10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

   [RFC4948]  Andersson, L., Davies, E., and L. Zhang, "Report from the
              IAB workshop on Unwanted Traffic March 9-10, 2006",
              RFC 4948, August 2007.

10.2.  Informative References

   [I-D.ao-crypto]
              Lebovitz, G., "Cryptographic Algorithms, Use and
              Implementation Requirements for TCP Authentication
              Option", March 2009, <http://tools.ietf.org/html/
              draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00>.

   [I-D.ietf-pim-sm-linklocal]
              Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in PIM-SM Link-local Messages",
              draft-ietf-pim-sm-linklocal-09 (work in progress),
              October 2009.

   [I-D.ietf-tcpm-tcp-auth-opt]
              Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-08
              (work in progress), October 2009.

   [ISR2008]  McPherson, D. and C. Labovitz, "Worldwide Infrastructure
              Security Report", October 2008,
              < http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf>.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453,
              November 1998.

   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
              Signature Option", RFC 3562, July 2003.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.



Lebovitz &                 Expires May 9, 2010                 [Page 41]

Internet-Draft                KARP Roadmap                 November 2009


   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, June 2005.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4615]  Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
              PRF-128) Algorithm for the Internet Key Exchange Protocol
              (IKE)", RFC 4615, August 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.










Lebovitz &                 Expires May 9, 2010                 [Page 42]

Internet-Draft                KARP Roadmap                 November 2009


Authors' Addresses

   Gregory Lebovitz
   Juniper Networks, Inc.
   1194 North Mathilda Ave.
   Sunnyvale, CA  94089-1206
   US

   Phone:
   Email: gregory.ietf@gmail.com




   Phone:
   Email:



































Lebovitz &                 Expires May 9, 2010                 [Page 43]









+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_448520953==.ALT-- --=====================_448520890==_ Content-Type: application/octet-stream; name="draft-lebovitz-kmart-roadmap-03.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-lebovitz-kmart-roadmap-03.txt" CgoKS0FSUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEcuIExlYm92aXR6CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBlcgpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMDUsIDIwMDkKRXhwaXJl czogTWF5IDksIDIwMTAKCgpSb2FkbWFwIGZvciBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9u IG9mIFJvdXRpbmcgUHJvdG9jb2wgUGFja2V0cyBvbgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBXaXJlCiAgICAgICAgICAgICAgICAgICAgZHJhZnQtbGVib3ZpdHota21hcnQt cm9hZG1hcC0wMwoKQWJzdHJhY3QKCiAgIEluIHRoZSBNYXJjaCBvZiAyMDA2IHRoZSBJQUIgaGVs ZCBhIHdvcmtzaG9wIG9uIHRoZSB0b3BpYyBvZgogICAiVW53YW50ZWQgSW50ZXJuZXQgVHJhZmZp YyIuICBUaGUgcmVwb3J0IGZyb20gdGhhdCB3b3Jrc2hvcCBpcwogICBkb2N1bWVudGVkIGluIFJG QyA0OTQ4IFtSRkM0OTQ4XS4gIFNlY3Rpb24gOC4yIG9mIFJGQyA0OTQ4IGNhbGxzIGZvcgogICAi W3RdaWdodGVuaW5nIHRoZSBzZWN1cml0eSBvZiB0aGUgY29yZSByb3V0aW5nIGluZnJhc3RydWN0 dXJlLiIgIEZvdXIKICAgbWFpbiBzdGVwcyB3ZXJlIGlkZW50aWZpZWQgZm9yIGltcHJvdmluZyB0 aGUgc2VjdXJpdHkgb2YgdGhlIHJvdXRpbmcKICAgaW5mcmFzdHJ1Y3R1cmUuICBPbmUgb2YgdGhv c2Ugc3RlcHMgd2FzICJzZWN1cmluZyB0aGUgcm91dGluZwogICBwcm90b2NvbHMnIHBhY2tldHMg b24gdGhlIHdpcmUuIiAgT25lIG1lY2hhbmlzbSBmb3Igc2VjdXJpbmcgcm91dGluZwogICBwcm90 b2NvbCBwYWNrZXRzIG9uIHRoZSB3aXJlIGlzIHRoZSB1c2Ugb2YgcGVyLXBhY2tldCBjcnlwdG9n cmFwaGljCiAgIG1lc3NhZ2UgYXV0aGVudGljYXRpb24sIHByb3ZpZGluZyBib3RoIHBlZXIgYXV0 aGVudGljYXRpb24gYW5kCiAgIG1lc3NhZ2UgaW50ZWdyaXR5LiAgTWFueSBkaWZmZXJlbnQgcm91 dGluZyBwcm90b2NvbHMgZXhpc3QgYW5kIHRoZXkKICAgZW1wbG95IGEgcmFuZ2Ugb2YgZGlmZmVy ZW50IHRyYW5zcG9ydCBzdWJzeXN0ZW1zLiAgVGhlcmVmb3JlIHRoZXJlCiAgIG11c3QgbmVjZXNz YXJpbHkgYmUgdmFyaW91cyBtZXRob2RzIGRlZmluZWQgZm9yIGFwcGx5aW5nCiAgIGNyeXB0b2dy YXBoaWMgYXV0aGVudGljYXRpb24gdG8gdGhlc2UgdmFyeWluZyBwcm90b2NvbHMuICBNYW55CiAg IHJvdXRpbmcgcHJvdG9jb2xzIGFscmVhZHkgaGF2ZSBzb21lIG1ldGhvZCBmb3IgYWNjb21wbGlz aGluZwogICBjcnlwdG9ncmFwaGljIG1lc3NhZ2UgYXV0aGVudGljYXRpb24uICBIb3dldmVyLCBp biBtYW55IGNhc2VzIHRoZQogICBleGlzdGluZyBtZXRob2RzIGFyZSBkYXRlZCwgdnVsbmVyYWJs ZSB0byBhdHRhY2ssIGFuZC9vciBlbXBsb3kKICAgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIHRo YXQgaGF2ZSBiZWVuIGRlcHJlY2F0ZWQuICBUaGlzIGRvY3VtZW50CiAgIGNyZWF0ZXMgYSByb2Fk bWFwIG9mIHByb3RvY29sIHNwZWNpZmljYXRpb24gd29yayBmb3IgdGhlIHVzZSBvZgogICBtb2Rl cm4gY3J5cHRvZ3JwYWhpYyBtZWNoYW5pc21zIGFuZCBhbGdvcml0aG1zIGZvciBtZXNzYWdlCiAg IGF1dGhlbnRpY2F0aW9uIGluIHJvdXRpbmcgcHJvdG9jb2xzLiAgSXQgYWxzbyBkZWZpbmVzIHRo ZSBmcmFtZXdvcmsKICAgZm9yIGEga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgdGhhdCBtYXkgYmUg dXNlZCB0byBjcmVhdGUgYW5kIG1hbmFnZQogICBzZXNzaW9uIGtleXMgZm9yIG1lc3NhZ2UgYXV0 aGVudGljYXRpb24gYW5kIGludGVncml0eS4gIFRoaXMgcm9hZG1hcAogICByZWZsZWN0cyB0aGUg aW5wdXQgb2YgYm90aCB0aGUgc2VjdXJpdHkgYXJlYSBhbmQgcm91dGluZyBhcmVhIGluCiAgIG9y ZGVyIHRvIGZvcm0gYSBqb2ludGx5IGFncmVlZCB1cG9uIGFuZCBwcmlvcml0aXplZCB3b3JrIGxp c3QgZm9yIHRoZQogICBlZmZvcnQuCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVy bmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0 aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRh c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwOQoKCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQK ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgOSwgMjAxMC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENv cHlyaWdodCAoYykgMjAwOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMg ZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwK ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVi bGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRz CiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rp b25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4 dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0 IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAg IGRlc2NyaWJlZCBpbiB0aGUgQlNEIExpY2Vuc2UuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkxl Ym92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAg ICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1h cCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKClRhYmxlIG9mIENvbnRlbnRzCgogICAx LiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQKICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMS4yLiAgUmVxdWlyZW1lbnRzIExhbmd1 YWdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDEuMy4gIFNj b3BlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDYKICAgICAxLjQuICBHb2FscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA4CiAgICAgMS41LiAgTm9uLUdvYWxzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgIDEuNi4gIEF1ZGllbmNlIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgMi4g IFRocmVhdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDEyCiAgICAgMi4xLiAgVGhyZWF0cyBJbiBTY29wZSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgIDIuMi4gIFRocmVhdHMgT3V0IG9mIFNjb3Bl IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgMy4gIENhdGVnb3Jp emluZyBSb3V0aW5nIFByb3RvY29scyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2 CiAgICAgMy4xLiAgQ2F0ZWdvcnk6IE1lc3NhZ2luZyBUcmFuc2FjdGlvbiBUeXBlIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNgogICAgIDMuMi4gIENhdGVnb3J5OiBQZWVyIHZzLiBHcm91cCBLZXlp bmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgICAzLjMuICBDYXRlZ29yeTogIFVw ZGF0ZSB2cy4gRGlzY292ZXJ5IFByb3RvY29sIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAgICAgMy40 LiAgU2VjdXJpdHkgQ2hhcmFjdGVyaXphdGlvbiBWZWN0b3JzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxOAogICAgICAgMy40LjEuICBJbnRlcm5hbCB2cy4gRXh0ZXJuYWwgT3BlcmF0aW9uICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgICAgIDMuNC4yLiAgVW5pcXVlIHZlcnN1cyBTaGFy ZWQgS2V5cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgICAgICAzLjQuMy4gIE91 dC1vZi1CYW5kIHZzLiBJbi1saW5lIEtleSBNYW5hZ2VtZW50IC4gLiAuIC4gLiAuIC4gLiAyMAog ICA0LiAgVGhlIFJvYWRtYXAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjIKICAgICA0LjEuICBXb3JrIFBoYXNlcyBvbiBhbnkgUGFydGljdWxhciBQ cm90b2NvbCAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyCiAgICAgNC4yLiAgUmVxdWlyZW1lbnRzIGZv ciBQaGFzZSAxIFJvdXRpbmcgUHJvdG9jb2xzJyBTZWN1cml0eQogICAgICAgICAgIFVwZGF0ZSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQKICAg ICA0LjMuICBDb21tb24gRnJhbWV3b3JrIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI1CiAgICAgNC40LiAgV29yayBJdGVtcyBQZXIgUm91dGluZyBQcm90b2NvbCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMQogICAgIDQuNS4gIFByb3RvY29scyBpbiBDYXRl Z29yaWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzMKICAgICA0LjYuICBQ cmlvcml0ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDM1CiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzNQogICA2LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgNy4gIEFja25vd2xlZGdlbWVu dHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM3CiAgIDgu ICBDaGFuZ2UgSGlzdG9yeSAoUkZDIEVkaXRvcjogRGVsZXRlIEJlZm9yZSBQdWJsaXNoaW5nKSAg LiAuIC4gLiAzNwogICA5LiAgTmVlZHMgV29yayBpbiBOZXh0IERyYWZ0IChSRkMgRWRpdG9yOiBE ZWxldGUgQmVmb3JlCiAgICAgICBQdWJsaXNoaW5nKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MAogICAxMC4gUmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDEKICAgICAxMC4xLiBO b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQxCiAgICAgMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0MQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDIKCgoKCgoKCgoKCgoKCkxlYm92aXR6 ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgICBb UGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEluIE1hcmNo IDIwMDYgdGhlIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBoZWxkIGEgd29ya3No b3AKICAgb24gdGhlIHRvcGljIG9mICJVbndhbnRlZCBJbnRlcm5ldCBUcmFmZmljIi4gIFRoZSBy ZXBvcnQgZnJvbSB0aGF0CiAgIHdvcmtzaG9wIGlzIGRvY3VtZW50ZWQgaW4gUkZDIDQ5NDggW1JG QzQ5NDhdLiAgU2VjdGlvbiA4LjEgb2YgdGhhdAogICBkb2N1bWVudCBzdGF0ZXMgdGhhdCAiQSBz aW1wbGUgcmlzayBhbmFseXNpcyB3b3VsZCBzdWdnZXN0IHRoYXQgYW4KICAgaWRlYWwgYXR0YWNr IHRhcmdldCBvZiBtaW5pbWFsIGNvc3QgYnV0IG1heGltYWwgZGlzcnVwdGlvbiBpcyB0aGUKICAg Y29yZSByb3V0aW5nIGluZnJhc3RydWN0dXJlLiIgIFNlY3Rpb24gOC4yIGNhbGxzIGZvciAiW3Rd aWdodGVuaW5nCiAgIHRoZSBzZWN1cml0eSBvZiB0aGUgY29yZSByb3V0aW5nIGluZnJhc3RydWN0 dXJlLiIgIEZvdXIgbWFpbiBzdGVwcwogICB3ZXJlIGlkZW50aWZpZWQgZm9yIHRoYXQgdGlnaHRl bmluZzoKCiAgIG8gIE1vcmUgc2VjdXJlIG1lY2hhbmlzbXMgYW5kIHByYWN0aWNlcyBmb3Igb3Bl cmF0aW5nIHJvdXRlcnMuICBUaGlzCiAgICAgIHdvcmsgaXMgYmVpbmcgYWRkcmVzc2VkIGluIHRo ZSBPUFNFQyBXb3JraW5nIEdyb3VwLgogICBvICBDbGVhbmluZyB1cCB0aGUgSW50ZXJuZXQgUm91 dGluZyBSZWdpc3RyeSByZXBvc2l0b3J5IFtJUlJdLCBhbmQKICAgICAgc2VjdXJpbmcgYm90aCB0 aGUgZGF0YWJhc2UgYW5kIHRoZSBhY2Nlc3MsIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQKICAgICAg Zm9yIHJvdXRpbmcgdmVyaWZpY2F0aW9ucy4gIFRoaXMgd29yayBzaG91bGQgYmUgYWRkcmVzc2Vk IHRocm91Z2gKICAgICAgbGlhaXNvbnMgd2l0aCB0aG9zZSBydW5uaW5nIHRoZSBJUlIncyBnbG9i YWxseS4KICAgbyAgU3BlY2lmaWNhdGlvbnMgZm9yIGNyeXB0b2dyYXBoaWMgdmFsaWRhdGlvbiBv ZiByb3V0aW5nIG1lc3NhZ2UKICAgICAgY29udGVudC4gIFRoaXMgd29yayB3aWxsIGxpa2VseSBi ZSBhZGRyZXNzZWQgaW4gdGhlIFNJRFIgV29ya2luZwogICAgICBHcm91cC4KICAgbyAgU2VjdXJp bmcgdGhlIHJvdXRpbmcgcHJvdG9jb2xzJyBwYWNrZXRzIG9uIHRoZSB3aXJlCgogICBUaGlzIGRv Y3VtZW50IGFkZHJlc3NlcyB0aGUgbGFzdCBidWxsZXQsIHNlY3VyaW5nIHRoZSBwYWNrZXRzIG9u IHRoZQogICB3aXJlIG9mIHRoZSByb3V0aW5nIHByb3RvY29sIGV4Y2hhbmdlcy4gIFRoZSBkb2N1 bWVudCBhZGRyZXNzZXMKICAgS2V5aW5nIGFuZCBBdXRoZW50aWNhdGlvbiBmb3IgUm91dGluZyBQ cm90b2NvbHMsIGFrYSAiS0FSUCIuCgogICBJdCBpcyB1bmxpa2VseSB0aGF0IHRoaXMgZG9jdW1l bnQsIGluIGl0cyBjdXJyZW50IGZvcm0sIHdpbGwgYmVjb21lCiAgIGFuIFJGQy4gIE1vcmUgbGlr ZWx5IGlzIHRoYXQgdGhpcyBkb2N1bWVudCB3aWxsIGJlIHNwbGl0IHVwIGludG8KICAgc2V2ZXJh bCBzbWFsbGVyIGRvY3VtZW50cyB3aGljaCBtYXkgbG9vayBzb21ldGhpbmcgbGlrZToKCiAgIG8g IFNjb3BlICYgR29hbHMgc2VjdGlvbnMgd2lsbCBsaWtlbHkgYmVjb21lIHBhcnQgb2YgdGhlIEtB UlAgV0cKICAgICAgY2hhcnRlcgogICBvICBUaHJlYXQgZG9jdW1lbnQKICAgbyAgUmVxdWlyZW1l bnRzIGRvY3VtZW50IChtYXkgYmUgY29tYmluZWQgd2l0aCBUaHJlYXQgZG9jdW1lbnQpCiAgIG8g IEZyYW1ld29yayBkb2N1bWVudAogICBvICBSb3V0aW5nUHJvdG9jb2wgRGVzaWduIFRlYW0gV29y ayBQbGFuIGRvY3VtZW50LiAgVGhpcyB3b3VsZAogICAgICBpbmNsdWRlIHNlY3Rpb25zIGxpa2Ug V29yayBQaGFzZXMsIFByaW9yaXRpZXMsIFNlY3VyaXR5CiAgICAgIENvbnNpZGVyYXRpb25zLCBl dGMuCiAgIEZvciBub3csIHRoZSBkb2N1bWVudCBzZXJ2ZXMgYXMgdGhlIGNhdGNoIGFsbCBmb3Ig dGhlIHNldCBvZiB0aG91Z2h0cwogICBhcm91bmQgdGhlIEtBUlAgZWZmb3J0LiAgQXMgYSB3b3Jr aW5nIGdyb3VwIGlzIGZvcm1lZCwgZGVjaXNpb25zIHdpbGwKICAgYmUgbWFkZSBhYm91dCB0aGUg Y3JlYXRpb24gb2Ygc3BlY2lmaWMgZG9jdW1lbnRzLgoKICAgRWRpdG9yJ3MgTm90ZSBvbiAiS01B UlQiIHZzICJLQVJQIjogVGhlIGZpcnN0IGZldyB2ZXJzaW9ucyBvZiB0aGlzCiAgIGRvY3VtZW50 IHdlcmUgY2FsbGVkICJkcmFmdC1sZWJvdml0ei1rbWFydC1yb2FkbWFwLXh4Ii4gIFVwb24gdGhl CiAgIGNyZWF0aW9uIG9mIHRoZSBCb0YgZm9yIElFVEY3NiwgdGhlIElFU0cgcmVxdWVzdGVkIHRo ZSBuYW1lIG9mIHRoZQogICBlZmZvcnQgY2hhbmdlIHNvIGFzIHRvIGF2b2lkIGFueSBwb3RlbnRp YWwgdHJhZGVtYXJrIGlzc3Vlcy4gIFRoZSBuZXcKICAgbmFtZSBvZiB0aGUgZWZmb3J0IGlzIEtB UlAuICBWZXJzaW9uIC0wMyB3aWxsIGdvIG91dCB0aXRsZWQKICAgImRyYWZ0LWxlYm92aXR6LWtt YXJ0LXJvYWRtYXAtMDMiLCBzbyBhcyB0byBhdm9pZCBjb25mdXNpb24uICBBcyBzb29uCgoKCkxl Ym92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAg ICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1h cCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIGFzIHRoZSBJLUQgZWRpdG9yIHF1 ZXVlIG9wZW5zIGFnYWluIChNb25kYXksIDA5IE5vdikgdGhlIGRvY3VtZW50CiAgIHdpbGwgYmUg c3VibWl0dGVkIHdpdGggcy9rbWFydC9rYXJwLyBpbiB0aGUgdGl0bGUuCgoxLjEuICBUZXJtaW5v bG9neQoKICAgV2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LCB0aGUgZm9sbG93aW5n IHdvcmRzLCB3aGVuCiAgIGJlZ2lubmluZyB3aXRoIGEgY2FwaXRhbCBsZXR0ZXIsIG9yIHNwZWxs ZWQgaW4gYWxsIGNhcGl0YWxzLCBob2xkIHRoZQogICBtZWFuaW5ncyBkZXNjcmliZWQgdG8gdGhl IHJpZ2h0IG9mIGVhY2ggdGVybS4gIElmIHRoZSBzYW1lIHdvcmQgaXMKICAgdXNlZCB1bmNhcGl0 YWxpemVkLCB0aGVuIGl0IGlzIGludGVuZGVkIHRvIGhhdmUgaXRzIGNvbW1vbiBlbmdsaXNoCiAg IGRlZmluaXRpb24uCgogICBQU0sgICAgICAgICAgICBQcmUtU2hhcmVkIEtleS4gQSBrZXkgdXNl ZCBieSBib3RoIHBlZXJzIGluIGEgc2VjdXJlCiAgICAgICAgICAgICAgICAgIGNvbmZpZ3VyYXRp b24uICBVc3VhbGx5IGV4Y2hhbmdlZCBvdXQtb2YtYmFuZCBwcmlvciB0bwogICAgICAgICAgICAg ICAgICBhIGZpcnN0IGNvbm5lY3Rpb24uCgogICBSb3V0aW5nIFByb3RvY29sICBXaGVuIHVzZWQg d2l0aCBjYXBpdGFsICJSIiBhbmQgIlAiIGluIHRoaXMgZG9jdW1lbnQKICAgICAgICAgICAgICAg ICAgdGhlIHRlcm0gcmVmZXJzIHRoZSBSb3V0aW5nIFByb3RvY29sIGZvciB3aGljaCB3b3JrIGlz CiAgICAgICAgICAgICAgICAgIGJlaW5nIGRvbmUgdG8gcHJvdmlkZSBvciBlbmhhbmNlIGl0cyBw ZWVyCiAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuCgogICBQUkYg ICAgICAgICAgICBQc2V1ZG9yYW5kb20gbnVtYmVyIGZ1bmN0aW9uLCBvciBzb21ldGltZXMgY2Fs bGVkCiAgICAgICAgICAgICAgICAgIHBzZXVkb3JhbmRvbSBudW1iZXIgZ2VuZXJhdG9yIChQUk5H KS4gIEFuIGFsZ29yaXRobQogICAgICAgICAgICAgICAgICBmb3IgZ2VuZXJhdGluZyBhIHNlcXVl bmNlIG9mIG51bWJlcnMgdGhhdCBhcHByb3hpbWF0ZXMKICAgICAgICAgICAgICAgICAgdGhlIHBy b3BlcnRpZXMgb2YgcmFuZG9tIG51bWJlcnMuICBUaGUgc2VxdWVuY2UgaXMgbm90CiAgICAgICAg ICAgICAgICAgIHRydWx5IHJhbmRvbSwgaW4gdGhhdCBpdCBpcyBjb21wbGV0ZWx5IGRldGVybWlu ZWQgYnkgYQogICAgICAgICAgICAgICAgICByZWxhdGl2ZWx5IHNtYWxsIHNldCBvZiBpbml0aWFs IHZhbHVlcyB0aGF0IGFyZSBwYXNzZWQKICAgICAgICAgICAgICAgICAgaW50byB0aGUgZnVuY3Rp b24uICBBbiBleG1hcGxlIGlzIFNIQS0yNTYuCgogICBLREYgICAgICAgICAgICBLZXkgZGVyaXZh dGlvbiBmdW5jdGlvbi4gIEEgcGFydGljdWxhciBzcGVjaWZpZWQgdXNlCiAgICAgICAgICAgICAg ICAgIG9mIGEgUFJGIHRoYXQgdGFrZXMgYSBQU0ssIGNvbWJpbmVzIGl0IHdpdGggb3RoZXIKICAg ICAgICAgICAgICAgICAgaW5wdXRzIHRvIHRoZSBQUkYsIGFuZCBwcm9kdWNlcyBhIHJlc3VsdCB0 aGF0IGlzCiAgICAgICAgICAgICAgICAgIHN1aXRhYmxlIGZvciB1c2UgYXMgYSBUcmFmZmljIEtl eS4KCiAgIElkZW50aWZpZXIgICAgIFRoZSB0eXBlIGFuZCB2YWx1ZSB1c2VkIGJ5IG9uZSBwZWVy IG9mIGFuCiAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0ZWQgbWVzc2FnZSBleGNoYW5nZSB0 byBzaWduaWZ5IHRvIHRoZSBvdGhlcgogICAgICAgICAgICAgICAgICBwZWVyIHdobyB0aGV5IGFy ZS4gIFRoZSBJZGVudGlmaWVyIGlzIHVzZWQgYnkgdGhlCiAgICAgICAgICAgICAgICAgIHJlY2Vp dmVyIGFzIGEgbG9va3VwIGluZGV4IGludG8gYSB0YWJsZSBjb250YWluaW5nCiAgICAgICAgICAg ICAgICAgIGZ1cnRoZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBlZXIgdGhhdCBpcyByZXF1aXJl ZCB0bwogICAgICAgICAgICAgICAgICBjb250aW51ZSBwcm9jZXNzaW5nIHRoZSBtZXNzYWdlLCBm b3IgZXhhbXBsZSBhCiAgICAgICAgICAgICAgICAgIFNlY3VyaXR5IEFzc29jaWF0aW9uIChTQSkg b3Iga2V5cy4KCiAgIElkZW50aXR5IFByb29mIEEgY3J5cHRvZ3JhcGhpYyBwcm9vZiBmb3IgYW4g YXNzZXJ0ZWQgaWRlbnRpdHksIHRoYXQKICAgICAgICAgICAgICAgICAgdGhlIHBlZXIgcmVhbGx5 IGlzIHdobyB0aGV5IGFzc2VydCB0aGVtc2VsdmVzIHRvIGJlLgogICAgICAgICAgICAgICAgICBQ cm9vZiBvZiBpZGVudGl0eSBjYW4gYmUgYXJyYW5nZWQgYmV0d2VlbiB0aGUgcGVlcnMgaW4KICAg ICAgICAgICAgICAgICAgYSBmZXcgd2F5cywgZm9yIGV4YW1wbGUgUFNLLCByYXcgYXNzeW1ldHJp YyBrZXlzLCBvciBhCiAgICAgICAgICAgICAgICAgIG1vcmUgdXNlci1mcmllbmRseSByZXByZXNl bnRhdGlvbiBvZiBhc3N5bWV0cmljIGtleXMsCiAgICAgICAgICAgICAgICAgIGxpa2UgYSBjZXJ0 aWZpY2F0ZS4KCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIw MTAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCgogICBTZWN1 cml0eSBBc3NvY2lhdGlvbiBvciBTQSAgVGhlIHBhcmFtZXRlcnMgYW5kIGtleXMgdGhhdCB0b2dl dGhlcgogICAgICAgICAgICAgICAgICBmb3JtIHRoZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBmb3Ig cHJvY2Vzc2luZyBzZWN1cmUKICAgICAgICAgICAgICAgICAgc2Vzc2lvbnMgYmV0d2VlbiBwZWVy cy4gIEV4YW1wbGVzIG9mIGl0ZW1zIHRoYXQgbWF5CiAgICAgICAgICAgICAgICAgIGV4aXN0IGlu IGFuIFNBIGluY2x1ZGU6IElkZW50aWZpZXIsIFBTSywgVHJhZmZpYyBLZXksCiAgICAgICAgICAg ICAgICAgIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcywga2V5IGxpZmV0aW1lcy4KCiAgIEtNUCAg ICAgICAgICAgIEtleSBNYW5hZ2VtZW50IFByb3RvY29sLiAgQSBwcm90b2NvbCB1c2VkIGJldHdl ZW4KICAgICAgICAgICAgICAgICAgcGVlcnMgdG8gZXhjaGFuZ2UgU0EgcGFyYW1ldGVycyBhbmQg VHJhZmZpYyBLZXlzLgogICAgICAgICAgICAgICAgICBFeGFtcGxlcyBvZiBLTVBzIGluY2x1ZGUg SUtFLCBUTFMsIGFuZCBTU0guCgogICBLTVAgRnVuY3Rpb24gICBBbnkgYWN0dWFsIEtNUCB1c2Vk IGluIHRoZSBnZW5lcmFsIEtBUlAgc29sdXRpb24KICAgICAgICAgICAgICAgICAgZnJhbWV3b3Jr CgogICBQZWVyIEtleSAgICAgICBLZXlzIHRoYXQgYXJlIHVzZWQgYmV0d2VlbiBwZWVycyBhcyB0 aGUgaWRlbnRpdHkKICAgICAgICAgICAgICAgICAgcHJvb2YuICBUaGVzZSBrZXlzIG1heSBvciBt YXkgbm90IGJlIGNvbm5lY3Rpb24KICAgICAgICAgICAgICAgICAgc3BlY2lmaWMsIGRlcGVuZGlu ZyBvbiB3aG8gdGhleSB3ZXJlIGVzdGFibGlzaGVkLCBhbmQKICAgICAgICAgICAgICAgICAgd2hh dCBmb3JtIG9mIGlkZW50aXR5IGFuZCBpZGVudGl0eSBwcm9vZiBpcyBiZWluZyB1c2VkCiAgICAg ICAgICAgICAgICAgIGluIHRoZSBzeXN0ZW0uCgogICBUcmFmZmljIEtleSAgICBUaGUgYWN0dWFs IGtleSB1c2VkIG9uIGVhY2ggcGFja2V0IG9mIGEgbWVzc2FnZS4KCiAgIERlZmluaXRpb25zIG9m IGl0ZW1zIHNwZWNpZmljIHRvIHRoZSBnZW5lcmFsIEtBUlAgZnJhbWV3b3JrIGFyZQogICBkZXNj cmliZWQgaW4gbW9yZSBkZXRhaWwgaW4gdGhlIEZyYW1ld29yayBzZWN0aW9uIFNlY3Rpb24gNC4z LgoKMS4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZD MjExOSBbUkZDMjExOV0uCgogICBXaGVuIHVzZWQgaW4gbG93ZXIgY2FzZSwgdGhlc2Ugd29yZHMg Y29udmV5IHRoZWlyIHR5cGljYWwgdXNlIGluCiAgIGNvbW1vbiBsYW5ndWFnZSwgYW5kIGFyZSBu b3QgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluCiAgIFJGQzIxMTkgW1JGQzIxMTld LgoKMS4zLiAgU2NvcGUKCiAgIEZvdXIgYmFzaWMgdGFjdGljcyBtYXkgYmUgZW1wbG95ZWQgaW4g b3JkZXIgdG8gc2VjdXJlIGFueSBwaWVjZSBvZgogICBkYXRhIGFzIGl0IGlzIHRyYW5zbWl0dGVk IG92ZXIgdGhlIHdpcmU6IHByaXZhY3kgKG9yIGVuY3J5cHRpb24pLAogICBhdXRoZW50aWNhdGlv biwgbWVzc2FnZSBpbnRlZ3JpdHksIGFuZCBub24tcmVwdWRpYXRpb24uICBUaGUgZm9jdXMKICAg Zm9yIHRoaXMgZWZmb3J0LCBhbmQgdGhlIHNjb3BlIGZvciB0aGlzIHJvYWRtYXAgZG9jdW1lbnQs IHdpbGwgYmUKICAgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBhbmQgcGFja2V0IGludGVncml0eSBv bmx5LiAgVGhpcyB3b3JrCiAgIGV4cGxpY2l0bHkgZXhjbHVkZXMsIGF0IHRoaXMgcG9pbnQgaW4g dGltZSwgdGhlIG90aGVyIHR3byB0YWN0aWNzOgogICBwcml2YWN5IGFuZCBub24tcmVwdWRpYXRp b24uICBTaW5jZSB0aGUgb2JqZWN0aXZlIG9mIG1vc3Qgcm91dGluZwogICBwcm90b2NvbHMgaXMg dG8gYnJvYWRseSBhZHZlcnRpc2UgdGhlIHJvdXRpbmcgdG9wb2xvZ3ksIHJvdXRpbmcKICAgbWVz c2FnZXMgYXJlIGNvbW1vbmx5IHNlbnQgaW4gdGhlIGNsZWFyOyBjb25maWRlbnRpYWxpdHkgaXMg bm90CiAgIG5vcm1hbGx5IHJlcXVpcmVkIGZvciByb3V0aW5nIHByb3RvY29scy4gIEhvd2V2ZXIs IGVuc3VyaW5nIHRoYXQKICAgcm91dGluZyBwZWVycyB0cnVseSBhcmUgdGhlIHRydXN0ZWQgcGVl cnMgZXhwZWN0ZWQsIGFuZCB0aGF0IG5vIHJvcXVlCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwOQoKCiAgIHBlZXJzIG9yIG1lc3NhZ2VzIGNhbiBjb21wcm9taXNlIHRoZSBzdGFi aWxpdHkgb2YgdGhlIHJvdXRpbmcKICAgZW52aXJvbm1lbnQgaXMgY3JpdGljYWwsIGFuZCB0aHVz IG91ciBmb2N1cy4gIFRoZSBvdGhlciB0d28KICAgZXhwbGljaXRseSBleGNsdWRlZCB0YWN0aWNz LCBwcml2YWN5IGFuZCBub24tcmVwdWRpYXRpb24sIG1heSBiZQogICBhZGRyZXNzZWQgaW4gZnV0 dXJlIHdvcmsuCgogICBJdCBpcyBwb3NzaWJsZSBmb3Igcm91dGluZyBwcm90b2NvbCBwYWNrZXRz IHRvIGJlIHRyYW5zbWl0dGVkCiAgIGVtcGxveWluZyBhbGwgZm91ciBzZWN1cml0eSB0YWN0aWNz IG1lbnRpb25lZCBhYm92ZSB1c2luZyBleGlzdGluZwogICBzdGFuZGFyZHMuICBGb3IgZXhhbXBs ZSwgb25lIGNvdWxkIHJ1biB1bmljYXN0LCBsYXllciAzIG9yIGFib3ZlCiAgIHJvdXRpbmcgcHJv dG9jb2wgcGFja2V0cyB0aHJvdWdoIElQc2VjIEVTUCBbUkZDNDMwM10uICBUaGlzIHdvdWxkCiAg IHByb3ZpZGUgdGhlIGFkZGVkIGJlbmVmaXQgb2YgcHJpdmFjeSwgYW5kIG5vbi1yZXB1ZGlhdGlv bi4gIEhvd2V2ZXIsCiAgIHJvdXRlciBwbGF0Zm9ybXMgYW5kIHN5c3RlbXMgaGF2ZSBiZWVuIGZp bmUgdHVuZWQgb3ZlciB0aGUgeWVhcnMgZm9yCiAgIHRoZSBzcGVjaWZpYyBwcm9jZXNzaW5nIG5l Y2Vzc2FyeSBmb3Igcm91dGluZyBwcm90b2NvbHMnIG5vbi0KICAgZW5jYXBzdWxhdGVkIGZvcm1h dHMuICBPcGVyYXRvcnMgYXJlLCB0aGVyZWZvcmUsIHF1aXRlIHJlbHVjdGFudCB0bwogICBleHBs b3JlIG5ldyBwYWNrZXQgZW5jYXBzdWxhdGlvbnMgZm9yIHRoZXNlIHRyaWVkIGFuZCB0cnVlIHBy b3RvY29scy4KCiAgIEluIGFkZGl0aW9uLCBhdCBsZWFzdCBpbiB0aGUgY2FzZSBvZiBCR1AgYW5k IExEUCwgdGhlc2UgcHJvdG9jb2xzCiAgIGFscmVhZHkgaGF2ZSBleGlzdGluZyBtZWNoYW5pc21z IGZvciBjcnlwdG9ncmFwaGljYWxseSBhdXRoZW50aWNhdGluZwogICBhbmQgaW50ZWdyaXR5IGNo ZWNraW5nIHRoZSBwYWNrZXRzIG9uIHRoZSB3aXJlLiAgUHJvZHVjdHMgd2l0aCB0aGVzZQogICBt ZWNoYW5pc21zIGhhdmUgYWxyZWFkeSBiZWVuIHByb2R1Y2VkLCBjb2RlIGhhcyBhbHJlYWR5IGJl ZW4gd3JpdHRlbgogICBhbmQgYm90aCBoYXZlIGJlZW4gb3B0aW1pemVkIGZvciB0aGUgZXhpc3Rp bmcgbWVjaGFuaXNtcy4gIFJhdGhlcgogICB0aGFuIHR1cm4gYXdheSBmcm9tIHRoZXNlIG1lY2hh bmlzbXMsIHdlIHdhbnQgdG8gZW5oYW5jZSB0aGVtLAogICB1cGRhdGluZyB0aGVtIHRvIG1vZGVy biBhbmQgc2VjdXJlIGxldmVscy4KCiAgIFRoZXJlIGFyZSB0d28gbWFpbiB3b3JrIHBoYXNlcyBm b3IgdGhpcyByb2FkbWFwLCBhbmQgZm9yIGFueSBSb3V0aW5nCiAgIFByb3RvY29sIHdvcmsgdW5k ZXJ0YWtlbiBhcyBwYXJ0IG9mIHRoaXMgcm9hZG1hcCAoZGlzY3Vzc2VkIGZ1cnRoZXIKICAgaW4g dGhlIFdvcmsgUGhhc2VzIChTZWN0aW9uIDQuMSkgc2VjdGlvbikuICBUaGUgZmlyc3QgaXMgdG8g ZW5oYW5jZQogICB0aGUgUm91dGluZyBQcm90b2NvbCdzIGN1cnJlbnQgYXV0aGVudGljYXRpb24g bWVjaGFuaXNtLCBlbnN1cmluZyBpdAogICBlbXBsb3lzIG1vZGVybiBjcnlwdG9ncmFwaGljIGFs Z29yaXRobXMgYW5kIG1ldGhvZHMgZm9yIGl0cyBiYXNpYwogICBvcGVyYXRpb25hbCBtb2RlbCwg ZnVsZmlsbGluZyB0aGUgcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gdGhlCiAgIFJlcXVpcmVtZW50 cyAoU2VjdGlvbiA0LjIpIHNlY3Rpb24sIGFuZCBwcm90ZWN0aW5nIGFnYWluc3QgYXMgbWFueSBv ZgogICB0aGUgdGhyZWF0cyBhcyBwb3NzaWJsZSBhcyBkZWZpbmVkIGluIHRoZSBUaHJlYXRzIChT ZWN0aW9uIDIuMSkKICAgc2VjdGlvbi4gIE1hbnkgb2YgdGhlIFJvdXRpbmcgUHJvdG9jb2xzJyBj dXJyZW50IG1lY2hhbmlzbXMgdXNlCiAgIG1hbnVhbCBrZXlzLCBzbyB0aGUgZmlyc3QgcGhhc2Ug dXBkYXRlcyB3aWxsIGZvY3VzIG9uIHNob3JpbmcgdXAgdGhlCiAgIG1hbnVhbCBrZXkgbWVjaGFu aXNtcyB0aGF0IGV4aXN0LgoKICAgVGhlIHNlY29uZCB3b3JrIHBoYXNlIGlzIHRvIGRlZmluZSB0 aGUgdXNlIG9mIGEga2V5IG1hbmFnZW1lbnQKICAgcHJvdG9jb2wgKEtNUCkgZm9yIGNyZWF0aW5n IGFuZCBtYW5hZ2luZyBzZXNzaW9uIGtleXMgdXNlZCBpbiB0aGUKICAgUm91dGluZyBQcm90b2Nv bHMnIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gYW5kIGRhdGEgaW50ZWdyaXR5CiAgIGZ1bmN0aW9u cy4gIEl0IGlzIGludGVuZGVkIHRoYXQgYSBnZW5lcmFsIEtNUCBmcmFtZXdvcmsgLS0gb3IgYSBz bWFsbAogICBudW1iZXIgb2YgZnJhbWV3b3JrcyAtLSBjYW4gYmUgZGVmaW5lZCBhbmQgbGV2ZXJh Z2VkIGZvciBtYW55IFJvdXRpbmcKICAgUHJvdG9jb2xzLgoKICAgVGhlcmVmb3JlLCB0aGUgc2Nv cGUgb2YgdGhpcyByb2FkbWFwIG9mIHdvcmsgaW5jbHVkZXM6CgoKCgoKCgoKTGVib3ZpdHogJiAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgIFtQYWdl IDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAg ICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgbyAgTWFraW5nIHVzZSBvZiBleGlzdGluZyByb3V0 aW5nIHByb3RvY29sIHNlY3VyaXR5IHByb3RvY29scywgd2hlcmUKICAgICAgdGhleSBleGlzdCwg YW5kIGVuaGFuY2luZyBvciB1cGRhdGluZyB0aGVtIGFzIG5lY2Vzc2FyeSBmb3IgbW9kZXJuCiAg ICAgIGNyeXB0b2dyYXBoaWMgYmVzdCBwcmFjdGljZXMsCgogICBvICBEZXZlbG9waW5nIGEgZnJh bWV3b3JrIGZvciB1c2luZyBhdXRvbWF0aWMga2V5IG1hbmFnZW1lbnQgaW4gb3JkZXIKICAgICAg dG8gZWFzZSBkZXBsb3ltZW50LCBsb3dlciBjb3N0IG9mIG9wZXJhdGlvbiwgYW5kIGFsbG93IGZv ciByYXBpZAogICAgICByZXNwb25zZXMgdG8gc2VjdXJpdHkgYnJlYWNoZXMsIGFuZAoKICAgbyAg U3BlY2lmeWluZyB0aGUgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50IHByb3RvY29sIHRoYXQgbWF5 IGJlCiAgICAgIGNvbWJpbmVkIHdpdGggdGhlIGJpdHMtb24tdGhlLXdpcmUgbWVjaGFuaXNtcy4K CiAgIFRoZSB3b3JrIGFsc28gc2VydmVzIGFzIGFuIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBSb3V0 aW5nIEFyZWEgYW5kIHRoZQogICBTZWN1cml0eSBBcmVhIGFib3V0IHRoZSBwcmlvcml0aWVzIGFu ZCB3b3JrIHBsYW4gZm9yIGluY3JlbWVudGFsbHkKICAgZGVsaXZlcmluZyB0aGUgYWJvdmUgd29y ay4gIFRoaXMgcG9pbnQgaXMgaW1wb3J0YW50LiAgVGhlcmUgd2lsbCBiZQogICB0aW1lcyB3aGVu IHRoZSBiZXN0LXNlY3VyaXR5LXBvc3NpYmxlIHdpbGwgZ2l2ZSB3YXkgdG8gdmFzdGx5LQogICBp bXByb3ZlZC1vdmVyLWN1cnJlbnQtc2VjdXJpdHktYnV0LWFkbWl0dGVkbHktbm90LXlldC1iZXN0 LXNlY3VyaXR5LQogICBwb3NzaWJsZSwgaW4gb3JkZXIgdGhhdCBpbmNyZW1lbnRhbCBwcm9ncmVz cyB0b3dhcmQgYSBtb3JlIHNlY3VyZQogICBJbnRlcm5ldCBtYXkgYmUgYWNoaWV2ZWQuICBBcyBz dWNoLCB0aGlzIGRvY3VtZW50IHdpbGwgY2FsbCBvdXQKICAgcGxhY2VzIHdoZXJlIGFncmVlbWVu dCBoYXMgYmVlbiByZWFjaGVkIG9uIHN1Y2ggdHJhZGUgb2Zmcy4KCiAgIFRoaXMgZG9jdW1lbnQg ZG9lcyBub3QgY29udGFpbiBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gIEluc3RlYWQsIGl0CiAg IGRlZmluZXMgdGhlIGFyZWFzIHdoZXJlIHByb3RvY29sIHNwZWNpZmljYXRpb24gd29yayBpcyBu ZWVkZWQgYW5kCiAgIHNldHMgYSBkaXJlY3Rpb24sIGEgc2V0IG9mIHJlcXVpcmVtZW50cywgYW5k IGEgcmVsYXRpdmUgcHJpb3JpdHkgZm9yCiAgIGFkZHJlc3NpbmcgdGhhdCBzcGVjaWZpY2F0aW9u IHdvcmsuCgogICBUaGVyZSBhcmUgYSBzZXQgb2YgdGhyZWF0cyB0byByb3V0aW5nIHByb3RvY29s cyB0aGF0IGFyZSBjb25zaWRlcmVkCiAgIGluLXNjb3BlIGZvciB0aGlzIGRvY3VtZW50L3JvYWRt YXAsIGFuZCBhIHNldCBjb25zaWRlcmVkIG91dC1vZi0KICAgc2NvcGUuICBUaGVzZSBhcmUgZGVz Y3JpYmVkIGluIGRldGFpbCBpbiB0aGUgVGhyZWF0cyAoU2VjdGlvbiAyKQogICBzZWN0aW9uIGJl bG93LgoKMS40LiAgR29hbHMKCiAgIFRoZSBnb2FscyBhbmQgZ2VuZXJhbCBndWlkYW5jZSBmb3Ig dGhpcyB3b3JrIHJvYWRtYXAgZm9sbG93OgoKICAgMS4gUHJvdmlkZSBhdXRoZW50aWNhdGlvbiBh bmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHBhY2tldHMgb24gdGhlCiAgICAgIHdpcmUgb2Yg ZXhpc3Rpbmcgcm91dGluZyBwcm90b2NvbHMKCiAgIDIuIERlbGl2ZXIgYSBwYXRoIHRvIGluY3Jl bWVudGFsbHkgaW1wcm92ZSBzZWN1cml0eSBvZiB0aGUgcm91dGluZwogICAgICBpbmZyYXN0cnVj dHVyZS4gIFRoZSBwcmluY2lwbGUgb2YgY3Jhd2wsIHdhbGssIHJ1biB3aWxsIGJlIGluCiAgICAg IHBsYWNlLiAgUm91dGluZyBwcm90b2NvbCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIG1heSBu b3QgZ28KICAgICAgaW1tZWRpYXRlbHkgZnJvbSB0aGVpciBjdXJyZW50IHN0YXRlIHRvIGEgc3Rh dGUgY29udGFpbmluZyB0aGUKICAgICAgYmVzdCBwb3NzaWJsZSwgbW9zdCBtb2Rlcm4gc2VjdXJp dHkgcHJhY3RpY2VzLiAgSW5jcmVtZW50YWwgc3RlcHMKICAgICAgd2lsbCBuZWVkIHRvIGJlIHRh a2VuIGZvciBhIGZldyB2ZXJ5IHByYWN0aWNhbCByZWFzb25zLiAgRmlyc3QsCiAgICAgIHRoZXJl IGFyZSBhIGNvbnNpZGVyYWJsZSBudW1iZXIgb2YgZGVwbG95ZWQgcm91dGluZyBkZXZpY2VzIGlu CiAgICAgIG9wZXJhdGluZyBuZXR3b3JrcyB0aGF0IHdpbGwgbm90IGJlIGFibGUgdG8gcnVuIHRo ZSBtb3N0IG1vZGVybgogICAgICBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMgd2l0aG91dCBzaWdu aWZpY2FudCBhbmQgdW5hY2NlcHRhYmxlCiAgICAgIHBlcmZvcm1hbmNlIHBlbmFsdGllcy4gIFRo ZSByb2FkbWFwIGZvciBhbnkgb25lIHJvdXRpbmcgcHJvdG9jb2wKICAgICAgTVVTVCBhbGxvdyBm b3IgaW5jcmVtZW50YWwgaW1wcm92ZW1lbnRzIG9uIGV4aXN0aW5nIG9wZXJhdGlvbmFsCgoKCkxl Ym92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAg ICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1h cCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgICAgIGRldmljZXMuICBTZWNvbmQs IGN1cnJlbnQgcm91dGluZyBwcm90b2NvbCBwZXJmb3JtYW5jZSBvbiBkZXBsb3llZAogICAgICBk ZXZpY2VzIGhhcyBiZWVuIGFjaGlldmVkIG92ZXIgdGhlIGxhc3QgMjAgeWVhcnMgdGhyb3VnaCBl eHRlbnNpdmUKICAgICAgdHVuaW5nIG9mIHNvZnR3YXJlIGFuZCBoYXJkd2FyZSBlbGVtZW50cywg YW5kIGlzIGEgY29uc3RhbnQgZm9jdXMKICAgICAgZm9yIGltcHJvdmVtZW50IGJ5IHZlbmRvcnMg YW5kIG9wZXJhdG9ycyBhbGlrZS4gIFRoZSBpbnRyb2R1Y3Rpb24KICAgICAgb2YgbmV3IHNlY3Vy aXR5IG1lY2hhbmlzbXMgYWZmZWN0cyB0aGlzIHBlcmZvcm1hbmNlIGJhbGFuY2UuICBUaGUKICAg ICAgcGVyZm9ybWFuY2UgaW1wYWN0IG9mIGFueSBpbmNyZW1lbnRhbCBzdGVwIG9mIHNlY3VyaXR5 IGltcHJvdmVtZW50CiAgICAgIHdpbGwgbmVlZCB0byBiZSB3ZWlnaGVkIGJ5IHRoZSBjb21tdW5p dHksIGFuZCBpbnRyb2R1Y2VkIGluIHN1Y2ggYQogICAgICB3YXkgdGhhdCBhbGxvd3MgdGhlIHZl bmRvciBhbmQgb3BlcmF0b3IgY29tbXVuaXR5IGEgcGF0aCB0bwogICAgICBhZG9wdGlvbiB0aGF0 IHVwaG9sZHMgcmVhc29uYWJsZSBwZXJmb3JtYW5jZSBtZXRyaWNzLiAgVGhlcmVmb3JlLAogICAg ICBjZXJ0YWluIHNwZWNpZmljYXRpb24gZWxlbWVudHMgbWF5IGJlIGludHJvZHVjZWQgY2Fycnlp bmcgdGhlCiAgICAgICJTSE9VTEQiIGd1aWRhbmNlLCB3aXRoIHRoZSBpbnRlbnRpb24gdGhhdCB0 aGUgc2FtZSBtZWNoYW5pc20gd2lsbAogICAgICBjYXJyeSBhICJNVVNUIiBpbiB0aGUgbmV4dCBy ZWxlYXNlIG9mIHRoZSBzcGVjaWZpY2F0aW9uLiAgVGhpcwogICAgICBnaXZlcyB0aGUgdmVuZG9y cyBhbmQgaW1wbGVtZW50b3JzIHRoZSBndWlkYW5jZSB0aGV5IG5lZWQgdG8gdHVuZQogICAgICB0 aGVpciBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgYXBwcm9wcmlhdGVseSBvdmVyIHRpbWUuICBMYXN0 LCBzb21lCiAgICAgIHNlY3VyaXR5IG1lY2hhbmlzbXMgcmVxdWlyZSB0aGUgYnVpbGQgb3V0IG9m IG90aGVyIG9wZXJhdGlvbmFsCiAgICAgIHN1cHBvcnQgc3lzdGVtcywgYW5kIHRoaXMgd2lsbCB0 YWtlIHRpbWUuICBBbiBleGFtcGxlIHdoZXJlIHRoZXNlCiAgICAgIHRocmVlIHJlYXNvbnMgYXJl IGF0IHBsYXkgaW4gYW4gaW5jcmVtZW50YWwgaW1wcm92ZW1lbnQgcm9hZG1hcCBpcwogICAgICBz ZWVuIGluIHRoZSBpbXByb3ZlbWVudCBvZiBCR1AncyBbUkZDNDI3MV0gc2VjdXJpdHkgdmlhIHRo ZSB1cGRhdGUKICAgICAgb2YgdGhlIFRDUCBBdXRoZW50aWNhdGlvbiBPcHRpb24gKFRDUC1BTykK ICAgICAgW0ktRC5pZXRmLXRjcG0tdGNwLWF1dGgtb3B0XSBlZmZvcnQuICBJdCB3b3VsZCBiZSBp ZGVhbCwgYW5kCiAgICAgIHJlZmxlY3QgYmVzdCBjb21tb24gc2VjdXJpdHkgcHJhY3RpY2UsIHRv IGhhdmUgYSBmdWxseSBzcGVjaWZpZWQKICAgICAga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9y IG5lZ290aWF0aW5nIFRDUC1BTydzIGF1dGhlbnRpY2F0aW9uCiAgICAgIG1hdGVyaWFsLCB1c2lu ZyBjZXJ0aWZpY2F0ZXMgZm9yIHBlZXIgYXV0aGVudGljYXRpb24gaW4gdGhlCiAgICAgIGtleWlu Zy4gIEhvd2V2ZXIsIGluIHRoZSBzcGlyaXQgb2YgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgd2Ug d2lsbAogICAgICBmaXJzdCBhZGRyZXNzIGlzc3VlcyBsaWtlIGNyeXB0b2dyYXBoaWMgYWxnb3Jp dGhtIGFnaWxpdHksIHJlcGxheQogICAgICBhdHRhY2tzLCBUQ1Agc2Vzc2lvbiByZXNldHRpbmcg aW4gdGhlIGJhc2UgVENQLUFPIHByb3RvY29sIGJlZm9yZQogICAgICB3ZSBsYXllciBrZXkgbWFu YWdlbWVudCBvbiB0b3Agb2YgaXQuCgogICAzLiBUaGUgZGVwbG95LWFiaWxpdHkgb2YgdGhlIGlt cHJvdmVkIHNlY3VyaXR5IHNvbHV0aW9ucyBvbiBjdXJyZW50bHkKICAgICAgcnVubmluZyByb3V0 aW5nIGluZnJhc3RydWN0dXJlIGVxdWlwbWVudC4gIFRoaXMgYmVncyB0aGUKICAgICAgY29uc2lk ZXJhdGlvbiBvZiB0aGUgY3VycmVudCBzdGF0ZSBvZiBwcm9jZXNzaW5nIHBvd2VyIGF2YWlsYWJs ZQogICAgICBvbiByb3V0ZXJzIGluIHRoZSBuZXR3b3JrIHRvZGF5LgoKICAgNC4gT3BlcmF0aW9u YWwgZGVwbG95LWFiaWxpdHkgLSBBIHNvbHV0aW9ucyBhY2NlcHRhYmlsaXR5IHdpbGwgYWxzbwog ICAgICBiZSBtZWFzdXJlZCBieSBob3cgZGVwbG95YWJsZSB0aGUgc29sdXRpb24gaXMgYnkgY29t bW9uIG9wZXJhdG9yCiAgICAgIHRlYW1zIHVzaW5nIGNvbW1vbiBkZXBsb3ltZW50IHByb2Nlc3Nl cyBhbmQgaW5mcmFzdHJ1Y3R1cmVzLiAgSS5lLgogICAgICBXZSB3aWxsIHRyeSB0byBtYWtlIHRo ZXNlIHNvbHV0aW9ucyBmaXQgYXMgd2VsbCBhcyBwb3NzaWJsZSBpbnRvCiAgICAgIGN1cnJlbnQg b3BlcmF0aW9uYWwgcHJhY3RpY2VzIG9yIHJvdXRlciBkZXBsb3ltZW50LiAgVGhpcyB3aWxsIGJl CiAgICAgIGhlYXZpbHkgaW5mbHVlbmNlZCBieSBvcGVyYXRvciBpbnB1dCwgdG8gZW5zdXJlIHRo YXQgd2hhdCB3ZQogICAgICBzcGVjaWZ5IGNhbiAtLSBhbmQsIG1vcmUgaW1wb3J0YW50bHksIHdp bGwgLS0gYmUgZGVwbG95ZWQgb25jZQogICAgICBzcGVjaWZpZWQgYW5kIGltcGxlbWVudGVkIGJ5 IHZlbmRvcnMuICBEZXBsb3ltZW50IG9mIGluY3JlbWVudGFsbHkKICAgICAgbW9yZSBzZWN1cmUg cm91dGluZyBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgSW50ZXJuZXQgaXMgdGhlIGZpbmFsCiAgICAg IG1lYXN1cmUgb2Ygc3VjY2Vzcy4gIE1lYXN1cmFibHksIHdlIHdvdWxkIGxpa2UgdG8gc2VlIGFu IGluY3JlYXNlCiAgICAgIGluIHRoZSBudW1iZXIgb2Ygc3VydmV5ZWQgcmVzcG9uZGVudHMgd2hv IHJlcG9ydCBkZXBsb3lpbmcgdGhlCiAgICAgIHVwZGF0ZWQgYXV0aGVudGljYXRpb24gbWVjaGFu aXNtcyBhbnl3aGVyZSBhY3Jvc3MgdGhlaXIgbmV0d29yaywKICAgICAgYXMgd2VsbCBhcyBhIHNo YXJwIHJpc2UgaW4gdXNhZ2UgZm9yIHRoZSB0b3RhbCBwZXJjZW50YWdlIG9mIHRoZWlyCiAgICAg IG5ldHdvcmsncyByb3V0ZXJzLgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5 CgoKCiAgICAgIEludGVydmlld3Mgd2l0aCBvcGVyYXRvcnMgc2hvdyBzZXZlcmFsIHBvaW50cyBh Ym91dCByb3V0aW5nCiAgICAgIHNlY3VyaXR5LiAgRmlyc3QsIG92ZXIgNzAlIG9mIG9wZXJhdG9y cyBoYXZlIGRlcGxveWVkIHRyYW5zcG9ydAogICAgICBjb25uZWN0aW9uIHByb3RlY3Rpb24gdmlh IFRDUC1NRDUgb24gdGhlaXIgRUJHUCBbSVNSMjAwOF0gLiAgT3ZlcgogICAgICA1NSUgYWxzbyBk ZXBsb3kgTUQ1IG9uIHRoZWlyIElCR1AgY29ubmVjdGlvbnMsIGFuZCA1MCUgZGVwbG95IE1ENQog ICAgICBvbiBzb21lIG90aGVyIElHUC4gIFRoZSBzdXJ2ZXkgc3RhdGVzIHRoYXQgImEgY29uc2lk ZXJhYmxlCiAgICAgIGluY3JlYXNlIHdhcyBvYnNlcnZlZCBvdmVyIHByZXZpb3VzIGVkaXRpb25z IG9mIHRoZSBzdXJ2ZXkgZm9yIHVzZQogICAgICBvZiBUQ1AgTUQ1IHdpdGggZXh0ZXJuYWwgcGVl cnMgKGVCR1ApLCBpbnRlcm5hbCBwZWVycyAoaUJHUCkgYW5kCiAgICAgIE1ENSBleHRlbnNpb25z IGZvciBJR1BzLiIgIFRob3VnaCB0aGUgZGF0YSBpcyBub3QgY2FwdHVyZWQgaW4gdGhlCiAgICAg IHJlcG9ydCwgdGhlIGF1dGhvcnMgYmVsaWV2ZSBhbmVjZG90YWxseSB0aGF0IG9mIHRob3NlIHdo byBoYXZlCiAgICAgIGRlcGxveWVkIE1ENSBzb21ld2hlcmUgaW4gdGhlaXIgbmV0d29yaywgb25s eSBhYm91dCAyNS0zMCUgb2YgdGhlCiAgICAgIHJvdXRlcnMgaW4gdGhlaXIgbmV0d29yayBhcmUg ZGVwbG95ZWQgd2l0aCB0aGUgYXV0aGVudGljYXRpb24KICAgICAgZW5hYmxlZC4gIE5vbmUgcmVw b3J0IHVzaW5nIElQc2VjIHRvIHByb3RlY3QgdGhlIHJvdXRpbmcgcHJvdG9jb2wsCiAgICAgIGFu ZCB0aGlzIHdhcyBhIGRlY2xpbmUgZnJvbSB0aGUgZmV3IHRoYXQgcmVwb3J0ZWQgZG9pbmcgc28g aW4gdGhlCiAgICAgIHByZXZpb3VzIHllYXIncyByZXBvcnQuCiAgICAgIEZyb20gbXkgcGVyc29u YWwgY29udmVyc2F0aW9ucyB3aXRoIG9wZXJhdG9ycywgb2YgdGhvc2UgdXNpbmcgTUQ1LAogICAg ICBhbG1vc3QgYWxsIHJlcG9ydCBkZXBsb3lpbmcgd2l0aCBvbmUgc2luZ2xlIG1hbnVhbCBrZXkg dGhyb3VnaG91dAogICAgICB0aGUgZW50aXJlIG5ldHdvcmsuICBUaGVzZSBzYW1lIG9wZXJhdG9y cyByZXBvcnQgdGhhdCB0aGUgb25lCiAgICAgIHNpbmdsZSBrZXkgaGFzIG5vdCBiZWVuIGNoYW5n ZWQgc2luY2UgaXQgd2FzIG9yaWdpbmFsbHkgaW5zdGFsbGVkLAogICAgICBzb21ldGltZXMgZml2 ZSBvciBtb3JlIHllYXJzIGFnby4gIFdoZW4gYXNrZWQgd2h5LCBwYXJ0aWN1bGFybHkKICAgICAg Zm9yIHRoZSBjYXNlIG9mIEJHUCB1c2luZyBUQ1AgTUQ1LCB0aGUgZm9sbG93aW5nIHJlYXNvbnMg YXJlIG9mdGVuCiAgICAgIGdpdmVuOgoKCiAgICAgIEEuICBDaGFuZ2luZyB0aGUga2V5cyB0cmln Z2VycyBhIFRDUCByZXNldCwgYW5kIHRodXMgYm91bmNlcyB0aGUKICAgICAgICAgIGxpbmtzL2Fk amFjZW5jaWVzLCB1bmRlcm1pbmluZyBTZXJ2aWNlIExldmVsIEFncmVlbWVudHMKICAgICAgICAg IChTTEFzKS4KICAgICAgQi4gIEZvciBleHRlcm5hbCBwZWVycywgZGlmZmljdWx0eSBvZiBjb29y ZGluYXRpb24gd2l0aCB0aGUgb3RoZXIKICAgICAgICAgIG9yZ2FuaXphdGlvbiBpcyBhbiBpc3N1 ZS4gIE9uY2UgdGhleSBmaW5kIHRoZSBjb3JyZWN0IGNvbnRhY3QKICAgICAgICAgIGF0IHRoZSBv dGhlciBvcmdhbml6YXRpb24gKG5vdCBhbHdheXMgc28gZWFzeSksIHRoZQogICAgICAgICAgY29v cmRpbmF0aW9uIGZ1bmN0aW9uIGlzIHNlcmlhbGl6ZWQgYW5kIG9uIGEgcGVyIHBlZXIvQVMKICAg ICAgICAgIGJhc2lzLiAgVGhlIGNvb3JkaW5hdGlvbiBpcyB2ZXJ5IGN1bWJlcnNvbWUgYW5kIHRl ZGlvdXMgdG8KICAgICAgICAgIGV4ZWN1dGUgaW4gcHJhY3RpY2UuCiAgICAgIEMuICBLZXlzIG11 c3QgYmUgY2hhbmdlZCBhdCBwcmVjaXNlbHkgdGhlIHNhbWUgdGltZSwgb3IgYXQgbGVhc3QKICAg ICAgICAgIHdpdGhpbiA2MCBzZWNvbmRzIChhcyBzdXBwb3J0ZWQgYnkgdHdvIG1ham9yIHZlbmRv cnMpIGluIG9yZGVyCiAgICAgICAgICB0byBsaW1pdCBjb25uZWN0aXZpdHkgb3V0YWdlIGR1cmF0 aW9uLiAgVGhpcyBpcyBpbmNyZWRpYmx5CiAgICAgICAgICBkaWZmaWN1bHQgdG8gZG8sIG9wZXJh dGlvbmFsbHksIGVzcGVjaWFsbHkgYmV0d2VlbiBkaWZmZXJlbnQKICAgICAgICAgIG9yZ2FuaXph dGlvbnMuCiAgICAgIEQuICBSZWxhdGl2ZWx5IGxvdyBwcmlvcml0eSBjb21wYXJlZCB0byBvdGhl ciBvcGVyYXRvaW5hbCBpc3N1ZXMuCiAgICAgIEUuICBMYWNrIG9mIHN0YWZmIHRvIGltcGxlbWVu dCB0aGUgY2hhbmdlcyBkZXZpY2UgYnkgZGV2aWNlLgogICAgICBGLiAgVGhlcmUgYXJlIHRocmVl IHVzZSBjYXNlcyBmb3Igb3BlcmF0aW9uYWwgcGVlcmluZyBhdCBwbGF5CiAgICAgICAgICBoZXJl OiBwZWVycyBhbmQgaW50ZXJjb25uZWN0aW9uIHdpdGggb3RoZXIgb3BlcmF0b3JzLCBJbnRlcm5h bAogICAgICAgICAgQkdQIGFuZCBvdGhlciByb3V0aW5nIHNlc3Npb25zIHdpdGhpbiBhIHNpbmds ZSBvcGVyYXRvciwgYW5kCiAgICAgICAgICBvcGVyYXRvci10by1jdXN0b21lci1DUEUgZGV2aWNl cy4gIEFsbCB0aHJlZSBoYXZlIHZlcnkKICAgICAgICAgIGRpZmZlcmVudCBwcm9wZXJ0aWVzLCBh bmQgYWxsIGFyZSByZXBvcnRlZCBhcyBjdW1iZXJzb21lLiAgT25lCiAgICAgICAgICBvcGVyYXRv ciByZXBvcnRlZCB0aGF0IHRoZSBzYW1lIGtleSBpcyB1c2VkIGZvciBhbGwgY3VzdG9tZXIKICAg ICAgICAgIHByZW1pc2UgZXF1aXBtZW50LiAgVGhlIHNhbWUgb3BlcmF0b3IgcmVwb3J0ZWQgdGhh dCBpZiB0aGUKICAgICAgICAgIGN1c3RvbWVyIG1hbmRhdGVkLCBhIHVuaXF1ZSBrZXkgY291bGQg YmUgY3JlYXRlZCwgYWx0aG91Z2ggdGhlCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4 cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIg MjAwOQoKCiAgICAgICAgICBsYXN0IHRpbWUgdGhpcyBvY2N1cnJlZCBpdCBjcmVhdGVkIHN1Y2gg YW4gb3BlcmF0aW9uYWwKICAgICAgICAgIGhlYWRhY2hlIHRoYXQgdGhlIGFkbWluaXN0cmF0b3Jz IG5vdyB1c3VhbGx5IHRlbGwgY3VzdG9tZXJzCiAgICAgICAgICB0aGF0IHRoZSBvcHRpb24gZG9l c24ndCBldmVuIGV4aXN0LCB0byBhdm9pZCB0aGUgZGlmZmljdWx0aWVzLgogICAgICAgICAgVGhl c2UgY3VzdG9tZXItdW5pcWUga2V5cyBhcmUgbmV2ZXIgY2hhbmdlZCwgdW5sZXNzIHRoZQogICAg ICAgICAgY3VzdG9tZXIgZGVtYW5kcyBzby4KICAgICAgVGhlIG1haW4gdGhyZWF0IGF0IHBsYXkg aGVyZSBpcyB0aGF0IGEgdGVybWluYXRlZCBlbXBsb3llZSBmcm9tCiAgICAgIHN1Y2ggYW4gb3Bl cmF0b3Igd2hvIGhhZCBhY2Nlc3MgdG8gdGhlIG9uZSAob3IgZmV3KSBrZXlzIHVzZWQgZm9yCiAg ICAgIGF1dGhlbnRpY2F0aW9uIGluIHRoZXNlIGVudmlyb25tZW50cyBjb3VsZCBlYXNpbHkgd2Fn ZSBhbiBhdHRhY2sKICAgICAgLS0gb3Igb2ZmZXIgdGhlIGtleXMgdG8gb3RoZXJzIHdobyB3b3Vs ZCB3YWdlIHRoZSBhdHRhY2sgLS0gYW5kCiAgICAgIGJyaW5nIGRvd24gbWFueSBvZiB0aGUgYWRq YWNlbmNpZXMsIGNhdXNpbmcgZGVzdGFiaWxpemF0aW9uIHRvIHRoZQogICAgICByb3V0aW5nIHN5 c3RlbS4KCiAgICAgIFdoYXRldmVyIG1lY2hhbmlzbXMgd2Ugc3BlY2lmeSBuZWVkIHRvIGJlIGVh c2llciB0aGFuIHRoZSBjdXJyZW50CiAgICAgIG1ldGhvZHMgdG8gZGVwbG95LCBhbmQgc2hvdWxk IHByb3ZpZGUgb2J2aW91cyBvcGVyYXRpb25hbAogICAgICBlZmZpY2llbmN5IGdhaW5zIGFsb25n IHdpdGggc2lnbmlmaWNhbnRseSBiZXR0ZXIgc2VjdXJpdHkgYW5kCiAgICAgIHRocmVhdCBwcm90 ZWN0aW9uLiAgVGhpcyBjb21iaW5hdGlvbiBvZiB2YWx1ZSBtYXkgYmUgZW5vdWdoIHRvCiAgICAg IGRyaXZlIG11Y2ggYnJvYWRlciBhZG9wdGlvbi4KCiAgIDUuIEFkZHJlc3MgdGhlIHRocmVhdHMg ZW51bWVyYXRlZCBhYm92ZSBpbiB0aGUgIlRocmVhdHMiIHNlY3Rpb24KICAgICAgKFNlY3Rpb24g MikgZm9yIGVhY2ggcm91dGluZyBwcm90b2NvbCwgYWxvbmcgYSByb2FkbWFwLiAgTm90IGFsbAog ICAgICB0aHJlYXRzIG1heSBiZSBhYmxlIHRvIGJlIGFkZHJlc3NlZCBpbiB0aGUgZmlyc3Qgc3Bl Y2lmaWNhdGlvbgogICAgICB1cGRhdGUgZm9yIGFueSBvbmUgcHJvdG9jb2wuICBSb2FkbWFwcyB3 aWxsIGJlIGRlZmluZWQgc28gdGhhdAogICAgICBib3RoIHRoZSBzZWN1cml0eSBhcmVhIGFuZCB0 aGUgcm91dGluZyBhcmVhIGFncmVlIG9uIGhvdyB0aGUKICAgICAgdGhyZWF0cyB3aWxsIGJlIGFk ZHJlc3NlZCBjb21wbGV0ZWx5IG92ZXIgdGltZS4KCiAgIDYuIENyZWF0ZSBhIHJlLXVzYWJsZSBh cmNoaXRlY3R1cmUsIGZyYW1ld29yaywgYW5kIGd1aWRlbGluZXMgZm9yCiAgICAgIHZhcmlvdXMg SUVURiB3b3JraW5nIHRlYW1zIHdobyB3aWxsIGFkZHJlc3MgdGhlc2Ugc2VjdXJpdHkKICAgICAg aW1wcm92ZW1lbnRzIGZvciB2YXJpb3VzIFJvdXRpbmcgUHJvdG9jb2xzLiAgVGhlIGNydXggb2Yg dGhlIEtBUlAKICAgICAgd29yayBpcyB0byByZS11c2UgdGhhdCBmcmFtZXdvcmsgYXMgbXVjaCBh cyBwb3NzaWJsZSBhY3Jvc3MKICAgICAgcmVsZXZhbnQgUm91dGluZyBQcm90b2NvbHMuICBGb3Ig ZXhhbXBsZSwgZGVzaWduZXJzIHNob3VsZCBhaW0gdG8KICAgICAgcmUtdXNlIHRoZSBrZXkgbWFu YWdlbWVudCBwcm90b2NvbCB0aGF0IHdpbGwgYmUgZGVmaW5lZCBmb3IgQkdQJ3MKICAgICAgVENQ LUFPIGtleSBlc3RhYmxpc2htZW50IGZvciBhcyBtYW55IG90aGVyIHJvdXRpbmcgcHJvdG9jb2xz IGFzCiAgICAgIHBvc3NpYmxlLiAgVGhpcyBpcyBidXQgb25lIGV4YW1wbGUuCgogICA3LiBCcmlk Z2UgYW55IGdhcHMgYmV0d2VlbiBJRVRGJ3MgUm91dGluZyBhbmQgU2VjdXJpdHkgQXJlYXMgYnkK ICAgICAgcmVjb3JkaW5nIGFncmVlbWVudHMgb24gd29yayBpdGVtcywgcm9hZG1hcHMsIGFuZCBn dWlkYW5jZSBmcm9tCiAgICAgIHRoZSBBcmVhIGxlYWRzIGFuZCBJbnRlcm5ldCBBcmNoaXRlY3R1 cmUgQm9hcmQgKElBQiwgd3d3LmlhYi5vcmcpLgoKCjEuNS4gIE5vbi1Hb2FscwoKICAgVGhlIGZv bGxvd2luZyB0d28gZ29hbHMgYXJlIGNvbnNpZGVyZWQgb3V0LW9mLXNjb3BlIGZvciB0aGlzIGVm Zm9ydDoKCiAgIG8gIFByaXZhY3kgb2YgdGhlIHBhY2tldHMgb24gdGhlIHdpcmUsIGF0IHRoaXMg cG9pbnQgaW4gdGltZS4gIE9uY2UKICAgICAgdGhpcyByb2FkbWFwIGlzIHJlYWxpemVkLCB3ZSBt YXkgcmV2aXNpdCB3b3JrIG9uIHByaXZhY3kuCgoKCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwOQoKCgogICBvICBNZXNzYWdlIGNvbnRlbnQgc2VjdXJpdHkuICBUaGlzIHdvcmsg aXMgYmVpbmcgYWRkcmVzc2VkIGluIG90aGVyCiAgICAgIElFVEYgZWZmb3J0cywgbGlrZSBTSURS LgoKMS42LiAgQXVkaWVuY2UKCiAgIFRoZSBhdWRpZW5jZSBmb3IgdGhpcyByb2FkbWFwIGluY2x1 ZGVzOgoKICAgbyAgUm91dGluZyBBcmVhIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGFuZCBwYXJ0aWNp cGFudHMgLSAgIFRoZXNlCiAgICAgICAgcGVvcGxlIGFyZSBjaGFyZ2VkIHdpdGggdXBkYXRlcyB0 byB0aGUgUm91dGluZyBQcm90b2NvbAogICAgICAgIHNwZWNpZmljYXRpb25zLiAgQW55IGFuZCBh bGwgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiB3b3JrCiAgICAgICAgb24gdGhlc2Ugc3Bl Y2lmaWNhdGlvbnMgd2lsbCBvY2N1ciBpbiBSb3V0aW5nIEFyZWEgd29ya2luZwogICAgICAgIGdy b3Vwcywgd2l0aCBjbG9zZSBwYXJ0bmVyc2hpcCB3aXRoIHRoZSBTZWN1cml0eSBBcmVhLiAgQ28t CiAgICAgICAgYWR2aXNvcnMgZnJvbSBTZWN1cml0eSBBcmVhIG1heSBvZnRlbiBiZSBuYW1lZCBm b3IgdGhlc2UKICAgICAgICBwYXJ0bmVyc2hpcCBlZmZvcnRzLgoKICAgbyAgU2VjdXJpdHkgQXJl YSByZXZpZXdlcnMgb2Ygcm91dGluZyBhcmVhIGRvY3VtZW50cyAtICAgVGhlc2UgcGVvcGxlCiAg ICAgICAgYXJlIGRlbGVnYXRlZCBieSB0aGUgU2VjdXJpdHkgQXJlYSBEaXJlY3RvcnMgdG8gcGVy Zm9ybSByZXZpZXdzCiAgICAgICAgb24gcm91dGluZyBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyBh cyB0aGV5IHBhc3MgdGhyb3VnaCB3b3JraW5nCiAgICAgICAgZ3JvdXAgbGFzdCBjYWxsIG9yIElF U0cgcmV2aWV3LiAgVGhleSB3aWxsIHBheSBwYXJ0aWN1bGFyCiAgICAgICAgYXR0ZW50aW9uIHRv IHRoZSB1c2Ugb2YgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiBhbmQKICAgICAgICBjb3Jy ZXNwb25kaW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgZm9yIHRoZSByb3V0aW5nIHByb3RvY29scy4K ICAgICAgICBUaGV5IHdpbGwgZW5zdXJlIHRoYXQgaW5jcmVtZW50YWwgc2VjdXJpdHkgaW1wcm92 ZW1lbnRzIGFyZQogICAgICAgIGJlaW5nIG1hZGUsIGluIGxpbmUgd2l0aCB0aGlzIHJvYWRtYXAu CgogICBvICBTZWN1cml0eSBBcmVhIGVuZ2luZWVycyAtICAgVGhlc2UgcGVvcGxlIHBhcnRuZXIg d2l0aCByb3V0aW5nIGFyZWEKICAgICAgICBhdXRob3JzL2Rlc2lnbmVycyBvbiB0aGUgc2VjdXJp dHkgbWVjaGFuaXNtcyBpbiByb3V0aW5nIHByb3RvY29sCiAgICAgICAgc3BlY2lmaWNhdGlvbnMu ICBTb21lIG9mIHRoZXNlIHNlY3VyaXR5IGFyZWEgZW5naW5lZXJzIHdpbGwgYmUKICAgICAgICBh c3NpZ25lZCBieSB0aGUgU2VjdXJpdHkgQXJlYSBEaXJlY3RvcnMsIHdoaWxlIG90aGVycyB3aWxs IGJlCiAgICAgICAgaW50ZXJlc3RlZCBwYXJ0aWVzIGluIHRoZSByZWxldmFudCB3b3JraW5nIGdy b3Vwcy4KCiAgIG8gIE9wZXJhdG9ycyAtICAgVGhlIG9wZXJhdG9ycyBhcmUgYSBrZXkgYXVkaWVu Y2UgZm9yIHRoaXMgd29yaywgYXMKICAgICAgICB0aGUgd29yayBpcyBjb25zaWRlcmVkIHRvIGhh dmUgc3VjY2VlZGVkIGlmIHRoZSBvcGVyYXRvcnMgZGVwbG95CiAgICAgICAgdGhlIHRlY2hub2xv Z3ksIHByZXN1bWFibHkgZHVlIHRvIGEgcGVyY2VwdGlvbiBvZiBzaWduaWZpY2FudGx5CiAgICAg ICAgaW1wcm92ZWQgc2VjdXJpdHkgdmFsdWUgY291cGxlZCB3aXRoIHJlbGF0aXZlIHNpbWlsYXJp dHkgdG8KICAgICAgICBkZXBsb3ltZW50IGNvbXBsZXhpdHkgYW5kIGNvc3QuICBDb252ZXJzZWx5 LCB0aGUgd29yayB3aWxsIGJlCiAgICAgICAgY29uc2lkZXJlZCBhIGZhaWx1cmUgaWYgdGhlIG9w ZXJhdG9ycyBkbyBub3QgY2FyZSB0byBkZXBsb3kgaXQsCiAgICAgICAgZWl0aGVyIGR1ZSB0byBs YWNrIG9mIHZhbHVlIG9yIHBlcmNlaXZlZCAob3IgcmVhbCkgb3Zlci0KICAgICAgICBjb21wbGV4 aXR5IG9mIG9wZXJhdGlvbnMuICBBbmQgYXMgc3VjaCwgdGhlIEdST1cgYW5kIE9QU0VDIFdHcwog ICAgICAgIHNob3VsZCBiZSBrZXB0IHNxdWFyZWx5IGluIHRoZSBsb29wIGFzIHdlbGwuCgoKCgoy LiAgVGhyZWF0cwoKICAgSW4gUkZDNDk0OVtSRkM0OTQ5XSwgYSB0aHJlYXQgaXMgZGVmaW5lZCBh cyBhIHBvdGVudGlhbCBmb3IgdmlvbGF0aW9uCiAgIG9mIHNlY3VyaXR5LCB3aGljaCBleGlzdHMg d2hlbiB0aGVyZSBpcyBhIGNpcmN1bXN0YW5jZSwgY2FwYWJpbGl0eSwKCgoKTGVib3ZpdHogJiAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2Ug MTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAg ICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgYWN0aW9uLCBvciBldmVudCB0aGF0IGNvdWxkIGJy ZWFjaCBzZWN1cml0eSBhbmQgY2F1c2UgaGFybS4gIFRoaXMKICAgc2VjdGlvbiBkZWZpbmVzIHRo ZSB0aHJlYXRzIHRoYXQgYXJlIGluIHNjb3BlIGZvciB0aGlzIHJvYWRtYXAsIGFuZAogICB0aG9z ZSB0aGF0IGFyZSBleHBsaWNpdGx5IG91dCBvZiBzY29wZS4gIFRoaXMgZG9jdW1lbnQgbGV2ZXJh Z2VzIHRoZQogICAiR2VuZXJpYyBUaHJlYXRzIHRvIFJvdXRpbmcgUHJvdG9jb2xzIiBtb2RlbCwg UkZDIDQ1OTMgW1JGQzQ1OTNdICwKICAgY2FwaXRhbGl6ZXMgdGVybXMgZnJvbSB0aGF0IGRvY3Vt ZW50LCBhbmQgb2ZmZXJzIGEgdGVyc2UgZGVmaW5pdGlvbgogICBvZiB0aG9zZSB0ZXJtcy4gIChN b3JlIHRob3JvdWdoIGRlc2NyaXB0aW9uIG9mIHJvdXRpbmcgcHJvdG9jb2wKICAgdGhyZWF0cyBz b3VyY2VzLCBtb3RpdmF0aW9ucywgY29uc2VxdWVuY2VzIGFuZCBhY3Rpb25zIGNhbiBiZSBmb3Vu ZAogICBpbiBSRkMgNDU5MyBbUkZDNDU5M10gaXRzZWxmKS4gIFRoZSB0aHJlYXQgbGlzdGluZ3Mg YmVsb3cgZXhwYW5kIHVwb24KICAgdGhlc2UgdGhyZWF0IGRlZmluaXRpb25zLgoKMi4xLiAgVGhy ZWF0cyBJbiBTY29wZQoKICAgVGhlIHRocmVhdHMgdGhhdCB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0 aGlzIHJvYWRtYXAgYXJlIHRob3NlIGZyb20KICAgT1VUU0lERVJTLCBhdHRhY2tlcnMgdGhhdCBt YXkgcmVzaWRlIGFueXdoZXJlIGluIHRoZSBJbnRlcm5ldCwgaGF2ZQogICB0aGUgYWJpbGl0eSB0 byBzZW5kIElQIHRyYWZmaWMgdG8gdGhlIHJvdXRlciwgbWF5IGJlIGFibGUgdG8gb2JzZXJ2ZQog ICB0aGUgcm91dGVyJ3MgcmVwbGllcywgYW5kIG1heSBldmVuIGNvbnRyb2wgdGhlIHBhdGggZm9y IGEgbGVnaXRpbWF0ZQogICBwZWVyJ3MgdHJhZmZpYy4gIFRoZXNlIGFyZSBub3QgbGVnaXRpbWF0 ZSBwYXJ0aWNpcGFudHMgaW4gdGhlIHJvdXRpbmcKICAgcHJvdG9jb2wuICBNZXNzYWdlIGF1dGhl bnRpY2F0aW9uIGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbgogICBzcGVjaWZpY2FsbHkgYWltcyB0 byBpZGVudGlmeSBtZXNzYWdlcyBvcmlnaW5hdGluZyBmcm9tIE9VVFNJREVSUy4KCiAgIFRoZSBj b25jZXB0IG9mIE9VVFNJREVSUyBjYW4gYmUgZnVydGhlciByZWZpbmVkIHRvIGluY2x1ZGUgYXR0 YWNrZXJzCiAgIHdobyBhcmUgdGVybWluYXRlZCBlbXBsb3llZXMsIGFuZCB0aG9zZSBzaXR0aW5n IG9uLXBhdGguCgogICBvICBPbi1QYXRoIC0gYXR0YWNrZXJzIHdpdGggY29udHJvbCBvZiBhIG5l dHdvcmsgcmVzb3VyY2Ugb3IgYSB0YXAKICAgICAgYWxvbmcgdGhlIHBhdGggb2YgcGFja2V0cyBi ZXR3ZWVuIHR3byByb3V0ZXJzLiAgQW4gb24tcGF0aAogICAgICBvdXRzaWRlciBjYW4gYXR0ZW1w dCBhIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFjaywgaW4gYWRkaXRpb24gdG8KICAgICAgc2V2ZXJh bCBvdGhlciBhdHRhY2sgY2xhc3Nlcy4gIEEgbWFuLWluLXRoZS1taWRkbGUgKE1pdE0pIGF0dGFj awogICAgICBvY2N1cnMgd2hlbiBhbiBhdHRhY2tlciB3aG8gaGFzIGFjY2VzcyB0byBwYWNrZXRz IGZsb3dpbmcgYmV0d2VlbgogICAgICB0d28gcGVlcnMgdGFtcGVycyB3aXRoIHRob3NlIHBhY2tl dHMgaW4gc3VjaCBhIHdheSB0aGF0IGJvdGggcGVlcnMKICAgICAgdGhpbmsgdGhleSBhcmUgdGFs a2luZyB0byBlYWNoIG90aGVyIGRpcmVjdGx5LCB3aGVuIGluIGZhY3QgdGhleQogICAgICBhcmUg YWN0dWFsbHkgdGFsa2luZyB0byB0aGUgYXR0YWNrZXIgb25seS4gIFByb3RvY29scyBjb25mb3Jt aW5nCiAgICAgIHRvIHRoaXMgcm9hZG1hcCB3aWxsIHVzZSBjcnlwdG9ncmFwaGljIG1lY2hhbmlz bXMgdG8gcHJldmVudCBhCiAgICAgIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja2VyIGZyb20gc2l0 dWF0aW5nIGhpbXNlbGYgdW5kZXRlY3RlZC4KCiAgIG8gIFRlcm1pbmF0ZWQgRW1wbG95ZWVzIC0g aW4gdGhpcyBjb250ZXh0LCB0aG9zZSB3aG8gaGFkIGFjY2VzcwogICAgICByb3V0ZXIgY29uZmln dXJhdGlvbiB0aGF0IGluY2x1ZGVkIGtleXMgb3Iga2V5aW5nIG1hdGVyaWFsIGxpa2UKICAgICAg cHJlLXNoYXJlZCBrZXlzIHVzZWQgaW4gc2VjdXJpbmcgdGhlIHJvdXRpbmcgcHJvdG9jb2wuICBV c2luZyB0aGlzCiAgICAgIG1hdGVyaWFsLCB0aGUgYXR0YWNrZXIgY291bGQgc2VuZCBwcm9wZXJs eSBNQUMnZCBzcG9vZmVkIHBhY2tldHMKICAgICAgYXBwZWFyaW5nIHRvIGNvbWUgZnJvbSByb3V0 ZXIgQSB0byByb3V0ZXIgQiwgYW5kIHRodXMgaW1wZXJzb25hdGUKICAgICAgYW4gYXV0aG9yaXpl ZCBwZWVyLiAgVGhlIGF0dGFja2VyIGNvdWxkIHRoZW4gc2VuZCBmYWxzZSB0cmFmZmljCiAgICAg IHRoYXQgY2hhbmdlcyB0aGUgbmV0d29yayBiZWhhdmlvciBmcm9tIGl0cyBvcGVyYXRvcidzIGRl c2lnbi4gIFRoZQogICAgICBnb2FsIG9mIGFkZHJlc3NpbmcgdGhpcyBzb3VyY2Ugc3BlY2lmaWNh bGx5IGlzIHRvIGNhbGwgb3V0IHRoZQogICAgICBjYXNlIHdoZXJlIG5ldyBrZXlzIG9yIGtleWlu ZyBtYXRlcmlhbCBiZWNvbWVzIG5lY2Vzc2FyeSB2ZXJ5CiAgICAgIHF1aWNrbHksIHdpdGggbGl0 dGxlIG9wZXJhdGlvbmFsIGV4cGVuc2UsIHVwb24gdGhlIHRlcm1pbmF0aW9uIG9mCiAgICAgIHN1 Y2ggYW4gZW1wbG95ZWUuICBUaGlzIGdyb3VwaW5nIGNvdWxkIGFsc28gcmVmZXIgdG8gYW55IGF0 dGFja2VyCiAgICAgIHdobyBzb21laG93IG1hbmFnZWQgdG8gZ2FpbiBhY2Nlc3MgdG8ga2V5aW5n IG1hdGVyaWFsLCBhbmQgc2FpZAogICAgICBhY2Nlc3MgaGFkIGJlZW4gZGV0ZWN0ZWQgYnkgdGhl IG9wZXJhdG9ycyBzdWNoIHRoYXQgdGhlIG9wZXJhdG9ycwogICAgICBoYXZlIGFuIG9wcG9ydHVu aXR5IHRvIG1vdmUgdG8gbmV3IGtleXMgaW4gb3JkZXIgdG8gcHJldmVudCBhbgoKCgpMZWJvdml0 eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBb UGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgogICAgICBhdHRhY2suCgogICBUaGVzZSBBVFRB Q0sgQUNUSU9OUyBhcmUgaW4gc2NvcGUgZm9yIHRoaXMgcm9hZG1hcDoKCiAgIG8gIFNQT09GSU5H IC0gd2hlbiBhbiB1bmF1dGhvcml6ZWQgZGV2aWNlIGFzc3VtZXMgdGhlIGlkZW50aXR5IG9mIGFu CiAgICAgIGF1dGhvcml6ZWQgb25lLiAgU3Bvb2ZpbmcgY2FuIGJlIHVzZWQsIGZvciBleGFtcGxl LCB0byBpbmplY3QKICAgICAgbWFsaWNpb3VzIHJvdXRpbmcgaW5mb3JtYXRpb24gdGhhdCBjYXVz ZXMgdGhlIGRpc3J1cHRpb24gb2YKICAgICAgbmV0d29yayBzZXJ2aWNlcy4gIFNwb29maW5nIGNh biBhbHNvIGJlIHVzZWQgdG8gY2F1c2UgYSBuZWlnaGJvcgogICAgICByZWxhdGlvbnNoaXAgdG8g Zm9ybSB0aGF0IHN1YnNlcXVlbnRseSBkZW5pZXMgdGhlIGZvcm1hdGlvbiBvZiB0aGUKICAgICAg cmVsYXRpb25zaGlwIHdpdGggdGhlIGxlZ2l0aW1hdGUgcm91dGVyLgoKICAgbyAgRkFMU0lGSUNB VElPTiAtIGFuIGFjdGlvbiB3aGVyZWJ5IGFuIGF0dGFja2VyIHNlbmRzIGZhbHNlIHJvdXRpbmcK ICAgICAgaW5mb3JtYXRpb24uICBUbyBmYWxzaWZ5IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLCBh biBhdHRhY2tlciBoYXMKICAgICAgdG8gYmUgZWl0aGVyIHRoZSBvcmlnaW5hdG9yIG9yIGEgZm9y d2FyZGVyIG9mIHRoZSByb3V0aW5nCiAgICAgIGluZm9ybWF0aW9uLiAgRmFsc2lmaWNhdGlvbiBt YXkgb2NjdXIgYnkgYW4gT1JJR0lOQVRPUiwgb3IgYQogICAgICBGT1JXQVJERVIsIGFuZCBtYXkg aW52b2x2ZSBPVkVSQ0xBSU1JTkcsIE1JU0NMQUlNSU5HLCBvcgogICAgICBNSVNUQVRFTUVOVCBv ZiBuZXR3b3JrIHJlc291cmNlIHJlYWNoYWJpbGl0eS4gIFdlIG11c3QgYmUgY2FyZWZ1bAogICAg ICB0byByZW1lbWJlciB0aGF0IGluIHRoaXMgd29yayB3ZSBhcmUgb25seSB0YXJnZXRpbmcgZmFs c2lmaWNhdGlvbgogICAgICBmcm9tIG91dHNpZGVycyBhcyBtYXkgb2NjdXIgZnJvbSB0YW1wZXJp bmcgd2l0aCBwYWNrZXRzIGluIGZsaWdodC4KICAgICAgRmFsc2lmaWNhdGlvbiBmcm9tIEJZWkFO VElORVMgKHNlZSB0aGUgVGhyZWF0cyBPdXQgb2YgU2NvcGUKICAgICAgc2VjdGlvbiAoU2VjdGlv biAyLjIpIGJlbG93KSBhcmUgbm90IGFkZHJlc3NlZCBieSB0aGUgS0FSUCBlZmZvcnQuCgogICBv ICBJTlRFUkZFUkVOQ0UgLSB3aGVuIGFuIGF0dGFja2VyIGluaGliaXRzIHRoZSBleGNoYW5nZXMg YnkKICAgICAgbGVnaXRpbWF0ZSByb3V0ZXJzLiAgVGhlIHR5cGVzIG9mIGludGVyZmVyZW5jZSBh ZGRyZXNzZWQgYnkgdGhpcwogICAgICB3b3JrIGluY2x1ZGU6CiAgICAgICogIEFERElORyBOT0lT RQogICAgICAqICBSRVBMQVlJTkcgT1VULURBVEVEIFBBQ0tFVFMKICAgICAgKiAgSU5TRVJUSU5H IE1FU1NBR0VTCiAgICAgICogIENPUlJVUFRJTkcgTUVTU0FHRVMKICAgICAgKiAgQlJFQUtJTkcg U1lOQ0hST05JWkFUSU9OCiAgICAgICogIENoYW5naW5nIG1lc3NhZ2UgY29udGVudAoKICAgbyAg RG9TIGF0dGFja3Mgb24gdHJhbnNwb3J0IHN1Yi1zeXN0ZW1zIC0gVGhpcyBpbmNsdWRlcyBhbnkg b3RoZXIgRG9TCiAgICAgIGF0dGFja3Mgc3BlY2lmaWNhbGx5IGJhc2VkIG9uIHRoZSBhYm92ZSBh dHRhY2sgdHlwZXMuICBUaGlzIGlzCiAgICAgIHdoZW4gYW4gYXR0YWNrZXIgc2VuZHMgc3Bvb2Zl ZCBwYWNrZXRzIGFpbWVkIGF0IGhhbHRpbmcgb3IKICAgICAgcHJldmVudGluZyB0aGUgdW5kZXJs eWluZyBwcm90b2NvbCBvdmVyIHdoaWNoIHRoZSByb3V0aW5nIHByb3RvY29sCiAgICAgIHJ1bnMs IGZvciBleGFtcGxlIGhhbHRpbmcgYSBCR1Agc2Vzc2lvbiBieSBzZW5kaW5nIGEgVENQIEZJTiBv cgogICAgICBSU1QgcGFja2V0LiAgU2luY2UgdGhpcyBhdHRhY2sgZGVwZW5kcyBvbiBzcG9vZmlu Zywgb3BlcmF0b3JzIGFyZQogICAgICBlbmNvdXJhZ2VkIHRvIGRlcGxveQoKICAgbyAgRG9TIGF0 dGFja3MgdXNpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSAtIFRoaXMgaW5jbHVkZXMg YW4KICAgICAgYXR0YWNrZXIgc2VuZGluZyBwYWNrZXRzIHdoaWNoIGNvbmZ1c2Ugb3Igb3Zlcndo ZWxtIGEgc2VjdXJpdHkKICAgICAgbWVjaGFuaXNtIGl0c2VsZi4gIEFuIGV4YW1wbGUgaXMgaW5p dGlhdGluZyBhbiBvdmVyd2hlbG1pbmcgbG9hZAogICAgICBvZiBzcG9vZmVkIGF1dGhlbnRpY2F0 ZWQgcm91dGUgbWVzc2FnZXMgc28gdGhhdCB0aGUgcmVjZWl2ZXIgbmVlZHMKICAgICAgdG8gcHJv Y2VzcyB0aGUgTUFDIGNoZWNrLCBvbmx5IHRvIGRpc2NhcmQgdGhlIHBhY2tldCwgc2VuZGluZyBD UFUKICAgICAgbGV2ZWxzIHJpc2luZy4gIEFub3RoZXIgZXhhbXBsZSBpcyB3aGVuIGFuIGF0dGFj a2VyIHNlbmRzIGFuCiAgICAgIG92ZXJ3aGVsbWluZyBsb2FkIG9mIGtleWluZyBwcm90b2NvbCBp bml0aWF0aW9ucyBmcm9tIGJvZ3VzCiAgICAgIHNvdXJjZXMuICBBbGwgb3RoZXIgcG9zc2libGUg RG9TIGF0dGFja3MgYXJlIG91dCBvZiBzY29wZSAoc2VlCgoKCkxlYm92aXR6ICYgICAgICAgICAg ICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAwOQoKCiAgICAgIG5leHQgc2VjdGlvbikuCgogICBvICBCcnV0ZSBGb2NlIEF0 dGFja3MgQWdhaW5zdCBQYXNzd29yZC9LZXlzIC0gVGhpcyBpbmNsdWRlcyBlaXRoZXIKICAgICAg b25saW5lIG9yIG9mZmxpbmUgYXR0YWNrcyB3aGVyZSBhdHRlbXB0cyBhcmUgbWFkZSByZXBlYXRl ZGx5IHVzaW5nCiAgICAgIGRpZmZlcmVudCBrZXlzL3Bhc3N3b3JkcyB1bnRpbCBhIG1hdGNoIGlz IGZvdW5kLiAgV2hpbGUgaXQgaXMKICAgICAgaW1wb3NzaWJsZSB0byBtYWtlIGJydXRlIGZvcmNl IGF0dGFja3Mgb24ga2V5cyBjb21wbGV0ZWx5CiAgICAgIHVuc3VjY2Vzc2Z1bCwgcHJvcGVyIGRl c2lnbiBjYW4gbWFrZSBzdWNoIGF0dGFja3MgbXVjaCBoYXJkZXIgdG8KICAgICAgc3VjY2VlZC4g IEZvciBleG1hcGxlLCB0aGUga2V5IGxlbmd0aCBzaG91bGQgYmUgc3VmZmljaWVudGx5IGxvbmcK ICAgICAgc28gdGhhdCBjb3ZlcmluZyB0aGUgZW50aXJlIHNwYWNlIG9mIHBvc3NpYmxlIGtleXMg aXMgaW1wcm9iYWJsZQogICAgICB1c2luZyBjb21wdXRhdGlvbmFsIHBvd2VyIGV4cGVjdGVkIHRv IGJlIGF2YWlsYWJsZSAxMCB5ZWFycyBvdXQgb3IKICAgICAgbW9yZS4gIEFsc28sIGZyZXF1ZW50 bHkgY2hhbmdpbmcgdGhlIGtleXMgbWF5IHJlbmRlciB1c2VsZXNzIGEKICAgICAgc3VjY2Vzc2Z1 bCBndWVzcyBzb21lIHRpbWUgaW4gdGhlIGZ1dHVyZSwgYXMgdGhvc2Uga2V5cyBtYXkgbm8KICAg ICAgbG9uZ2VyIGJlIGluIHVzZS4KCjIuMi4gIFRocmVhdHMgT3V0IG9mIFNjb3BlCgogICBUaHJl YXRzIGZyb20gQllaQU5USU5FIHNvdXJjZXMgLS0gZmF1bHR5LCBtaXNjb25maWd1cmVkLCBvciBz dWJ2ZXJ0ZWQKICAgcm91dGVycywgaS5lLiwgbGVnaXRpbWF0ZSBwYXJ0aWNpcGFudHMgaW4gdGhl IHJvdXRpbmcgcHJvdG9jb2wgLS0gYXJlCiAgIG91dCBvZiBzY29wZSBmb3IgdGhpcyByb2FkbWFw LiAgQW55IG9mIHRoZSBhdHRhY2tzIGRlc2NyaWJlZCBpbiB0aGUKICAgYWJvdmUgc2VjdGlvbiAo U2VjdGlvbiAyLjEpIHRoYXQgbWF5IGJlIGxldmllZCBieSBhIEJZWkFOVElORSBzb3VyY2UKICAg YXJlIHRoZXJlZm9yZSBhbHNvIG91dCBvZiBzY29wZS4KCiAgIEluIGFkZGl0aW9uLCB0aGVzZSBv dGhlciBhdHRhY2sgYWN0aW9ucyBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzCiAgIHdvcms6Cgog ICBvICBTTklGRklORyAtIHBhc3NpdmUgb2JzZXJ2YXRpb24gb2Ygcm91dGUgbWVzc2FnZSBjb250 ZW50cyBpbiBmbGlnaHQKICAgbyAgRkFMU0lGSUNBVElPTiBieSBCWVpBTlRJTkUgc291cmNlcyAt IHVuYXV0aG9yaXplZCBtZXNzYWdlIGNvbnRlbnQKICAgICAgYnkgYSBsZWdpdGltYXRlIGF1dGhv cml6ZWQgc291cmNlLgogICBvICBJTlRFUkZFUkVOQ0UgZHVlIHRvOgogICAgICAqICBOT1QgRk9S V0FSRElORyBQQUNLRVRTIC0gY2Fubm90IGJlIHByZXZlbnRlZCB3aXRoIGNyeXB0b2dyYXBoaWMK ICAgICAgICAgYXV0aGVudGljYXRpb24KICAgICAgKiAgREVMQVlJTkcgTUVTU0FHRVMgLSBjYW5u b3QgYmUgcHJldmVudGVkIHdpdGggY3J5cHRvZ3JhcGhpYwogICAgICAgICBhdXRoZW50aWNhdGlv bgogICAgICAqICBERU5JQUwgT0YgUkVDRUlQVCAtIGNhbm5vdCBiZSBwcmV2ZW50ZWQgd2l0aCBj cnlwdG9ncmFwaGljCiAgICAgICAgIGF1dGhlbnRpY2F0aW9uCiAgICAgICogIFVOQVVUSE9SSVpF RCBNRVNTQUdFIENPTlRFTlQgLSB0aGUgd29yayBvZiB0aGUgSUVURidzIFNJRFIKICAgICAgICAg d29ya2luZyBncm91cAogICAgICAgICAoaHR0cDovL3d3dy5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJz L3NpZHItY2hhcnRlci5odG1sKS4KICAgICAgKiAgQW55IG90aGVyIHR5cGUgb2YgRG9TIGF0dGFj ay4gIEZvciBleGFtcGxlLCBhIGZsb29kIG9mIHRyYWZmaWMKICAgICAgICAgdGhhdCBmaWxscyB0 aGUgbGluayBhaGVhZCBvZiB0aGUgcm91dGVyLCBzbyB0aGF0IHRoZSByb3V0ZXIgaXMKICAgICAg ICAgcmVuZGVyZWQgdW51c2FibGUgYW5kIHVucmVhY2hhYmxlIGJ5IHZhbGlkIHBhY2tldHMgaXMg Tk9UIGFuCiAgICAgICAgIGF0dGFjayB0aGF0IHRoaXMgd29yayB3aWxsIGFkZHJlc3MuICBNYW55 IG90aGVyIHN1Y2ggZXhhbXBsZXMKICAgICAgICAgY291bGQgYmUgY29udHJpdmVkLgoKCgoKCgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDE1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9h ZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCjMuICBDYXRlZ29yaXppbmcgUm91 dGluZyBQcm90b2NvbHMKCiAgIEZvciB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3VyaXR5IHJvYWRt YXAgZGVmaW5pdGlvbiwgd2Ugd2lsbAogICBjYXRlZ29yaXplIHRoZSByb3V0aW5nIHByb3RvY29s cyBpbnRvIGdyb3VwcyBhbmQgaGF2ZSBkZXNpZ24gdGVhbXMKICAgZm9jdXMgb24gdGhlIHNwZWNp ZmljYXRpb24gd29yayB3aXRoaW4gdGhvc2UgZ3JvdXBpbmdzLiAgSXQgaXMKICAgYmVsaWV2ZWQg dGhhdCB0aGUgZ3JvdXBpbmdzIHdpbGwgaGF2ZSBsaWtlIHJlcXVpcmVtZW50cyBmb3IgdGhlaXIK ICAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcywgYW5kIHRoYXQgcmV1c2Ugb2YgYXV0aGVudGlj YXRpb24KICAgbWVjaGFuaXNtcyB3aWxsIGJlIGdyZWF0ZXN0IHdpdGhpbiB0aGVzZSBncm91cGlu Zy4gIFRoZSB3b3JrIGl0ZW1zCiAgIHBsYWNlZCBvbiB0aGUgcm9hZG1hcCB3aWxsIGJlIGRlZmlu ZWQgYW5kIGFzc2lnbmVkIGJhc2VkIG9uIHRoZXNlCiAgIGNhdGVnb3JpemF0aW9ucy4gIEl0IGlz IGFsc28gaG9wZWQgdGhhdCwgZG93biB0aGUgcm9hZCBpbiB0aGUgUGhhc2UgMgogICB3b3JrLCB3 ZSBjYW4gY3JlYXRlIG9uZSBLTVAgcGVyIGNhdGVnb3J5IChpZiBub3QgZm9yIHNldmVyYWwKICAg Y2F0ZWdvcmllcykgc28gdGhhdCB0aGUgd29yayBjYW4gYmUgZWFzaWx5IGxldmVyYWdlZCBieSB0 aGUgdmFyaW91cwogICBSb3V0aW5nIFByb3RvY29sIHRlYW1zLiAgS01QcyBhcmUgdXNlZnVsIGZv ciBhbGxvd2luZyBzaW1wbGUsCiAgIGF1dG9tYXRlZCB1cGRhdGVzIG9mIHRoZSB0cmFmZmljIGtl eXMgdXNlZCBpbiBhIGJhc2UgcHJvdG9jb2wuICBLTVBzCiAgIHJlcGxhY2UgdGhlIG5lZWQgZm9y IGh1bWFucywgb3IgT1NTIHJvdXRpbmVzLCB0byBwZXJpb2RpY2FsbHkgcmVwbGFjZQogICBrZXlz IG9uIHJ1bm5pbmcgc3lzdGVtcy4gIEl0IGFsc28gcmVtb3ZlcyB0aGUgbmVlZCBmb3IgYSBjaGFp biBvZgogICBtYW51YWwga2V5cyB0byBiZSBjaG9zZW4gb3IgY29uZmlndXJlZC4gIFdoZW4gY29u ZmlndXJlZCBwcm9wZXJseSwgYQogICBLTVAgd2lsbCBlbmZvcmNlIHRoZSBrZXkgZnJlc2huZXNz IHBvbGljeSBvZiB0d28gcGVlcnMgYnkga2VlcGluZwogICB0cmFjayBvZiB0aGUga2V5IGxpZmV0 aW1lIGFuZCBuZWdvdGlhdGluZyBhIG5ldyBrZXkgYXQgdGhlIGRlZmluZWQKICAgaW50ZXJ2YWwu CgozLjEuICBDYXRlZ29yeTogTWVzc2FnaW5nIFRyYW5zYWN0aW9uIFR5cGUKCiAgIFRoZSBmaXJz dCBjYXRlZ29yaXphdGlvbiBkZWZpbmVzIGZvdXIgdHlwZXMgb2YgbWVzc2FnaW5nIHRyYW5zYWN0 aW9ucwogICB1c2VkIG9uIHRoZSB3aXJlIGJ5IHRoZSBiYXNlIFJvdXRpbmcgUHJvdG9jb2wuICBU aGV5IGFyZToKCgogICBPbmUtdG8tT25lICAgICBPbmUgcGVlciByb3V0ZXIgZGlyZWN0bHkgYW5k IGludGVudGlvbmFsbHkgZGVsaXZlcnMgYQogICAgICAgICAgICAgICAgICByb3V0ZSB1cGRhdGUg c3BlY2lmaWNhbGx5IHRvIG9uZSBvdGhlciBwZWVyIHJvdXRlci4KICAgICAgICAgICAgICAgICAg RXhhbXBsZXMgYXJlIEJHUCBhbmQgTERQLiAgUG9pbnQtdG8tcG9pbnQgbW9kZXMgb2YKICAgICAg ICAgICAgICAgICAgYm90aCBJUy1JUyBhbmQgT1NQRiwgd2hlbiBzZW50IG92ZXIgYm90aCB0cmFk aXRpb25hbAogICAgICAgICAgICAgICAgICBwb2ludC10by1wb2ludCBsaW5rcyBhbmQgd2hlbiB1 c2luZyBtdWx0aS1hY2Nlc3MKICAgICAgICAgICAgICAgICAgbGF5ZXJzLCBtYXkgYm90aCBhbHNv IGZhbGwgaW50byB0aGlzIGNhdGVnb3J5LgogICAgICAgICAgICAgICAgICBbcXVlc3Rpb24gdG8g cmV2aWV3ZXJzOiBTaG91bGQgd2UgbGlzdCBhbGwgcHJvdG9jb2xzCiAgICAgICAgICAgICAgICAg IGludG8gdGhlc2UgY2F0ZWdvcmllcyByaWdodCBoZXJlLCBvciBqdXN0IGdpdmUgYSBmZXcKICAg ICAgICAgICAgICAgICAgZXhhbXBsZXM/XQoKICAgT25lLXRvLU1hbnkgICAgQSByb3V0ZXIgcGVl cnMgd2l0aCBtdWx0aXBsZSBvdGhlciByb3V0ZXJzIG9uIGEgc2luZ2xlCiAgICAgICAgICAgICAg ICAgIG5ldHdvcmsgc2VnbWVudCAtLSBpLmUuIG9uIGxpbmsgbG9jYWwgLS0gc3VjaCB0aGF0IGl0 CiAgICAgICAgICAgICAgICAgIGNyZWF0ZXMgYW5kIHNlbmRzIG9uZSByb3V0ZSB1cGRhdGUgbWVz c2FnZSB3aGljaCBpcwogICAgICAgICAgICAgICAgICBpbnRlbmRlZCBmb3IgY29uc3VtcHRpb24g YnkgbXVsdGlwbGUgcGVlcnMuICBFeGFtcGxlcwogICAgICAgICAgICAgICAgICB3b3VsZCBiZSBP U1BGIGFuZCBJUy1JUyBpbiB0aGVpciBicm9hZGNhc3QsIG5vbi1wb2ludC0KICAgICAgICAgICAg ICAgICAgdG8tcG9pbnQgbW9kZXMuCgoKCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJl ciAyMDA5CgoKICAgQ2xpZW50LVNlcnZlciAgQSBjbGllbnQtc2VydmVyIHJvdXRpbmcgcHJvdG9j b2wgaXMgb25lIHdoZXJlIG9uZQogICAgICAgICAgICAgICAgICByb3V0ZXIgaW5pdGlhdGVzIGEg cmVxdWVzdCBmb3Igcm91dGUgaW5mb3JtYXRpb24gZnJvbQogICAgICAgICAgICAgICAgICBhbm90 aGVyIHJvdXRlciwgd2hvIHRoZW4gZm9ybXVsYXRlcyBhIHJlc3BvbnNlIHRvIHRoYXQKICAgICAg ICAgICAgICAgICAgcmVxdWVzdCwgYW5kIHJlcGxpZXMgd2l0aCB0aGUgcmVxdWVzdGVkIGRhdGEu CiAgICAgICAgICAgICAgICAgIEV4YW1wbGVzIGFyZSBhIEJHUCBSb3V0ZSBSZWZsZWN0b3IgYW5k IFs/Pz8/ICBBcmUKICAgICAgICAgICAgICAgICAgdGhlcmUgb3RoZXIgZXhhbXBsZXM/ICBJcyB0 aGlzIHRoZSByaWdodCBleGFtcGxlPyAgRG8KICAgICAgICAgICAgICAgICAgZGlzY292ZXJ5IHBy b3RvY29scyBmYWxsIHVuZGVyIHRoaXMgY2F0ZWdvcnk/XS4KCiAgIE11bHRpY2FzdCAgICAgIE11 bHRpY2FzdCBwcm90b2NvbHMgaGF2ZSB1bmlxdWUgc2VjdXJpdHkgcHJvcGVydGllcwogICAgICAg ICAgICAgICAgICBiZWNhdXNlIG9mIHRoZSBmYWN0IHRoYXQgdGhleSBhcmUgaW5oZXJlbnRseSBn cm91cC0KICAgICAgICAgICAgICAgICAgYmFzZWQgcHJvdG9jb2xzIGFuZCB0aHVzIGhhdmUgZ3Jv dXAga2V5aW5nCiAgICAgICAgICAgICAgICAgIHJlcXVpcmVtZW50cyBhdCB0aGUgcm91dGluZyBs ZXZlbCB3aGVyZSBsaW5rLWxvY2FsCiAgICAgICAgICAgICAgICAgIHJvdXRpbmcgbWVzc2FnZXMg YXJlIG11bHRpY2FzdGVkLiAgQWxzbywgYXQgbGVhc3QgaW4KICAgICAgICAgICAgICAgICAgdGhl IGNhc2Ugb2YgUElNLVNNLCBzb21lIG1lc3NhZ2VzIGFyZSBhcmUgc2VudCB1bmljYXN0CiAgICAg ICAgICAgICAgICAgIHRvIGEgZ2l2ZW4gcGVlcihzKSwgYXMgaXMgdGhlIGNhc2Ugd2l0aCByb3V0 ZXItY2xvc2UtCiAgICAgICAgICAgICAgICAgIHRvLXNlbmRlciBhbmQgdGhlICJSZW5kZXp2b3Vz IFBvaW50Ii4gIFNvbWUgd29yayBmb3IKICAgICAgICAgICAgICAgICAgYXBwbGljYXRpb24gbGF5 ZXIgbWVzc2FnZSBzZWN1cml0eSBoYXMgYmVlbiBkb25lIGluCiAgICAgICAgICAgICAgICAgIHRo ZSBNdWx0aWNhc3QgU2VjdXJpdHkgd29ya2luZyBncm91cCAoTVNFQywKICAgICAgICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL21zZWMtY2hhcnRlci5odG1sKQog ICAgICAgICAgICAgICAgICBhbmQgbWF5IGJlIGhlbHBmdWwgdG8gcmV2aWV3LCBidXQgaXMgbm90 IGRpcmVjdGx5CiAgICAgICAgICAgICAgICAgIGFwcGxpY2FibGUuCgogICBbYXV0aG9yJ3Mgbm90 ZTogSSB0aGluayB0aGUgYWJvdmUgZGVmaW5pdGlvbnMgbmVlZCBjbGVhbiB1cC4gIFJvdXRpbmcK ICAgYXJlYSBmb2xrcywgZXNwZWNpYWxseSBBRHMsIFBMRUFTRSBzdWdnZXN0IG5ldyB0ZXh0Ll0K CjMuMi4gIENhdGVnb3J5OiBQZWVyIHZzLiBHcm91cCBLZXlpbmcKCiAgIFRoZSBzZWNvbmQgYXhp cyBvZiBjYXRlZ29yaXphdGlvbiBncm91cHMgcHJvdG9jb2xzIGJ5IHRoZSBrZXlpbmcKICAgbWVj aGFuaXNtIHRoYXQgd2lsbCBiZSBuZWNlc3NhcnkgZm9yIGRpc3RyaWJ1dGluZyBzZXNzaW9uIGtl eXMgdG8gdGhlCiAgIGFjdHVhbCBSb3V0aW5nIFByb3RvY29sIHRyYW5zcG9ydHMuICBUaGV5IGFy ZToKCgogICBQZWVyIGtleWluZyAgICBPbmUgcm91dGVyIHNlbmRzIHRoZSBrZXlpbmcgbWVzc2Fn ZXMgZGlyZWN0bHkgYW5kIG9ubHkKICAgICAgICAgICAgICAgICAgdG8gb25lIG90aGVyIHJvdXRl ciwgc3VjaCB0aGF0IGEgb25lLXRvLW9uZSwgdW5pcXVlCiAgICAgICAgICAgICAgICAgIGtleWlu ZyBzZWN1cml0eSBhc3NvY2lhdGlvbiAoU0EpIGlzIGVzdGFibGlzaGVkCiAgICAgICAgICAgICAg ICAgIGJldHdlZW4gdGhlIHR3byByb3V0ZXJzCgogICBHcm91cCBLZXlpbmcgICBPbmUgcm91dGVy IGNyZWF0ZXMgYW5kIGRpc3RyaWJ1dGVzIGEgc2luZ2xlIGtleWluZwogICAgICAgICAgICAgICAg ICBtZXNzYWdlIHRvIG11bHRpcGxlIHBlZXJzLiAgSW4gdGhpcyBjYXNlIGFuIGdyb3VwIFNBCiAg ICAgICAgICAgICAgICAgIHdpbGwgYmUgZXN0YWJsaXNoZWQgYW5kIHVzZWQgYmV0d2VlbiBtdWx0 aXBsZSBwZWVycwogICAgICAgICAgICAgICAgICBzaW11bHRhbmVvdXNseS4gIEdyb3VwIGtleWlu ZyBleGlzdHMgZm9yIHByb3RvY29scwogICAgICAgICAgICAgICAgICBsaWtlIE9TUEYgW1JGQzIz MjhdICwgYW5kIGFsc28gZm9yIG11bHRpY2FzdCBwcm90b2NvbHMKICAgICAgICAgICAgICAgICAg bGlrZSBQSU0tU00gW1JGQzQ2MDFdLgoKCgoKCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwOQoKCjMuMy4gIENhdGVnb3J5OiAgVXBkYXRlIHZzLiBEaXNjb3ZlcnkgUHJvdG9jb2wK CiAgIFRoZSB0aGlyZCBjYXRlZ29yeSBncm91cCBjb25zaWRlcnMgcHJvdG9jb2xzIGJ5IHRoZSBj b250ZW50cyBvZiB0aGUKICAgbWVzc2FnZXMgYmVpbmcgZXhjaGFuZ2VkIGluIHRoZSBSb3V0aW5n IFByb3RvY29sLiAgVGhleSBhcmU6CgoKICAgVXBkYXRlcyAgICAgICAgTWVzc2FnZXMgdGhhdCBj YXJyeSByb3V0ZSBhZHZlcnRpc2VtZW50cyBvciB1cGRhdGUKICAgICAgICAgICAgICAgICAgaW5m b3JtYXRpb24gZnJvbSBwZWVyIHRvIHBlZXIKCiAgIERpc2NvdmVyeSAgICAgIE1lc3NhZ2VzIHNl bnQgYXMgcGFydCBvZiBhIHBvbGljeSwgcGVlciwgb3Igc2VydmljZQogICAgICAgICAgICAgICAg ICBkaXNjb3ZlcnkgcHJvY2Vzcy4gIFRoZXNlIG1lc3NhZ2VzIGFyZSBub3JtYWxseQogICAgICAg ICAgICAgICAgICBleGNoYW5nZWQgcHJpb3IgdG8gYW55IGFkamFjZW5jeSBiZWluZyBmb3JtZWQs IGFuZAogICAgICAgICAgICAgICAgICBiZWZvcmUgYW55IHVwZGF0ZXMgYXJlIHNlbnQuICBGb3Ig ZXhhbXBsZSwgZW5kLXBvaW50CiAgICAgICAgICAgICAgICAgIGRpc2NvdmVyeSBtZWNoYW5pc21z IGFyZSBjb21tb24gaW4gTDJWUE4gYW5kIEwzVlBOCiAgICAgICAgICAgICAgICAgIHNvbHV0aW9u cy4KCiAgIFtRVUVTVElPTiBUTyBSRVZJRVdFUlM6IGlzIHRoaXMgcmVhbGx5IGp1c3Qgd2hhdCdz IGRlc2NyaWJlZCBpbiAzLjEKICAgYXMgIkNsaWVudC1TZXJ2ZXIiIGFuZC9vciAiT25lLXRvLU9u ZSI/ICBJcyB0aGVyZSByZWFsbHkgc3VjaCBhCiAgIGRpZmZlcmVudCBpbiBkaXNjb3ZlcnkgcHJv dG9jb2xzIHRoYXQgdGhleSBuZWVkIHRoZWlyIG93biBjYXRlZ29yeSB0bwogICBmaWd1cmUgb3V0 IGhvdyB0byBhdXRoZW50aWNhdGUgdGhlbT8gIENhbiBzb21lb25lIHByb3ZpZGUgYSBmZXcKICAg ZXhhbXBsZXM/CgozLjQuICBTZWN1cml0eSBDaGFyYWN0ZXJpemF0aW9uIFZlY3RvcnMKCiAgIEEg ZmV3IG1vcmUgY29uc2lkZXJhdGlvbnMgbXVzdCBiZSBtYWRlIGFib3V0IHRoZSBwcm90b2NvbCBh bmQgaXRzIHVzZQogICB3aGVuIGluaXRpYWxseSBjYXRlZ29yaXppbmcgdGhlIHByb3RvY29sIGFu ZCBzY29waW5nIHRoZQogICBhdXRoZW50aWNhdGlvbiB3b3JrLgoKMy40LjEuICBJbnRlcm5hbCB2 cy4gRXh0ZXJuYWwgT3BlcmF0aW9uCgogICBUaGUgZGVzaWduZXJzIG11c3QgY29uc2lkZXIgd2hl dGhlciB0aGUgcHJvdG9jb2wgaXMgYW4gaW50ZXJuYWwKICAgcm91dGluZyBwcm90b2NvbCBvciBh biBleHRlcm5hbCBvbmUsIGkuZS4gIERvZXMgaXQgcHJpbWFyaWx5IHJ1bgogICBiZXR3ZWVuIHBl ZXJzIHdpdGhpbiBhIHNpbmdsZSBkb21haW4gb2YgY29udHJvbCBvciBiZXR3ZWVuIHR3bwogICBk aWZmZXJlbnQgZG9tYWlucyBvZiBjb250cm9sPyAgU29tZSBwcm90b2NvbHMgbWF5IGJlIHVzZWQg aW4gYm90aAogICBjYXNlcywgaW50ZXJuYWxseSBhbmQgZXh0ZXJuYWxseSwgYW5kIGFzIHN1Y2gg dmFyaW91cyBtb2RlcyBvZgogICBhdXRoZW50aWNhdGlvbiBvcGVyYXRpb24gbWF5IGJlIHJlcXVp cmVkIGZvciB0aGUgc2FtZSBwcm90b2NvbC4KICAgV2hpbGUgaXQgaXMgcHJlZmVycmVkIHRoYXQg YWxsIHJvdXRpbmcgZXhjaGFuZ2VzIHJ1biB3aXRoIHRoZSB1dG1vc3QKICAgc2VjdXJpdHkgbWVj aGFuaXNtcyBlbmFibGVkIGluIGFsbCBkZXBsb3ltZW50cywgdGhpcyBleGhvcnRhdGlvbiBpcwog ICBncmVhdGVyIGZvciB0aG9zZSBwcm90b2NvbHMgcnVubmluZyBvbiBpbnRlci1kb21haW4gcG9p bnQtdG8tcG9pbnQKICAgbGlua3MsIGFuZCBncmVhdGVzdCBmb3IgdGhvc2Ugb24gc2hhcmVkIGFj Y2VzcyBsaW5rIGxheWVycyB3aXRoCiAgIHNldmVyYWwgZGlmZmVyZW50IGRvbWFpbnMgaW50ZXJj aGFuZ2luZyB0b2dldGhlciwgYmVjYXVzZSB0aGUgdm9sdW1lCiAgIG9mIGF0dGFja2VycyBhcmUg Z3JlYXRlciBmcm9tIHRoZSBvdXRzaWRlLiAgTm90ZSBob3dldmVyIHRoYXQgdGhlCiAgIGNvbnNl cXVlbmNlcyBvZiBpbnRlcm5hbCBhdHRhY2tzIG1heWJlIG5vIGxlc3Mgc2V2ZXJlIC0tIGluIGZh Y3QgdGhleQogICBtYXkgYmUgcXVpdGUgYSBiaXQgbW9yZSBzZXZlcmUgLS0gdGhhbiBhbiBleHRl cm5hbCBhdHRhY2suICBBbgogICBleGFtcGxlIG9mIHRoaXMgaW50ZXJuYWwgdmVyc3VzIGV4dGVy bmFsIGNvbnNpZGVyYXRpb24gaXMgQkdQIHdoaWNoCiAgIGhhcyBib3RoIEVCR1AgYW5kIElCR1Ag bW9kZXMuICBBbm90aGVyIGV4YW1wbGUgaXMgYSBtdWx0aWNhc3QKICAgcHJvdG9jb2wgd2hlcmUg dGhlIG5laWdoYm9ycyBhcmUgc29tZXRpbWVzIHdpdGhpbiBhIGRvbWFpbiBvZiBjb250cm9sCiAg IGFuZCBzb21ldGltZXMgYXQgYW4gaW50ZXItZG9tYWluIGV4Y2hhbmdlIHBvaW50LiAgSW4gdGhl IGNhc2Ugb2YKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAx MCAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgUElNLVNN IHJ1bm5pbmcgb24gYW4gaW50ZXJuYWwgbXVsdGktYWNjZXNzIGxpbmssIEl0IHdvdWxkIGJlCiAg IGFjY2VwdGFibGUgdG8gZ2l2ZSB1cCBzb21lIHNlY3VyaXR5IHRvIGdldCBzb21lIGNvbnZlbmll bmNlIGJ5IHVzaW5nCiAgIGEgZ3JvdXAga2V5IGJldHdlZW4gdGhlIHBlZXJzIG9uIHRoZSBsaW5r LiAgT24gdGhlIG90aGVyIGhhbmQsIGluIHRoZQogICBjYXNlIG9mIFBJTS1TTSBydW5uaW5nIG92 ZXIgYSBtdWx0aS1hY2Nlc3MgbGluayBhdCBhIHB1YmxpYyBleGNoYW5nZQogICBwb2ludCwgb3Bl cmF0b3JzIG1heSBmYXZvciBzZWN1cml0eSBvdmVyIGNvbnZlbmllbmNlIGJ5IHVzaW5nIHVuaXF1 ZQogICBwYWlyLXdpc2Uga2V5cyBmb3IgZXZlcnkgcGVlci4gIERlc2lnbmVycyBtdXN0IGNvbnNp ZGVyIGJvdGggbW9kZXMgb2YKICAgb3BlcmF0aW9uIGFuZCBlbnN1cmUgdGhlIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMgZml0IGJvdGguCgogICBPcGVyYXRvcnMgYXJlIGVuY291cmFnZWQgdG8g cnVuIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24gb24gYWxsCiAgIHRoZWlyIGFkamFjZW5j aWVzLCBidXQgdG8gd29yayBmcm9tIHRoZSBvdXRzaWRlIGluLCBpLmUuICBUaGUgRUJHUAogICBs aW5rcyBhcmUgYSBoaWdoZXIgcHJpb3JpdHkgdGhhbiB0aGUgSUJHUCBsaW5rcyBiZWNhdXNlIHRo ZXkgYXJlCiAgIGV4dGVybmFsbHkgZmFjaW5nLCBhbmQsIGFzIGEgcmVzdWx0LCBtb3JlIGxpa2Vs eSB0byBiZSB0YXJnZXRlZCBpbiBhbgogICBhdHRhY2suCgozLjQuMi4gIFVuaXF1ZSB2ZXJzdXMg U2hhcmVkIEtleXMKCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgcmVnYXJkaW5nIHdoZW4gaXQgaXMKICAgYXBwcm9wcmlhdGUgdG8gdXNlIHRoZSBzYW1l IGF1dGhlbnRpY2F0aW9uIGtleSBpbnB1dHMgZm9yIG11bHRpcGxlCiAgIHBlZXJzIGFuZCB3aGVu IGl0IGlzIG5vdC4gIFRoaXMgaXMgbGFyZ2VseSBhIGRlYmF0ZSBvZiBjb252ZW5pZW5jZQogICB2 ZXJzdXMgc2VjdXJpdHkuICBJdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IHRoZSBiZXN0IHNlY3Vy ZWQKICAgbWVjaGFuaXNtIGlzIGFsc28gdGhlIGxlYXN0IGNvbnZlbmllbnQgbWVjaGFuaXNtLiAg Rm9yIGV4YW1wbGUsIGFuCiAgIGFpciBnYXAgYmV0d2VlbiBhIGhvc3QgYW5kIHRoZSBuZXR3b3Jr IGFic29sdXRlbHkgcHJldmVudHMgcmVtb3RlCiAgIGF0dGFja3Mgb24gdGhlIGhvc3QsIGJ1dCBo YXZpbmcgdG8gY29weSBhbmQgY2FycnkgZmlsZXMgdXNpbmcgdGhlCiAgICJzbmVha2VyIG5ldCIg aXMgcXVpdGUgaW5jb252ZW5pZW50IGFuZCB1bnNjYWxhYmxlLgoKICAgT3BlcmF0b3JzIGhhdmUg ZXJyZWQgb24gdGhlIHNpZGUgb2YgY29udmVuaWVuY2Ugd2hlbiBpdCBjb21lcyB0bwogICBzZWN1 cmluZyByb3V0aW5nIHByb3RvY29scyB3aXRoIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24u ICBNYW55CiAgIGRvIG5vdCB1c2UgaXQgYXQgYWxsLiAgU29tZSB1c2UgaXQgb25seSBvbiBleHRl cm5hbCBsaW5rcywgYnV0IG5vdCBvbgogICBpbnRlcm5hbCBsaW5rcy4gIFRob3NlIHRoYXQgZG8g dXNlIGl0IG9mdGVuIHVzZSB0aGUgc2FtZSBrZXkgZm9yIGFsbAogICBwZWVycyBhY3Jvc3MgdGhl aXIgZW50aXJlIG5ldHdvcmsuICBJdCBpcyBjb21tb24gdG8gc2VlIHRoZSBzYW1lIGtleQogICBp biB1c2UgZm9yIHllYXJzLCBhbmQgdGhhdCBiZWluZyB0aGUgc2FtZSBrZXkgdGhhdCB3YXMgZW50 ZXJlZCB3aGVuCiAgIGF1dGhlbnRpY2F0aW9uIHdhcyBvcmlnaW5hbGx5IGNvbmZpZ3VyZWQsIG9y IHRoZSByb3V0aW5nIGdlYXIKICAgZGVwbG95ZWQuCgogICBUaGUgZ29hbCBmb3IgZGVzaWduZXJz IGlzIHRvIGNyZWF0ZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIHRoYXQKICAgYXJlIGVhc3kg Zm9yIHRoZSBvcGVyYXRvcnMgdG8gZGVwbG95IGFuZCBtYW5hZ2UsIGFuZCBzdGlsbCB1c2UgdW5p cXVlCiAgIGtleXMgYmV0d2VlbiBwZWVycyAob3Igc21hbGwgZ3JvdXBzIG9uIG11bHRpLWFjY2Vz cyBsaW5rcyksIGFuZAogICB3aXRoaW4gYmV0d2VlbiBzZXNzaW9ucy4gIE9wZXJhdG9ycyBoYXZl IHRoZSBpbXByZXNzaW9uIHRoYXQgdGhleQogICBORUVEIG9uZSBrZXkgc2hhcmVkIGFjcm9zcyB0 aGUgbmV0d29yaywgd2hlbiBpbiBmYWN0IHRoZXkgZG8gbm90LgogICBXaGF0IHRoZXkgbmVlZCBp cyB0aGUgcmVsYXRpdmUgY29udmVuaWVuY2UgdGhleSBleHBlcmllbmNlIGZyb20KICAgZGVwbG95 aW5nIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24gd2l0aCBvbmUgKG9yIGZldykga2V5LAog ICBjb21wYXJlZCB0byB0aGUgaW5jb252ZW5pZW5jZSB0aGV5IHdvdWxkIGV4cGVyaWVuY2UgaWYg dGhleSBkZXBsb3llZAogICB0aGUgc2FtZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gdXNpbmcg dW5pcXVlIHBhaXItd2lzZSBrZXlzLiAgQW4KICAgZXhhbXBsZSBpcyBCR1AgUm91dGUgUmVmbGVj dG9ycy4gIEhlcmUgb3BlcmF0b3JzIG9mdGVuIHVzZSB0aGUgc2FtZQogICBhdXRoZW50aWNhdGlv biBrZXkgYmV0d2VlbiBlYWNoIGNsaWVudCBhbmQgdGhlIHJvdXRlIHJlZmxlY3Rvci4gIFRoZQog ICByb2FkbWFwcyBkZWZpbmVkIGZyb20gdGhpcyBndWlkYW5jZSBkb2N1bWVudCB3aWxsIGFsbG93 IGZvciB1bmlxdWUKICAga2V5cyB0byBiZSB1c2VkIGJldHdlZW4gZWFjaCBjbGllbnQgYW5kIHRo ZSBwZWVyLCB3aXRob3V0IHNhY3JpZmljaW5nCiAgIG11Y2ggY29udmVuaWVuY2UuICBEZXNpZ25l cnMgc2hvdWxkIHN0cml2ZSB0byBkZWxpdmVyIHBlZXItd2lzZQoKCgpMZWJvdml0eiAmICAgICAg ICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAxOV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMDkKCgogICB1bmlxdWUga2V5aW5nIG1lY2hhbmlzbXMgd2l0aCBzaW1p bGFyIGVhc2Utb2YtZGVwbG95bWVudCBwcm9wZXJ0aWVzCiAgIGFzIHRvZGF5J3Mgb25lLWtleSBt ZXRob2QuCgogICBPcGVyYXRvcnMgbXVzdCB1bmRlcnN0YW5kIHRoZSBjb25zZXF1ZW5jZXMgb2Yg dXNpbmcgdGhlIHNhbWUga2V5cwogICBhY3Jvc3MgbWFueSBwZWVycy4gIFVuaXF1ZSBrZXlzIGFy ZSBtb3JlIHNlY3VyZSB0aGFuIHNoYXJlZCBrZXlzCiAgIGJlY2F1c2UgdGhleSByZWR1Y2UgYm90 aCB0aGUgYXR0YWNrIHRhcmdldCBzaXplIGFuZCB0aGUgYXR0YWNrCiAgIGNvbnNlcXVlbmNlIHNp emUuICBJbiB0aGlzIGNvbnRleHQsIHRoZSBhdHRhY2sgdGFyZ2V0IHNpemUgcmVwcmVzZW50cwog ICB0aGUgbnVtYmVyIG9mIHVuaXF1ZSByb3V0aW5nIGV4Y2hhbmdlcyBhY3Jvc3MgYSBuZXR3b3Jr IHRoYXQgYW4KICAgYXR0YWNrZXIgbWF5IGJlIGFibGUgdG8gb2JzZXJ2ZSBpbiBvcmRlciB0byBn YWluIHNlY3VyaXR5IGFzc29jaWF0aW9uCiAgIGNyZWRlbnRpYWxzLCBpLmUuIGNyYWNrIHRoZSBr ZXlzLiAgSWYgYSBzaGFyZWQga2V5IGlzIHVzZWQgYWNyb3NzIHRoZQogICBlbnRpcmUgaW50ZXJu YWwgZG9tYWluIG9mIGNvbnRyb2wsIHRoZW4gdGhlIGF0dGFjayB0YXJnZXQgc2l6ZSBpcwogICB2 ZXJ5IGxhcmdlLiAgVGhlIGxhcmdlciB0aGUgYXR0YWNrIHRhcmdldCwgdGhlIGVhc2llciBpdCBp cyBmb3IgdGhlCiAgIGF0dGFja2VyIHRvIGdhaW4gYWNjZXNzIHRvIGFuYWx5c2lzIGRhdGEsIGFu ZCBncmVhdGVyIHRoZSB2b2x1bWUgb2YKICAgYW5hbHlzaXMgZGF0YSBoZSBjYW4gYWNjZXNzIGlu IGEgZ2l2ZW4gdGltZSBmcmFtZSwgYm90aCBvZiB3aGljaCBtYWtlCiAgIGhpcyBqb2IgZWFzaWVy LiAgVXNpbmcgdGhlIHNhbWUga2V5IGFjcm9zcyB0aGUgbmV0d29yayBtYWtlcyB0aGUKICAgYXR0 YWNrIHZ1bG5lcmFiaWxpdHkgc3VyZmFjZSBtb3JlIHBlbmV0cmFibGUgdGhhbiB1bmlxdWUga2V5 cy4KICAgQ29uc2lkZXIgYWxzbyB0aGUgYXR0YWNrIGNvbnNlcXVlbmNlIHNpemUsIHRoZSBhbW91 bnQgb2Ygcm91dGluZwogICBhZGphY2VuY2llcyB0aGF0IGNhbiBiZSBuZWdhdGl2ZWx5IGFmZmVj dGVkIG9uY2UgYSBicmVhY2ggaGFzCiAgIG9jY3VycmVkLCBpLmUuIG9uY2UgdGhlIGtleXMgaGF2 ZSBiZWVuIGFjcXVpcmVkIGJ5IHRoZSBhdHRhY2tlci4KICAgQWdhaW4sIGlmIGEgc2hhcmVkIGtl eSBpcyB1c2VkIGFjcm9zcyB0aGUgaW50ZXJuYWwgZG9tYWluLCB0aGVuIHRoZQogICBjb25zZXF1 ZW5jZSBzaXplIGlzIHRoZSB3aG9sZSBuZXR3b3JrLiAgSWRlYWxseSwgdW5pcXVlIGtleSBwYWly cwogICB3b3VsZCBiZSB1c2VkIGZvciBlYWNoIGFkamFjZW5jeS4KCiAgIEluIHNvbWUgY2FzZXMg ZGVzaWduZXJzIG1heSBuZWVkIHRvIHVzZSBzaGFyZWQga2V5cyBpbiBvcmRlciB0byBzb2x2ZQog ICB0aGUgZ2l2ZW4gcHJvYmxlbSBzcGFjZS4gIEZvciBleGFtcGxlLCBhIG11bHRpY2FzdCBwYWNr ZXQgaXMgc2VudAogICBvbmNlIGJ1dCB0aGVuIG9ic2VydmVkIGFuZCBjb25zdW1lZCBieSBzZXZl cmFsIHJvdXRpbmcgbmVpZ2hib3JzLiAgSWYKICAgdW5pcXVlIGtleXMgd2VyZSB1c2VkIHBlciBu ZWlnaGJvciwgdGhlIGJlbmVmaXQgb2YgbXVsdGljYXN0IHdvdWxkIGJlCiAgIGVyYXNlZCBiZWNh dXNlIHRoZSBjYXN0aW5nIHBlZXIgd291bGQgaGF2ZSB0byBjcmVhdGUgYSBkaWZmZXJlbnQKICAg YW5ub3VuY2VtZW50IHBhY2tldC9zdHJlYW0gZm9yIGVhY2ggbGlzdGVuaW5nIHBlZXIuICBUaG91 Z2ggdGhpcyBtYXkKICAgYmUgZGVzaXJlZCBhbmQgYWNjZXB0YWJsZSBpbiBzb21lIHNtYWxsIGFt b3VudCBvZiB1c2UgY2FzZXMsIGl0IGlzCiAgIG5vdCB0aGUgbm9ybS4gIFNoYXJlZCBncm91cCBr ZXlzIGFyZSBhbiBhY2NlcHRhYmxlIHNvbHV0aW9uIGhlcmUsIGFuZAogICBtdWNoIHdvcmsgaGFz IGJlZW4gZG9uZSBhbHJlYWR5IGluIHRoaXMgYXJlYSAoc2VlIE1TRUMgd29ya2luZwogICBncm91 cCkuCgozLjQuMy4gIE91dC1vZi1CYW5kIHZzLiBJbi1saW5lIEtleSBNYW5hZ2VtZW50CgogICBU aGlzIHNlY3Rpb24gZGlzY3Vzc2VzIHRoZSBzZWN1cml0eSBhbmQgdXNlIGNhc2UgY29uc2lkZXJh dGlvbnMgZm9yCiAgIGtleXMgcGxhY2VkIG9uIGRldmljZXMgdGhyb3VnaCBvdXQtb2YtYmFuZCBj b25maWd1cmF0aW9ucyB2ZXJzdXMKICAgdGhyb3VnaCBvbmUgcm91dGluZyBwZWVyLXRvLXBlZXIg a2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgZXhjaGFuZ2VzLgogICBOb3RlLCB3aGVuIHdlIHNheSBo ZXJlICJQZWVyLXRvLVBlZXIgS01QIiB3ZSBkbyBub3QgbWVhbiBpbi1iYW5kIHRvCiAgIHRoZSBS b3V0aW5nIFByb3RvY29sLiAgSW5zdGVhZCwgd2UgbWVhbiB0aGF0IHRoZSBleGNoYW5nZSBvY2N1 cnMgaW4tCiAgIGxpbmUsIG92ZXIgSVAsIGJldHdlZW4gdGhlIHR3byByb3V0aW5nIHBlZXJzIGRp cmVjdGx5LiAgSW4gaW4tbGluZQogICBLTVAgdGhlIHBlZXJzIHRoZW1zZWx2ZXMgaGFuZGxlIHRo ZSBrZXkgYW5kIHNlY3VyaXR5IGFzc29jaWF0aW9uCiAgIG5lZ290aWF0aW9uIGJldHdlZW4gdGhl bXNlbHZlcyBkaXJlY3RseSwgd2hlcmVhcyBpbiBhbiBvdXQtb2YtYmFuZAogICBzeXN0ZW0gdGhl IGtleXMgYXJlIHBsYWNlZCBvbnRvIHRoZSBkZXZpY2UgdGhyb3VnaCBzb21lIG90aGVyCiAgIGNv bmZpZ3VyYXRpb24gb3IgbWFuYWdlbWVudCBtZXRob2Qgb3IgaW50ZXJmYWNlLgoKICAgQW4gZXhh bXBsZSBvZiBhbiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gY291bGQgYmUgYW4gYWRtaW5pc3RyYXRv ciB3aG8KCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAg ICAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg S0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgbWFrZXMgYSBy ZW1vdGUgbWFuYWdlbWVudCBjb25uZWN0aW9uIChlLmcuIHVzaW5nIFNTSCkgdG8gYSByb3V0ZXIg YW5kCiAgIG1hbnVhbGx5IGVudGVycyB0aGUga2V5aW5nIGluZm9ybWF0aW9uIC0tIGxpa2UgdGhl IGFsZ29yaXRobSwgdGhlCiAgIGtleShzKSwgdGhlIGxpZmV0aW1lcywgZXRjLiAgQW5vdGhlciBl eGFtcGxlIGNvdWxkIGJlIGFuIE9TUyBzeXN0ZW0KICAgd2hpY2ggaW5wdXRzIHRoZSBzYW1lIGlu Zm9ybWF0aW9uIHZpYSBhIHNjcmlwdCBvdmVyIGFuIFNTSAogICBjb25uZWN0aW9uLCBvciBieSBw dXNoaW5nIGNvbmZpZ3VyYXRpb24gdGhyb3VnaCBzb21lIG90aGVyIG1hbmFnZW1lbnQKICAgY29u bmVjdGlvbiwgc3RhbmRhcmQgKE5ldGNvbmYtYmFzZWQpIG9yIHByb3ByaWV0YXJ5LgoKICAgVGhl IGRyYXdiYWNrcyBvZiBhbiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gaW5jbHVkZTogbGFjayBvZiBz Y2FsZS0KICAgYWJpbGl0eSwgY29tcGxleGl0eSBhbmQgc3BlZWQgb2YgY2hhbmdpbmcgaWYgYSBi cmVhY2ggaXMgc3VzcGVjdGVkLgogICBGb3IgZXhhbXBsZSwgaWYgYW4gZW1wbG95ZWUgd2hvIGhh ZCBhY2Nlc3MgdG8ga2V5cyB3YXMgd2FzCiAgIHRlcm1pbmF0ZWQsIG9yIGlmIGEgbWFjaGluZSBo b2xkaW5nIHRob3NlIGtleXMgd2FzIGJlbGl2ZWQKICAgY29tcHJvbWlzZWQsIHRoZW4gdGhlIHN5 c3RlbSB3b3VsZCBiZSBjb25zaWRlcmVkIGluc2VjdXJlIGFuZAogICB2dWxuZXJhYmxlIHVudGls IG5ldyBrZXlzIHdlcmUgZGVmaW5lZCBieSBhIGh1bWFuLiAgVGhvc2Uga2V5cyB0aGVuCiAgIG5l ZWQgdG8gYmUgcGxhY2VkIGludG8gdGhlIE9TUyBzeXN0ZW0sIG1hbnVhbGx5LCBhbmQgdGhlIE9T UyBzeXN0ZW0KICAgdGhlbiBuZWVkcyB0byBwdXNoIHRoZSBjaGFuZ2UgLS0gb2Z0ZW4gZHVyaW5n IGEgdmVyeSBsaW1pdGVkIGNoYW5nZQogICB3aW5kb3cgLS0gaW50byB0aGUgcmVsZXZhbnQgZGV2 aWNlcy4gIElmIHRoZXJlIGFyZSBtdWx0aXBsZQogICBvcmdhbml6YXRpb25zIGludm9sdmVkIGlu IHRoZXNlIGNvbm5lY3Rpb25zLCB0aGlzIHByb2Nlc3MgaXMgZ3JlYXRseQogICBjb21wbGljYXRl ZC4KCiAgIFRoZSBiZW5lZml0cyBvZiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gaXMgdGhhdCBvbmNl IHRoZSBuZXcga2V5cy8KICAgcGFyYW1ldGVycyBhcmUgc2V0IGluIE9TUyBzeXN0ZW0gdGhleSBj YW4gYmUgcHVzaGVkIGF1dG9tYXRpY2FsbHkgdG8KICAgYWxsIGRldmljZXMgd2l0aGluIHRoZSBP U1MncyBkb21haW4gb2YgY29udHJvbC4gIE9wZXJhdG9ycyBoYXZlCiAgIG1lY2hhbmlzbXMgaW4g cGxhY2UgZm9yIHRoaXMgYWxyZWFkeS4gIEluIHNtYWxsIGVudmlyb25tZW50cyB3aXRoIGZldwog ICByb3V0ZXJzLCBhIG1hbnVhbCBzeXN0ZW0gaXMgbm90IGRpZmZpY3VsdCB0byBlbXBsb3kuCgog ICBXZSBmdXJ0aGVyIGRlZmluZSBhbiBpbi1saW5lIGtleSBleGNoYW5nZSBhcyB1c2luZyBjcnlw dG9ncmFwaGljbHkKICAgcHJvdGVjdGVkIGlkZW50aXR5IHZlcmlmaWNhdGlvbiwgc2Vzc2lvbiBr ZXkgbmVnb3RpYXRpb24sIGFuZAogICBzZWN1cml0eSBhc3NvY2lhdGlvbiBwYXJhbWV0ZXIgbmVn b3RpYXRpb24gYmV0d2VlbiB0aGUgdHdvIHJvdXRpbmcKICAgcGVlcnMuICBUaGUgS01QIGJldHdl ZW4gdGhlIHR3byBwZWVycyBtYXkgYWxzbyBpbmNsdWRlIHRoZQogICBuZWdvdGlhdGlvbiBvZiBw YXJhbWV0ZXJzLCBsaWtlIGFsZ29yaXRobXMsIGNyeXB0b2dyYXBoaWMgaW5wdXRzCiAgIChlLmcu IGluaXRpYWxpemF0aW9uIHZlY3RvcnMpLCBrZXkgbGlmZS10aW1lcywgZXRjLgoKICAgVGhlIGJl bmVmaXRzIGFuIGluLWxpbmUgS01QIGFyZSBzZXZlcmFsLiAgQW4gaW4tbGluZSBLTVAgcmVzdWx0 cyBpbgogICBrZXkocykgdGhhdCBhcmUgcHJpdmF0ZWx5IGdlbmVyYXRlZCwgYW5kIG5vdCByZWNv cmRlZCBwZXJtYW5lbnRseQogICBhbnl3aGVyZS4gIFNpbmNlIHRoZSB0cmFmZmljIGtleXMgdXNl ZCBpbiBhIHBhcnRpY3VsYXIgY29ubmVjdGlvbiBhcmUKICAgbm90IGEgZml4ZWQgcGFydCBvZiBh IGRldmljZSBjb25maWd1cmF0aW9uIG5vIHN0ZWFsLWFibGUgZGF0YSBleGlzdHMKICAgYW55d2hl cmUgZWxzZSBpbiB0aGUgb3BlcmF0b3IncyBzeXN0ZW1zIHdoaWNoIGNhbiBiZSBzdG9sZW4sIGUu Zy4gaW4KICAgdGhlIGNhc2Ugb2YgYSB0ZXJtaW5hdGVkIG9yIHR1cm5lZCBlbXBsb3llZS4gIElm IGEgc2VydmVyIG9yIG90aGVyCiAgIGRhdGEgc3RvcmUgaXMgc3RvbGVuIG9yIGNvbXByb21pc2Vk LCB0aGUgdGhpZXZlcyBnYWluIG5vIGFjY2VzcyB0bwogICBjdXJyZW50IHRyYWZmaWMga2V5cy4g IFRoZXkgbWF5IGdhaW4gYWNjZXNzIHRvIGtleSBkZXJpdmF0aW9uCiAgIG1hdGVyaWFsLCBsaWtl IGEgUFNLLCBidXQgbm90IGN1cnJlbnQgdHJhZmZpYyBrZXlzIGluIHVzZS4gIEluIHRoaXMKICAg ZXhhbXBsZSwgdGhlc2UgUFNLcyBjYW4gYmUgdXBkYXRlZCBpbnRvIHRoZSBkZXZpY2UgY29uZmln dXJhdGlvbnMKICAgKGVpdGhlciBtYW51YWxseSBvciB0aHJvdWdoIGFuIE9TUykgd2l0aG91dCBi b3VuY2luZyBvciBpbXBhY3RpbmcgdGhlCiAgIGV4aXN0aW5nIHNlc3Npb24gYXQgYWxsLiAgSW4g dGhlIGNhc2Ugb2YgdXNpbmcgcmF3IGFzc3ltZXRyaWMga2V5cyBvcgogICBjZXJ0aWZpY2F0ZXMs IGluc3RlYWQgb2YgUFNLcywgdGhlIGRhdGEgdGhlZnQgd291bGQgbGlrZWx5IG5vdCBldmVuCiAg IHJlc3VsdCBpbiBhbnkgY29tcHJvbWlzZSwgYXMgdGhlIGtleSBwYWlycyB3b3VsZCBoYXZlIGJl ZW4gZ2VuZXJhdGVkCiAgIG9uIHRoZSByb3V0ZXJzLCBhbmQgbmV2ZXIgbGVhdmUgdGhvc2Ugcm91 dGVycy4gIEluIHN1Y2ggYSBjYXNlIG5vCiAgIGNoYW5nZXMgYXJlIG5lZWRlZCBvbiB0aGUgcm91 dGVyczsgdGhlIGNvbm5lY3Rpb25zIHdpbGwgY29udGludWUgdG8KCgoKTGVib3ZpdHogJiAgICAg ICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMjFd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAg ICAgICBOb3ZlbWJlciAyMDA5CgoKICAgYmUgc2VjdXJlLCB1bmNvbXByb21pc2VkLiAgQWRkaXRp b25hbGx5LCB3aXRoIGEgS01QIHJlZ3VsYXIgcmUta2V5cwogICBvcGVyYXRpb25zIG9jY3VyIHdp dGhvdXQgYW55IG9wZXJhdG9yIGludm9sdmVtZW50IG9yIG92ZXJzaWdodC4gIFRoaXMKICAga2Vl cHMga2V5cyBmcmVzaC4KCiAgIFRoZSBkcmF3YmFja3MgdG8gdXNpbmcgYSBLTVAgYXJlIGZldy4g IEZpcnN0LCBhIEtNUCByZXF1aXJlcyBtb3JlCiAgIGNyeXB0b2dyYXBoaWMgcHJvY2Vzc2luZyBm b3IgdGhlIHJvdXRlciBhdCB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgYQogICBjb25uZWN0aW9uLiAg VGhpcyB3aWxsIGFkZCBzb21lIG1pbm9yIHN0YXJ0LXVwIHRpbWUgdG8gY29ubmVjdGlvbgogICBl c3RhYmxpc2htZW50IHZlcnN1cyBhIHB1cmVseSBtYW51YWwga2V5IGFwcHJvYWNoLiAgT25jZSBh IGNvbm5lY3Rpb24KICAgd2l0aCB0cmFmZmljIGtleXMgaGF2ZSBiZWVuIGVzdGFibGlzaGVkIHZp YSBhIEtNUCwgdGhlIHBlcmZvcm1hbmNlIGlzCiAgIHRoZSBzYW1lIGluIHRoZSBLTVAgYW5kIHRo ZSBvdXQtb2YtYmFuZCBjYXNlLiAgS01QcyBhbHNvIGFkZCBhbm90aGVyCiAgIGxheWVyIG9mIHBy b3RvY29sIGFuZCBjb25maWd1cmF0aW9uIGNvbXBsZXhpdHkgd2hpY2ggY2FuIGZhaWwgb3IgYmUK ICAgbWlzY29uZmlndXJlZC4gIFRoaXMgd2FzIG1vcmUgb2YgYW4gaXNzdWUgd2hlbiB0aGVzZSBL TVBzIHdlcmUgZmlyc3QKICAgZGVwbG95ZWQsIGJ1dCBsZXNzIHNvIGFzIHRoZXNlIGltcGxlbWVu dGFpdG9ucyBhbmQgb3BlcmF0aW9uYWwKICAgZXhwZXJpZW5jZSB3aXRoIHRoZW0gaGFzIG1hdHVy ZWQuCgogICBUaGUgZGVzaXJlZCBlbmQgZ29hbCBpcyBpbi1saW5lIEtNUHMuCgoKNC4gIFRoZSBS b2FkbWFwCgo0LjEuICBXb3JrIFBoYXNlcyBvbiBhbnkgUGFydGljdWxhciBQcm90b2NvbAoKICAg VGhlIGRlc2lyZWQgZW5kc3RhdGUgZm9yIHRoZSBLQVJQIHdvcmsgY29udGFpbnMgc2V2ZXJhbCBp dGVtcy4KICAgRmlyc3QsIHRoZSBwZW9wbGUgZGVzaXJpbmcgdG8gZGVwbG95IHNlY3VyZWx5IGF1 dGhlbnRpY2F0ZWQgYW5kCiAgIGludGVncml0eSB2YWxpZGF0ZWQgcGFja2V0cyBiZXR3ZWVuIHJv dXRpbmcgcGVlcnMgaGF2ZSB0aGUgdG9vbHMKICAgc3BlY2lmaWVkLCBpbXBsZW1lbnRlZCBhbmQg c2hpcHBpbmcgaW4gb3JkZXIgdG8gZGVwbG95LiAgVGhlc2UgdG9vbHMKICAgc2hvdWxkIGJlIGZh aXJseSBzaW1wbGUgdG8gaW1wbGVtZW50LCBhbmQgbm90IG1vcmUgY29tcGxleCB0aGFuIHRoZQog ICBzZWN1cml0eSBtZWNoYW5pc21zIHRvIHdoaWNoIHRoZSBvcGVyYXRvcnMgYXJlIGFscmVhZHkg YWNjdXN0b21lZC4KICAgKEV4YW1wbGVzIG9mIHNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gd2hpY2gg cm91dGVyIG9wZXJhdG9ycyBhcmUKICAgYWNjdXN0b21lZCBpbmNsdWRlOiB0aGUgdXNlIG9mIGFz c3ltZXRyaWMga2V5cyBmb3IgYXV0aGVudGljYXRpb24gaW4KICAgU1NIIGZvciByb3V0ZXIgY29u ZmlndXJhdGlvbiwgdGhlIHVzZSBvZiBwcmUtc2hhcmVkIGtleXMgKFBTS3MpIGluCiAgIFRDUCBN RDUgZm9yIEJHUCBwcm90ZWN0aW9uLCB0aGUgdXNlIG9mIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRl cyBmb3IKICAgSFRUUFMgYWNjZXNzIHRvIGRldmljZSBXZWItYmFzZWQgdXNlciBpbnRlcmZhY2Vz LCB0aGUgdXNlIG9mIHN0cm9uZ2x5CiAgIGNvbnN0cnVjdGVkIHBhc3N3b3JkcyBhbmQvb3IgaWRl bnRpdHkgdG9rZW5zIGZvciB1c2VyIGlkZW50aWZpY2F0aW9uCiAgIHdoZW4gbG9nZ2luZyBpbnRv IHJvdXRlcnMgYW5kIG1hbmFnZW1lbnQgc3lzdGVtcy4pICBXaGlsZSB0aGUgdG9vbHMKICAgdGhh dCB3ZSBpbnRlbmQgdG8gc3BlY2lmeSBtYXkgbm90IGJlIGFibGUgdG8gc3RvcCBhIGRlcGxveW1l bnQgZnJvbQogICB1c2luZyAiZm9vYmFyIiBhcyBhbiBpbnB1dCBrZXkgZm9yIGV2ZXJ5IGRldmlj ZSBhY3Jvc3MgdGhlaXIgZW50aXJlCiAgIHJvdXRpbmcgZG9tYWluLCB3ZSBpbnRlbmQgdG8gbWFr ZSBhIHNvbGlkLCBtb2Rlcm4gc2VjdXJpdHkgc3lzdGVtCiAgIHRoYXQgaXMgbm90IHRvbyBtdWNo IG1vcmUgZGlmZmljdWx0IHRoYW4gdGhhdC4gIEluIG90aGVyIHdvcmRzLAogICBzaW1wbGljaXR5 IGFuZCBkZXBsb3lhYmlsaXR5IGFyZSBrZXlzIHRvIHN1Y2Nlc3MuICBUaGUgUm91dGluZwogICBQ cm90b2NvbHMgd2lsbCBzcGVjaWZ5IG1vZGVybiBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgYW5k IHNlY3VyaXR5CiAgIG1lY2hhbmlzbXMuICBSb3V0aW5nIHBlZXJzIHdpbGwgYmUgYWJsZSB0byBl bXBsb3kgdW5pcXVlLCBwYWlyLXdpc2UKICAga2V5cyBwZXIgcGVlcmluZyBpbnN0YW5jZSwgd2l0 aCByZWFzb25hYmxlIGtleSBsaWZldGltZXMsIGFuZAogICB1cGRhdGluZyB0aG9zZSBrZXlzIG9u IGEgc29tZXdoYXQgcmVndWxhciBiYXNpcyB3aWxsIGJlIG9wZXJhdGlvbmFsbHkKICAgZWFzeSwg Y2F1c2luZyBubyBzZXJ2aWNlIGludGVycnVwdGlvbi4KCiAgIEFjaGlldmluZyB0aGUgYWJvdmUg ZGVzY3JpYmVkIGVuZC1zdGF0ZSB1c2luZyBtYW51YWwga2V5cyBtYXkgb25seSBiZQogICBwcmFn bWF0aWMgaW4gdmVyeSBzbWFsbCBkZXBsb3ltZW50cy4gIEluIGxhcmdlciBkZXBsb3ltZW50cywg dGhpcyBlbmQKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAx MCAgICAgICAgICAgICAgICAgW1BhZ2UgMjJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgc3RhdGUg d2lsbCBiZSBtdWNoIG1vcmUgb3BlcmF0aW9uYWxseSBkaWZmaWN1bHQgdG8gcmVhY2ggd2l0aCBv bmx5CiAgIG1hbnVhbCBrZXlzLiAgVGh1cywgdGhlcmUgd2lsbCBiZSBhIG5lZWQgZm9yIGtleSBs aWZlIGN5Y2xlCiAgIG1hbmFnZW1lbnQsIGluIHRoZSBmb3JtIG9mIGEga2V5IG1hbmFnZW1lbnQg cHJvdG9jb2wsIG9yIEtNUC4gIFdlCiAgIGV4cGVjdCB0aGF0IHRoZSB0d28gZm9ybXMsIG1hbnVh bCBrZXkgdXNhZ2UgYW5kIEtNUCB1c2FnZSwgd2lsbCBjby0KICAgZXhpc3QgaW4gdGhlIHJlYWwg d29ybGQuICBGb3IgZXhhbXBsZSwgYSBwcm92aWRlcidzIGVkZ2Ugcm91dGVyIGF0IGEKICAgcHVi bGljIGV4Y2hhbmdlIHBlZXJpbmcgcG9pbnQgd2lsbCB3YW50IHRvIHVzZSBhIEtNUCBmb3IgZW5z dXJpbmcKICAgdW5pcXVlIGFuZCBmcmVzaCBrZXlzIHdpdGggZXh0ZXJuYWwgcGVlcnMsIHdoaWxl IGEgbWFudWFsIGtleSBtYXkgYmUKICAgdXNlZCBiZXR3ZWVuIGEgcHJvdmlkZXIncyBhY2Nlc3Mg ZWRnZSByb3V0ZXIgYW5kIGVhY2ggb2YgdGhlIHNhbWUKICAgcHJvdmlkZXIncyBjdXN0b21lciBw cmVtaXNlIHJvdXRlcnMgd2l0aCB3aGljaCBpdCBwZWVycy4KCiAgIEluIGFjY29yZGFuY2Ugd2l0 aCB0aGUgZGVzaXJlZCBlbmQgc3RhdGUganVzdCBkZXNjcmliZWQsIHdlIGRlZmluZQogICB0d28g bWFpbiB3b3JrIHBoYXNlcyBmb3IgZWFjaCBSb3V0aW5nIFByb3RvY29sOgoKICAgMS4gIEVuaGFu Y2UgdGhlIFJvdXRpbmcgUHJvdG9jb2wncyBjdXJyZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bS4KICAgICAgIFRoaXMgd29yayBpbnZvbHZlcyBlbmhhbmNpbmcgYSBSb3V0aW5nIFByb3RvY29s J3MgY3VycmVudAogICAgICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBpbiBvcmRlciB0byBhY2hpZXZl IGEgY29uc2lzdGVudCwgbW9kZXJuCiAgICAgICBsZXZlbCBvZiBzZWN1cml0eSBmdW5jdGlvbmFs aXR5IHdpdGhpbiBpdHMgZXhpc3Rpbmcga2V5aW5nCiAgICAgICBmcmFtZXdvcmsuICBJdCBpcyB1 bmRlcnN0b29kIGFuZCBhY2NlcHRlZCB0aGF0IHRoZSBleGlzdGluZwogICAgICAga2V5aW5nIGZy YW1ld29ya3MgYXJlIGxhcmdlbHkgYmFzZWQgb24gbWFudWFsIGtleXMuICBTaW5jZSBtYW55CiAg ICAgICBvcGVyYXRvcnMgaGF2ZSBhbHJlYWR5IGJ1aWx0IG9wZXJhdGlvbmFsIHN1cHBvcnQgc3lz dGVtcyAoT1NTKQogICAgICAgYXJvdW5kIHRoZXNlIG1hbnVhbCBrZXkgaW1wbGVtZW50YXRpb25z LCB0aGVyZSBpcyBzb21lIGF1dG9tYXRpb24KICAgICAgIGF2YWlsYWJsZSBmb3IgYW4gb3BlcmF0 b3IgdG8gbGV2ZXJhZ2UgaW4gdGhhdCB3YXksIGlmIHRoZQogICAgICAgdW5kZXJseWluZyBtZWNo YW5pc21zIGFyZSB0aGVtc2VsdmVzIHNlY3VyZS4gIEluIHRoaXMgcGhhc2UsIHdlCiAgICAgICBl eHBsaWNpdGx5IGV4Y2x1ZGUgZW1iZWRkaW5nIG9yIGNyZWF0aW5nIGEgS01QLiAgQSBsaXN0IG9m IHRoZQogICAgICAgcmVxdWlyZW1lbnRzIGZvciBQaGFzZSAxIHdvcmsgYXJlIGJlbG93IGluIHRo ZSBzZWN0aW9uCiAgICAgICAiUmVxdWlyZW1lbnRzIGZvciBQaGFzZSAxIFJvdXRpbmcgUHJvdG9j b2xzJyBTZWN1cml0eSBVcGRhdGVzCiAgICAgICAoU2VjdGlvbiA0LjIpLgoKICAgMi4gIERldmVs b3AgYW4gYXV0b21hdGVkIGtleWluZyBmcmFtZXdvcmsuICBUaGUgc2Vjb25kIHBoYXNlIHdpbGwK ICAgICAgIGZvY3VzIG9uIHRoZSBkZXZlbG9wbWVudCBvZiBhbiBhdXRvbWF0ZWQga2V5aW5nIGZy YW1ld29yayB0bwogICAgICAgZmFjaWxpYXRlIHVuaXF1ZSBwYWlyLXdpc2UgKG9yIHBlcmhhcHMg Z3JvdXAtd2lzZSwgd2hlcmUKICAgICAgIGFwcGxpY2FibGUpIGtleXMgcGVyIHBlZXJpbmcgaW5z dGFuY2UuICBUaGlzIGludm9sdmVzIHRoZSB1c2Ugb2YKICAgICAgIGEgS01QLiAgQSBLTVAgaXMg aGVscGZ1bCBiZWNhdXNlIGl0IG5lZ290aWF0ZXMgdW5pcXVlLCBwYWlyIHdpc2UsCiAgICAgICBy YW5kb20ga2V5cyB3aXRob3V0IGFkbWluaXN0cmF0b3IgaW52b2x2ZW1lbnQuICBJdCBhbHNvCiAg ICAgICBuZWdvdGlhdGVzIHNldmVyYWwgb2YgdGhlIFNBIHBhcmFtZXRlcnMgcmVxdWlyZWQgZm9y IHRoZSBzZWN1cmUKICAgICAgIGNvbm5lY3Rpb24sIGluY2x1ZGluZyBrZXkgbGlmZSB0aW1lcy4g IEl0IGtlZXBzIHRyYWNrIG9mIHRob3NlCiAgICAgICBsaWZldGltZXMgdXNpbmcgY291bnRlcnMs IGFuZCBuZWdvdGlhdGVzIG5ldyBrZXlzIGFuZCBwYXJhbWV0ZXJzCiAgICAgICBiZWZvcmUgdGhl eSBleHBpcmUsIGFnYWluLCB3aXRob3V0IGFkbWluaXN0cmF0b3IgaW50ZXJhY3Rpb24uCiAgICAg ICBBZGRpdGlvbmFsbHksIGluIHRoZSBldmVudCBvZiBhIGJyZWFjaCwgY2hhbmdpbmcgdGhlIEtN UCBrZXkgd2lsbAogICAgICAgaW1tZWRpYXRlbHkgY2F1c2UgYSByZWtleSB0byBvY2N1ciBmb3Ig dGhlIFRyYWZmaWMgS2V5LCBhbmQgdGhvc2UKICAgICAgIG5ldyBUcmFmZmljIEtleXMgd2lsbCBi ZSBpbnN0YWxsZWQgYW5kIHVzZWQgaW4gdGhlIGN1cnJlbnQKICAgICAgIGNvbm5lY3Rpb24uICBJ biBzdW1tYXJ5LCBhIEtNUCBwcm92aWRlcyBhIHByb3RlY3RlZCBjaGFubmVsCiAgICAgICBiZXR3 ZWVuIHRoZSBwZWVycyB0aHJvdWdoIHdoaWNoIHRoZXkgY2FuIG5lZ290aWF0ZSBhbmQgcGFzcwog ICAgICAgaW1wb3J0YW50IGRhdGEgcmVxdWlyZWQgdG8gZXhjaGFuZ2UgcHJvb2Ygb2Yga2V5IGlk ZW50aWZpZXJzLAogICAgICAgZGVyaXZlIFRyYWZmaWMgS2V5cywgZGV0ZXJtaW5lIHJlLWtleWlu Zywgc3luY2hyb25pemUgdGhlaXIKICAgICAgIGtleWluZyBzdGF0ZSwgc2lnbmFsIHZhcmlvdXMg a2V5aW5nIGV2ZW50cywgbm90aWZ5IHdpdGggZXJyb3IKICAgICAgIG1lc3NhZ2VzLCBldGMuICBU byBhZGRyZXNzIGJydXRlIGZvcmNlIGF0dGFja3MgW1JGQzM1NjJdCiAgICAgICByZWNvbW1lbmRz IGEga2V5IG1hbmFnZW1lbnQgcHJhY3RpY2UgdG8gbWluaW1pemUgdGhlIHBvc3NpYmlsaXR5CgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9h ZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgICAgICBvZiBzdWNjZXNzZnVs IGF0dGFjay0tIGZyZXF1ZW50IGtleSByb3RhdGlvbiwgbGltaXRlZCBrZXkKICAgICAgIHNoYXJp bmcsIGtleSBsZW5ndGggcmVzdHJpY3Rpb25zLCBldGMuICBBZHZhbmNlcyBpbiBjb21wdXRhdGlv bmFsCiAgICAgICBwb3dlciBkdWUgdG8gTW9vcmUncyBsYXcgYXJlIG1ha2luZyB0aGF0IG1hbmFn ZW1lbnQgYnVyZGVuCiAgICAgICB1bnRlbmFibGUtLSBrZXlzIG11c3QgYmUgb2YgYSBzaXplIGFu ZCBjb21wb3NpdGlvbiB0aGF0IG1ha2VzCiAgICAgICBjb25maWd1cmF0aW9uIGFuZCBtYWludGFu Y2UgZGlmZmljdWx0IG9yIGtleXMgbXVzdCBiZSByb3RhdGVkCiAgICAgICB3aXRoIGFuIHVucmVh c29uYWJsZSBmcmVxdWVuY3kuICBBIEtNUCB3aWxsIGhlbHAgaW1tZW5zZWx5IHdpdGgKICAgICAg IHRoaXMgZ3Jvd2luZyBwcm9ibGVtLgoKICAgICAgIFRoZSBmcmFtZXdvcmsgZm9yIGFueSBvbmUg Um91dGluZyBQcm90b2NvbCB3aWxsIGZhbGwgdW5kZXIsIGFuZAogICAgICAgYmUgYWJsZSB0byBs ZXZlcmFnZSwgdGhlIGdlbmVyaWMgZnJhbWV3b3JrIGRlc2NyaWJlZCBiZWxvdyBpbgogICAgICAg c2VjdGlvbiBTZWN0aW9uIDQuMy4KCjQuMi4gIFJlcXVpcmVtZW50cyBmb3IgUGhhc2UgMSBSb3V0 aW5nIFByb3RvY29scycgU2VjdXJpdHkgVXBkYXRlCgogICBIZXJlIGlzIGEgcHJvcG9zZWQgbGlz dCBvZiByZXF1aXJlbWVudHMgdGhhdCBTSE9VTEQgYmUgYWRkcmVzc2VkIGJ5CiAgIFBoYXNlIDEg KGFjY29yZGluZyB0byAiMS4iIGFib3ZlKSBzZWN1cml0eSB1cGRhdGVzIHRvIFJvdXRpbmcKICAg UHJvdG9jb2xzIFt0byBiZSByZXZpZXdlZCBhZnRlciAtMDEgaXMgcmVsZWFzZWRdOgoKICAgMS4g ICBDbGVhciBkZWZpbml0aW9ucyBvZiB3aGljaCBlbGVtZW50cyBvZiB0aGUgdHJhbnNtaXNzaW9u IChmcmFtZSwKICAgICAgICBwYWNrZXQsIHNlZ21lbnQsIGV0Yy4pIGFyZSBwcm90ZWN0ZWQgYnkg dGhlIGF1dGhlbnRpY2F0aW9uCiAgICAgICAgbWVjaGFuaXNtCiAgIDIuICAgU3Ryb25nIGFsZ29y aXRobXMsIGFuZCBkZWZpbmVkIGFuZCBhY2NlcHRlZCBieSB0aGUgc2VjdXJpdHkKICAgICAgICBj b21tdW5pdHksIE1VU1QgYmUgc3BlY2lmaWVkLiAgVGhlIG9wdGlvbiBzaG91bGQgdXNlIGFsZ29y aXRobXMKICAgICAgICBjb25zaWRlcmVkIGFjY2VwdGVkIGJ5IHRoZSBzZWN1cml0eSBjb21tdW5p dHksIHdoaWNoIGFyZQogICAgICAgIGNvbnNpZGVyZWQgYXBwcm9wcmlhdGVseSBzYWZlLiAgVGhl IHVzZSBvZiBub24tc3RhbmRhcmQgb3IKICAgICAgICB1bnB1Ymxpc2hlZCBhbGdvcml0aG1zIFNI T1VMRCBCRSBhdm9pZGVkLgogICAzLiAgIEFsZ29yaXRobSBhZ2lsaXR5IGZvciB0aGUgY3J5cHRv Z3JhaHBpYyBhbGdvcml0aG1zIHVzZWQgaW4gdGhlCiAgICAgICAgYXV0aGVudGljYXRpb24gTVVT VCBiZSBzcGVjaWZpZWQsIGkuZS4gbW9yZSB0aGFuIG9uZSBhbGdvcml0aG0KICAgICAgICBNVVNU IGJlIHNwZWNpZmllZCBhbmQgaXQgTVVTVCBiZSBjbGVhciBob3cgbmV3IGFsZ29yaXRobXMgTUFZ IGJlCiAgICAgICAgc3BlY2lmaWVkIGFuZCB1c2VkIHdpdGhpbiB0aGUgcHJvdG9jb2wuICBUaGlz IHJlcXVpcmVtZW50IGV4aXN0cwogICAgICAgIGluIGNhc2Ugb25lIGFsZ29yaXRobSBnZXRzIGJy b2tlbiBzdWRkZW5seS4gIFJlc2VhcmNoIHRvCiAgICAgICAgaWRlbnRpZnkgd2Vha25lc3MgaW4g YWxnb3JpdGhtcyBpcyBjb25zdGFudC4gIEJyZWFraW5nIGEgY2lwaGVyCiAgICAgICAgaXNuJ3Qg YSBtYXR0ZXIgb2YgaWYsIGJ1dCB3aGVuIGl0IHdpbGwgb2NjdXIuIHQncyBoaWdobHkKICAgICAg ICB1bmxpa2VseSB0aGF0IHR3byBkaWZmZXJlbnQgYWxnb3JpdGhtcyB3aWxsIGJlIGJyb2tlbgog ICAgICAgIHNpbXVsdGFuZW91c2x5LiAgU28sIGlmIHR3byBhcmUgc3VwcG9ydGVkLCBhbmQgb25l IGdldHMgYnJva2VuLAogICAgICAgIHdlIGNhbiB1c2UgdGhlIG90aGVyIHVudGlsIHdlIGdldCBh IG5ldyBvbmUgaW4gcGxhY2UuICBIYXZpbmcKICAgICAgICB0aGUgYWJpbGl0eSB3aXRoaW4gdGhl IHByb3RvY29sIHNwZWNpZmljYXRpb24gdG8gc3VwcG9ydCBzdWNoIGFuCiAgICAgICAgZXZlbnQs IGhhdmluZyBhbGdvcml0aG0gYWdpbGl0eSwgaXMgZXNzZW50aWFsLiAgTWFuZGF0aW5nIHR3bwog ICAgICAgIGFsZ29yaXRobXMgcHJvdmlkZXMgYm90aCBhIHJlZHVuZGFuY3ksIGFuZCBhIG1lY2hh bmlzbSBmb3IKICAgICAgICBlbmFjdGluZyB0aGF0IHJlZHVuZGFuY3kgd2hlbiBuZWVkZWQuCiAg IDQuICAgU2VjdXJlIHVzZSBvZiBzaW1wbGUgUFNLcywgb2ZmZXJpbmcgYm90aCBvcGVyYXRpb25h bCBjb252ZW5pZW5jZQogICAgICAgIGFzIHdlbGwgYXMgYnVpbGRpbmcgc29tZXRoaW5nIG9mIGEg ZmVuY2UgYXJvdW5kIHN0dXBpZGl0eSwgTVVTVAogICAgICAgIGJlIHNwZWNpZmllZC4KICAgNS4g ICBJbnRlci1jb25uZWN0aW9uIHJlcGxheSBwcm90ZWN0aW9uLiAgUGFja2V0cyBjYXB0dXJlZCBm cm9tIG9uZQogICAgICAgIGNvbm5lY3Rpb24gTVVTVCBOT1QgYmUgYWJsZSB0byBiZSByZS1zZW50 IGFuZCBhY2NlcHRlZCBkdXJpbmcgYQogICAgICAgIGxhdGVyIGNvbm5lY3Rpb24uCgoKCgoKTGVi b3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAg ICAgW1BhZ2UgMjRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFw ICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgNi4gICBJbnRyYS1jb25uZWN0aW9u IHJlcGxheSBwcm90ZWN0aW9uLiAgUGFja2V0cyBjYXB0dXJlZCBkdXJpbmcgYQogICAgICAgIGNv bm5lY3Rpb24gTVVTVCBOT1QgYmUgYWJsZSB0byBiZSByZS1zZW50IGFuZCBhY2NlcHRlZCBkdXJp bmcKICAgICAgICB0aGF0IHNhbWUgY29ubmVjdGlvbiwgdG8gZGVhbCB3aXRoIGxvbmctbGl2ZWQg Y29ubmVjdGlvbnMuCiAgIDcuICAgQSBjaGFuZ2Ugb2Ygc2VjdXJpdHkgcGFyYW1ldGVycyBSRVFV SVJFUywgYW5kIGV2ZW4gZm9yY2VzLCBhCiAgICAgICAgY2hhbmdlIG9mIHNlc3Npb24gdHJhZmZp YyBrZXlzCiAgIDguICAgSW50cmEtY29ubmVjdGlvbiByZS1rZXlpbmcgd2hpY2ggb2NjdXJzIHdp dGhvdXQgYSBicmVhayBvcgogICAgICAgIGludGVycnVwdGlvbiB0byB0aGUgY3VycmVudCBwZWVy aW5nIHNlc3Npb24sIGFuZCwgaWYgcG9zc2libGUsCiAgICAgICAgd2l0aG91dCBkYXRhIGxvc3Ms IE1VU1QgYmUgc3BlY2lmaWVkLgogICA5LiAgIEVmZmljaWVudCByZS1rZXlpbmcgU0hPVUxEIGJl IHByb3ZpZGVkLiAgVGhlIHNwZWNpZmljYWlvbiBTSE9VTEQKICAgICAgICBzdXBwb3J0IHJla2V5 aW5nIGR1cmluZyBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUgbmVlZCB0byBleHBlbmQKICAgICAg ICB1bmR1ZSBjb21wdXRhdGlvbmFsIHJlc291cmNlcy4gIEluIHBhcnRpY3VsYXIsIHRoZSBzcGVj aWZpY2F0aW9uCiAgICAgICAgU0hPVUxEIGF2b2lkIHRoZSBuZWVkIHRvIHRyeS9jb21wdXRlIG11 bHRpcGxlIGtleXMgb24gYSBnaXZlbgogICAgICAgIHBhY2tldC4KICAgMTAuICBQcmV2ZW50IERv UyBhdHRhY2tzIGFzIHRob3NlIGRlc2NyaWJlZCBhcyBpbi1zY29wZSBpbiB0aGUKICAgICAgICB0 aHJlYXRzIHNlY3Rpb24gU2VjdGlvbiAyLjEgYWJvdmUuCiAgIDExLiAgRGVmYXVsdCBtZWNoYW5p c21zIGFuZCBhbGdvcml0aG1zIHNwZWNpZmllZCBhbmQgZGVmaW5lZCBhcwogICAgICAgIFJFUVVJ UkVEIGZvciBhbGwgaW1wbGVtZW50YXRpb25zCiAgIDEyLiAgTWFudWFsIGtleWluZyBNVVNUIGJl IHN1cHBvcnRlZC4KICAgMTMuICBDb252ZXJnZW5jZSB0aW1lcyBvZiB0aGUgUm91dGluZyBQcm90 b2NvbHMgU0hPVUxEIE5PVCBiZQogICAgICAgIG1hdGVyaWFsbHkgYWZmZWN0ZWQuICBNYXRlcmlh bGx5IGhlcmUgaXMgZGVmaW5lZCBhcyBhbnl0aGluZwogICAgICAgIGdyZWF0ZXIgdGhhbiBhIDUl IGNvbnZlcmdlbmNlIHRpbWUgaW5jcmVhc2UuICBOb3RlIHRoYXQKICAgICAgICBjb252ZXJnZW5j ZSBpcyBkaWZmZXJlbnQgdGhhbiBib290IHRpbWUuICBBbHNvIG5vdGUgdGhhdAogICAgICAgIGNv bnZlcmdlbmNlIHRpbWUgaGFzIGEgbG90IHRvIGRvIHdpdGggdGhlIHNwZWVkIG9mIHByb2Nlc3Nv cnMKICAgICAgICB1c2VkIG9uIGluZGl2aWR1YWwgcm91dGluZyBwZWVycywgYW5kIHRoaXMgaW5j cmVhc2VzIGJ5IE1vb3JlJ3MKICAgICAgICBsYXcgb3ZlciB0aW1lLiAgVGhlcmVmb3JlLCB0aGlz IHJlcXVpcmVtZW50IHNob3VsZCBiZSBjb25zaWRlcmVkCiAgICAgICAgb25seSBpbiB0ZXJtcyBv ZiB0b3RhbCBudW1iZXIgb2YgbWVzc2FnZXMgdGhhdCBtdXN0IGJlCiAgICAgICAgZXhjaGFuZ2Vk LCBhbmQgbGVzcyBmb3IgdGhlIGNvbXB1dGF0aW9uYWwgaW50ZW5zaXR5IG9mCiAgICAgICAgcHJv Y2Vzc2luZyBhbnkgb25lIG1lc3NhZ2UuCiAgIDE0LiAgVGhlIGNoYW5nZXMgb3IgYWRkaXRpb24g b2Ygc2VjdXJpdHkgbWVjaGFuaXNtcyBTSE9VTEQgTk9UIGNhdXNlCiAgICAgICAgYSByZWZyZXNo IG9mIHJvdXRlIHVwZGF0ZXMgb3IgY2F1c2UgYWRkaXRpb25hbCByb3V0ZSB1cGRhdGVzIHRvCiAg ICAgICAgYmUgZ2VuZXJhdGVkCiAgIDE1LiAgQXJjaGl0ZWN0dXJlIG9mIHRoZSBzcGVjaWZpY2F0 aW9uIE1VU1QgY29uc2lkZXIgYW5kIGFsbG93IGZvcgogICAgICAgIGZ1dHVyZSB1c2Ugb2YgYSBL TVAuCgo0LjMuICBDb21tb24gRnJhbWV3b3JrCgogICBFYWNoIG9mIHRoZSBjYXRlZ29yaWVzIG9m IHJvdXRpbmcgcHJvdG9jb2xzIGFib3ZlIHdpbGwgcmVxdWlyZSB1bmlxdWUKICAgZGVzaWducyBm b3IgYXV0aGVudGljYXRpbmcgYW5kIGludGVncml0eSBjaGVja2luZyB0aGVpciBwcm90b2NvbHMu CiAgIEhvd2V2ZXIsIGEgc2luZ2xlIHVuZGVybHlpbmcgZnJhbWV3b3JrIGZvciBkZWxpdmVyaW5n IGF1dG9tYXRpYwogICBrZXlpbmcgdG8gdGhvc2Ugc29sdXRpb25zIHdpbGwgYmUgcHVyc3VlZC4g IFByb3ZpZGluZyBzdWNoIGEgc2luZ2xlCiAgIGZyYW1ld29yayB3aWxsIHNpZ25pZmljYW50bHkg cmVkdWNlIHRoZSBjb21wbGV4aXR5IG9mIGVhY2ggc3RlcCBvZgogICB0aGUgb3ZlcmFsbCByb2Fk bWFwLiAgRm9yIGV4YW1wbGUsIGlmIGVhY2ggUm91dGluZyBQcm90b2NvbCBuZWVkZWQgdG8KICAg ZGVmaW5lIGl0J3Mgb3duIGtleSBtYW5hZ2VtZW50IHByb3RvY29sIHRoaXMgd291bGQgYmFsbG9v biB0aGUgdG90YWwKICAgYW1vdW50IG9mIGRpZmZlcmVudCBzb2NrZXRzIHRoYXQgYXJlIG5lZWRl ZCB0byBiZSBvcGVuZWQgYW5kCiAgIHByb2Nlc3NlcyB0aGF0IGFyZSBuZWVkZWQgdG8gYmUgc2lt dWx0YW5lb3VzbHkgcnVubmluZyBvbiBhbgogICBpbXBsZW1lbnRhdGlvbi4gIEl0IHdvdWxkIGFs c28gc2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUgcnVuLXRpbWUKICAgY29tcGxleGl0eSBhbmQg bWVtb3J5IHJlcXVpcmVtZW50cyBvZiBzdWNoIHN5c3RlbXMgcnVubmluZyBtdWx0aXBsZQogICBS b3V0aW5nIFByb3RvY29scywgY2F1c2luZyBwZXJoYXBzIHNsb3dlciBwZXJmb3JtYW5jZSBvZiBz dWNoCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAg ICAgICAgICAgICAgIFtQYWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtB UlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIHN5c3RlbXMuICBI b3dldmVyLCBpZiB3ZSBjYW4gbGFuZCBvbiBhIHZlcnkgc21hbGwgc2V0IChwZXJoYXBzIG9uZSBv cgogICB0d28pIG9mIGF1dG9tYXRpYyBrZXkgbWFuYWdlbWVudCBwcm90b2NvbHMsIEtNUHMsIHRo YXQgdGhlIHZhcmlvdXMKICAgUm91dGluZyBQcm90b2NvbHMgY2FuIHVzZSwgdGhlbiB3ZSBjYW4g cmVkdWNlIHRoaXMgaW1wbGVtZW50YXRpb24gYW5kCiAgIHJ1bi10aW1lIGNvbXBsZXhpdHkuICBX ZSBjYW4gYWxzbyBkZWNyZWFzZSB0aGUgdG90YWwgYW1vdW50IG9mIHRpbWUKICAgaW1wbGVtZW50 ZXJzIG5lZWQgdG8gZGVsaXZlciB0aGUgS01QcyBmb3IgdGhlIFJvdXRpbmcgUHJvdG9jb2xzIHRo YXQKICAgd2lsbCBwcm92aWRlIGJldHRlciB0aHJlYXQgcHJvdGVjdGlvbi4KCiAgIFRoZSBjb21w b25lbnRzIGZvciB0aGUgZnJhbWV3b3JrIGFyZSBsaXN0ZWQgaGVyZSwgYW5kIGRlc2NyaWJlZAog ICBiZWxvdzoKCiAgIG8gIFJvdXRpbmcgUHJvdG9jb2wgc2VjdXJpdHkgbWVjaGFuaXNtCiAgIG8g IEtNUAogICBvICBLZXlTdG9yZQogICBvICBUcmFmZmljIEtleQogICBvICBSb3V0aW5nUHJvdG9j b2wtdG8tS01QIEFQSQogICBvICBSb3V0aW5nUHJvdG9jb2wtdG8tS2V5U3RvcmUgQVBJCiAgIG8g IEtNUC10by1LZXlTdG9yZSBBUEkKICAgbyAgQ29tbW9uIFJvdXRpbmcgUHJvdG9jb2wgbWVjaGFu aXNtcwogICBvICBJZGVudGlmaWVycwogICBvICBQcm9vZiBvZiBpZGVudGl0eQogICBvICBQcm9m aWxlcwoKICAgVGhlIGZyYW1ld29yayBpcyBtb2R1bGFyaXplZCBmb3IgaG93IGtleXMgYW5kIHNl Y3VyaXR5IGFzc29jaWF0aW9uCiAgIChTQSkgcGFyYW1ldGVycyBnZW5lcmFsbHkgZ2V0IHBhc3Nl ZCBmcm9tIGEgS01QIHRvIGEgdHJhbnNwb3J0CiAgIHByb3RvY29sLiAgSXQgY29udGFpbnMgdGhy ZWUgbWFpbiBibG9ja3MgYW5kIEFQSXMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTGVib3Zp dHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAg W1BhZ2UgMjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAg ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgICAgKy0tLS0tLS0tLS0tLSsgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgIHwgICAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAg ICAgICAgfCBDaGVjayAgICAgKy0tLS0tLS0tLS0tKwogICAgICB8IElkZW50aWZpZXIgKy0tPnwg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tPnwgICAgICAgICAgIHwKICAgICAgfCAgICAg ICAgICAgIHwgICB8ICAgIEtNUCBGdW5jdGlvbiAgICB8ICAgICAgICAgICB8ICBJZGVudGl0eSB8 CiAgICAgICstLS0tLS0tLS0tLSArICAgfCAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0t KyAgIFByb29mICAgfAogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg IHwgIEFwcHJvdmUgIHwgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICArLSstLS0t LS0tLS0tLS0tLSstLS0rICAgICAgICAgICArLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8CiAgICAgICAgIEtNUC10by1LZXlTdG9yZSB8ICAgICAg ICAgICAgICB8CiAgICAgICAgICAgIEFQSSAgICAgICAgICB8ICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgICAgICAgIFx8LyAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgKy0t LS0tLS0rLS0tLS0tLSsgICAgICB8CiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwg ICAgICB8IEtNUC10by1Sb3V0aW5nUHJvdG9jb2wKICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfCAgICAgIHwgIEFQSQogICAgICAgICAgICAgICAgIHwgICAgS2V5U3RvcmUgICB8ICAg ICAgfAogICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgfAogICAgICAgICAg ICAgICAgICstLS0tLS0tKy0tLS0tLS0rICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg fAogICAgICAgICAgIEtleVN0b3JlLXRvLSAgfCAgICAgICAgICAgICAgfAogICAgUm91dGluZ1By b3RvY29sIEFQSSAgfCAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICBcfC8KICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICAgICAgICAgICB8ICAgICAgICAgIFx8LyAgICAgICAgICBDb21tb24g UnRnUHJvdG8gIHwKICAgICAgICAgICAgIHwgICArLS0tLS0tLSstLS0tLS0tKyAgIEF1dGhlbnRp Y2F0aW9uICAgfAogICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8ICAgTWVjaGFuaXNt cyAgICAgICB8CiAgICAgICAgICAgICArLS0tfCAgVHJhZmZpYyAgICAgIHwtLS0tLSstLS0tLS0t LS0tLS0tLSsKICAgICAgICAgICAgIHwgICB8ICAgS2V5KHMpICAgICAgfCAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0tLSsgICBTcGVjaWZpYyAgICAg ICAgIHwKICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIFJvdXRpbmdQcm90b2Nv bCAgfAogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24g ICB8CiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICBTZWN1cml0eSAgICAgICAg IHwKICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIE1lY2hhbmlzbSAgICAgICAg fAogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CgoKICAgICAgICAgICAgICAgRmlndXJlIDE6IEF1dG9tYXRpYyBLZXkgTWFuYWdlbWVudCBGcmFt ZXdvcmsKCiAgIEVhY2ggZWxlbWVudCBvZiB0aGUgZnJhbWV3b3JrIGlzIGRlc2NyaWJlZCBoZXJl OgoKCiAgIG8gIFJvdXRpbmcgUHJvdG9jb2wgLSAgUm91dGluZyBwcm90b2NvbCBzZWN1cml0eSBt ZWNoYW5pc20gLSBJbiBlYWNoCiAgICAgICAgICAgY2FzZSwgdGhlIFJvdXRpbmcgUHJvdG9jb2wg d2lsbCBjb250YWluIGEgbWVjaGFuaXNtIGZvciB1c2luZwogICAgICAgICAgIHNlc3Npb24ga2V5 cyBpbiB0aGVpciBzZWN1cml0eSBvcHRpb24uICBXaGVuIHRoZSBSb3V0aW5nCiAgICAgICAgICAg UHJvdG9jb2wgdXNlcyBhIHRyYW5zcG9ydCBzdWJzdHJhdGUsIGUuZy4gdGhlIHdheSBCR1AsIExE UAogICAgICAgICAgIGFuZCBNU0RQIHVzZSBUQ1AsIHRoZW4gdGhpcyBhcHBsaWVzIHRvIHRoZSBz ZWN1cml0eSBtZWNoYW5pc20KCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBN YXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMjddCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoK ICAgICAgICAgICB0aGUgaW5jbHVkZXMgdGhhdCBzdWJzdHJhdGUuCgogICBvICBLZXlTdG9yZSAt ICAgRWFjaCBpbXBsZW1lbnRhdGlvbiB3aWxsIGFsc28gY29udGFpbiBhIHByb3RvY29sCiAgICAg ICAgICAgaW5kZXBlbmRlbnQgbWVjaGFuaXNtIGZvciBzdG9yaW5nIGtleXMsIGNhbGxlZCBLZXlT dG9yZS4gIFRoZQogICAgICAgICAgIEtleVN0b3JlIHdpbGwgaGF2ZSBtdWx0aXBsZSBkaWZmZXJl bnQgbG9naWNhbCBjb250YWluZXJzLCBvbmUKICAgICAgICAgICBjb250YWluZXIgZm9yIGVhY2gg c2Vzc2lvbiBrZXkgdGhhdCBhbnkgZ2l2ZW4gUm91dGluZwogICAgICAgICAgIFByb3RvY29sIHdp bGwgbmVlZC4gIEtleXMgc3RvcmVkIGhlcmUgbWF5IGJlIGEgUGVlciBLZXkgb3IgYQogICAgICAg ICAgIFRyYWZmaWMgS2V5LiBUaGVyZSBtYXkgYWxzbyBiZSBhc3NvY2lhdGVkIHBhcmFtZXRlcnMg YXMKICAgICAgICAgICByZXF1aXJlZCBieSB0aGUgU0EgZm9yIGFueSBnaXZlbiBSb3V0aW5nIFBy b3RvY29sLgoKICAgbyAgUGVlciBLZXkgIEEga2V5IHVzZWQgYmV0d2VlbiBwZWVycyBmcm9tIHdo aWNoIGEgdHJhZmZpYyBrZXkgaXMKICAgICAgICAgICBkZXJpdmVkLiAgQW4gZXhhbXBsZSBpcyBh IFBTSy4KCiAgIG8gIFRyYWZmaWMgS2V5ICBUaGUgYWN0dWFsIGtleSB1c2VkIG9uIGVhY2ggcGFj a2V0IG9mIGEgbWVzc2FnZS4KICAgICAgICAgICBUaGlzIGtleSBtYXkgYmUgZGVyaXZlZCBmcm9t IHRoZSBrZXkgZXhpc3RpbmcgaW4gdGhlCiAgICAgICAgICAgS2V5U3RvcmUuICBUaGlzIHdpbGwg ZGVwZW5kIG9uIHdoZXRoZXIgdGhlIGtleSBpbiBLZXlTdG9yZQogICAgICAgICAgIHdhcyBhIG1h bnVhbCBQU0sgZm9yIHRoZSBwZWVycywgb3Igd2hldGhlciBhIGNvbm5lY3Rpb24tYXdhcmUKICAg ICAgICAgICBLTVAgY3JlYXRlZCB0aGUga2V5LiAgRnVydGhlciwgaXQgd2lsbCBiZSBjb25uZWN0 aW9uCiAgICAgICAgICAgc3BlY2lmaWMsIHNvIGFzIHRvIHByb3ZpZGUgaW50ZXItIGFuZCBpbnRy YS1jb25uZWN0aW9uIHJlcGxheQogICAgICAgICAgIHByb3RlY3Rpb24uCgogICBvICBSb3V0aW5n UHJvdG9jb2wtS2V5U3RvcmUgQVBJIC0gICBUaGVyZSB3aWxsIGJlIGFuIEFQSSBmb3IgUm91dGlu ZwogICAgICAgICAgIFByb3RvY29sIHRvIHJldHJpZXZlIChvciByZWNlaXZlOyBpdCBjb3VsZCBi ZSBhIHB1c2ggb3IgYQogICAgICAgICAgIHB1bGwpIHRoZSBrZXlzIGZyb20gdGhlIEtleVN0b3Jl LiAgVGhpcyB3aWxsIGVuYWJsZQogICAgICAgICAgIGltcGxlbWVudGVycyB0byByZXVzZSB0aGUg c2FtZSBBUEkgY2FsbHMgZm9yIGFsbCB0aGVpcgogICAgICAgICAgIFJvdXRpbmcgUHJvdG9jb2xz LiAgVGhlIEFQSSB3aWxsIG5lY2Vzc2FyaWx5IGluY2x1ZGUgZmFjaWxpdHkKICAgICAgICAgICB0 byByZXRyaWV2ZSBvdGhlciBTQSBwYXJhbWV0ZXJzIHJlcXVpcmVkIGZvciB0aGUgY29uc3RydWN0 aW9uCiAgICAgICAgICAgb2YgdGhlIFJvdXRpbmcgUHJvdG9jb2wncyBwYWNrZXRzLCBsaWtlIGtl eSBJRHMgb3Iga2V5CiAgICAgICAgICAgbGlmZXRpbWVzLCBldGMuCgogICBvICBLTVAgLSAgIFRo ZXJlIHdpbGwgYmUgYW4gYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50IHByb3RvY29sLCBLTVAuCiAg ICAgICAgICAgVGhpcyBLTVAgd2lsbCBydW4gYmV0d2VlbiB0aGUgcGVlcnMuICBUaGUgS01QIHNl cnZlcyBhcyBhCiAgICAgICAgICAgcHJvdGVjdGVkIGNoYW5uZWwgYmV0d2VlbiB0aGUgcGVlcnMs IHRocm91Z2ggd2hpY2ggdGhleSBjYW4KICAgICAgICAgICBuZWdvdGlhdGUgYW5kIHBhc3MgaW1w b3J0YW50IGRhdGEgcmVxdWlyZWQgdG8gZXhjaGFuZ2UgcHJvb2YKICAgICAgICAgICBvZiBrZXkg aWRlbnRpZmllcnMsIGRlcml2ZSBzZXNzaW9uIGtleXMsIGRldGVybWluZSByZS1rZXlpbmcsCiAg ICAgICAgICAgc3luY2hyb25pemUgdGhlaXIga2V5aW5nIHN0YXRlLCBzaWduYWwgdmFyaW91cyBr ZXlpbmcgZXZlbnRzLAogICAgICAgICAgIG5vdGlmeSB3aXRoIGVycm9yIG1lc3NhZ2VzLCBldGMu ICBBcyBhbiBhbmFsb2d5LCBpbiB0aGUgSVBzZWMKICAgICAgICAgICBwcm90b2NvbCAoUkZDNDMw MSBbUkZDNDMwMV0sIFJGQzQzMDMgW1JGQzQzMDNdIGFuZCBSRkM0MzA2CiAgICAgICAgICAgW1JG QzQzMDZdKSBJS0V2MiBpcyB0aGUgS01QIHRoYXQgcnVucyBiZXR3ZWVuIHRoZSB0d28gcGVlcnMs CiAgICAgICAgICAgd2hpbGUgQUggYW5kIEVTUCBhcmUgdHdvIGRpZmZlcmVudCBiYXNlIHByb3Rv Y29scyB0aGF0IHRha2UKICAgICAgICAgICBzZXNzaW9uIGtleXMgZnJvbSBJS0V2MiBhbmQgdXNl IHRoZW0gaW4gdGhlaXIgdHJhbnNtaXNzaW9ucy4KICAgICAgICAgICBJbiB0aGUgYW5hbG9neSwg dGhlIFJvdXRpbmcgUHJvdG9jb2wsIHNheSBCR1AgYW5kIExEUCwgYXJlCiAgICAgICAgICAgYW5h bG9nb3VzIHRvIEVTUCBhbmQgQUgsIHdoaWxlIHRoZSBLTVAgaXMgYW5hbG9nb3VzIHRvIElLRXYy CiAgICAgICAgICAgaXRzZWxmLgoKCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhw aXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAy MDA5CgoKCiAgIG8gIFJvdXRpbmdQcm90b2NvbC1LTVAgQVBJIC0gICBUaGVyZSB3aWxsIGJlIGFu IEFQSSBmb3IgdGhlIFJvdXRpbmcKICAgICAgICAgICBQcm90b2NvbCB0byByZXF1ZXN0IGEgc2Vz c2lvbiBrZXkgb2YgdGhlIEtNUCwgYW5kIGJlIG5vdGlmaWVkCiAgICAgICAgICAgd2hlbiB0aGUg a2V5cyBhcmUgYXZhaWxhYmxlIGZvciBpdC4gIFRoZSBBUEkgd2lsbCBhbHNvCiAgICAgICAgICAg Y29udGFpbiBhIG1lY2hhbmlzbSBmb3IgdGhlIEtNUCB0byBub3RpZnkgdGhlIFJvdXRpbmcKICAg ICAgICAgICBQcm90b2NvbCB0aGF0IHRoZXJlIGFyZSBuZXcga2V5cyB0aGF0IGl0IG11c3Qgbm93 IHVzZSwgZXZlbgogICAgICAgICAgIGlmIGl0IGRpZG4ndCByZXF1ZXN0IHRob3NlIGtleXMuICBU aGUgQVBJIHdpbGwgYWxzbyBpbmNsdWRlIGEKICAgICAgICAgICBtZWNoYW5pc20gZm9yIHRoZSBL TVAgdG8gcmVjZWl2ZSByZXF1ZXN0cyBmb3Igc2Vzc2lvbiBrZXlzCiAgICAgICAgICAgYW5kIG90 aGVyIHBhcmFtZXRlcnMgZnJvbSB0aGUgcm91dGluZyBwcm90b2NvbC4gIFRoZSBLTVAgd2lsbAog ICAgICAgICAgIGFsc28gYmUgYXdhcmUgb2YgdGhlIHZhcmlvdXMgUm91dGluZyBQcm90b2NvbHMg YW5kIGVhY2ggb2YKICAgICAgICAgICB0aGVpciB1bmlxdWUgcGFyYW1ldGVycyB0aGF0IG5lZWQg dG8gYmUgbmVnb3RpYXRlZCBhbmQKICAgICAgICAgICByZXR1cm5lZC4KCiAgIG8gIEtNUC1LZXlT dG9yZSBBUEkgLSAgIFRoZXJlIHdpbGwgYmUgYW4gQVBJIGZvciB0aGUgS01QIHRvIHBsYWNlCiAg ICAgICAgICAga2V5cyBhbmQgcGFyYW1ldGVycyBpbnRvIHRoZSBLZXlTdG9yZSBhZnRlciB0aGVp ciBuZWdvdGlhdGlvbgogICAgICAgICAgIGFuZCBkZXJpdmF0aW9uIHdpdGggdGhlIG90aGVyIHBl ZXIuICBUaGlzIHdpbGwgZW5hYmxlIHRoZQogICAgICAgICAgIGltcGxlbWVudGVycyB0byByZXVz ZSB0aGUgc2FtZSBjYWxscyBmb3IgbXVsdGlwbGUgS01QcyB0aGF0CiAgICAgICAgICAgbWF5IGJl IG5lZWRlZCB0byBhZGRyZXNzIHRoZSB2YXJpb3VzIGNhdGVnb3JpZXMgb2YgUm91dGluZwogICAg ICAgICAgIFByb3RvY29scyBhcyBkZXNjcmliZWQgaW4gdGhlIHNlY3Rpb24gZGVmaW5pbmdjYXRl Z29yaWVzCiAgICAgICAgICAgKFNlY3Rpb24gMykuCgoKICAgW2FmdGVyIHdyaXRpbmcgdGhpcyBh bGwgdXAsIEknbSBub3Qgc3VyZSB3ZSByZWFsbHkgbmVlZCB0aGUga2V5X3N0b3JlCiAgIGluIHRo ZSBtaWRkbGUuICBBcyBsb25nIGFzIHdlIHN0YW5kYXJkaXplIGZ1bGx5IGFsbCB0aGUgY2FsbHMg bmVlZGVkCiAgIGZyb20gYW55IFJvdXRpbmcgUHJvdG9jb2wgdG8gYW55IEtNUCwgdGhlbiB0aGVy ZSBjYW4gYmUgYSBnZW5lcmljCiAgIGhhbmQtZG93biBmdW5jdGlvbiBmcm9tIHRoZSBLTVAgdG8g dGhlIFJvdXRpbmcgUHJvdG9jb2wgd2hlbiB0aGUga2V5CiAgIGFuZCBwYXJhbWV0ZXJzIGFyZSBy ZWFkeS4gIExldCdzIHNsZWVwIG9uIGl0Ll0KCiAgIFt3aWxsIG5lZWQgc3RhdGUgbWFjaGluZXMg YW5kIGZ1bmN0aW9uIGNhbGxzIGZvciB0aGVzZSBBUElzLCBhcyBvbmUKICAgb2YgdGhlIHdvcmsg aXRlbXMuICBJbiBlc3NlbmNlLCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgY29yZSB0ZWFtIHRvCiAg IGRldmVsb3AgdGhlIEFQSXMgb3V0IGNvbXBsZXRlbHkgaW4gb3JkZXIgZm9yIHRoZSBSb3V0aW5n IFByb3RvY29sCiAgIHRlYW1zIHRvIHVzZSB0aGVtLiAgTmVlZCB0byBnZXQgdGhpcyB0ZWFtIGdv aW5nIGFzYXAuXQoKCiAgIG8gSWRlbnRpZmllcnMgLSAgIEEgS01QIGlzIGZlZCBieSBpZGVudGl0 aWVzLiAgVGhlIGlkZW50aXRpZXMgYXJlCiAgICAgICAgICAgdGV4dCBzdHJpbmdzIHVzZWQgYnkg dGhlIHBlZXJzIHRvIGluZGljYXRlIHRvIGVhY2ggb3RoZXIgdGhhdAogICAgICAgICAgIGVhY2gg YXJlIGtub3duIHRvIHRoZSBvdGhlciwgYW5kIGF1dGhvcml6ZWQgdG8gZXN0YWJsaXNoCiAgICAg ICAgICAgY29ubmVjdGlvbnMuICBUaG9zZSBpZGVudGl0aWVzIG11c3QgYmUgcmVwcmVzZW50ZWQg aW4gc29tZQogICAgICAgICAgIHN0YW5kYXJkIHN0cmluZyBmb3JtYXQsIGUuZy4gYW4gSVAgYWRk cmVzcyAtLSBlaXRoZXIgdjQgb3IKICAgICAgICAgICB2NiwgYW4gRlFETiwgYW4gUkZDIDgyMiBl bWFpbCBhZGRyZXNzLCBhIENvbW1vbiBOYW1lIFtSRkMKICAgICAgICAgICBQS0ldLCBldGMuICBO b3RlIHRoYXQgZXZlbiB0aG91Z2ggcm91dGVycyBkbyBub3Qgbm9ybWFsbHkKICAgICAgICAgICBo YXZlIGVtYWlsIGFkZHJlc3Nlcywgb25lIGNvdWxkIHVzZSBhbiBSRkMgODIyIGVtYWlsIGFkZHJl c3MKICAgICAgICAgICBzdHJpbmcgYXMgYSBmb3JtYXR0ZWQgaWRlbnRpZmllciBmb3IgYSByb3V0 ZXIuICBUaGV5IHdvdWxkIGRvCiAgICAgICAgICAgc28gc2ltcGx5IGJ5IHB1dHRpbmcgdGhlIHJv dXRlcidzIHJlZmVyZW5jZSBudW1iZXIgb3IgbmFtZS0KICAgICAgICAgICBjb2RlIGFzIHRoZSAi TkFNRSIgcGFydCBvZiB0aGUgYWRkcmVzcywgbGVmdCBvZiB0aGUgIkAiCiAgICAgICAgICAgc3lt Ym9sLiAgVGhleSB3b3VsZCB0aGVuIHBsYWNlIHNvbWUgbG9jYXRpb25hbCBjb250ZXh0IGluIHRo ZQogICAgICAgICAgICJET01BSU4iIHBhcnQgb2YgdGhlIHN0cmluZywgcmlnaHQgb2YgdGhlICJA IiBzeW1ib2wuICBBbgogICAgICAgICAgIGV4YW1wbGUgd291bGQgYmUgInJ0cjAyMTBAc2YuY2Eu dXMuY29tcGFueS5jb20iLiAgVGhpcwoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBp cmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAyOV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIw MDkKCgogICAgICAgICAgIGRvY3VtZW50IGRvZXMgbm90IHN1Z2dlc3QgdGhpcyBzdHJpbmcgdmFs dWUgYXQgYWxsLiAgSW5zdGVhZCwKICAgICAgICAgICB0aGUgY29uY2VwdCBpcyB1c2VkIG9ubHkg dG8gY2xhcmlmeSB0aGF0IHRoZSB0eXBlIG9mIHN0cmluZwogICAgICAgICAgIGVtcGxveWVkIGRv ZXMgbm90IG1hdHRlci4gIEl0IGFsc28gZG9lcyBub3QgbWF0dGVyIHdoYXQKICAgICAgICAgICBz cGVjaWZpYyB0ZXh0IHlvdSBjaG9zZSB0byBwbGFjZSBpbiB0aGF0IHN0cmluZyB0eXBlLiAgSXQK ICAgICAgICAgICBvbmx5IG1hdHRlcnMgdGhhdCB0aGUgdHlwZSBvZiBzdHJpbmcgLS0gYW5kIGl0 J3MgZm9ybWF0IC0tCiAgICAgICAgICAgbXVzdCBiZSBhZ3JlZWQgdXBvbiBieSB0aGUgdHdvIGVu ZHBvaW50cy4gIEZ1cnRoZXIsIHRoZQogICAgICAgICAgIHN0cmluZyBjYW4gYmUgdXNlZCBhcyBh biBpZGVudGlmaWVyIGluIHRoaXMgY29udGV4dCwgZXZlbiBpZgogICAgICAgICAgIHRoZSBzdHJp bmcgaXMgbm90IGFjdHVhbGx5IHByb3Zpc2lvbmVkIGluIGl0J3Mgc291cmNlIGRvbWFpbi4KICAg ICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGVtYWlsIGFkZHJlc3MgInJ0cjAyMTBAc2YuY2EudXMu Y29tcGFueS5jb20iCiAgICAgICAgICAgbWF5IG5vdCBhY3R1YWxseSBleGlzdCBhcyBhbiBlbWFp bCBhZGRyZXNzIGluIHRoYXQgZG9tYWluLAogICAgICAgICAgIGJ1dCB0aGF0IHN0cmluZyBvZiBj aGFyYWN0ZXJzIG1heSBzdGlsbCBiZSB1c2VkIGFzIGFuCiAgICAgICAgICAgaWRlbnRpZmllciB0 eXBlKHMpIGluIHRoZSByb3V0aW5nIHByb3RvY29sIHNlY3VyaXR5IGNvbnRleHQuCiAgICAgICAg ICAgV2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhhdCB0aGUgY29tbXVuaXR5IGRlY2lkZSBvbiBhIHNt YWxsIGJ1dAogICAgICAgICAgIGZsZXhpYmxlIHNldCBvZiBJZGVudGlmaWVycyB0aGV5IHdpbGwg YWxsIHN1cHBvcnQsIGFuZCB0aGF0CiAgICAgICAgICAgdGhleSBkZWNpZGUgb24gdGhlIGV4YWN0 IGZvcm1hdCBvZiB0aG9zZSBzdHJpbmcuICBUaGUgZm9ybWF0cwogICAgICAgICAgIHRoYXQgd2ls bCBiZSB1c2VkIG11c3QgYmUgc3RhbmRhcmRpemVkIGFuZCBtdXN0IGJlIHNlbnNpYmxlCiAgICAg ICAgICAgZm9yIHRoZSByb3V0aW5nIGluZnJhc3RydWN0dXJlLgoKICAgbyAgSWRlbnRpdHkgUHJv b2YgLSAgIE9uY2UgdGhlIGZvcm0gb2YgaWRlbnRpdHkgaXMgZGVjaWRlZCwgdGhlbgogICAgICAg ICAgIHRoZXJlIG11c3QgYmUgYSBjcnlwdG9ncmFwaGljIHByb29mIG9mIHRoYXQgaWRlbnRpdHks IHRoYXQKICAgICAgICAgICB0aGUgcGVlciByZWFsbHkgaXMgd2hvIHRoZXkgYXNzZXJ0IHRoZW1z ZWx2ZXMgdG8gYmUuICBQcm9vZgogICAgICAgICAgIG9mIGlkZW50aXR5IGNhbiBiZSBhcnJhbmdl ZCBiZXR3ZWVuIHRoZSBwZWVycyBpbiBhIGZldyB3YXlzLAogICAgICAgICAgIGZvciBleGFtcGxl IHByZS1zaGFyZWQga2V5cywgcmF3IGFzc3ltZXRyaWMga2V5cywgb3IgYSBtb3JlCiAgICAgICAg ICAgdXNlci1mcmllbmRseSByZXByZXNlbnRhdGlvbiBvZiBhc3N5bWV0cmljIGtleXMsIGxpa2Ug YQogICAgICAgICAgIGNlcnRpZmljYXRlLiAgQ2VydGlmaWNhdGVzIGNhbiBiZSB1c2VkIGluIGEg d2F5IHJlcXVpcmluZyBubwogICAgICAgICAgIGFkZGl0aW9uYWwgc3VwcG9ydGluZyBzeXN0ZW1z IC0tIGUuZy4gcHVibGljIGtleXMgZm9yIGVhY2gKICAgICAgICAgICBwZWVyIGNhbiBiZSBtYWlu dGFpbmVkIGxvY2FsbHkgZm9yIHZlcmlmaWNhdGlvbiB1cG9uIGNvbnRhY3QuCiAgICAgICAgICAg Q2VydGlmaWNhdGUgbWFuYWdlbWVudCBjYW4gYmUgbWFkZSBtb3JlIHNpbXBsZSBhbmQgc2NhbGFi bGUKICAgICAgICAgICB3aXRoIHRoZSB1c2UgbWlub3IgYWRkaXRpb25hbCBzdXBwb3J0aW5nIHN5 c3RlbXMsIGFzIGlzIHRoZQogICAgICAgICAgIGNhc2Ugd2l0aCBzZWxmLXNpZ25lZCBjZXJ0aWZp Y2F0ZXMgYW5kIGEgZmxhdCBmaWxlIGxpc3Qgb2YKICAgICAgICAgICAiYXBwcm92ZWQgdGh1bWJw cmludHMiLiAgU2VsZi1zaWduZWQgY2VydGlmaWNhdGVzIHdpbGwgaGF2ZQogICAgICAgICAgIHNv bWV3aGF0IGxvd2VyIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhbiBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkKICAgICAgICAgICBzaWduZWQgY2VydGlmaWNhdGVzIFtSRkMgQ2VydHNdLiAgVGhlIHVzZSBv ZiB0aGVzZSBkaWZmZXJlbnQKICAgICAgICAgICBpZGVudGl0eSBwcm9vZnMgdmFyeSBpbiBlYXNl IG9mIGRlcGxveW1lbnQsIGVhc2Ugb2Ygb25nb2luZwogICAgICAgICAgIG1hbmFnZW1lbnQsIHN0 YXJ0dXAgZWZmb3J0LCBvbmdvaW5nIGVmZm9ydCBhbmQgbWFuYWdlbWVudCwKICAgICAgICAgICBz ZWN1cml0eSBzdHJlbmd0aCwgYW5kIGNvbnNlcXVlbmNlcyBmcm9tIGxvc3Mgb2Ygc2VjcmV0cyBm cm9tCiAgICAgICAgICAgb25lIHBhcnQgb2YgdGhlIHN5c3RlbSB0byB0aGUgcmVzdCBvZiB0aGUg c3lzdGVtLiAgRm9yCiAgICAgICAgICAgZXhhbXBsZSwgdGhleSBkaWZmZXIgaW4gcmVzaXN0YW5j ZSB0byBhIHNlY3VyaXR5IGJyZWFjaCwgYW5kCiAgICAgICAgICAgdGhlIGVmZm9ydCByZXF1aXJl ZCB0byByZW1lZGlhdGUgdGhlIHdob2xlIHN5c3RlbSBpbiB0aGUKICAgICAgICAgICBldmVudCBv ZiBzdWNoIGEgYnJlYWNoLiAgVGhlIHBvaW50IGhlcmUgaXMgdGhhdCB0aGVyZSBhcmUKICAgICAg ICAgICBvcHRpb25zLCBtYW55IG9mIHdoaWNoIGFyZSBxdWl0ZSBzaW1wbGUgdG8gZW1wbG95IGFu ZCBkZXBsb3kuCgogICBvICBQcm9maWxlcyAtICAgT25jZSB0aGUgS01QLCBJZGVudGlmaWVycyBh bmQgUHJvb2ZzIG1lY2hhbmlzbXMgYXJlCiAgICAgICAgICAgY29udmVyZ2VkIHVwb24sIHRoZXkg bXVzdCBiZSBjbGVhcmx5IHByb2ZpbGVkIGZvciBlYWNoCiAgICAgICAgICAgUm91dGluZyBQcm90 b2NvbCwgc28gdGhhdCBpbXBsZW1lbnRvcnMgYW5kIGRlcGxveWVycyBhbGlrZQogICAgICAgICAg IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCBwaWVjZXMgb2YgdGhlIHNvbHV0aW9uLCBhbmQgY2Fu IGhhdmUKICAgICAgICAgICBzaW1pbGFyIGNvbmZpZ3VyYXRpb25zIGFuZCBpbnRlcm9wZXJhYmls aXR5IGFjcm9zcyBtdWx0aXBsZQogICAgICAgICAgIHZlbmRvcnMnIGRldmljZXMsIHNvIGFzIHRv IHJlZHVjZSBtYW5hZ2VtZW50IGRpZmZpY3VsdHkuICBUaGUKCgoKTGVib3ZpdHogJiAgICAgICAg ICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMzBdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAg ICBOb3ZlbWJlciAyMDA5CgoKICAgICAgICAgICBwcm9maWxlcyBTSE9VTEQgYWxzbyBwcm92aWRl IGd1aWRhbmNlIG9uIHdoZW4gdG8gdXNlIHdoaWNoCiAgICAgICAgICAgdmFyaW91cyBjb21iaW5h dGlvbnMgb2Ygb3B0aW9ucy4gIFRoaXMgd2lsbCwgYWdhaW4sIHNpbXBsaWZ5CiAgICAgICAgICAg dXNlIGFuZCBpbnRlcm9wZXJhYmlsaXR5LgoKICAgSW4gYWRkaXRpb24gdG8gb3RoZXIgYnVzaW5l c3MsIGFkbWluaXN0cmF0aXZlLCBhbmQgb3BlcmF0aW9uYWwgdGVybXMKICAgdGhleSBtdXN0IGFs cmVhZHkgZXhjaGFuZ2UgcHJpb3IgdG8gZm9ybWluZyBmaXJzdCBhZGphY2VuY2llcywgaXQgaXMK ICAgYXNzdW1lZCB0aGF0IHR3byBwYXJ0aWVzIGRlcGxveWluZyBtZXNzYWdlIGF1dGhlbnRpY2F0 aW9uIG9uIHRoZWlyCiAgIHJvdXRpbmcgcHJvdG9jb2wgd2lsbCBhbHNvIG5lZWQgdG8gZGVjaWRl IHVwb24gYWNjZXB0YWJsZSBzZWN1cml0eQogICBwYXJhbWV0ZXJzIGZvciB0aGUgY29ubmVjdGlv bi4gIFRoaXMgd2lsbCBpbmNsdWRlIHRoZSBmb3JtIGFuZAogICBjb250ZW50IG9mIHRoZSBpZGVu dGl0eSBlYWNoIHVzZSB0byByZXByZXNlbnQgdGhlIG90aGVyLiAgSXQgd2lsbAogICBhbHNvIGlu Y2x1ZGUgdGhlIHR5cGUgb2Yga2V5cyB0byBiZSB1c2VkLCBlLmcuICBQU0ssIHJhdyBhc3N5bWV0 cmljCiAgIGtleXMsIGNlcnRpZmljYXRlLiAgQW5kIGl0IHdpbGwgaW5jbHVkZSB0aGUgYWNjZXB0 YWJsZSBjcnlwdG9ncmFwaGljCiAgIGFsZ29yaXRobXMsIG9yIGFsZ29yaXRobSBzdWl0ZS4gIFRo aXMgYWdyZWVtZW50IGlzIG5lY2Vzc2FyeSBpbiBvcmRlcgogICBmb3IgZWFjaCB0byBwcm9wZXJs eSBjb25maWd1cmUgdGhlIGNvbm5lY3Rpb24gb24gdGhlaXIgcmVzcGVjdGl2ZQogICBkZXZpY2Vz LiAgVGhlIG1hbm5lciBpbiB3aGljaCB0aGV5IGFncmVlIHVwb24gYW5kIGV4Y2hhbmdlIHRoaXMK ICAgcG9saWN5IGluZm9ybWF0aW9uIGlzIG5vcm1hbGx5IHZpYSBwaG9uZSBjYWxsIG9yIHdyaXR0 ZW4gZXhjaGFuZ2UsCiAgIGFuZCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgS0FSUCBlZmZv cnQsIGJ1dCBhc3N1bWVkIHRvIGhhdmUKICAgb2NjdXJlZC4gIFdlIHRha2UgYXMgYSBnaXZlbiB0 aGF0IGVhY2ggcGFydHkga25vd3MgdGhlIGlkZW50aXR5IHR5cGVzCiAgIGFuZCB2YWx1ZXMsIGtl eSB0eXBlcyBhbmQgdmFsdWVzLCBhbmQgYWNjZXB0YWJsZSBjcnlwdG9ncmFwaGljCiAgIGFsZ29y aXRobXMgZm9yIGJvdGggdGhlaXIgb3duIGRldmljZSBhbmQgdGhlIHBlZXIgdGhhdCBmb3JtIHRo ZQogICBzZWN1cml0eSBwb2xpY3kgZm9yIGNvbmZpZ3VyYXRpb24gb24gdGhlaXIgZGV2aWNlLgoK ICAgQ29tbW9uIE1lY2hhbmlzbXMgLSBJbiBhcyBtdWNoIGFzIHRoZXkgZXhpc3QsIHRoZSBmcmFt ZXdvcmsgd2lsbAogICBjYXB0dXJlIG1lY2hhbmlzbXMgdGhhdCBjYW4gYmUgdXNlZCBjb21tb25s eSBub3Qgb25seSB3aXRoaW4gYQogICBwYXJ0aWN1bGFyIGNhdGVnb3J5IG9mIFJvdXRpbmcgUHJv dG9jb2wgYW5kIFJvdXRpbmcgUHJvdG9jb2wgdG8gS01QLAogICBidXQgYWxzbyBiZXR3ZWVuIFJv dXRpbmcgUHJvdG9jb2wgY2F0ZWdvcmllcy4gIEFnYWluLCB0aGUgZ29hbCBoZXJlCiAgIGlzIHNp bXBsaWZ5aW5nIHRoZSBpbXBsZW1lbnRhdGlvbnMgYW5kIHJ1bnRpbWUgY29kZSBhbmQgcmVzb3Vy Y2UKICAgcmVxdWlyZW1lbnRzLiAgVGhlcmUgaXMgYWxzbyBhIGdvYWwgaGVyZSBvZiBmYXZvcmlu ZyB3ZWxsIHZldHRlZCwKICAgcmV2aWV3ZWQsIG9wZXJhdGlvbmFsbHkgcHJvdmVuIHNlY3VyaXR5 IG1lY2hhbmlzbXMgb3ZlciBuZXdseSBicmV3ZWQKICAgbWVjaGFuaXNtcyB0aGF0IGFyZSBsZXNz IHdlbGwgdHJpZWQgaW4gdGhlIHdpbGQuCgo0LjQuICBXb3JrIEl0ZW1zIFBlciBSb3V0aW5nIFBy b3RvY29sCgogICBFYWNoIFJvdXRpbmcgUHJvdG9jb2wgd2lsbCBoYXZlIGEgdGVhbSAodGhlIFtS b3V0aW5nX1Byb3RvY29sXS1LQVJQCiAgIHRlYW0pIHdvcmtpbmcgb24gaW5jcmVtZW50YWxseSBp bXByb3ZpbmcgdGhlaXIgUm91dGluZyBQcm90b2NvbCdzCiAgIHNlY3VyaXR5LCBUaGVzZSB0ZWFt cyB3aWxsIGhhdmUgdGhlIGZvbGxvd2luZyBtYWluIHdvcmsgaXRlbXM6CgogICBQSEFTRSAxOgoK ICAgQ2hhcmFjdGVyaXplIHRoZSBSUAogICAgICBBc3Nlc3MgdGhlIFJvdXRpbmcgUHJvdG9jb2wg dG8gc2VlIHdoYXQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcwogICAgICBpdCBoYXMgdG9kYXku ICBEb2VzIGl0IG5lZWRzIHNpZ25pZmljYW50IGltcHJvdmVtZW50IHRvIGl0cwogICAgICBleGlz dGluZyBtZWNoYW5pc21zIG9yIG5vdD8gIFRoaXMgd2lsbCBpbmNsdWRlIGRldGVybWluaW5nIGlm CiAgICAgIG1vZGVybiwgc3Ryb25nIHNlY3VyaXR5IGFsZ29yaXRobXMgYW5kIHBhcmFtZXRlcnMg YXJlIHByZXNlbnQuCgoKCgoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1h eSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgoK ICAgRGVmaW5lIE9wdGltYWwgU3RhdGUKICAgICAgTGlzdCB0aGUgcmVxdWlyZW1lbnRzIGZvciB0 aGUgUm91dGluZyBQcm90b2NvbCdzIHNlc3Npb24ga2V5IHVzYWdlCiAgICAgIGFuZCBmb3JtYXQg dG8gY29udGFpbiB0byBtb2Rlcm4sIHN0cm9uZyBzZWN1cml0eSBhbGdvcml0aG1zIGFuZAogICAg ICBtZWNoYW5pc21zLCBwZXIgdGhlIFJlcXVpcmVtZW50cyAoU2VjdGlvbiA0LjIpIHNlY3Rpb24g YWJvdmUuICBUaGUKICAgICAgZ29hbCBoZXJlIGlzIHRvIGRldGVybWluZSB3aGF0IGlzIG5lZWRl ZCBmb3IgdGhleSBSb3V0aW5nIFByb3RvY29sCiAgICAgIGFsb25lIHRvIGJlIHVzZWQgc2VjdXJl bHkgd2l0aCBhdCBsZWFzdCBtYW51YWwga2V5cy4KCiAgIEdhcCBBbmFseXNpcwogICAgICBFbnVt ZXJhdGUgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBtb3ZlIGZyb20gaXRz CiAgICAgIGN1cnJlbnQgc2VjdXJpdHkgc3RhdGUsIHRoZSBmaXJzdCBidWxsZXQsIHRvIGl0cyBv cHRpbWFsIHN0YXRlLCBhcwogICAgICBsaXN0ZWQganVzdCBhYm92ZS4KCiAgIFRyYW5zaXRpb24g YW5kIERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMgIERvY3VtZW50IHRoZSBvcGVyYXRpb25hbAog ICAgICB0cmFuc2l0aW9uIHBsYW4gZm9yIG1vdmluZyBmcm9tIHRoZSBvbGQgdG8gdGhlIG5ldyBz ZWN1cml0eQogICAgICBtZWNoYW5pc20uICBXaWxsIGFkamFjZW5jaWVzIG5lZWQgdG8gYm91bmNl PyAgV2hhdCBuZXcgZWxlbWVudHMvCiAgICAgIHNlcnZlcnMvc2VydmljZXMgaW4gdGhlIGluZnJh c3RydWN0dXJlIHdpbGwgYmUgcmVxdWlyZWQ/ICBXaGF0IGlzCiAgICAgIGFuIGV4YW1wbGUgd29y ayBmbG93IHRoYXQgYW4gb3BlcmF0b3Igd2lsbCB0YWtlPyAgVGhlIGJlc3QKICAgICAgcG9zc2li bGUgY2FzZSBpcyBpZiB0aGUgYWRqYWNlbmN5IGRvZXMgbm90IGJyZWFrLCBidXQgdGhpcyBtYXkg bm90CiAgICAgIGFsd2F5cyBiZSBwb3NzaWJsZS4KCiAgIERlZmluZSwgQXNzaWduLCBEZXNpZ24K ICAgICAgQ3JlYXRlIGEgZGVsaXZlcmFibGVzIGxpc3Qgb2YgdGhlIGRlc2lnbiBhbmQgc3BlY2lm aWNhdGlvbiB3b3JrLAogICAgICB3aXRoIG1pbGVzdG9uZXMuICBEZWZpbmUgb3duZXJzLiAgUmVs ZWFzZSBhIGRvY3VtZW50KHMpCgoKICAgUEhBU0UgMjoKCiAgIEtNUCBBbmFseXNpcwogICAgICBS ZXZpZXcgcmVxdWlyZW1lbnRzIGZvciBLTVBzIFtSRkM/Pz8/XS4gIElkZW50aWZ5IGFueSBudWFu Y2VzIGZvcgogICAgICB0aGlzIHBhcnRpY3VsYXIgcHJvdG9jb2wncyBuZWVkcyBhbmQgaXRzIHVz ZSBjYXNlcyBmb3IgS01QLiAgTGlzdAogICAgICB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgdGhpcyBS b3V0aW5nIFByb3RvY29sIGhhcyBmb3IgYmVpbmcgYWJsZSB0bwogICAgICBiZSB1c2UgaW4gY29u anVuY3Rpb25zIHdpdGggYSBLTVAuICBEZWZpbmUgdGhlIG9wdGltYWwgc3RhdGUuCgogICBHYXAg QW5hbHlzaXMKICAgICAgRW51bWVyYXRlIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoaXMgcHJvdG9j b2wgdG8gbW92ZSBmcm9tIGl0cwogICAgICBjdXJyZW50IHNlY3VyaXR5IHN0YXRlIHRvIGl0cyBv cHRpbWFsIHN0YXRlLgoKICAgRGVmaW5lLCBBc3NpZ24sIERlc2lnbgogICAgICBDcmVhdGUgYSBk ZWxpdmVyYWJlbHMgbGlzdCBvZiB0aGUgZGVzaWduIGFuZCBzcGVjaWZpY2F0aW9uIHdvcmssCiAg ICAgIHdpdGggbWlsZXRzb25lcy4gIERlZmluZSBvd25lcnMuICBEbyB0aGUgZGVzaWduIGFuZCBk b2N1bWVudCB3b3JrCiAgICAgIGZvciBhIEtNUCB0byBiZSBhYmxlIHRvIGdlbmVyYXRlIHRoZSBS b3V0aW5nIFByb3RvY29sJ3Mgc2Vzc2lvbgogICAgICBrZXlzIGZvciB0aGUgcGFja2V0cyBvbiB0 aGUgd2lyZS4gIFRoZXNlIHdpbGwgYmUgdGhlIGFyZ3VtZW50cwogICAgICBwYXNzZWQgaW4gdGhl IEFQSSB0byB0aGUgS01QIGluIG9yZGVyIHRvIGJvb3RzdHJhcCB0aGUgc2Vzc2lvbgogICAgICBr ZXlzIHRvIHRoZSBSb3V0aW5nIFByb3RvY29sLgoKICAgVGhlcmUgd2lsbCBhbHNvIGJlIGEgdGVh bSBmb3JtZWQgdG8gd29yayBvbiB0aGUgYmFzZSBmcmFtZXdvcmsKICAgbWVjaGFuaXNtcyBmb3Ig ZWFjaCBvZiB0aGUgbWFpbiBjYXRlZ29yaWVzLCBpLmUuIHRoZSBibG9ja3MgYW5kIEFQSSdzCgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDMyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9h ZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIHJlcHJlc2VudGVkIGluIGZp Z3VyZSAxIChGaWd1cmUgMSkuCgo0LjUuICBQcm90b2NvbHMgaW4gQ2F0ZWdvcmllcwoKICAgVGhp cyBzZWN0aW9uIGdyb3VwcyB0aGUgUm91dGluZyBQcm90b2NvbHMgaW50byBsaWtlIGNhdGVnb3Jp ZXMsCiAgIGFjY29yZGluZyB0byBhdHRyaWJ1dGVzIHNldCBmb3J0aCBpbiBDYXRlZ29yaWVzIFNl Y3Rpb24gKFNlY3Rpb24gMykuCiAgIEVhY2ggZ3JvdXAgd2lsbCBoYXZlIGEgZGVzaWduIHRlYW0g dGFza2VkIHdpdGggaW1wcm92aW5nIHRoZSBzZWN1cml0eQogICBvZiB0aGUgUm91dGluZyBQcm90 b2NvbCBtZWNoYW5pc21zIGFuZCBkZWZpbmluZyB0aGUgS01QIHJlcXVpcmVtZW50cwogICBmb3Ig dGhlaXIgZ3JvdXAsIHRoZW4gcm9sbGluZyBib3RoIGludG8gYSByb2FkbWFwIGRvY3VtZW50IHVw b24gd2hpY2gKICAgdGhleSB3aWxsIGV4ZWN1dGUuCgogICBCR1AsIExEUCBhbmQgTVNEUAogICAg ICAgVGhlIFJvdXRpbmcgUHJvdG9jb2wncyB0aGF0IGZhbGwgaW50byB0aGUgY2F0ZWdvcnkgb2Yg dGhlIG9uZS10by0KICAgICAgIG9uZSBwZWVyaW5nIG1lc3NhZ2VzLCBhbmQgd2lsbCB1c2UgcGVl ciBrZXlpbmcgcHJvdG9jb2xzLCBBTkQgYXJlCiAgICAgICBhbGwgdHJhbnNtaXR0ZWQgb3ZlciBU Q1AgaW5jbHVkZSBCR1AgUkZDIDQyNzEgW1JGQzQyNzFdLCBMRFAKICAgICAgIFtSRkM1MDM2XSBh bmQgTVNEUCBbUkZDMzYxOF0uICBBIHRlYW0gd2lsbCB3b3JrIG9uIG9uZSBtZWNoYW5pc20KICAg ICAgIHRvIGNvdmVyIHRoZXNlIHRocmVlIHByb3RvY29scy4gIE11Y2ggb2YgdGhlIHdvcmsgb24g dGhlIFJvdXRpbmcKICAgICAgIFByb3RvY29sIHVwZGF0ZSBmb3IgaXRzIGV4aXN0aW5nIGF1dGhl bnRpY2F0aW9uIG1lY2hhbmlzbSBpcwogICAgICAgYWxyZWFkeSBvY2N1cmluZyBpbiB0aGUgVENQ TSBXb3JraW5nIEdyb3VwLCBvbiB0aGUgVENQLUFPCiAgICAgICBbSS1ELmlldGYtdGNwbS10Y3At YXV0aC1vcHRdIGRvY3VtZW50LCBhcyB3ZWxsIGFzIGl0cwogICAgICAgY3J5cHRvZ3JhcGh5LWhl bHBlciBkb2N1bWVudCwgVENQLUFPLUNSWVBUTyBbSS1ELmFvLWNyeXB0b10uICBUaGUKICAgICAg IGV4Y2VwdGlvbiBpcyB0aGUgbW9kZSB3aGVyZSBMRFAgaXMgdXNlZCBkaXJlY3RseSBvbiB0aGUg TEFOCiAgICAgICBbUkZDPz8/P10uICBUaGUgd29yayBmb3IgdGhpcyBtYXkgZ28gaW50byB0aGUg R3JvdXAga2V5aW5nCiAgICAgICBjYXRlZ29yeSAody8gT1NQRikgbWVudGlvbmVkIGJlbG93LgoK ICAgT1NQRiwgSVNJUywgYW5kIFJJUAogICAgICAgVGhlIFJvdXRpbmcgUHJvdG9jb2xzIHRoYXQg ZmFsbCBpbnRvIHRoZSBjYXRlZ29yeSBHcm91cCBrZXlpbmcKICAgICAgIHdpdGggb25lLXRvLW1h bnkgcGVlcmluZyBtZXNzYWdlcyBpbmNsdWRlcyBPU1BGIFtSRkMyMzI4XSwgSVNJUwogICAgICAg W1JGQzExOTVdIGFuZCBSSVAgW1JGQzI0NTNdLiAgTm90IHN1cnByaXNpbmdseSwgYWxsIHRoZXNl IHJvdXRpbmcKICAgICAgIHByb3RvY29scyBoYXZlIHR3byBvdGhlciB0aGluZ3MgaW4gY29tbW9u LiAgRmlyc3QsIHRoZXkgYXJlIHJ1bgogICAgICAgb24gYSBjb21iaW5hdGlvbiBvZiB0aGUgT1NJ IGRhdGFsaW5rIGxheWVyIDIsIGFuZCB0aGUgT1NJIG5ldHdvcmsKICAgICAgIGxheWVyIDMuICBC eSB0aGlzIHdlIG1lYW4gdGhhdCB0aGV5IGhhdmUgYSBjb21wb25lbnQgb2YgaG93IHRoZQogICAg ICAgcm91dGluZyBwcm90b2NvbCB3b3JrcyB3aGljaCBpcyBzcGVjaWZpZWQgaW4gTGF5ZXIgMiBh cyB3ZWxsIGFzCiAgICAgICBpbiBMYXllciAzLiAgU2Vjb25kLCB0aGV5IGFyZSBhbGwgaW50ZXJu YWwgZ2F0ZXdheSBwcm90b2NvbHMsIG9yCiAgICAgICBJR1BzLiAgVGhlIGtleWluZyBtZWNoYW5p c21zIGFuZCB1c2Ugd2lsbCBiZSBtdWNoIG1vcmUKICAgICAgIGNvbXBsaWNhdGVkIHRvIGRlZmlu ZSBmb3IgdGhlc2UgdGhhbiBmb3IgYSBvbmUtdG8tb25lIG1lc3NhZ2luZwogICAgICAgcHJvdG9j b2wuCgogICBCRkQKICAgICAgIEJlY2F1c2UgaXQgaXMgbGVzcyBvZiBhIHJvdXRpbmcgcHJvdG9j b2wsIHBlciBzZSwgYW5kIG1vcmUgb2YgYQogICAgICAgcGVlciBhbGl2ZW5lc3MgZGV0ZWN0aW9u IG1lY2hhbmlzbSwgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nCiAgICAgICBEZXRlY3Rpb24gKEJG RCkgW1JGQz8/Pz9dIHdpbGwgaGF2ZSBpdHMgb3duIHRlYW0uCgogICBSU1ZQIFtSRkM/Pz8/XSwg UlNWUC1URSBbUkZDPz8/P10sIGFuZCBQQ0UKCgoKCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDMzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwOQoKCiAgICAgICBUaGVzZSB0aHJlZSBwcm90b2NvbHMgd2lsbCBiZSBoYW5kbGVk IHRvZ2V0aGVyLiBbd2hhdCBtb3JlCiAgICAgICBjaGFyYWN0ZXJpc2F0aW9uIHNob3VsZCB3ZSBn aXZlIGhlcmU/ICBSb3V0aW5nIEFEJ3MsIHByb3ZpZGUgdGV4dAogICAgICAgcGxzP10KCiAgIFBJ TS1TTSBhbmQgUElNLURNCiAgICAgICBGaW5hbGx5LCB0aGUgbXVsdGljYXN0IHByb3RvY29scyBv ZiBQSU0tU00gW1JGQzQ2MDFdIGFuZCBQSU0tRE0KICAgICAgIFtSRkMzOTczXSB3aWxsIGJlIGhh bmRsZWQgdG9nZXRoZXIuICBQSU0tU00gbXVsdGljYXN0cyByb3V0aW5nCiAgICAgICBpbmZvcm1h dGlvbiAoSGVsbG8sIEpvaW4vUHJ1bmUsIEFzc2VydCkgb24gYSBsaW5rLWxvY2FsIGJhc2lzLAog ICAgICAgdXNpbmcgYSBkZWZpbmVkIG11bHRpY2FzdCBhZGRyZXNzLiAgSW4gYWRkaXRpb24sIGl0 IHNwZWNpZmllcwogICAgICAgdW5pY2FzdCBjb21tdW5pY2F0aW9uIGZvciBleGNoYW5nZSBvZiBp bmZvcm1hdGlvbiAoUmVnaXN0ZXIsCiAgICAgICBSZWdpc3Rlci1TdG9wKSBiZXR3ZWVuIHRoZSBy b3V0ZXIgY2xvc2VzdCB0byBhIGdyb3VwIHNlbmRlciBhbmQKICAgICAgIHRoZSAicmVuZGV6dm91 cyBwb2ludCIgKFJQKS4gIFRoZSBSUCBpcyB0eXBpY2FsbHkgbm90ICJvbi1saW5rIgogICAgICAg Zm9yIGEgcGFydGljdWxhciByb3V0ZXIuICBXaGlsZSBtdWNoIHdvcmsgaGFzIGJlZW4gZG9uZSBv bgogICAgICAgbXVsdGljYXN0IHNlY3VyaXR5IGZvciBhcHBsaWNhdGlvbi1sYXllciBncm91cHMs IGxpdHRsZSBoYXMgYmVlbgogICAgICAgZG9uZSB0byBhZGRyZXNzIHRoZSBwcm9ibGVtIG9mIG1h bmFnaW5nIGh1bmRyZWRzIG9yIHRob3VzYW5kcyBvZgogICAgICAgc21hbGwgb25lLXRvLW1hbnkg Z3JvdXBzIHdpdGggbGluay1sb2NhbCBzY29wZS4gIFN1Y2ggYW4KICAgICAgIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbSBzaG91bGQgYmUgY29uc2lkZXJlZCBhbG9uZyB3aXRoIHRoZQogICAgICAg cm91dGVyLXRvLVJlbmRlenZvdXMgUG9pbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLiAgVGhl IG1vc3QKICAgICAgIGltcG9ydGFudCBpc3N1ZSBpcyBlbnN1cmluZyB0aGF0IG9ubHkgdGhlICJh dXRob3JpemVkIG5laWdoYm9ycyIKICAgICAgIGdldCB0aGUga2V5cyBmb3IgKFMsRyksIHNvIHRo YXQgcm9ndWUgcm91dGVycyBjYW5ub3QgcGFydGljaXBhdGUKICAgICAgIGluIHRoZSBleGNoYW5n ZXMuICBBbm90aGVyIGlzc3VlIGlzIHRoYXQgc29tZSBvZiB0aGUKICAgICAgIGNvbW11bmljYXRp b24gbWF5IG9jY3VyIGludHJhLWRvbWFpbiwgZS5nLiB0aGUgbGluay1sb2NhbAogICAgICAgbWVz c2FnZXMgaW4gYW4gZW50ZXJwcmlzZSwgd2hpbGUgb3RoZXJzIGZvciB0aGUgc2FtZSAoKixHKSBt YXkKICAgICAgIG9jY3VyIGludGVyLWRvbWFpbiwgZS5nLiB0aGUgcm91dGVyLXRvLVJlbmRlenZv dXMgUG9pbnQgbWVzc2dlcwogICAgICAgbWF5IGJlIGZyb20gb25lIGVudGVycHJpc2UncyByb3V0 ZXIgdG8gYW5vdGhlci4gIE9uZSBwb3NzaWJsZQogICAgICAgc29sdXRpb24gcHJvcG9zZXMgYSBy ZWdpb24td2lkZSAibWFzdGVyIiBrZXkgc2VydmVyIChwb3NzaWJseQogICAgICAgcmVwbGljYXRl ZCksIGFuZCBvbmUgImxvY2FsIiBrZXkgc2VydmVyIHBlciBzcGVha2luZyByb3V0ZXIuCiAgICAg ICBUaGVyZSBpcyBubyBpc3N1ZSB3aXRoIHByb3BhZ2F0aW5nIHRoZSBtZXNzYWdlcyBvdXRzaWRl IHRoZSBsaW5rLAogICAgICAgYmVjYXVzZSBsaW5rLWxvY2FsIG1lc3NhZ2VzLCBieSBkZWZpbml0 aW9uLCBhcmUgbm90IGZvcndhcmRlZC4KICAgICAgIFRoaXMgc29sdXRpb24gaXMgb2ZmZXJlZCBv bmx5IGFzIGFuIGV4YW1wbGUgb2YgaG93IHdvcmsgbWF5CiAgICAgICBwcm9ncmVzczsgZnVydGhl ciBkaXNjdXNzaW9uIHNob3VsZCBvY2N1ciBpbiB0aGlzIHdvcmsgdGVhbS4KICAgICAgIFNwZWNp ZmljYXRpb24gb2YgYSBsaW5rLWxvY2FsIHByb3RlY3Rpb24gbWVjaGFuaXNtIGZvciBQSU0tU00K ICAgICAgIG9jY3VycmVkIGluIFJGQyA0NjAxIFtSRkM0NjAxXSwgYW5kIHRoaXMgd29yayBpcyBi ZWluZyB1cGRhdGVkIGluCiAgICAgICBQSU0tU00tTElOS0xPQ0FMIFtJLUQuaWV0Zi1waW0tc20t bGlua2xvY2FsXS4gIEhvd2V2ZXIsIHRoZSBLTVAKICAgICAgIHBhcnQgaXMgY29tcGxldGVseSB1 bnNwZWNpZmllZCwgYW5kIHdpbGwgcmVxdWlyZSB3b3JrIG91dHNpZGUgdGhlCiAgICAgICBleHBl cnRpc2Ugb2YgdGhlIFBJTSB3b3JraW5nIGdyb3VwIHRvIGFjY29tcGxpc2gsIHdoaWNoIGlzIHdo eQogICAgICAgdGhpcyByb2FkbWFwIGlzIGJlaW5nIGNyZWF0ZWQuCgogICBUaGVzZSBwcm90b2Nv bHMgYXJlIGRlZW1lZCBvdXQtb2Ytc2NvcGUgZm9yIHRoaXMgY3VycmVudCBpdGVyYXRpb24gb2YK ICAgdGhlIHdvcmsgcm9hZG1hcC4gIE9uY2UgYWxsIG9mIHRoZSBwcm90b2NvbHMgbGlzdGVkIGFi b3ZlIGhhdmUgaGFkCiAgIHRoZWlyIHdvcmsgY29tcGxldGVkLCBvciBhcmUgY2xlYXJseSB3aXRo aW4gc2l0ZSBvZiBjb21wbGV0aW9uLCB0aGVuCiAgIHRoZSBjb21tdW5pdHkgd2lsbCByZXZpc2l0 IHRoZSBuZWVkIGFuZCBpbnRlcmVzdCBmb3Igd29ya2luZyBvbgogICB0aGVzZToKCiAgIG8gIE1B TkVUCiAgIG8gIEZPUkNFUwoKICAgW25lZWQgdGV4dCBmcm9tIHJvdXRpbmcgQURzIG9uIHdoeSB0 aGVzZSBhcmUgb3V0IG9mIHNjb3BlXQoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBp cmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAzNF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIw MDkKCgo0LjYuICBQcmlvcml0ZXMKCiAgIFJlc291cmNlcyBmcm9tIGJvdGggdGhlIHJvdXRpbmcg YXJlYSBhbmQgdGhlIHNlY3VyaXR5IGFyZWEgd2lsbCBiZQogICBhcHBsaWVkIHRvIHdvcmsgb24g dGhlc2UgcHJvYmxlbSBzcGFjZXMgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4KICAgUmVhbGl6aW5n IHRoYXQgc3VjaCByZXNvdXJjZXMgYXJlIGZhciBmcm9tIHVubGltaXRlZCwgYSByYW5rIG9yZGVy CiAgIHByaW9yaXR5IGZvciBhZGRyZXNzaW5nIHRoZSB3b3JrIG9mIGluY3JlbWVudGFsbHkgc2Vj dXJpbmcgdGhlc2UKICAgZ3JvdXBzIG9mIHJvdXRpbmcgcHJvdG9jb2xzIGlzIHByb3ZpZGVkOgoK ICAgbyAgUHJpb3JpdHkgMSAtIEJHUCAvIExEUCAvIE1TRFAgLSBhbG1vc3QgZG9uZSB3aXRoIFBo YXNlIDEgb24gdGhlc2UsCiAgICAgIHZpYSBUQ1AtQU8gW0ktRC5pZXRmLXRjcG0tdGNwLWF1dGgt b3B0XSAuCiAgIG8gIFByaW9yaXR5IDIgLSBQSU0tU00KICAgbyAgUHJpb3JpdHkgMyAtIE9TUEYg LyBJU0lTIC8gUklQCiAgIG8gIFByaW9yaXR5IDQgLSBCRkQKICAgbyAgUHJpb3JpdHkgNSAtIFJT VlAgYW5kIFJTVlAtVEUKCiAgIEJ5IGZhciB0aGUgbW9zdCBpbXBvcnRhbnQgZ3JvdXAgaXMgdGhl IFByaW9yaXR5IDEgZ3JvdXAgYXMgdGhlc2UgYXJlCiAgIHRoZSBwcm90b2NvbHMgdXNlZCBvbiB0 aGUgbW9zdCBwdWJsaWMgYW5kIGV4cG9zZWQgc2VnbWVudHMgb2YgdGhlCiAgIG5ldHdvcmtzLCBh dCB0aGUgcGVlcmluZyBwb2ludHMgYmV0d2VlbiBvcGVyYXRvcnMgYW5kIGJldHdlZW4KICAgb3Bl cmF0b3JzIGFuZCB0aGVpciBjdXN0b21lcnMuICBCRkQsIGFzIGEgZGV0ZWN0aW9uIG1lY2hhbmlz bQogICB1bmRlcmx5aW5nIHRoZSBQcmlvcml0eSAxIHByb3RvY29scyBpcyB0aGVyZWZvcmUgc2Vj b25kLgoKCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgQXMgbWVudGlvbmVkIGluIHRo ZSBJbnRyb2R1Y3Rpb24gLCBSRkM0OTQ4IGlkZW50aWZpZXMgYWRkaXRpb25hbAogICBzdGVwcyBu ZWVkZWQgdG8gYWNoaWV2ZSB0aGUgb3ZlcmFsbCBnb2FsIG9mIGltcHJvdmluZyB0aGUgc2VjdXJp dHkgb2YKICAgdGhlIGNvcmUgcm91dGluZyBpbmZyYXN0cnVjdHVyZS4gIFRob3NlIGluY2x1ZGUg dmFsaWRhdGlvbiBvZiByb3V0ZQogICBvcmlnaW4gYW5ub3VuY2VtZW50cywgcGF0aCB2YWxpZGF0 aW9uLCBjbGVhbmluZyB1cCB0aGUgSVJSIGRhdGFiYXNlcwogICBmb3IgYWNjdXJhY3ksIGFuZCBv cGVyYXRpb25hbCBzZWN1cml0eSBwcmFjdGljaWVzIHRoYXQgcHJldmVudAogICByb3V0ZXJzIGZy b20gYmVpbmcgY29tcHJvbWlzZWQgZGV2aWNlcy4gIFRoZSBLQVJQIHdvcmsgaXMgYnV0IG9uZQog ICBzdGVwIGluIGEgbmVjZXNzYXJ5IHN5c3RlbSBvZiBzZWN1cml0eSBpbXByb3ZlbWVudHMuCgog ICBUaGUgc2VjdXJpdHkgb2YgY3J5cHRvZ3JhcGhpYy1iYXNlZCBzeXN0ZW1zIGRlcGVuZHMgb24g Ym90aCB0aGUKICAgc3RyZW5ndGggb2YgdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBjaG9z ZW4gYW5kIHRoZSBzdHJlbmd0aCBvZgogICB0aGUga2V5cyB1c2VkIHdpdGggdGhvc2UgYWxnb3Jp dGhtcy4gIFRoZSBzZWN1cml0eSBhbHNvIGRlcGVuZHMgb24KICAgdGhlIGVuZ2luZWVyaW5nIG9m IHRoZSBwcm90b2NvbCB1c2VkIGJ5IHRoZSBzeXN0ZW0gdG8gZW5zdXJlIHRoYXQKICAgdGhlcmUg YXJlIG5vIG5vbi1jcnlwdG9ncmFwaGljIHdheXMgdG8gYnlwYXNzIHRoZSBzZWN1cml0eSBvZiB0 aGUKICAgb3ZlcmFsbCBzeXN0ZW0uCgogICBDYXJlIHNob3VsZCBhbHNvIGJlIHRha2VuIHRvIGVu c3VyZSB0aGF0IHRoZSBzZWxlY3RlZCBrZXkgaXMKICAgdW5wcmVkaWN0YWJsZSwgYXZvaWRpbmcg YW55IGtleXMga25vd24gdG8gYmUgd2VhayBmb3IgdGhlIGFsZ29yaXRobQogICBpbiB1c2UuICBb UkZDNDA4Nl0gY29udGFpbnMgaGVscGZ1bCBpbmZvcm1hdGlvbiBvbiBib3RoIGtleQogICBnZW5l cmF0aW9uIHRlY2huaXF1ZXMgYW5kIGNyeXB0b2dyYXBoaWMgcmFuZG9tbmVzcy4KCiAgIEluIGFk ZGl0aW9uIHRvIHVzaW5nIGEgc3Rvbmcga2V5L1BTSyBvZiBhcHByb3ByaWF0ZSBsZW5ndGggYW5k CiAgIHJhbmRvbW5lc3MsIGRlcGxveWVycyBvZiBLQVJQIHByb3RvY29scyBTSE9VTEQgdXNlIGRp ZmZlcmVudCBrZXlzCiAgIGJldHdlZW4gZGlmZmVyZW50IHJvdXRpbmcgcGVlcnMgd2hlbmV2ZXIg b3BlcmF0aW9uYWxseSBwb3NzaWJsZS4KICAgUkZDMzU2MiBbUkZDMzU2Ml0gcHJvdmlkZXMgc29t ZSB2ZXJ5IHNvdW5kIGd1aWRhbmNlLiAgSXQgd2FzIG1lYW50CgoKCkxlYm92aXR6ICYgICAgICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDM1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAg ICAgTm92ZW1iZXIgMjAwOQoKCiAgIHNwZWNpZmljYWxseSBmb3IgdGhlIHVzZSBvZiBUQ1AgTUQ1 IGZvciBCR1AsIGJ1dCBpdCBpcyBtb3JlIG9yIGxlc3MKICAgYXBwbGljYWJsZSB0byBSb3V0aW5n IFByb3RvY29sIGF1dGhlbnRpY2F0aW9uIHdvcmsgdGhhdCB3b3VsZCByZXN1bHQKICAgZnJvbSBL QVJQLiAgSXQgc3RhdGVzIHRocmVlIG1haW4gcG9pbnRzOiAoMSkga2V5IGxlbmd0aHMgU0hPVUxE IGJlCiAgIGJldHdlZW4gMTIgYW5kIDI0IGJ5dGVzICh0aGlzIHdpbGwgdmFyeSBkZXBlbmRpbmcg b24gdGhlIE1BQy9LREYgaW4KICAgdXNlKSwgd2l0aCBsYXJnZXIga2V5cyBoYXZpbmcgZWZmZWN0 aXZlbHkgemVybyBhZGRpdGlvbmFsCiAgIGNvbXB1dGF0aW9uYWwgY29zdHMgd2hlbiBjb21wYXJl ZCB0byBzaG9ydGVyIGtleXMsICgyKSBrZXkgc2hhcmluZwogICBTSE9VTEQgYmUgbGltaXRlZCBz byB0aGF0IGtleXMgYXJlbid0IHNoYXJlZCBhbW9uZyBtdWx0aXBsZSBCR1AKICAgcGVlcmluZyBh cnJhbmdlbWVudHMsIGFuZCAoMykgS2V5cyBTSE9VTEQgYmUgY2hhbmdlZCBhdCBsZWFzdCBldmVy eQogICA5MCBkYXlzICh0aGlzIGNvdWxkIGJlIGxvbmdlciBmb3Igc3Ryb25nZXIgTUFDIGFsZ29y aXRobXMsIGJ1dCBpdCBpcwogICBnZW5lcmFsbHkgYSB3aXNlIGlkZWEpLgoKICAgVGhpcyBpcyBl c3BlY2lhbGx5IHRydWUgd2hlbiB0aGUgUm91dGluZyBQcm90b2NvbCB0YWtlcyBhIHN0YXRpYwog ICBUcmFmZmljIEtleSBhcyBvcHBvc2VkIHRvIGEgVHJhZmZpYyBLZXkgZGVyaXZlZCBwZXItY29u bmVjdGlvbiBieSBhCiAgIEtERi4gIFRoZSBidXJkb24gZm9yIGRvaW5nIHNvIGlzIHVuZGVyc3Rh bmRhYmxlIG11Y2ggaGlnaGVyIHRoYW4gZm9yCiAgIHVzaW5nIHRoZSBzYW1lIHN0YXRpYyBUcmFm ZmljIEtleSBhY3Jvc3MgYWxsIHBlZXJpbmcgcm91dGVycy4gIFRoaXMKICAgaXMgd2h5IHVzZSBv ZiBhIEtNUCBuZXR3b3JrLXdpZGUgaW5jcmVhc2VzIHBlZXItd2lzZSBzZWN1cml0eSBzbwogICBn cmVhdGx5LCBiZWNhdXNlIG5vdyBlYWNoIHNldCBvZiBwZWVycyBjYW4gZW5qb3lzIGEgdW5pcXVl IFRyYWZmaWMKICAgS2V5LCBhbmQgaWYgYW4gYXR0YWNrZXIgc2l0dGluZyBiZXR3ZWVuIHR3byBy b3V0ZXJzIGxlYXJucyBvciBndWVzc2VzCiAgIHRoZSBUcmFmZmljIEtleSBmb3IgdGhhdCBjb25u ZWN0aW9uLCBzaGUgZG9lc24ndCBnYWluIGFjY2VzcyB0byBhbGwKICAgdGhlIG90aGVyIGNvbm5l Y3Rpb25zIGFzIHdlbGwuCgogICBIb3dldmVyLCB3aGVuZXZlciB1c2luZyBtYW51YWwga2V5cywg aXQgaXMgYmVzdCB0byBkZXNpZ24gYSBzeXN0ZW0KICAgd2hlcmUgYSBnaXZlbiBQU0sgd2lsbCBi ZSB1c2VkIGluIGEgS0RGLCBtaXhlZCB3aXRoIGNvbm5lY3Rpb24KICAgc3BlY2lmaWMgbWF0ZXJp YWwsIGluIG9yZGVyIHRvIGdlbmVyYXRlIHNlc3Npb24gdW5pcXVlIC0tIGFuZAogICB0aGVyZWZv cmUgcGVlci13aXNlIC0tIFRyYWZmaWMgS2V5cy4gIERvaW5nIHNvIGhhcyB0aGUgZm9sbG93aW5n CiAgIGFkdmFudGFnZXM6IHRoZSBUcmFmZmljIEtleXMgdXNlZCBpbiB0aGUgcGVyLW1lc3NhZ2Ug TUFDIG9wZXJhdGlvbgogICBhcmUgcGVlci13aXNlIHVuaXF1ZSwgaXQgcHJvdmlkZXMgaW50ZXIt Y29ubmVjdGlvbiByZXBsYXkgcHJvdGVjdGlvbiwKICAgYW5kLCBpZiB0aGUgcGVyLW1lc3NhZ2Ug TUFDIGNvdmVycyBzb21lIGNvbm5lY3Rpb24gY291bnRlciwgaW50cmEtCiAgIGNvbm5lY3Rpb24g cmVwbGF5IHByb3RlY3Rpb24uCgogICBOb3RlIHRoYXQgaW4gdGhlIGNvbXBvc2l0aW9uIG9mIGNl cnRhaW4ga2V5IGRlcml2YXRpb24gZnVuY3Rpb25zCiAgIChlLmcuICBLREZfQUVTXzEyOF9DTUFD LCBhcyB1c2VkIGluIFRDUC1BTyBbSS1ELmFvLWNyeXB0b10pLCB0aGUKICAgcHNldWRvcmFuZG9t IGZ1bmN0aW9uIChQUkYpIHVzZWQgaW4gdGhlIEtERiBtYXkgcmVxdWlyZSBhIGtleSBvZiBhCiAg IGNlcnRhaW4gZml4ZWQgc2l6ZSBhcyBhbiBpbnB1dC4gIEZvciBleGFtcGxlLCBBRVNfMTI4X0NN QUMgcmVxdWlyZXMgYQogICAxMjggYml0ICgxNiBieXRlKSBrZXkgYXMgdGhlIHNlZWQuICBIb3dl dmVyLCBmb3IgY29udmVuaWVuY2UgdG8gdGhlCiAgIGFkbWluaXN0cmF0b3JzL2RlcGxveWVycywg YSBzcGVjaWZpY2F0aW9uIG1heSBub3Qgd2FudCB0byBmb3JjZSB0aGUKICAgZGVwbG95ZXIgdG8g ZW50ZXIgYSBQU0sgb2YgZXhhY3RseSAxNiBieXRlcy4gIEluc3RlYWQsIGEKICAgc3BlY2lmaWNh dGlvbiBtYXkgY2FsbCBmb3IgYSBzdWIta2V5IHJvdXRpbmUgdGhhdCBjb3VsZCBoYW5kbGUgYQog ICB2YXJpYWJsZSBsZW5ndGggUFNLLCBvbmUgdGhhdCBtaWdodCBiZSBsZXNzIHRoYW4gMTYgYnl0 ZXMgKHNlZQogICBbUkZDNDYxNV0sIHNlY3Rpb24gMywgYXMgYW4gZXhhbXBsZSkuICBUaGF0IHN1 Yi1rZXkgcm91dGluZSB3b3VsZCBhY3QKICAgYXMgYSBrZXkgZXh0cmFjdG9yIHRvIGRlcml2ZSBh IHNlY29uZCBrZXkgb2YgZXhhY3RseSB0aGUgcmVxdWlyZWQKICAgbGVuZ3RoLCBhbmQgdGh1cyBz dWl0YWJsZSBhcyBhIHNlZWQgdG8gdGhlIFBSRi4gIFRoaXMgZG9lcyBOT1QgbWVhbgogICB0aGF0 IGFkbWluaXN0cmF0b3JzIGFyZSBzYWZlIHRvIHVzZSB3ZWFrIGtleXMuICBBZG1pbmlzdHJhdG9y cyBhcmUKICAgZW5jb3VyYWdlZCB0byBmb2xsb3cgW1JGQzQwODZdIGFzIGxpc3RlZCBhYm92ZS4g IFdlIHNpbXBseSBhdHRlbXB0ZWQKICAgdG8gInB1dCBhIGZlbmNlIGFyb3VuZCBzdHVwaWRpdHki LCBpbiBhcyBtdWNoIGFzIHBvc3NpYmxlLgoKICAgQSBiZXR0ZXIgb3B0aW9uLCBmcm9tIGEgc2Vj dXJpdHkgcGVyc3BlY3RpdmUsIGlzIHRvIHVzZSBzb21lCiAgIHJlcHJlc2VudGF0aW9uIG9mIGEg ZGV2aWNlLXNwZWNpZmljIGFzc3ltZXRyaWMga2V5IHBhaXIgYXMgdGhlCgoKCkxlYm92aXR6ICYg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdl IDM2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIGlkZW50aXR5IHByb29mLCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiAzLjQuMi4KCiAgIFdoZW4gaXQgY29tZXMgdGltZSBmb3IgdGhlIEtBUlAgV0cg dG8gZGVzaWduIHRoZSByZS11c2FibGUgbW9kZWwgZm9yCiAgIGEgS01QLCBUaGUgR3VpZGVsaW5l cyBmb3IgQ3J5cHRvZ3JhcGhpYyBLZXkgTWFuYWdlbWVudCwgUkZDNDEwNwogICBbUkZDNDEwN10g c2hvdWxkIGJlIHdpbGwgYmUgY29uc3VsdGVkLgoKICAgW1tRVUVTVElPTiBUTyBSRVZJRVdFUlM6 IGl0IG1heSBiZSB3b3J0aHdoaWxlIHRvIHB1bGwgdGhlIGxhc3QgZmV3CiAgIHBhcmFncmFwaHMs IGFsb25nIHdpdGggc29tZSBndWlkYW5jZSBhbG9uZyB0aGUgc2FtZSBsaW5lcywgaW50bwogICBz ZWN0aW9uIDQsIGluIGEgbmV3IHN1Yi1zZWN0aW9uIHdpdGggYSB0aXRsZSBzb21ldGhpbmcgbGlr ZSAiU2VjdXJpdHkKICAgdGlwcyBmb3IgS0FSUCBkZXNpZ24gdGVhbXMgd29ya2luZyBvbiBSb3V0 aW5nIFByb3RvY29sIHJldmlld3MgYW5kCiAgIHVwZGF0ZXMiLiAgT3IgbWF5YmUgZXZlbiBpbnRv IGl0cyBvd24gaW5mbyBkb2N1bWVudCwgIlNlY3VyaXR5CiAgIEd1aWRlbGluZXMgZm9yIEtBUlAg RGVzaWduIFRlYW1zIi5UaG91Z2h0cz9dXQoKICAgVGhlIG1lY2hhbmlzbXMgdGhhdCB3aWxsIGJl IGRlZmluZWQgdW5kZXIgdGhpcyByb2FkbWFwIGFpbSB0byBpbXByb3ZlCiAgIHRoZSBzZWN1cml0 eSwgYmV0dGVyIHByb3RlY3QgYWdhaW5zdCBtb3JlIHRocmVhdHMsIGFuZCBwcm92aWRlciBmYXIK ICAgZ3JlYXRlciBvcGVyYXRpb25hbCBlZmZpY2llbmNpZXMgdGhhbiB0aGUgc3RhdGUgb2YgdGhp bmdzIGF0IHRoZSB0aW1lCiAgIG9mIHRoaXMgd3JpdGluZy4gIEhvd2V2ZXIsIG5vbmUgb2YgdGhl c2UgY2hhbmdlcyB3aWxsIGltcHJvdmUKICAgSW50ZXJuZXQgc2VjdXJpdHkgdW5sZXNzIHRoZXkg YXJlIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZC4gIE90aGVyCiAgIGluZmx1ZW5jZXMgbXVzdCBi ZSBicm91Z2h0IHRvIGJhcmUgdXBvbiBvcGVyYXRvcnMgYW5kIG9yZ2FuaXphdGlvbnMKICAgdG8g Y3JlYXRlIGluY2VudGl2ZXMgZm9yIGRlcGxveW1lbnQuICBTdWNoIGluY2VudGl2ZXMgbWF5IHRh a2UgdGhlCiAgIGZvcm0gb2YgUENJLWxpa2UgaW5kdXN0cnkgY29tcGxpYW5jZS9jZXJ0aWZpY2F0 aW9ucywgd2VsbCBhZHZlcnRpc2VkCiAgIEJDUHMgcHJvZmlsaW5nIHRoZSB1c2Ugb2YgdGhpcyBy b2FkbWFwJ3Mgb3V0cHV0LCBlbmQtdXNlciBkZW1hbmQgb3IKICAgaW5zaXN0YW5jZS4KCgo2LiAg SUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBoYXMgbm8gYWN0aW9ucyBmb3Ig SUFOQS4KCgo3LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIG91dGxpbmUgZm9yIHRoaXMgZHJh ZnQgd2FzIGNyZWF0ZWQgZnJvbSBkaXNjdXNzaW9ucyBhbmQKICAgYWdyZWVtZW50cyB3aXRoIFJv dXRpbmcgQUQncyBSb3NzIENhbGxvbiBhbmQgRGF2ZSBXYXJkLCBTZWN1cml0eSBBRCdzCiAgIFRp bSBQb2xrIGFuZCBQYXNpIEVyb25lbiwgYW5kIElBQiBtZW1iZXJzIERhbm55IE1jUGhlcnNvbiBh bmQgR3JlZ29yeQogICBMZWJvdml0ei4KCiAgIE1hdCBGb3JkIGFuZCBCaWxsIEF0d29vZCBwcm92 aWRlZCByZXZpZXdzIHRvIC0wMC4KCiAgIERhbm55IE1jUGhlcnNvbiBwcm92aWRlZCBhbiBleHRy ZW1lbHkgZGV0YWlsZWQgYW5kIHVzZWZ1bCByZXZpZXcgb2YKICAgLTAxLgoKCjguICBDaGFuZ2Ug SGlzdG9yeSAoUkZDIEVkaXRvcjogRGVsZXRlIEJlZm9yZSBQdWJsaXNoaW5nKQoKICAgW05PVEUg VE8gUkZDIEVESVRPUjogdGhpcyBzZWN0aW9uIGZvciB1c2UgZHVyaW5nIEktRCBzdGFnZSBvbmx5 LgogICBQbGVhc2UgcmVtb3ZlIGJlZm9yZSBwdWJsaXNoaW5nIGFzIFJGQy5dCgoKCgpMZWJvdml0 eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBb UGFnZSAzN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgogICAtMDAtMDAgb3JpZ2luYWwgcm91Z2ggcm91 Z2ggcm91Z2ggZHJhZnQgZm9yIHJldmlldyBieSByb3V0aW5nIGFuZAogICBzZWN1cml0eSBBRCdz CgogICAtMDAtIG9yaWdpbmFsIHN1Ym1pc3Npb24KCiAgIG8gIGFkZHMgbmV3IGNhdGVnb3J5ID0g bXVsdGljYXN0IHByb3RvY29scyBpbiBjYXRlZ29yeSBzZWN0aW9uIGFuZAogICAgICBtZW50aW9u cyBtY2FzdCBpbiBncm91cCBrZXlpbmcgY2F0ZWdvcnkgZGVzY3JpcHRpb24uCiAgIG8gIGFkZCBh IGxvdCBvZiByZWZlcmVuY2VzIHdoZXJlIHRoZXkgZGlkIG5vdCBleGlzdCBiZWZvcmUsIG9yIHdo ZXJlCiAgICAgIHRoZXJlIHdlcmUgb25seSBwbGFjZSBob2xkZXJzLiAgU3RpbGwgbW9yZSB3b3Jr IG5lZWRlZCBvbiB0aGlzLgogICBvICBhYnN0cmFjdCBmaWxsZWQgaW4KICAgbyAgY2hhbmdlZCBm cm9tIHN0YW5kYXJkcyB0cmFjayB0byBpbmZvcm1hdGlvbmFsICh0aGlzIHdhcyBhbgogICAgICBv dmVyc2lnaHQgaW4gbGFzdCBkcmFmdCkuCiAgIG8gIGZpbGxlZCBvdXQgdGhyZWF0cyBzZWN0aW9u IHdpdGggZGV0YWlsZWQgZGVzY3JpcHRpb25zLCBhbmQgbGlua2VkCiAgICAgIHRvIFJQc2VjIHRo cmVhdHMgUkZDCiAgIG8gIG1hZGUgYXNjaWkgYXJ0IGZvciB0aGUgYmFzaWMgS01QIGZyYW1ld29y awogICBvICBhZGRlZCBzZWN0aW9uIG9uIGludGVybmFsIHZlcnN1cyBleHRlcm5hbCBwZWVyaW5n IGFuZCB0aGUKICAgICAgcmVxdWlyZW1lbnRzIGRlY2lzaW9ucyBmb3IgdGhlbQogICBvICBhZGRl ZCBzZWN1cml0eSBjaGFyYWN0ZXJpemF0aW9uIHNlY3Rpb24gaW4gc2VjdCAyLCBhZGRlZCBzZWN0 aW9ucwogICAgICBkaXNjdXNzaW5nIGludGVybmFsIHZzIGV4dGVybmFsIHByb3RvY29scywgc2hh cmVkIHZzIHVuaXF1ZSBrZXlzLAogICAgICBvb2IgdnMgaW4tYmFuZCBrZXlpbmcKICAgbyAgaW5j b3Jwb3JhdGVzIGFsbCBEIFdhcmQncyBmZWVkYmFjayBmcm9tIGhpcyBpbml0aWFsIHNraW0gb2Yg dGhlCiAgICAgIGRvY3VtZW50LgoKICAgLTAxLQoKICAgbyAgVXBkYXRlZCBmcmFtZXdvcmsgKEZp Z3VyZSAxKSBkaWFncmFtIHRvIGluY2x1ZGUgYWxsIGxpc3RlZCBhbmQKICAgICAgZGVzY3JpYmVk IGVsZW1lbnRzLiAgTmVlZHMgcmV2aWV3IGFuZCBob25pbmcuICBHcmVnb3J5IExlYm92aXR6CiAg ICAgIChHTCkuCiAgIG8gIEFkZGVkIGNvbW1lbnQgaW4gcHJvdG9jb2xzIChTZWN0aW9uIDQuNSkg c2VjdGlvbiB0aGF0IG11Y2ggb2YgdGhlCiAgICAgIEJHUC9MRFAgUGhhc2UgMSB3b3JrIGlzIGFs cmVhZHkgYmVpbmcgZG9uZSBpbiB0Y3AtYW8gYW5kIGFvLQogICAgICBjcnlwdG8uICBHTC4KICAg byAgVXBkYXRlZCBTY29wZSBtYWtpbmcgdGhlIDIgd29yayBwaGFzZXMgbW9yZSBjbGVhciBlYXJs aWVyIGluIHRoZQogICAgICBkb2N1bWVudC4gIEdMLgogICBvICBCcm9rZSB3b3JrIGl0ZW1zIChT ZWN0aW9uIDQuNCkgc2VjdGlvbiBpbnRvIHR3byBQaGFzZXMsIDEgZm9yCiAgICAgIG1hbnVhbCBr ZXkgdXBkYXRlLCBhbmQgc2Vjb25kIGZvciBLTVAgd29yay4gIEdMLgogICBvICBSZS1vcmcnZCBk b2MuICBCcm91Z2h0IFRocmVhdHMgKFNlY3Rpb24gMikgc2VjdGlvbiBvdXQgaW50byBpdHMKICAg ICAgb3duIHRvcC1sZXZlbCBzZWN0aW9uLiAgRGlkIHNhbWUgd2l0aCBDYXRlZ29yaXphdGlvbiAo U2VjdGlvbiAzKQogICAgICBzZWN0aW9uLCBsZWF2aW5nIFJvYWRtYXAgc2VjdGlvbiBtb3JlIGZv Y3VzZWQuICBNb3ZlZCBUb0RvIGxpc3QKICAgICAgYW5kIENoYW5nZSBIaXN0b3J5IHRvIGVuZCBv ZiBkb2MsIGFmdGVyIEFja25vd2xlZGdlbWVudHMuICBHTC4KICAgbyAgYWRkZWQgbmV3IHNlY3Qg Mi4zIChTZWN0aW9uIDQuMSkgb24gbWFpbiByb2FkbWFwIHBoYXNlcy4gIFByZXZpb3VzCiAgICAg IHNlY3Rpb24gQ29tbW9uIEZyYW1ld29yayAoU2VjdGlvbiA0LjMpIG1vdmVkIHRvIDIuNC4gIFRp bSBQb2xrCiAgICAgIChUUCkuCiAgIG8gIEFkZGVkIFNlY3Rpb24gMi4zLjEgUmVxdWlyZW1lbnRz IGZvciBQaGFzZSAxIFJvdXRpbmcgUHJvdG9jb2xzJwogICAgICBTZWN1cml0eSBVcGRhdGUgKFNl Y3Rpb24gNC4yKS4gIFRoaXMgcHJvdmlkZXMgYSBuaWNlIHN0YXJ0ZXIgc2V0CiAgICAgIG9mIHJl cXVpcmVtZW50cyBmb3IgYW55IHdvcmsgdGVhbS4gIEdMLgogICBvICBGaWxsZWQgb3V0IHRleHQg Zm9yIE91dCB2cyBJbi1iYW5kIEtleSBNZ210IChTZWN0aW9uIDMuNC4zKQogICAgICBzZWN0aW9u LCBzaWduaWZpY2FudGx5LiAgQ2hhbmdlZCB0aGUgdGVybSBmcm9tICJpbi1iYW5kIiB0byAiaW4t CiAgICAgIGxpbmUiLgoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5 LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAzOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgogICBv ICBTZWN0aW9uIFRocmVhdHMgKFNlY3Rpb24gMikgQ2xhcmlmaWVkIERvUyB0aHJlYXRzIGluIGFu ZCBvdXQgb2YKICAgICAgc2NvcGUgYmV0dGVyLiAgV2UgYXJlIG5vdCBwcmV2ZW50aW5nIGFsbCBE b1MgYXR0YWNrcy4gIEp1c3QgdGhvc2UKICAgICAgd2UgY2FuIHJlYXNvbmFibHkgdmlhIGF1dGhl bnRpY2F0aW9uLiAgVFAuCiAgIG8gIFNlY3QgSW4tYmFuZCB2cyBPdXQtb2YtQmFuZCAoU2VjdGlv biAzLjQuMyljbGFyaWZpZWQgdGhhdCBJbi1iYW5kCiAgICAgIGRvZXMgbm90IG1lYW4gaW4tYmFu ZCB0byBSb3V0aW5nIFByb3RvY29sLCBidXQgcmF0aGVyIG92ZXIgSVAKICAgICAgYmV0d2VlbiB0 aGUgUm91dGluZyBQcm90b2NvbHMsIHJhdGhlciB0aGFuIHB1c2hlZCBkb3duIGJ5IHNvbWUKICAg ICAgZXh0ZXJuYWwgbWFuYWdlbWVudCBlbnRpdHkuICBUUC4KICAgbyAgSW4gcm9hZG1hcCAoU2Vj dGlvbiAzKSBzZWN0aW9uLCBhZGRlZCAiaXQgaXMgYWxzbyBob3BlZCB0aGF0IHdlCiAgICAgIGNh biBjcmVhdGUgb25lIGttcCBwZXIgY2F0ZWdvcnkuLi4iICBBbHNvIGV4cGxhaW5lZCB2YWx1ZSBv ZiBhCiAgICAgIEtNUC4gIFRQLgogICBvICBBZGRlZCAib3BlcmF0b3JzIiB0byBhdWRpZW5jZSAo U2VjdGlvbiAxLjYpIGxpc3QuICBNYXR0IEZvcmQgKE1GKS4KICAgbyAgRGVzY3JpYmVkIHdoeSBC R1AgKGFuZCBMRFApIHNlY3VyaXR5IGlzIG5vdCBkZXBsb3llZCB2ZXJ5IG9mdGVuLgogICAgICBB ZGRlZCB0aGlzIFNjb3BlIChTZWN0aW9uIDEuMykgc2VjdGlvbiwgcG9pbnQgNC4gIElmIG1lY2hh bmlzbXMKICAgICAgYXJlbid0IGJlaW5nIGRlcGxveWVkLCB3aHkgaXMgdGhhdD8gIFdoYXQsIGlm IGFueXRoaW5nLCBjb3VsZCBiZQogICAgICBkb25lIHRvIGltcHJvdmUgZGVwbG95bWVudD8gIFRy aWVkIHRvIGFkZHJlc3MgdGhlc2UuICBOZWVkCiAgICAgIHJlZmVyZW5jZXMgKHNlZSBUbyBEbyBs aXN0IGJlbG93KS4gIE1GLgogICBvICBBZGRlZCBzb21lIHRleHQgdG8gc2VjdXJpdHkgc2VjdGlv biB0byBhZGRyZXNzIHRoaXMgZnJvbSBNRjogc2F5CiAgICAgIHNvbWV0aGluZyBoZXJlIGFib3V0 IHRoZSBsaW1pdGF0aW9ucyBvZiB0aGlzIGFwcHJvYWNoLCBpZiBhbnkgLQogICAgICBhbmQgcmVm ZXIgYmFjayB0byB0aGUgbmVlZCBmb3Igb3RoZXIgcGllY2VzIG9mIHRoZSBwdXp6bGUuICBNYXkK ICAgICAgbmVlZCBtb3JlIHdvcmsuCiAgIG8gIENsZWFuZWQgdXAgdGV4dCBmb3IgbXVsdGljYXN0 IHBhcnQgb2YgTWVzc2FnZSBUeXBlIChTZWN0aW9uIDMuMSkKICAgICAgc2VjdGlvbiBhbmQgUHJv dG9jb2xzIChTZWN0aW9uIDQuNSkgc2VjdGlvbiwgY2xhcmlmeWluZyBQSU0ncyB0d28KICAgICAg bWVzc2FnZSB0eXBlcywgbWNhc3QgYW5kIHVuaWNhc3QsIGluIGJvdGggcGxhY2VzLiAgQmlsbCBB dHdvb2QKICAgICAgKEJBKS4KICAgbyAgSW4gc2VjdGlvbiBQcm90b2NvbHMgKFNlY3Rpb24gNC41 KSwgYWRkZWQgcmVmZXJlbmNlcyB0byA0NjAxIGFuZAogICAgICBQSU0tU00tTElOS0xPQ0FMLiAg QkEuCiAgIG8gIEVkaXRvcmlhbCBjaGFuZ2VzIHBvaW50ZWQgb3V0IHZhcmlvdXMgZm9sa3MuCgog ICAtMDItCgogICBvICBSZS1zdWJtaXR0ZWQgZHVlIHRvIGV4cGlyYXRpb24uICBUZXh0IGRpZCBu b3QgY2hhbmdlLiAgU3Vic3RhbnRpdmUKICAgICAgdXBkYXRlIGNvbWluZyBzaG9ydGx5LgogICBv CiAgIG8KCiAgIC0gMDMgLQoKICAgbyAgY2hhbmdlZCAiQmFzZVJQIiB0byAiUm91dGluZyBQcm90 b2NvbCIgdGhyb3VnaG91dCB0aGUgZG9jIC0gbWFuCiAgIG8gIGZpbGxlZCBvdXQgdGhlIFRlcm1p bm9sb2d5IHNlY3Rpb24KICAgbyAgY2hhbmdlZCAiS01BUlQiIHRvICJLQVJQIiBpbiBldmVyeXRo aW5nIGJ1dCB0aGUgdGl0bGUsIHNpbmNlIHRoZQogICAgICAtMDAgZGVhZGxpbmUgaGFkIGxvbmcg c2luY2UgcGFzc2VkLiAgV2lsbCBjaGFuZ2UgdGhlIHRpdGxlIG9mIHRoZQogICAgICBkb2MgdG8g S0FSUCBhcyBzb29uIGFzIHRoZSB3aW5kb3cgcmUtb3BlbnMuCiAgIG8gIHByaW9yaXRpZXMgaW4g c2VjdCA0LjYgY2hhbmdlZC4gIEFkZGVkIFBJTS1TTS4gIExvd2VyZWQgT1NQRiBhbmQKICAgICAg QkZELCBiYXNlZCBvbiBmZWVkYmFjayBieSBhIGZldyBwZW9wbGUuCiAgIG8gIG1hbnkgZWRpdHMg cmVzdWx0aW5nIGZyb20gRGFubnkgTWNQaGVyc29uJ3MgcmV2aWV3LgogICBvICBhZGRlZCAiQnJ1 dGUgRm9jZSBBdHRhY2tzIEFnYWluc3QgUGFzc3dvcmQvS2V5cyIgdG8gVGhyZWF0cwogICAgICBT ZWN0aW9uIDIuMSBzZWN0aW9uLgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMzldCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5 CgoKICAgbyAgU2lnbmlmaWNhbnQgdXBkYXRlcyB0byBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uCiAgIG8gIEFkZGVkIGEgZmV3IHJlZmVyZW5jZXMgdGhyb3VnaG91dCB0byBSRkMzNTYy CiAgIG8gIDQuMyAybmQgdG8gbGFzdCBQIC0gYWRkZWQgYSBjb21tZW50IHRvIGNsYXJpZnkgdGhh dCB0d28gcGFydGllcwogICAgICAob3IgYW4gb3JnKSBtdXN0IGRpc2N1c3MgYWhlYWQgb2YgdGlt ZSB3aGF0IHRoZXkgd2FudCB0aGVpcgogICAgICBjb25uZWN0aW9ucycgc2VjcnVpdHkgcHJvcGVy dGllcyB0byBiZS4gLSBkd2FyZAogICBvICBhZGRlZCB0byA0LjQgUGhhc2UgMSAtIE5ldyBTZWN0 aW9uOiBUcmFuc2l0aW9uIGFuZCBEZXBsb3ltZW50CiAgICAgIENvbnNpZGVyYXRpb25zLiBlYSB3 ZyBtdXN0IGNhbGwgb3V0IHRoZSBvcGVyYXRpb25hbCB0cmFuc2l0aW9uCiAgICAgIHBsYW4gZnJv bSBvbGQgdG8gbmV3IHNlY3VyaXR5LiAgQmVzdCBpZiBkb24ndCBib3VuY2UgbGluay4gLSBkd2Fy ZAogICBvICBhZGRlZCAzLjMgKGJ1dCBub3Qgc3VyZSBpZiB0aGlzIGlzIHJpZ2h0KS0gZW5kcG9p bnQgZGlzY292ZXJ5CiAgICAgIG1lY2hhbmlzbXM/IGVuZHBvaW50IGRpc2NvdmVyeSBtZWNoYW5p c20gKEwyVlBOLCBMM1ZQTiwgZXRjKS4KICAgICAgRGlzY292ZXJ5IGlzIG11Y2ggZGlmZmVyZW50 IHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhbiBwYXNzaW5nCiAgICAgIFJvdXRpbmcgdXBkYXRlcy4g LSBkd2FyZAogICBvICBNb3JlIHJlcXVpcmVtZW50czogQWRkZWQgdG8gNC4yOiBYIC0gY29udmVy Z2VuY2UgU0hPVUxEIG5vdCBiZQogICAgICBhZmZlY3RlZCBieSB3aGF0IHdlIGNob29zZTsgYWRk aW5nIHNlY3VyaXR5IFNIT1VMRCBub3QgY2F1c2UgYQogICAgICByZWZyZXNoIG9mIHJvdXRlIHVw ZGF0ZXMgb3IgY2F1c2UgYWRkaXRpb25hbCByb3V0ZSB1cGRhdGVzIHRvIGJlCiAgICAgIGdlbmVy YXRlZDsgYWRkaW5nIGF1dGggc2hvdWxkIG5vdCBiZSBhbiBhdHRhY2sgdmVjdG9yIGl0c2VsZi4K ICAgICAgQUtBLCB0aGUgdXNlIG9mIE1ENSBpcyBzbyBleHBlbnNpdmUgdGhhdCBzcG9vZmluZyBC R1AgcGFja2V0cyB3LwogICAgICBNRDUgY2F1c2VzIHRoZSBjb250cm9sIHBsYW5lIHRvIGJlIGF0 dGFja2VkIGJlY2F1c2UgQ1BVIHdlbnQgdG8KICAgICAgMTAwJSAtIGR3YXJkCiAgIG8gIHVwZGF0 ZWQgc3RhdHMgb24gTUQ1IHVzYWdlLCBhbmQgY2l0ZWQgW0lTUjIwMDhdLiAtIG1jaHBoZXJzb24K Cgo5LiAgTmVlZHMgV29yayBpbiBOZXh0IERyYWZ0IChSRkMgRWRpdG9yOiBEZWxldGUgQmVmb3Jl IFB1Ymxpc2hpbmcpCgogICBbTk9URSBUTyBSRkMgRURJVE9SOiB0aGlzIHNlY3Rpb24gZm9yIHVz ZSBkdXJpbmcgSS1EIHN0YWdlIG9ubHkuCiAgIFBsZWFzZSByZW1vdmUgYmVmb3JlIHB1Ymxpc2hp bmcgYXMgUkZDLl0KCiAgIExpc3Qgb2Ygc3R1ZmYgdGhhdCBzdGlsbCBuZWVkcyB3b3JrCiAgIG8g IFJURyBBRCdzIG9yIGRlbGVnYXRlczogY2xlYW4gdXAgdGhlIHRocmVlIGRlZmluaXRpb25zIG9m IHJvdXRlCiAgICAgIG1lc3NhZ2UgdHlwZSBjYXRlZ29yaWVzLiAgTmVlZCBSVEcgQXJlYSBmb2xr cyBpbnB1dCBvbiB0aGlzLgogICBvICBNb3JlIGNsYXJpdHkgb24gdGhlIHdvcmsgaXRlbXMgZm9y IHRob3NlIGRlZmluaW5nIGFuZCBzcGVjaWZ5aW5nCiAgICAgIHRoZSBmcmFtZXdvcmsgZWxlbWVu dHMgYW5kIEFQSSdzIHRoZW1zZWx2ZXMuCiAgIG8gIFJURyBBRCdzIG9yIGRlbGVnYXRlczogdGV4 dCBqdXN0aWZ5aW5nIFJTVlAgYW5kIFJTVlAtVEUgYW5kIHdoYXQKICAgICAgd2UgdGhpbmsgc29s dmluZyB0aGF0IHByb2JsZW0gbWF5IGxvb2sgbGlrZQogICBvICBSVEcgQUQncyBvciBkZWxlZ2F0 ZXM6IG1vcmUganVzdGlmaWNhdGlvbiBmb3Igd2h5IE1BTkVUIGFuZCBGT1JDRVMKICAgICAgYXJl IG91dCBvZiBzY29wZS4gIE5lZWQgcmVmIGZvciB0aG9zZSBSRkNzLgogICBvICBEYW5ueSBNY1Bo ZXJzb246IEdldCByZWZlcmVuY2UgZm9yIEJHUCBhdXRoIHVzYWdlIHN0YXRzIGluIFNjb3BlCiAg ICAgIChTZWN0aW9uIDEuMykgc2VjdGlvbiwgaXRlbSA0LgogICBvCiAgIG8gIHNlY3VyaXR5IHNl Y3Rpb246IHB1bGwgb3V0IHNlY3VyaXR5IGd1aWRhbmNlIHRvIHJvdXRpbmcgcHJvdG9jb2wKICAg ICAgZGVzaWduIHRlYW1zIHN0dWZmIGFuZCBwbGFjZSBpbnRvIGl0cyBvd24gc2VjdGlvbj8KICAg bwogICBvCgoKMTAuICBSZWZlcmVuY2VzCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgNDBdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJl ciAyMDA5CgoKMTAuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRu ZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgog ICBbUkZDNDU5M10gIEJhcmJpciwgQS4sIE11cnBoeSwgUy4sIGFuZCBZLiBZYW5nLCAiR2VuZXJp YyBUaHJlYXRzIHRvCiAgICAgICAgICAgICAgUm91dGluZyBQcm90b2NvbHMiLCBSRkMgNDU5Mywg T2N0b2JlciAyMDA2LgoKICAgW1JGQzQ5NDhdICBBbmRlcnNzb24sIEwuLCBEYXZpZXMsIEUuLCBh bmQgTC4gWmhhbmcsICJSZXBvcnQgZnJvbSB0aGUKICAgICAgICAgICAgICBJQUIgd29ya3Nob3Ag b24gVW53YW50ZWQgVHJhZmZpYyBNYXJjaCA5LTEwLCAyMDA2IiwKICAgICAgICAgICAgICBSRkMg NDk0OCwgQXVndXN0IDIwMDcuCgoxMC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0kt RC5hby1jcnlwdG9dCiAgICAgICAgICAgICAgTGVib3ZpdHosIEcuLCAiQ3J5cHRvZ3JhcGhpYyBB bGdvcml0aG1zLCBVc2UgYW5kCiAgICAgICAgICAgICAgSW1wbGVtZW50YXRpb24gUmVxdWlyZW1l bnRzIGZvciBUQ1AgQXV0aGVudGljYXRpb24KICAgICAgICAgICAgICBPcHRpb24iLCBNYXJjaCAy MDA5LCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvCiAgICAgICAgICAgICAgZHJhZnQtbGVi b3ZpdHotaWV0Zi10Y3BtLXRjcC1hby1jcnlwdG8tMDA+LgoKICAgW0ktRC5pZXRmLXBpbS1zbS1s aW5rbG9jYWxdCiAgICAgICAgICAgICAgQXR3b29kLCBXLiwgSXNsYW0sIFMuLCBhbmQgTS4gU2lh bWksICJBdXRoZW50aWNhdGlvbiBhbmQKICAgICAgICAgICAgICBDb25maWRlbnRpYWxpdHkgaW4g UElNLVNNIExpbmstbG9jYWwgTWVzc2FnZXMiLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtcGlt LXNtLWxpbmtsb2NhbC0wOSAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgT2N0b2Jl ciAyMDA5LgoKICAgW0ktRC5pZXRmLXRjcG0tdGNwLWF1dGgtb3B0XQogICAgICAgICAgICAgIFRv dWNoLCBKLiwgTWFua2luLCBBLiwgYW5kIFIuIEJvbmljYSwgIlRoZSBUQ1AKICAgICAgICAgICAg ICBBdXRoZW50aWNhdGlvbiBPcHRpb24iLCBkcmFmdC1pZXRmLXRjcG0tdGNwLWF1dGgtb3B0LTA4 CiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBPY3RvYmVyIDIwMDkuCgogICBbSVNS MjAwOF0gIE1jUGhlcnNvbiwgRC4gYW5kIEMuIExhYm92aXR6LCAiV29ybGR3aWRlIEluZnJhc3Ry dWN0dXJlCiAgICAgICAgICAgICAgU2VjdXJpdHkgUmVwb3J0IiwgT2N0b2JlciAyMDA4LAogICAg ICAgICAgICAgIDxodHRwOi8vd3d3LmFyYm9ybmV0d29ya3MuY29tL2RtZG9jdW1lbnRzL0lTUjIw MDhfVVMucGRmPi4KCiAgIFtSRkMxMTk1XSAgQ2FsbG9uLCBSLiwgIlVzZSBvZiBPU0kgSVMtSVMg Zm9yIHJvdXRpbmcgaW4gVENQL0lQIGFuZAogICAgICAgICAgICAgIGR1YWwgZW52aXJvbm1lbnRz IiwgUkZDIDExOTUsIERlY2VtYmVyIDE5OTAuCgogICBbUkZDMjMyOF0gIE1veSwgSi4sICJPU1BG IFZlcnNpb24gMiIsIFNURCA1NCwgUkZDIDIzMjgsIEFwcmlsIDE5OTguCgogICBbUkZDMjQ1M10g IE1hbGtpbiwgRy4sICJSSVAgVmVyc2lvbiAyIiwgU1REIDU2LCBSRkMgMjQ1MywKICAgICAgICAg ICAgICBOb3ZlbWJlciAxOTk4LgoKICAgW1JGQzM1NjJdICBMZWVjaCwgTS4sICJLZXkgTWFuYWdl bWVudCBDb25zaWRlcmF0aW9ucyBmb3IgdGhlIFRDUCBNRDUKICAgICAgICAgICAgICBTaWduYXR1 cmUgT3B0aW9uIiwgUkZDIDM1NjIsIEp1bHkgMjAwMy4KCiAgIFtSRkMzNjE4XSAgRmVubmVyLCBC LiBhbmQgRC4gTWV5ZXIsICJNdWx0aWNhc3QgU291cmNlIERpc2NvdmVyeQogICAgICAgICAgICAg IFByb3RvY29sIChNU0RQKSIsIFJGQyAzNjE4LCBPY3RvYmVyIDIwMDMuCgoKCkxlYm92aXR6ICYg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdl IDQxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIFtSRkMzOTczXSAgQWRhbXMsIEEuLCBOaWNob2xh cywgSi4sIGFuZCBXLiBTaWFkYWssICJQcm90b2NvbAogICAgICAgICAgICAgIEluZGVwZW5kZW50 IE11bHRpY2FzdCAtIERlbnNlIE1vZGUgKFBJTS1ETSk6IFByb3RvY29sCiAgICAgICAgICAgICAg U3BlY2lmaWNhdGlvbiAoUmV2aXNlZCkiLCBSRkMgMzk3MywgSmFudWFyeSAyMDA1LgoKICAgW1JG QzQwODZdICBFYXN0bGFrZSwgRC4sIFNjaGlsbGVyLCBKLiwgYW5kIFMuIENyb2NrZXIsICJSYW5k b21uZXNzCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTZWN1cml0eSIsIEJDUCAxMDYs IFJGQyA0MDg2LCBKdW5lIDIwMDUuCgogICBbUkZDNDEwN10gIEJlbGxvdmluLCBTLiBhbmQgUi4g SG91c2xleSwgIkd1aWRlbGluZXMgZm9yIENyeXB0b2dyYXBoaWMKICAgICAgICAgICAgICBLZXkg TWFuYWdlbWVudCIsIEJDUCAxMDcsIFJGQyA0MTA3LCBKdW5lIDIwMDUuCgogICBbUkZDNDI3MV0g IFJla2h0ZXIsIFkuLCBMaSwgVC4sIGFuZCBTLiBIYXJlcywgIkEgQm9yZGVyIEdhdGV3YXkKICAg ICAgICAgICAgICBQcm90b2NvbCA0IChCR1AtNCkiLCBSRkMgNDI3MSwgSmFudWFyeSAyMDA2LgoK ICAgW1JGQzQzMDFdICBLZW50LCBTLiBhbmQgSy4gU2VvLCAiU2VjdXJpdHkgQXJjaGl0ZWN0dXJl IGZvciB0aGUKICAgICAgICAgICAgICBJbnRlcm5ldCBQcm90b2NvbCIsIFJGQyA0MzAxLCBEZWNl bWJlciAyMDA1LgoKICAgW1JGQzQzMDNdICBLZW50LCBTLiwgIklQIEVuY2Fwc3VsYXRpbmcgU2Vj dXJpdHkgUGF5bG9hZCAoRVNQKSIsCiAgICAgICAgICAgICAgUkZDIDQzMDMsIERlY2VtYmVyIDIw MDUuCgogICBbUkZDNDMwNl0gIEthdWZtYW4sIEMuLCAiSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIChJ S0V2MikgUHJvdG9jb2wiLAogICAgICAgICAgICAgIFJGQyA0MzA2LCBEZWNlbWJlciAyMDA1LgoK ICAgW1JGQzQ2MDFdICBGZW5uZXIsIEIuLCBIYW5kbGV5LCBNLiwgSG9sYnJvb2ssIEguLCBhbmQg SS4gS291dmVsYXMsCiAgICAgICAgICAgICAgIlByb3RvY29sIEluZGVwZW5kZW50IE11bHRpY2Fz dCAtIFNwYXJzZSBNb2RlIChQSU0tU00pOgogICAgICAgICAgICAgIFByb3RvY29sIFNwZWNpZmlj YXRpb24gKFJldmlzZWQpIiwgUkZDIDQ2MDEsIEF1Z3VzdCAyMDA2LgoKICAgW1JGQzQ2MTVdICBT b25nLCBKLiwgUG9vdmVuZHJhbiwgUi4sIExlZSwgSi4sIGFuZCBULiBJd2F0YSwgIlRoZQogICAg ICAgICAgICAgIEFkdmFuY2VkIEVuY3J5cHRpb24gU3RhbmRhcmQtQ2lwaGVyLWJhc2VkIE1lc3Nh Z2UKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBDb2RlLVBzZXVkby1SYW5kb20gRnVuY3Rp b24tMTI4IChBRVMtQ01BQy0KICAgICAgICAgICAgICBQUkYtMTI4KSBBbGdvcml0aG0gZm9yIHRo ZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wKICAgICAgICAgICAgICAoSUtFKSIsIFJG QyA0NjE1LCBBdWd1c3QgMjAwNi4KCiAgIFtSRkM0OTQ5XSAgU2hpcmV5LCBSLiwgIkludGVybmV0 IFNlY3VyaXR5IEdsb3NzYXJ5LCBWZXJzaW9uIDIiLAogICAgICAgICAgICAgIFJGQyA0OTQ5LCBB dWd1c3QgMjAwNy4KCiAgIFtSRkM1MDM2XSAgQW5kZXJzc29uLCBMLiwgTWluZWksIEkuLCBhbmQg Qi4gVGhvbWFzLCAiTERQCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiIsIFJGQyA1MDM2LCBP Y3RvYmVyIDIwMDcuCgogICBbUkZDNTIyNl0gIE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQs ICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuCiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0 aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyA1MjI2LAogICAgICAgICAgICAgIE1h eSAyMDA4LgoKCgoKCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkg OSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgNDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKQXV0 aG9ycycgQWRkcmVzc2VzCgogICBHcmVnb3J5IExlYm92aXR6CiAgIEp1bmlwZXIgTmV0d29ya3Ms IEluYy4KICAgMTE5NCBOb3J0aCBNYXRoaWxkYSBBdmUuCiAgIFN1bm55dmFsZSwgQ0EgIDk0MDg5 LTEyMDYKICAgVVMKCiAgIFBob25lOgogICBFbWFpbDogZ3JlZ29yeS5pZXRmQGdtYWlsLmNvbQoK CgoKICAgUGhvbmU6CiAgIEVtYWlsOgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDQzXQoMCgo= --=====================_448520890==_ Content-Type: application/octet-stream; name="draft-lebovitz-kmart-roadmap-03.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-lebovitz-kmart-roadmap-03.txt" CgoKS0FSUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEcuIExlYm92aXR6CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBlcgpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMDUsIDIwMDkKRXhwaXJl czogTWF5IDksIDIwMTAKCgpSb2FkbWFwIGZvciBDcnlwdG9ncmFwaGljIEF1dGhlbnRpY2F0aW9u IG9mIFJvdXRpbmcgUHJvdG9jb2wgUGFja2V0cyBvbgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBXaXJlCiAgICAgICAgICAgICAgICAgICAgZHJhZnQtbGVib3ZpdHota21hcnQt cm9hZG1hcC0wMwoKQWJzdHJhY3QKCiAgIEluIHRoZSBNYXJjaCBvZiAyMDA2IHRoZSBJQUIgaGVs ZCBhIHdvcmtzaG9wIG9uIHRoZSB0b3BpYyBvZgogICAiVW53YW50ZWQgSW50ZXJuZXQgVHJhZmZp YyIuICBUaGUgcmVwb3J0IGZyb20gdGhhdCB3b3Jrc2hvcCBpcwogICBkb2N1bWVudGVkIGluIFJG QyA0OTQ4IFtSRkM0OTQ4XS4gIFNlY3Rpb24gOC4yIG9mIFJGQyA0OTQ4IGNhbGxzIGZvcgogICAi W3RdaWdodGVuaW5nIHRoZSBzZWN1cml0eSBvZiB0aGUgY29yZSByb3V0aW5nIGluZnJhc3RydWN0 dXJlLiIgIEZvdXIKICAgbWFpbiBzdGVwcyB3ZXJlIGlkZW50aWZpZWQgZm9yIGltcHJvdmluZyB0 aGUgc2VjdXJpdHkgb2YgdGhlIHJvdXRpbmcKICAgaW5mcmFzdHJ1Y3R1cmUuICBPbmUgb2YgdGhv c2Ugc3RlcHMgd2FzICJzZWN1cmluZyB0aGUgcm91dGluZwogICBwcm90b2NvbHMnIHBhY2tldHMg b24gdGhlIHdpcmUuIiAgT25lIG1lY2hhbmlzbSBmb3Igc2VjdXJpbmcgcm91dGluZwogICBwcm90 b2NvbCBwYWNrZXRzIG9uIHRoZSB3aXJlIGlzIHRoZSB1c2Ugb2YgcGVyLXBhY2tldCBjcnlwdG9n cmFwaGljCiAgIG1lc3NhZ2UgYXV0aGVudGljYXRpb24sIHByb3ZpZGluZyBib3RoIHBlZXIgYXV0 aGVudGljYXRpb24gYW5kCiAgIG1lc3NhZ2UgaW50ZWdyaXR5LiAgTWFueSBkaWZmZXJlbnQgcm91 dGluZyBwcm90b2NvbHMgZXhpc3QgYW5kIHRoZXkKICAgZW1wbG95IGEgcmFuZ2Ugb2YgZGlmZmVy ZW50IHRyYW5zcG9ydCBzdWJzeXN0ZW1zLiAgVGhlcmVmb3JlIHRoZXJlCiAgIG11c3QgbmVjZXNz YXJpbHkgYmUgdmFyaW91cyBtZXRob2RzIGRlZmluZWQgZm9yIGFwcGx5aW5nCiAgIGNyeXB0b2dy YXBoaWMgYXV0aGVudGljYXRpb24gdG8gdGhlc2UgdmFyeWluZyBwcm90b2NvbHMuICBNYW55CiAg IHJvdXRpbmcgcHJvdG9jb2xzIGFscmVhZHkgaGF2ZSBzb21lIG1ldGhvZCBmb3IgYWNjb21wbGlz aGluZwogICBjcnlwdG9ncmFwaGljIG1lc3NhZ2UgYXV0aGVudGljYXRpb24uICBIb3dldmVyLCBp biBtYW55IGNhc2VzIHRoZQogICBleGlzdGluZyBtZXRob2RzIGFyZSBkYXRlZCwgdnVsbmVyYWJs ZSB0byBhdHRhY2ssIGFuZC9vciBlbXBsb3kKICAgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIHRo YXQgaGF2ZSBiZWVuIGRlcHJlY2F0ZWQuICBUaGlzIGRvY3VtZW50CiAgIGNyZWF0ZXMgYSByb2Fk bWFwIG9mIHByb3RvY29sIHNwZWNpZmljYXRpb24gd29yayBmb3IgdGhlIHVzZSBvZgogICBtb2Rl cm4gY3J5cHRvZ3JwYWhpYyBtZWNoYW5pc21zIGFuZCBhbGdvcml0aG1zIGZvciBtZXNzYWdlCiAg IGF1dGhlbnRpY2F0aW9uIGluIHJvdXRpbmcgcHJvdG9jb2xzLiAgSXQgYWxzbyBkZWZpbmVzIHRo ZSBmcmFtZXdvcmsKICAgZm9yIGEga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgdGhhdCBtYXkgYmUg dXNlZCB0byBjcmVhdGUgYW5kIG1hbmFnZQogICBzZXNzaW9uIGtleXMgZm9yIG1lc3NhZ2UgYXV0 aGVudGljYXRpb24gYW5kIGludGVncml0eS4gIFRoaXMgcm9hZG1hcAogICByZWZsZWN0cyB0aGUg aW5wdXQgb2YgYm90aCB0aGUgc2VjdXJpdHkgYXJlYSBhbmQgcm91dGluZyBhcmVhIGluCiAgIG9y ZGVyIHRvIGZvcm0gYSBqb2ludGx5IGFncmVlZCB1cG9uIGFuZCBwcmlvcml0aXplZCB3b3JrIGxp c3QgZm9yIHRoZQogICBlZmZvcnQuCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVy bmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0 aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRh c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwOQoKCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQK ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgOSwgMjAxMC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENv cHlyaWdodCAoYykgMjAwOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMg ZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwK ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVi bGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRz CiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rp b25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4 dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0 IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAg IGRlc2NyaWJlZCBpbiB0aGUgQlNEIExpY2Vuc2UuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkxl Ym92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAg ICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1h cCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKClRhYmxlIG9mIENvbnRlbnRzCgogICAx LiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQKICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMS4yLiAgUmVxdWlyZW1lbnRzIExhbmd1 YWdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAgIDEuMy4gIFNj b3BlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDYKICAgICAxLjQuICBHb2FscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA4CiAgICAgMS41LiAgTm9uLUdvYWxzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgIDEuNi4gIEF1ZGllbmNlIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgMi4g IFRocmVhdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDEyCiAgICAgMi4xLiAgVGhyZWF0cyBJbiBTY29wZSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgIDIuMi4gIFRocmVhdHMgT3V0IG9mIFNjb3Bl IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgMy4gIENhdGVnb3Jp emluZyBSb3V0aW5nIFByb3RvY29scyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2 CiAgICAgMy4xLiAgQ2F0ZWdvcnk6IE1lc3NhZ2luZyBUcmFuc2FjdGlvbiBUeXBlIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNgogICAgIDMuMi4gIENhdGVnb3J5OiBQZWVyIHZzLiBHcm91cCBLZXlp bmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgICAzLjMuICBDYXRlZ29yeTogIFVw ZGF0ZSB2cy4gRGlzY292ZXJ5IFByb3RvY29sIC4gLiAuIC4gLiAuIC4gLiAuIDE4CiAgICAgMy40 LiAgU2VjdXJpdHkgQ2hhcmFjdGVyaXphdGlvbiBWZWN0b3JzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxOAogICAgICAgMy40LjEuICBJbnRlcm5hbCB2cy4gRXh0ZXJuYWwgT3BlcmF0aW9uICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgICAgIDMuNC4yLiAgVW5pcXVlIHZlcnN1cyBTaGFy ZWQgS2V5cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgICAgICAzLjQuMy4gIE91 dC1vZi1CYW5kIHZzLiBJbi1saW5lIEtleSBNYW5hZ2VtZW50IC4gLiAuIC4gLiAuIC4gLiAyMAog ICA0LiAgVGhlIFJvYWRtYXAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMjIKICAgICA0LjEuICBXb3JrIFBoYXNlcyBvbiBhbnkgUGFydGljdWxhciBQ cm90b2NvbCAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyCiAgICAgNC4yLiAgUmVxdWlyZW1lbnRzIGZv ciBQaGFzZSAxIFJvdXRpbmcgUHJvdG9jb2xzJyBTZWN1cml0eQogICAgICAgICAgIFVwZGF0ZSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQKICAg ICA0LjMuICBDb21tb24gRnJhbWV3b3JrIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI1CiAgICAgNC40LiAgV29yayBJdGVtcyBQZXIgUm91dGluZyBQcm90b2NvbCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMQogICAgIDQuNS4gIFByb3RvY29scyBpbiBDYXRl Z29yaWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzMKICAgICA0LjYuICBQ cmlvcml0ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDM1CiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzNQogICA2LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgNy4gIEFja25vd2xlZGdlbWVu dHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM3CiAgIDgu ICBDaGFuZ2UgSGlzdG9yeSAoUkZDIEVkaXRvcjogRGVsZXRlIEJlZm9yZSBQdWJsaXNoaW5nKSAg LiAuIC4gLiAzNwogICA5LiAgTmVlZHMgV29yayBpbiBOZXh0IERyYWZ0IChSRkMgRWRpdG9yOiBE ZWxldGUgQmVmb3JlCiAgICAgICBQdWJsaXNoaW5nKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MAogICAxMC4gUmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDEKICAgICAxMC4xLiBO b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQxCiAgICAgMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0MQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDIKCgoKCgoKCgoKCgoKCkxlYm92aXR6 ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgICBb UGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEluIE1hcmNo IDIwMDYgdGhlIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBoZWxkIGEgd29ya3No b3AKICAgb24gdGhlIHRvcGljIG9mICJVbndhbnRlZCBJbnRlcm5ldCBUcmFmZmljIi4gIFRoZSBy ZXBvcnQgZnJvbSB0aGF0CiAgIHdvcmtzaG9wIGlzIGRvY3VtZW50ZWQgaW4gUkZDIDQ5NDggW1JG QzQ5NDhdLiAgU2VjdGlvbiA4LjEgb2YgdGhhdAogICBkb2N1bWVudCBzdGF0ZXMgdGhhdCAiQSBz aW1wbGUgcmlzayBhbmFseXNpcyB3b3VsZCBzdWdnZXN0IHRoYXQgYW4KICAgaWRlYWwgYXR0YWNr IHRhcmdldCBvZiBtaW5pbWFsIGNvc3QgYnV0IG1heGltYWwgZGlzcnVwdGlvbiBpcyB0aGUKICAg Y29yZSByb3V0aW5nIGluZnJhc3RydWN0dXJlLiIgIFNlY3Rpb24gOC4yIGNhbGxzIGZvciAiW3Rd aWdodGVuaW5nCiAgIHRoZSBzZWN1cml0eSBvZiB0aGUgY29yZSByb3V0aW5nIGluZnJhc3RydWN0 dXJlLiIgIEZvdXIgbWFpbiBzdGVwcwogICB3ZXJlIGlkZW50aWZpZWQgZm9yIHRoYXQgdGlnaHRl bmluZzoKCiAgIG8gIE1vcmUgc2VjdXJlIG1lY2hhbmlzbXMgYW5kIHByYWN0aWNlcyBmb3Igb3Bl cmF0aW5nIHJvdXRlcnMuICBUaGlzCiAgICAgIHdvcmsgaXMgYmVpbmcgYWRkcmVzc2VkIGluIHRo ZSBPUFNFQyBXb3JraW5nIEdyb3VwLgogICBvICBDbGVhbmluZyB1cCB0aGUgSW50ZXJuZXQgUm91 dGluZyBSZWdpc3RyeSByZXBvc2l0b3J5IFtJUlJdLCBhbmQKICAgICAgc2VjdXJpbmcgYm90aCB0 aGUgZGF0YWJhc2UgYW5kIHRoZSBhY2Nlc3MsIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQKICAgICAg Zm9yIHJvdXRpbmcgdmVyaWZpY2F0aW9ucy4gIFRoaXMgd29yayBzaG91bGQgYmUgYWRkcmVzc2Vk IHRocm91Z2gKICAgICAgbGlhaXNvbnMgd2l0aCB0aG9zZSBydW5uaW5nIHRoZSBJUlIncyBnbG9i YWxseS4KICAgbyAgU3BlY2lmaWNhdGlvbnMgZm9yIGNyeXB0b2dyYXBoaWMgdmFsaWRhdGlvbiBv ZiByb3V0aW5nIG1lc3NhZ2UKICAgICAgY29udGVudC4gIFRoaXMgd29yayB3aWxsIGxpa2VseSBi ZSBhZGRyZXNzZWQgaW4gdGhlIFNJRFIgV29ya2luZwogICAgICBHcm91cC4KICAgbyAgU2VjdXJp bmcgdGhlIHJvdXRpbmcgcHJvdG9jb2xzJyBwYWNrZXRzIG9uIHRoZSB3aXJlCgogICBUaGlzIGRv Y3VtZW50IGFkZHJlc3NlcyB0aGUgbGFzdCBidWxsZXQsIHNlY3VyaW5nIHRoZSBwYWNrZXRzIG9u IHRoZQogICB3aXJlIG9mIHRoZSByb3V0aW5nIHByb3RvY29sIGV4Y2hhbmdlcy4gIFRoZSBkb2N1 bWVudCBhZGRyZXNzZXMKICAgS2V5aW5nIGFuZCBBdXRoZW50aWNhdGlvbiBmb3IgUm91dGluZyBQ cm90b2NvbHMsIGFrYSAiS0FSUCIuCgogICBJdCBpcyB1bmxpa2VseSB0aGF0IHRoaXMgZG9jdW1l bnQsIGluIGl0cyBjdXJyZW50IGZvcm0sIHdpbGwgYmVjb21lCiAgIGFuIFJGQy4gIE1vcmUgbGlr ZWx5IGlzIHRoYXQgdGhpcyBkb2N1bWVudCB3aWxsIGJlIHNwbGl0IHVwIGludG8KICAgc2V2ZXJh bCBzbWFsbGVyIGRvY3VtZW50cyB3aGljaCBtYXkgbG9vayBzb21ldGhpbmcgbGlrZToKCiAgIG8g IFNjb3BlICYgR29hbHMgc2VjdGlvbnMgd2lsbCBsaWtlbHkgYmVjb21lIHBhcnQgb2YgdGhlIEtB UlAgV0cKICAgICAgY2hhcnRlcgogICBvICBUaHJlYXQgZG9jdW1lbnQKICAgbyAgUmVxdWlyZW1l bnRzIGRvY3VtZW50IChtYXkgYmUgY29tYmluZWQgd2l0aCBUaHJlYXQgZG9jdW1lbnQpCiAgIG8g IEZyYW1ld29yayBkb2N1bWVudAogICBvICBSb3V0aW5nUHJvdG9jb2wgRGVzaWduIFRlYW0gV29y ayBQbGFuIGRvY3VtZW50LiAgVGhpcyB3b3VsZAogICAgICBpbmNsdWRlIHNlY3Rpb25zIGxpa2Ug V29yayBQaGFzZXMsIFByaW9yaXRpZXMsIFNlY3VyaXR5CiAgICAgIENvbnNpZGVyYXRpb25zLCBl dGMuCiAgIEZvciBub3csIHRoZSBkb2N1bWVudCBzZXJ2ZXMgYXMgdGhlIGNhdGNoIGFsbCBmb3Ig dGhlIHNldCBvZiB0aG91Z2h0cwogICBhcm91bmQgdGhlIEtBUlAgZWZmb3J0LiAgQXMgYSB3b3Jr aW5nIGdyb3VwIGlzIGZvcm1lZCwgZGVjaXNpb25zIHdpbGwKICAgYmUgbWFkZSBhYm91dCB0aGUg Y3JlYXRpb24gb2Ygc3BlY2lmaWMgZG9jdW1lbnRzLgoKICAgRWRpdG9yJ3MgTm90ZSBvbiAiS01B UlQiIHZzICJLQVJQIjogVGhlIGZpcnN0IGZldyB2ZXJzaW9ucyBvZiB0aGlzCiAgIGRvY3VtZW50 IHdlcmUgY2FsbGVkICJkcmFmdC1sZWJvdml0ei1rbWFydC1yb2FkbWFwLXh4Ii4gIFVwb24gdGhl CiAgIGNyZWF0aW9uIG9mIHRoZSBCb0YgZm9yIElFVEY3NiwgdGhlIElFU0cgcmVxdWVzdGVkIHRo ZSBuYW1lIG9mIHRoZQogICBlZmZvcnQgY2hhbmdlIHNvIGFzIHRvIGF2b2lkIGFueSBwb3RlbnRp YWwgdHJhZGVtYXJrIGlzc3Vlcy4gIFRoZSBuZXcKICAgbmFtZSBvZiB0aGUgZWZmb3J0IGlzIEtB UlAuICBWZXJzaW9uIC0wMyB3aWxsIGdvIG91dCB0aXRsZWQKICAgImRyYWZ0LWxlYm92aXR6LWtt YXJ0LXJvYWRtYXAtMDMiLCBzbyBhcyB0byBhdm9pZCBjb25mdXNpb24uICBBcyBzb29uCgoKCkxl Ym92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAg ICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1h cCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIGFzIHRoZSBJLUQgZWRpdG9yIHF1 ZXVlIG9wZW5zIGFnYWluIChNb25kYXksIDA5IE5vdikgdGhlIGRvY3VtZW50CiAgIHdpbGwgYmUg c3VibWl0dGVkIHdpdGggcy9rbWFydC9rYXJwLyBpbiB0aGUgdGl0bGUuCgoxLjEuICBUZXJtaW5v bG9neQoKICAgV2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LCB0aGUgZm9sbG93aW5n IHdvcmRzLCB3aGVuCiAgIGJlZ2lubmluZyB3aXRoIGEgY2FwaXRhbCBsZXR0ZXIsIG9yIHNwZWxs ZWQgaW4gYWxsIGNhcGl0YWxzLCBob2xkIHRoZQogICBtZWFuaW5ncyBkZXNjcmliZWQgdG8gdGhl IHJpZ2h0IG9mIGVhY2ggdGVybS4gIElmIHRoZSBzYW1lIHdvcmQgaXMKICAgdXNlZCB1bmNhcGl0 YWxpemVkLCB0aGVuIGl0IGlzIGludGVuZGVkIHRvIGhhdmUgaXRzIGNvbW1vbiBlbmdsaXNoCiAg IGRlZmluaXRpb24uCgogICBQU0sgICAgICAgICAgICBQcmUtU2hhcmVkIEtleS4gQSBrZXkgdXNl ZCBieSBib3RoIHBlZXJzIGluIGEgc2VjdXJlCiAgICAgICAgICAgICAgICAgIGNvbmZpZ3VyYXRp b24uICBVc3VhbGx5IGV4Y2hhbmdlZCBvdXQtb2YtYmFuZCBwcmlvciB0bwogICAgICAgICAgICAg ICAgICBhIGZpcnN0IGNvbm5lY3Rpb24uCgogICBSb3V0aW5nIFByb3RvY29sICBXaGVuIHVzZWQg d2l0aCBjYXBpdGFsICJSIiBhbmQgIlAiIGluIHRoaXMgZG9jdW1lbnQKICAgICAgICAgICAgICAg ICAgdGhlIHRlcm0gcmVmZXJzIHRoZSBSb3V0aW5nIFByb3RvY29sIGZvciB3aGljaCB3b3JrIGlz CiAgICAgICAgICAgICAgICAgIGJlaW5nIGRvbmUgdG8gcHJvdmlkZSBvciBlbmhhbmNlIGl0cyBw ZWVyCiAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuCgogICBQUkYg ICAgICAgICAgICBQc2V1ZG9yYW5kb20gbnVtYmVyIGZ1bmN0aW9uLCBvciBzb21ldGltZXMgY2Fs bGVkCiAgICAgICAgICAgICAgICAgIHBzZXVkb3JhbmRvbSBudW1iZXIgZ2VuZXJhdG9yIChQUk5H KS4gIEFuIGFsZ29yaXRobQogICAgICAgICAgICAgICAgICBmb3IgZ2VuZXJhdGluZyBhIHNlcXVl bmNlIG9mIG51bWJlcnMgdGhhdCBhcHByb3hpbWF0ZXMKICAgICAgICAgICAgICAgICAgdGhlIHBy b3BlcnRpZXMgb2YgcmFuZG9tIG51bWJlcnMuICBUaGUgc2VxdWVuY2UgaXMgbm90CiAgICAgICAg ICAgICAgICAgIHRydWx5IHJhbmRvbSwgaW4gdGhhdCBpdCBpcyBjb21wbGV0ZWx5IGRldGVybWlu ZWQgYnkgYQogICAgICAgICAgICAgICAgICByZWxhdGl2ZWx5IHNtYWxsIHNldCBvZiBpbml0aWFs IHZhbHVlcyB0aGF0IGFyZSBwYXNzZWQKICAgICAgICAgICAgICAgICAgaW50byB0aGUgZnVuY3Rp b24uICBBbiBleG1hcGxlIGlzIFNIQS0yNTYuCgogICBLREYgICAgICAgICAgICBLZXkgZGVyaXZh dGlvbiBmdW5jdGlvbi4gIEEgcGFydGljdWxhciBzcGVjaWZpZWQgdXNlCiAgICAgICAgICAgICAg ICAgIG9mIGEgUFJGIHRoYXQgdGFrZXMgYSBQU0ssIGNvbWJpbmVzIGl0IHdpdGggb3RoZXIKICAg ICAgICAgICAgICAgICAgaW5wdXRzIHRvIHRoZSBQUkYsIGFuZCBwcm9kdWNlcyBhIHJlc3VsdCB0 aGF0IGlzCiAgICAgICAgICAgICAgICAgIHN1aXRhYmxlIGZvciB1c2UgYXMgYSBUcmFmZmljIEtl eS4KCiAgIElkZW50aWZpZXIgICAgIFRoZSB0eXBlIGFuZCB2YWx1ZSB1c2VkIGJ5IG9uZSBwZWVy IG9mIGFuCiAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0ZWQgbWVzc2FnZSBleGNoYW5nZSB0 byBzaWduaWZ5IHRvIHRoZSBvdGhlcgogICAgICAgICAgICAgICAgICBwZWVyIHdobyB0aGV5IGFy ZS4gIFRoZSBJZGVudGlmaWVyIGlzIHVzZWQgYnkgdGhlCiAgICAgICAgICAgICAgICAgIHJlY2Vp dmVyIGFzIGEgbG9va3VwIGluZGV4IGludG8gYSB0YWJsZSBjb250YWluaW5nCiAgICAgICAgICAg ICAgICAgIGZ1cnRoZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBlZXIgdGhhdCBpcyByZXF1aXJl ZCB0bwogICAgICAgICAgICAgICAgICBjb250aW51ZSBwcm9jZXNzaW5nIHRoZSBtZXNzYWdlLCBm b3IgZXhhbXBsZSBhCiAgICAgICAgICAgICAgICAgIFNlY3VyaXR5IEFzc29jaWF0aW9uIChTQSkg b3Iga2V5cy4KCiAgIElkZW50aXR5IFByb29mIEEgY3J5cHRvZ3JhcGhpYyBwcm9vZiBmb3IgYW4g YXNzZXJ0ZWQgaWRlbnRpdHksIHRoYXQKICAgICAgICAgICAgICAgICAgdGhlIHBlZXIgcmVhbGx5 IGlzIHdobyB0aGV5IGFzc2VydCB0aGVtc2VsdmVzIHRvIGJlLgogICAgICAgICAgICAgICAgICBQ cm9vZiBvZiBpZGVudGl0eSBjYW4gYmUgYXJyYW5nZWQgYmV0d2VlbiB0aGUgcGVlcnMgaW4KICAg ICAgICAgICAgICAgICAgYSBmZXcgd2F5cywgZm9yIGV4YW1wbGUgUFNLLCByYXcgYXNzeW1ldHJp YyBrZXlzLCBvciBhCiAgICAgICAgICAgICAgICAgIG1vcmUgdXNlci1mcmllbmRseSByZXByZXNl bnRhdGlvbiBvZiBhc3N5bWV0cmljIGtleXMsCiAgICAgICAgICAgICAgICAgIGxpa2UgYSBjZXJ0 aWZpY2F0ZS4KCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIw MTAgICAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCgogICBTZWN1 cml0eSBBc3NvY2lhdGlvbiBvciBTQSAgVGhlIHBhcmFtZXRlcnMgYW5kIGtleXMgdGhhdCB0b2dl dGhlcgogICAgICAgICAgICAgICAgICBmb3JtIHRoZSByZXF1aXJlZCBpbmZvcm1hdGlvbiBmb3Ig cHJvY2Vzc2luZyBzZWN1cmUKICAgICAgICAgICAgICAgICAgc2Vzc2lvbnMgYmV0d2VlbiBwZWVy cy4gIEV4YW1wbGVzIG9mIGl0ZW1zIHRoYXQgbWF5CiAgICAgICAgICAgICAgICAgIGV4aXN0IGlu IGFuIFNBIGluY2x1ZGU6IElkZW50aWZpZXIsIFBTSywgVHJhZmZpYyBLZXksCiAgICAgICAgICAg ICAgICAgIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcywga2V5IGxpZmV0aW1lcy4KCiAgIEtNUCAg ICAgICAgICAgIEtleSBNYW5hZ2VtZW50IFByb3RvY29sLiAgQSBwcm90b2NvbCB1c2VkIGJldHdl ZW4KICAgICAgICAgICAgICAgICAgcGVlcnMgdG8gZXhjaGFuZ2UgU0EgcGFyYW1ldGVycyBhbmQg VHJhZmZpYyBLZXlzLgogICAgICAgICAgICAgICAgICBFeGFtcGxlcyBvZiBLTVBzIGluY2x1ZGUg SUtFLCBUTFMsIGFuZCBTU0guCgogICBLTVAgRnVuY3Rpb24gICBBbnkgYWN0dWFsIEtNUCB1c2Vk IGluIHRoZSBnZW5lcmFsIEtBUlAgc29sdXRpb24KICAgICAgICAgICAgICAgICAgZnJhbWV3b3Jr CgogICBQZWVyIEtleSAgICAgICBLZXlzIHRoYXQgYXJlIHVzZWQgYmV0d2VlbiBwZWVycyBhcyB0 aGUgaWRlbnRpdHkKICAgICAgICAgICAgICAgICAgcHJvb2YuICBUaGVzZSBrZXlzIG1heSBvciBt YXkgbm90IGJlIGNvbm5lY3Rpb24KICAgICAgICAgICAgICAgICAgc3BlY2lmaWMsIGRlcGVuZGlu ZyBvbiB3aG8gdGhleSB3ZXJlIGVzdGFibGlzaGVkLCBhbmQKICAgICAgICAgICAgICAgICAgd2hh dCBmb3JtIG9mIGlkZW50aXR5IGFuZCBpZGVudGl0eSBwcm9vZiBpcyBiZWluZyB1c2VkCiAgICAg ICAgICAgICAgICAgIGluIHRoZSBzeXN0ZW0uCgogICBUcmFmZmljIEtleSAgICBUaGUgYWN0dWFs IGtleSB1c2VkIG9uIGVhY2ggcGFja2V0IG9mIGEgbWVzc2FnZS4KCiAgIERlZmluaXRpb25zIG9m IGl0ZW1zIHNwZWNpZmljIHRvIHRoZSBnZW5lcmFsIEtBUlAgZnJhbWV3b3JrIGFyZQogICBkZXNj cmliZWQgaW4gbW9yZSBkZXRhaWwgaW4gdGhlIEZyYW1ld29yayBzZWN0aW9uIFNlY3Rpb24gNC4z LgoKMS4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZD MjExOSBbUkZDMjExOV0uCgogICBXaGVuIHVzZWQgaW4gbG93ZXIgY2FzZSwgdGhlc2Ugd29yZHMg Y29udmV5IHRoZWlyIHR5cGljYWwgdXNlIGluCiAgIGNvbW1vbiBsYW5ndWFnZSwgYW5kIGFyZSBu b3QgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluCiAgIFJGQzIxMTkgW1JGQzIxMTld LgoKMS4zLiAgU2NvcGUKCiAgIEZvdXIgYmFzaWMgdGFjdGljcyBtYXkgYmUgZW1wbG95ZWQgaW4g b3JkZXIgdG8gc2VjdXJlIGFueSBwaWVjZSBvZgogICBkYXRhIGFzIGl0IGlzIHRyYW5zbWl0dGVk IG92ZXIgdGhlIHdpcmU6IHByaXZhY3kgKG9yIGVuY3J5cHRpb24pLAogICBhdXRoZW50aWNhdGlv biwgbWVzc2FnZSBpbnRlZ3JpdHksIGFuZCBub24tcmVwdWRpYXRpb24uICBUaGUgZm9jdXMKICAg Zm9yIHRoaXMgZWZmb3J0LCBhbmQgdGhlIHNjb3BlIGZvciB0aGlzIHJvYWRtYXAgZG9jdW1lbnQs IHdpbGwgYmUKICAgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBhbmQgcGFja2V0IGludGVncml0eSBv bmx5LiAgVGhpcyB3b3JrCiAgIGV4cGxpY2l0bHkgZXhjbHVkZXMsIGF0IHRoaXMgcG9pbnQgaW4g dGltZSwgdGhlIG90aGVyIHR3byB0YWN0aWNzOgogICBwcml2YWN5IGFuZCBub24tcmVwdWRpYXRp b24uICBTaW5jZSB0aGUgb2JqZWN0aXZlIG9mIG1vc3Qgcm91dGluZwogICBwcm90b2NvbHMgaXMg dG8gYnJvYWRseSBhZHZlcnRpc2UgdGhlIHJvdXRpbmcgdG9wb2xvZ3ksIHJvdXRpbmcKICAgbWVz c2FnZXMgYXJlIGNvbW1vbmx5IHNlbnQgaW4gdGhlIGNsZWFyOyBjb25maWRlbnRpYWxpdHkgaXMg bm90CiAgIG5vcm1hbGx5IHJlcXVpcmVkIGZvciByb3V0aW5nIHByb3RvY29scy4gIEhvd2V2ZXIs IGVuc3VyaW5nIHRoYXQKICAgcm91dGluZyBwZWVycyB0cnVseSBhcmUgdGhlIHRydXN0ZWQgcGVl cnMgZXhwZWN0ZWQsIGFuZCB0aGF0IG5vIHJvcXVlCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwOQoKCiAgIHBlZXJzIG9yIG1lc3NhZ2VzIGNhbiBjb21wcm9taXNlIHRoZSBzdGFi aWxpdHkgb2YgdGhlIHJvdXRpbmcKICAgZW52aXJvbm1lbnQgaXMgY3JpdGljYWwsIGFuZCB0aHVz IG91ciBmb2N1cy4gIFRoZSBvdGhlciB0d28KICAgZXhwbGljaXRseSBleGNsdWRlZCB0YWN0aWNz LCBwcml2YWN5IGFuZCBub24tcmVwdWRpYXRpb24sIG1heSBiZQogICBhZGRyZXNzZWQgaW4gZnV0 dXJlIHdvcmsuCgogICBJdCBpcyBwb3NzaWJsZSBmb3Igcm91dGluZyBwcm90b2NvbCBwYWNrZXRz IHRvIGJlIHRyYW5zbWl0dGVkCiAgIGVtcGxveWluZyBhbGwgZm91ciBzZWN1cml0eSB0YWN0aWNz IG1lbnRpb25lZCBhYm92ZSB1c2luZyBleGlzdGluZwogICBzdGFuZGFyZHMuICBGb3IgZXhhbXBs ZSwgb25lIGNvdWxkIHJ1biB1bmljYXN0LCBsYXllciAzIG9yIGFib3ZlCiAgIHJvdXRpbmcgcHJv dG9jb2wgcGFja2V0cyB0aHJvdWdoIElQc2VjIEVTUCBbUkZDNDMwM10uICBUaGlzIHdvdWxkCiAg IHByb3ZpZGUgdGhlIGFkZGVkIGJlbmVmaXQgb2YgcHJpdmFjeSwgYW5kIG5vbi1yZXB1ZGlhdGlv bi4gIEhvd2V2ZXIsCiAgIHJvdXRlciBwbGF0Zm9ybXMgYW5kIHN5c3RlbXMgaGF2ZSBiZWVuIGZp bmUgdHVuZWQgb3ZlciB0aGUgeWVhcnMgZm9yCiAgIHRoZSBzcGVjaWZpYyBwcm9jZXNzaW5nIG5l Y2Vzc2FyeSBmb3Igcm91dGluZyBwcm90b2NvbHMnIG5vbi0KICAgZW5jYXBzdWxhdGVkIGZvcm1h dHMuICBPcGVyYXRvcnMgYXJlLCB0aGVyZWZvcmUsIHF1aXRlIHJlbHVjdGFudCB0bwogICBleHBs b3JlIG5ldyBwYWNrZXQgZW5jYXBzdWxhdGlvbnMgZm9yIHRoZXNlIHRyaWVkIGFuZCB0cnVlIHBy b3RvY29scy4KCiAgIEluIGFkZGl0aW9uLCBhdCBsZWFzdCBpbiB0aGUgY2FzZSBvZiBCR1AgYW5k IExEUCwgdGhlc2UgcHJvdG9jb2xzCiAgIGFscmVhZHkgaGF2ZSBleGlzdGluZyBtZWNoYW5pc21z IGZvciBjcnlwdG9ncmFwaGljYWxseSBhdXRoZW50aWNhdGluZwogICBhbmQgaW50ZWdyaXR5IGNo ZWNraW5nIHRoZSBwYWNrZXRzIG9uIHRoZSB3aXJlLiAgUHJvZHVjdHMgd2l0aCB0aGVzZQogICBt ZWNoYW5pc21zIGhhdmUgYWxyZWFkeSBiZWVuIHByb2R1Y2VkLCBjb2RlIGhhcyBhbHJlYWR5IGJl ZW4gd3JpdHRlbgogICBhbmQgYm90aCBoYXZlIGJlZW4gb3B0aW1pemVkIGZvciB0aGUgZXhpc3Rp bmcgbWVjaGFuaXNtcy4gIFJhdGhlcgogICB0aGFuIHR1cm4gYXdheSBmcm9tIHRoZXNlIG1lY2hh bmlzbXMsIHdlIHdhbnQgdG8gZW5oYW5jZSB0aGVtLAogICB1cGRhdGluZyB0aGVtIHRvIG1vZGVy biBhbmQgc2VjdXJlIGxldmVscy4KCiAgIFRoZXJlIGFyZSB0d28gbWFpbiB3b3JrIHBoYXNlcyBm b3IgdGhpcyByb2FkbWFwLCBhbmQgZm9yIGFueSBSb3V0aW5nCiAgIFByb3RvY29sIHdvcmsgdW5k ZXJ0YWtlbiBhcyBwYXJ0IG9mIHRoaXMgcm9hZG1hcCAoZGlzY3Vzc2VkIGZ1cnRoZXIKICAgaW4g dGhlIFdvcmsgUGhhc2VzIChTZWN0aW9uIDQuMSkgc2VjdGlvbikuICBUaGUgZmlyc3QgaXMgdG8g ZW5oYW5jZQogICB0aGUgUm91dGluZyBQcm90b2NvbCdzIGN1cnJlbnQgYXV0aGVudGljYXRpb24g bWVjaGFuaXNtLCBlbnN1cmluZyBpdAogICBlbXBsb3lzIG1vZGVybiBjcnlwdG9ncmFwaGljIGFs Z29yaXRobXMgYW5kIG1ldGhvZHMgZm9yIGl0cyBiYXNpYwogICBvcGVyYXRpb25hbCBtb2RlbCwg ZnVsZmlsbGluZyB0aGUgcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gdGhlCiAgIFJlcXVpcmVtZW50 cyAoU2VjdGlvbiA0LjIpIHNlY3Rpb24sIGFuZCBwcm90ZWN0aW5nIGFnYWluc3QgYXMgbWFueSBv ZgogICB0aGUgdGhyZWF0cyBhcyBwb3NzaWJsZSBhcyBkZWZpbmVkIGluIHRoZSBUaHJlYXRzIChT ZWN0aW9uIDIuMSkKICAgc2VjdGlvbi4gIE1hbnkgb2YgdGhlIFJvdXRpbmcgUHJvdG9jb2xzJyBj dXJyZW50IG1lY2hhbmlzbXMgdXNlCiAgIG1hbnVhbCBrZXlzLCBzbyB0aGUgZmlyc3QgcGhhc2Ug dXBkYXRlcyB3aWxsIGZvY3VzIG9uIHNob3JpbmcgdXAgdGhlCiAgIG1hbnVhbCBrZXkgbWVjaGFu aXNtcyB0aGF0IGV4aXN0LgoKICAgVGhlIHNlY29uZCB3b3JrIHBoYXNlIGlzIHRvIGRlZmluZSB0 aGUgdXNlIG9mIGEga2V5IG1hbmFnZW1lbnQKICAgcHJvdG9jb2wgKEtNUCkgZm9yIGNyZWF0aW5n IGFuZCBtYW5hZ2luZyBzZXNzaW9uIGtleXMgdXNlZCBpbiB0aGUKICAgUm91dGluZyBQcm90b2Nv bHMnIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gYW5kIGRhdGEgaW50ZWdyaXR5CiAgIGZ1bmN0aW9u cy4gIEl0IGlzIGludGVuZGVkIHRoYXQgYSBnZW5lcmFsIEtNUCBmcmFtZXdvcmsgLS0gb3IgYSBz bWFsbAogICBudW1iZXIgb2YgZnJhbWV3b3JrcyAtLSBjYW4gYmUgZGVmaW5lZCBhbmQgbGV2ZXJh Z2VkIGZvciBtYW55IFJvdXRpbmcKICAgUHJvdG9jb2xzLgoKICAgVGhlcmVmb3JlLCB0aGUgc2Nv cGUgb2YgdGhpcyByb2FkbWFwIG9mIHdvcmsgaW5jbHVkZXM6CgoKCgoKCgoKTGVib3ZpdHogJiAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgIFtQYWdl IDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAg ICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgbyAgTWFraW5nIHVzZSBvZiBleGlzdGluZyByb3V0 aW5nIHByb3RvY29sIHNlY3VyaXR5IHByb3RvY29scywgd2hlcmUKICAgICAgdGhleSBleGlzdCwg YW5kIGVuaGFuY2luZyBvciB1cGRhdGluZyB0aGVtIGFzIG5lY2Vzc2FyeSBmb3IgbW9kZXJuCiAg ICAgIGNyeXB0b2dyYXBoaWMgYmVzdCBwcmFjdGljZXMsCgogICBvICBEZXZlbG9waW5nIGEgZnJh bWV3b3JrIGZvciB1c2luZyBhdXRvbWF0aWMga2V5IG1hbmFnZW1lbnQgaW4gb3JkZXIKICAgICAg dG8gZWFzZSBkZXBsb3ltZW50LCBsb3dlciBjb3N0IG9mIG9wZXJhdGlvbiwgYW5kIGFsbG93IGZv ciByYXBpZAogICAgICByZXNwb25zZXMgdG8gc2VjdXJpdHkgYnJlYWNoZXMsIGFuZAoKICAgbyAg U3BlY2lmeWluZyB0aGUgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50IHByb3RvY29sIHRoYXQgbWF5 IGJlCiAgICAgIGNvbWJpbmVkIHdpdGggdGhlIGJpdHMtb24tdGhlLXdpcmUgbWVjaGFuaXNtcy4K CiAgIFRoZSB3b3JrIGFsc28gc2VydmVzIGFzIGFuIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBSb3V0 aW5nIEFyZWEgYW5kIHRoZQogICBTZWN1cml0eSBBcmVhIGFib3V0IHRoZSBwcmlvcml0aWVzIGFu ZCB3b3JrIHBsYW4gZm9yIGluY3JlbWVudGFsbHkKICAgZGVsaXZlcmluZyB0aGUgYWJvdmUgd29y ay4gIFRoaXMgcG9pbnQgaXMgaW1wb3J0YW50LiAgVGhlcmUgd2lsbCBiZQogICB0aW1lcyB3aGVu IHRoZSBiZXN0LXNlY3VyaXR5LXBvc3NpYmxlIHdpbGwgZ2l2ZSB3YXkgdG8gdmFzdGx5LQogICBp bXByb3ZlZC1vdmVyLWN1cnJlbnQtc2VjdXJpdHktYnV0LWFkbWl0dGVkbHktbm90LXlldC1iZXN0 LXNlY3VyaXR5LQogICBwb3NzaWJsZSwgaW4gb3JkZXIgdGhhdCBpbmNyZW1lbnRhbCBwcm9ncmVz cyB0b3dhcmQgYSBtb3JlIHNlY3VyZQogICBJbnRlcm5ldCBtYXkgYmUgYWNoaWV2ZWQuICBBcyBz dWNoLCB0aGlzIGRvY3VtZW50IHdpbGwgY2FsbCBvdXQKICAgcGxhY2VzIHdoZXJlIGFncmVlbWVu dCBoYXMgYmVlbiByZWFjaGVkIG9uIHN1Y2ggdHJhZGUgb2Zmcy4KCiAgIFRoaXMgZG9jdW1lbnQg ZG9lcyBub3QgY29udGFpbiBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gIEluc3RlYWQsIGl0CiAg IGRlZmluZXMgdGhlIGFyZWFzIHdoZXJlIHByb3RvY29sIHNwZWNpZmljYXRpb24gd29yayBpcyBu ZWVkZWQgYW5kCiAgIHNldHMgYSBkaXJlY3Rpb24sIGEgc2V0IG9mIHJlcXVpcmVtZW50cywgYW5k IGEgcmVsYXRpdmUgcHJpb3JpdHkgZm9yCiAgIGFkZHJlc3NpbmcgdGhhdCBzcGVjaWZpY2F0aW9u IHdvcmsuCgogICBUaGVyZSBhcmUgYSBzZXQgb2YgdGhyZWF0cyB0byByb3V0aW5nIHByb3RvY29s cyB0aGF0IGFyZSBjb25zaWRlcmVkCiAgIGluLXNjb3BlIGZvciB0aGlzIGRvY3VtZW50L3JvYWRt YXAsIGFuZCBhIHNldCBjb25zaWRlcmVkIG91dC1vZi0KICAgc2NvcGUuICBUaGVzZSBhcmUgZGVz Y3JpYmVkIGluIGRldGFpbCBpbiB0aGUgVGhyZWF0cyAoU2VjdGlvbiAyKQogICBzZWN0aW9uIGJl bG93LgoKMS40LiAgR29hbHMKCiAgIFRoZSBnb2FscyBhbmQgZ2VuZXJhbCBndWlkYW5jZSBmb3Ig dGhpcyB3b3JrIHJvYWRtYXAgZm9sbG93OgoKICAgMS4gUHJvdmlkZSBhdXRoZW50aWNhdGlvbiBh bmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHBhY2tldHMgb24gdGhlCiAgICAgIHdpcmUgb2Yg ZXhpc3Rpbmcgcm91dGluZyBwcm90b2NvbHMKCiAgIDIuIERlbGl2ZXIgYSBwYXRoIHRvIGluY3Jl bWVudGFsbHkgaW1wcm92ZSBzZWN1cml0eSBvZiB0aGUgcm91dGluZwogICAgICBpbmZyYXN0cnVj dHVyZS4gIFRoZSBwcmluY2lwbGUgb2YgY3Jhd2wsIHdhbGssIHJ1biB3aWxsIGJlIGluCiAgICAg IHBsYWNlLiAgUm91dGluZyBwcm90b2NvbCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIG1heSBu b3QgZ28KICAgICAgaW1tZWRpYXRlbHkgZnJvbSB0aGVpciBjdXJyZW50IHN0YXRlIHRvIGEgc3Rh dGUgY29udGFpbmluZyB0aGUKICAgICAgYmVzdCBwb3NzaWJsZSwgbW9zdCBtb2Rlcm4gc2VjdXJp dHkgcHJhY3RpY2VzLiAgSW5jcmVtZW50YWwgc3RlcHMKICAgICAgd2lsbCBuZWVkIHRvIGJlIHRh a2VuIGZvciBhIGZldyB2ZXJ5IHByYWN0aWNhbCByZWFzb25zLiAgRmlyc3QsCiAgICAgIHRoZXJl IGFyZSBhIGNvbnNpZGVyYWJsZSBudW1iZXIgb2YgZGVwbG95ZWQgcm91dGluZyBkZXZpY2VzIGlu CiAgICAgIG9wZXJhdGluZyBuZXR3b3JrcyB0aGF0IHdpbGwgbm90IGJlIGFibGUgdG8gcnVuIHRo ZSBtb3N0IG1vZGVybgogICAgICBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMgd2l0aG91dCBzaWdu aWZpY2FudCBhbmQgdW5hY2NlcHRhYmxlCiAgICAgIHBlcmZvcm1hbmNlIHBlbmFsdGllcy4gIFRo ZSByb2FkbWFwIGZvciBhbnkgb25lIHJvdXRpbmcgcHJvdG9jb2wKICAgICAgTVVTVCBhbGxvdyBm b3IgaW5jcmVtZW50YWwgaW1wcm92ZW1lbnRzIG9uIGV4aXN0aW5nIG9wZXJhdGlvbmFsCgoKCkxl Ym92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAg ICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1h cCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgICAgIGRldmljZXMuICBTZWNvbmQs IGN1cnJlbnQgcm91dGluZyBwcm90b2NvbCBwZXJmb3JtYW5jZSBvbiBkZXBsb3llZAogICAgICBk ZXZpY2VzIGhhcyBiZWVuIGFjaGlldmVkIG92ZXIgdGhlIGxhc3QgMjAgeWVhcnMgdGhyb3VnaCBl eHRlbnNpdmUKICAgICAgdHVuaW5nIG9mIHNvZnR3YXJlIGFuZCBoYXJkd2FyZSBlbGVtZW50cywg YW5kIGlzIGEgY29uc3RhbnQgZm9jdXMKICAgICAgZm9yIGltcHJvdmVtZW50IGJ5IHZlbmRvcnMg YW5kIG9wZXJhdG9ycyBhbGlrZS4gIFRoZSBpbnRyb2R1Y3Rpb24KICAgICAgb2YgbmV3IHNlY3Vy aXR5IG1lY2hhbmlzbXMgYWZmZWN0cyB0aGlzIHBlcmZvcm1hbmNlIGJhbGFuY2UuICBUaGUKICAg ICAgcGVyZm9ybWFuY2UgaW1wYWN0IG9mIGFueSBpbmNyZW1lbnRhbCBzdGVwIG9mIHNlY3VyaXR5 IGltcHJvdmVtZW50CiAgICAgIHdpbGwgbmVlZCB0byBiZSB3ZWlnaGVkIGJ5IHRoZSBjb21tdW5p dHksIGFuZCBpbnRyb2R1Y2VkIGluIHN1Y2ggYQogICAgICB3YXkgdGhhdCBhbGxvd3MgdGhlIHZl bmRvciBhbmQgb3BlcmF0b3IgY29tbXVuaXR5IGEgcGF0aCB0bwogICAgICBhZG9wdGlvbiB0aGF0 IHVwaG9sZHMgcmVhc29uYWJsZSBwZXJmb3JtYW5jZSBtZXRyaWNzLiAgVGhlcmVmb3JlLAogICAg ICBjZXJ0YWluIHNwZWNpZmljYXRpb24gZWxlbWVudHMgbWF5IGJlIGludHJvZHVjZWQgY2Fycnlp bmcgdGhlCiAgICAgICJTSE9VTEQiIGd1aWRhbmNlLCB3aXRoIHRoZSBpbnRlbnRpb24gdGhhdCB0 aGUgc2FtZSBtZWNoYW5pc20gd2lsbAogICAgICBjYXJyeSBhICJNVVNUIiBpbiB0aGUgbmV4dCBy ZWxlYXNlIG9mIHRoZSBzcGVjaWZpY2F0aW9uLiAgVGhpcwogICAgICBnaXZlcyB0aGUgdmVuZG9y cyBhbmQgaW1wbGVtZW50b3JzIHRoZSBndWlkYW5jZSB0aGV5IG5lZWQgdG8gdHVuZQogICAgICB0 aGVpciBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgYXBwcm9wcmlhdGVseSBvdmVyIHRpbWUuICBMYXN0 LCBzb21lCiAgICAgIHNlY3VyaXR5IG1lY2hhbmlzbXMgcmVxdWlyZSB0aGUgYnVpbGQgb3V0IG9m IG90aGVyIG9wZXJhdGlvbmFsCiAgICAgIHN1cHBvcnQgc3lzdGVtcywgYW5kIHRoaXMgd2lsbCB0 YWtlIHRpbWUuICBBbiBleGFtcGxlIHdoZXJlIHRoZXNlCiAgICAgIHRocmVlIHJlYXNvbnMgYXJl IGF0IHBsYXkgaW4gYW4gaW5jcmVtZW50YWwgaW1wcm92ZW1lbnQgcm9hZG1hcCBpcwogICAgICBz ZWVuIGluIHRoZSBpbXByb3ZlbWVudCBvZiBCR1AncyBbUkZDNDI3MV0gc2VjdXJpdHkgdmlhIHRo ZSB1cGRhdGUKICAgICAgb2YgdGhlIFRDUCBBdXRoZW50aWNhdGlvbiBPcHRpb24gKFRDUC1BTykK ICAgICAgW0ktRC5pZXRmLXRjcG0tdGNwLWF1dGgtb3B0XSBlZmZvcnQuICBJdCB3b3VsZCBiZSBp ZGVhbCwgYW5kCiAgICAgIHJlZmxlY3QgYmVzdCBjb21tb24gc2VjdXJpdHkgcHJhY3RpY2UsIHRv IGhhdmUgYSBmdWxseSBzcGVjaWZpZWQKICAgICAga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9y IG5lZ290aWF0aW5nIFRDUC1BTydzIGF1dGhlbnRpY2F0aW9uCiAgICAgIG1hdGVyaWFsLCB1c2lu ZyBjZXJ0aWZpY2F0ZXMgZm9yIHBlZXIgYXV0aGVudGljYXRpb24gaW4gdGhlCiAgICAgIGtleWlu Zy4gIEhvd2V2ZXIsIGluIHRoZSBzcGlyaXQgb2YgaW5jcmVtZW50YWwgZGVwbG95bWVudCwgd2Ug d2lsbAogICAgICBmaXJzdCBhZGRyZXNzIGlzc3VlcyBsaWtlIGNyeXB0b2dyYXBoaWMgYWxnb3Jp dGhtIGFnaWxpdHksIHJlcGxheQogICAgICBhdHRhY2tzLCBUQ1Agc2Vzc2lvbiByZXNldHRpbmcg aW4gdGhlIGJhc2UgVENQLUFPIHByb3RvY29sIGJlZm9yZQogICAgICB3ZSBsYXllciBrZXkgbWFu YWdlbWVudCBvbiB0b3Agb2YgaXQuCgogICAzLiBUaGUgZGVwbG95LWFiaWxpdHkgb2YgdGhlIGlt cHJvdmVkIHNlY3VyaXR5IHNvbHV0aW9ucyBvbiBjdXJyZW50bHkKICAgICAgcnVubmluZyByb3V0 aW5nIGluZnJhc3RydWN0dXJlIGVxdWlwbWVudC4gIFRoaXMgYmVncyB0aGUKICAgICAgY29uc2lk ZXJhdGlvbiBvZiB0aGUgY3VycmVudCBzdGF0ZSBvZiBwcm9jZXNzaW5nIHBvd2VyIGF2YWlsYWJs ZQogICAgICBvbiByb3V0ZXJzIGluIHRoZSBuZXR3b3JrIHRvZGF5LgoKICAgNC4gT3BlcmF0aW9u YWwgZGVwbG95LWFiaWxpdHkgLSBBIHNvbHV0aW9ucyBhY2NlcHRhYmlsaXR5IHdpbGwgYWxzbwog ICAgICBiZSBtZWFzdXJlZCBieSBob3cgZGVwbG95YWJsZSB0aGUgc29sdXRpb24gaXMgYnkgY29t bW9uIG9wZXJhdG9yCiAgICAgIHRlYW1zIHVzaW5nIGNvbW1vbiBkZXBsb3ltZW50IHByb2Nlc3Nl cyBhbmQgaW5mcmFzdHJ1Y3R1cmVzLiAgSS5lLgogICAgICBXZSB3aWxsIHRyeSB0byBtYWtlIHRo ZXNlIHNvbHV0aW9ucyBmaXQgYXMgd2VsbCBhcyBwb3NzaWJsZSBpbnRvCiAgICAgIGN1cnJlbnQg b3BlcmF0aW9uYWwgcHJhY3RpY2VzIG9yIHJvdXRlciBkZXBsb3ltZW50LiAgVGhpcyB3aWxsIGJl CiAgICAgIGhlYXZpbHkgaW5mbHVlbmNlZCBieSBvcGVyYXRvciBpbnB1dCwgdG8gZW5zdXJlIHRo YXQgd2hhdCB3ZQogICAgICBzcGVjaWZ5IGNhbiAtLSBhbmQsIG1vcmUgaW1wb3J0YW50bHksIHdp bGwgLS0gYmUgZGVwbG95ZWQgb25jZQogICAgICBzcGVjaWZpZWQgYW5kIGltcGxlbWVudGVkIGJ5 IHZlbmRvcnMuICBEZXBsb3ltZW50IG9mIGluY3JlbWVudGFsbHkKICAgICAgbW9yZSBzZWN1cmUg cm91dGluZyBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgSW50ZXJuZXQgaXMgdGhlIGZpbmFsCiAgICAg IG1lYXN1cmUgb2Ygc3VjY2Vzcy4gIE1lYXN1cmFibHksIHdlIHdvdWxkIGxpa2UgdG8gc2VlIGFu IGluY3JlYXNlCiAgICAgIGluIHRoZSBudW1iZXIgb2Ygc3VydmV5ZWQgcmVzcG9uZGVudHMgd2hv IHJlcG9ydCBkZXBsb3lpbmcgdGhlCiAgICAgIHVwZGF0ZWQgYXV0aGVudGljYXRpb24gbWVjaGFu aXNtcyBhbnl3aGVyZSBhY3Jvc3MgdGhlaXIgbmV0d29yaywKICAgICAgYXMgd2VsbCBhcyBhIHNo YXJwIHJpc2UgaW4gdXNhZ2UgZm9yIHRoZSB0b3RhbCBwZXJjZW50YWdlIG9mIHRoZWlyCiAgICAg IG5ldHdvcmsncyByb3V0ZXJzLgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5 CgoKCiAgICAgIEludGVydmlld3Mgd2l0aCBvcGVyYXRvcnMgc2hvdyBzZXZlcmFsIHBvaW50cyBh Ym91dCByb3V0aW5nCiAgICAgIHNlY3VyaXR5LiAgRmlyc3QsIG92ZXIgNzAlIG9mIG9wZXJhdG9y cyBoYXZlIGRlcGxveWVkIHRyYW5zcG9ydAogICAgICBjb25uZWN0aW9uIHByb3RlY3Rpb24gdmlh IFRDUC1NRDUgb24gdGhlaXIgRUJHUCBbSVNSMjAwOF0gLiAgT3ZlcgogICAgICA1NSUgYWxzbyBk ZXBsb3kgTUQ1IG9uIHRoZWlyIElCR1AgY29ubmVjdGlvbnMsIGFuZCA1MCUgZGVwbG95IE1ENQog ICAgICBvbiBzb21lIG90aGVyIElHUC4gIFRoZSBzdXJ2ZXkgc3RhdGVzIHRoYXQgImEgY29uc2lk ZXJhYmxlCiAgICAgIGluY3JlYXNlIHdhcyBvYnNlcnZlZCBvdmVyIHByZXZpb3VzIGVkaXRpb25z IG9mIHRoZSBzdXJ2ZXkgZm9yIHVzZQogICAgICBvZiBUQ1AgTUQ1IHdpdGggZXh0ZXJuYWwgcGVl cnMgKGVCR1ApLCBpbnRlcm5hbCBwZWVycyAoaUJHUCkgYW5kCiAgICAgIE1ENSBleHRlbnNpb25z IGZvciBJR1BzLiIgIFRob3VnaCB0aGUgZGF0YSBpcyBub3QgY2FwdHVyZWQgaW4gdGhlCiAgICAg IHJlcG9ydCwgdGhlIGF1dGhvcnMgYmVsaWV2ZSBhbmVjZG90YWxseSB0aGF0IG9mIHRob3NlIHdo byBoYXZlCiAgICAgIGRlcGxveWVkIE1ENSBzb21ld2hlcmUgaW4gdGhlaXIgbmV0d29yaywgb25s eSBhYm91dCAyNS0zMCUgb2YgdGhlCiAgICAgIHJvdXRlcnMgaW4gdGhlaXIgbmV0d29yayBhcmUg ZGVwbG95ZWQgd2l0aCB0aGUgYXV0aGVudGljYXRpb24KICAgICAgZW5hYmxlZC4gIE5vbmUgcmVw b3J0IHVzaW5nIElQc2VjIHRvIHByb3RlY3QgdGhlIHJvdXRpbmcgcHJvdG9jb2wsCiAgICAgIGFu ZCB0aGlzIHdhcyBhIGRlY2xpbmUgZnJvbSB0aGUgZmV3IHRoYXQgcmVwb3J0ZWQgZG9pbmcgc28g aW4gdGhlCiAgICAgIHByZXZpb3VzIHllYXIncyByZXBvcnQuCiAgICAgIEZyb20gbXkgcGVyc29u YWwgY29udmVyc2F0aW9ucyB3aXRoIG9wZXJhdG9ycywgb2YgdGhvc2UgdXNpbmcgTUQ1LAogICAg ICBhbG1vc3QgYWxsIHJlcG9ydCBkZXBsb3lpbmcgd2l0aCBvbmUgc2luZ2xlIG1hbnVhbCBrZXkg dGhyb3VnaG91dAogICAgICB0aGUgZW50aXJlIG5ldHdvcmsuICBUaGVzZSBzYW1lIG9wZXJhdG9y cyByZXBvcnQgdGhhdCB0aGUgb25lCiAgICAgIHNpbmdsZSBrZXkgaGFzIG5vdCBiZWVuIGNoYW5n ZWQgc2luY2UgaXQgd2FzIG9yaWdpbmFsbHkgaW5zdGFsbGVkLAogICAgICBzb21ldGltZXMgZml2 ZSBvciBtb3JlIHllYXJzIGFnby4gIFdoZW4gYXNrZWQgd2h5LCBwYXJ0aWN1bGFybHkKICAgICAg Zm9yIHRoZSBjYXNlIG9mIEJHUCB1c2luZyBUQ1AgTUQ1LCB0aGUgZm9sbG93aW5nIHJlYXNvbnMg YXJlIG9mdGVuCiAgICAgIGdpdmVuOgoKCiAgICAgIEEuICBDaGFuZ2luZyB0aGUga2V5cyB0cmln Z2VycyBhIFRDUCByZXNldCwgYW5kIHRodXMgYm91bmNlcyB0aGUKICAgICAgICAgIGxpbmtzL2Fk amFjZW5jaWVzLCB1bmRlcm1pbmluZyBTZXJ2aWNlIExldmVsIEFncmVlbWVudHMKICAgICAgICAg IChTTEFzKS4KICAgICAgQi4gIEZvciBleHRlcm5hbCBwZWVycywgZGlmZmljdWx0eSBvZiBjb29y ZGluYXRpb24gd2l0aCB0aGUgb3RoZXIKICAgICAgICAgIG9yZ2FuaXphdGlvbiBpcyBhbiBpc3N1 ZS4gIE9uY2UgdGhleSBmaW5kIHRoZSBjb3JyZWN0IGNvbnRhY3QKICAgICAgICAgIGF0IHRoZSBv dGhlciBvcmdhbml6YXRpb24gKG5vdCBhbHdheXMgc28gZWFzeSksIHRoZQogICAgICAgICAgY29v cmRpbmF0aW9uIGZ1bmN0aW9uIGlzIHNlcmlhbGl6ZWQgYW5kIG9uIGEgcGVyIHBlZXIvQVMKICAg ICAgICAgIGJhc2lzLiAgVGhlIGNvb3JkaW5hdGlvbiBpcyB2ZXJ5IGN1bWJlcnNvbWUgYW5kIHRl ZGlvdXMgdG8KICAgICAgICAgIGV4ZWN1dGUgaW4gcHJhY3RpY2UuCiAgICAgIEMuICBLZXlzIG11 c3QgYmUgY2hhbmdlZCBhdCBwcmVjaXNlbHkgdGhlIHNhbWUgdGltZSwgb3IgYXQgbGVhc3QKICAg ICAgICAgIHdpdGhpbiA2MCBzZWNvbmRzIChhcyBzdXBwb3J0ZWQgYnkgdHdvIG1ham9yIHZlbmRv cnMpIGluIG9yZGVyCiAgICAgICAgICB0byBsaW1pdCBjb25uZWN0aXZpdHkgb3V0YWdlIGR1cmF0 aW9uLiAgVGhpcyBpcyBpbmNyZWRpYmx5CiAgICAgICAgICBkaWZmaWN1bHQgdG8gZG8sIG9wZXJh dGlvbmFsbHksIGVzcGVjaWFsbHkgYmV0d2VlbiBkaWZmZXJlbnQKICAgICAgICAgIG9yZ2FuaXph dGlvbnMuCiAgICAgIEQuICBSZWxhdGl2ZWx5IGxvdyBwcmlvcml0eSBjb21wYXJlZCB0byBvdGhl ciBvcGVyYXRvaW5hbCBpc3N1ZXMuCiAgICAgIEUuICBMYWNrIG9mIHN0YWZmIHRvIGltcGxlbWVu dCB0aGUgY2hhbmdlcyBkZXZpY2UgYnkgZGV2aWNlLgogICAgICBGLiAgVGhlcmUgYXJlIHRocmVl IHVzZSBjYXNlcyBmb3Igb3BlcmF0aW9uYWwgcGVlcmluZyBhdCBwbGF5CiAgICAgICAgICBoZXJl OiBwZWVycyBhbmQgaW50ZXJjb25uZWN0aW9uIHdpdGggb3RoZXIgb3BlcmF0b3JzLCBJbnRlcm5h bAogICAgICAgICAgQkdQIGFuZCBvdGhlciByb3V0aW5nIHNlc3Npb25zIHdpdGhpbiBhIHNpbmds ZSBvcGVyYXRvciwgYW5kCiAgICAgICAgICBvcGVyYXRvci10by1jdXN0b21lci1DUEUgZGV2aWNl cy4gIEFsbCB0aHJlZSBoYXZlIHZlcnkKICAgICAgICAgIGRpZmZlcmVudCBwcm9wZXJ0aWVzLCBh bmQgYWxsIGFyZSByZXBvcnRlZCBhcyBjdW1iZXJzb21lLiAgT25lCiAgICAgICAgICBvcGVyYXRv ciByZXBvcnRlZCB0aGF0IHRoZSBzYW1lIGtleSBpcyB1c2VkIGZvciBhbGwgY3VzdG9tZXIKICAg ICAgICAgIHByZW1pc2UgZXF1aXBtZW50LiAgVGhlIHNhbWUgb3BlcmF0b3IgcmVwb3J0ZWQgdGhh dCBpZiB0aGUKICAgICAgICAgIGN1c3RvbWVyIG1hbmRhdGVkLCBhIHVuaXF1ZSBrZXkgY291bGQg YmUgY3JlYXRlZCwgYWx0aG91Z2ggdGhlCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4 cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIg MjAwOQoKCiAgICAgICAgICBsYXN0IHRpbWUgdGhpcyBvY2N1cnJlZCBpdCBjcmVhdGVkIHN1Y2gg YW4gb3BlcmF0aW9uYWwKICAgICAgICAgIGhlYWRhY2hlIHRoYXQgdGhlIGFkbWluaXN0cmF0b3Jz IG5vdyB1c3VhbGx5IHRlbGwgY3VzdG9tZXJzCiAgICAgICAgICB0aGF0IHRoZSBvcHRpb24gZG9l c24ndCBldmVuIGV4aXN0LCB0byBhdm9pZCB0aGUgZGlmZmljdWx0aWVzLgogICAgICAgICAgVGhl c2UgY3VzdG9tZXItdW5pcWUga2V5cyBhcmUgbmV2ZXIgY2hhbmdlZCwgdW5sZXNzIHRoZQogICAg ICAgICAgY3VzdG9tZXIgZGVtYW5kcyBzby4KICAgICAgVGhlIG1haW4gdGhyZWF0IGF0IHBsYXkg aGVyZSBpcyB0aGF0IGEgdGVybWluYXRlZCBlbXBsb3llZSBmcm9tCiAgICAgIHN1Y2ggYW4gb3Bl cmF0b3Igd2hvIGhhZCBhY2Nlc3MgdG8gdGhlIG9uZSAob3IgZmV3KSBrZXlzIHVzZWQgZm9yCiAg ICAgIGF1dGhlbnRpY2F0aW9uIGluIHRoZXNlIGVudmlyb25tZW50cyBjb3VsZCBlYXNpbHkgd2Fn ZSBhbiBhdHRhY2sKICAgICAgLS0gb3Igb2ZmZXIgdGhlIGtleXMgdG8gb3RoZXJzIHdobyB3b3Vs ZCB3YWdlIHRoZSBhdHRhY2sgLS0gYW5kCiAgICAgIGJyaW5nIGRvd24gbWFueSBvZiB0aGUgYWRq YWNlbmNpZXMsIGNhdXNpbmcgZGVzdGFiaWxpemF0aW9uIHRvIHRoZQogICAgICByb3V0aW5nIHN5 c3RlbS4KCiAgICAgIFdoYXRldmVyIG1lY2hhbmlzbXMgd2Ugc3BlY2lmeSBuZWVkIHRvIGJlIGVh c2llciB0aGFuIHRoZSBjdXJyZW50CiAgICAgIG1ldGhvZHMgdG8gZGVwbG95LCBhbmQgc2hvdWxk IHByb3ZpZGUgb2J2aW91cyBvcGVyYXRpb25hbAogICAgICBlZmZpY2llbmN5IGdhaW5zIGFsb25n IHdpdGggc2lnbmlmaWNhbnRseSBiZXR0ZXIgc2VjdXJpdHkgYW5kCiAgICAgIHRocmVhdCBwcm90 ZWN0aW9uLiAgVGhpcyBjb21iaW5hdGlvbiBvZiB2YWx1ZSBtYXkgYmUgZW5vdWdoIHRvCiAgICAg IGRyaXZlIG11Y2ggYnJvYWRlciBhZG9wdGlvbi4KCiAgIDUuIEFkZHJlc3MgdGhlIHRocmVhdHMg ZW51bWVyYXRlZCBhYm92ZSBpbiB0aGUgIlRocmVhdHMiIHNlY3Rpb24KICAgICAgKFNlY3Rpb24g MikgZm9yIGVhY2ggcm91dGluZyBwcm90b2NvbCwgYWxvbmcgYSByb2FkbWFwLiAgTm90IGFsbAog ICAgICB0aHJlYXRzIG1heSBiZSBhYmxlIHRvIGJlIGFkZHJlc3NlZCBpbiB0aGUgZmlyc3Qgc3Bl Y2lmaWNhdGlvbgogICAgICB1cGRhdGUgZm9yIGFueSBvbmUgcHJvdG9jb2wuICBSb2FkbWFwcyB3 aWxsIGJlIGRlZmluZWQgc28gdGhhdAogICAgICBib3RoIHRoZSBzZWN1cml0eSBhcmVhIGFuZCB0 aGUgcm91dGluZyBhcmVhIGFncmVlIG9uIGhvdyB0aGUKICAgICAgdGhyZWF0cyB3aWxsIGJlIGFk ZHJlc3NlZCBjb21wbGV0ZWx5IG92ZXIgdGltZS4KCiAgIDYuIENyZWF0ZSBhIHJlLXVzYWJsZSBh cmNoaXRlY3R1cmUsIGZyYW1ld29yaywgYW5kIGd1aWRlbGluZXMgZm9yCiAgICAgIHZhcmlvdXMg SUVURiB3b3JraW5nIHRlYW1zIHdobyB3aWxsIGFkZHJlc3MgdGhlc2Ugc2VjdXJpdHkKICAgICAg aW1wcm92ZW1lbnRzIGZvciB2YXJpb3VzIFJvdXRpbmcgUHJvdG9jb2xzLiAgVGhlIGNydXggb2Yg dGhlIEtBUlAKICAgICAgd29yayBpcyB0byByZS11c2UgdGhhdCBmcmFtZXdvcmsgYXMgbXVjaCBh cyBwb3NzaWJsZSBhY3Jvc3MKICAgICAgcmVsZXZhbnQgUm91dGluZyBQcm90b2NvbHMuICBGb3Ig ZXhhbXBsZSwgZGVzaWduZXJzIHNob3VsZCBhaW0gdG8KICAgICAgcmUtdXNlIHRoZSBrZXkgbWFu YWdlbWVudCBwcm90b2NvbCB0aGF0IHdpbGwgYmUgZGVmaW5lZCBmb3IgQkdQJ3MKICAgICAgVENQ LUFPIGtleSBlc3RhYmxpc2htZW50IGZvciBhcyBtYW55IG90aGVyIHJvdXRpbmcgcHJvdG9jb2xz IGFzCiAgICAgIHBvc3NpYmxlLiAgVGhpcyBpcyBidXQgb25lIGV4YW1wbGUuCgogICA3LiBCcmlk Z2UgYW55IGdhcHMgYmV0d2VlbiBJRVRGJ3MgUm91dGluZyBhbmQgU2VjdXJpdHkgQXJlYXMgYnkK ICAgICAgcmVjb3JkaW5nIGFncmVlbWVudHMgb24gd29yayBpdGVtcywgcm9hZG1hcHMsIGFuZCBn dWlkYW5jZSBmcm9tCiAgICAgIHRoZSBBcmVhIGxlYWRzIGFuZCBJbnRlcm5ldCBBcmNoaXRlY3R1 cmUgQm9hcmQgKElBQiwgd3d3LmlhYi5vcmcpLgoKCjEuNS4gIE5vbi1Hb2FscwoKICAgVGhlIGZv bGxvd2luZyB0d28gZ29hbHMgYXJlIGNvbnNpZGVyZWQgb3V0LW9mLXNjb3BlIGZvciB0aGlzIGVm Zm9ydDoKCiAgIG8gIFByaXZhY3kgb2YgdGhlIHBhY2tldHMgb24gdGhlIHdpcmUsIGF0IHRoaXMg cG9pbnQgaW4gdGltZS4gIE9uY2UKICAgICAgdGhpcyByb2FkbWFwIGlzIHJlYWxpemVkLCB3ZSBt YXkgcmV2aXNpdCB3b3JrIG9uIHByaXZhY3kuCgoKCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwOQoKCgogICBvICBNZXNzYWdlIGNvbnRlbnQgc2VjdXJpdHkuICBUaGlzIHdvcmsg aXMgYmVpbmcgYWRkcmVzc2VkIGluIG90aGVyCiAgICAgIElFVEYgZWZmb3J0cywgbGlrZSBTSURS LgoKMS42LiAgQXVkaWVuY2UKCiAgIFRoZSBhdWRpZW5jZSBmb3IgdGhpcyByb2FkbWFwIGluY2x1 ZGVzOgoKICAgbyAgUm91dGluZyBBcmVhIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGFuZCBwYXJ0aWNp cGFudHMgLSAgIFRoZXNlCiAgICAgICAgcGVvcGxlIGFyZSBjaGFyZ2VkIHdpdGggdXBkYXRlcyB0 byB0aGUgUm91dGluZyBQcm90b2NvbAogICAgICAgIHNwZWNpZmljYXRpb25zLiAgQW55IGFuZCBh bGwgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiB3b3JrCiAgICAgICAgb24gdGhlc2Ugc3Bl Y2lmaWNhdGlvbnMgd2lsbCBvY2N1ciBpbiBSb3V0aW5nIEFyZWEgd29ya2luZwogICAgICAgIGdy b3Vwcywgd2l0aCBjbG9zZSBwYXJ0bmVyc2hpcCB3aXRoIHRoZSBTZWN1cml0eSBBcmVhLiAgQ28t CiAgICAgICAgYWR2aXNvcnMgZnJvbSBTZWN1cml0eSBBcmVhIG1heSBvZnRlbiBiZSBuYW1lZCBm b3IgdGhlc2UKICAgICAgICBwYXJ0bmVyc2hpcCBlZmZvcnRzLgoKICAgbyAgU2VjdXJpdHkgQXJl YSByZXZpZXdlcnMgb2Ygcm91dGluZyBhcmVhIGRvY3VtZW50cyAtICAgVGhlc2UgcGVvcGxlCiAg ICAgICAgYXJlIGRlbGVnYXRlZCBieSB0aGUgU2VjdXJpdHkgQXJlYSBEaXJlY3RvcnMgdG8gcGVy Zm9ybSByZXZpZXdzCiAgICAgICAgb24gcm91dGluZyBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyBh cyB0aGV5IHBhc3MgdGhyb3VnaCB3b3JraW5nCiAgICAgICAgZ3JvdXAgbGFzdCBjYWxsIG9yIElF U0cgcmV2aWV3LiAgVGhleSB3aWxsIHBheSBwYXJ0aWN1bGFyCiAgICAgICAgYXR0ZW50aW9uIHRv IHRoZSB1c2Ugb2YgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiBhbmQKICAgICAgICBjb3Jy ZXNwb25kaW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgZm9yIHRoZSByb3V0aW5nIHByb3RvY29scy4K ICAgICAgICBUaGV5IHdpbGwgZW5zdXJlIHRoYXQgaW5jcmVtZW50YWwgc2VjdXJpdHkgaW1wcm92 ZW1lbnRzIGFyZQogICAgICAgIGJlaW5nIG1hZGUsIGluIGxpbmUgd2l0aCB0aGlzIHJvYWRtYXAu CgogICBvICBTZWN1cml0eSBBcmVhIGVuZ2luZWVycyAtICAgVGhlc2UgcGVvcGxlIHBhcnRuZXIg d2l0aCByb3V0aW5nIGFyZWEKICAgICAgICBhdXRob3JzL2Rlc2lnbmVycyBvbiB0aGUgc2VjdXJp dHkgbWVjaGFuaXNtcyBpbiByb3V0aW5nIHByb3RvY29sCiAgICAgICAgc3BlY2lmaWNhdGlvbnMu ICBTb21lIG9mIHRoZXNlIHNlY3VyaXR5IGFyZWEgZW5naW5lZXJzIHdpbGwgYmUKICAgICAgICBh c3NpZ25lZCBieSB0aGUgU2VjdXJpdHkgQXJlYSBEaXJlY3RvcnMsIHdoaWxlIG90aGVycyB3aWxs IGJlCiAgICAgICAgaW50ZXJlc3RlZCBwYXJ0aWVzIGluIHRoZSByZWxldmFudCB3b3JraW5nIGdy b3Vwcy4KCiAgIG8gIE9wZXJhdG9ycyAtICAgVGhlIG9wZXJhdG9ycyBhcmUgYSBrZXkgYXVkaWVu Y2UgZm9yIHRoaXMgd29yaywgYXMKICAgICAgICB0aGUgd29yayBpcyBjb25zaWRlcmVkIHRvIGhh dmUgc3VjY2VlZGVkIGlmIHRoZSBvcGVyYXRvcnMgZGVwbG95CiAgICAgICAgdGhlIHRlY2hub2xv Z3ksIHByZXN1bWFibHkgZHVlIHRvIGEgcGVyY2VwdGlvbiBvZiBzaWduaWZpY2FudGx5CiAgICAg ICAgaW1wcm92ZWQgc2VjdXJpdHkgdmFsdWUgY291cGxlZCB3aXRoIHJlbGF0aXZlIHNpbWlsYXJp dHkgdG8KICAgICAgICBkZXBsb3ltZW50IGNvbXBsZXhpdHkgYW5kIGNvc3QuICBDb252ZXJzZWx5 LCB0aGUgd29yayB3aWxsIGJlCiAgICAgICAgY29uc2lkZXJlZCBhIGZhaWx1cmUgaWYgdGhlIG9w ZXJhdG9ycyBkbyBub3QgY2FyZSB0byBkZXBsb3kgaXQsCiAgICAgICAgZWl0aGVyIGR1ZSB0byBs YWNrIG9mIHZhbHVlIG9yIHBlcmNlaXZlZCAob3IgcmVhbCkgb3Zlci0KICAgICAgICBjb21wbGV4 aXR5IG9mIG9wZXJhdGlvbnMuICBBbmQgYXMgc3VjaCwgdGhlIEdST1cgYW5kIE9QU0VDIFdHcwog ICAgICAgIHNob3VsZCBiZSBrZXB0IHNxdWFyZWx5IGluIHRoZSBsb29wIGFzIHdlbGwuCgoKCgoy LiAgVGhyZWF0cwoKICAgSW4gUkZDNDk0OVtSRkM0OTQ5XSwgYSB0aHJlYXQgaXMgZGVmaW5lZCBh cyBhIHBvdGVudGlhbCBmb3IgdmlvbGF0aW9uCiAgIG9mIHNlY3VyaXR5LCB3aGljaCBleGlzdHMg d2hlbiB0aGVyZSBpcyBhIGNpcmN1bXN0YW5jZSwgY2FwYWJpbGl0eSwKCgoKTGVib3ZpdHogJiAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2Ug MTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAg ICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgYWN0aW9uLCBvciBldmVudCB0aGF0IGNvdWxkIGJy ZWFjaCBzZWN1cml0eSBhbmQgY2F1c2UgaGFybS4gIFRoaXMKICAgc2VjdGlvbiBkZWZpbmVzIHRo ZSB0aHJlYXRzIHRoYXQgYXJlIGluIHNjb3BlIGZvciB0aGlzIHJvYWRtYXAsIGFuZAogICB0aG9z ZSB0aGF0IGFyZSBleHBsaWNpdGx5IG91dCBvZiBzY29wZS4gIFRoaXMgZG9jdW1lbnQgbGV2ZXJh Z2VzIHRoZQogICAiR2VuZXJpYyBUaHJlYXRzIHRvIFJvdXRpbmcgUHJvdG9jb2xzIiBtb2RlbCwg UkZDIDQ1OTMgW1JGQzQ1OTNdICwKICAgY2FwaXRhbGl6ZXMgdGVybXMgZnJvbSB0aGF0IGRvY3Vt ZW50LCBhbmQgb2ZmZXJzIGEgdGVyc2UgZGVmaW5pdGlvbgogICBvZiB0aG9zZSB0ZXJtcy4gIChN b3JlIHRob3JvdWdoIGRlc2NyaXB0aW9uIG9mIHJvdXRpbmcgcHJvdG9jb2wKICAgdGhyZWF0cyBz b3VyY2VzLCBtb3RpdmF0aW9ucywgY29uc2VxdWVuY2VzIGFuZCBhY3Rpb25zIGNhbiBiZSBmb3Vu ZAogICBpbiBSRkMgNDU5MyBbUkZDNDU5M10gaXRzZWxmKS4gIFRoZSB0aHJlYXQgbGlzdGluZ3Mg YmVsb3cgZXhwYW5kIHVwb24KICAgdGhlc2UgdGhyZWF0IGRlZmluaXRpb25zLgoKMi4xLiAgVGhy ZWF0cyBJbiBTY29wZQoKICAgVGhlIHRocmVhdHMgdGhhdCB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0 aGlzIHJvYWRtYXAgYXJlIHRob3NlIGZyb20KICAgT1VUU0lERVJTLCBhdHRhY2tlcnMgdGhhdCBt YXkgcmVzaWRlIGFueXdoZXJlIGluIHRoZSBJbnRlcm5ldCwgaGF2ZQogICB0aGUgYWJpbGl0eSB0 byBzZW5kIElQIHRyYWZmaWMgdG8gdGhlIHJvdXRlciwgbWF5IGJlIGFibGUgdG8gb2JzZXJ2ZQog ICB0aGUgcm91dGVyJ3MgcmVwbGllcywgYW5kIG1heSBldmVuIGNvbnRyb2wgdGhlIHBhdGggZm9y IGEgbGVnaXRpbWF0ZQogICBwZWVyJ3MgdHJhZmZpYy4gIFRoZXNlIGFyZSBub3QgbGVnaXRpbWF0 ZSBwYXJ0aWNpcGFudHMgaW4gdGhlIHJvdXRpbmcKICAgcHJvdG9jb2wuICBNZXNzYWdlIGF1dGhl bnRpY2F0aW9uIGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbgogICBzcGVjaWZpY2FsbHkgYWltcyB0 byBpZGVudGlmeSBtZXNzYWdlcyBvcmlnaW5hdGluZyBmcm9tIE9VVFNJREVSUy4KCiAgIFRoZSBj b25jZXB0IG9mIE9VVFNJREVSUyBjYW4gYmUgZnVydGhlciByZWZpbmVkIHRvIGluY2x1ZGUgYXR0 YWNrZXJzCiAgIHdobyBhcmUgdGVybWluYXRlZCBlbXBsb3llZXMsIGFuZCB0aG9zZSBzaXR0aW5n IG9uLXBhdGguCgogICBvICBPbi1QYXRoIC0gYXR0YWNrZXJzIHdpdGggY29udHJvbCBvZiBhIG5l dHdvcmsgcmVzb3VyY2Ugb3IgYSB0YXAKICAgICAgYWxvbmcgdGhlIHBhdGggb2YgcGFja2V0cyBi ZXR3ZWVuIHR3byByb3V0ZXJzLiAgQW4gb24tcGF0aAogICAgICBvdXRzaWRlciBjYW4gYXR0ZW1w dCBhIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFjaywgaW4gYWRkaXRpb24gdG8KICAgICAgc2V2ZXJh bCBvdGhlciBhdHRhY2sgY2xhc3Nlcy4gIEEgbWFuLWluLXRoZS1taWRkbGUgKE1pdE0pIGF0dGFj awogICAgICBvY2N1cnMgd2hlbiBhbiBhdHRhY2tlciB3aG8gaGFzIGFjY2VzcyB0byBwYWNrZXRz IGZsb3dpbmcgYmV0d2VlbgogICAgICB0d28gcGVlcnMgdGFtcGVycyB3aXRoIHRob3NlIHBhY2tl dHMgaW4gc3VjaCBhIHdheSB0aGF0IGJvdGggcGVlcnMKICAgICAgdGhpbmsgdGhleSBhcmUgdGFs a2luZyB0byBlYWNoIG90aGVyIGRpcmVjdGx5LCB3aGVuIGluIGZhY3QgdGhleQogICAgICBhcmUg YWN0dWFsbHkgdGFsa2luZyB0byB0aGUgYXR0YWNrZXIgb25seS4gIFByb3RvY29scyBjb25mb3Jt aW5nCiAgICAgIHRvIHRoaXMgcm9hZG1hcCB3aWxsIHVzZSBjcnlwdG9ncmFwaGljIG1lY2hhbmlz bXMgdG8gcHJldmVudCBhCiAgICAgIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja2VyIGZyb20gc2l0 dWF0aW5nIGhpbXNlbGYgdW5kZXRlY3RlZC4KCiAgIG8gIFRlcm1pbmF0ZWQgRW1wbG95ZWVzIC0g aW4gdGhpcyBjb250ZXh0LCB0aG9zZSB3aG8gaGFkIGFjY2VzcwogICAgICByb3V0ZXIgY29uZmln dXJhdGlvbiB0aGF0IGluY2x1ZGVkIGtleXMgb3Iga2V5aW5nIG1hdGVyaWFsIGxpa2UKICAgICAg cHJlLXNoYXJlZCBrZXlzIHVzZWQgaW4gc2VjdXJpbmcgdGhlIHJvdXRpbmcgcHJvdG9jb2wuICBV c2luZyB0aGlzCiAgICAgIG1hdGVyaWFsLCB0aGUgYXR0YWNrZXIgY291bGQgc2VuZCBwcm9wZXJs eSBNQUMnZCBzcG9vZmVkIHBhY2tldHMKICAgICAgYXBwZWFyaW5nIHRvIGNvbWUgZnJvbSByb3V0 ZXIgQSB0byByb3V0ZXIgQiwgYW5kIHRodXMgaW1wZXJzb25hdGUKICAgICAgYW4gYXV0aG9yaXpl ZCBwZWVyLiAgVGhlIGF0dGFja2VyIGNvdWxkIHRoZW4gc2VuZCBmYWxzZSB0cmFmZmljCiAgICAg IHRoYXQgY2hhbmdlcyB0aGUgbmV0d29yayBiZWhhdmlvciBmcm9tIGl0cyBvcGVyYXRvcidzIGRl c2lnbi4gIFRoZQogICAgICBnb2FsIG9mIGFkZHJlc3NpbmcgdGhpcyBzb3VyY2Ugc3BlY2lmaWNh bGx5IGlzIHRvIGNhbGwgb3V0IHRoZQogICAgICBjYXNlIHdoZXJlIG5ldyBrZXlzIG9yIGtleWlu ZyBtYXRlcmlhbCBiZWNvbWVzIG5lY2Vzc2FyeSB2ZXJ5CiAgICAgIHF1aWNrbHksIHdpdGggbGl0 dGxlIG9wZXJhdGlvbmFsIGV4cGVuc2UsIHVwb24gdGhlIHRlcm1pbmF0aW9uIG9mCiAgICAgIHN1 Y2ggYW4gZW1wbG95ZWUuICBUaGlzIGdyb3VwaW5nIGNvdWxkIGFsc28gcmVmZXIgdG8gYW55IGF0 dGFja2VyCiAgICAgIHdobyBzb21laG93IG1hbmFnZWQgdG8gZ2FpbiBhY2Nlc3MgdG8ga2V5aW5n IG1hdGVyaWFsLCBhbmQgc2FpZAogICAgICBhY2Nlc3MgaGFkIGJlZW4gZGV0ZWN0ZWQgYnkgdGhl IG9wZXJhdG9ycyBzdWNoIHRoYXQgdGhlIG9wZXJhdG9ycwogICAgICBoYXZlIGFuIG9wcG9ydHVu aXR5IHRvIG1vdmUgdG8gbmV3IGtleXMgaW4gb3JkZXIgdG8gcHJldmVudCBhbgoKCgpMZWJvdml0 eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBb UGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgogICAgICBhdHRhY2suCgogICBUaGVzZSBBVFRB Q0sgQUNUSU9OUyBhcmUgaW4gc2NvcGUgZm9yIHRoaXMgcm9hZG1hcDoKCiAgIG8gIFNQT09GSU5H IC0gd2hlbiBhbiB1bmF1dGhvcml6ZWQgZGV2aWNlIGFzc3VtZXMgdGhlIGlkZW50aXR5IG9mIGFu CiAgICAgIGF1dGhvcml6ZWQgb25lLiAgU3Bvb2ZpbmcgY2FuIGJlIHVzZWQsIGZvciBleGFtcGxl LCB0byBpbmplY3QKICAgICAgbWFsaWNpb3VzIHJvdXRpbmcgaW5mb3JtYXRpb24gdGhhdCBjYXVz ZXMgdGhlIGRpc3J1cHRpb24gb2YKICAgICAgbmV0d29yayBzZXJ2aWNlcy4gIFNwb29maW5nIGNh biBhbHNvIGJlIHVzZWQgdG8gY2F1c2UgYSBuZWlnaGJvcgogICAgICByZWxhdGlvbnNoaXAgdG8g Zm9ybSB0aGF0IHN1YnNlcXVlbnRseSBkZW5pZXMgdGhlIGZvcm1hdGlvbiBvZiB0aGUKICAgICAg cmVsYXRpb25zaGlwIHdpdGggdGhlIGxlZ2l0aW1hdGUgcm91dGVyLgoKICAgbyAgRkFMU0lGSUNB VElPTiAtIGFuIGFjdGlvbiB3aGVyZWJ5IGFuIGF0dGFja2VyIHNlbmRzIGZhbHNlIHJvdXRpbmcK ICAgICAgaW5mb3JtYXRpb24uICBUbyBmYWxzaWZ5IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLCBh biBhdHRhY2tlciBoYXMKICAgICAgdG8gYmUgZWl0aGVyIHRoZSBvcmlnaW5hdG9yIG9yIGEgZm9y d2FyZGVyIG9mIHRoZSByb3V0aW5nCiAgICAgIGluZm9ybWF0aW9uLiAgRmFsc2lmaWNhdGlvbiBt YXkgb2NjdXIgYnkgYW4gT1JJR0lOQVRPUiwgb3IgYQogICAgICBGT1JXQVJERVIsIGFuZCBtYXkg aW52b2x2ZSBPVkVSQ0xBSU1JTkcsIE1JU0NMQUlNSU5HLCBvcgogICAgICBNSVNUQVRFTUVOVCBv ZiBuZXR3b3JrIHJlc291cmNlIHJlYWNoYWJpbGl0eS4gIFdlIG11c3QgYmUgY2FyZWZ1bAogICAg ICB0byByZW1lbWJlciB0aGF0IGluIHRoaXMgd29yayB3ZSBhcmUgb25seSB0YXJnZXRpbmcgZmFs c2lmaWNhdGlvbgogICAgICBmcm9tIG91dHNpZGVycyBhcyBtYXkgb2NjdXIgZnJvbSB0YW1wZXJp bmcgd2l0aCBwYWNrZXRzIGluIGZsaWdodC4KICAgICAgRmFsc2lmaWNhdGlvbiBmcm9tIEJZWkFO VElORVMgKHNlZSB0aGUgVGhyZWF0cyBPdXQgb2YgU2NvcGUKICAgICAgc2VjdGlvbiAoU2VjdGlv biAyLjIpIGJlbG93KSBhcmUgbm90IGFkZHJlc3NlZCBieSB0aGUgS0FSUCBlZmZvcnQuCgogICBv ICBJTlRFUkZFUkVOQ0UgLSB3aGVuIGFuIGF0dGFja2VyIGluaGliaXRzIHRoZSBleGNoYW5nZXMg YnkKICAgICAgbGVnaXRpbWF0ZSByb3V0ZXJzLiAgVGhlIHR5cGVzIG9mIGludGVyZmVyZW5jZSBh ZGRyZXNzZWQgYnkgdGhpcwogICAgICB3b3JrIGluY2x1ZGU6CiAgICAgICogIEFERElORyBOT0lT RQogICAgICAqICBSRVBMQVlJTkcgT1VULURBVEVEIFBBQ0tFVFMKICAgICAgKiAgSU5TRVJUSU5H IE1FU1NBR0VTCiAgICAgICogIENPUlJVUFRJTkcgTUVTU0FHRVMKICAgICAgKiAgQlJFQUtJTkcg U1lOQ0hST05JWkFUSU9OCiAgICAgICogIENoYW5naW5nIG1lc3NhZ2UgY29udGVudAoKICAgbyAg RG9TIGF0dGFja3Mgb24gdHJhbnNwb3J0IHN1Yi1zeXN0ZW1zIC0gVGhpcyBpbmNsdWRlcyBhbnkg b3RoZXIgRG9TCiAgICAgIGF0dGFja3Mgc3BlY2lmaWNhbGx5IGJhc2VkIG9uIHRoZSBhYm92ZSBh dHRhY2sgdHlwZXMuICBUaGlzIGlzCiAgICAgIHdoZW4gYW4gYXR0YWNrZXIgc2VuZHMgc3Bvb2Zl ZCBwYWNrZXRzIGFpbWVkIGF0IGhhbHRpbmcgb3IKICAgICAgcHJldmVudGluZyB0aGUgdW5kZXJs eWluZyBwcm90b2NvbCBvdmVyIHdoaWNoIHRoZSByb3V0aW5nIHByb3RvY29sCiAgICAgIHJ1bnMs IGZvciBleGFtcGxlIGhhbHRpbmcgYSBCR1Agc2Vzc2lvbiBieSBzZW5kaW5nIGEgVENQIEZJTiBv cgogICAgICBSU1QgcGFja2V0LiAgU2luY2UgdGhpcyBhdHRhY2sgZGVwZW5kcyBvbiBzcG9vZmlu Zywgb3BlcmF0b3JzIGFyZQogICAgICBlbmNvdXJhZ2VkIHRvIGRlcGxveQoKICAgbyAgRG9TIGF0 dGFja3MgdXNpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSAtIFRoaXMgaW5jbHVkZXMg YW4KICAgICAgYXR0YWNrZXIgc2VuZGluZyBwYWNrZXRzIHdoaWNoIGNvbmZ1c2Ugb3Igb3Zlcndo ZWxtIGEgc2VjdXJpdHkKICAgICAgbWVjaGFuaXNtIGl0c2VsZi4gIEFuIGV4YW1wbGUgaXMgaW5p dGlhdGluZyBhbiBvdmVyd2hlbG1pbmcgbG9hZAogICAgICBvZiBzcG9vZmVkIGF1dGhlbnRpY2F0 ZWQgcm91dGUgbWVzc2FnZXMgc28gdGhhdCB0aGUgcmVjZWl2ZXIgbmVlZHMKICAgICAgdG8gcHJv Y2VzcyB0aGUgTUFDIGNoZWNrLCBvbmx5IHRvIGRpc2NhcmQgdGhlIHBhY2tldCwgc2VuZGluZyBD UFUKICAgICAgbGV2ZWxzIHJpc2luZy4gIEFub3RoZXIgZXhhbXBsZSBpcyB3aGVuIGFuIGF0dGFj a2VyIHNlbmRzIGFuCiAgICAgIG92ZXJ3aGVsbWluZyBsb2FkIG9mIGtleWluZyBwcm90b2NvbCBp bml0aWF0aW9ucyBmcm9tIGJvZ3VzCiAgICAgIHNvdXJjZXMuICBBbGwgb3RoZXIgcG9zc2libGUg RG9TIGF0dGFja3MgYXJlIG91dCBvZiBzY29wZSAoc2VlCgoKCkxlYm92aXR6ICYgICAgICAgICAg ICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAwOQoKCiAgICAgIG5leHQgc2VjdGlvbikuCgogICBvICBCcnV0ZSBGb2NlIEF0 dGFja3MgQWdhaW5zdCBQYXNzd29yZC9LZXlzIC0gVGhpcyBpbmNsdWRlcyBlaXRoZXIKICAgICAg b25saW5lIG9yIG9mZmxpbmUgYXR0YWNrcyB3aGVyZSBhdHRlbXB0cyBhcmUgbWFkZSByZXBlYXRl ZGx5IHVzaW5nCiAgICAgIGRpZmZlcmVudCBrZXlzL3Bhc3N3b3JkcyB1bnRpbCBhIG1hdGNoIGlz IGZvdW5kLiAgV2hpbGUgaXQgaXMKICAgICAgaW1wb3NzaWJsZSB0byBtYWtlIGJydXRlIGZvcmNl IGF0dGFja3Mgb24ga2V5cyBjb21wbGV0ZWx5CiAgICAgIHVuc3VjY2Vzc2Z1bCwgcHJvcGVyIGRl c2lnbiBjYW4gbWFrZSBzdWNoIGF0dGFja3MgbXVjaCBoYXJkZXIgdG8KICAgICAgc3VjY2VlZC4g IEZvciBleG1hcGxlLCB0aGUga2V5IGxlbmd0aCBzaG91bGQgYmUgc3VmZmljaWVudGx5IGxvbmcK ICAgICAgc28gdGhhdCBjb3ZlcmluZyB0aGUgZW50aXJlIHNwYWNlIG9mIHBvc3NpYmxlIGtleXMg aXMgaW1wcm9iYWJsZQogICAgICB1c2luZyBjb21wdXRhdGlvbmFsIHBvd2VyIGV4cGVjdGVkIHRv IGJlIGF2YWlsYWJsZSAxMCB5ZWFycyBvdXQgb3IKICAgICAgbW9yZS4gIEFsc28sIGZyZXF1ZW50 bHkgY2hhbmdpbmcgdGhlIGtleXMgbWF5IHJlbmRlciB1c2VsZXNzIGEKICAgICAgc3VjY2Vzc2Z1 bCBndWVzcyBzb21lIHRpbWUgaW4gdGhlIGZ1dHVyZSwgYXMgdGhvc2Uga2V5cyBtYXkgbm8KICAg ICAgbG9uZ2VyIGJlIGluIHVzZS4KCjIuMi4gIFRocmVhdHMgT3V0IG9mIFNjb3BlCgogICBUaHJl YXRzIGZyb20gQllaQU5USU5FIHNvdXJjZXMgLS0gZmF1bHR5LCBtaXNjb25maWd1cmVkLCBvciBz dWJ2ZXJ0ZWQKICAgcm91dGVycywgaS5lLiwgbGVnaXRpbWF0ZSBwYXJ0aWNpcGFudHMgaW4gdGhl IHJvdXRpbmcgcHJvdG9jb2wgLS0gYXJlCiAgIG91dCBvZiBzY29wZSBmb3IgdGhpcyByb2FkbWFw LiAgQW55IG9mIHRoZSBhdHRhY2tzIGRlc2NyaWJlZCBpbiB0aGUKICAgYWJvdmUgc2VjdGlvbiAo U2VjdGlvbiAyLjEpIHRoYXQgbWF5IGJlIGxldmllZCBieSBhIEJZWkFOVElORSBzb3VyY2UKICAg YXJlIHRoZXJlZm9yZSBhbHNvIG91dCBvZiBzY29wZS4KCiAgIEluIGFkZGl0aW9uLCB0aGVzZSBv dGhlciBhdHRhY2sgYWN0aW9ucyBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzCiAgIHdvcms6Cgog ICBvICBTTklGRklORyAtIHBhc3NpdmUgb2JzZXJ2YXRpb24gb2Ygcm91dGUgbWVzc2FnZSBjb250 ZW50cyBpbiBmbGlnaHQKICAgbyAgRkFMU0lGSUNBVElPTiBieSBCWVpBTlRJTkUgc291cmNlcyAt IHVuYXV0aG9yaXplZCBtZXNzYWdlIGNvbnRlbnQKICAgICAgYnkgYSBsZWdpdGltYXRlIGF1dGhv cml6ZWQgc291cmNlLgogICBvICBJTlRFUkZFUkVOQ0UgZHVlIHRvOgogICAgICAqICBOT1QgRk9S V0FSRElORyBQQUNLRVRTIC0gY2Fubm90IGJlIHByZXZlbnRlZCB3aXRoIGNyeXB0b2dyYXBoaWMK ICAgICAgICAgYXV0aGVudGljYXRpb24KICAgICAgKiAgREVMQVlJTkcgTUVTU0FHRVMgLSBjYW5u b3QgYmUgcHJldmVudGVkIHdpdGggY3J5cHRvZ3JhcGhpYwogICAgICAgICBhdXRoZW50aWNhdGlv bgogICAgICAqICBERU5JQUwgT0YgUkVDRUlQVCAtIGNhbm5vdCBiZSBwcmV2ZW50ZWQgd2l0aCBj cnlwdG9ncmFwaGljCiAgICAgICAgIGF1dGhlbnRpY2F0aW9uCiAgICAgICogIFVOQVVUSE9SSVpF RCBNRVNTQUdFIENPTlRFTlQgLSB0aGUgd29yayBvZiB0aGUgSUVURidzIFNJRFIKICAgICAgICAg d29ya2luZyBncm91cAogICAgICAgICAoaHR0cDovL3d3dy5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJz L3NpZHItY2hhcnRlci5odG1sKS4KICAgICAgKiAgQW55IG90aGVyIHR5cGUgb2YgRG9TIGF0dGFj ay4gIEZvciBleGFtcGxlLCBhIGZsb29kIG9mIHRyYWZmaWMKICAgICAgICAgdGhhdCBmaWxscyB0 aGUgbGluayBhaGVhZCBvZiB0aGUgcm91dGVyLCBzbyB0aGF0IHRoZSByb3V0ZXIgaXMKICAgICAg ICAgcmVuZGVyZWQgdW51c2FibGUgYW5kIHVucmVhY2hhYmxlIGJ5IHZhbGlkIHBhY2tldHMgaXMg Tk9UIGFuCiAgICAgICAgIGF0dGFjayB0aGF0IHRoaXMgd29yayB3aWxsIGFkZHJlc3MuICBNYW55 IG90aGVyIHN1Y2ggZXhhbXBsZXMKICAgICAgICAgY291bGQgYmUgY29udHJpdmVkLgoKCgoKCgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDE1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9h ZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCjMuICBDYXRlZ29yaXppbmcgUm91 dGluZyBQcm90b2NvbHMKCiAgIEZvciB0aGUgcHVycG9zZSBvZiB0aGlzIHNlY3VyaXR5IHJvYWRt YXAgZGVmaW5pdGlvbiwgd2Ugd2lsbAogICBjYXRlZ29yaXplIHRoZSByb3V0aW5nIHByb3RvY29s cyBpbnRvIGdyb3VwcyBhbmQgaGF2ZSBkZXNpZ24gdGVhbXMKICAgZm9jdXMgb24gdGhlIHNwZWNp ZmljYXRpb24gd29yayB3aXRoaW4gdGhvc2UgZ3JvdXBpbmdzLiAgSXQgaXMKICAgYmVsaWV2ZWQg dGhhdCB0aGUgZ3JvdXBpbmdzIHdpbGwgaGF2ZSBsaWtlIHJlcXVpcmVtZW50cyBmb3IgdGhlaXIK ICAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcywgYW5kIHRoYXQgcmV1c2Ugb2YgYXV0aGVudGlj YXRpb24KICAgbWVjaGFuaXNtcyB3aWxsIGJlIGdyZWF0ZXN0IHdpdGhpbiB0aGVzZSBncm91cGlu Zy4gIFRoZSB3b3JrIGl0ZW1zCiAgIHBsYWNlZCBvbiB0aGUgcm9hZG1hcCB3aWxsIGJlIGRlZmlu ZWQgYW5kIGFzc2lnbmVkIGJhc2VkIG9uIHRoZXNlCiAgIGNhdGVnb3JpemF0aW9ucy4gIEl0IGlz IGFsc28gaG9wZWQgdGhhdCwgZG93biB0aGUgcm9hZCBpbiB0aGUgUGhhc2UgMgogICB3b3JrLCB3 ZSBjYW4gY3JlYXRlIG9uZSBLTVAgcGVyIGNhdGVnb3J5IChpZiBub3QgZm9yIHNldmVyYWwKICAg Y2F0ZWdvcmllcykgc28gdGhhdCB0aGUgd29yayBjYW4gYmUgZWFzaWx5IGxldmVyYWdlZCBieSB0 aGUgdmFyaW91cwogICBSb3V0aW5nIFByb3RvY29sIHRlYW1zLiAgS01QcyBhcmUgdXNlZnVsIGZv ciBhbGxvd2luZyBzaW1wbGUsCiAgIGF1dG9tYXRlZCB1cGRhdGVzIG9mIHRoZSB0cmFmZmljIGtl eXMgdXNlZCBpbiBhIGJhc2UgcHJvdG9jb2wuICBLTVBzCiAgIHJlcGxhY2UgdGhlIG5lZWQgZm9y IGh1bWFucywgb3IgT1NTIHJvdXRpbmVzLCB0byBwZXJpb2RpY2FsbHkgcmVwbGFjZQogICBrZXlz IG9uIHJ1bm5pbmcgc3lzdGVtcy4gIEl0IGFsc28gcmVtb3ZlcyB0aGUgbmVlZCBmb3IgYSBjaGFp biBvZgogICBtYW51YWwga2V5cyB0byBiZSBjaG9zZW4gb3IgY29uZmlndXJlZC4gIFdoZW4gY29u ZmlndXJlZCBwcm9wZXJseSwgYQogICBLTVAgd2lsbCBlbmZvcmNlIHRoZSBrZXkgZnJlc2huZXNz IHBvbGljeSBvZiB0d28gcGVlcnMgYnkga2VlcGluZwogICB0cmFjayBvZiB0aGUga2V5IGxpZmV0 aW1lIGFuZCBuZWdvdGlhdGluZyBhIG5ldyBrZXkgYXQgdGhlIGRlZmluZWQKICAgaW50ZXJ2YWwu CgozLjEuICBDYXRlZ29yeTogTWVzc2FnaW5nIFRyYW5zYWN0aW9uIFR5cGUKCiAgIFRoZSBmaXJz dCBjYXRlZ29yaXphdGlvbiBkZWZpbmVzIGZvdXIgdHlwZXMgb2YgbWVzc2FnaW5nIHRyYW5zYWN0 aW9ucwogICB1c2VkIG9uIHRoZSB3aXJlIGJ5IHRoZSBiYXNlIFJvdXRpbmcgUHJvdG9jb2wuICBU aGV5IGFyZToKCgogICBPbmUtdG8tT25lICAgICBPbmUgcGVlciByb3V0ZXIgZGlyZWN0bHkgYW5k IGludGVudGlvbmFsbHkgZGVsaXZlcnMgYQogICAgICAgICAgICAgICAgICByb3V0ZSB1cGRhdGUg c3BlY2lmaWNhbGx5IHRvIG9uZSBvdGhlciBwZWVyIHJvdXRlci4KICAgICAgICAgICAgICAgICAg RXhhbXBsZXMgYXJlIEJHUCBhbmQgTERQLiAgUG9pbnQtdG8tcG9pbnQgbW9kZXMgb2YKICAgICAg ICAgICAgICAgICAgYm90aCBJUy1JUyBhbmQgT1NQRiwgd2hlbiBzZW50IG92ZXIgYm90aCB0cmFk aXRpb25hbAogICAgICAgICAgICAgICAgICBwb2ludC10by1wb2ludCBsaW5rcyBhbmQgd2hlbiB1 c2luZyBtdWx0aS1hY2Nlc3MKICAgICAgICAgICAgICAgICAgbGF5ZXJzLCBtYXkgYm90aCBhbHNv IGZhbGwgaW50byB0aGlzIGNhdGVnb3J5LgogICAgICAgICAgICAgICAgICBbcXVlc3Rpb24gdG8g cmV2aWV3ZXJzOiBTaG91bGQgd2UgbGlzdCBhbGwgcHJvdG9jb2xzCiAgICAgICAgICAgICAgICAg IGludG8gdGhlc2UgY2F0ZWdvcmllcyByaWdodCBoZXJlLCBvciBqdXN0IGdpdmUgYSBmZXcKICAg ICAgICAgICAgICAgICAgZXhhbXBsZXM/XQoKICAgT25lLXRvLU1hbnkgICAgQSByb3V0ZXIgcGVl cnMgd2l0aCBtdWx0aXBsZSBvdGhlciByb3V0ZXJzIG9uIGEgc2luZ2xlCiAgICAgICAgICAgICAg ICAgIG5ldHdvcmsgc2VnbWVudCAtLSBpLmUuIG9uIGxpbmsgbG9jYWwgLS0gc3VjaCB0aGF0IGl0 CiAgICAgICAgICAgICAgICAgIGNyZWF0ZXMgYW5kIHNlbmRzIG9uZSByb3V0ZSB1cGRhdGUgbWVz c2FnZSB3aGljaCBpcwogICAgICAgICAgICAgICAgICBpbnRlbmRlZCBmb3IgY29uc3VtcHRpb24g YnkgbXVsdGlwbGUgcGVlcnMuICBFeGFtcGxlcwogICAgICAgICAgICAgICAgICB3b3VsZCBiZSBP U1BGIGFuZCBJUy1JUyBpbiB0aGVpciBicm9hZGNhc3QsIG5vbi1wb2ludC0KICAgICAgICAgICAg ICAgICAgdG8tcG9pbnQgbW9kZXMuCgoKCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJl ciAyMDA5CgoKICAgQ2xpZW50LVNlcnZlciAgQSBjbGllbnQtc2VydmVyIHJvdXRpbmcgcHJvdG9j b2wgaXMgb25lIHdoZXJlIG9uZQogICAgICAgICAgICAgICAgICByb3V0ZXIgaW5pdGlhdGVzIGEg cmVxdWVzdCBmb3Igcm91dGUgaW5mb3JtYXRpb24gZnJvbQogICAgICAgICAgICAgICAgICBhbm90 aGVyIHJvdXRlciwgd2hvIHRoZW4gZm9ybXVsYXRlcyBhIHJlc3BvbnNlIHRvIHRoYXQKICAgICAg ICAgICAgICAgICAgcmVxdWVzdCwgYW5kIHJlcGxpZXMgd2l0aCB0aGUgcmVxdWVzdGVkIGRhdGEu CiAgICAgICAgICAgICAgICAgIEV4YW1wbGVzIGFyZSBhIEJHUCBSb3V0ZSBSZWZsZWN0b3IgYW5k IFs/Pz8/ICBBcmUKICAgICAgICAgICAgICAgICAgdGhlcmUgb3RoZXIgZXhhbXBsZXM/ICBJcyB0 aGlzIHRoZSByaWdodCBleGFtcGxlPyAgRG8KICAgICAgICAgICAgICAgICAgZGlzY292ZXJ5IHBy b3RvY29scyBmYWxsIHVuZGVyIHRoaXMgY2F0ZWdvcnk/XS4KCiAgIE11bHRpY2FzdCAgICAgIE11 bHRpY2FzdCBwcm90b2NvbHMgaGF2ZSB1bmlxdWUgc2VjdXJpdHkgcHJvcGVydGllcwogICAgICAg ICAgICAgICAgICBiZWNhdXNlIG9mIHRoZSBmYWN0IHRoYXQgdGhleSBhcmUgaW5oZXJlbnRseSBn cm91cC0KICAgICAgICAgICAgICAgICAgYmFzZWQgcHJvdG9jb2xzIGFuZCB0aHVzIGhhdmUgZ3Jv dXAga2V5aW5nCiAgICAgICAgICAgICAgICAgIHJlcXVpcmVtZW50cyBhdCB0aGUgcm91dGluZyBs ZXZlbCB3aGVyZSBsaW5rLWxvY2FsCiAgICAgICAgICAgICAgICAgIHJvdXRpbmcgbWVzc2FnZXMg YXJlIG11bHRpY2FzdGVkLiAgQWxzbywgYXQgbGVhc3QgaW4KICAgICAgICAgICAgICAgICAgdGhl IGNhc2Ugb2YgUElNLVNNLCBzb21lIG1lc3NhZ2VzIGFyZSBhcmUgc2VudCB1bmljYXN0CiAgICAg ICAgICAgICAgICAgIHRvIGEgZ2l2ZW4gcGVlcihzKSwgYXMgaXMgdGhlIGNhc2Ugd2l0aCByb3V0 ZXItY2xvc2UtCiAgICAgICAgICAgICAgICAgIHRvLXNlbmRlciBhbmQgdGhlICJSZW5kZXp2b3Vz IFBvaW50Ii4gIFNvbWUgd29yayBmb3IKICAgICAgICAgICAgICAgICAgYXBwbGljYXRpb24gbGF5 ZXIgbWVzc2FnZSBzZWN1cml0eSBoYXMgYmVlbiBkb25lIGluCiAgICAgICAgICAgICAgICAgIHRo ZSBNdWx0aWNhc3QgU2VjdXJpdHkgd29ya2luZyBncm91cCAoTVNFQywKICAgICAgICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL21zZWMtY2hhcnRlci5odG1sKQog ICAgICAgICAgICAgICAgICBhbmQgbWF5IGJlIGhlbHBmdWwgdG8gcmV2aWV3LCBidXQgaXMgbm90 IGRpcmVjdGx5CiAgICAgICAgICAgICAgICAgIGFwcGxpY2FibGUuCgogICBbYXV0aG9yJ3Mgbm90 ZTogSSB0aGluayB0aGUgYWJvdmUgZGVmaW5pdGlvbnMgbmVlZCBjbGVhbiB1cC4gIFJvdXRpbmcK ICAgYXJlYSBmb2xrcywgZXNwZWNpYWxseSBBRHMsIFBMRUFTRSBzdWdnZXN0IG5ldyB0ZXh0Ll0K CjMuMi4gIENhdGVnb3J5OiBQZWVyIHZzLiBHcm91cCBLZXlpbmcKCiAgIFRoZSBzZWNvbmQgYXhp cyBvZiBjYXRlZ29yaXphdGlvbiBncm91cHMgcHJvdG9jb2xzIGJ5IHRoZSBrZXlpbmcKICAgbWVj aGFuaXNtIHRoYXQgd2lsbCBiZSBuZWNlc3NhcnkgZm9yIGRpc3RyaWJ1dGluZyBzZXNzaW9uIGtl eXMgdG8gdGhlCiAgIGFjdHVhbCBSb3V0aW5nIFByb3RvY29sIHRyYW5zcG9ydHMuICBUaGV5IGFy ZToKCgogICBQZWVyIGtleWluZyAgICBPbmUgcm91dGVyIHNlbmRzIHRoZSBrZXlpbmcgbWVzc2Fn ZXMgZGlyZWN0bHkgYW5kIG9ubHkKICAgICAgICAgICAgICAgICAgdG8gb25lIG90aGVyIHJvdXRl ciwgc3VjaCB0aGF0IGEgb25lLXRvLW9uZSwgdW5pcXVlCiAgICAgICAgICAgICAgICAgIGtleWlu ZyBzZWN1cml0eSBhc3NvY2lhdGlvbiAoU0EpIGlzIGVzdGFibGlzaGVkCiAgICAgICAgICAgICAg ICAgIGJldHdlZW4gdGhlIHR3byByb3V0ZXJzCgogICBHcm91cCBLZXlpbmcgICBPbmUgcm91dGVy IGNyZWF0ZXMgYW5kIGRpc3RyaWJ1dGVzIGEgc2luZ2xlIGtleWluZwogICAgICAgICAgICAgICAg ICBtZXNzYWdlIHRvIG11bHRpcGxlIHBlZXJzLiAgSW4gdGhpcyBjYXNlIGFuIGdyb3VwIFNBCiAg ICAgICAgICAgICAgICAgIHdpbGwgYmUgZXN0YWJsaXNoZWQgYW5kIHVzZWQgYmV0d2VlbiBtdWx0 aXBsZSBwZWVycwogICAgICAgICAgICAgICAgICBzaW11bHRhbmVvdXNseS4gIEdyb3VwIGtleWlu ZyBleGlzdHMgZm9yIHByb3RvY29scwogICAgICAgICAgICAgICAgICBsaWtlIE9TUEYgW1JGQzIz MjhdICwgYW5kIGFsc28gZm9yIG11bHRpY2FzdCBwcm90b2NvbHMKICAgICAgICAgICAgICAgICAg bGlrZSBQSU0tU00gW1JGQzQ2MDFdLgoKCgoKCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1i ZXIgMjAwOQoKCjMuMy4gIENhdGVnb3J5OiAgVXBkYXRlIHZzLiBEaXNjb3ZlcnkgUHJvdG9jb2wK CiAgIFRoZSB0aGlyZCBjYXRlZ29yeSBncm91cCBjb25zaWRlcnMgcHJvdG9jb2xzIGJ5IHRoZSBj b250ZW50cyBvZiB0aGUKICAgbWVzc2FnZXMgYmVpbmcgZXhjaGFuZ2VkIGluIHRoZSBSb3V0aW5n IFByb3RvY29sLiAgVGhleSBhcmU6CgoKICAgVXBkYXRlcyAgICAgICAgTWVzc2FnZXMgdGhhdCBj YXJyeSByb3V0ZSBhZHZlcnRpc2VtZW50cyBvciB1cGRhdGUKICAgICAgICAgICAgICAgICAgaW5m b3JtYXRpb24gZnJvbSBwZWVyIHRvIHBlZXIKCiAgIERpc2NvdmVyeSAgICAgIE1lc3NhZ2VzIHNl bnQgYXMgcGFydCBvZiBhIHBvbGljeSwgcGVlciwgb3Igc2VydmljZQogICAgICAgICAgICAgICAg ICBkaXNjb3ZlcnkgcHJvY2Vzcy4gIFRoZXNlIG1lc3NhZ2VzIGFyZSBub3JtYWxseQogICAgICAg ICAgICAgICAgICBleGNoYW5nZWQgcHJpb3IgdG8gYW55IGFkamFjZW5jeSBiZWluZyBmb3JtZWQs IGFuZAogICAgICAgICAgICAgICAgICBiZWZvcmUgYW55IHVwZGF0ZXMgYXJlIHNlbnQuICBGb3Ig ZXhhbXBsZSwgZW5kLXBvaW50CiAgICAgICAgICAgICAgICAgIGRpc2NvdmVyeSBtZWNoYW5pc21z IGFyZSBjb21tb24gaW4gTDJWUE4gYW5kIEwzVlBOCiAgICAgICAgICAgICAgICAgIHNvbHV0aW9u cy4KCiAgIFtRVUVTVElPTiBUTyBSRVZJRVdFUlM6IGlzIHRoaXMgcmVhbGx5IGp1c3Qgd2hhdCdz IGRlc2NyaWJlZCBpbiAzLjEKICAgYXMgIkNsaWVudC1TZXJ2ZXIiIGFuZC9vciAiT25lLXRvLU9u ZSI/ICBJcyB0aGVyZSByZWFsbHkgc3VjaCBhCiAgIGRpZmZlcmVudCBpbiBkaXNjb3ZlcnkgcHJv dG9jb2xzIHRoYXQgdGhleSBuZWVkIHRoZWlyIG93biBjYXRlZ29yeSB0bwogICBmaWd1cmUgb3V0 IGhvdyB0byBhdXRoZW50aWNhdGUgdGhlbT8gIENhbiBzb21lb25lIHByb3ZpZGUgYSBmZXcKICAg ZXhhbXBsZXM/CgozLjQuICBTZWN1cml0eSBDaGFyYWN0ZXJpemF0aW9uIFZlY3RvcnMKCiAgIEEg ZmV3IG1vcmUgY29uc2lkZXJhdGlvbnMgbXVzdCBiZSBtYWRlIGFib3V0IHRoZSBwcm90b2NvbCBh bmQgaXRzIHVzZQogICB3aGVuIGluaXRpYWxseSBjYXRlZ29yaXppbmcgdGhlIHByb3RvY29sIGFu ZCBzY29waW5nIHRoZQogICBhdXRoZW50aWNhdGlvbiB3b3JrLgoKMy40LjEuICBJbnRlcm5hbCB2 cy4gRXh0ZXJuYWwgT3BlcmF0aW9uCgogICBUaGUgZGVzaWduZXJzIG11c3QgY29uc2lkZXIgd2hl dGhlciB0aGUgcHJvdG9jb2wgaXMgYW4gaW50ZXJuYWwKICAgcm91dGluZyBwcm90b2NvbCBvciBh biBleHRlcm5hbCBvbmUsIGkuZS4gIERvZXMgaXQgcHJpbWFyaWx5IHJ1bgogICBiZXR3ZWVuIHBl ZXJzIHdpdGhpbiBhIHNpbmdsZSBkb21haW4gb2YgY29udHJvbCBvciBiZXR3ZWVuIHR3bwogICBk aWZmZXJlbnQgZG9tYWlucyBvZiBjb250cm9sPyAgU29tZSBwcm90b2NvbHMgbWF5IGJlIHVzZWQg aW4gYm90aAogICBjYXNlcywgaW50ZXJuYWxseSBhbmQgZXh0ZXJuYWxseSwgYW5kIGFzIHN1Y2gg dmFyaW91cyBtb2RlcyBvZgogICBhdXRoZW50aWNhdGlvbiBvcGVyYXRpb24gbWF5IGJlIHJlcXVp cmVkIGZvciB0aGUgc2FtZSBwcm90b2NvbC4KICAgV2hpbGUgaXQgaXMgcHJlZmVycmVkIHRoYXQg YWxsIHJvdXRpbmcgZXhjaGFuZ2VzIHJ1biB3aXRoIHRoZSB1dG1vc3QKICAgc2VjdXJpdHkgbWVj aGFuaXNtcyBlbmFibGVkIGluIGFsbCBkZXBsb3ltZW50cywgdGhpcyBleGhvcnRhdGlvbiBpcwog ICBncmVhdGVyIGZvciB0aG9zZSBwcm90b2NvbHMgcnVubmluZyBvbiBpbnRlci1kb21haW4gcG9p bnQtdG8tcG9pbnQKICAgbGlua3MsIGFuZCBncmVhdGVzdCBmb3IgdGhvc2Ugb24gc2hhcmVkIGFj Y2VzcyBsaW5rIGxheWVycyB3aXRoCiAgIHNldmVyYWwgZGlmZmVyZW50IGRvbWFpbnMgaW50ZXJj aGFuZ2luZyB0b2dldGhlciwgYmVjYXVzZSB0aGUgdm9sdW1lCiAgIG9mIGF0dGFja2VycyBhcmUg Z3JlYXRlciBmcm9tIHRoZSBvdXRzaWRlLiAgTm90ZSBob3dldmVyIHRoYXQgdGhlCiAgIGNvbnNl cXVlbmNlcyBvZiBpbnRlcm5hbCBhdHRhY2tzIG1heWJlIG5vIGxlc3Mgc2V2ZXJlIC0tIGluIGZh Y3QgdGhleQogICBtYXkgYmUgcXVpdGUgYSBiaXQgbW9yZSBzZXZlcmUgLS0gdGhhbiBhbiBleHRl cm5hbCBhdHRhY2suICBBbgogICBleGFtcGxlIG9mIHRoaXMgaW50ZXJuYWwgdmVyc3VzIGV4dGVy bmFsIGNvbnNpZGVyYXRpb24gaXMgQkdQIHdoaWNoCiAgIGhhcyBib3RoIEVCR1AgYW5kIElCR1Ag bW9kZXMuICBBbm90aGVyIGV4YW1wbGUgaXMgYSBtdWx0aWNhc3QKICAgcHJvdG9jb2wgd2hlcmUg dGhlIG5laWdoYm9ycyBhcmUgc29tZXRpbWVzIHdpdGhpbiBhIGRvbWFpbiBvZiBjb250cm9sCiAg IGFuZCBzb21ldGltZXMgYXQgYW4gaW50ZXItZG9tYWluIGV4Y2hhbmdlIHBvaW50LiAgSW4gdGhl IGNhc2Ugb2YKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAx MCAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgUElNLVNN IHJ1bm5pbmcgb24gYW4gaW50ZXJuYWwgbXVsdGktYWNjZXNzIGxpbmssIEl0IHdvdWxkIGJlCiAg IGFjY2VwdGFibGUgdG8gZ2l2ZSB1cCBzb21lIHNlY3VyaXR5IHRvIGdldCBzb21lIGNvbnZlbmll bmNlIGJ5IHVzaW5nCiAgIGEgZ3JvdXAga2V5IGJldHdlZW4gdGhlIHBlZXJzIG9uIHRoZSBsaW5r LiAgT24gdGhlIG90aGVyIGhhbmQsIGluIHRoZQogICBjYXNlIG9mIFBJTS1TTSBydW5uaW5nIG92 ZXIgYSBtdWx0aS1hY2Nlc3MgbGluayBhdCBhIHB1YmxpYyBleGNoYW5nZQogICBwb2ludCwgb3Bl cmF0b3JzIG1heSBmYXZvciBzZWN1cml0eSBvdmVyIGNvbnZlbmllbmNlIGJ5IHVzaW5nIHVuaXF1 ZQogICBwYWlyLXdpc2Uga2V5cyBmb3IgZXZlcnkgcGVlci4gIERlc2lnbmVycyBtdXN0IGNvbnNp ZGVyIGJvdGggbW9kZXMgb2YKICAgb3BlcmF0aW9uIGFuZCBlbnN1cmUgdGhlIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMgZml0IGJvdGguCgogICBPcGVyYXRvcnMgYXJlIGVuY291cmFnZWQgdG8g cnVuIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24gb24gYWxsCiAgIHRoZWlyIGFkamFjZW5j aWVzLCBidXQgdG8gd29yayBmcm9tIHRoZSBvdXRzaWRlIGluLCBpLmUuICBUaGUgRUJHUAogICBs aW5rcyBhcmUgYSBoaWdoZXIgcHJpb3JpdHkgdGhhbiB0aGUgSUJHUCBsaW5rcyBiZWNhdXNlIHRo ZXkgYXJlCiAgIGV4dGVybmFsbHkgZmFjaW5nLCBhbmQsIGFzIGEgcmVzdWx0LCBtb3JlIGxpa2Vs eSB0byBiZSB0YXJnZXRlZCBpbiBhbgogICBhdHRhY2suCgozLjQuMi4gIFVuaXF1ZSB2ZXJzdXMg U2hhcmVkIEtleXMKCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgcmVnYXJkaW5nIHdoZW4gaXQgaXMKICAgYXBwcm9wcmlhdGUgdG8gdXNlIHRoZSBzYW1l IGF1dGhlbnRpY2F0aW9uIGtleSBpbnB1dHMgZm9yIG11bHRpcGxlCiAgIHBlZXJzIGFuZCB3aGVu IGl0IGlzIG5vdC4gIFRoaXMgaXMgbGFyZ2VseSBhIGRlYmF0ZSBvZiBjb252ZW5pZW5jZQogICB2 ZXJzdXMgc2VjdXJpdHkuICBJdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IHRoZSBiZXN0IHNlY3Vy ZWQKICAgbWVjaGFuaXNtIGlzIGFsc28gdGhlIGxlYXN0IGNvbnZlbmllbnQgbWVjaGFuaXNtLiAg Rm9yIGV4YW1wbGUsIGFuCiAgIGFpciBnYXAgYmV0d2VlbiBhIGhvc3QgYW5kIHRoZSBuZXR3b3Jr IGFic29sdXRlbHkgcHJldmVudHMgcmVtb3RlCiAgIGF0dGFja3Mgb24gdGhlIGhvc3QsIGJ1dCBo YXZpbmcgdG8gY29weSBhbmQgY2FycnkgZmlsZXMgdXNpbmcgdGhlCiAgICJzbmVha2VyIG5ldCIg aXMgcXVpdGUgaW5jb252ZW5pZW50IGFuZCB1bnNjYWxhYmxlLgoKICAgT3BlcmF0b3JzIGhhdmUg ZXJyZWQgb24gdGhlIHNpZGUgb2YgY29udmVuaWVuY2Ugd2hlbiBpdCBjb21lcyB0bwogICBzZWN1 cmluZyByb3V0aW5nIHByb3RvY29scyB3aXRoIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24u ICBNYW55CiAgIGRvIG5vdCB1c2UgaXQgYXQgYWxsLiAgU29tZSB1c2UgaXQgb25seSBvbiBleHRl cm5hbCBsaW5rcywgYnV0IG5vdCBvbgogICBpbnRlcm5hbCBsaW5rcy4gIFRob3NlIHRoYXQgZG8g dXNlIGl0IG9mdGVuIHVzZSB0aGUgc2FtZSBrZXkgZm9yIGFsbAogICBwZWVycyBhY3Jvc3MgdGhl aXIgZW50aXJlIG5ldHdvcmsuICBJdCBpcyBjb21tb24gdG8gc2VlIHRoZSBzYW1lIGtleQogICBp biB1c2UgZm9yIHllYXJzLCBhbmQgdGhhdCBiZWluZyB0aGUgc2FtZSBrZXkgdGhhdCB3YXMgZW50 ZXJlZCB3aGVuCiAgIGF1dGhlbnRpY2F0aW9uIHdhcyBvcmlnaW5hbGx5IGNvbmZpZ3VyZWQsIG9y IHRoZSByb3V0aW5nIGdlYXIKICAgZGVwbG95ZWQuCgogICBUaGUgZ29hbCBmb3IgZGVzaWduZXJz IGlzIHRvIGNyZWF0ZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIHRoYXQKICAgYXJlIGVhc3kg Zm9yIHRoZSBvcGVyYXRvcnMgdG8gZGVwbG95IGFuZCBtYW5hZ2UsIGFuZCBzdGlsbCB1c2UgdW5p cXVlCiAgIGtleXMgYmV0d2VlbiBwZWVycyAob3Igc21hbGwgZ3JvdXBzIG9uIG11bHRpLWFjY2Vz cyBsaW5rcyksIGFuZAogICB3aXRoaW4gYmV0d2VlbiBzZXNzaW9ucy4gIE9wZXJhdG9ycyBoYXZl IHRoZSBpbXByZXNzaW9uIHRoYXQgdGhleQogICBORUVEIG9uZSBrZXkgc2hhcmVkIGFjcm9zcyB0 aGUgbmV0d29yaywgd2hlbiBpbiBmYWN0IHRoZXkgZG8gbm90LgogICBXaGF0IHRoZXkgbmVlZCBp cyB0aGUgcmVsYXRpdmUgY29udmVuaWVuY2UgdGhleSBleHBlcmllbmNlIGZyb20KICAgZGVwbG95 aW5nIGNyeXB0b2dyYXBoaWMgYXV0aGVudGljYXRpb24gd2l0aCBvbmUgKG9yIGZldykga2V5LAog ICBjb21wYXJlZCB0byB0aGUgaW5jb252ZW5pZW5jZSB0aGV5IHdvdWxkIGV4cGVyaWVuY2UgaWYg dGhleSBkZXBsb3llZAogICB0aGUgc2FtZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gdXNpbmcg dW5pcXVlIHBhaXItd2lzZSBrZXlzLiAgQW4KICAgZXhhbXBsZSBpcyBCR1AgUm91dGUgUmVmbGVj dG9ycy4gIEhlcmUgb3BlcmF0b3JzIG9mdGVuIHVzZSB0aGUgc2FtZQogICBhdXRoZW50aWNhdGlv biBrZXkgYmV0d2VlbiBlYWNoIGNsaWVudCBhbmQgdGhlIHJvdXRlIHJlZmxlY3Rvci4gIFRoZQog ICByb2FkbWFwcyBkZWZpbmVkIGZyb20gdGhpcyBndWlkYW5jZSBkb2N1bWVudCB3aWxsIGFsbG93 IGZvciB1bmlxdWUKICAga2V5cyB0byBiZSB1c2VkIGJldHdlZW4gZWFjaCBjbGllbnQgYW5kIHRo ZSBwZWVyLCB3aXRob3V0IHNhY3JpZmljaW5nCiAgIG11Y2ggY29udmVuaWVuY2UuICBEZXNpZ25l cnMgc2hvdWxkIHN0cml2ZSB0byBkZWxpdmVyIHBlZXItd2lzZQoKCgpMZWJvdml0eiAmICAgICAg ICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAxOV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMDkKCgogICB1bmlxdWUga2V5aW5nIG1lY2hhbmlzbXMgd2l0aCBzaW1p bGFyIGVhc2Utb2YtZGVwbG95bWVudCBwcm9wZXJ0aWVzCiAgIGFzIHRvZGF5J3Mgb25lLWtleSBt ZXRob2QuCgogICBPcGVyYXRvcnMgbXVzdCB1bmRlcnN0YW5kIHRoZSBjb25zZXF1ZW5jZXMgb2Yg dXNpbmcgdGhlIHNhbWUga2V5cwogICBhY3Jvc3MgbWFueSBwZWVycy4gIFVuaXF1ZSBrZXlzIGFy ZSBtb3JlIHNlY3VyZSB0aGFuIHNoYXJlZCBrZXlzCiAgIGJlY2F1c2UgdGhleSByZWR1Y2UgYm90 aCB0aGUgYXR0YWNrIHRhcmdldCBzaXplIGFuZCB0aGUgYXR0YWNrCiAgIGNvbnNlcXVlbmNlIHNp emUuICBJbiB0aGlzIGNvbnRleHQsIHRoZSBhdHRhY2sgdGFyZ2V0IHNpemUgcmVwcmVzZW50cwog ICB0aGUgbnVtYmVyIG9mIHVuaXF1ZSByb3V0aW5nIGV4Y2hhbmdlcyBhY3Jvc3MgYSBuZXR3b3Jr IHRoYXQgYW4KICAgYXR0YWNrZXIgbWF5IGJlIGFibGUgdG8gb2JzZXJ2ZSBpbiBvcmRlciB0byBn YWluIHNlY3VyaXR5IGFzc29jaWF0aW9uCiAgIGNyZWRlbnRpYWxzLCBpLmUuIGNyYWNrIHRoZSBr ZXlzLiAgSWYgYSBzaGFyZWQga2V5IGlzIHVzZWQgYWNyb3NzIHRoZQogICBlbnRpcmUgaW50ZXJu YWwgZG9tYWluIG9mIGNvbnRyb2wsIHRoZW4gdGhlIGF0dGFjayB0YXJnZXQgc2l6ZSBpcwogICB2 ZXJ5IGxhcmdlLiAgVGhlIGxhcmdlciB0aGUgYXR0YWNrIHRhcmdldCwgdGhlIGVhc2llciBpdCBp cyBmb3IgdGhlCiAgIGF0dGFja2VyIHRvIGdhaW4gYWNjZXNzIHRvIGFuYWx5c2lzIGRhdGEsIGFu ZCBncmVhdGVyIHRoZSB2b2x1bWUgb2YKICAgYW5hbHlzaXMgZGF0YSBoZSBjYW4gYWNjZXNzIGlu IGEgZ2l2ZW4gdGltZSBmcmFtZSwgYm90aCBvZiB3aGljaCBtYWtlCiAgIGhpcyBqb2IgZWFzaWVy LiAgVXNpbmcgdGhlIHNhbWUga2V5IGFjcm9zcyB0aGUgbmV0d29yayBtYWtlcyB0aGUKICAgYXR0 YWNrIHZ1bG5lcmFiaWxpdHkgc3VyZmFjZSBtb3JlIHBlbmV0cmFibGUgdGhhbiB1bmlxdWUga2V5 cy4KICAgQ29uc2lkZXIgYWxzbyB0aGUgYXR0YWNrIGNvbnNlcXVlbmNlIHNpemUsIHRoZSBhbW91 bnQgb2Ygcm91dGluZwogICBhZGphY2VuY2llcyB0aGF0IGNhbiBiZSBuZWdhdGl2ZWx5IGFmZmVj dGVkIG9uY2UgYSBicmVhY2ggaGFzCiAgIG9jY3VycmVkLCBpLmUuIG9uY2UgdGhlIGtleXMgaGF2 ZSBiZWVuIGFjcXVpcmVkIGJ5IHRoZSBhdHRhY2tlci4KICAgQWdhaW4sIGlmIGEgc2hhcmVkIGtl eSBpcyB1c2VkIGFjcm9zcyB0aGUgaW50ZXJuYWwgZG9tYWluLCB0aGVuIHRoZQogICBjb25zZXF1 ZW5jZSBzaXplIGlzIHRoZSB3aG9sZSBuZXR3b3JrLiAgSWRlYWxseSwgdW5pcXVlIGtleSBwYWly cwogICB3b3VsZCBiZSB1c2VkIGZvciBlYWNoIGFkamFjZW5jeS4KCiAgIEluIHNvbWUgY2FzZXMg ZGVzaWduZXJzIG1heSBuZWVkIHRvIHVzZSBzaGFyZWQga2V5cyBpbiBvcmRlciB0byBzb2x2ZQog ICB0aGUgZ2l2ZW4gcHJvYmxlbSBzcGFjZS4gIEZvciBleGFtcGxlLCBhIG11bHRpY2FzdCBwYWNr ZXQgaXMgc2VudAogICBvbmNlIGJ1dCB0aGVuIG9ic2VydmVkIGFuZCBjb25zdW1lZCBieSBzZXZl cmFsIHJvdXRpbmcgbmVpZ2hib3JzLiAgSWYKICAgdW5pcXVlIGtleXMgd2VyZSB1c2VkIHBlciBu ZWlnaGJvciwgdGhlIGJlbmVmaXQgb2YgbXVsdGljYXN0IHdvdWxkIGJlCiAgIGVyYXNlZCBiZWNh dXNlIHRoZSBjYXN0aW5nIHBlZXIgd291bGQgaGF2ZSB0byBjcmVhdGUgYSBkaWZmZXJlbnQKICAg YW5ub3VuY2VtZW50IHBhY2tldC9zdHJlYW0gZm9yIGVhY2ggbGlzdGVuaW5nIHBlZXIuICBUaG91 Z2ggdGhpcyBtYXkKICAgYmUgZGVzaXJlZCBhbmQgYWNjZXB0YWJsZSBpbiBzb21lIHNtYWxsIGFt b3VudCBvZiB1c2UgY2FzZXMsIGl0IGlzCiAgIG5vdCB0aGUgbm9ybS4gIFNoYXJlZCBncm91cCBr ZXlzIGFyZSBhbiBhY2NlcHRhYmxlIHNvbHV0aW9uIGhlcmUsIGFuZAogICBtdWNoIHdvcmsgaGFz IGJlZW4gZG9uZSBhbHJlYWR5IGluIHRoaXMgYXJlYSAoc2VlIE1TRUMgd29ya2luZwogICBncm91 cCkuCgozLjQuMy4gIE91dC1vZi1CYW5kIHZzLiBJbi1saW5lIEtleSBNYW5hZ2VtZW50CgogICBU aGlzIHNlY3Rpb24gZGlzY3Vzc2VzIHRoZSBzZWN1cml0eSBhbmQgdXNlIGNhc2UgY29uc2lkZXJh dGlvbnMgZm9yCiAgIGtleXMgcGxhY2VkIG9uIGRldmljZXMgdGhyb3VnaCBvdXQtb2YtYmFuZCBj b25maWd1cmF0aW9ucyB2ZXJzdXMKICAgdGhyb3VnaCBvbmUgcm91dGluZyBwZWVyLXRvLXBlZXIg a2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgZXhjaGFuZ2VzLgogICBOb3RlLCB3aGVuIHdlIHNheSBo ZXJlICJQZWVyLXRvLVBlZXIgS01QIiB3ZSBkbyBub3QgbWVhbiBpbi1iYW5kIHRvCiAgIHRoZSBS b3V0aW5nIFByb3RvY29sLiAgSW5zdGVhZCwgd2UgbWVhbiB0aGF0IHRoZSBleGNoYW5nZSBvY2N1 cnMgaW4tCiAgIGxpbmUsIG92ZXIgSVAsIGJldHdlZW4gdGhlIHR3byByb3V0aW5nIHBlZXJzIGRp cmVjdGx5LiAgSW4gaW4tbGluZQogICBLTVAgdGhlIHBlZXJzIHRoZW1zZWx2ZXMgaGFuZGxlIHRo ZSBrZXkgYW5kIHNlY3VyaXR5IGFzc29jaWF0aW9uCiAgIG5lZ290aWF0aW9uIGJldHdlZW4gdGhl bXNlbHZlcyBkaXJlY3RseSwgd2hlcmVhcyBpbiBhbiBvdXQtb2YtYmFuZAogICBzeXN0ZW0gdGhl IGtleXMgYXJlIHBsYWNlZCBvbnRvIHRoZSBkZXZpY2UgdGhyb3VnaCBzb21lIG90aGVyCiAgIGNv bmZpZ3VyYXRpb24gb3IgbWFuYWdlbWVudCBtZXRob2Qgb3IgaW50ZXJmYWNlLgoKICAgQW4gZXhh bXBsZSBvZiBhbiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gY291bGQgYmUgYW4gYWRtaW5pc3RyYXRv ciB3aG8KCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAg ICAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg S0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgbWFrZXMgYSBy ZW1vdGUgbWFuYWdlbWVudCBjb25uZWN0aW9uIChlLmcuIHVzaW5nIFNTSCkgdG8gYSByb3V0ZXIg YW5kCiAgIG1hbnVhbGx5IGVudGVycyB0aGUga2V5aW5nIGluZm9ybWF0aW9uIC0tIGxpa2UgdGhl IGFsZ29yaXRobSwgdGhlCiAgIGtleShzKSwgdGhlIGxpZmV0aW1lcywgZXRjLiAgQW5vdGhlciBl eGFtcGxlIGNvdWxkIGJlIGFuIE9TUyBzeXN0ZW0KICAgd2hpY2ggaW5wdXRzIHRoZSBzYW1lIGlu Zm9ybWF0aW9uIHZpYSBhIHNjcmlwdCBvdmVyIGFuIFNTSAogICBjb25uZWN0aW9uLCBvciBieSBw dXNoaW5nIGNvbmZpZ3VyYXRpb24gdGhyb3VnaCBzb21lIG90aGVyIG1hbmFnZW1lbnQKICAgY29u bmVjdGlvbiwgc3RhbmRhcmQgKE5ldGNvbmYtYmFzZWQpIG9yIHByb3ByaWV0YXJ5LgoKICAgVGhl IGRyYXdiYWNrcyBvZiBhbiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gaW5jbHVkZTogbGFjayBvZiBz Y2FsZS0KICAgYWJpbGl0eSwgY29tcGxleGl0eSBhbmQgc3BlZWQgb2YgY2hhbmdpbmcgaWYgYSBi cmVhY2ggaXMgc3VzcGVjdGVkLgogICBGb3IgZXhhbXBsZSwgaWYgYW4gZW1wbG95ZWUgd2hvIGhh ZCBhY2Nlc3MgdG8ga2V5cyB3YXMgd2FzCiAgIHRlcm1pbmF0ZWQsIG9yIGlmIGEgbWFjaGluZSBo b2xkaW5nIHRob3NlIGtleXMgd2FzIGJlbGl2ZWQKICAgY29tcHJvbWlzZWQsIHRoZW4gdGhlIHN5 c3RlbSB3b3VsZCBiZSBjb25zaWRlcmVkIGluc2VjdXJlIGFuZAogICB2dWxuZXJhYmxlIHVudGls IG5ldyBrZXlzIHdlcmUgZGVmaW5lZCBieSBhIGh1bWFuLiAgVGhvc2Uga2V5cyB0aGVuCiAgIG5l ZWQgdG8gYmUgcGxhY2VkIGludG8gdGhlIE9TUyBzeXN0ZW0sIG1hbnVhbGx5LCBhbmQgdGhlIE9T UyBzeXN0ZW0KICAgdGhlbiBuZWVkcyB0byBwdXNoIHRoZSBjaGFuZ2UgLS0gb2Z0ZW4gZHVyaW5n IGEgdmVyeSBsaW1pdGVkIGNoYW5nZQogICB3aW5kb3cgLS0gaW50byB0aGUgcmVsZXZhbnQgZGV2 aWNlcy4gIElmIHRoZXJlIGFyZSBtdWx0aXBsZQogICBvcmdhbml6YXRpb25zIGludm9sdmVkIGlu IHRoZXNlIGNvbm5lY3Rpb25zLCB0aGlzIHByb2Nlc3MgaXMgZ3JlYXRseQogICBjb21wbGljYXRl ZC4KCiAgIFRoZSBiZW5lZml0cyBvZiBvdXQtb2YtYmFuZCBtZWNoYW5pc20gaXMgdGhhdCBvbmNl IHRoZSBuZXcga2V5cy8KICAgcGFyYW1ldGVycyBhcmUgc2V0IGluIE9TUyBzeXN0ZW0gdGhleSBj YW4gYmUgcHVzaGVkIGF1dG9tYXRpY2FsbHkgdG8KICAgYWxsIGRldmljZXMgd2l0aGluIHRoZSBP U1MncyBkb21haW4gb2YgY29udHJvbC4gIE9wZXJhdG9ycyBoYXZlCiAgIG1lY2hhbmlzbXMgaW4g cGxhY2UgZm9yIHRoaXMgYWxyZWFkeS4gIEluIHNtYWxsIGVudmlyb25tZW50cyB3aXRoIGZldwog ICByb3V0ZXJzLCBhIG1hbnVhbCBzeXN0ZW0gaXMgbm90IGRpZmZpY3VsdCB0byBlbXBsb3kuCgog ICBXZSBmdXJ0aGVyIGRlZmluZSBhbiBpbi1saW5lIGtleSBleGNoYW5nZSBhcyB1c2luZyBjcnlw dG9ncmFwaGljbHkKICAgcHJvdGVjdGVkIGlkZW50aXR5IHZlcmlmaWNhdGlvbiwgc2Vzc2lvbiBr ZXkgbmVnb3RpYXRpb24sIGFuZAogICBzZWN1cml0eSBhc3NvY2lhdGlvbiBwYXJhbWV0ZXIgbmVn b3RpYXRpb24gYmV0d2VlbiB0aGUgdHdvIHJvdXRpbmcKICAgcGVlcnMuICBUaGUgS01QIGJldHdl ZW4gdGhlIHR3byBwZWVycyBtYXkgYWxzbyBpbmNsdWRlIHRoZQogICBuZWdvdGlhdGlvbiBvZiBw YXJhbWV0ZXJzLCBsaWtlIGFsZ29yaXRobXMsIGNyeXB0b2dyYXBoaWMgaW5wdXRzCiAgIChlLmcu IGluaXRpYWxpemF0aW9uIHZlY3RvcnMpLCBrZXkgbGlmZS10aW1lcywgZXRjLgoKICAgVGhlIGJl bmVmaXRzIGFuIGluLWxpbmUgS01QIGFyZSBzZXZlcmFsLiAgQW4gaW4tbGluZSBLTVAgcmVzdWx0 cyBpbgogICBrZXkocykgdGhhdCBhcmUgcHJpdmF0ZWx5IGdlbmVyYXRlZCwgYW5kIG5vdCByZWNv cmRlZCBwZXJtYW5lbnRseQogICBhbnl3aGVyZS4gIFNpbmNlIHRoZSB0cmFmZmljIGtleXMgdXNl ZCBpbiBhIHBhcnRpY3VsYXIgY29ubmVjdGlvbiBhcmUKICAgbm90IGEgZml4ZWQgcGFydCBvZiBh IGRldmljZSBjb25maWd1cmF0aW9uIG5vIHN0ZWFsLWFibGUgZGF0YSBleGlzdHMKICAgYW55d2hl cmUgZWxzZSBpbiB0aGUgb3BlcmF0b3IncyBzeXN0ZW1zIHdoaWNoIGNhbiBiZSBzdG9sZW4sIGUu Zy4gaW4KICAgdGhlIGNhc2Ugb2YgYSB0ZXJtaW5hdGVkIG9yIHR1cm5lZCBlbXBsb3llZS4gIElm IGEgc2VydmVyIG9yIG90aGVyCiAgIGRhdGEgc3RvcmUgaXMgc3RvbGVuIG9yIGNvbXByb21pc2Vk LCB0aGUgdGhpZXZlcyBnYWluIG5vIGFjY2VzcyB0bwogICBjdXJyZW50IHRyYWZmaWMga2V5cy4g IFRoZXkgbWF5IGdhaW4gYWNjZXNzIHRvIGtleSBkZXJpdmF0aW9uCiAgIG1hdGVyaWFsLCBsaWtl IGEgUFNLLCBidXQgbm90IGN1cnJlbnQgdHJhZmZpYyBrZXlzIGluIHVzZS4gIEluIHRoaXMKICAg ZXhhbXBsZSwgdGhlc2UgUFNLcyBjYW4gYmUgdXBkYXRlZCBpbnRvIHRoZSBkZXZpY2UgY29uZmln dXJhdGlvbnMKICAgKGVpdGhlciBtYW51YWxseSBvciB0aHJvdWdoIGFuIE9TUykgd2l0aG91dCBi b3VuY2luZyBvciBpbXBhY3RpbmcgdGhlCiAgIGV4aXN0aW5nIHNlc3Npb24gYXQgYWxsLiAgSW4g dGhlIGNhc2Ugb2YgdXNpbmcgcmF3IGFzc3ltZXRyaWMga2V5cyBvcgogICBjZXJ0aWZpY2F0ZXMs IGluc3RlYWQgb2YgUFNLcywgdGhlIGRhdGEgdGhlZnQgd291bGQgbGlrZWx5IG5vdCBldmVuCiAg IHJlc3VsdCBpbiBhbnkgY29tcHJvbWlzZSwgYXMgdGhlIGtleSBwYWlycyB3b3VsZCBoYXZlIGJl ZW4gZ2VuZXJhdGVkCiAgIG9uIHRoZSByb3V0ZXJzLCBhbmQgbmV2ZXIgbGVhdmUgdGhvc2Ugcm91 dGVycy4gIEluIHN1Y2ggYSBjYXNlIG5vCiAgIGNoYW5nZXMgYXJlIG5lZWRlZCBvbiB0aGUgcm91 dGVyczsgdGhlIGNvbm5lY3Rpb25zIHdpbGwgY29udGludWUgdG8KCgoKTGVib3ZpdHogJiAgICAg ICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMjFd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAg ICAgICBOb3ZlbWJlciAyMDA5CgoKICAgYmUgc2VjdXJlLCB1bmNvbXByb21pc2VkLiAgQWRkaXRp b25hbGx5LCB3aXRoIGEgS01QIHJlZ3VsYXIgcmUta2V5cwogICBvcGVyYXRpb25zIG9jY3VyIHdp dGhvdXQgYW55IG9wZXJhdG9yIGludm9sdmVtZW50IG9yIG92ZXJzaWdodC4gIFRoaXMKICAga2Vl cHMga2V5cyBmcmVzaC4KCiAgIFRoZSBkcmF3YmFja3MgdG8gdXNpbmcgYSBLTVAgYXJlIGZldy4g IEZpcnN0LCBhIEtNUCByZXF1aXJlcyBtb3JlCiAgIGNyeXB0b2dyYXBoaWMgcHJvY2Vzc2luZyBm b3IgdGhlIHJvdXRlciBhdCB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgYQogICBjb25uZWN0aW9uLiAg VGhpcyB3aWxsIGFkZCBzb21lIG1pbm9yIHN0YXJ0LXVwIHRpbWUgdG8gY29ubmVjdGlvbgogICBl c3RhYmxpc2htZW50IHZlcnN1cyBhIHB1cmVseSBtYW51YWwga2V5IGFwcHJvYWNoLiAgT25jZSBh IGNvbm5lY3Rpb24KICAgd2l0aCB0cmFmZmljIGtleXMgaGF2ZSBiZWVuIGVzdGFibGlzaGVkIHZp YSBhIEtNUCwgdGhlIHBlcmZvcm1hbmNlIGlzCiAgIHRoZSBzYW1lIGluIHRoZSBLTVAgYW5kIHRo ZSBvdXQtb2YtYmFuZCBjYXNlLiAgS01QcyBhbHNvIGFkZCBhbm90aGVyCiAgIGxheWVyIG9mIHBy b3RvY29sIGFuZCBjb25maWd1cmF0aW9uIGNvbXBsZXhpdHkgd2hpY2ggY2FuIGZhaWwgb3IgYmUK ICAgbWlzY29uZmlndXJlZC4gIFRoaXMgd2FzIG1vcmUgb2YgYW4gaXNzdWUgd2hlbiB0aGVzZSBL TVBzIHdlcmUgZmlyc3QKICAgZGVwbG95ZWQsIGJ1dCBsZXNzIHNvIGFzIHRoZXNlIGltcGxlbWVu dGFpdG9ucyBhbmQgb3BlcmF0aW9uYWwKICAgZXhwZXJpZW5jZSB3aXRoIHRoZW0gaGFzIG1hdHVy ZWQuCgogICBUaGUgZGVzaXJlZCBlbmQgZ29hbCBpcyBpbi1saW5lIEtNUHMuCgoKNC4gIFRoZSBS b2FkbWFwCgo0LjEuICBXb3JrIFBoYXNlcyBvbiBhbnkgUGFydGljdWxhciBQcm90b2NvbAoKICAg VGhlIGRlc2lyZWQgZW5kc3RhdGUgZm9yIHRoZSBLQVJQIHdvcmsgY29udGFpbnMgc2V2ZXJhbCBp dGVtcy4KICAgRmlyc3QsIHRoZSBwZW9wbGUgZGVzaXJpbmcgdG8gZGVwbG95IHNlY3VyZWx5IGF1 dGhlbnRpY2F0ZWQgYW5kCiAgIGludGVncml0eSB2YWxpZGF0ZWQgcGFja2V0cyBiZXR3ZWVuIHJv dXRpbmcgcGVlcnMgaGF2ZSB0aGUgdG9vbHMKICAgc3BlY2lmaWVkLCBpbXBsZW1lbnRlZCBhbmQg c2hpcHBpbmcgaW4gb3JkZXIgdG8gZGVwbG95LiAgVGhlc2UgdG9vbHMKICAgc2hvdWxkIGJlIGZh aXJseSBzaW1wbGUgdG8gaW1wbGVtZW50LCBhbmQgbm90IG1vcmUgY29tcGxleCB0aGFuIHRoZQog ICBzZWN1cml0eSBtZWNoYW5pc21zIHRvIHdoaWNoIHRoZSBvcGVyYXRvcnMgYXJlIGFscmVhZHkg YWNjdXN0b21lZC4KICAgKEV4YW1wbGVzIG9mIHNlY3VyaXR5IG1lY2hhbmlzbXMgdG8gd2hpY2gg cm91dGVyIG9wZXJhdG9ycyBhcmUKICAgYWNjdXN0b21lZCBpbmNsdWRlOiB0aGUgdXNlIG9mIGFz c3ltZXRyaWMga2V5cyBmb3IgYXV0aGVudGljYXRpb24gaW4KICAgU1NIIGZvciByb3V0ZXIgY29u ZmlndXJhdGlvbiwgdGhlIHVzZSBvZiBwcmUtc2hhcmVkIGtleXMgKFBTS3MpIGluCiAgIFRDUCBN RDUgZm9yIEJHUCBwcm90ZWN0aW9uLCB0aGUgdXNlIG9mIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRl cyBmb3IKICAgSFRUUFMgYWNjZXNzIHRvIGRldmljZSBXZWItYmFzZWQgdXNlciBpbnRlcmZhY2Vz LCB0aGUgdXNlIG9mIHN0cm9uZ2x5CiAgIGNvbnN0cnVjdGVkIHBhc3N3b3JkcyBhbmQvb3IgaWRl bnRpdHkgdG9rZW5zIGZvciB1c2VyIGlkZW50aWZpY2F0aW9uCiAgIHdoZW4gbG9nZ2luZyBpbnRv IHJvdXRlcnMgYW5kIG1hbmFnZW1lbnQgc3lzdGVtcy4pICBXaGlsZSB0aGUgdG9vbHMKICAgdGhh dCB3ZSBpbnRlbmQgdG8gc3BlY2lmeSBtYXkgbm90IGJlIGFibGUgdG8gc3RvcCBhIGRlcGxveW1l bnQgZnJvbQogICB1c2luZyAiZm9vYmFyIiBhcyBhbiBpbnB1dCBrZXkgZm9yIGV2ZXJ5IGRldmlj ZSBhY3Jvc3MgdGhlaXIgZW50aXJlCiAgIHJvdXRpbmcgZG9tYWluLCB3ZSBpbnRlbmQgdG8gbWFr ZSBhIHNvbGlkLCBtb2Rlcm4gc2VjdXJpdHkgc3lzdGVtCiAgIHRoYXQgaXMgbm90IHRvbyBtdWNo IG1vcmUgZGlmZmljdWx0IHRoYW4gdGhhdC4gIEluIG90aGVyIHdvcmRzLAogICBzaW1wbGljaXR5 IGFuZCBkZXBsb3lhYmlsaXR5IGFyZSBrZXlzIHRvIHN1Y2Nlc3MuICBUaGUgUm91dGluZwogICBQ cm90b2NvbHMgd2lsbCBzcGVjaWZ5IG1vZGVybiBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgYW5k IHNlY3VyaXR5CiAgIG1lY2hhbmlzbXMuICBSb3V0aW5nIHBlZXJzIHdpbGwgYmUgYWJsZSB0byBl bXBsb3kgdW5pcXVlLCBwYWlyLXdpc2UKICAga2V5cyBwZXIgcGVlcmluZyBpbnN0YW5jZSwgd2l0 aCByZWFzb25hYmxlIGtleSBsaWZldGltZXMsIGFuZAogICB1cGRhdGluZyB0aG9zZSBrZXlzIG9u IGEgc29tZXdoYXQgcmVndWxhciBiYXNpcyB3aWxsIGJlIG9wZXJhdGlvbmFsbHkKICAgZWFzeSwg Y2F1c2luZyBubyBzZXJ2aWNlIGludGVycnVwdGlvbi4KCiAgIEFjaGlldmluZyB0aGUgYWJvdmUg ZGVzY3JpYmVkIGVuZC1zdGF0ZSB1c2luZyBtYW51YWwga2V5cyBtYXkgb25seSBiZQogICBwcmFn bWF0aWMgaW4gdmVyeSBzbWFsbCBkZXBsb3ltZW50cy4gIEluIGxhcmdlciBkZXBsb3ltZW50cywg dGhpcyBlbmQKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAx MCAgICAgICAgICAgICAgICAgW1BhZ2UgMjJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgc3RhdGUg d2lsbCBiZSBtdWNoIG1vcmUgb3BlcmF0aW9uYWxseSBkaWZmaWN1bHQgdG8gcmVhY2ggd2l0aCBv bmx5CiAgIG1hbnVhbCBrZXlzLiAgVGh1cywgdGhlcmUgd2lsbCBiZSBhIG5lZWQgZm9yIGtleSBs aWZlIGN5Y2xlCiAgIG1hbmFnZW1lbnQsIGluIHRoZSBmb3JtIG9mIGEga2V5IG1hbmFnZW1lbnQg cHJvdG9jb2wsIG9yIEtNUC4gIFdlCiAgIGV4cGVjdCB0aGF0IHRoZSB0d28gZm9ybXMsIG1hbnVh bCBrZXkgdXNhZ2UgYW5kIEtNUCB1c2FnZSwgd2lsbCBjby0KICAgZXhpc3QgaW4gdGhlIHJlYWwg d29ybGQuICBGb3IgZXhhbXBsZSwgYSBwcm92aWRlcidzIGVkZ2Ugcm91dGVyIGF0IGEKICAgcHVi bGljIGV4Y2hhbmdlIHBlZXJpbmcgcG9pbnQgd2lsbCB3YW50IHRvIHVzZSBhIEtNUCBmb3IgZW5z dXJpbmcKICAgdW5pcXVlIGFuZCBmcmVzaCBrZXlzIHdpdGggZXh0ZXJuYWwgcGVlcnMsIHdoaWxl IGEgbWFudWFsIGtleSBtYXkgYmUKICAgdXNlZCBiZXR3ZWVuIGEgcHJvdmlkZXIncyBhY2Nlc3Mg ZWRnZSByb3V0ZXIgYW5kIGVhY2ggb2YgdGhlIHNhbWUKICAgcHJvdmlkZXIncyBjdXN0b21lciBw cmVtaXNlIHJvdXRlcnMgd2l0aCB3aGljaCBpdCBwZWVycy4KCiAgIEluIGFjY29yZGFuY2Ugd2l0 aCB0aGUgZGVzaXJlZCBlbmQgc3RhdGUganVzdCBkZXNjcmliZWQsIHdlIGRlZmluZQogICB0d28g bWFpbiB3b3JrIHBoYXNlcyBmb3IgZWFjaCBSb3V0aW5nIFByb3RvY29sOgoKICAgMS4gIEVuaGFu Y2UgdGhlIFJvdXRpbmcgUHJvdG9jb2wncyBjdXJyZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bS4KICAgICAgIFRoaXMgd29yayBpbnZvbHZlcyBlbmhhbmNpbmcgYSBSb3V0aW5nIFByb3RvY29s J3MgY3VycmVudAogICAgICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBpbiBvcmRlciB0byBhY2hpZXZl IGEgY29uc2lzdGVudCwgbW9kZXJuCiAgICAgICBsZXZlbCBvZiBzZWN1cml0eSBmdW5jdGlvbmFs aXR5IHdpdGhpbiBpdHMgZXhpc3Rpbmcga2V5aW5nCiAgICAgICBmcmFtZXdvcmsuICBJdCBpcyB1 bmRlcnN0b29kIGFuZCBhY2NlcHRlZCB0aGF0IHRoZSBleGlzdGluZwogICAgICAga2V5aW5nIGZy YW1ld29ya3MgYXJlIGxhcmdlbHkgYmFzZWQgb24gbWFudWFsIGtleXMuICBTaW5jZSBtYW55CiAg ICAgICBvcGVyYXRvcnMgaGF2ZSBhbHJlYWR5IGJ1aWx0IG9wZXJhdGlvbmFsIHN1cHBvcnQgc3lz dGVtcyAoT1NTKQogICAgICAgYXJvdW5kIHRoZXNlIG1hbnVhbCBrZXkgaW1wbGVtZW50YXRpb25z LCB0aGVyZSBpcyBzb21lIGF1dG9tYXRpb24KICAgICAgIGF2YWlsYWJsZSBmb3IgYW4gb3BlcmF0 b3IgdG8gbGV2ZXJhZ2UgaW4gdGhhdCB3YXksIGlmIHRoZQogICAgICAgdW5kZXJseWluZyBtZWNo YW5pc21zIGFyZSB0aGVtc2VsdmVzIHNlY3VyZS4gIEluIHRoaXMgcGhhc2UsIHdlCiAgICAgICBl eHBsaWNpdGx5IGV4Y2x1ZGUgZW1iZWRkaW5nIG9yIGNyZWF0aW5nIGEgS01QLiAgQSBsaXN0IG9m IHRoZQogICAgICAgcmVxdWlyZW1lbnRzIGZvciBQaGFzZSAxIHdvcmsgYXJlIGJlbG93IGluIHRo ZSBzZWN0aW9uCiAgICAgICAiUmVxdWlyZW1lbnRzIGZvciBQaGFzZSAxIFJvdXRpbmcgUHJvdG9j b2xzJyBTZWN1cml0eSBVcGRhdGVzCiAgICAgICAoU2VjdGlvbiA0LjIpLgoKICAgMi4gIERldmVs b3AgYW4gYXV0b21hdGVkIGtleWluZyBmcmFtZXdvcmsuICBUaGUgc2Vjb25kIHBoYXNlIHdpbGwK ICAgICAgIGZvY3VzIG9uIHRoZSBkZXZlbG9wbWVudCBvZiBhbiBhdXRvbWF0ZWQga2V5aW5nIGZy YW1ld29yayB0bwogICAgICAgZmFjaWxpYXRlIHVuaXF1ZSBwYWlyLXdpc2UgKG9yIHBlcmhhcHMg Z3JvdXAtd2lzZSwgd2hlcmUKICAgICAgIGFwcGxpY2FibGUpIGtleXMgcGVyIHBlZXJpbmcgaW5z dGFuY2UuICBUaGlzIGludm9sdmVzIHRoZSB1c2Ugb2YKICAgICAgIGEgS01QLiAgQSBLTVAgaXMg aGVscGZ1bCBiZWNhdXNlIGl0IG5lZ290aWF0ZXMgdW5pcXVlLCBwYWlyIHdpc2UsCiAgICAgICBy YW5kb20ga2V5cyB3aXRob3V0IGFkbWluaXN0cmF0b3IgaW52b2x2ZW1lbnQuICBJdCBhbHNvCiAg ICAgICBuZWdvdGlhdGVzIHNldmVyYWwgb2YgdGhlIFNBIHBhcmFtZXRlcnMgcmVxdWlyZWQgZm9y IHRoZSBzZWN1cmUKICAgICAgIGNvbm5lY3Rpb24sIGluY2x1ZGluZyBrZXkgbGlmZSB0aW1lcy4g IEl0IGtlZXBzIHRyYWNrIG9mIHRob3NlCiAgICAgICBsaWZldGltZXMgdXNpbmcgY291bnRlcnMs IGFuZCBuZWdvdGlhdGVzIG5ldyBrZXlzIGFuZCBwYXJhbWV0ZXJzCiAgICAgICBiZWZvcmUgdGhl eSBleHBpcmUsIGFnYWluLCB3aXRob3V0IGFkbWluaXN0cmF0b3IgaW50ZXJhY3Rpb24uCiAgICAg ICBBZGRpdGlvbmFsbHksIGluIHRoZSBldmVudCBvZiBhIGJyZWFjaCwgY2hhbmdpbmcgdGhlIEtN UCBrZXkgd2lsbAogICAgICAgaW1tZWRpYXRlbHkgY2F1c2UgYSByZWtleSB0byBvY2N1ciBmb3Ig dGhlIFRyYWZmaWMgS2V5LCBhbmQgdGhvc2UKICAgICAgIG5ldyBUcmFmZmljIEtleXMgd2lsbCBi ZSBpbnN0YWxsZWQgYW5kIHVzZWQgaW4gdGhlIGN1cnJlbnQKICAgICAgIGNvbm5lY3Rpb24uICBJ biBzdW1tYXJ5LCBhIEtNUCBwcm92aWRlcyBhIHByb3RlY3RlZCBjaGFubmVsCiAgICAgICBiZXR3 ZWVuIHRoZSBwZWVycyB0aHJvdWdoIHdoaWNoIHRoZXkgY2FuIG5lZ290aWF0ZSBhbmQgcGFzcwog ICAgICAgaW1wb3J0YW50IGRhdGEgcmVxdWlyZWQgdG8gZXhjaGFuZ2UgcHJvb2Ygb2Yga2V5IGlk ZW50aWZpZXJzLAogICAgICAgZGVyaXZlIFRyYWZmaWMgS2V5cywgZGV0ZXJtaW5lIHJlLWtleWlu Zywgc3luY2hyb25pemUgdGhlaXIKICAgICAgIGtleWluZyBzdGF0ZSwgc2lnbmFsIHZhcmlvdXMg a2V5aW5nIGV2ZW50cywgbm90aWZ5IHdpdGggZXJyb3IKICAgICAgIG1lc3NhZ2VzLCBldGMuICBU byBhZGRyZXNzIGJydXRlIGZvcmNlIGF0dGFja3MgW1JGQzM1NjJdCiAgICAgICByZWNvbW1lbmRz IGEga2V5IG1hbmFnZW1lbnQgcHJhY3RpY2UgdG8gbWluaW1pemUgdGhlIHBvc3NpYmlsaXR5CgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9h ZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgICAgICBvZiBzdWNjZXNzZnVs IGF0dGFjay0tIGZyZXF1ZW50IGtleSByb3RhdGlvbiwgbGltaXRlZCBrZXkKICAgICAgIHNoYXJp bmcsIGtleSBsZW5ndGggcmVzdHJpY3Rpb25zLCBldGMuICBBZHZhbmNlcyBpbiBjb21wdXRhdGlv bmFsCiAgICAgICBwb3dlciBkdWUgdG8gTW9vcmUncyBsYXcgYXJlIG1ha2luZyB0aGF0IG1hbmFn ZW1lbnQgYnVyZGVuCiAgICAgICB1bnRlbmFibGUtLSBrZXlzIG11c3QgYmUgb2YgYSBzaXplIGFu ZCBjb21wb3NpdGlvbiB0aGF0IG1ha2VzCiAgICAgICBjb25maWd1cmF0aW9uIGFuZCBtYWludGFu Y2UgZGlmZmljdWx0IG9yIGtleXMgbXVzdCBiZSByb3RhdGVkCiAgICAgICB3aXRoIGFuIHVucmVh c29uYWJsZSBmcmVxdWVuY3kuICBBIEtNUCB3aWxsIGhlbHAgaW1tZW5zZWx5IHdpdGgKICAgICAg IHRoaXMgZ3Jvd2luZyBwcm9ibGVtLgoKICAgICAgIFRoZSBmcmFtZXdvcmsgZm9yIGFueSBvbmUg Um91dGluZyBQcm90b2NvbCB3aWxsIGZhbGwgdW5kZXIsIGFuZAogICAgICAgYmUgYWJsZSB0byBs ZXZlcmFnZSwgdGhlIGdlbmVyaWMgZnJhbWV3b3JrIGRlc2NyaWJlZCBiZWxvdyBpbgogICAgICAg c2VjdGlvbiBTZWN0aW9uIDQuMy4KCjQuMi4gIFJlcXVpcmVtZW50cyBmb3IgUGhhc2UgMSBSb3V0 aW5nIFByb3RvY29scycgU2VjdXJpdHkgVXBkYXRlCgogICBIZXJlIGlzIGEgcHJvcG9zZWQgbGlz dCBvZiByZXF1aXJlbWVudHMgdGhhdCBTSE9VTEQgYmUgYWRkcmVzc2VkIGJ5CiAgIFBoYXNlIDEg KGFjY29yZGluZyB0byAiMS4iIGFib3ZlKSBzZWN1cml0eSB1cGRhdGVzIHRvIFJvdXRpbmcKICAg UHJvdG9jb2xzIFt0byBiZSByZXZpZXdlZCBhZnRlciAtMDEgaXMgcmVsZWFzZWRdOgoKICAgMS4g ICBDbGVhciBkZWZpbml0aW9ucyBvZiB3aGljaCBlbGVtZW50cyBvZiB0aGUgdHJhbnNtaXNzaW9u IChmcmFtZSwKICAgICAgICBwYWNrZXQsIHNlZ21lbnQsIGV0Yy4pIGFyZSBwcm90ZWN0ZWQgYnkg dGhlIGF1dGhlbnRpY2F0aW9uCiAgICAgICAgbWVjaGFuaXNtCiAgIDIuICAgU3Ryb25nIGFsZ29y aXRobXMsIGFuZCBkZWZpbmVkIGFuZCBhY2NlcHRlZCBieSB0aGUgc2VjdXJpdHkKICAgICAgICBj b21tdW5pdHksIE1VU1QgYmUgc3BlY2lmaWVkLiAgVGhlIG9wdGlvbiBzaG91bGQgdXNlIGFsZ29y aXRobXMKICAgICAgICBjb25zaWRlcmVkIGFjY2VwdGVkIGJ5IHRoZSBzZWN1cml0eSBjb21tdW5p dHksIHdoaWNoIGFyZQogICAgICAgIGNvbnNpZGVyZWQgYXBwcm9wcmlhdGVseSBzYWZlLiAgVGhl IHVzZSBvZiBub24tc3RhbmRhcmQgb3IKICAgICAgICB1bnB1Ymxpc2hlZCBhbGdvcml0aG1zIFNI T1VMRCBCRSBhdm9pZGVkLgogICAzLiAgIEFsZ29yaXRobSBhZ2lsaXR5IGZvciB0aGUgY3J5cHRv Z3JhaHBpYyBhbGdvcml0aG1zIHVzZWQgaW4gdGhlCiAgICAgICAgYXV0aGVudGljYXRpb24gTVVT VCBiZSBzcGVjaWZpZWQsIGkuZS4gbW9yZSB0aGFuIG9uZSBhbGdvcml0aG0KICAgICAgICBNVVNU IGJlIHNwZWNpZmllZCBhbmQgaXQgTVVTVCBiZSBjbGVhciBob3cgbmV3IGFsZ29yaXRobXMgTUFZ IGJlCiAgICAgICAgc3BlY2lmaWVkIGFuZCB1c2VkIHdpdGhpbiB0aGUgcHJvdG9jb2wuICBUaGlz IHJlcXVpcmVtZW50IGV4aXN0cwogICAgICAgIGluIGNhc2Ugb25lIGFsZ29yaXRobSBnZXRzIGJy b2tlbiBzdWRkZW5seS4gIFJlc2VhcmNoIHRvCiAgICAgICAgaWRlbnRpZnkgd2Vha25lc3MgaW4g YWxnb3JpdGhtcyBpcyBjb25zdGFudC4gIEJyZWFraW5nIGEgY2lwaGVyCiAgICAgICAgaXNuJ3Qg YSBtYXR0ZXIgb2YgaWYsIGJ1dCB3aGVuIGl0IHdpbGwgb2NjdXIuIHQncyBoaWdobHkKICAgICAg ICB1bmxpa2VseSB0aGF0IHR3byBkaWZmZXJlbnQgYWxnb3JpdGhtcyB3aWxsIGJlIGJyb2tlbgog ICAgICAgIHNpbXVsdGFuZW91c2x5LiAgU28sIGlmIHR3byBhcmUgc3VwcG9ydGVkLCBhbmQgb25l IGdldHMgYnJva2VuLAogICAgICAgIHdlIGNhbiB1c2UgdGhlIG90aGVyIHVudGlsIHdlIGdldCBh IG5ldyBvbmUgaW4gcGxhY2UuICBIYXZpbmcKICAgICAgICB0aGUgYWJpbGl0eSB3aXRoaW4gdGhl IHByb3RvY29sIHNwZWNpZmljYXRpb24gdG8gc3VwcG9ydCBzdWNoIGFuCiAgICAgICAgZXZlbnQs IGhhdmluZyBhbGdvcml0aG0gYWdpbGl0eSwgaXMgZXNzZW50aWFsLiAgTWFuZGF0aW5nIHR3bwog ICAgICAgIGFsZ29yaXRobXMgcHJvdmlkZXMgYm90aCBhIHJlZHVuZGFuY3ksIGFuZCBhIG1lY2hh bmlzbSBmb3IKICAgICAgICBlbmFjdGluZyB0aGF0IHJlZHVuZGFuY3kgd2hlbiBuZWVkZWQuCiAg IDQuICAgU2VjdXJlIHVzZSBvZiBzaW1wbGUgUFNLcywgb2ZmZXJpbmcgYm90aCBvcGVyYXRpb25h bCBjb252ZW5pZW5jZQogICAgICAgIGFzIHdlbGwgYXMgYnVpbGRpbmcgc29tZXRoaW5nIG9mIGEg ZmVuY2UgYXJvdW5kIHN0dXBpZGl0eSwgTVVTVAogICAgICAgIGJlIHNwZWNpZmllZC4KICAgNS4g ICBJbnRlci1jb25uZWN0aW9uIHJlcGxheSBwcm90ZWN0aW9uLiAgUGFja2V0cyBjYXB0dXJlZCBm cm9tIG9uZQogICAgICAgIGNvbm5lY3Rpb24gTVVTVCBOT1QgYmUgYWJsZSB0byBiZSByZS1zZW50 IGFuZCBhY2NlcHRlZCBkdXJpbmcgYQogICAgICAgIGxhdGVyIGNvbm5lY3Rpb24uCgoKCgoKTGVi b3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAg ICAgW1BhZ2UgMjRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFw ICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgNi4gICBJbnRyYS1jb25uZWN0aW9u IHJlcGxheSBwcm90ZWN0aW9uLiAgUGFja2V0cyBjYXB0dXJlZCBkdXJpbmcgYQogICAgICAgIGNv bm5lY3Rpb24gTVVTVCBOT1QgYmUgYWJsZSB0byBiZSByZS1zZW50IGFuZCBhY2NlcHRlZCBkdXJp bmcKICAgICAgICB0aGF0IHNhbWUgY29ubmVjdGlvbiwgdG8gZGVhbCB3aXRoIGxvbmctbGl2ZWQg Y29ubmVjdGlvbnMuCiAgIDcuICAgQSBjaGFuZ2Ugb2Ygc2VjdXJpdHkgcGFyYW1ldGVycyBSRVFV SVJFUywgYW5kIGV2ZW4gZm9yY2VzLCBhCiAgICAgICAgY2hhbmdlIG9mIHNlc3Npb24gdHJhZmZp YyBrZXlzCiAgIDguICAgSW50cmEtY29ubmVjdGlvbiByZS1rZXlpbmcgd2hpY2ggb2NjdXJzIHdp dGhvdXQgYSBicmVhayBvcgogICAgICAgIGludGVycnVwdGlvbiB0byB0aGUgY3VycmVudCBwZWVy aW5nIHNlc3Npb24sIGFuZCwgaWYgcG9zc2libGUsCiAgICAgICAgd2l0aG91dCBkYXRhIGxvc3Ms IE1VU1QgYmUgc3BlY2lmaWVkLgogICA5LiAgIEVmZmljaWVudCByZS1rZXlpbmcgU0hPVUxEIGJl IHByb3ZpZGVkLiAgVGhlIHNwZWNpZmljYWlvbiBTSE9VTEQKICAgICAgICBzdXBwb3J0IHJla2V5 aW5nIGR1cmluZyBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUgbmVlZCB0byBleHBlbmQKICAgICAg ICB1bmR1ZSBjb21wdXRhdGlvbmFsIHJlc291cmNlcy4gIEluIHBhcnRpY3VsYXIsIHRoZSBzcGVj aWZpY2F0aW9uCiAgICAgICAgU0hPVUxEIGF2b2lkIHRoZSBuZWVkIHRvIHRyeS9jb21wdXRlIG11 bHRpcGxlIGtleXMgb24gYSBnaXZlbgogICAgICAgIHBhY2tldC4KICAgMTAuICBQcmV2ZW50IERv UyBhdHRhY2tzIGFzIHRob3NlIGRlc2NyaWJlZCBhcyBpbi1zY29wZSBpbiB0aGUKICAgICAgICB0 aHJlYXRzIHNlY3Rpb24gU2VjdGlvbiAyLjEgYWJvdmUuCiAgIDExLiAgRGVmYXVsdCBtZWNoYW5p c21zIGFuZCBhbGdvcml0aG1zIHNwZWNpZmllZCBhbmQgZGVmaW5lZCBhcwogICAgICAgIFJFUVVJ UkVEIGZvciBhbGwgaW1wbGVtZW50YXRpb25zCiAgIDEyLiAgTWFudWFsIGtleWluZyBNVVNUIGJl IHN1cHBvcnRlZC4KICAgMTMuICBDb252ZXJnZW5jZSB0aW1lcyBvZiB0aGUgUm91dGluZyBQcm90 b2NvbHMgU0hPVUxEIE5PVCBiZQogICAgICAgIG1hdGVyaWFsbHkgYWZmZWN0ZWQuICBNYXRlcmlh bGx5IGhlcmUgaXMgZGVmaW5lZCBhcyBhbnl0aGluZwogICAgICAgIGdyZWF0ZXIgdGhhbiBhIDUl IGNvbnZlcmdlbmNlIHRpbWUgaW5jcmVhc2UuICBOb3RlIHRoYXQKICAgICAgICBjb252ZXJnZW5j ZSBpcyBkaWZmZXJlbnQgdGhhbiBib290IHRpbWUuICBBbHNvIG5vdGUgdGhhdAogICAgICAgIGNv bnZlcmdlbmNlIHRpbWUgaGFzIGEgbG90IHRvIGRvIHdpdGggdGhlIHNwZWVkIG9mIHByb2Nlc3Nv cnMKICAgICAgICB1c2VkIG9uIGluZGl2aWR1YWwgcm91dGluZyBwZWVycywgYW5kIHRoaXMgaW5j cmVhc2VzIGJ5IE1vb3JlJ3MKICAgICAgICBsYXcgb3ZlciB0aW1lLiAgVGhlcmVmb3JlLCB0aGlz IHJlcXVpcmVtZW50IHNob3VsZCBiZSBjb25zaWRlcmVkCiAgICAgICAgb25seSBpbiB0ZXJtcyBv ZiB0b3RhbCBudW1iZXIgb2YgbWVzc2FnZXMgdGhhdCBtdXN0IGJlCiAgICAgICAgZXhjaGFuZ2Vk LCBhbmQgbGVzcyBmb3IgdGhlIGNvbXB1dGF0aW9uYWwgaW50ZW5zaXR5IG9mCiAgICAgICAgcHJv Y2Vzc2luZyBhbnkgb25lIG1lc3NhZ2UuCiAgIDE0LiAgVGhlIGNoYW5nZXMgb3IgYWRkaXRpb24g b2Ygc2VjdXJpdHkgbWVjaGFuaXNtcyBTSE9VTEQgTk9UIGNhdXNlCiAgICAgICAgYSByZWZyZXNo IG9mIHJvdXRlIHVwZGF0ZXMgb3IgY2F1c2UgYWRkaXRpb25hbCByb3V0ZSB1cGRhdGVzIHRvCiAg ICAgICAgYmUgZ2VuZXJhdGVkCiAgIDE1LiAgQXJjaGl0ZWN0dXJlIG9mIHRoZSBzcGVjaWZpY2F0 aW9uIE1VU1QgY29uc2lkZXIgYW5kIGFsbG93IGZvcgogICAgICAgIGZ1dHVyZSB1c2Ugb2YgYSBL TVAuCgo0LjMuICBDb21tb24gRnJhbWV3b3JrCgogICBFYWNoIG9mIHRoZSBjYXRlZ29yaWVzIG9m IHJvdXRpbmcgcHJvdG9jb2xzIGFib3ZlIHdpbGwgcmVxdWlyZSB1bmlxdWUKICAgZGVzaWducyBm b3IgYXV0aGVudGljYXRpbmcgYW5kIGludGVncml0eSBjaGVja2luZyB0aGVpciBwcm90b2NvbHMu CiAgIEhvd2V2ZXIsIGEgc2luZ2xlIHVuZGVybHlpbmcgZnJhbWV3b3JrIGZvciBkZWxpdmVyaW5n IGF1dG9tYXRpYwogICBrZXlpbmcgdG8gdGhvc2Ugc29sdXRpb25zIHdpbGwgYmUgcHVyc3VlZC4g IFByb3ZpZGluZyBzdWNoIGEgc2luZ2xlCiAgIGZyYW1ld29yayB3aWxsIHNpZ25pZmljYW50bHkg cmVkdWNlIHRoZSBjb21wbGV4aXR5IG9mIGVhY2ggc3RlcCBvZgogICB0aGUgb3ZlcmFsbCByb2Fk bWFwLiAgRm9yIGV4YW1wbGUsIGlmIGVhY2ggUm91dGluZyBQcm90b2NvbCBuZWVkZWQgdG8KICAg ZGVmaW5lIGl0J3Mgb3duIGtleSBtYW5hZ2VtZW50IHByb3RvY29sIHRoaXMgd291bGQgYmFsbG9v biB0aGUgdG90YWwKICAgYW1vdW50IG9mIGRpZmZlcmVudCBzb2NrZXRzIHRoYXQgYXJlIG5lZWRl ZCB0byBiZSBvcGVuZWQgYW5kCiAgIHByb2Nlc3NlcyB0aGF0IGFyZSBuZWVkZWQgdG8gYmUgc2lt dWx0YW5lb3VzbHkgcnVubmluZyBvbiBhbgogICBpbXBsZW1lbnRhdGlvbi4gIEl0IHdvdWxkIGFs c28gc2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUgcnVuLXRpbWUKICAgY29tcGxleGl0eSBhbmQg bWVtb3J5IHJlcXVpcmVtZW50cyBvZiBzdWNoIHN5c3RlbXMgcnVubmluZyBtdWx0aXBsZQogICBS b3V0aW5nIFByb3RvY29scywgY2F1c2luZyBwZXJoYXBzIHNsb3dlciBwZXJmb3JtYW5jZSBvZiBz dWNoCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAg ICAgICAgICAgICAgIFtQYWdlIDI1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtB UlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIHN5c3RlbXMuICBI b3dldmVyLCBpZiB3ZSBjYW4gbGFuZCBvbiBhIHZlcnkgc21hbGwgc2V0IChwZXJoYXBzIG9uZSBv cgogICB0d28pIG9mIGF1dG9tYXRpYyBrZXkgbWFuYWdlbWVudCBwcm90b2NvbHMsIEtNUHMsIHRo YXQgdGhlIHZhcmlvdXMKICAgUm91dGluZyBQcm90b2NvbHMgY2FuIHVzZSwgdGhlbiB3ZSBjYW4g cmVkdWNlIHRoaXMgaW1wbGVtZW50YXRpb24gYW5kCiAgIHJ1bi10aW1lIGNvbXBsZXhpdHkuICBX ZSBjYW4gYWxzbyBkZWNyZWFzZSB0aGUgdG90YWwgYW1vdW50IG9mIHRpbWUKICAgaW1wbGVtZW50 ZXJzIG5lZWQgdG8gZGVsaXZlciB0aGUgS01QcyBmb3IgdGhlIFJvdXRpbmcgUHJvdG9jb2xzIHRo YXQKICAgd2lsbCBwcm92aWRlIGJldHRlciB0aHJlYXQgcHJvdGVjdGlvbi4KCiAgIFRoZSBjb21w b25lbnRzIGZvciB0aGUgZnJhbWV3b3JrIGFyZSBsaXN0ZWQgaGVyZSwgYW5kIGRlc2NyaWJlZAog ICBiZWxvdzoKCiAgIG8gIFJvdXRpbmcgUHJvdG9jb2wgc2VjdXJpdHkgbWVjaGFuaXNtCiAgIG8g IEtNUAogICBvICBLZXlTdG9yZQogICBvICBUcmFmZmljIEtleQogICBvICBSb3V0aW5nUHJvdG9j b2wtdG8tS01QIEFQSQogICBvICBSb3V0aW5nUHJvdG9jb2wtdG8tS2V5U3RvcmUgQVBJCiAgIG8g IEtNUC10by1LZXlTdG9yZSBBUEkKICAgbyAgQ29tbW9uIFJvdXRpbmcgUHJvdG9jb2wgbWVjaGFu aXNtcwogICBvICBJZGVudGlmaWVycwogICBvICBQcm9vZiBvZiBpZGVudGl0eQogICBvICBQcm9m aWxlcwoKICAgVGhlIGZyYW1ld29yayBpcyBtb2R1bGFyaXplZCBmb3IgaG93IGtleXMgYW5kIHNl Y3VyaXR5IGFzc29jaWF0aW9uCiAgIChTQSkgcGFyYW1ldGVycyBnZW5lcmFsbHkgZ2V0IHBhc3Nl ZCBmcm9tIGEgS01QIHRvIGEgdHJhbnNwb3J0CiAgIHByb3RvY29sLiAgSXQgY29udGFpbnMgdGhy ZWUgbWFpbiBibG9ja3MgYW5kIEFQSXMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTGVib3Zp dHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAg W1BhZ2UgMjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAg ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKICAgICAgKy0tLS0tLS0tLS0tLSsgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgIHwgICAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAg ICAgICAgfCBDaGVjayAgICAgKy0tLS0tLS0tLS0tKwogICAgICB8IElkZW50aWZpZXIgKy0tPnwg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tPnwgICAgICAgICAgIHwKICAgICAgfCAgICAg ICAgICAgIHwgICB8ICAgIEtNUCBGdW5jdGlvbiAgICB8ICAgICAgICAgICB8ICBJZGVudGl0eSB8 CiAgICAgICstLS0tLS0tLS0tLSArICAgfCAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0t KyAgIFByb29mICAgfAogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg IHwgIEFwcHJvdmUgIHwgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICArLSstLS0t LS0tLS0tLS0tLSstLS0rICAgICAgICAgICArLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8CiAgICAgICAgIEtNUC10by1LZXlTdG9yZSB8ICAgICAg ICAgICAgICB8CiAgICAgICAgICAgIEFQSSAgICAgICAgICB8ICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgICAgICAgIFx8LyAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgKy0t LS0tLS0rLS0tLS0tLSsgICAgICB8CiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwg ICAgICB8IEtNUC10by1Sb3V0aW5nUHJvdG9jb2wKICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfCAgICAgIHwgIEFQSQogICAgICAgICAgICAgICAgIHwgICAgS2V5U3RvcmUgICB8ICAg ICAgfAogICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgfAogICAgICAgICAg ICAgICAgICstLS0tLS0tKy0tLS0tLS0rICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg fAogICAgICAgICAgIEtleVN0b3JlLXRvLSAgfCAgICAgICAgICAgICAgfAogICAgUm91dGluZ1By b3RvY29sIEFQSSAgfCAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICBcfC8KICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICAgICAgICAgICB8ICAgICAgICAgIFx8LyAgICAgICAgICBDb21tb24g UnRnUHJvdG8gIHwKICAgICAgICAgICAgIHwgICArLS0tLS0tLSstLS0tLS0tKyAgIEF1dGhlbnRp Y2F0aW9uICAgfAogICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8ICAgTWVjaGFuaXNt cyAgICAgICB8CiAgICAgICAgICAgICArLS0tfCAgVHJhZmZpYyAgICAgIHwtLS0tLSstLS0tLS0t LS0tLS0tLSsKICAgICAgICAgICAgIHwgICB8ICAgS2V5KHMpICAgICAgfCAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0tLSsgICBTcGVjaWZpYyAgICAg ICAgIHwKICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIFJvdXRpbmdQcm90b2Nv bCAgfAogICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24g ICB8CiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICBTZWN1cml0eSAgICAgICAg IHwKICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIE1lY2hhbmlzbSAgICAgICAg fAogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r CgoKICAgICAgICAgICAgICAgRmlndXJlIDE6IEF1dG9tYXRpYyBLZXkgTWFuYWdlbWVudCBGcmFt ZXdvcmsKCiAgIEVhY2ggZWxlbWVudCBvZiB0aGUgZnJhbWV3b3JrIGlzIGRlc2NyaWJlZCBoZXJl OgoKCiAgIG8gIFJvdXRpbmcgUHJvdG9jb2wgLSAgUm91dGluZyBwcm90b2NvbCBzZWN1cml0eSBt ZWNoYW5pc20gLSBJbiBlYWNoCiAgICAgICAgICAgY2FzZSwgdGhlIFJvdXRpbmcgUHJvdG9jb2wg d2lsbCBjb250YWluIGEgbWVjaGFuaXNtIGZvciB1c2luZwogICAgICAgICAgIHNlc3Npb24ga2V5 cyBpbiB0aGVpciBzZWN1cml0eSBvcHRpb24uICBXaGVuIHRoZSBSb3V0aW5nCiAgICAgICAgICAg UHJvdG9jb2wgdXNlcyBhIHRyYW5zcG9ydCBzdWJzdHJhdGUsIGUuZy4gdGhlIHdheSBCR1AsIExE UAogICAgICAgICAgIGFuZCBNU0RQIHVzZSBUQ1AsIHRoZW4gdGhpcyBhcHBsaWVzIHRvIHRoZSBz ZWN1cml0eSBtZWNoYW5pc20KCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBN YXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMjddCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoK ICAgICAgICAgICB0aGUgaW5jbHVkZXMgdGhhdCBzdWJzdHJhdGUuCgogICBvICBLZXlTdG9yZSAt ICAgRWFjaCBpbXBsZW1lbnRhdGlvbiB3aWxsIGFsc28gY29udGFpbiBhIHByb3RvY29sCiAgICAg ICAgICAgaW5kZXBlbmRlbnQgbWVjaGFuaXNtIGZvciBzdG9yaW5nIGtleXMsIGNhbGxlZCBLZXlT dG9yZS4gIFRoZQogICAgICAgICAgIEtleVN0b3JlIHdpbGwgaGF2ZSBtdWx0aXBsZSBkaWZmZXJl bnQgbG9naWNhbCBjb250YWluZXJzLCBvbmUKICAgICAgICAgICBjb250YWluZXIgZm9yIGVhY2gg c2Vzc2lvbiBrZXkgdGhhdCBhbnkgZ2l2ZW4gUm91dGluZwogICAgICAgICAgIFByb3RvY29sIHdp bGwgbmVlZC4gIEtleXMgc3RvcmVkIGhlcmUgbWF5IGJlIGEgUGVlciBLZXkgb3IgYQogICAgICAg ICAgIFRyYWZmaWMgS2V5LiBUaGVyZSBtYXkgYWxzbyBiZSBhc3NvY2lhdGVkIHBhcmFtZXRlcnMg YXMKICAgICAgICAgICByZXF1aXJlZCBieSB0aGUgU0EgZm9yIGFueSBnaXZlbiBSb3V0aW5nIFBy b3RvY29sLgoKICAgbyAgUGVlciBLZXkgIEEga2V5IHVzZWQgYmV0d2VlbiBwZWVycyBmcm9tIHdo aWNoIGEgdHJhZmZpYyBrZXkgaXMKICAgICAgICAgICBkZXJpdmVkLiAgQW4gZXhhbXBsZSBpcyBh IFBTSy4KCiAgIG8gIFRyYWZmaWMgS2V5ICBUaGUgYWN0dWFsIGtleSB1c2VkIG9uIGVhY2ggcGFj a2V0IG9mIGEgbWVzc2FnZS4KICAgICAgICAgICBUaGlzIGtleSBtYXkgYmUgZGVyaXZlZCBmcm9t IHRoZSBrZXkgZXhpc3RpbmcgaW4gdGhlCiAgICAgICAgICAgS2V5U3RvcmUuICBUaGlzIHdpbGwg ZGVwZW5kIG9uIHdoZXRoZXIgdGhlIGtleSBpbiBLZXlTdG9yZQogICAgICAgICAgIHdhcyBhIG1h bnVhbCBQU0sgZm9yIHRoZSBwZWVycywgb3Igd2hldGhlciBhIGNvbm5lY3Rpb24tYXdhcmUKICAg ICAgICAgICBLTVAgY3JlYXRlZCB0aGUga2V5LiAgRnVydGhlciwgaXQgd2lsbCBiZSBjb25uZWN0 aW9uCiAgICAgICAgICAgc3BlY2lmaWMsIHNvIGFzIHRvIHByb3ZpZGUgaW50ZXItIGFuZCBpbnRy YS1jb25uZWN0aW9uIHJlcGxheQogICAgICAgICAgIHByb3RlY3Rpb24uCgogICBvICBSb3V0aW5n UHJvdG9jb2wtS2V5U3RvcmUgQVBJIC0gICBUaGVyZSB3aWxsIGJlIGFuIEFQSSBmb3IgUm91dGlu ZwogICAgICAgICAgIFByb3RvY29sIHRvIHJldHJpZXZlIChvciByZWNlaXZlOyBpdCBjb3VsZCBi ZSBhIHB1c2ggb3IgYQogICAgICAgICAgIHB1bGwpIHRoZSBrZXlzIGZyb20gdGhlIEtleVN0b3Jl LiAgVGhpcyB3aWxsIGVuYWJsZQogICAgICAgICAgIGltcGxlbWVudGVycyB0byByZXVzZSB0aGUg c2FtZSBBUEkgY2FsbHMgZm9yIGFsbCB0aGVpcgogICAgICAgICAgIFJvdXRpbmcgUHJvdG9jb2xz LiAgVGhlIEFQSSB3aWxsIG5lY2Vzc2FyaWx5IGluY2x1ZGUgZmFjaWxpdHkKICAgICAgICAgICB0 byByZXRyaWV2ZSBvdGhlciBTQSBwYXJhbWV0ZXJzIHJlcXVpcmVkIGZvciB0aGUgY29uc3RydWN0 aW9uCiAgICAgICAgICAgb2YgdGhlIFJvdXRpbmcgUHJvdG9jb2wncyBwYWNrZXRzLCBsaWtlIGtl eSBJRHMgb3Iga2V5CiAgICAgICAgICAgbGlmZXRpbWVzLCBldGMuCgogICBvICBLTVAgLSAgIFRo ZXJlIHdpbGwgYmUgYW4gYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50IHByb3RvY29sLCBLTVAuCiAg ICAgICAgICAgVGhpcyBLTVAgd2lsbCBydW4gYmV0d2VlbiB0aGUgcGVlcnMuICBUaGUgS01QIHNl cnZlcyBhcyBhCiAgICAgICAgICAgcHJvdGVjdGVkIGNoYW5uZWwgYmV0d2VlbiB0aGUgcGVlcnMs IHRocm91Z2ggd2hpY2ggdGhleSBjYW4KICAgICAgICAgICBuZWdvdGlhdGUgYW5kIHBhc3MgaW1w b3J0YW50IGRhdGEgcmVxdWlyZWQgdG8gZXhjaGFuZ2UgcHJvb2YKICAgICAgICAgICBvZiBrZXkg aWRlbnRpZmllcnMsIGRlcml2ZSBzZXNzaW9uIGtleXMsIGRldGVybWluZSByZS1rZXlpbmcsCiAg ICAgICAgICAgc3luY2hyb25pemUgdGhlaXIga2V5aW5nIHN0YXRlLCBzaWduYWwgdmFyaW91cyBr ZXlpbmcgZXZlbnRzLAogICAgICAgICAgIG5vdGlmeSB3aXRoIGVycm9yIG1lc3NhZ2VzLCBldGMu ICBBcyBhbiBhbmFsb2d5LCBpbiB0aGUgSVBzZWMKICAgICAgICAgICBwcm90b2NvbCAoUkZDNDMw MSBbUkZDNDMwMV0sIFJGQzQzMDMgW1JGQzQzMDNdIGFuZCBSRkM0MzA2CiAgICAgICAgICAgW1JG QzQzMDZdKSBJS0V2MiBpcyB0aGUgS01QIHRoYXQgcnVucyBiZXR3ZWVuIHRoZSB0d28gcGVlcnMs CiAgICAgICAgICAgd2hpbGUgQUggYW5kIEVTUCBhcmUgdHdvIGRpZmZlcmVudCBiYXNlIHByb3Rv Y29scyB0aGF0IHRha2UKICAgICAgICAgICBzZXNzaW9uIGtleXMgZnJvbSBJS0V2MiBhbmQgdXNl IHRoZW0gaW4gdGhlaXIgdHJhbnNtaXNzaW9ucy4KICAgICAgICAgICBJbiB0aGUgYW5hbG9neSwg dGhlIFJvdXRpbmcgUHJvdG9jb2wsIHNheSBCR1AgYW5kIExEUCwgYXJlCiAgICAgICAgICAgYW5h bG9nb3VzIHRvIEVTUCBhbmQgQUgsIHdoaWxlIHRoZSBLTVAgaXMgYW5hbG9nb3VzIHRvIElLRXYy CiAgICAgICAgICAgaXRzZWxmLgoKCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhw aXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAy MDA5CgoKCiAgIG8gIFJvdXRpbmdQcm90b2NvbC1LTVAgQVBJIC0gICBUaGVyZSB3aWxsIGJlIGFu IEFQSSBmb3IgdGhlIFJvdXRpbmcKICAgICAgICAgICBQcm90b2NvbCB0byByZXF1ZXN0IGEgc2Vz c2lvbiBrZXkgb2YgdGhlIEtNUCwgYW5kIGJlIG5vdGlmaWVkCiAgICAgICAgICAgd2hlbiB0aGUg a2V5cyBhcmUgYXZhaWxhYmxlIGZvciBpdC4gIFRoZSBBUEkgd2lsbCBhbHNvCiAgICAgICAgICAg Y29udGFpbiBhIG1lY2hhbmlzbSBmb3IgdGhlIEtNUCB0byBub3RpZnkgdGhlIFJvdXRpbmcKICAg ICAgICAgICBQcm90b2NvbCB0aGF0IHRoZXJlIGFyZSBuZXcga2V5cyB0aGF0IGl0IG11c3Qgbm93 IHVzZSwgZXZlbgogICAgICAgICAgIGlmIGl0IGRpZG4ndCByZXF1ZXN0IHRob3NlIGtleXMuICBU aGUgQVBJIHdpbGwgYWxzbyBpbmNsdWRlIGEKICAgICAgICAgICBtZWNoYW5pc20gZm9yIHRoZSBL TVAgdG8gcmVjZWl2ZSByZXF1ZXN0cyBmb3Igc2Vzc2lvbiBrZXlzCiAgICAgICAgICAgYW5kIG90 aGVyIHBhcmFtZXRlcnMgZnJvbSB0aGUgcm91dGluZyBwcm90b2NvbC4gIFRoZSBLTVAgd2lsbAog ICAgICAgICAgIGFsc28gYmUgYXdhcmUgb2YgdGhlIHZhcmlvdXMgUm91dGluZyBQcm90b2NvbHMg YW5kIGVhY2ggb2YKICAgICAgICAgICB0aGVpciB1bmlxdWUgcGFyYW1ldGVycyB0aGF0IG5lZWQg dG8gYmUgbmVnb3RpYXRlZCBhbmQKICAgICAgICAgICByZXR1cm5lZC4KCiAgIG8gIEtNUC1LZXlT dG9yZSBBUEkgLSAgIFRoZXJlIHdpbGwgYmUgYW4gQVBJIGZvciB0aGUgS01QIHRvIHBsYWNlCiAg ICAgICAgICAga2V5cyBhbmQgcGFyYW1ldGVycyBpbnRvIHRoZSBLZXlTdG9yZSBhZnRlciB0aGVp ciBuZWdvdGlhdGlvbgogICAgICAgICAgIGFuZCBkZXJpdmF0aW9uIHdpdGggdGhlIG90aGVyIHBl ZXIuICBUaGlzIHdpbGwgZW5hYmxlIHRoZQogICAgICAgICAgIGltcGxlbWVudGVycyB0byByZXVz ZSB0aGUgc2FtZSBjYWxscyBmb3IgbXVsdGlwbGUgS01QcyB0aGF0CiAgICAgICAgICAgbWF5IGJl IG5lZWRlZCB0byBhZGRyZXNzIHRoZSB2YXJpb3VzIGNhdGVnb3JpZXMgb2YgUm91dGluZwogICAg ICAgICAgIFByb3RvY29scyBhcyBkZXNjcmliZWQgaW4gdGhlIHNlY3Rpb24gZGVmaW5pbmdjYXRl Z29yaWVzCiAgICAgICAgICAgKFNlY3Rpb24gMykuCgoKICAgW2FmdGVyIHdyaXRpbmcgdGhpcyBh bGwgdXAsIEknbSBub3Qgc3VyZSB3ZSByZWFsbHkgbmVlZCB0aGUga2V5X3N0b3JlCiAgIGluIHRo ZSBtaWRkbGUuICBBcyBsb25nIGFzIHdlIHN0YW5kYXJkaXplIGZ1bGx5IGFsbCB0aGUgY2FsbHMg bmVlZGVkCiAgIGZyb20gYW55IFJvdXRpbmcgUHJvdG9jb2wgdG8gYW55IEtNUCwgdGhlbiB0aGVy ZSBjYW4gYmUgYSBnZW5lcmljCiAgIGhhbmQtZG93biBmdW5jdGlvbiBmcm9tIHRoZSBLTVAgdG8g dGhlIFJvdXRpbmcgUHJvdG9jb2wgd2hlbiB0aGUga2V5CiAgIGFuZCBwYXJhbWV0ZXJzIGFyZSBy ZWFkeS4gIExldCdzIHNsZWVwIG9uIGl0Ll0KCiAgIFt3aWxsIG5lZWQgc3RhdGUgbWFjaGluZXMg YW5kIGZ1bmN0aW9uIGNhbGxzIGZvciB0aGVzZSBBUElzLCBhcyBvbmUKICAgb2YgdGhlIHdvcmsg aXRlbXMuICBJbiBlc3NlbmNlLCB0aGVyZSBpcyBhIG5lZWQgZm9yIGEgY29yZSB0ZWFtIHRvCiAg IGRldmVsb3AgdGhlIEFQSXMgb3V0IGNvbXBsZXRlbHkgaW4gb3JkZXIgZm9yIHRoZSBSb3V0aW5n IFByb3RvY29sCiAgIHRlYW1zIHRvIHVzZSB0aGVtLiAgTmVlZCB0byBnZXQgdGhpcyB0ZWFtIGdv aW5nIGFzYXAuXQoKCiAgIG8gSWRlbnRpZmllcnMgLSAgIEEgS01QIGlzIGZlZCBieSBpZGVudGl0 aWVzLiAgVGhlIGlkZW50aXRpZXMgYXJlCiAgICAgICAgICAgdGV4dCBzdHJpbmdzIHVzZWQgYnkg dGhlIHBlZXJzIHRvIGluZGljYXRlIHRvIGVhY2ggb3RoZXIgdGhhdAogICAgICAgICAgIGVhY2gg YXJlIGtub3duIHRvIHRoZSBvdGhlciwgYW5kIGF1dGhvcml6ZWQgdG8gZXN0YWJsaXNoCiAgICAg ICAgICAgY29ubmVjdGlvbnMuICBUaG9zZSBpZGVudGl0aWVzIG11c3QgYmUgcmVwcmVzZW50ZWQg aW4gc29tZQogICAgICAgICAgIHN0YW5kYXJkIHN0cmluZyBmb3JtYXQsIGUuZy4gYW4gSVAgYWRk cmVzcyAtLSBlaXRoZXIgdjQgb3IKICAgICAgICAgICB2NiwgYW4gRlFETiwgYW4gUkZDIDgyMiBl bWFpbCBhZGRyZXNzLCBhIENvbW1vbiBOYW1lIFtSRkMKICAgICAgICAgICBQS0ldLCBldGMuICBO b3RlIHRoYXQgZXZlbiB0aG91Z2ggcm91dGVycyBkbyBub3Qgbm9ybWFsbHkKICAgICAgICAgICBo YXZlIGVtYWlsIGFkZHJlc3Nlcywgb25lIGNvdWxkIHVzZSBhbiBSRkMgODIyIGVtYWlsIGFkZHJl c3MKICAgICAgICAgICBzdHJpbmcgYXMgYSBmb3JtYXR0ZWQgaWRlbnRpZmllciBmb3IgYSByb3V0 ZXIuICBUaGV5IHdvdWxkIGRvCiAgICAgICAgICAgc28gc2ltcGx5IGJ5IHB1dHRpbmcgdGhlIHJv dXRlcidzIHJlZmVyZW5jZSBudW1iZXIgb3IgbmFtZS0KICAgICAgICAgICBjb2RlIGFzIHRoZSAi TkFNRSIgcGFydCBvZiB0aGUgYWRkcmVzcywgbGVmdCBvZiB0aGUgIkAiCiAgICAgICAgICAgc3lt Ym9sLiAgVGhleSB3b3VsZCB0aGVuIHBsYWNlIHNvbWUgbG9jYXRpb25hbCBjb250ZXh0IGluIHRo ZQogICAgICAgICAgICJET01BSU4iIHBhcnQgb2YgdGhlIHN0cmluZywgcmlnaHQgb2YgdGhlICJA IiBzeW1ib2wuICBBbgogICAgICAgICAgIGV4YW1wbGUgd291bGQgYmUgInJ0cjAyMTBAc2YuY2Eu dXMuY29tcGFueS5jb20iLiAgVGhpcwoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBp cmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAyOV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIw MDkKCgogICAgICAgICAgIGRvY3VtZW50IGRvZXMgbm90IHN1Z2dlc3QgdGhpcyBzdHJpbmcgdmFs dWUgYXQgYWxsLiAgSW5zdGVhZCwKICAgICAgICAgICB0aGUgY29uY2VwdCBpcyB1c2VkIG9ubHkg dG8gY2xhcmlmeSB0aGF0IHRoZSB0eXBlIG9mIHN0cmluZwogICAgICAgICAgIGVtcGxveWVkIGRv ZXMgbm90IG1hdHRlci4gIEl0IGFsc28gZG9lcyBub3QgbWF0dGVyIHdoYXQKICAgICAgICAgICBz cGVjaWZpYyB0ZXh0IHlvdSBjaG9zZSB0byBwbGFjZSBpbiB0aGF0IHN0cmluZyB0eXBlLiAgSXQK ICAgICAgICAgICBvbmx5IG1hdHRlcnMgdGhhdCB0aGUgdHlwZSBvZiBzdHJpbmcgLS0gYW5kIGl0 J3MgZm9ybWF0IC0tCiAgICAgICAgICAgbXVzdCBiZSBhZ3JlZWQgdXBvbiBieSB0aGUgdHdvIGVu ZHBvaW50cy4gIEZ1cnRoZXIsIHRoZQogICAgICAgICAgIHN0cmluZyBjYW4gYmUgdXNlZCBhcyBh biBpZGVudGlmaWVyIGluIHRoaXMgY29udGV4dCwgZXZlbiBpZgogICAgICAgICAgIHRoZSBzdHJp bmcgaXMgbm90IGFjdHVhbGx5IHByb3Zpc2lvbmVkIGluIGl0J3Mgc291cmNlIGRvbWFpbi4KICAg ICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGVtYWlsIGFkZHJlc3MgInJ0cjAyMTBAc2YuY2EudXMu Y29tcGFueS5jb20iCiAgICAgICAgICAgbWF5IG5vdCBhY3R1YWxseSBleGlzdCBhcyBhbiBlbWFp bCBhZGRyZXNzIGluIHRoYXQgZG9tYWluLAogICAgICAgICAgIGJ1dCB0aGF0IHN0cmluZyBvZiBj aGFyYWN0ZXJzIG1heSBzdGlsbCBiZSB1c2VkIGFzIGFuCiAgICAgICAgICAgaWRlbnRpZmllciB0 eXBlKHMpIGluIHRoZSByb3V0aW5nIHByb3RvY29sIHNlY3VyaXR5IGNvbnRleHQuCiAgICAgICAg ICAgV2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhhdCB0aGUgY29tbXVuaXR5IGRlY2lkZSBvbiBhIHNt YWxsIGJ1dAogICAgICAgICAgIGZsZXhpYmxlIHNldCBvZiBJZGVudGlmaWVycyB0aGV5IHdpbGwg YWxsIHN1cHBvcnQsIGFuZCB0aGF0CiAgICAgICAgICAgdGhleSBkZWNpZGUgb24gdGhlIGV4YWN0 IGZvcm1hdCBvZiB0aG9zZSBzdHJpbmcuICBUaGUgZm9ybWF0cwogICAgICAgICAgIHRoYXQgd2ls bCBiZSB1c2VkIG11c3QgYmUgc3RhbmRhcmRpemVkIGFuZCBtdXN0IGJlIHNlbnNpYmxlCiAgICAg ICAgICAgZm9yIHRoZSByb3V0aW5nIGluZnJhc3RydWN0dXJlLgoKICAgbyAgSWRlbnRpdHkgUHJv b2YgLSAgIE9uY2UgdGhlIGZvcm0gb2YgaWRlbnRpdHkgaXMgZGVjaWRlZCwgdGhlbgogICAgICAg ICAgIHRoZXJlIG11c3QgYmUgYSBjcnlwdG9ncmFwaGljIHByb29mIG9mIHRoYXQgaWRlbnRpdHks IHRoYXQKICAgICAgICAgICB0aGUgcGVlciByZWFsbHkgaXMgd2hvIHRoZXkgYXNzZXJ0IHRoZW1z ZWx2ZXMgdG8gYmUuICBQcm9vZgogICAgICAgICAgIG9mIGlkZW50aXR5IGNhbiBiZSBhcnJhbmdl ZCBiZXR3ZWVuIHRoZSBwZWVycyBpbiBhIGZldyB3YXlzLAogICAgICAgICAgIGZvciBleGFtcGxl IHByZS1zaGFyZWQga2V5cywgcmF3IGFzc3ltZXRyaWMga2V5cywgb3IgYSBtb3JlCiAgICAgICAg ICAgdXNlci1mcmllbmRseSByZXByZXNlbnRhdGlvbiBvZiBhc3N5bWV0cmljIGtleXMsIGxpa2Ug YQogICAgICAgICAgIGNlcnRpZmljYXRlLiAgQ2VydGlmaWNhdGVzIGNhbiBiZSB1c2VkIGluIGEg d2F5IHJlcXVpcmluZyBubwogICAgICAgICAgIGFkZGl0aW9uYWwgc3VwcG9ydGluZyBzeXN0ZW1z IC0tIGUuZy4gcHVibGljIGtleXMgZm9yIGVhY2gKICAgICAgICAgICBwZWVyIGNhbiBiZSBtYWlu dGFpbmVkIGxvY2FsbHkgZm9yIHZlcmlmaWNhdGlvbiB1cG9uIGNvbnRhY3QuCiAgICAgICAgICAg Q2VydGlmaWNhdGUgbWFuYWdlbWVudCBjYW4gYmUgbWFkZSBtb3JlIHNpbXBsZSBhbmQgc2NhbGFi bGUKICAgICAgICAgICB3aXRoIHRoZSB1c2UgbWlub3IgYWRkaXRpb25hbCBzdXBwb3J0aW5nIHN5 c3RlbXMsIGFzIGlzIHRoZQogICAgICAgICAgIGNhc2Ugd2l0aCBzZWxmLXNpZ25lZCBjZXJ0aWZp Y2F0ZXMgYW5kIGEgZmxhdCBmaWxlIGxpc3Qgb2YKICAgICAgICAgICAiYXBwcm92ZWQgdGh1bWJw cmludHMiLiAgU2VsZi1zaWduZWQgY2VydGlmaWNhdGVzIHdpbGwgaGF2ZQogICAgICAgICAgIHNv bWV3aGF0IGxvd2VyIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhbiBDZXJ0aWZpY2F0ZSBBdXRob3Jp dHkKICAgICAgICAgICBzaWduZWQgY2VydGlmaWNhdGVzIFtSRkMgQ2VydHNdLiAgVGhlIHVzZSBv ZiB0aGVzZSBkaWZmZXJlbnQKICAgICAgICAgICBpZGVudGl0eSBwcm9vZnMgdmFyeSBpbiBlYXNl IG9mIGRlcGxveW1lbnQsIGVhc2Ugb2Ygb25nb2luZwogICAgICAgICAgIG1hbmFnZW1lbnQsIHN0 YXJ0dXAgZWZmb3J0LCBvbmdvaW5nIGVmZm9ydCBhbmQgbWFuYWdlbWVudCwKICAgICAgICAgICBz ZWN1cml0eSBzdHJlbmd0aCwgYW5kIGNvbnNlcXVlbmNlcyBmcm9tIGxvc3Mgb2Ygc2VjcmV0cyBm cm9tCiAgICAgICAgICAgb25lIHBhcnQgb2YgdGhlIHN5c3RlbSB0byB0aGUgcmVzdCBvZiB0aGUg c3lzdGVtLiAgRm9yCiAgICAgICAgICAgZXhhbXBsZSwgdGhleSBkaWZmZXIgaW4gcmVzaXN0YW5j ZSB0byBhIHNlY3VyaXR5IGJyZWFjaCwgYW5kCiAgICAgICAgICAgdGhlIGVmZm9ydCByZXF1aXJl ZCB0byByZW1lZGlhdGUgdGhlIHdob2xlIHN5c3RlbSBpbiB0aGUKICAgICAgICAgICBldmVudCBv ZiBzdWNoIGEgYnJlYWNoLiAgVGhlIHBvaW50IGhlcmUgaXMgdGhhdCB0aGVyZSBhcmUKICAgICAg ICAgICBvcHRpb25zLCBtYW55IG9mIHdoaWNoIGFyZSBxdWl0ZSBzaW1wbGUgdG8gZW1wbG95IGFu ZCBkZXBsb3kuCgogICBvICBQcm9maWxlcyAtICAgT25jZSB0aGUgS01QLCBJZGVudGlmaWVycyBh bmQgUHJvb2ZzIG1lY2hhbmlzbXMgYXJlCiAgICAgICAgICAgY29udmVyZ2VkIHVwb24sIHRoZXkg bXVzdCBiZSBjbGVhcmx5IHByb2ZpbGVkIGZvciBlYWNoCiAgICAgICAgICAgUm91dGluZyBQcm90 b2NvbCwgc28gdGhhdCBpbXBsZW1lbnRvcnMgYW5kIGRlcGxveWVycyBhbGlrZQogICAgICAgICAg IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCBwaWVjZXMgb2YgdGhlIHNvbHV0aW9uLCBhbmQgY2Fu IGhhdmUKICAgICAgICAgICBzaW1pbGFyIGNvbmZpZ3VyYXRpb25zIGFuZCBpbnRlcm9wZXJhYmls aXR5IGFjcm9zcyBtdWx0aXBsZQogICAgICAgICAgIHZlbmRvcnMnIGRldmljZXMsIHNvIGFzIHRv IHJlZHVjZSBtYW5hZ2VtZW50IGRpZmZpY3VsdHkuICBUaGUKCgoKTGVib3ZpdHogJiAgICAgICAg ICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMzBdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAg ICBOb3ZlbWJlciAyMDA5CgoKICAgICAgICAgICBwcm9maWxlcyBTSE9VTEQgYWxzbyBwcm92aWRl IGd1aWRhbmNlIG9uIHdoZW4gdG8gdXNlIHdoaWNoCiAgICAgICAgICAgdmFyaW91cyBjb21iaW5h dGlvbnMgb2Ygb3B0aW9ucy4gIFRoaXMgd2lsbCwgYWdhaW4sIHNpbXBsaWZ5CiAgICAgICAgICAg dXNlIGFuZCBpbnRlcm9wZXJhYmlsaXR5LgoKICAgSW4gYWRkaXRpb24gdG8gb3RoZXIgYnVzaW5l c3MsIGFkbWluaXN0cmF0aXZlLCBhbmQgb3BlcmF0aW9uYWwgdGVybXMKICAgdGhleSBtdXN0IGFs cmVhZHkgZXhjaGFuZ2UgcHJpb3IgdG8gZm9ybWluZyBmaXJzdCBhZGphY2VuY2llcywgaXQgaXMK ICAgYXNzdW1lZCB0aGF0IHR3byBwYXJ0aWVzIGRlcGxveWluZyBtZXNzYWdlIGF1dGhlbnRpY2F0 aW9uIG9uIHRoZWlyCiAgIHJvdXRpbmcgcHJvdG9jb2wgd2lsbCBhbHNvIG5lZWQgdG8gZGVjaWRl IHVwb24gYWNjZXB0YWJsZSBzZWN1cml0eQogICBwYXJhbWV0ZXJzIGZvciB0aGUgY29ubmVjdGlv bi4gIFRoaXMgd2lsbCBpbmNsdWRlIHRoZSBmb3JtIGFuZAogICBjb250ZW50IG9mIHRoZSBpZGVu dGl0eSBlYWNoIHVzZSB0byByZXByZXNlbnQgdGhlIG90aGVyLiAgSXQgd2lsbAogICBhbHNvIGlu Y2x1ZGUgdGhlIHR5cGUgb2Yga2V5cyB0byBiZSB1c2VkLCBlLmcuICBQU0ssIHJhdyBhc3N5bWV0 cmljCiAgIGtleXMsIGNlcnRpZmljYXRlLiAgQW5kIGl0IHdpbGwgaW5jbHVkZSB0aGUgYWNjZXB0 YWJsZSBjcnlwdG9ncmFwaGljCiAgIGFsZ29yaXRobXMsIG9yIGFsZ29yaXRobSBzdWl0ZS4gIFRo aXMgYWdyZWVtZW50IGlzIG5lY2Vzc2FyeSBpbiBvcmRlcgogICBmb3IgZWFjaCB0byBwcm9wZXJs eSBjb25maWd1cmUgdGhlIGNvbm5lY3Rpb24gb24gdGhlaXIgcmVzcGVjdGl2ZQogICBkZXZpY2Vz LiAgVGhlIG1hbm5lciBpbiB3aGljaCB0aGV5IGFncmVlIHVwb24gYW5kIGV4Y2hhbmdlIHRoaXMK ICAgcG9saWN5IGluZm9ybWF0aW9uIGlzIG5vcm1hbGx5IHZpYSBwaG9uZSBjYWxsIG9yIHdyaXR0 ZW4gZXhjaGFuZ2UsCiAgIGFuZCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgS0FSUCBlZmZv cnQsIGJ1dCBhc3N1bWVkIHRvIGhhdmUKICAgb2NjdXJlZC4gIFdlIHRha2UgYXMgYSBnaXZlbiB0 aGF0IGVhY2ggcGFydHkga25vd3MgdGhlIGlkZW50aXR5IHR5cGVzCiAgIGFuZCB2YWx1ZXMsIGtl eSB0eXBlcyBhbmQgdmFsdWVzLCBhbmQgYWNjZXB0YWJsZSBjcnlwdG9ncmFwaGljCiAgIGFsZ29y aXRobXMgZm9yIGJvdGggdGhlaXIgb3duIGRldmljZSBhbmQgdGhlIHBlZXIgdGhhdCBmb3JtIHRo ZQogICBzZWN1cml0eSBwb2xpY3kgZm9yIGNvbmZpZ3VyYXRpb24gb24gdGhlaXIgZGV2aWNlLgoK ICAgQ29tbW9uIE1lY2hhbmlzbXMgLSBJbiBhcyBtdWNoIGFzIHRoZXkgZXhpc3QsIHRoZSBmcmFt ZXdvcmsgd2lsbAogICBjYXB0dXJlIG1lY2hhbmlzbXMgdGhhdCBjYW4gYmUgdXNlZCBjb21tb25s eSBub3Qgb25seSB3aXRoaW4gYQogICBwYXJ0aWN1bGFyIGNhdGVnb3J5IG9mIFJvdXRpbmcgUHJv dG9jb2wgYW5kIFJvdXRpbmcgUHJvdG9jb2wgdG8gS01QLAogICBidXQgYWxzbyBiZXR3ZWVuIFJv dXRpbmcgUHJvdG9jb2wgY2F0ZWdvcmllcy4gIEFnYWluLCB0aGUgZ29hbCBoZXJlCiAgIGlzIHNp bXBsaWZ5aW5nIHRoZSBpbXBsZW1lbnRhdGlvbnMgYW5kIHJ1bnRpbWUgY29kZSBhbmQgcmVzb3Vy Y2UKICAgcmVxdWlyZW1lbnRzLiAgVGhlcmUgaXMgYWxzbyBhIGdvYWwgaGVyZSBvZiBmYXZvcmlu ZyB3ZWxsIHZldHRlZCwKICAgcmV2aWV3ZWQsIG9wZXJhdGlvbmFsbHkgcHJvdmVuIHNlY3VyaXR5 IG1lY2hhbmlzbXMgb3ZlciBuZXdseSBicmV3ZWQKICAgbWVjaGFuaXNtcyB0aGF0IGFyZSBsZXNz IHdlbGwgdHJpZWQgaW4gdGhlIHdpbGQuCgo0LjQuICBXb3JrIEl0ZW1zIFBlciBSb3V0aW5nIFBy b3RvY29sCgogICBFYWNoIFJvdXRpbmcgUHJvdG9jb2wgd2lsbCBoYXZlIGEgdGVhbSAodGhlIFtS b3V0aW5nX1Byb3RvY29sXS1LQVJQCiAgIHRlYW0pIHdvcmtpbmcgb24gaW5jcmVtZW50YWxseSBp bXByb3ZpbmcgdGhlaXIgUm91dGluZyBQcm90b2NvbCdzCiAgIHNlY3VyaXR5LCBUaGVzZSB0ZWFt cyB3aWxsIGhhdmUgdGhlIGZvbGxvd2luZyBtYWluIHdvcmsgaXRlbXM6CgogICBQSEFTRSAxOgoK ICAgQ2hhcmFjdGVyaXplIHRoZSBSUAogICAgICBBc3Nlc3MgdGhlIFJvdXRpbmcgUHJvdG9jb2wg dG8gc2VlIHdoYXQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcwogICAgICBpdCBoYXMgdG9kYXku ICBEb2VzIGl0IG5lZWRzIHNpZ25pZmljYW50IGltcHJvdmVtZW50IHRvIGl0cwogICAgICBleGlz dGluZyBtZWNoYW5pc21zIG9yIG5vdD8gIFRoaXMgd2lsbCBpbmNsdWRlIGRldGVybWluaW5nIGlm CiAgICAgIG1vZGVybiwgc3Ryb25nIHNlY3VyaXR5IGFsZ29yaXRobXMgYW5kIHBhcmFtZXRlcnMg YXJlIHByZXNlbnQuCgoKCgoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1h eSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgoK ICAgRGVmaW5lIE9wdGltYWwgU3RhdGUKICAgICAgTGlzdCB0aGUgcmVxdWlyZW1lbnRzIGZvciB0 aGUgUm91dGluZyBQcm90b2NvbCdzIHNlc3Npb24ga2V5IHVzYWdlCiAgICAgIGFuZCBmb3JtYXQg dG8gY29udGFpbiB0byBtb2Rlcm4sIHN0cm9uZyBzZWN1cml0eSBhbGdvcml0aG1zIGFuZAogICAg ICBtZWNoYW5pc21zLCBwZXIgdGhlIFJlcXVpcmVtZW50cyAoU2VjdGlvbiA0LjIpIHNlY3Rpb24g YWJvdmUuICBUaGUKICAgICAgZ29hbCBoZXJlIGlzIHRvIGRldGVybWluZSB3aGF0IGlzIG5lZWRl ZCBmb3IgdGhleSBSb3V0aW5nIFByb3RvY29sCiAgICAgIGFsb25lIHRvIGJlIHVzZWQgc2VjdXJl bHkgd2l0aCBhdCBsZWFzdCBtYW51YWwga2V5cy4KCiAgIEdhcCBBbmFseXNpcwogICAgICBFbnVt ZXJhdGUgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBtb3ZlIGZyb20gaXRz CiAgICAgIGN1cnJlbnQgc2VjdXJpdHkgc3RhdGUsIHRoZSBmaXJzdCBidWxsZXQsIHRvIGl0cyBv cHRpbWFsIHN0YXRlLCBhcwogICAgICBsaXN0ZWQganVzdCBhYm92ZS4KCiAgIFRyYW5zaXRpb24g YW5kIERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMgIERvY3VtZW50IHRoZSBvcGVyYXRpb25hbAog ICAgICB0cmFuc2l0aW9uIHBsYW4gZm9yIG1vdmluZyBmcm9tIHRoZSBvbGQgdG8gdGhlIG5ldyBz ZWN1cml0eQogICAgICBtZWNoYW5pc20uICBXaWxsIGFkamFjZW5jaWVzIG5lZWQgdG8gYm91bmNl PyAgV2hhdCBuZXcgZWxlbWVudHMvCiAgICAgIHNlcnZlcnMvc2VydmljZXMgaW4gdGhlIGluZnJh c3RydWN0dXJlIHdpbGwgYmUgcmVxdWlyZWQ/ICBXaGF0IGlzCiAgICAgIGFuIGV4YW1wbGUgd29y ayBmbG93IHRoYXQgYW4gb3BlcmF0b3Igd2lsbCB0YWtlPyAgVGhlIGJlc3QKICAgICAgcG9zc2li bGUgY2FzZSBpcyBpZiB0aGUgYWRqYWNlbmN5IGRvZXMgbm90IGJyZWFrLCBidXQgdGhpcyBtYXkg bm90CiAgICAgIGFsd2F5cyBiZSBwb3NzaWJsZS4KCiAgIERlZmluZSwgQXNzaWduLCBEZXNpZ24K ICAgICAgQ3JlYXRlIGEgZGVsaXZlcmFibGVzIGxpc3Qgb2YgdGhlIGRlc2lnbiBhbmQgc3BlY2lm aWNhdGlvbiB3b3JrLAogICAgICB3aXRoIG1pbGVzdG9uZXMuICBEZWZpbmUgb3duZXJzLiAgUmVs ZWFzZSBhIGRvY3VtZW50KHMpCgoKICAgUEhBU0UgMjoKCiAgIEtNUCBBbmFseXNpcwogICAgICBS ZXZpZXcgcmVxdWlyZW1lbnRzIGZvciBLTVBzIFtSRkM/Pz8/XS4gIElkZW50aWZ5IGFueSBudWFu Y2VzIGZvcgogICAgICB0aGlzIHBhcnRpY3VsYXIgcHJvdG9jb2wncyBuZWVkcyBhbmQgaXRzIHVz ZSBjYXNlcyBmb3IgS01QLiAgTGlzdAogICAgICB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgdGhpcyBS b3V0aW5nIFByb3RvY29sIGhhcyBmb3IgYmVpbmcgYWJsZSB0bwogICAgICBiZSB1c2UgaW4gY29u anVuY3Rpb25zIHdpdGggYSBLTVAuICBEZWZpbmUgdGhlIG9wdGltYWwgc3RhdGUuCgogICBHYXAg QW5hbHlzaXMKICAgICAgRW51bWVyYXRlIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoaXMgcHJvdG9j b2wgdG8gbW92ZSBmcm9tIGl0cwogICAgICBjdXJyZW50IHNlY3VyaXR5IHN0YXRlIHRvIGl0cyBv cHRpbWFsIHN0YXRlLgoKICAgRGVmaW5lLCBBc3NpZ24sIERlc2lnbgogICAgICBDcmVhdGUgYSBk ZWxpdmVyYWJlbHMgbGlzdCBvZiB0aGUgZGVzaWduIGFuZCBzcGVjaWZpY2F0aW9uIHdvcmssCiAg ICAgIHdpdGggbWlsZXRzb25lcy4gIERlZmluZSBvd25lcnMuICBEbyB0aGUgZGVzaWduIGFuZCBk b2N1bWVudCB3b3JrCiAgICAgIGZvciBhIEtNUCB0byBiZSBhYmxlIHRvIGdlbmVyYXRlIHRoZSBS b3V0aW5nIFByb3RvY29sJ3Mgc2Vzc2lvbgogICAgICBrZXlzIGZvciB0aGUgcGFja2V0cyBvbiB0 aGUgd2lyZS4gIFRoZXNlIHdpbGwgYmUgdGhlIGFyZ3VtZW50cwogICAgICBwYXNzZWQgaW4gdGhl IEFQSSB0byB0aGUgS01QIGluIG9yZGVyIHRvIGJvb3RzdHJhcCB0aGUgc2Vzc2lvbgogICAgICBr ZXlzIHRvIHRoZSBSb3V0aW5nIFByb3RvY29sLgoKICAgVGhlcmUgd2lsbCBhbHNvIGJlIGEgdGVh bSBmb3JtZWQgdG8gd29yayBvbiB0aGUgYmFzZSBmcmFtZXdvcmsKICAgbWVjaGFuaXNtcyBmb3Ig ZWFjaCBvZiB0aGUgbWFpbiBjYXRlZ29yaWVzLCBpLmUuIHRoZSBibG9ja3MgYW5kIEFQSSdzCgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDMyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9h ZG1hcCAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIHJlcHJlc2VudGVkIGluIGZp Z3VyZSAxIChGaWd1cmUgMSkuCgo0LjUuICBQcm90b2NvbHMgaW4gQ2F0ZWdvcmllcwoKICAgVGhp cyBzZWN0aW9uIGdyb3VwcyB0aGUgUm91dGluZyBQcm90b2NvbHMgaW50byBsaWtlIGNhdGVnb3Jp ZXMsCiAgIGFjY29yZGluZyB0byBhdHRyaWJ1dGVzIHNldCBmb3J0aCBpbiBDYXRlZ29yaWVzIFNl Y3Rpb24gKFNlY3Rpb24gMykuCiAgIEVhY2ggZ3JvdXAgd2lsbCBoYXZlIGEgZGVzaWduIHRlYW0g dGFza2VkIHdpdGggaW1wcm92aW5nIHRoZSBzZWN1cml0eQogICBvZiB0aGUgUm91dGluZyBQcm90 b2NvbCBtZWNoYW5pc21zIGFuZCBkZWZpbmluZyB0aGUgS01QIHJlcXVpcmVtZW50cwogICBmb3Ig dGhlaXIgZ3JvdXAsIHRoZW4gcm9sbGluZyBib3RoIGludG8gYSByb2FkbWFwIGRvY3VtZW50IHVw b24gd2hpY2gKICAgdGhleSB3aWxsIGV4ZWN1dGUuCgogICBCR1AsIExEUCBhbmQgTVNEUAogICAg ICAgVGhlIFJvdXRpbmcgUHJvdG9jb2wncyB0aGF0IGZhbGwgaW50byB0aGUgY2F0ZWdvcnkgb2Yg dGhlIG9uZS10by0KICAgICAgIG9uZSBwZWVyaW5nIG1lc3NhZ2VzLCBhbmQgd2lsbCB1c2UgcGVl ciBrZXlpbmcgcHJvdG9jb2xzLCBBTkQgYXJlCiAgICAgICBhbGwgdHJhbnNtaXR0ZWQgb3ZlciBU Q1AgaW5jbHVkZSBCR1AgUkZDIDQyNzEgW1JGQzQyNzFdLCBMRFAKICAgICAgIFtSRkM1MDM2XSBh bmQgTVNEUCBbUkZDMzYxOF0uICBBIHRlYW0gd2lsbCB3b3JrIG9uIG9uZSBtZWNoYW5pc20KICAg ICAgIHRvIGNvdmVyIHRoZXNlIHRocmVlIHByb3RvY29scy4gIE11Y2ggb2YgdGhlIHdvcmsgb24g dGhlIFJvdXRpbmcKICAgICAgIFByb3RvY29sIHVwZGF0ZSBmb3IgaXRzIGV4aXN0aW5nIGF1dGhl bnRpY2F0aW9uIG1lY2hhbmlzbSBpcwogICAgICAgYWxyZWFkeSBvY2N1cmluZyBpbiB0aGUgVENQ TSBXb3JraW5nIEdyb3VwLCBvbiB0aGUgVENQLUFPCiAgICAgICBbSS1ELmlldGYtdGNwbS10Y3At YXV0aC1vcHRdIGRvY3VtZW50LCBhcyB3ZWxsIGFzIGl0cwogICAgICAgY3J5cHRvZ3JhcGh5LWhl bHBlciBkb2N1bWVudCwgVENQLUFPLUNSWVBUTyBbSS1ELmFvLWNyeXB0b10uICBUaGUKICAgICAg IGV4Y2VwdGlvbiBpcyB0aGUgbW9kZSB3aGVyZSBMRFAgaXMgdXNlZCBkaXJlY3RseSBvbiB0aGUg TEFOCiAgICAgICBbUkZDPz8/P10uICBUaGUgd29yayBmb3IgdGhpcyBtYXkgZ28gaW50byB0aGUg R3JvdXAga2V5aW5nCiAgICAgICBjYXRlZ29yeSAody8gT1NQRikgbWVudGlvbmVkIGJlbG93LgoK ICAgT1NQRiwgSVNJUywgYW5kIFJJUAogICAgICAgVGhlIFJvdXRpbmcgUHJvdG9jb2xzIHRoYXQg ZmFsbCBpbnRvIHRoZSBjYXRlZ29yeSBHcm91cCBrZXlpbmcKICAgICAgIHdpdGggb25lLXRvLW1h bnkgcGVlcmluZyBtZXNzYWdlcyBpbmNsdWRlcyBPU1BGIFtSRkMyMzI4XSwgSVNJUwogICAgICAg W1JGQzExOTVdIGFuZCBSSVAgW1JGQzI0NTNdLiAgTm90IHN1cnByaXNpbmdseSwgYWxsIHRoZXNl IHJvdXRpbmcKICAgICAgIHByb3RvY29scyBoYXZlIHR3byBvdGhlciB0aGluZ3MgaW4gY29tbW9u LiAgRmlyc3QsIHRoZXkgYXJlIHJ1bgogICAgICAgb24gYSBjb21iaW5hdGlvbiBvZiB0aGUgT1NJ IGRhdGFsaW5rIGxheWVyIDIsIGFuZCB0aGUgT1NJIG5ldHdvcmsKICAgICAgIGxheWVyIDMuICBC eSB0aGlzIHdlIG1lYW4gdGhhdCB0aGV5IGhhdmUgYSBjb21wb25lbnQgb2YgaG93IHRoZQogICAg ICAgcm91dGluZyBwcm90b2NvbCB3b3JrcyB3aGljaCBpcyBzcGVjaWZpZWQgaW4gTGF5ZXIgMiBh cyB3ZWxsIGFzCiAgICAgICBpbiBMYXllciAzLiAgU2Vjb25kLCB0aGV5IGFyZSBhbGwgaW50ZXJu YWwgZ2F0ZXdheSBwcm90b2NvbHMsIG9yCiAgICAgICBJR1BzLiAgVGhlIGtleWluZyBtZWNoYW5p c21zIGFuZCB1c2Ugd2lsbCBiZSBtdWNoIG1vcmUKICAgICAgIGNvbXBsaWNhdGVkIHRvIGRlZmlu ZSBmb3IgdGhlc2UgdGhhbiBmb3IgYSBvbmUtdG8tb25lIG1lc3NhZ2luZwogICAgICAgcHJvdG9j b2wuCgogICBCRkQKICAgICAgIEJlY2F1c2UgaXQgaXMgbGVzcyBvZiBhIHJvdXRpbmcgcHJvdG9j b2wsIHBlciBzZSwgYW5kIG1vcmUgb2YgYQogICAgICAgcGVlciBhbGl2ZW5lc3MgZGV0ZWN0aW9u IG1lY2hhbmlzbSwgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nCiAgICAgICBEZXRlY3Rpb24gKEJG RCkgW1JGQz8/Pz9dIHdpbGwgaGF2ZSBpdHMgb3duIHRlYW0uCgogICBSU1ZQIFtSRkM/Pz8/XSwg UlNWUC1URSBbUkZDPz8/P10sIGFuZCBQQ0UKCgoKCgoKCkxlYm92aXR6ICYgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDMzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwOQoKCiAgICAgICBUaGVzZSB0aHJlZSBwcm90b2NvbHMgd2lsbCBiZSBoYW5kbGVk IHRvZ2V0aGVyLiBbd2hhdCBtb3JlCiAgICAgICBjaGFyYWN0ZXJpc2F0aW9uIHNob3VsZCB3ZSBn aXZlIGhlcmU/ICBSb3V0aW5nIEFEJ3MsIHByb3ZpZGUgdGV4dAogICAgICAgcGxzP10KCiAgIFBJ TS1TTSBhbmQgUElNLURNCiAgICAgICBGaW5hbGx5LCB0aGUgbXVsdGljYXN0IHByb3RvY29scyBv ZiBQSU0tU00gW1JGQzQ2MDFdIGFuZCBQSU0tRE0KICAgICAgIFtSRkMzOTczXSB3aWxsIGJlIGhh bmRsZWQgdG9nZXRoZXIuICBQSU0tU00gbXVsdGljYXN0cyByb3V0aW5nCiAgICAgICBpbmZvcm1h dGlvbiAoSGVsbG8sIEpvaW4vUHJ1bmUsIEFzc2VydCkgb24gYSBsaW5rLWxvY2FsIGJhc2lzLAog ICAgICAgdXNpbmcgYSBkZWZpbmVkIG11bHRpY2FzdCBhZGRyZXNzLiAgSW4gYWRkaXRpb24sIGl0 IHNwZWNpZmllcwogICAgICAgdW5pY2FzdCBjb21tdW5pY2F0aW9uIGZvciBleGNoYW5nZSBvZiBp bmZvcm1hdGlvbiAoUmVnaXN0ZXIsCiAgICAgICBSZWdpc3Rlci1TdG9wKSBiZXR3ZWVuIHRoZSBy b3V0ZXIgY2xvc2VzdCB0byBhIGdyb3VwIHNlbmRlciBhbmQKICAgICAgIHRoZSAicmVuZGV6dm91 cyBwb2ludCIgKFJQKS4gIFRoZSBSUCBpcyB0eXBpY2FsbHkgbm90ICJvbi1saW5rIgogICAgICAg Zm9yIGEgcGFydGljdWxhciByb3V0ZXIuICBXaGlsZSBtdWNoIHdvcmsgaGFzIGJlZW4gZG9uZSBv bgogICAgICAgbXVsdGljYXN0IHNlY3VyaXR5IGZvciBhcHBsaWNhdGlvbi1sYXllciBncm91cHMs IGxpdHRsZSBoYXMgYmVlbgogICAgICAgZG9uZSB0byBhZGRyZXNzIHRoZSBwcm9ibGVtIG9mIG1h bmFnaW5nIGh1bmRyZWRzIG9yIHRob3VzYW5kcyBvZgogICAgICAgc21hbGwgb25lLXRvLW1hbnkg Z3JvdXBzIHdpdGggbGluay1sb2NhbCBzY29wZS4gIFN1Y2ggYW4KICAgICAgIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbSBzaG91bGQgYmUgY29uc2lkZXJlZCBhbG9uZyB3aXRoIHRoZQogICAgICAg cm91dGVyLXRvLVJlbmRlenZvdXMgUG9pbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLiAgVGhl IG1vc3QKICAgICAgIGltcG9ydGFudCBpc3N1ZSBpcyBlbnN1cmluZyB0aGF0IG9ubHkgdGhlICJh dXRob3JpemVkIG5laWdoYm9ycyIKICAgICAgIGdldCB0aGUga2V5cyBmb3IgKFMsRyksIHNvIHRo YXQgcm9ndWUgcm91dGVycyBjYW5ub3QgcGFydGljaXBhdGUKICAgICAgIGluIHRoZSBleGNoYW5n ZXMuICBBbm90aGVyIGlzc3VlIGlzIHRoYXQgc29tZSBvZiB0aGUKICAgICAgIGNvbW11bmljYXRp b24gbWF5IG9jY3VyIGludHJhLWRvbWFpbiwgZS5nLiB0aGUgbGluay1sb2NhbAogICAgICAgbWVz c2FnZXMgaW4gYW4gZW50ZXJwcmlzZSwgd2hpbGUgb3RoZXJzIGZvciB0aGUgc2FtZSAoKixHKSBt YXkKICAgICAgIG9jY3VyIGludGVyLWRvbWFpbiwgZS5nLiB0aGUgcm91dGVyLXRvLVJlbmRlenZv dXMgUG9pbnQgbWVzc2dlcwogICAgICAgbWF5IGJlIGZyb20gb25lIGVudGVycHJpc2UncyByb3V0 ZXIgdG8gYW5vdGhlci4gIE9uZSBwb3NzaWJsZQogICAgICAgc29sdXRpb24gcHJvcG9zZXMgYSBy ZWdpb24td2lkZSAibWFzdGVyIiBrZXkgc2VydmVyIChwb3NzaWJseQogICAgICAgcmVwbGljYXRl ZCksIGFuZCBvbmUgImxvY2FsIiBrZXkgc2VydmVyIHBlciBzcGVha2luZyByb3V0ZXIuCiAgICAg ICBUaGVyZSBpcyBubyBpc3N1ZSB3aXRoIHByb3BhZ2F0aW5nIHRoZSBtZXNzYWdlcyBvdXRzaWRl IHRoZSBsaW5rLAogICAgICAgYmVjYXVzZSBsaW5rLWxvY2FsIG1lc3NhZ2VzLCBieSBkZWZpbml0 aW9uLCBhcmUgbm90IGZvcndhcmRlZC4KICAgICAgIFRoaXMgc29sdXRpb24gaXMgb2ZmZXJlZCBv bmx5IGFzIGFuIGV4YW1wbGUgb2YgaG93IHdvcmsgbWF5CiAgICAgICBwcm9ncmVzczsgZnVydGhl ciBkaXNjdXNzaW9uIHNob3VsZCBvY2N1ciBpbiB0aGlzIHdvcmsgdGVhbS4KICAgICAgIFNwZWNp ZmljYXRpb24gb2YgYSBsaW5rLWxvY2FsIHByb3RlY3Rpb24gbWVjaGFuaXNtIGZvciBQSU0tU00K ICAgICAgIG9jY3VycmVkIGluIFJGQyA0NjAxIFtSRkM0NjAxXSwgYW5kIHRoaXMgd29yayBpcyBi ZWluZyB1cGRhdGVkIGluCiAgICAgICBQSU0tU00tTElOS0xPQ0FMIFtJLUQuaWV0Zi1waW0tc20t bGlua2xvY2FsXS4gIEhvd2V2ZXIsIHRoZSBLTVAKICAgICAgIHBhcnQgaXMgY29tcGxldGVseSB1 bnNwZWNpZmllZCwgYW5kIHdpbGwgcmVxdWlyZSB3b3JrIG91dHNpZGUgdGhlCiAgICAgICBleHBl cnRpc2Ugb2YgdGhlIFBJTSB3b3JraW5nIGdyb3VwIHRvIGFjY29tcGxpc2gsIHdoaWNoIGlzIHdo eQogICAgICAgdGhpcyByb2FkbWFwIGlzIGJlaW5nIGNyZWF0ZWQuCgogICBUaGVzZSBwcm90b2Nv bHMgYXJlIGRlZW1lZCBvdXQtb2Ytc2NvcGUgZm9yIHRoaXMgY3VycmVudCBpdGVyYXRpb24gb2YK ICAgdGhlIHdvcmsgcm9hZG1hcC4gIE9uY2UgYWxsIG9mIHRoZSBwcm90b2NvbHMgbGlzdGVkIGFi b3ZlIGhhdmUgaGFkCiAgIHRoZWlyIHdvcmsgY29tcGxldGVkLCBvciBhcmUgY2xlYXJseSB3aXRo aW4gc2l0ZSBvZiBjb21wbGV0aW9uLCB0aGVuCiAgIHRoZSBjb21tdW5pdHkgd2lsbCByZXZpc2l0 IHRoZSBuZWVkIGFuZCBpbnRlcmVzdCBmb3Igd29ya2luZyBvbgogICB0aGVzZToKCiAgIG8gIE1B TkVUCiAgIG8gIEZPUkNFUwoKICAgW25lZWQgdGV4dCBmcm9tIHJvdXRpbmcgQURzIG9uIHdoeSB0 aGVzZSBhcmUgb3V0IG9mIHNjb3BlXQoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBp cmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAzNF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIw MDkKCgo0LjYuICBQcmlvcml0ZXMKCiAgIFJlc291cmNlcyBmcm9tIGJvdGggdGhlIHJvdXRpbmcg YXJlYSBhbmQgdGhlIHNlY3VyaXR5IGFyZWEgd2lsbCBiZQogICBhcHBsaWVkIHRvIHdvcmsgb24g dGhlc2UgcHJvYmxlbSBzcGFjZXMgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4KICAgUmVhbGl6aW5n IHRoYXQgc3VjaCByZXNvdXJjZXMgYXJlIGZhciBmcm9tIHVubGltaXRlZCwgYSByYW5rIG9yZGVy CiAgIHByaW9yaXR5IGZvciBhZGRyZXNzaW5nIHRoZSB3b3JrIG9mIGluY3JlbWVudGFsbHkgc2Vj dXJpbmcgdGhlc2UKICAgZ3JvdXBzIG9mIHJvdXRpbmcgcHJvdG9jb2xzIGlzIHByb3ZpZGVkOgoK ICAgbyAgUHJpb3JpdHkgMSAtIEJHUCAvIExEUCAvIE1TRFAgLSBhbG1vc3QgZG9uZSB3aXRoIFBo YXNlIDEgb24gdGhlc2UsCiAgICAgIHZpYSBUQ1AtQU8gW0ktRC5pZXRmLXRjcG0tdGNwLWF1dGgt b3B0XSAuCiAgIG8gIFByaW9yaXR5IDIgLSBQSU0tU00KICAgbyAgUHJpb3JpdHkgMyAtIE9TUEYg LyBJU0lTIC8gUklQCiAgIG8gIFByaW9yaXR5IDQgLSBCRkQKICAgbyAgUHJpb3JpdHkgNSAtIFJT VlAgYW5kIFJTVlAtVEUKCiAgIEJ5IGZhciB0aGUgbW9zdCBpbXBvcnRhbnQgZ3JvdXAgaXMgdGhl IFByaW9yaXR5IDEgZ3JvdXAgYXMgdGhlc2UgYXJlCiAgIHRoZSBwcm90b2NvbHMgdXNlZCBvbiB0 aGUgbW9zdCBwdWJsaWMgYW5kIGV4cG9zZWQgc2VnbWVudHMgb2YgdGhlCiAgIG5ldHdvcmtzLCBh dCB0aGUgcGVlcmluZyBwb2ludHMgYmV0d2VlbiBvcGVyYXRvcnMgYW5kIGJldHdlZW4KICAgb3Bl cmF0b3JzIGFuZCB0aGVpciBjdXN0b21lcnMuICBCRkQsIGFzIGEgZGV0ZWN0aW9uIG1lY2hhbmlz bQogICB1bmRlcmx5aW5nIHRoZSBQcmlvcml0eSAxIHByb3RvY29scyBpcyB0aGVyZWZvcmUgc2Vj b25kLgoKCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgQXMgbWVudGlvbmVkIGluIHRo ZSBJbnRyb2R1Y3Rpb24gLCBSRkM0OTQ4IGlkZW50aWZpZXMgYWRkaXRpb25hbAogICBzdGVwcyBu ZWVkZWQgdG8gYWNoaWV2ZSB0aGUgb3ZlcmFsbCBnb2FsIG9mIGltcHJvdmluZyB0aGUgc2VjdXJp dHkgb2YKICAgdGhlIGNvcmUgcm91dGluZyBpbmZyYXN0cnVjdHVyZS4gIFRob3NlIGluY2x1ZGUg dmFsaWRhdGlvbiBvZiByb3V0ZQogICBvcmlnaW4gYW5ub3VuY2VtZW50cywgcGF0aCB2YWxpZGF0 aW9uLCBjbGVhbmluZyB1cCB0aGUgSVJSIGRhdGFiYXNlcwogICBmb3IgYWNjdXJhY3ksIGFuZCBv cGVyYXRpb25hbCBzZWN1cml0eSBwcmFjdGljaWVzIHRoYXQgcHJldmVudAogICByb3V0ZXJzIGZy b20gYmVpbmcgY29tcHJvbWlzZWQgZGV2aWNlcy4gIFRoZSBLQVJQIHdvcmsgaXMgYnV0IG9uZQog ICBzdGVwIGluIGEgbmVjZXNzYXJ5IHN5c3RlbSBvZiBzZWN1cml0eSBpbXByb3ZlbWVudHMuCgog ICBUaGUgc2VjdXJpdHkgb2YgY3J5cHRvZ3JhcGhpYy1iYXNlZCBzeXN0ZW1zIGRlcGVuZHMgb24g Ym90aCB0aGUKICAgc3RyZW5ndGggb2YgdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBjaG9z ZW4gYW5kIHRoZSBzdHJlbmd0aCBvZgogICB0aGUga2V5cyB1c2VkIHdpdGggdGhvc2UgYWxnb3Jp dGhtcy4gIFRoZSBzZWN1cml0eSBhbHNvIGRlcGVuZHMgb24KICAgdGhlIGVuZ2luZWVyaW5nIG9m IHRoZSBwcm90b2NvbCB1c2VkIGJ5IHRoZSBzeXN0ZW0gdG8gZW5zdXJlIHRoYXQKICAgdGhlcmUg YXJlIG5vIG5vbi1jcnlwdG9ncmFwaGljIHdheXMgdG8gYnlwYXNzIHRoZSBzZWN1cml0eSBvZiB0 aGUKICAgb3ZlcmFsbCBzeXN0ZW0uCgogICBDYXJlIHNob3VsZCBhbHNvIGJlIHRha2VuIHRvIGVu c3VyZSB0aGF0IHRoZSBzZWxlY3RlZCBrZXkgaXMKICAgdW5wcmVkaWN0YWJsZSwgYXZvaWRpbmcg YW55IGtleXMga25vd24gdG8gYmUgd2VhayBmb3IgdGhlIGFsZ29yaXRobQogICBpbiB1c2UuICBb UkZDNDA4Nl0gY29udGFpbnMgaGVscGZ1bCBpbmZvcm1hdGlvbiBvbiBib3RoIGtleQogICBnZW5l cmF0aW9uIHRlY2huaXF1ZXMgYW5kIGNyeXB0b2dyYXBoaWMgcmFuZG9tbmVzcy4KCiAgIEluIGFk ZGl0aW9uIHRvIHVzaW5nIGEgc3Rvbmcga2V5L1BTSyBvZiBhcHByb3ByaWF0ZSBsZW5ndGggYW5k CiAgIHJhbmRvbW5lc3MsIGRlcGxveWVycyBvZiBLQVJQIHByb3RvY29scyBTSE9VTEQgdXNlIGRp ZmZlcmVudCBrZXlzCiAgIGJldHdlZW4gZGlmZmVyZW50IHJvdXRpbmcgcGVlcnMgd2hlbmV2ZXIg b3BlcmF0aW9uYWxseSBwb3NzaWJsZS4KICAgUkZDMzU2MiBbUkZDMzU2Ml0gcHJvdmlkZXMgc29t ZSB2ZXJ5IHNvdW5kIGd1aWRhbmNlLiAgSXQgd2FzIG1lYW50CgoKCkxlYm92aXR6ICYgICAgICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDM1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAgICAgICAg ICAgTm92ZW1iZXIgMjAwOQoKCiAgIHNwZWNpZmljYWxseSBmb3IgdGhlIHVzZSBvZiBUQ1AgTUQ1 IGZvciBCR1AsIGJ1dCBpdCBpcyBtb3JlIG9yIGxlc3MKICAgYXBwbGljYWJsZSB0byBSb3V0aW5n IFByb3RvY29sIGF1dGhlbnRpY2F0aW9uIHdvcmsgdGhhdCB3b3VsZCByZXN1bHQKICAgZnJvbSBL QVJQLiAgSXQgc3RhdGVzIHRocmVlIG1haW4gcG9pbnRzOiAoMSkga2V5IGxlbmd0aHMgU0hPVUxE IGJlCiAgIGJldHdlZW4gMTIgYW5kIDI0IGJ5dGVzICh0aGlzIHdpbGwgdmFyeSBkZXBlbmRpbmcg b24gdGhlIE1BQy9LREYgaW4KICAgdXNlKSwgd2l0aCBsYXJnZXIga2V5cyBoYXZpbmcgZWZmZWN0 aXZlbHkgemVybyBhZGRpdGlvbmFsCiAgIGNvbXB1dGF0aW9uYWwgY29zdHMgd2hlbiBjb21wYXJl ZCB0byBzaG9ydGVyIGtleXMsICgyKSBrZXkgc2hhcmluZwogICBTSE9VTEQgYmUgbGltaXRlZCBz byB0aGF0IGtleXMgYXJlbid0IHNoYXJlZCBhbW9uZyBtdWx0aXBsZSBCR1AKICAgcGVlcmluZyBh cnJhbmdlbWVudHMsIGFuZCAoMykgS2V5cyBTSE9VTEQgYmUgY2hhbmdlZCBhdCBsZWFzdCBldmVy eQogICA5MCBkYXlzICh0aGlzIGNvdWxkIGJlIGxvbmdlciBmb3Igc3Ryb25nZXIgTUFDIGFsZ29y aXRobXMsIGJ1dCBpdCBpcwogICBnZW5lcmFsbHkgYSB3aXNlIGlkZWEpLgoKICAgVGhpcyBpcyBl c3BlY2lhbGx5IHRydWUgd2hlbiB0aGUgUm91dGluZyBQcm90b2NvbCB0YWtlcyBhIHN0YXRpYwog ICBUcmFmZmljIEtleSBhcyBvcHBvc2VkIHRvIGEgVHJhZmZpYyBLZXkgZGVyaXZlZCBwZXItY29u bmVjdGlvbiBieSBhCiAgIEtERi4gIFRoZSBidXJkb24gZm9yIGRvaW5nIHNvIGlzIHVuZGVyc3Rh bmRhYmxlIG11Y2ggaGlnaGVyIHRoYW4gZm9yCiAgIHVzaW5nIHRoZSBzYW1lIHN0YXRpYyBUcmFm ZmljIEtleSBhY3Jvc3MgYWxsIHBlZXJpbmcgcm91dGVycy4gIFRoaXMKICAgaXMgd2h5IHVzZSBv ZiBhIEtNUCBuZXR3b3JrLXdpZGUgaW5jcmVhc2VzIHBlZXItd2lzZSBzZWN1cml0eSBzbwogICBn cmVhdGx5LCBiZWNhdXNlIG5vdyBlYWNoIHNldCBvZiBwZWVycyBjYW4gZW5qb3lzIGEgdW5pcXVl IFRyYWZmaWMKICAgS2V5LCBhbmQgaWYgYW4gYXR0YWNrZXIgc2l0dGluZyBiZXR3ZWVuIHR3byBy b3V0ZXJzIGxlYXJucyBvciBndWVzc2VzCiAgIHRoZSBUcmFmZmljIEtleSBmb3IgdGhhdCBjb25u ZWN0aW9uLCBzaGUgZG9lc24ndCBnYWluIGFjY2VzcyB0byBhbGwKICAgdGhlIG90aGVyIGNvbm5l Y3Rpb25zIGFzIHdlbGwuCgogICBIb3dldmVyLCB3aGVuZXZlciB1c2luZyBtYW51YWwga2V5cywg aXQgaXMgYmVzdCB0byBkZXNpZ24gYSBzeXN0ZW0KICAgd2hlcmUgYSBnaXZlbiBQU0sgd2lsbCBi ZSB1c2VkIGluIGEgS0RGLCBtaXhlZCB3aXRoIGNvbm5lY3Rpb24KICAgc3BlY2lmaWMgbWF0ZXJp YWwsIGluIG9yZGVyIHRvIGdlbmVyYXRlIHNlc3Npb24gdW5pcXVlIC0tIGFuZAogICB0aGVyZWZv cmUgcGVlci13aXNlIC0tIFRyYWZmaWMgS2V5cy4gIERvaW5nIHNvIGhhcyB0aGUgZm9sbG93aW5n CiAgIGFkdmFudGFnZXM6IHRoZSBUcmFmZmljIEtleXMgdXNlZCBpbiB0aGUgcGVyLW1lc3NhZ2Ug TUFDIG9wZXJhdGlvbgogICBhcmUgcGVlci13aXNlIHVuaXF1ZSwgaXQgcHJvdmlkZXMgaW50ZXIt Y29ubmVjdGlvbiByZXBsYXkgcHJvdGVjdGlvbiwKICAgYW5kLCBpZiB0aGUgcGVyLW1lc3NhZ2Ug TUFDIGNvdmVycyBzb21lIGNvbm5lY3Rpb24gY291bnRlciwgaW50cmEtCiAgIGNvbm5lY3Rpb24g cmVwbGF5IHByb3RlY3Rpb24uCgogICBOb3RlIHRoYXQgaW4gdGhlIGNvbXBvc2l0aW9uIG9mIGNl cnRhaW4ga2V5IGRlcml2YXRpb24gZnVuY3Rpb25zCiAgIChlLmcuICBLREZfQUVTXzEyOF9DTUFD LCBhcyB1c2VkIGluIFRDUC1BTyBbSS1ELmFvLWNyeXB0b10pLCB0aGUKICAgcHNldWRvcmFuZG9t IGZ1bmN0aW9uIChQUkYpIHVzZWQgaW4gdGhlIEtERiBtYXkgcmVxdWlyZSBhIGtleSBvZiBhCiAg IGNlcnRhaW4gZml4ZWQgc2l6ZSBhcyBhbiBpbnB1dC4gIEZvciBleGFtcGxlLCBBRVNfMTI4X0NN QUMgcmVxdWlyZXMgYQogICAxMjggYml0ICgxNiBieXRlKSBrZXkgYXMgdGhlIHNlZWQuICBIb3dl dmVyLCBmb3IgY29udmVuaWVuY2UgdG8gdGhlCiAgIGFkbWluaXN0cmF0b3JzL2RlcGxveWVycywg YSBzcGVjaWZpY2F0aW9uIG1heSBub3Qgd2FudCB0byBmb3JjZSB0aGUKICAgZGVwbG95ZXIgdG8g ZW50ZXIgYSBQU0sgb2YgZXhhY3RseSAxNiBieXRlcy4gIEluc3RlYWQsIGEKICAgc3BlY2lmaWNh dGlvbiBtYXkgY2FsbCBmb3IgYSBzdWIta2V5IHJvdXRpbmUgdGhhdCBjb3VsZCBoYW5kbGUgYQog ICB2YXJpYWJsZSBsZW5ndGggUFNLLCBvbmUgdGhhdCBtaWdodCBiZSBsZXNzIHRoYW4gMTYgYnl0 ZXMgKHNlZQogICBbUkZDNDYxNV0sIHNlY3Rpb24gMywgYXMgYW4gZXhhbXBsZSkuICBUaGF0IHN1 Yi1rZXkgcm91dGluZSB3b3VsZCBhY3QKICAgYXMgYSBrZXkgZXh0cmFjdG9yIHRvIGRlcml2ZSBh IHNlY29uZCBrZXkgb2YgZXhhY3RseSB0aGUgcmVxdWlyZWQKICAgbGVuZ3RoLCBhbmQgdGh1cyBz dWl0YWJsZSBhcyBhIHNlZWQgdG8gdGhlIFBSRi4gIFRoaXMgZG9lcyBOT1QgbWVhbgogICB0aGF0 IGFkbWluaXN0cmF0b3JzIGFyZSBzYWZlIHRvIHVzZSB3ZWFrIGtleXMuICBBZG1pbmlzdHJhdG9y cyBhcmUKICAgZW5jb3VyYWdlZCB0byBmb2xsb3cgW1JGQzQwODZdIGFzIGxpc3RlZCBhYm92ZS4g IFdlIHNpbXBseSBhdHRlbXB0ZWQKICAgdG8gInB1dCBhIGZlbmNlIGFyb3VuZCBzdHVwaWRpdHki LCBpbiBhcyBtdWNoIGFzIHBvc3NpYmxlLgoKICAgQSBiZXR0ZXIgb3B0aW9uLCBmcm9tIGEgc2Vj dXJpdHkgcGVyc3BlY3RpdmUsIGlzIHRvIHVzZSBzb21lCiAgIHJlcHJlc2VudGF0aW9uIG9mIGEg ZGV2aWNlLXNwZWNpZmljIGFzc3ltZXRyaWMga2V5IHBhaXIgYXMgdGhlCgoKCkxlYm92aXR6ICYg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdl IDM2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIGlkZW50aXR5IHByb29mLCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiAzLjQuMi4KCiAgIFdoZW4gaXQgY29tZXMgdGltZSBmb3IgdGhlIEtBUlAgV0cg dG8gZGVzaWduIHRoZSByZS11c2FibGUgbW9kZWwgZm9yCiAgIGEgS01QLCBUaGUgR3VpZGVsaW5l cyBmb3IgQ3J5cHRvZ3JhcGhpYyBLZXkgTWFuYWdlbWVudCwgUkZDNDEwNwogICBbUkZDNDEwN10g c2hvdWxkIGJlIHdpbGwgYmUgY29uc3VsdGVkLgoKICAgW1tRVUVTVElPTiBUTyBSRVZJRVdFUlM6 IGl0IG1heSBiZSB3b3J0aHdoaWxlIHRvIHB1bGwgdGhlIGxhc3QgZmV3CiAgIHBhcmFncmFwaHMs IGFsb25nIHdpdGggc29tZSBndWlkYW5jZSBhbG9uZyB0aGUgc2FtZSBsaW5lcywgaW50bwogICBz ZWN0aW9uIDQsIGluIGEgbmV3IHN1Yi1zZWN0aW9uIHdpdGggYSB0aXRsZSBzb21ldGhpbmcgbGlr ZSAiU2VjdXJpdHkKICAgdGlwcyBmb3IgS0FSUCBkZXNpZ24gdGVhbXMgd29ya2luZyBvbiBSb3V0 aW5nIFByb3RvY29sIHJldmlld3MgYW5kCiAgIHVwZGF0ZXMiLiAgT3IgbWF5YmUgZXZlbiBpbnRv IGl0cyBvd24gaW5mbyBkb2N1bWVudCwgIlNlY3VyaXR5CiAgIEd1aWRlbGluZXMgZm9yIEtBUlAg RGVzaWduIFRlYW1zIi5UaG91Z2h0cz9dXQoKICAgVGhlIG1lY2hhbmlzbXMgdGhhdCB3aWxsIGJl IGRlZmluZWQgdW5kZXIgdGhpcyByb2FkbWFwIGFpbSB0byBpbXByb3ZlCiAgIHRoZSBzZWN1cml0 eSwgYmV0dGVyIHByb3RlY3QgYWdhaW5zdCBtb3JlIHRocmVhdHMsIGFuZCBwcm92aWRlciBmYXIK ICAgZ3JlYXRlciBvcGVyYXRpb25hbCBlZmZpY2llbmNpZXMgdGhhbiB0aGUgc3RhdGUgb2YgdGhp bmdzIGF0IHRoZSB0aW1lCiAgIG9mIHRoaXMgd3JpdGluZy4gIEhvd2V2ZXIsIG5vbmUgb2YgdGhl c2UgY2hhbmdlcyB3aWxsIGltcHJvdmUKICAgSW50ZXJuZXQgc2VjdXJpdHkgdW5sZXNzIHRoZXkg YXJlIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZC4gIE90aGVyCiAgIGluZmx1ZW5jZXMgbXVzdCBi ZSBicm91Z2h0IHRvIGJhcmUgdXBvbiBvcGVyYXRvcnMgYW5kIG9yZ2FuaXphdGlvbnMKICAgdG8g Y3JlYXRlIGluY2VudGl2ZXMgZm9yIGRlcGxveW1lbnQuICBTdWNoIGluY2VudGl2ZXMgbWF5IHRh a2UgdGhlCiAgIGZvcm0gb2YgUENJLWxpa2UgaW5kdXN0cnkgY29tcGxpYW5jZS9jZXJ0aWZpY2F0 aW9ucywgd2VsbCBhZHZlcnRpc2VkCiAgIEJDUHMgcHJvZmlsaW5nIHRoZSB1c2Ugb2YgdGhpcyBy b2FkbWFwJ3Mgb3V0cHV0LCBlbmQtdXNlciBkZW1hbmQgb3IKICAgaW5zaXN0YW5jZS4KCgo2LiAg SUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBoYXMgbm8gYWN0aW9ucyBmb3Ig SUFOQS4KCgo3LiAgQWNrbm93bGVkZ2VtZW50cwoKICAgVGhlIG91dGxpbmUgZm9yIHRoaXMgZHJh ZnQgd2FzIGNyZWF0ZWQgZnJvbSBkaXNjdXNzaW9ucyBhbmQKICAgYWdyZWVtZW50cyB3aXRoIFJv dXRpbmcgQUQncyBSb3NzIENhbGxvbiBhbmQgRGF2ZSBXYXJkLCBTZWN1cml0eSBBRCdzCiAgIFRp bSBQb2xrIGFuZCBQYXNpIEVyb25lbiwgYW5kIElBQiBtZW1iZXJzIERhbm55IE1jUGhlcnNvbiBh bmQgR3JlZ29yeQogICBMZWJvdml0ei4KCiAgIE1hdCBGb3JkIGFuZCBCaWxsIEF0d29vZCBwcm92 aWRlZCByZXZpZXdzIHRvIC0wMC4KCiAgIERhbm55IE1jUGhlcnNvbiBwcm92aWRlZCBhbiBleHRy ZW1lbHkgZGV0YWlsZWQgYW5kIHVzZWZ1bCByZXZpZXcgb2YKICAgLTAxLgoKCjguICBDaGFuZ2Ug SGlzdG9yeSAoUkZDIEVkaXRvcjogRGVsZXRlIEJlZm9yZSBQdWJsaXNoaW5nKQoKICAgW05PVEUg VE8gUkZDIEVESVRPUjogdGhpcyBzZWN0aW9uIGZvciB1c2UgZHVyaW5nIEktRCBzdGFnZSBvbmx5 LgogICBQbGVhc2UgcmVtb3ZlIGJlZm9yZSBwdWJsaXNoaW5nIGFzIFJGQy5dCgoKCgpMZWJvdml0 eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDEwICAgICAgICAgICAgICAgICBb UGFnZSAzN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBLQVJQIFJvYWRtYXAgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgogICAtMDAtMDAgb3JpZ2luYWwgcm91Z2ggcm91 Z2ggcm91Z2ggZHJhZnQgZm9yIHJldmlldyBieSByb3V0aW5nIGFuZAogICBzZWN1cml0eSBBRCdz CgogICAtMDAtIG9yaWdpbmFsIHN1Ym1pc3Npb24KCiAgIG8gIGFkZHMgbmV3IGNhdGVnb3J5ID0g bXVsdGljYXN0IHByb3RvY29scyBpbiBjYXRlZ29yeSBzZWN0aW9uIGFuZAogICAgICBtZW50aW9u cyBtY2FzdCBpbiBncm91cCBrZXlpbmcgY2F0ZWdvcnkgZGVzY3JpcHRpb24uCiAgIG8gIGFkZCBh IGxvdCBvZiByZWZlcmVuY2VzIHdoZXJlIHRoZXkgZGlkIG5vdCBleGlzdCBiZWZvcmUsIG9yIHdo ZXJlCiAgICAgIHRoZXJlIHdlcmUgb25seSBwbGFjZSBob2xkZXJzLiAgU3RpbGwgbW9yZSB3b3Jr IG5lZWRlZCBvbiB0aGlzLgogICBvICBhYnN0cmFjdCBmaWxsZWQgaW4KICAgbyAgY2hhbmdlZCBm cm9tIHN0YW5kYXJkcyB0cmFjayB0byBpbmZvcm1hdGlvbmFsICh0aGlzIHdhcyBhbgogICAgICBv dmVyc2lnaHQgaW4gbGFzdCBkcmFmdCkuCiAgIG8gIGZpbGxlZCBvdXQgdGhyZWF0cyBzZWN0aW9u IHdpdGggZGV0YWlsZWQgZGVzY3JpcHRpb25zLCBhbmQgbGlua2VkCiAgICAgIHRvIFJQc2VjIHRo cmVhdHMgUkZDCiAgIG8gIG1hZGUgYXNjaWkgYXJ0IGZvciB0aGUgYmFzaWMgS01QIGZyYW1ld29y awogICBvICBhZGRlZCBzZWN0aW9uIG9uIGludGVybmFsIHZlcnN1cyBleHRlcm5hbCBwZWVyaW5n IGFuZCB0aGUKICAgICAgcmVxdWlyZW1lbnRzIGRlY2lzaW9ucyBmb3IgdGhlbQogICBvICBhZGRl ZCBzZWN1cml0eSBjaGFyYWN0ZXJpemF0aW9uIHNlY3Rpb24gaW4gc2VjdCAyLCBhZGRlZCBzZWN0 aW9ucwogICAgICBkaXNjdXNzaW5nIGludGVybmFsIHZzIGV4dGVybmFsIHByb3RvY29scywgc2hh cmVkIHZzIHVuaXF1ZSBrZXlzLAogICAgICBvb2IgdnMgaW4tYmFuZCBrZXlpbmcKICAgbyAgaW5j b3Jwb3JhdGVzIGFsbCBEIFdhcmQncyBmZWVkYmFjayBmcm9tIGhpcyBpbml0aWFsIHNraW0gb2Yg dGhlCiAgICAgIGRvY3VtZW50LgoKICAgLTAxLQoKICAgbyAgVXBkYXRlZCBmcmFtZXdvcmsgKEZp Z3VyZSAxKSBkaWFncmFtIHRvIGluY2x1ZGUgYWxsIGxpc3RlZCBhbmQKICAgICAgZGVzY3JpYmVk IGVsZW1lbnRzLiAgTmVlZHMgcmV2aWV3IGFuZCBob25pbmcuICBHcmVnb3J5IExlYm92aXR6CiAg ICAgIChHTCkuCiAgIG8gIEFkZGVkIGNvbW1lbnQgaW4gcHJvdG9jb2xzIChTZWN0aW9uIDQuNSkg c2VjdGlvbiB0aGF0IG11Y2ggb2YgdGhlCiAgICAgIEJHUC9MRFAgUGhhc2UgMSB3b3JrIGlzIGFs cmVhZHkgYmVpbmcgZG9uZSBpbiB0Y3AtYW8gYW5kIGFvLQogICAgICBjcnlwdG8uICBHTC4KICAg byAgVXBkYXRlZCBTY29wZSBtYWtpbmcgdGhlIDIgd29yayBwaGFzZXMgbW9yZSBjbGVhciBlYXJs aWVyIGluIHRoZQogICAgICBkb2N1bWVudC4gIEdMLgogICBvICBCcm9rZSB3b3JrIGl0ZW1zIChT ZWN0aW9uIDQuNCkgc2VjdGlvbiBpbnRvIHR3byBQaGFzZXMsIDEgZm9yCiAgICAgIG1hbnVhbCBr ZXkgdXBkYXRlLCBhbmQgc2Vjb25kIGZvciBLTVAgd29yay4gIEdMLgogICBvICBSZS1vcmcnZCBk b2MuICBCcm91Z2h0IFRocmVhdHMgKFNlY3Rpb24gMikgc2VjdGlvbiBvdXQgaW50byBpdHMKICAg ICAgb3duIHRvcC1sZXZlbCBzZWN0aW9uLiAgRGlkIHNhbWUgd2l0aCBDYXRlZ29yaXphdGlvbiAo U2VjdGlvbiAzKQogICAgICBzZWN0aW9uLCBsZWF2aW5nIFJvYWRtYXAgc2VjdGlvbiBtb3JlIGZv Y3VzZWQuICBNb3ZlZCBUb0RvIGxpc3QKICAgICAgYW5kIENoYW5nZSBIaXN0b3J5IHRvIGVuZCBv ZiBkb2MsIGFmdGVyIEFja25vd2xlZGdlbWVudHMuICBHTC4KICAgbyAgYWRkZWQgbmV3IHNlY3Qg Mi4zIChTZWN0aW9uIDQuMSkgb24gbWFpbiByb2FkbWFwIHBoYXNlcy4gIFByZXZpb3VzCiAgICAg IHNlY3Rpb24gQ29tbW9uIEZyYW1ld29yayAoU2VjdGlvbiA0LjMpIG1vdmVkIHRvIDIuNC4gIFRp bSBQb2xrCiAgICAgIChUUCkuCiAgIG8gIEFkZGVkIFNlY3Rpb24gMi4zLjEgUmVxdWlyZW1lbnRz IGZvciBQaGFzZSAxIFJvdXRpbmcgUHJvdG9jb2xzJwogICAgICBTZWN1cml0eSBVcGRhdGUgKFNl Y3Rpb24gNC4yKS4gIFRoaXMgcHJvdmlkZXMgYSBuaWNlIHN0YXJ0ZXIgc2V0CiAgICAgIG9mIHJl cXVpcmVtZW50cyBmb3IgYW55IHdvcmsgdGVhbS4gIEdMLgogICBvICBGaWxsZWQgb3V0IHRleHQg Zm9yIE91dCB2cyBJbi1iYW5kIEtleSBNZ210IChTZWN0aW9uIDMuNC4zKQogICAgICBzZWN0aW9u LCBzaWduaWZpY2FudGx5LiAgQ2hhbmdlZCB0aGUgdGVybSBmcm9tICJpbi1iYW5kIiB0byAiaW4t CiAgICAgIGxpbmUiLgoKCgpMZWJvdml0eiAmICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5 LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSAzOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICBLQVJQIFJvYWRtYXAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDkKCgogICBv ICBTZWN0aW9uIFRocmVhdHMgKFNlY3Rpb24gMikgQ2xhcmlmaWVkIERvUyB0aHJlYXRzIGluIGFu ZCBvdXQgb2YKICAgICAgc2NvcGUgYmV0dGVyLiAgV2UgYXJlIG5vdCBwcmV2ZW50aW5nIGFsbCBE b1MgYXR0YWNrcy4gIEp1c3QgdGhvc2UKICAgICAgd2UgY2FuIHJlYXNvbmFibHkgdmlhIGF1dGhl bnRpY2F0aW9uLiAgVFAuCiAgIG8gIFNlY3QgSW4tYmFuZCB2cyBPdXQtb2YtQmFuZCAoU2VjdGlv biAzLjQuMyljbGFyaWZpZWQgdGhhdCBJbi1iYW5kCiAgICAgIGRvZXMgbm90IG1lYW4gaW4tYmFu ZCB0byBSb3V0aW5nIFByb3RvY29sLCBidXQgcmF0aGVyIG92ZXIgSVAKICAgICAgYmV0d2VlbiB0 aGUgUm91dGluZyBQcm90b2NvbHMsIHJhdGhlciB0aGFuIHB1c2hlZCBkb3duIGJ5IHNvbWUKICAg ICAgZXh0ZXJuYWwgbWFuYWdlbWVudCBlbnRpdHkuICBUUC4KICAgbyAgSW4gcm9hZG1hcCAoU2Vj dGlvbiAzKSBzZWN0aW9uLCBhZGRlZCAiaXQgaXMgYWxzbyBob3BlZCB0aGF0IHdlCiAgICAgIGNh biBjcmVhdGUgb25lIGttcCBwZXIgY2F0ZWdvcnkuLi4iICBBbHNvIGV4cGxhaW5lZCB2YWx1ZSBv ZiBhCiAgICAgIEtNUC4gIFRQLgogICBvICBBZGRlZCAib3BlcmF0b3JzIiB0byBhdWRpZW5jZSAo U2VjdGlvbiAxLjYpIGxpc3QuICBNYXR0IEZvcmQgKE1GKS4KICAgbyAgRGVzY3JpYmVkIHdoeSBC R1AgKGFuZCBMRFApIHNlY3VyaXR5IGlzIG5vdCBkZXBsb3llZCB2ZXJ5IG9mdGVuLgogICAgICBB ZGRlZCB0aGlzIFNjb3BlIChTZWN0aW9uIDEuMykgc2VjdGlvbiwgcG9pbnQgNC4gIElmIG1lY2hh bmlzbXMKICAgICAgYXJlbid0IGJlaW5nIGRlcGxveWVkLCB3aHkgaXMgdGhhdD8gIFdoYXQsIGlm IGFueXRoaW5nLCBjb3VsZCBiZQogICAgICBkb25lIHRvIGltcHJvdmUgZGVwbG95bWVudD8gIFRy aWVkIHRvIGFkZHJlc3MgdGhlc2UuICBOZWVkCiAgICAgIHJlZmVyZW5jZXMgKHNlZSBUbyBEbyBs aXN0IGJlbG93KS4gIE1GLgogICBvICBBZGRlZCBzb21lIHRleHQgdG8gc2VjdXJpdHkgc2VjdGlv biB0byBhZGRyZXNzIHRoaXMgZnJvbSBNRjogc2F5CiAgICAgIHNvbWV0aGluZyBoZXJlIGFib3V0 IHRoZSBsaW1pdGF0aW9ucyBvZiB0aGlzIGFwcHJvYWNoLCBpZiBhbnkgLQogICAgICBhbmQgcmVm ZXIgYmFjayB0byB0aGUgbmVlZCBmb3Igb3RoZXIgcGllY2VzIG9mIHRoZSBwdXp6bGUuICBNYXkK ICAgICAgbmVlZCBtb3JlIHdvcmsuCiAgIG8gIENsZWFuZWQgdXAgdGV4dCBmb3IgbXVsdGljYXN0 IHBhcnQgb2YgTWVzc2FnZSBUeXBlIChTZWN0aW9uIDMuMSkKICAgICAgc2VjdGlvbiBhbmQgUHJv dG9jb2xzIChTZWN0aW9uIDQuNSkgc2VjdGlvbiwgY2xhcmlmeWluZyBQSU0ncyB0d28KICAgICAg bWVzc2FnZSB0eXBlcywgbWNhc3QgYW5kIHVuaWNhc3QsIGluIGJvdGggcGxhY2VzLiAgQmlsbCBB dHdvb2QKICAgICAgKEJBKS4KICAgbyAgSW4gc2VjdGlvbiBQcm90b2NvbHMgKFNlY3Rpb24gNC41 KSwgYWRkZWQgcmVmZXJlbmNlcyB0byA0NjAxIGFuZAogICAgICBQSU0tU00tTElOS0xPQ0FMLiAg QkEuCiAgIG8gIEVkaXRvcmlhbCBjaGFuZ2VzIHBvaW50ZWQgb3V0IHZhcmlvdXMgZm9sa3MuCgog ICAtMDItCgogICBvICBSZS1zdWJtaXR0ZWQgZHVlIHRvIGV4cGlyYXRpb24uICBUZXh0IGRpZCBu b3QgY2hhbmdlLiAgU3Vic3RhbnRpdmUKICAgICAgdXBkYXRlIGNvbWluZyBzaG9ydGx5LgogICBv CiAgIG8KCiAgIC0gMDMgLQoKICAgbyAgY2hhbmdlZCAiQmFzZVJQIiB0byAiUm91dGluZyBQcm90 b2NvbCIgdGhyb3VnaG91dCB0aGUgZG9jIC0gbWFuCiAgIG8gIGZpbGxlZCBvdXQgdGhlIFRlcm1p bm9sb2d5IHNlY3Rpb24KICAgbyAgY2hhbmdlZCAiS01BUlQiIHRvICJLQVJQIiBpbiBldmVyeXRo aW5nIGJ1dCB0aGUgdGl0bGUsIHNpbmNlIHRoZQogICAgICAtMDAgZGVhZGxpbmUgaGFkIGxvbmcg c2luY2UgcGFzc2VkLiAgV2lsbCBjaGFuZ2UgdGhlIHRpdGxlIG9mIHRoZQogICAgICBkb2MgdG8g S0FSUCBhcyBzb29uIGFzIHRoZSB3aW5kb3cgcmUtb3BlbnMuCiAgIG8gIHByaW9yaXRpZXMgaW4g c2VjdCA0LjYgY2hhbmdlZC4gIEFkZGVkIFBJTS1TTS4gIExvd2VyZWQgT1NQRiBhbmQKICAgICAg QkZELCBiYXNlZCBvbiBmZWVkYmFjayBieSBhIGZldyBwZW9wbGUuCiAgIG8gIG1hbnkgZWRpdHMg cmVzdWx0aW5nIGZyb20gRGFubnkgTWNQaGVyc29uJ3MgcmV2aWV3LgogICBvICBhZGRlZCAiQnJ1 dGUgRm9jZSBBdHRhY2tzIEFnYWluc3QgUGFzc3dvcmQvS2V5cyIgdG8gVGhyZWF0cwogICAgICBT ZWN0aW9uIDIuMSBzZWN0aW9uLgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMzldCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5 CgoKICAgbyAgU2lnbmlmaWNhbnQgdXBkYXRlcyB0byBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uCiAgIG8gIEFkZGVkIGEgZmV3IHJlZmVyZW5jZXMgdGhyb3VnaG91dCB0byBSRkMzNTYy CiAgIG8gIDQuMyAybmQgdG8gbGFzdCBQIC0gYWRkZWQgYSBjb21tZW50IHRvIGNsYXJpZnkgdGhh dCB0d28gcGFydGllcwogICAgICAob3IgYW4gb3JnKSBtdXN0IGRpc2N1c3MgYWhlYWQgb2YgdGlt ZSB3aGF0IHRoZXkgd2FudCB0aGVpcgogICAgICBjb25uZWN0aW9ucycgc2VjcnVpdHkgcHJvcGVy dGllcyB0byBiZS4gLSBkd2FyZAogICBvICBhZGRlZCB0byA0LjQgUGhhc2UgMSAtIE5ldyBTZWN0 aW9uOiBUcmFuc2l0aW9uIGFuZCBEZXBsb3ltZW50CiAgICAgIENvbnNpZGVyYXRpb25zLiBlYSB3 ZyBtdXN0IGNhbGwgb3V0IHRoZSBvcGVyYXRpb25hbCB0cmFuc2l0aW9uCiAgICAgIHBsYW4gZnJv bSBvbGQgdG8gbmV3IHNlY3VyaXR5LiAgQmVzdCBpZiBkb24ndCBib3VuY2UgbGluay4gLSBkd2Fy ZAogICBvICBhZGRlZCAzLjMgKGJ1dCBub3Qgc3VyZSBpZiB0aGlzIGlzIHJpZ2h0KS0gZW5kcG9p bnQgZGlzY292ZXJ5CiAgICAgIG1lY2hhbmlzbXM/IGVuZHBvaW50IGRpc2NvdmVyeSBtZWNoYW5p c20gKEwyVlBOLCBMM1ZQTiwgZXRjKS4KICAgICAgRGlzY292ZXJ5IGlzIG11Y2ggZGlmZmVyZW50 IHNlY3VyaXR5IHByb3BlcnRpZXMgdGhhbiBwYXNzaW5nCiAgICAgIFJvdXRpbmcgdXBkYXRlcy4g LSBkd2FyZAogICBvICBNb3JlIHJlcXVpcmVtZW50czogQWRkZWQgdG8gNC4yOiBYIC0gY29udmVy Z2VuY2UgU0hPVUxEIG5vdCBiZQogICAgICBhZmZlY3RlZCBieSB3aGF0IHdlIGNob29zZTsgYWRk aW5nIHNlY3VyaXR5IFNIT1VMRCBub3QgY2F1c2UgYQogICAgICByZWZyZXNoIG9mIHJvdXRlIHVw ZGF0ZXMgb3IgY2F1c2UgYWRkaXRpb25hbCByb3V0ZSB1cGRhdGVzIHRvIGJlCiAgICAgIGdlbmVy YXRlZDsgYWRkaW5nIGF1dGggc2hvdWxkIG5vdCBiZSBhbiBhdHRhY2sgdmVjdG9yIGl0c2VsZi4K ICAgICAgQUtBLCB0aGUgdXNlIG9mIE1ENSBpcyBzbyBleHBlbnNpdmUgdGhhdCBzcG9vZmluZyBC R1AgcGFja2V0cyB3LwogICAgICBNRDUgY2F1c2VzIHRoZSBjb250cm9sIHBsYW5lIHRvIGJlIGF0 dGFja2VkIGJlY2F1c2UgQ1BVIHdlbnQgdG8KICAgICAgMTAwJSAtIGR3YXJkCiAgIG8gIHVwZGF0 ZWQgc3RhdHMgb24gTUQ1IHVzYWdlLCBhbmQgY2l0ZWQgW0lTUjIwMDhdLiAtIG1jaHBoZXJzb24K Cgo5LiAgTmVlZHMgV29yayBpbiBOZXh0IERyYWZ0IChSRkMgRWRpdG9yOiBEZWxldGUgQmVmb3Jl IFB1Ymxpc2hpbmcpCgogICBbTk9URSBUTyBSRkMgRURJVE9SOiB0aGlzIHNlY3Rpb24gZm9yIHVz ZSBkdXJpbmcgSS1EIHN0YWdlIG9ubHkuCiAgIFBsZWFzZSByZW1vdmUgYmVmb3JlIHB1Ymxpc2hp bmcgYXMgUkZDLl0KCiAgIExpc3Qgb2Ygc3R1ZmYgdGhhdCBzdGlsbCBuZWVkcyB3b3JrCiAgIG8g IFJURyBBRCdzIG9yIGRlbGVnYXRlczogY2xlYW4gdXAgdGhlIHRocmVlIGRlZmluaXRpb25zIG9m IHJvdXRlCiAgICAgIG1lc3NhZ2UgdHlwZSBjYXRlZ29yaWVzLiAgTmVlZCBSVEcgQXJlYSBmb2xr cyBpbnB1dCBvbiB0aGlzLgogICBvICBNb3JlIGNsYXJpdHkgb24gdGhlIHdvcmsgaXRlbXMgZm9y IHRob3NlIGRlZmluaW5nIGFuZCBzcGVjaWZ5aW5nCiAgICAgIHRoZSBmcmFtZXdvcmsgZWxlbWVu dHMgYW5kIEFQSSdzIHRoZW1zZWx2ZXMuCiAgIG8gIFJURyBBRCdzIG9yIGRlbGVnYXRlczogdGV4 dCBqdXN0aWZ5aW5nIFJTVlAgYW5kIFJTVlAtVEUgYW5kIHdoYXQKICAgICAgd2UgdGhpbmsgc29s dmluZyB0aGF0IHByb2JsZW0gbWF5IGxvb2sgbGlrZQogICBvICBSVEcgQUQncyBvciBkZWxlZ2F0 ZXM6IG1vcmUganVzdGlmaWNhdGlvbiBmb3Igd2h5IE1BTkVUIGFuZCBGT1JDRVMKICAgICAgYXJl IG91dCBvZiBzY29wZS4gIE5lZWQgcmVmIGZvciB0aG9zZSBSRkNzLgogICBvICBEYW5ueSBNY1Bo ZXJzb246IEdldCByZWZlcmVuY2UgZm9yIEJHUCBhdXRoIHVzYWdlIHN0YXRzIGluIFNjb3BlCiAg ICAgIChTZWN0aW9uIDEuMykgc2VjdGlvbiwgaXRlbSA0LgogICBvCiAgIG8gIHNlY3VyaXR5IHNl Y3Rpb246IHB1bGwgb3V0IHNlY3VyaXR5IGd1aWRhbmNlIHRvIHJvdXRpbmcgcHJvdG9jb2wKICAg ICAgZGVzaWduIHRlYW1zIHN0dWZmIGFuZCBwbGFjZSBpbnRvIGl0cyBvd24gc2VjdGlvbj8KICAg bwogICBvCgoKMTAuICBSZWZlcmVuY2VzCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgOSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgNDBdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJl ciAyMDA5CgoKMTAuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRu ZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgog ICBbUkZDNDU5M10gIEJhcmJpciwgQS4sIE11cnBoeSwgUy4sIGFuZCBZLiBZYW5nLCAiR2VuZXJp YyBUaHJlYXRzIHRvCiAgICAgICAgICAgICAgUm91dGluZyBQcm90b2NvbHMiLCBSRkMgNDU5Mywg T2N0b2JlciAyMDA2LgoKICAgW1JGQzQ5NDhdICBBbmRlcnNzb24sIEwuLCBEYXZpZXMsIEUuLCBh bmQgTC4gWmhhbmcsICJSZXBvcnQgZnJvbSB0aGUKICAgICAgICAgICAgICBJQUIgd29ya3Nob3Ag b24gVW53YW50ZWQgVHJhZmZpYyBNYXJjaCA5LTEwLCAyMDA2IiwKICAgICAgICAgICAgICBSRkMg NDk0OCwgQXVndXN0IDIwMDcuCgoxMC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0kt RC5hby1jcnlwdG9dCiAgICAgICAgICAgICAgTGVib3ZpdHosIEcuLCAiQ3J5cHRvZ3JhcGhpYyBB bGdvcml0aG1zLCBVc2UgYW5kCiAgICAgICAgICAgICAgSW1wbGVtZW50YXRpb24gUmVxdWlyZW1l bnRzIGZvciBUQ1AgQXV0aGVudGljYXRpb24KICAgICAgICAgICAgICBPcHRpb24iLCBNYXJjaCAy MDA5LCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvCiAgICAgICAgICAgICAgZHJhZnQtbGVi b3ZpdHotaWV0Zi10Y3BtLXRjcC1hby1jcnlwdG8tMDA+LgoKICAgW0ktRC5pZXRmLXBpbS1zbS1s aW5rbG9jYWxdCiAgICAgICAgICAgICAgQXR3b29kLCBXLiwgSXNsYW0sIFMuLCBhbmQgTS4gU2lh bWksICJBdXRoZW50aWNhdGlvbiBhbmQKICAgICAgICAgICAgICBDb25maWRlbnRpYWxpdHkgaW4g UElNLVNNIExpbmstbG9jYWwgTWVzc2FnZXMiLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtcGlt LXNtLWxpbmtsb2NhbC0wOSAod29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgT2N0b2Jl ciAyMDA5LgoKICAgW0ktRC5pZXRmLXRjcG0tdGNwLWF1dGgtb3B0XQogICAgICAgICAgICAgIFRv dWNoLCBKLiwgTWFua2luLCBBLiwgYW5kIFIuIEJvbmljYSwgIlRoZSBUQ1AKICAgICAgICAgICAg ICBBdXRoZW50aWNhdGlvbiBPcHRpb24iLCBkcmFmdC1pZXRmLXRjcG0tdGNwLWF1dGgtb3B0LTA4 CiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBPY3RvYmVyIDIwMDkuCgogICBbSVNS MjAwOF0gIE1jUGhlcnNvbiwgRC4gYW5kIEMuIExhYm92aXR6LCAiV29ybGR3aWRlIEluZnJhc3Ry dWN0dXJlCiAgICAgICAgICAgICAgU2VjdXJpdHkgUmVwb3J0IiwgT2N0b2JlciAyMDA4LAogICAg ICAgICAgICAgIDxodHRwOi8vd3d3LmFyYm9ybmV0d29ya3MuY29tL2RtZG9jdW1lbnRzL0lTUjIw MDhfVVMucGRmPi4KCiAgIFtSRkMxMTk1XSAgQ2FsbG9uLCBSLiwgIlVzZSBvZiBPU0kgSVMtSVMg Zm9yIHJvdXRpbmcgaW4gVENQL0lQIGFuZAogICAgICAgICAgICAgIGR1YWwgZW52aXJvbm1lbnRz IiwgUkZDIDExOTUsIERlY2VtYmVyIDE5OTAuCgogICBbUkZDMjMyOF0gIE1veSwgSi4sICJPU1BG IFZlcnNpb24gMiIsIFNURCA1NCwgUkZDIDIzMjgsIEFwcmlsIDE5OTguCgogICBbUkZDMjQ1M10g IE1hbGtpbiwgRy4sICJSSVAgVmVyc2lvbiAyIiwgU1REIDU2LCBSRkMgMjQ1MywKICAgICAgICAg ICAgICBOb3ZlbWJlciAxOTk4LgoKICAgW1JGQzM1NjJdICBMZWVjaCwgTS4sICJLZXkgTWFuYWdl bWVudCBDb25zaWRlcmF0aW9ucyBmb3IgdGhlIFRDUCBNRDUKICAgICAgICAgICAgICBTaWduYXR1 cmUgT3B0aW9uIiwgUkZDIDM1NjIsIEp1bHkgMjAwMy4KCiAgIFtSRkMzNjE4XSAgRmVubmVyLCBC LiBhbmQgRC4gTWV5ZXIsICJNdWx0aWNhc3QgU291cmNlIERpc2NvdmVyeQogICAgICAgICAgICAg IFByb3RvY29sIChNU0RQKSIsIFJGQyAzNjE4LCBPY3RvYmVyIDIwMDMuCgoKCkxlYm92aXR6ICYg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdl IDQxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEtBUlAgUm9hZG1hcCAgICAgICAg ICAgICAgICAgTm92ZW1iZXIgMjAwOQoKCiAgIFtSRkMzOTczXSAgQWRhbXMsIEEuLCBOaWNob2xh cywgSi4sIGFuZCBXLiBTaWFkYWssICJQcm90b2NvbAogICAgICAgICAgICAgIEluZGVwZW5kZW50 IE11bHRpY2FzdCAtIERlbnNlIE1vZGUgKFBJTS1ETSk6IFByb3RvY29sCiAgICAgICAgICAgICAg U3BlY2lmaWNhdGlvbiAoUmV2aXNlZCkiLCBSRkMgMzk3MywgSmFudWFyeSAyMDA1LgoKICAgW1JG QzQwODZdICBFYXN0bGFrZSwgRC4sIFNjaGlsbGVyLCBKLiwgYW5kIFMuIENyb2NrZXIsICJSYW5k b21uZXNzCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTZWN1cml0eSIsIEJDUCAxMDYs IFJGQyA0MDg2LCBKdW5lIDIwMDUuCgogICBbUkZDNDEwN10gIEJlbGxvdmluLCBTLiBhbmQgUi4g SG91c2xleSwgIkd1aWRlbGluZXMgZm9yIENyeXB0b2dyYXBoaWMKICAgICAgICAgICAgICBLZXkg TWFuYWdlbWVudCIsIEJDUCAxMDcsIFJGQyA0MTA3LCBKdW5lIDIwMDUuCgogICBbUkZDNDI3MV0g IFJla2h0ZXIsIFkuLCBMaSwgVC4sIGFuZCBTLiBIYXJlcywgIkEgQm9yZGVyIEdhdGV3YXkKICAg ICAgICAgICAgICBQcm90b2NvbCA0IChCR1AtNCkiLCBSRkMgNDI3MSwgSmFudWFyeSAyMDA2LgoK ICAgW1JGQzQzMDFdICBLZW50LCBTLiBhbmQgSy4gU2VvLCAiU2VjdXJpdHkgQXJjaGl0ZWN0dXJl IGZvciB0aGUKICAgICAgICAgICAgICBJbnRlcm5ldCBQcm90b2NvbCIsIFJGQyA0MzAxLCBEZWNl bWJlciAyMDA1LgoKICAgW1JGQzQzMDNdICBLZW50LCBTLiwgIklQIEVuY2Fwc3VsYXRpbmcgU2Vj dXJpdHkgUGF5bG9hZCAoRVNQKSIsCiAgICAgICAgICAgICAgUkZDIDQzMDMsIERlY2VtYmVyIDIw MDUuCgogICBbUkZDNDMwNl0gIEthdWZtYW4sIEMuLCAiSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIChJ S0V2MikgUHJvdG9jb2wiLAogICAgICAgICAgICAgIFJGQyA0MzA2LCBEZWNlbWJlciAyMDA1LgoK ICAgW1JGQzQ2MDFdICBGZW5uZXIsIEIuLCBIYW5kbGV5LCBNLiwgSG9sYnJvb2ssIEguLCBhbmQg SS4gS291dmVsYXMsCiAgICAgICAgICAgICAgIlByb3RvY29sIEluZGVwZW5kZW50IE11bHRpY2Fz dCAtIFNwYXJzZSBNb2RlIChQSU0tU00pOgogICAgICAgICAgICAgIFByb3RvY29sIFNwZWNpZmlj YXRpb24gKFJldmlzZWQpIiwgUkZDIDQ2MDEsIEF1Z3VzdCAyMDA2LgoKICAgW1JGQzQ2MTVdICBT b25nLCBKLiwgUG9vdmVuZHJhbiwgUi4sIExlZSwgSi4sIGFuZCBULiBJd2F0YSwgIlRoZQogICAg ICAgICAgICAgIEFkdmFuY2VkIEVuY3J5cHRpb24gU3RhbmRhcmQtQ2lwaGVyLWJhc2VkIE1lc3Nh Z2UKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBDb2RlLVBzZXVkby1SYW5kb20gRnVuY3Rp b24tMTI4IChBRVMtQ01BQy0KICAgICAgICAgICAgICBQUkYtMTI4KSBBbGdvcml0aG0gZm9yIHRo ZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wKICAgICAgICAgICAgICAoSUtFKSIsIFJG QyA0NjE1LCBBdWd1c3QgMjAwNi4KCiAgIFtSRkM0OTQ5XSAgU2hpcmV5LCBSLiwgIkludGVybmV0 IFNlY3VyaXR5IEdsb3NzYXJ5LCBWZXJzaW9uIDIiLAogICAgICAgICAgICAgIFJGQyA0OTQ5LCBB dWd1c3QgMjAwNy4KCiAgIFtSRkM1MDM2XSAgQW5kZXJzc29uLCBMLiwgTWluZWksIEkuLCBhbmQg Qi4gVGhvbWFzLCAiTERQCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiIsIFJGQyA1MDM2LCBP Y3RvYmVyIDIwMDcuCgogICBbUkZDNTIyNl0gIE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQs ICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuCiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0 aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyA1MjI2LAogICAgICAgICAgICAgIE1h eSAyMDA4LgoKCgoKCgoKCgoKTGVib3ZpdHogJiAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkg OSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgNDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgS0FSUCBSb2FkbWFwICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA5CgoKQXV0 aG9ycycgQWRkcmVzc2VzCgogICBHcmVnb3J5IExlYm92aXR6CiAgIEp1bmlwZXIgTmV0d29ya3Ms IEluYy4KICAgMTE5NCBOb3J0aCBNYXRoaWxkYSBBdmUuCiAgIFN1bm55dmFsZSwgQ0EgIDk0MDg5 LTEyMDYKICAgVVMKCiAgIFBob25lOgogICBFbWFpbDogZ3JlZ29yeS5pZXRmQGdtYWlsLmNvbQoK CgoKICAgUGhvbmU6CiAgIEVtYWlsOgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CkxlYm92aXR6ICYgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMTAgICAgICAgICAg ICAgICAgIFtQYWdlIDQzXQoMCgo= --=====================_448520890==_-- From jmh@joelhalpern.com Wed Nov 4 15:37:50 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834433A6A42 for ; Wed, 4 Nov 2009 15:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSiq2nXkAivr for ; Wed, 4 Nov 2009 15:37:49 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C6F373A682B for ; Wed, 4 Nov 2009 15:37:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2DF41433C73 for ; Wed, 4 Nov 2009 15:38:12 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-240.clppva.btas.verizon.net [71.161.50.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B728F433C6B for ; Wed, 4 Nov 2009 15:38:11 -0800 (PST) Message-ID: <4AF21062.4010101@joelhalpern.com> Date: Wed, 04 Nov 2009 18:38:10 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 23:37:50 -0000 Held up due to who knows what confusion in the tools... -------- Original Message -------- Subject: re: Draft KARP BoF charter Date: Wed, 4 Nov 2009 15:30:07 -0500 From: Francois Le Faucheur To: karp@ietf.org CC: Le Faucheur Francois Hi, Here is a couple of small suggestions on the draft KARP BOF charter as per: http://www.ietf.org/mail-archive/web/karp/current/msg00049.html * I understand the KARP scope includes protocols that can easily be considered as "routing protocols" (e.g. BGP, OSPF, ISIS, ) as well as protocols that are not really "routing protocols" (e.g. RSVP-TE, LDP, BFD). Would it be appropriate to bring up in the charter another term for the "non-routing protocols"? Could the charter mention "routing protocols and signaling protocols"? * Can KARP aim at addressing RSVP in general (as opposed to just RSVP- TE)? Thanks. Francois PS: I didn't follow the KARP activity so apologies if this has already been discussed. From gregory.ietf@gmail.com Thu Nov 5 01:12:18 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5866128C1A9 for ; Thu, 5 Nov 2009 01:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b80wAyfmu1kF for ; Thu, 5 Nov 2009 01:12:17 -0800 (PST) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id B556F28C1A4 for ; Thu, 5 Nov 2009 01:12:16 -0800 (PST) Received: by pxi42 with SMTP id 42so5612919pxi.5 for ; Thu, 05 Nov 2009 01:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=qkYQ+VXWAWcqRfCXEvOEa6ix14Zw94YbH4WIPChzFlQ=; b=V7f5z2HXF04Xms6fkIzMmDgktI+gJ5Nid/d3dXLAFhwkeod264fytJoITWK3aWAym6 miHjsjnSdelAXmTKXRsUvm1iip4LM3tuxlO8K4l8hBWFG3ue7qgI5mNlvVXIDt77rhRL Lus1pVEq9BiVlw8XWIFX6/s5x0qaG/QkEWiDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=W/DmHr5TyhiA3/iS6vCiBF0O2EB1Q3335u+Qf6vniSK6gXUCbGNgzjOzUa1XooIBjD /5FXn4jV70Rcft9sPKKDOyrMK2E8bpEogJcB1FAmhilj+nGBo8IkCQWBiYvWgBi8/3bj lSMSXZRNx9gmppTvasxJke69+wtsP02YtJ+ms= Received: by 10.114.19.30 with SMTP id 30mr4528473was.134.1257412358286; Thu, 05 Nov 2009 01:12:38 -0800 (PST) Received: from Gregory-T60.gmail.com ([222.252.8.89]) by mx.google.com with ESMTPS id 20sm564152pxi.7.2009.11.05.01.12.33 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 01:12:36 -0800 (PST) Message-ID: <4af29704.141bf30a.23ab.404c@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Nov 2009 01:12:27 -0800 To: Francois Le Faucheur From: "Gregory M. Lebovitz" In-Reply-To: <4AF21062.4010101@joelhalpern.com> References: <4AF21062.4010101@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: karp@ietf.org Subject: Re: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 09:12:18 -0000 inline... >-------- Original Message -------- >Subject: re: Draft KARP BoF charter >Date: Wed, 4 Nov 2009 15:30:07 -0500 >From: Francois Le Faucheur >To: karp@ietf.org >CC: Le Faucheur Francois > >Hi, > >Here is a couple of small suggestions on the draft KARP BOF charter as >per: >http://www.ietf.org/mail-archive/web/karp/current/msg00049.html > >* I understand the KARP scope includes protocols that can easily be >considered as "routing protocols" (e.g. BGP, OSPF, ISIS, ) as well as >protocols that are not really "routing protocols" (e.g. RSVP-TE, LDP, >BFD). Would it be appropriate to bring up in the charter another term >for the "non-routing protocols"? Could the charter mention "routing >protocols and signaling protocols"? This seems like a very reasonable distinction to me. Anyone object? There may be two or three distinctions to make: - Routing Protocols - Signaling Protocols - Discovery Protocols Now, LDP and BGP and MDCP are a signaling, a routing and adiscovery protocol respectively. All run over TCP, with similar transaction models, so once we are done with TCP-AO, then we have succeeded in providing authentication for them all. It may be similar for some of the link-local broadcasting type protocols, which would include OSPF, IS-IS and PIM-SM, among others. >* Can KARP aim at addressing RSVP in general (as opposed to just RSVP- >TE)? "Can it?" is a question that could be read in many ways: - "Is it possible?" Sure, anything is possible, given enough time, money and resource, and we are smart people who can do anything we put our minds to. - "Should it be our first priority?" No, I don't think so. We have far more demand from the PIM and OSFP and IS-IS communities than I've heard from the RSVP community. And the threat landscape is much much broader for those than for RSVP. - "Should it be on the very first KARP charter?" Not sure. I can see the answer going either way. Personally, I'd rather see us charter narrowly, and succeed, then add more things to the charter, than to try to take on too much right at the start. - "Is there a good reason why -TE is there, but not RSVP in general?" This I don't know the answer to. Anyone else have the background or thoughts? Hope that helps, Gregory. >Thanks. > >Francois > >PS: I didn't follow the KARP activity so apologies if this has already >been discussed. >_______________________________________________ >karp mailing list >karp@ietf.org >https://www.ietf.org/mailman/listinfo/karp From jmh@joelhalpern.com Thu Nov 5 04:41:06 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6B13A6979 for ; Thu, 5 Nov 2009 04:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRgPKTVKYak1 for ; Thu, 5 Nov 2009 04:41:05 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 920813A68DA for ; Thu, 5 Nov 2009 04:41:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 69D5843009A; Thu, 5 Nov 2009 04:41:28 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-240.clppva.btas.verizon.net [71.161.50.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B0AD4430088; Thu, 5 Nov 2009 04:41:27 -0800 (PST) Message-ID: <4AF2C7F7.7060006@joelhalpern.com> Date: Thu, 05 Nov 2009 07:41:27 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <4AF21062.4010101@joelhalpern.com> <4af29704.141bf30a.23ab.404c@mx.google.com> In-Reply-To: <4af29704.141bf30a.23ab.404c@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Francois Le Faucheur , karp@ietf.org Subject: Re: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 12:41:06 -0000 My personal read on why RSVP-TE rather than just RSVP... RSVP is a host-to-host protocol that happens to be proxyable, and is processed by routers. RSVP-TE is a router-router protocol. Is that really a good reason for doing one and not the other? I have no idea. Joel Gregory M. Lebovitz wrote: ... >> * Can KARP aim at addressing RSVP in general (as opposed to just RSVP- >> TE)? > > "Can it?" is a question that could be read in many ways: > - "Is it possible?" Sure, anything is possible, given enough time, > money and resource, and we are smart people who can do anything we put > our minds to. > - "Should it be our first priority?" No, I don't think so. We have far > more demand from the PIM and OSFP and IS-IS communities than I've heard > from the RSVP community. And the threat landscape is much much broader > for those than for RSVP. > - "Should it be on the very first KARP charter?" Not sure. I can see > the answer going either way. Personally, I'd rather see us charter > narrowly, and succeed, then add more things to the charter, than to try > to take on too much right at the start. > - "Is there a good reason why -TE is there, but not RSVP in general?" > This I don't know the answer to. Anyone else have the background or > thoughts? > > Hope that helps, > Gregory. From gregory.ietf@gmail.com Thu Nov 5 09:47:55 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762F228C0D8 for ; Thu, 5 Nov 2009 09:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9pDFP8r0-qv for ; Thu, 5 Nov 2009 09:47:54 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id E36113A6869 for ; Thu, 5 Nov 2009 09:47:53 -0800 (PST) Received: by bwz23 with SMTP id 23so248116bwz.29 for ; Thu, 05 Nov 2009 09:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=t0UTAN0qzTYkdc2mLHbABYdZXPFjsD48b1XXYCG/0a8=; b=lKnCORwDJIDTgnCcYPkg5KLXBE0Ok2DRUCBFpaHHRBXlFGwxKkUs41hCY4KMXnwll+ a8CNHHQx41RbJM9iVLds/6h7e/WsQ9EEoC7Z2r71birkpXAtkGmT347G9oCPGoafiuwl zxemSAqYt04ThWrBiDZEFmsa3r5WZLELal1Mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=nlE3qnm5/xNAsi8iie2J24oL4E7NkvD084rg1snNfwDUsjfz6rMhYcEg0m304XsGzJ DV2FYH0Ejm8g+Rgbwj7dJTYHz/MOwqopbNMJ+6ryp0+T8WAxqQGXAe6IIU8Ev3KS5zf6 ypcxHFdVWmjaqHGR0gBpeCDwwZs3zoDB7q8G0= Received: by 10.204.26.130 with SMTP id e2mr3276045bkc.144.1257443294179; Thu, 05 Nov 2009 09:48:14 -0800 (PST) Received: from Gregory-T60.gmail.com ([58.187.113.237]) by mx.google.com with ESMTPS id 14sm777061bwz.9.2009.11.05.09.48.09 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 09:48:11 -0800 (PST) Message-ID: <4af30fdb.0e1abc0a.5431.5dab@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Nov 2009 09:48:02 -0800 To: Francois Le Faucheur , "Joel M. Halpern" From: "Gregory M. Lebovitz" In-Reply-To: <16ED8DE3-B4D3-4E23-AD94-0DB77AEFC13C@cisco.com> References: <4AF21062.4010101@joelhalpern.com> <4af29704.141bf30a.23ab.404c@mx.google.com> <4AF2C7F7.7060006@joelhalpern.com> <16ED8DE3-B4D3-4E23-AD94-0DB77AEFC13C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Le Faucheur Francois , karp@ietf.org Subject: Re: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:47:55 -0000 At 05:37 AM 11/5/2009, Francois Le Faucheur wrote: >Joel, Gregory, > >Let me clarify my input re RSVP: > * I have the impression that some of KARP general objectives of >modernizing/enhancing/facilitating-deployment of security for >routing/ signaling/discovery protocols are applicable to RSVP. Perhaps, this >could translate into a nice group keying solution among RSVP/RSVP-TE >routers (not sure about applicability to hosts). > * I personally would like to see that happen sooner than later. > * I understand there are competing priorities > * when RSVP-TE is considered by KARP, I recommend that RSVP is >considered at the same. If a common solution cannot be devised to >address all RSVP requirements (let's say because of the "host" aspect >brought up by Joel, just as an example), then I would suggest the WG >documents applicability & restrictions of the mechanism for RSVP (e.g. >continuing on with the previous example, that may be to limit >applicability of the KARP mechanism to securing RSVP on routers and >exclude Hosts). Francois, Speaking as an individual contributor here (i.e. not a BoF shepherd or any other role), I think your suggestion is 100% reasonable and support it. We did pretty much the same thing during the TCP-AO effort. Yes, TCP-AO could be used by hosts for any number of different applications. However, when we looked at the requirements and priorities and such we focused on the solution required to secure BGP/LDP/MSDP, and excluded every other application, where including it would have taken us into more requirements or different solution spaces. I understand you suggesting the same thing, i.e. in as much as we can solve authentication for RSVP while doing RSVP-TE, let's do so. Otherwise, we'll push it off until later. Gregory. >Thanks for considering this input. > >Francois > >On 5 Nov 2009, at 13:41, Joel M. Halpern wrote: > >>My personal read on why RSVP-TE rather than just RSVP... >>RSVP is a host-to-host protocol that happens to be proxyable, and is >>processed by routers. RSVP-TE is a router-router protocol. >> >>Is that really a good reason for doing one and not the other? I >>have no idea. >> >>Joel >> >>Gregory M. Lebovitz wrote: >>... >>>>* Can KARP aim at addressing RSVP in general (as opposed to just >>>>RSVP- >>>>TE)? >>>"Can it?" is a question that could be read in many ways: >>>- "Is it possible?" Sure, anything is possible, given enough time, >>>money and resource, and we are smart people who can do anything we >>>put our minds to. >>>- "Should it be our first priority?" No, I don't think so. We have >>>far more demand from the PIM and OSFP and IS-IS communities than >>>I've heard from the RSVP community. And the threat landscape is >>>much much broader for those than for RSVP. >>>- "Should it be on the very first KARP charter?" Not sure. I can >>>see the answer going either way. Personally, I'd rather see us >>>charter narrowly, and succeed, then add more things to the charter, >>>than to try to take on too much right at the start. >>>- "Is there a good reason why -TE is there, but not RSVP in >>>general?" This I don't know the answer to. Anyone else have the >>>background or thoughts? >>>Hope that helps, >>>Gregory. From gregory.ietf@gmail.com Thu Nov 5 09:51:29 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B94D3A69A4 for ; Thu, 5 Nov 2009 09:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or1G+tDm1vtF for ; Thu, 5 Nov 2009 09:51:28 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 011C23A683D for ; Thu, 5 Nov 2009 09:51:27 -0800 (PST) Received: by bwz23 with SMTP id 23so251707bwz.29 for ; Thu, 05 Nov 2009 09:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=xGp3gDBAscuu40Zew3CrDI2sceKcwOUwnNipMUzG82A=; b=FW+xfPmX9iWXdaoIy1OncMoUaifkNwkS0c0NITV6DewGvgvoZIrtqZ34qLrbpRpaAf COb58uxtbmJ8uaxy3qFjm9gtdyIv3EzM88jSBsFlO7QCIqz35Iah7DdSVLWazUBNCNOJ 6oDzvzu+bVWmpK4JraPIT6jyCSSIh7ucnXOwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=EpRmZ3naBJ5Zeztgiwgsu00K5WgMYwHH2yz99KlY6EA7zlsx2T39EXpKmXsIyDvg3C MYVXBXsjl4L7OX3H4ITiK3mW4USX4tIJ4qPJXXbHxcP/gO2iashajKY2HCAu2740dDe+ VTjEbfgBJwbGwDcLGlH1RD5Kp5y6nfATmQV74= Received: by 10.204.34.20 with SMTP id j20mr3375583bkd.57.1257443507486; Thu, 05 Nov 2009 09:51:47 -0800 (PST) Received: from Gregory-T60.gmail.com ([58.187.113.237]) by mx.google.com with ESMTPS id 15sm776487bwz.8.2009.11.05.09.51.44 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 09:51:47 -0800 (PST) Message-ID: <4af310b3.0f1abc0a.68f4.6098@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Nov 2009 09:51:39 -0800 To: Francois Le Faucheur From: "Gregory M. Lebovitz" In-Reply-To: <16ED8DE3-B4D3-4E23-AD94-0DB77AEFC13C@cisco.com> References: <4AF21062.4010101@joelhalpern.com> <4af29704.141bf30a.23ab.404c@mx.google.com> <4AF2C7F7.7060006@joelhalpern.com> <16ED8DE3-B4D3-4E23-AD94-0DB77AEFC13C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: karp@ietf.org Subject: Re: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 17:51:29 -0000 At 05:37 AM 11/5/2009, Francois Le Faucheur wrote: >Joel, Gregory, > >Let me clarify my input re RSVP: > * I have the impression that some of KARP general objectives of >modernizing/enhancing/facilitating-deployment of security for >routing/ signaling/discovery protocols are applicable to RSVP. Perhaps, this >could translate into a nice group keying solution among RSVP/RSVP-TE >routers (not sure about applicability to hosts). > * I personally would like to see that happen sooner than later. > * I understand there are competing priorities > * when RSVP-TE is considered by KARP, I recommend that RSVP is >considered at the same. If a common solution cannot be devised to >address all RSVP requirements (let's say because of the "host" aspect >brought up by Joel, just as an example), then I would suggest the WG >documents applicability & restrictions of the mechanism for RSVP (e.g. >continuing on with the previous example, that may be to limit >applicability of the KARP mechanism to securing RSVP on routers and >exclude Hosts). > >Thanks for considering this input. PART II - now let me ask a different question altogether: why should we spend time on RSVP-TE/RSVP at all? Why is it important to solve now? By way of prioritizing, what protocols do you believe is more important for us to focus on in KARP than it/them? (by answering the last question, anything you do not list as more important we will assume to be less important). Others please feel free to weigh in on this too. Gregory >Francois > >On 5 Nov 2009, at 13:41, Joel M. Halpern wrote: > >>My personal read on why RSVP-TE rather than just RSVP... >>RSVP is a host-to-host protocol that happens to be proxyable, and is >>processed by routers. RSVP-TE is a router-router protocol. >> >>Is that really a good reason for doing one and not the other? I >>have no idea. >> >>Joel >> >>Gregory M. Lebovitz wrote: >>... >>>>* Can KARP aim at addressing RSVP in general (as opposed to just >>>>RSVP- >>>>TE)? >>>"Can it?" is a question that could be read in many ways: >>>- "Is it possible?" Sure, anything is possible, given enough time, >>>money and resource, and we are smart people who can do anything we >>>put our minds to. >>>- "Should it be our first priority?" No, I don't think so. We have >>>far more demand from the PIM and OSFP and IS-IS communities than >>>I've heard from the RSVP community. And the threat landscape is >>>much much broader for those than for RSVP. >>>- "Should it be on the very first KARP charter?" Not sure. I can >>>see the answer going either way. Personally, I'd rather see us >>>charter narrowly, and succeed, then add more things to the charter, >>>than to try to take on too much right at the start. >>>- "Is there a good reason why -TE is there, but not RSVP in >>>general?" This I don't know the answer to. Anyone else have the >>>background or thoughts? >>>Hope that helps, >>>Gregory. From gregory.ietf@gmail.com Thu Nov 5 11:06:55 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB7F3A6859 for ; Thu, 5 Nov 2009 11:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWOzrkpPwbFx for ; Thu, 5 Nov 2009 11:06:54 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id CECF43A62C1 for ; Thu, 5 Nov 2009 11:06:53 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so1461664fgb.13 for ; Thu, 05 Nov 2009 11:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=5YUFmvyvPAPjCqoJQINMIBOI9IRPP6nCC0nysi3nY6M=; b=h6UFxykhRcrakltvvvhJIvLW4fCU/4QkbXgERb3oHow748Gx/e4OO9Li9HGzxVwDBL avP6SrlDGIbAlizs+DJYXBnS+h5gux/BB6Iz1t6QVT9FdCPKKoWdX7jlKcTIwm9ruMbK AJEx4cQzGTd3TnyHnp1T8+FR7qJf5Vv9R+w2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=CJ30r1EAvVKz6hD9K5NjC1S/Zui08hYMejXbLtZFuCIgNDcUZ0cKf+p0uioevR40Dv eq4BVfkcVNtpb90mCn1yU0w8Rl5PX6YXdypissj0fQ569o89ZT8DP4hL7gu+tGVzyei9 OpRa7Hr3GV7zP3pmzDOyetFC5NNjEmDYWtZPc= Received: by 10.86.106.13 with SMTP id e13mr1483015fgc.54.1257448033303; Thu, 05 Nov 2009 11:07:13 -0800 (PST) Received: from Gregory-T60.gmail.com ([58.187.113.237]) by mx.google.com with ESMTPS id e3sm4641222fga.8.2009.11.05.11.07.10 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 11:07:12 -0800 (PST) Message-ID: <4af32260.0338560a.1485.ffffb3a5@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Nov 2009 11:07:04 -0800 To: Francois Le Faucheur From: "Gregory M. Lebovitz" In-Reply-To: <4DB0BFA0-6352-42CE-875C-F1CFE254081B@cisco.com> References: <4AF21062.4010101@joelhalpern.com> <4af29704.141bf30a.23ab.404c@mx.google.com> <4AF2C7F7.7060006@joelhalpern.com> <16ED8DE3-B4D3-4E23-AD94-0DB77AEFC13C@cisco.com> <4af310b3.0f1abc0a.68f4.6098@mx.google.com> <4DB0BFA0-6352-42CE-875C-F1CFE254081B@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Francois Le Faucheur , karp@ietf.org Subject: Re: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 19:06:55 -0000 At 10:49 AM 11/5/2009, Francois Le Faucheur wrote: >On 5 Nov 2009, at 18:51, Gregory M. Lebovitz wrote: > >>At 05:37 AM 11/5/2009, Francois Le Faucheur wrote: >>>Joel, Gregory, >>> >>>Let me clarify my input re RSVP: >>> * I have the impression that some of KARP general objectives >>>of >>>modernizing/enhancing/facilitating-deployment of security for >>>routing/ signaling/discovery protocols are applicable to RSVP. >>>Perhaps, this >>>could translate into a nice group keying solution among RSVP/RSVP-TE >>>routers (not sure about applicability to hosts). >>> * I personally would like to see that happen sooner than >>>later. >>> * I understand there are competing priorities >>> * when RSVP-TE is considered by KARP, I recommend that RSVP is >>>considered at the same. If a common solution cannot be devised to >>>address all RSVP requirements (let's say because of the "host" aspect >>>brought up by Joel, just as an example), then I would suggest the WG >>>documents applicability & restrictions of the mechanism for RSVP >>>(e.g. >>>continuing on with the previous example, that may be to limit >>>applicability of the KARP mechanism to securing RSVP on routers and >>>exclude Hosts). >>> >>>Thanks for considering this input. >> >>PART II - now let me ask a different question altogether: why >>should we spend time on RSVP-TE/RSVP at all? > >RSVP-TE is deployed in many SP Core. >RSVP is deployed in some enterprise network and also considered by >some SP for Video reservation & admission control. >My perception is that in practice, the current RSVP security >mechanisms are not easily deployable because they depend on either >static key provisioning (which is operationally painful) or IKE key >negotiation (which is somewhat heavy for some). An easy-to-deploy >option (e.g. some dynamic group key distribution approach) would be a >good practical step forward. > >>Why is it important to solve now? > >I would personally like this problem to be solved now because it would >increase the security of the current deployments I talked about above. >Now, I won't argue that it is the most important security painpoint to >solve. It is not. > >I seem to remember from a cursory scan of the KARP archive that >someone (or perhaps it was even in the charter) argued that there is >higher priority/urgency to enhance security at trust boundaries as >compared to enhance security within a trust domain because the inner >of the trust domain can always be somewhat protected/isolated from the >evil outside world via conventional protection mechanism (while a >device at the edge of the trust domain is fully exposed). That seems >like a reasonable argument to me. If that logic is followed by the >working group, it would suggest that RSVP/RSVP-TE be taken on in the >lower priority batch, since the deployments are currently >predominantly intra-domain. (I know I'm pushing a bit here, I hope you don't mind...) And what other intra-domain protocols would you place ahead of it, if any? OSPF? IS-IS? RIP? Gregory. >Francois > > >>By way of prioritizing, what protocols do you believe is more >>important for us to focus on in KARP than it/them? (by answering the >>last question, anything you do not list as more important we will >>assume to be less important). >> >>Others please feel free to weigh in on this too. >> >>Gregory >> >> >>>Francois >>> >>>On 5 Nov 2009, at 13:41, Joel M. Halpern wrote: >>> >>>>My personal read on why RSVP-TE rather than just RSVP... >>>>RSVP is a host-to-host protocol that happens to be proxyable, and is >>>>processed by routers. RSVP-TE is a router-router protocol. >>>> >>>>Is that really a good reason for doing one and not the other? I >>>>have no idea. >>>> >>>>Joel >>>> >>>>Gregory M. Lebovitz wrote: >>>>... >>>>>>* Can KARP aim at addressing RSVP in general (as opposed to just >>>>>>RSVP- >>>>>>TE)? >>>>>"Can it?" is a question that could be read in many ways: >>>>>- "Is it possible?" Sure, anything is possible, given enough time, >>>>>money and resource, and we are smart people who can do anything we >>>>>put our minds to. >>>>>- "Should it be our first priority?" No, I don't think so. We have >>>>>far more demand from the PIM and OSFP and IS-IS communities than >>>>>I've heard from the RSVP community. And the threat landscape is >>>>>much much broader for those than for RSVP. >>>>>- "Should it be on the very first KARP charter?" Not sure. I can >>>>>see the answer going either way. Personally, I'd rather see us >>>>>charter narrowly, and succeed, then add more things to the charter, >>>>>than to try to take on too much right at the start. >>>>>- "Is there a good reason why -TE is there, but not RSVP in >>>>>general?" This I don't know the answer to. Anyone else have the >>>>>background or thoughts? >>>>>Hope that helps, >>>>>Gregory. From flefauch@cisco.com Wed Nov 4 12:29:49 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA833A67B3 for ; Wed, 4 Nov 2009 12:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C8UCBAKFNR6 for ; Wed, 4 Nov 2009 12:29:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A9FF73A63D3 for ; Wed, 4 Nov 2009 12:29:48 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,682,1249257600"; d="scan'208";a="53645409" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2009 20:30:09 +0000 Received: from ams-flefauch-8717.cisco.com (ams-flefauch-8717.cisco.com [10.55.161.200]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4KU9IB012486; Wed, 4 Nov 2009 20:30:09 GMT Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <4B7942DC-6925-4901-A321-DDFF4617FD20@cisco.com> Date: Wed, 4 Nov 2009 21:30:07 +0100 To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Sat, 07 Nov 2009 03:19:39 -0800 Cc: Le Faucheur Francois Subject: Re: [karp] Draft KARP BoF charter X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:29:49 -0000 Hi, Here is a couple of small suggestions on the draft KARP BOF charter as per: http://www.ietf.org/mail-archive/web/karp/current/msg00049.html * I understand the KARP scope includes protocols that can easily be considered as "routing protocols" (e.g. BGP, OSPF, ISIS, ) as well as protocols that are not really "routing protocols" (e.g. RSVP-TE, LDP, BFD). Would it be appropriate to bring up in the charter another term for the "non-routing protocols"? Could the charter mention "routing protocols and signaling protocols"? * Can KARP aim at addressing RSVP in general (as opposed to just RSVP- TE)? Thanks. Francois PS: I didn't follow the KARP activity so apologies if this has already been discussed. From flefauch@cisco.com Thu Nov 5 05:37:35 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5BE28C1B9 for ; Thu, 5 Nov 2009 05:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X19kE1wDGuTd for ; Thu, 5 Nov 2009 05:37:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 375A528C1B8 for ; Thu, 5 Nov 2009 05:37:34 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,686,1249257600"; d="scan'208";a="53708731" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2009 13:37:55 +0000 Received: from [144.254.53.136] ([144.254.53.136]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA5DbsNa000779; Thu, 5 Nov 2009 13:37:54 GMT References: <4AF21062.4010101@joelhalpern.com> <4af29704.141bf30a.23ab.404c@mx.google.com> <4AF2C7F7.7060006@joelhalpern.com> In-Reply-To: <4AF2C7F7.7060006@joelhalpern.com> Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <16ED8DE3-B4D3-4E23-AD94-0DB77AEFC13C@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Thu, 5 Nov 2009 14:37:52 +0100 To: "Joel M. Halpern" , "Gregory M. Lebovitz" X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Sat, 07 Nov 2009 03:19:39 -0800 Cc: Le Faucheur Francois , karp@ietf.org Subject: Re: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 13:37:35 -0000 Joel, Gregory, Let me clarify my input re RSVP: * I have the impression that some of KARP general objectives of modernizing/enhancing/facilitating-deployment of security for routing/ signaling/discovery protocols are applicable to RSVP. Perhaps, this could translate into a nice group keying solution among RSVP/RSVP-TE routers (not sure about applicability to hosts). * I personally would like to see that happen sooner than later. * I understand there are competing priorities * when RSVP-TE is considered by KARP, I recommend that RSVP is considered at the same. If a common solution cannot be devised to address all RSVP requirements (let's say because of the "host" aspect brought up by Joel, just as an example), then I would suggest the WG documents applicability & restrictions of the mechanism for RSVP (e.g. continuing on with the previous example, that may be to limit applicability of the KARP mechanism to securing RSVP on routers and exclude Hosts). Thanks for considering this input. Francois On 5 Nov 2009, at 13:41, Joel M. Halpern wrote: > My personal read on why RSVP-TE rather than just RSVP... > RSVP is a host-to-host protocol that happens to be proxyable, and is > processed by routers. RSVP-TE is a router-router protocol. > > Is that really a good reason for doing one and not the other? I > have no idea. > > Joel > > Gregory M. Lebovitz wrote: > ... >>> * Can KARP aim at addressing RSVP in general (as opposed to just >>> RSVP- >>> TE)? >> "Can it?" is a question that could be read in many ways: >> - "Is it possible?" Sure, anything is possible, given enough time, >> money and resource, and we are smart people who can do anything we >> put our minds to. >> - "Should it be our first priority?" No, I don't think so. We have >> far more demand from the PIM and OSFP and IS-IS communities than >> I've heard from the RSVP community. And the threat landscape is >> much much broader for those than for RSVP. >> - "Should it be on the very first KARP charter?" Not sure. I can >> see the answer going either way. Personally, I'd rather see us >> charter narrowly, and succeed, then add more things to the charter, >> than to try to take on too much right at the start. >> - "Is there a good reason why -TE is there, but not RSVP in >> general?" This I don't know the answer to. Anyone else have the >> background or thoughts? >> Hope that helps, >> Gregory. From flefauch@cisco.com Thu Nov 5 10:49:22 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C0A3A691D for ; Thu, 5 Nov 2009 10:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyFEJa8BZelV for ; Thu, 5 Nov 2009 10:49:21 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5E79D3A63EB for ; Thu, 5 Nov 2009 10:49:21 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,687,1249257600"; d="scan'208";a="53741232" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2009 18:49:43 +0000 Received: from [144.254.53.136] ([144.254.53.136]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA5IngFf002980; Thu, 5 Nov 2009 18:49:42 GMT References: <4AF21062.4010101@joelhalpern.com> <4af29704.141bf30a.23ab.404c@mx.google.com> <4AF2C7F7.7060006@joelhalpern.com> <16ED8DE3-B4D3-4E23-AD94-0DB77AEFC13C@cisco.com> <4af310b3.0f1abc0a.68f4.6098@mx.google.com> In-Reply-To: <4af310b3.0f1abc0a.68f4.6098@mx.google.com> Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <4DB0BFA0-6352-42CE-875C-F1CFE254081B@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Thu, 5 Nov 2009 19:49:42 +0100 To: "Gregory M. Lebovitz" X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Sat, 07 Nov 2009 03:19:39 -0800 Cc: Francois Le Faucheur , karp@ietf.org Subject: Re: [karp] [Fwd: re: Draft KARP BoF charter] X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 18:49:23 -0000 On 5 Nov 2009, at 18:51, Gregory M. Lebovitz wrote: > At 05:37 AM 11/5/2009, Francois Le Faucheur wrote: >> Joel, Gregory, >> >> Let me clarify my input re RSVP: >> * I have the impression that some of KARP general objectives >> of >> modernizing/enhancing/facilitating-deployment of security for >> routing/ signaling/discovery protocols are applicable to RSVP. >> Perhaps, this >> could translate into a nice group keying solution among RSVP/RSVP-TE >> routers (not sure about applicability to hosts). >> * I personally would like to see that happen sooner than >> later. >> * I understand there are competing priorities >> * when RSVP-TE is considered by KARP, I recommend that RSVP is >> considered at the same. If a common solution cannot be devised to >> address all RSVP requirements (let's say because of the "host" aspect >> brought up by Joel, just as an example), then I would suggest the WG >> documents applicability & restrictions of the mechanism for RSVP >> (e.g. >> continuing on with the previous example, that may be to limit >> applicability of the KARP mechanism to securing RSVP on routers and >> exclude Hosts). >> >> Thanks for considering this input. > > PART II - now let me ask a different question altogether: why > should we spend time on RSVP-TE/RSVP at all? RSVP-TE is deployed in many SP Core. RSVP is deployed in some enterprise network and also considered by some SP for Video reservation & admission control. My perception is that in practice, the current RSVP security mechanisms are not easily deployable because they depend on either static key provisioning (which is operationally painful) or IKE key negotiation (which is somewhat heavy for some). An easy-to-deploy option (e.g. some dynamic group key distribution approach) would be a good practical step forward. > Why is it important to solve now? I would personally like this problem to be solved now because it would increase the security of the current deployments I talked about above. Now, I won't argue that it is the most important security painpoint to solve. It is not. I seem to remember from a cursory scan of the KARP archive that someone (or perhaps it was even in the charter) argued that there is higher priority/urgency to enhance security at trust boundaries as compared to enhance security within a trust domain because the inner of the trust domain can always be somewhat protected/isolated from the evil outside world via conventional protection mechanism (while a device at the edge of the trust domain is fully exposed). That seems like a reasonable argument to me. If that logic is followed by the working group, it would suggest that RSVP/RSVP-TE be taken on in the lower priority batch, since the deployments are currently predominantly intra-domain. Francois > By way of prioritizing, what protocols do you believe is more > important for us to focus on in KARP than it/them? (by answering the > last question, anything you do not list as more important we will > assume to be less important). > > Others please feel free to weigh in on this too. > > Gregory > > >> Francois >> >> On 5 Nov 2009, at 13:41, Joel M. Halpern wrote: >> >>> My personal read on why RSVP-TE rather than just RSVP... >>> RSVP is a host-to-host protocol that happens to be proxyable, and is >>> processed by routers. RSVP-TE is a router-router protocol. >>> >>> Is that really a good reason for doing one and not the other? I >>> have no idea. >>> >>> Joel >>> >>> Gregory M. Lebovitz wrote: >>> ... >>>>> * Can KARP aim at addressing RSVP in general (as opposed to just >>>>> RSVP- >>>>> TE)? >>>> "Can it?" is a question that could be read in many ways: >>>> - "Is it possible?" Sure, anything is possible, given enough time, >>>> money and resource, and we are smart people who can do anything we >>>> put our minds to. >>>> - "Should it be our first priority?" No, I don't think so. We have >>>> far more demand from the PIM and OSFP and IS-IS communities than >>>> I've heard from the RSVP community. And the threat landscape is >>>> much much broader for those than for RSVP. >>>> - "Should it be on the very first KARP charter?" Not sure. I can >>>> see the answer going either way. Personally, I'd rather see us >>>> charter narrowly, and succeed, then add more things to the charter, >>>> than to try to take on too much right at the start. >>>> - "Is there a good reason why -TE is there, but not RSVP in >>>> general?" This I don't know the answer to. Anyone else have the >>>> background or thoughts? >>>> Hope that helps, >>>> Gregory. > From gregory.ietf@gmail.com Sat Nov 7 04:12:07 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FE43A689E for ; Sat, 7 Nov 2009 04:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttxH6SFIr3fu for ; Sat, 7 Nov 2009 04:12:06 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 713243A6774 for ; Sat, 7 Nov 2009 04:12:06 -0800 (PST) Received: by pzk42 with SMTP id 42so1426698pzk.31 for ; Sat, 07 Nov 2009 04:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:mime-version:content-type; bh=RTigKZiMdExSMo5A+uYddAnLuDQltGQTeJDJe2XLA3Q=; b=GhDaeAUdT+L5VnycqSN8/SytkhPvp9gIGxP4aQ0tyB8hsV5Yz9/qrWlT8gu5V4S1QQ jctzc0S8cukwBS9G67IEhkfmsRTBuFsrJFS4IustTWaKmuYhUKuWzKB7ZSsy3B3NnNh2 jORNRGnP0zMvn579XFqmvWca/dkSlPdId3RrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:mime-version :content-type; b=cOp1btBKZYREvbmO7OZ39DA2GMfeQJKLIuyqHxBygiY/mbB6PxSG5p2Jn4zcgDdY0J Hijc27e8ReELibvkwVWREXpDu1wuHMSqmZE478UBKSbAPMcomdeCW8kw7botb0fNLLG4 5Rh4MV4w4MZ96Np95oVFThLw0szbdGE2Ve8y4= Received: by 10.115.102.9 with SMTP id e9mr8694827wam.199.1257595947527; Sat, 07 Nov 2009 04:12:27 -0800 (PST) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id 20sm573570pzk.1.2009.11.07.04.12.24 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Nov 2009 04:12:26 -0800 (PST) Message-ID: <4af5642a.9413f30a.08c9.55f1@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Nov 2009 04:12:20 -0800 To: Ross Callon , "Joel M. Halpern" ,Brian Weis From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_678544109==.ALT" Cc: karp@ietf.org Subject: [karp] karp - update bof page, with vital signs X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 12:12:07 -0000 --=====================_678544109==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hey guys, Here are some changes I hope we can make asap to the KARP bof page: - link to agenda - http://www.ietf.org/proceedings/09nov/agenda/karp.html - link to most current draft-lebovitz-kmart-roadmap-03 (http://www.ietf.org/mail-archive/web/karp/current/msg00072.html ) - change mailing list link from a "mailto:" command, to the actual mailman link: https://www1.ietf.org/mailman/listinfo/karp Anyone able to take the token for updating these ASAP? (cc:'ing list, so at least those on list will have everything consolidated) Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_678544109==.ALT Content-Type: text/html; charset="us-ascii" Hey guys,
Here are some changes I hope we can make asap to the KARP bof page:
- link to agenda - http://www.ietf.org/proceedings/09nov/agenda/karp.html
- link to most current draft-lebovitz-kmart-roadmap-03 ( http://www.ietf.org/mail-archive/web/karp/current/msg00072.html )
- change mailing list link from a "mailto:" command, to the actual mailman link: https://www1.ietf.org/mailman/listinfo/karp

Anyone able to take the token for updating these ASAP? (cc:'ing list, so at least those on list will have everything consolidated)

Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_678544109==.ALT-- From jmh@joelhalpern.com Sun Nov 8 16:14:09 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23A83A68E7 for ; Sun, 8 Nov 2009 16:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZeM2++vM+61 for ; Sun, 8 Nov 2009 16:14:09 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3000F3A6839 for ; Sun, 8 Nov 2009 16:14:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 426BA437E53; Sun, 8 Nov 2009 16:14:35 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [133.93.18.245] (host-18-245.meeting.ietf.org [133.93.18.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B9259437E4A; Sun, 8 Nov 2009 16:14:34 -0800 (PST) Message-ID: <4AF75EEA.10307@joelhalpern.com> Date: Sun, 08 Nov 2009 19:14:34 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [karp] Volunteers X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 00:14:09 -0000 We are meeting Tuesday morning, in Orchid East. We have a good selection of presentations, and will then be discussing the charter. We will need at least one minute taker, and should have at least one jabber scribe. We would like to have these lined up in advance. If you are willing to help out, please contact either or both of Brian and myself to volunteer. Thank you, Joel M. Halpern w/ Brian Weis From gregory.ietf@gmail.com Sun Nov 8 17:47:20 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7443A68CC for ; Sun, 8 Nov 2009 17:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJrju2bbtfUg for ; Sun, 8 Nov 2009 17:47:19 -0800 (PST) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 993EF3A6823 for ; Sun, 8 Nov 2009 17:47:19 -0800 (PST) Received: by gxk4 with SMTP id 4so2657466gxk.8 for ; Sun, 08 Nov 2009 17:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:mime-version:content-type; bh=1lABhCYKrmgFNsSHXRGNKcTPNlCPg5iepFxMikwNAfA=; b=iUV5+5D518KPhBmPUDSopf6J1kqNc45pR/2WLqNJn/hKxYlIrhejkxV74qfN7joKcU M49dHO/DE68DAQ+P3rJ6ihSP6EypAJVU+Z5fjfnC6L3tuiEAOuO5jy1gkflclDe6U0XJ WdcBkFIxGKlr7V0oCbyf1Me/IjhfcItcvgyt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:mime-version :content-type; b=Cm7/f9Rtr9t3z4LMZy1Jvd3oIS5aPRhJVl5+6BX3/S8hT7JGi00pJzlOmoum5sjofF o1oIvOPjBvs+MSP6NyXY6H/JhTaS2gIx3eJQEbcYnPsgoI3GWx0qFP9UTaY5GHjOdcQU o+yCN4UymGo0toQ8zKgQUnUiGTV4XnIpNx2c0= Received: by 10.150.26.5 with SMTP id 5mr12215405ybz.135.1257731262688; Sun, 08 Nov 2009 17:47:42 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 15sm1215394gxk.8.2009.11.08.17.47.39 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 17:47:41 -0800 (PST) Message-ID: <4af774bd.0f0bca0a.3d00.3a72@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Nov 2009 17:47:34 -0800 To: Ross Callon From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_813860250==.ALT" Cc: karp@ietf.org Subject: [karp] KARP Mailing List Info Link, update on BoF page X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:47:20 -0000 --=====================_813860250==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Ross, Could you pls asap make the following change on the BoF page at: http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 The mailing list link is currently a "mailto:" for karp@ietf.org, but I think it should actually be a link to the mailing list mail man info page at: https://www.ietf.org/mailman/listinfo/karp Could you pls make this change asap? Brian and Joel say they don't have access to edit that page. Thx, Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_813860250==.ALT Content-Type: text/html; charset="us-ascii" Ross,
Could you pls asap make the following change on the BoF page at:
     http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76

The mailing list link is currently a "mailto:" for karp@ietf.org, but I think it should actually be a link to the mailing list mail man info page at:
  https://www.ietf.org/mailman/listinfo/karp
   
Could you pls make this change asap? Brian and Joel say they don't have access to edit that page.

Thx,
Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_813860250==.ALT-- From gregory.ietf@gmail.com Sun Nov 8 18:01:19 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3CE3A6841 for ; Sun, 8 Nov 2009 18:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=-3.074, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_BOUND_EQ_REL=2.832] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14zdEg7mhngG for ; Sun, 8 Nov 2009 18:01:17 -0800 (PST) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 134403A67A8 for ; Sun, 8 Nov 2009 18:01:16 -0800 (PST) Received: by gxk4 with SMTP id 4so2665206gxk.8 for ; Sun, 08 Nov 2009 18:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer :x-priority:date:to:from:subject:mime-version:content-type; bh=0saq8E9FKg0fMYQM5HPj/D+M9Gue0Ygk6kPcpRL6bsY=; b=VqzH96fKKf50iXJe5taZogNcYtM4LZLx2sArWr6qaI/4TtJZ9map6u96YNldCm3D+w m8hbjOVccE52VG+ZzD41X+EaG7N3tqUyhclMta+ul9LwWbJOjHDOYj2n2m6m18IBYeFo q9qFo+hR2bBmPiEHmtyPRII1RyKw15mfuWa08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:x-priority:date:to:from:subject:mime-version :content-type; b=YtwXDbRn87Ofw24Mv8KKqjUNPhBHXkc9FhgtpiL7ZSXXEDZGKjvcnTZmpZNECoHJUv G+/kLHUBSNFJ29P4IsEarWmmEDpGk4P3t5Q3D0srTEbSQucKbpH93kMigGNi98Z6OzAx CZXhBXYPAuYFwNQQHie1Cyq23zdkFtTAZ6lwE= Received: by 10.150.17.37 with SMTP id 37mr5899322ybq.285.1257732099711; Sun, 08 Nov 2009 18:01:39 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 15sm1217674gxk.12.2009.11.08.18.01.35 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 18:01:38 -0800 (PST) Message-ID: <4af77802.0f0bca0a.3f87.39db@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 X-Priority: 5 (Lowest) Date: Sun, 08 Nov 2009 18:01:30 -0800 To: karp@ietf.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_814695437==.REL" Subject: [karp] The Hiroshima Toyo Carp baseball team X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:01:19 -0000 --=====================_814695437==.REL Content-Type: multipart/alternative; boundary="=====================_814695437==.ALT" --=====================_814695437==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Ironically, the Nippon Baseball League's local team here in Hiroshima is the Hiroshima Toyo Carp. Ok, so they misspelled they use a "C" instead of a "K", but close enough for us. Here's the key info: Hiroshima (Japanese character) [] HiroshimaCarp.png http://en.wikipedia.org/wiki/Hiroshima_Toyo_Carp From Japanball.com: Only five years after Hiroshima was destroyed by an atomic bomb, the city got it's own baseball team, a source of pride and a symbol of the city's determination to rebuild. But it took a lot longer for the Carp, who were established in 1950, to win their first pennant. In their first 25 seasons, the Carp never finished higher than third place. But in 1975, Hiroshima turned things around. With Koji Yamamoto (536 career home runs) and Sachio Kinugasa (2215 consecutive games) leading the team's offense, the Carp surged to first place, capturing their first Central League title. Though they lost the 1975 Japan Series, Hiroshima has six pennants. Inviting immediate comparison to the Cincinnati Reds, the Carp wear crimson and white jerseys and share an identical cap with their Midwest counterpart. Partly owned by the City of Hiroshima and Toyo, a car manufacturing company, the Carp may be one of the poorest ball clubs in Japan. Because the team reportedly has a low salary benchmark above which it refuses to go, the Carp tend to rarely negotiate with free agents or sign high-priced foreign players. Unable or unwilling to purchase any high-profile players, the Carp have invested their meager funds in developing younger players and in setting up a baseball academy in the Dominican Republic. Not surprisingly, many of the team's foreign players come from Latin America. Bored with pitchers' duels? Enjoy watching a lot of action and home runs? If so, the Hiroshima Carp are your team. Hiroshima's sluggers take advantage of their home ballpark's shallow outfield walls. Hiroshima Municipal Stadium (capacity 32,000) is located across the street from the city's most famous landmark, the A-Bomb Dome, which is visible just beyond the park's third base bleachers. The smallest ballpark in Japan, it offers seats that are close to the action, a natural grass outfield, bullpens down the foul lines and a new high-tech scoreboard. The shallow outfield fences make this the best park for fans seeking to catch a home run ball. This is a cozy old-fashioned ballpark for you to enjoy...but bring your own food, there's not much to select from at the park. Why the team picked a Philadelphia Phillie Phanatic-clone instead of a carp for a mascot remains a mystery. But fans don't seem to care. Filling Hiroshima Stadium, Carp fans come in one flavor: rabid. Possibly the most energetic in Japan, Hiroshima's cheering section repeats one hypnotic cheer for all their players. It's fun to watch and even more fun to join. Even if you can't see a Carp game in Hiroshima, their fans almost always fill the left-field bleachers at all the Tokyo and Osaka Central League ballparks. Acknowledgment: Dan Latham Hiroshima Toyo Carp Baseball Jersey Hiroshima Toyo Carp Baseball Jersey Emacs! +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_814695437==.ALT Content-Type: text/html; charset="us-ascii" Ironically, the Nippon Baseball League's local team here in Hiroshima is the Hiroshima Toyo Carp. Ok, so they misspelled they use a "C" instead of a "K", but close enough for us. Here's the key info:

Hiroshima (Japanese character)   []


HiroshimaCarp.png  

http://en.wikipedia.org/wiki/Hiroshima_Toyo_Carp

From Japanball.com:
Only five years after Hiroshima was destroyed by an atomic bomb, the city got it's own baseball team, a source of pride and a symbol of the city's determination to rebuild.  But it took a lot longer for the Carp, who were established in 1950, to win their first pennant.

In their first 25 seasons, the Carp never finished higher than third place. But in 1975, Hiroshima turned things around.  With Koji Yamamoto (536 career home runs) and Sachio Kinugasa (2215 consecutive games) leading the team's offense, the Carp surged to first place, capturing their first Central League title.  Though they lost the 1975 Japan Series, Hiroshima has six pennants.

Inviting immediate comparison to the Cincinnati Reds, the Carp wear crimson and white jerseys and share an identical cap with their Midwest counterpart.

Partly owned by the City of Hiroshima and Toyo, a car manufacturing company, the Carp may be one of the poorest ball clubs in Japan.  Because the team reportedly has a low salary benchmark above which it refuses to go, the Carp tend to rarely negotiate with free agents or sign high-priced foreign players.

Unable or unwilling to purchase any high-profile players, the Carp have invested their meager funds in developing younger players and in setting up a baseball academy in the Dominican Republic.  Not surprisingly, many of the team's foreign players come from Latin America.

Bored with pitchers' duels?  Enjoy watching a lot of action and home runs?  If so, the Hiroshima Carp are your team.  Hiroshima's sluggers take advantage of their home ballpark's shallow outfield walls.

Hiroshima Municipal Stadium (capacity 32,000) is located across the street from the city's most famous landmark, the A-Bomb Dome, which is visible just beyond the park's third base bleachers.

The smallest ballpark in Japan, it offers seats that are close to the action, a natural grass outfield, bullpens down the foul lines and a new high-tech scoreboard.  The shallow outfield fences make this the best park for fans seeking to catch a home run ball.  This is a cozy old-fashioned ballpark for you to enjoy...but bring your own food, there's not much to select from at the park.

Why the team picked a Philadelphia Phillie Phanatic-clone instead of a carp for a mascot remains a mystery.  But fans don't seem to care. Filling Hiroshima Stadium, Carp fans come in one flavor: rabid. Possibly the most energetic in Japan, Hiroshima's cheering section repeats one hypnotic cheer for all their players.  It's fun to watch and even more fun to join.

Even if you can't see a Carp game in Hiroshima, their fans almost always fill the left-field bleachers at all the Tokyo and Osaka Central League ballparks.

Acknowledgment: Dan Latham

 Hiroshima Toyo Carp Baseball Jersey Hiroshima Toyo Carp Baseball Jersey Emacs! 

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_814695437==.ALT-- --=====================_814695437==.REL Content-Type: application/octet-stream; name="308f3d37.jpg" Content-ID: <.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="308f3d37.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAHgAeADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACikyM47gZ+naloA KKM849gfzz/hUaEsScnA4x2znk/X1+vagCSiiigAopoySTn5TwPw4yPbrSjPc5/DFAC0UZGcd8Z/ CmBiWOOVA6jH3hjj6/jQA+iiigAopMjOO45/z+dLQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRSE 4IHrn9KWgBGOAT/nrTVYscEDGM598+n+eRQ44B9P61BbtvMjDpuKj3CnBIIzken4jigaV032t+Ja opCdoJOcD0BJ/ICs7ULiSGDEJImmkiijYqxVDO4QM4UMwRT97aGZVqJtq1n3/QIxcnZFqKQy5dSM HOAR2yAM8/y64qcDAA9KiijEYAUALjAA4/Hpz0qTJHUdjkg8DBGOM98n3457VYO13bboNkfYBjGW OB9c+mOlKCQAABkAbhnoT+Prmq0b+fKzYPlxNtUngM67t2OeQp+XoPmVun8VonHbk9MdyATjP0HG cUEv3b37/jb/AIA0lwDgKMc89MDk9D6cVFJPtKKhUvLzGDnG0DLFsHnAye3T1pzzRrG7s6qqqzFi y42IMu3BPCgHd7D0rPsZDdj7YVYRzjNqMoxNueY5wFdlCTJiZR/rNrqGVWytBUdU5NaL197s/L/K 2juaSEjCgDA/QfnTyQuT3JA/HGf5elOAA4FUL29hs4jLNJtVnWGNQjySSzOCUjhhjVpJ5GwzbYVZ 9qM23bGzKErV+XlbW/37fjfy1dLK7OsKEB2wxOD9wE55zjPXtVpcAAJg4IB/qfrke9VbWN/L3zFf NfmQr2boFGR91QAuP7warbHaMnJ6DAGSzEgDAHTnv0UfMxABNBUrL4buy+9/1/THDPcY9utRySLG OT8x+6vc/hUVxcx28TTSPsjQEuxGdvIGDgHnJCj3PXvVeHMxWd1ZXYMURsFgmeGIB2jI+b1GRxu+ WgErq70XX17FyNW5duGbqO3f2+n/AOqpaKjMiglTn0zjjPcfXGD6f98tgESUmRnbnnBbHtkf48VA Jd3CtlieMjHccfocZHzA71+WplUL9T1P9PpQA6iijPX26/zoAKKQEHoQfoc0tABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRTJG2qTj Pb86AH0UA5APqM0mRnHc0m7JvsBGG3SkAghQMjnKll3An/eB7/8A6nhsD5jz0P5n0+lU7Z/Me5ly MCd4QM4H7lvKzkdODx9atEKBg55P8u/6/wD1qE7pPuJ36Wv5le8nEFrNKBloo2dVz95gDtUY6k46 L3I96W2QxxogIwqKNx4L8cnGOOnWsrU3WW+0nT8TAXN1JdCWM7VQ6aqXAWU45jlLBNv8Q+mRtAAg DqQoJPZie4Pop5/pSUr30/l/8mNJe7TjbVz97f7O34tO33vYkJHc4+n4H09x/nNcok6ap4hdYX3w aBEyPJDMcJqWoIHltrqJkXLR2MlrdW+3cq+erbs/Kuxqt/HpemXuoSK0qWVrPO0SffmaGMssMTE4 8yZgsUf96R1H+zXN+CIZl0C31O+Ep1DXXk128F1bJZ3tvHqjteWOnXscaR77nSNOltNHdmVWcWQZ /nDVM949dVdaae8tX+np3LpwSozqyum5xp09dJTaTmm9NVG+zXxR6XO4XoPoP5VSvZ/KjIUFpWKp EikBpHdWAVScYKjdJ/wA1dyAB2BwB+PSsQMt1qE7ggw2JMK/MxJvZFVpsqTtBt4hF5bL2nk5q27N Lvf8DOCTb5tEldP7vzehpW0PkQxqxBKgbyBw7ty79f4nJbp34qdiACzEqCVGeOPmwvT1JGevWkGS CBg5AYd15wcZ44/u+3fisbXtXtNC0y51G7eLZCsccEckyQ/aryeRLexso3k+UT3t5LBa26/xXM0S rliBSbaTta60Udr/AAtLp/l9yuowdSpGMU5TlKNlvzSeiVtui8rLzKd9Mb2+j0WEsAIxcaoyrgQ2 u9vs8G/I8ua+kR2VkWRfLtZlk2lo93QxKFVVUKAAQFHRV/uJhVUKoG1McbQPpXP+HbCe1tvtV+Fb U9TkN7qEiNLsSaVVEUMKXEkskEUMCRxtbxssCzJNNHGrzMB0xGAMYwB1Oc5/Afn6800/dTas7a3/ AK/Lcuu0n7ODTUdJS6Sa0m427bRvrZK+zIpJEijZ2ZUVVLOzMFVUALszMxCqFXJYs2FAOWrmtOkf WbhdajmWTTE8yLSo44m2zKSEn1CRpgknmM6mG2VYY/s8aXEnmXMd0vl5Gr376/rjeE9Ou7cQ2SQX XiqRNlzLBY3CNLZ6QYWLQ29zrKFXka6idZtIW+8hUuPImh7mFI440jQGNIwqIm3aFRBtRQoxtCgb VHZccAUouTbTVkkv6/rTZdy5RVCnF71aiTUf5YStrqvicXzeSX94kRtqndgEDJXPTj5ju2rnkE52 r06DrSSuEQyFlQL8zMxAVVUZYlicKMdW4AGd1JITncoLbQSFGRy2QSSflIx/eU7fpXDz6lc67q9z o+nQEaPprbdb1WSItbTuVZToum+butbybgrqs3lzQWcazWcka3k0UsQ5LVLVrp93+ZFOnzvml7sF Zyeto62SbTe72vv5mtY3K65K1zHEw0qCTZatICP7RmQsHulUncbOMgxW7MqyTS+eWjWOOGSTplXa pyO2CeMkYOAOeuf5/lWgjVNiKu1YwFjUDYqKEACIECr5eFwrMG3fNtOVq4Twe/GcU1sr9kZ1JXko xei0dnLa6/4f+kDMFBJIGATz7DNZN3eLHIkEIE15MCY4C2VVAAPNmYD91EvO1m+aRgVVW+Zlpapq ckDR2thCLrVLshbWBy3l26A5a8vGGPIsrdcsyqY5LqYR2cchmmjqbTrE2XnM7me7uikl1eOuGnlK sQE/uwR4K29qu0Qgs20yTSM0qV2klp+PXzNVDlSlU0e6jupJ7ffvv+TtpWsWxWLMHlYgyS4A3PjB IGflC4Cqn8Kjadxyxt5wOT+P/wBamRKFQADHJPTBJY7skdm5+b/azTXOCTnGOfpxz9Ksy5lJuz/r 9fUlPyjjAx65x/jUXm7mATJXnc4HC45AOevHp3/KqqTi6JETARb9rSD+NlPKLk+g/wDrVdVdo2gD BznrnJ6/560Daa3FVQgwKUZ7nP4YpaKCdb9LW+d/8gopjMQ2AOwPT1JH9P1pwzjkYNAxaKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiohIDLJGCP3aR u30k80D9Y/foaV9Uu9/wAlJA5NV7pisQIGf3sAx9Zo6kBYkAjjjIx7fTuR/SszULiSGbT4QFIu70 RHd2VLee5yOoLAwAD9OF5Y4pykorRu930i0r9tX2NUkYORwPT/eI9fYVE5KnP90EgnocZxk/j9cj NO3EDgjAZgO/Ax1/HPSuf8USXCaJqa2knlXk0LQWDFgu6+lDRwRqcZ3NIF2/7R/KZtKLb9B0l7Sc IpfHNR/wqUrc2n9avcuaNIJ9PtbtohHJeQ/bJkAxtmuAJZsjjndn9DmtCRT8zKCGIwzMQDkcqozl SOW9uetOhQLDGoAB2BcDgD5ew7DIrP1e/XStOv8AUpUaaKztJ7hkjAMkn2eOSUxoD/G5Qog/icgf VpWSS1aXzdv+H6bBFSlVjGEby50lG3xcz5Vbpdc23Zffh6U/9o+JNdvQLiJNMgstB8p/9ROxgj1a S9tznB8s6ibOTbn95auuSVrq2YABhuxgqQQCH3ZwM8AckfNxx96uL+Hce7wrpt+ZLqQa99o8RIt7 F5V3aw+IbmXWo7C4BZ28zT4r9LLGVwluqAYWuzncRx72wdhYHOSMEMT6gdOMj/ZGO2dNqUVJqymr vtF/yy77+e22iNa8Uq8qcNXCapK11tyqy/7evseLfFKeLXdV8H/DIvZOvi+8vNV1vT7tLxPtfg3w o1hPrMlhcwwvBb6la63qvhbYs00Jnt5bgwM3lOq+zLH0DDI2oSGw+HU9QVLDCnH+6R+NeCfCq6m8 aeM/iF8RZUujoc+o2ngrwUz3dnqGkahoXhdLm6vPF3h6eFPNtk8R6prdzo+qQtKwkm8IW2eIlNfQ BUKeDwSRjHGMnI6+mfz69BUUJSceZ6KTcV717xT92XW/No01tFq505go0Fh8Ponh4KpVbi9cRUUZ VE+qnBctKV/tU3r0WfqN21naSyouZg0cMAZJJVM1xKkNuZharJIkDzSI0jbT5ce6RsKrVZsLb7NZ 28DM7vGhLtJLJOxkdi8mZZNskihnIXcPlUKv8Izzscp1XxA4OfsegAFXaMgS6teW7xb4J4rhllWz tJLq3urOa33R3Ukcm/dGDXSkPgEksfQHcoHGDnC8kDn5eC22tl70otbLmXNf3dl1/wCAcNROFNRS cpWjJ2V+bm5dLaJOzvbztuPlOFJL7VX75GAQn8eOcgkA/Nj/AHeteZW9zJ4u8Vs8Esv/AAjng+5u LQywz24tdU8UCOW0u4WWGdrp4NCR7qxu7G+gg/4mclrdQxzfZlnWX4i+KbzSbbTvD+gSKfGHi66k 0rw3G1j/AGjHbSqsbajrd9ZG9037RpPh62lXUdTiS+t7iS1Xba+dM6o/UeF/D2neGNC03QtNEhtd Ps4oVluGE13cybQHu7u5Ecf2m9uJP3lxcMvmTSnzGO7NZyTdSHKr2av08r/L5HTTX1fDrENr2tWM oUo7SjB8qlUto7t3pxWsW+fZxN5NuCcgH5VyxyQwx8rHvwTtXHY8/NmuL8aeKR4ftLeysWtJ/E+t zHS/DOk3Us6DUtSkA3TzW9lHcXg0qxEkdzq97b28y6ZZZubryYV3V0Gs6xpugabf6vq13BY6bp1v LdXl5PIkcMEMSAszMxXLt91F+87sqDcxUHzLwBaaj4ovJPiXriwRSa1CLfwTpyQyhtG8IbjJZ3Vz PdYuJdY8Qo7axdOLPSxY2V/aeH7i2updKfU7y51FzKEdZvl21stN9L2W1n39brD0VCM8XWjGFCm4 KHN7qnVmoyVPdXS3k1qlbdtJ954X0BvD2k29rPdi9vZpJLvWNS+zQ2kmp6zeyrNe6g9rbNJDatdX LFmtYS0MaMfmO3npycckBcHk5GR2IGM/Nnbx2z6UbFO1XHGST1HJ6nHbnPPHXtXnvxB8W3Hhuxs7 DRoLW/8AF3iGdtL8LaZdXDQ28t4yeZcX98Yo5500zTIEFxeyLGBJI1rZedbPerPEnJU1Hmla8lGU k/dXNa10rtt31TUvk2ZwhUxmIcYe9OU1urRS9xynp8MKcOaT05VFNtKK0Z4v1/W5rq28I+EGhi13 UI1n1HV50jls/C2itI0L6lJBIdt7qk3lyx6RpoV4ZLmJW1KSzs3Erdpoum2+kWUGm2ok8q2QKxmm aeZ3OCZ5pWJeSWYgu8kn7xmOTXL+AvCDeE9Jl/tHU5/EPiPV7h9R8R+IbqFbebVtSnA3tBZCSddM 0myjWOw0bSlmuDp+k29nb3N5f3kdxqFz3BYIMhSC24YGN+1RkcnO5mwAu5h1Lf7NKCjHmfNF2bu9 rX/vaX/r0LxVWEFHCUJSdOElOpO1pV6isnKVl8EbyjTi9o3dlKcrzsQAc46E4POfqP8AP865rWNX +wiK0tUE+p3pMOn2akEFgPnuJcEeVa2/PnO23gMVDNis3xV4utfC9raCZJL3WNWnNjoOiWgV77Vr /YZPKhjLKscFvGPOvbyaSO3t4kbc29oYpl8O6NdWyvq2svFc67qCB7143ke3slVQG03Tt6K/2K0Y FPtDIst5J5l00cIm8iAc5O6ipeeu3wvzve32dGmnfqFKlGNL6xUtFSa9nFqzq2d3ZPlvFNWk+rtF ap209K0trBTNcObrULvfNe3u3c0jYJAU5ytrCSY7S1X/AFSFVVF210MQOwE4yRk46f59ffNIAM5H HQYC+20EHPQc9arXdzHaxSzTTJbwQozySudqqgBLZY8BsEMpVWPysuG3YqopQja9u19Pw+7mMJyl VkuvM+VqPTyS6eaXlaxJPIIxksEUKXeRjgRgZKuQ3BAYEnf6ZXmsp0fVNqjcmnllkZzkNegg5jVD 8yw7iGYyKrMwXarLurBsTqPiG7i1G532mhW+Tptk5KT6rG42pqepLj93bsQZdOsV2yNGI7y6kje5 axtu0jGwYPIA2qTgnAwAx+VVBYD7o6kYHXhxbau1Zv8Ar+vvHOCo8sY8spNe842kodru61u16bb3 JI4hEqIihVQBQo4CqAQOnU/4n8JajHCjceOo46YPX9fy+uKqXd9FaxtLM4ijQSMzNgnbGN37tB80 pYfwxhm46dzRmlJzstv6/r0+RbLqi7nOFXjcxAz1znOMciofNaYlI1ZU6GbIXnr8gOd36fiKy0W4 vjFJdK9vExZorMnMkhALI12424bZmT7LHtVHXb9obbWygO1CcDaPuqcgYBGATzj0/uj5QSOaV9bW e1+lrfeVJKNrtXfy/wCHHIoUYGTk5LN1Y8c88n29MU+ikJA/HP04BPJ7DimTfW1ntfpa33i0VD5u 5ikeGYYzjouc9SRg9O3NSjOOTk/h/QD8f0oGLRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUhOAT6An8qAA5wcde1IpyM8d849c0m7Kk/Uf0qvbykxsdp+V3GCRkbZGT16N tLLjPykdc0A9E29luWGbgEev+NZkTh9WvYyeVs9PYqOwd70g9+pQ/l+NaDEbQMcAbvXqM8fgTXNW M2/xXr8G7iLSvDzD2Ms+t5yMfxBR+WM+kPeLf83L6vlvp+G5VNc8ZtauMFN7e7FzpqL8vit3OpBO 4+m0HPbq2P061zuoj7TrGjQLIoks5rnUHjxgvbGzurEkjqQs11H/AMCK571v7iCe/GCDzkgH9M9e vUn6cC80n/CzraHkxf8ACE6nIwGceYuv6Sq5425ZWf8AD8KbcVZN2bat5tNfnt93QqjdOpJr4aUm trXaSb9LS1R3gO4AhccHgDOMjGQPp+B/nw3i2aC61DwnoLXRivL/AFuHVrUAYEsXhuSPUbyKQZ58 yAhW/vMTnbiu7JGepwPTjjAxj8zn8q8wuryC/wDirYaPNav53hzwmfENle4IjR9f1DUNDu4Dgcyf Z9PSRV6/ODznNRUbtG2t306dVftpf1LwsU6km0vco1qmv8yj7lt95uF/J6O1z1A4CqR22j8s8fzr x74v3y/2Ro/hKOfUbK88e+JdK8L2eqaau6XTJnW61pruYFXUWfkaLPZzsy/evI03ANtb14tncMEY JbJ4/Ae/+FeGy3i+LPjtFYW15qNrF8L/AAW15q2mywEaTrFx8RL8RaHewy52vf6AngfV4nG39zFr mEY+Yxqas1Bwj9qo+WK+H7N5dnsm767G2WwjKrOvJvlwlKpiHUjryVINKi90rSrunD/t69tz2uNB CqRoCojUBVGfuqAuFH3Rt4wv3f7qr38X/aD8eXngL4Y65faTPNa+J9ck03wZ4Ou7ewfVf7P8Y+Od Us/CHhnWLjS03Nd6Vomt61ZazrKsrRxaTY3s8uI42Ye2MecABhtACdcN14z6H1+Xoa+PvEF4nxW/ au8OeCoJYLjw7+z1o8nj/wAQzWWoyQX1j8SPGGkXfh3wf4e1rTdoiv8ARNR8CeIfE/iKBsPHBq2l 6bMSs0cQE4mTVD2cVyyqShTi00n79lJq+7jaU2uiTW2p05Lh6dfHTrYnmnhcDSrY3FqKcZckHBUo OSu4+1rzo0HJ3t7RSs3dP6E+Gfg+3+HngTwz4PsLKxtItD0uC3mi06H7NYyajOWvdWu7aNt3kw3m rXN/eiPOI/PZMDjb0PiHWl0HSbnUPKFzcKI4rOxWZIZdR1CciO1062eUMq3d5Kyw2qsrbpGVcHvt vHgMTjjOMljhTwOMZ3Mf++fx482knfxL44Fgjb9G8FJC2oL5qvHdeKr2CK9s9PvLeRVYtpWnz6br dlewrJGs17sEkckLqNbxhBUYq1oxgn00SSuurSXkl59OGEp4qvPE1bcrlOvVs5NylzX95vb2km4r s3dvdnXeHtKOk6VBaTzLcXrPJeajepDDC97qd2fNvrySGKOO3jmupDI0ywwxqrOxjWMEVevr2y0y zu7u9uYbSysrWS7u7maQIkEEKPPLPIxK7Ioo4pHkdm27FZsqqtm8JAByGDKSRgHaeyc8qdxx/F8v V/lFfOPxQ1G9+IXjDRfgpoN7dw2k0Nr4o+Kd/pmoQWl1onhAXE0eh6IZLa7TWtM1HxvqtrdyaNqd nayWMmn+E/EtleXlq09tHdTUnGlBQbaUm46O/NLa2z1l90bNmuEw7xmIfNJwoU+aripp3UKNNxdS cVouaztGLkueo4U9HI2/hbC/jjV9T+MGoxAW+sBtK+HsP2i9kS38D2k0i22tiGW6fSftXi24N5r1 lrOk2dncXnhTUtC028mulslavcTtUlmyAqlRlyFwTnkZ2ggqDu5wCcNt6Q28NtZ2cdvBEsMEEaww xRosaxpEBGEVThUQBdq7tse0LtbbtNeE/Gzx9q1m+i/C7wBeWo+JfxAE8OmtLJ5snhDwzb/u9f8A iBf2Fus999h0aF/seiTy2o0m+8aXvhzRNRvLO31KS5izU/YUZSldScvdW+snFRtGO7fRLbb01jTq ZrmMadCCjSakqcnaMcPQoxu5yb0tCnFzk3duV3dyetHVbp/jH8QLjwhZtpdz8Nvh1qMP/CcyFYdR PijxoixXdn4OaGTzbO0sfDUD22s+JIr22mvry71Xwu+mXFitnqK3f0Ssap93ITDEqT3I+9zwT9R+ RrkPAng3R/h94R0PwjodslvpujWnkoIbeOEXE8sr3V7eukfypNfX9xc3s0algZbiXbujTI2/EHiL Q/C2h6r4k8Q6rp+iaBolhc6pqusard2+naZp2n2cbTXN7fX95JDa2lpbxq0s1zcTRwxxAyPII9rU 6dqVOVSatUspSf8AcfK9X5bLbTd3crxi6kcRWpYXC3qYalJ0aFOSblWnLl5qziua1StJRk4q/s/d pqUlFXwvHnjvRfh74a1HxLrc223tFggtLWNlF5qusajdRafo2hadGxJuNV1vVbm00vTbVA0l1fXc MMasz1xfwz8EanHeXXxK8ezHUfiB4ntYYPIkDjTvB2gLI09p4V8OWMhK6dBG0hutfvWVtY13VDHF rd/fWWjeHrXSuA+HGj33xk8V2Xxw8ZaPqen6FpMt1/wpbwtr1tcWF3pGnXdpPp0/xAvNBvYobrS/ E/ijSbq5tNPOrWll4g0Lw7q2p6He2tmb+7hf6nJGVABGQcZ4IHcEMee3v8o67uUk6soTfMqc4qSi 1s7x1s+6SUb23va7st8VyZbSng6clLFTX+21YuM/Z6prB05q8VySt7aaTbqJQi3CF5puKlhw7Abt 38THsgAKktgfL65wK4D4g/EPT/A2mWbS2k2seItevY9G8J+F9PIfV/E2uyRvNHY2Ue1zHa2sEM+p azqkiG00PQ7PUtdvillp87in8TfiTo/w90qzmuLe81zxJrM8mm+EvCGjiB/EXirWWVSmn6VDPNbw QpH5kcmp6tqM9pouiWbDUNcv9PsQ1wOZ+Gnw01Sx1S8+IvxEvLXXPihrdmbOWe1M76L4M8PTTx3s XgzwclzHHJHpEE0VrJqeptbWt74lv7C21TVraO4jhihtzjKXsYRWii5dknyu7ffqk2rt3ehhh8NT pUIY7F80cP8ABRoXaqYiorbaqSpxb/eVNkvdinJ3W74B8F6pY3c/i/x5eW+r+P8AWrcQ3LW3mf2P 4Z0ws0sXh7wvbSyOLWwiJV9V1Bmk1LXr5Y5dRu57LT9FtNN9WEYG7DMSSpyWwcrgADJ4XH8Odp9P vUBXDKSPug4xt5467h0RsD5WK5x7YrlvFvjPTPCdvbC68281fVJns9A0CwCy6trt+qq7W9hbM6Yj t0dZb2+uWg0/TYCbrUbq1tQ01UuWnHm+zGz0vzK+19dfxvd+aMKk62NxMeVXnJxhThFWhFRSSVOK 92NOK012Su3fUva/4k0zwvpV3q2rStDa2qoAIkee5u7mWRLe1sLK1T99d6lqF3LDY6fYw77i8vJ7 e3gVpJFWsTR7TVfEGzWPEtuLSF283TvDzHK6fAwDxvqwPy3GqsPmljbENnlYY4EuEuJXq6P4WvtR 1Gz8UeMGhu9Us2aXRNLgLSaX4cklhltpru1EqqbnVZ7WaazbUJIo7iGzubqxgcW082/vxx8oUkqD uxkL1zkL90lcj+91+tKK9pyzel9un8tuZN6X7St59lc5Rw7lSpOM6q0nWjZwitE1Sk/VqUutrQai 7ycqq3oG3E4wpGQSVbkFScEEsBuxxnPFDbYjluS5CgBSfmPAOBywA+Zv7qhm6U3zFQLnILFsMQqk YBOCmd2QCBxubozda87n8V3viLUrzQPBqCaOxgI1PxZLGkuiafeSkRxWOnsSya3rEAc3ksNuJtNt FtXstWvLK+mht5LcrWT10V9fT799vvOelRnVcnH3IPWdR7JXs7t7e9tbd7a3Om1nxFFp81tp9tDL qOq38ghtLC25k24YyXt4QG+xadbgBZ7yZREsstvDnzLiMEs9Gl+1tqepTC7vysUdtH832HTreI8Q afbOWVJpJN81xfz+bfSNL5C3H2OG3ggNA8OW2h2ItYpJrmeSRri91G7dri9v7tyDNc3krlmleTaq ohbbDCkMMf7uGMV0mMEhQeRjJGQAcng55Ayfl/yVG7fvaNabX/Frs+n/AAXVSUYJRprmWjc9HJ7N pa6K6elm+/RJPLwMEljjHJwcdOGxuztJXduzg9eeDdj5V5xge656MxPbOevpxR5inOAc5xgjaTjk lS3ykAZbr2965O614XFxPY6Gn9q3sVzFaXjRSCOxsGYGVze3ynCvbIB5ljambUEa6t2ktVt5PMol Oz5VZP8AF7fL+n2M40nVd1eys5dlHbe2n397XWp0093FbruldEBcRqXyuXY7VUAnlmP3VHLfwg1X he6vCDIjWlsVY+U//H1OCQFMgP8Ax7xshO+Has6vt/eBdytSstKKMLm7ujqN2Li4dZ5EAithI7KI rOFN0duYYgsMjR7WuGjaSbbJIxG4oKrkkkkZbGTye655wP4VP3Rx7FpzurrTy/Pd/wDBHJQi+WDv bfv0/r8wSNY1CJkKBwoPT8T8x/4Ex/Sn46+/U96N3UkEY9RikLDH4ge4JAOMfezg5xjd9ODVkNpb 9R1FReYudqAsenHIGO/Xn8OfWgKxOXI57D8gP88/0BktFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAISFBJOAOSaDyMeuR9OD/+qkbGMHGDyc5+6OT09qihcsjA9Y8oTjGWUfMfzoAc pI4/2gPzyD/L9KydOn8671qIgEWt5FEuPR7C0nPXod8j+3J+laxG7nqcEnOQD2HT2z2/OuRtdQjj 8YajoqxhTJo1lrcz8gtJPe3Ol4PPaCxj6fp3Una1t7X9OVfrbe/Xui6S51XXS0Vrtp7O/wB9n97O vK5LD0Ax9cDHt25rzzRbrf8AEnxrbbsmDw74LlK56Ce58VpuPHX9wR74r0JiQze4x0+hP6V5H4cl Y/GP4lxHpH4O+G7j/trqHjxfr0jHt6VjVdpU9d60Vbzcd/w/E3wsU6OMl2wsfwr0NvJc2vQ9cOFB JOdwPzccKQDnHp/hXm+iazb6n8RfGummNRc+FrHw9amUffEGu2TamyH0Be3RvTIHUivR2UMApGBg g9OgPr+B7YryHwbpLxfE34r+I45fMs9dl8JWcIHOybQNHurC9Uc4/wBbJ+nPs52dSjd6c8rW8o// ACSt8762KwsU6WOlJ6rC2jfVczxGGio384e0t6bI9d525UkDBOcdMZ69e3b3/GvJPAM2rX3iv4n3 +pxRyWsHibTdO8L3iqrPJodv4X0Oa9hV1ZmKW/iWXWo2Vgu2ZZFC8bm9P1HUbXSNL1DVLyQRWenW V1f3UjDCxW1pC88znGfuxRu2B6GvH/gNYyWXw8tL86n/AGzB4k1vxZ410vUi24zaF438Vaz4v0CL dnlLTRNasLWNc7FjgVV+VKV/fjCKT5k3Puo8yjB626yf4aFUbU8uzGpd2l9Xo02viScvaz5b67Ul GXS0rvVo9mlZkEkjEBER8BiAFxwSWPdQD7enWvnf9nG+PizQfFnxUTVL7UtN+J3jPWtf8PQapaC0 vdA0DTjD4at/DrZ/eSWtpqeiatqVsZAv/IWkKLtJZr/7THjD/hD/AIPeLWj1K70XVPFkWmfDjw5r djEbi50fxV8TdXsPh74T1lIyGzHpXiLxLpt/Mdv+rgdm+UM1eqeBPDx8KeDvDXht2hmn0jRtOsrq aCGO3iur6C1iW/vUhjVY4vt14J7tsKoMkzNw1ReDxHK7Nwj7STf2ZTajTtpo3FT0u3utjeKnh8nq VXFc2YVoUIS3jPD4dRq4hLlldt1Z4e75bJxaTd9LniTXtN8M6Dq3iLW9QttI0vSNPur+8vr6ZLaz tba2heWa4ubh8LFFEql3kYhVXaSwGcfLX7FukarqXw0v/jJ4qs9StfGXx412++Jt/beILGGz8TeH PDevzzX3gv4f6wYXPnn4faJdJoFozHcscbsAm854r9uXVZPHFl8Nf2VdIEVxqv7R/ixtB8T2E4mj iuvg14aFpqnxkjjvraSKbT9Rm8H3U0OkTxyxyPfSKsbbo9p+6rGCKzsbSBAIhDBDb7Rt2KUjEK8j 5T0UL/eYq3zcmsoP6xi5/wAmGXLyqP8Ay+qKE3du7bUHT6q6qPTdL0a0FlvDVBP3MXn+J9ryptTj lmBahTlbTmpYrFutdy5rSwUGktJGN4z8SW3hXw3qetzNk2sIW0jWOSZ57u4lS2tIhDEGmkV7qWMS iNWkWAyyKreWareCdCuNB8PWVvfMp1m7FzqutyCUXSHWdVmk1DUoobhoLaaeysbm5ks9LaZVkj0u 3s4H/wBUa42/Wbxh8SdN0vypn8P/AA6hj16/nkhu44dR8W6mlzaaJDp+pW0sNvNL4asINYk8Q6Rc LcRsviDQbiSFTHCx9dDBU3kZVEKg7g4wv8YI7sM+6/dxziuiEvaSba+Fq36/P4X+FzxqsPY0adFc vtKvLXqbO0ZWVKEuqbV6jV9edLRqx5/8TviDpPwx8Fa34v1dZrgafFFBp2lWzIt94g1vU7uHSfDf hvTNxEQ1XxFr17p2iaWZzHAdQv7cTyRQ75o+R+BfgHVfCnh7UPEfi91u/iP8QtRPizxtepaiySG8 u4I4LDQ7O1a91Gaw07QtOhgtk07+072CLVX1e+tpoxqLwp5DbXDftD/HW6dQl18IvgDq1zaQsjXM th4x+NEAn0+/VzDOumapZfDGN9W03U9E1i0vn07x3/YWu2X2O/0e3kH2UWESGSRiqInXhVXCsQzk /dVdrZyxXc25sZ+XOEnVrTqtXpxXLTi1dSkpatelmkm7KN2m0zuxdNYHA0svpSUcZjPZYjHcurp0 3yuhhY2dveU1WrRk21UVKElGVJo4L4l/EXw98KPBWveOvFVxLBo+iWctxIlugutR1GYqy2unadY5 je/1W/lCQ6fYwH7Rd3MiQRIXO0+a/AnwB4itP7c+KvxKg0+P4q/Eb7Nda1Z2btqFp4P8P2436H4F 07Upkt31GDRLNkt9R1qC00SDxJqMCaxNolnLthTy3wqZ/wBpn4vv4/vYo5fgj8GPEeq6N8P7CXdN b/ED4m6FdSadr/jy4t5S9j/ZPgfXLW48O+Eg1sNWsfFvh/V/ElrqK2N9Z26fbK5QDaqBMFF+UheC AnfaY9pPKhf9nbUwU8RVVdr3aatRpXXvPlSdV79bxhqtOZ3akjbGpZVhFlijJZhi4RnmNRaKjTXJ OlgVfWM9I1sRr8bp03GMqUuaF5ktopJZphFDboXlkllREVBud3nlZVVFjQHJbCgbizEfNXxnHcP+ 1b48WW2hE/7OXw316VUublXWz+L/AMQfD9/JFO1jaFV+2+AvBGrWxs/t104s/EviWw1iwTTb7QLT T9Y1GP4veKNc+O3jO+/Z6+G+qPpfhLSJYl/aE+JVpLHbpoNpLGk0Hws8K3bN5N34+8QQf6V4jZ/t cPg3wybVNXsmuPGOhPD9ZeF9J8L+D/D+jeGPDS6Vpeh6DptjpGlafZz2sdraadYWsVna2cEaviOO 1toYlQrzsUBix3NS5aletBJTnSozTqPkfLVqe5JRukrRov4o7Td46pSTqlGnkmCpV5ygs3xlJvC0 JRVsDg6q5Y4mpzJtYqum/YK3NSg1XTTqUnHp1UJtCBQFwpwScJ2Cj7vzAAY/5Z54Lbdreb/FD4oe H/hZ4el1rV/PvL+7li0/QPD9kFl1fxDrV0WWx0fSoFBaaeeRXaRwrJbQLJcSMY4whk+JPxL8L/DD wbq3jTXb0NYaYsEUVnYkXupatqeoXEWnaLoWi2NvJ52o61rurXdnpOi6dAkk9/qd5a2sKGaZM+K/ Cf4eeKvF3iRPjb8aYILfxhJFIvgPwCl0t5ZfC7w/eBTsliMkkN5451VUR9c1ryx9ggig0jTI7MR6 q2obVvac3sqMWp1fjnKL/dQdr1G9byb/AIaS9526JtcmW4LDTozzLMqqjg6MuSlRhUSxGPxVk/q9 OKbcaV2pYitZxpxdo/vJwi+w+FPw611tWuvix8T0iuviN4gtUis9MScXem/Dvw+SXj8I6BK0SB5B uabX9UMa3Oq6tc3vltb6clpZW30AilQTuLdQHbnaM9eFXAwTt60oAVUCYwMDAAyNzfM/9085Zto5 b9PHvid8RdW0D7F4U8CaMviX4ieJRPDodhMk7aFokMaE3Hivxnd20kcmneGdJA8yZBNa3eu3/wBj 8NaPcxavq1lIFCnSow9mpyvGznKTvUc3b3m/5pW0+61ooxq1sTmuLnKUIRS5YwhFKnQw9CCVoRTd oQgrpuT96TcpOU5Nm/4z8fWXhaS30iztJtf8VagrnR/DOnuBeXuBtFxcysGisLBZCfMurghQqSeQ lxJE8a5XgfwDqFnqV5458a3UGs+P9ZhETSRZXSvCekA7rbwr4ZikVmSwtmZ5NR1WZRfa7qk19qDp YWE9pommzfDf4cW3g22n1HVNRufFHjbXpFvvFfi/Ux/pupX2wAWtjb4WDR/D9jzFpHh/T47XT7CP zLiS3k1TUNSvbv1Unjk7t2D7Dr05P0/x6VUFKVpz91R+CF9raqUtry66WVrW7tVq+Hw0PquCinNq 2Jxc7qdd3S5KKdnSw62tZTm2nU0tCMeSflDKHweBkk8ckDPT8enrxWVq+r6ZodjcanrOoW+n2Fqk k1xcXMqxpHGkLyNtz8zy+WjtHFGWlf5tiu21RyPxD8faZ4B0uC5ksdR1vXtYuoNF8MeGdFgludZ8 Q6teECGytLeBJGt7SzhWXUtb1WWI2+haFZ6lrd+8Vhp9w68XoXw517xPrieMfivNbX91aqq+GfBN q8svhfwzBIIpprq/gkd7XxL4onuIo4pNYvkubbSbexg/4Rm20aTUtcl1OnOKkoRSdSduZbqNuV++ 9k7arTXTptlQwcHT+uYqtLD0I/BB2dWvPqqNPrBL3ZVZWjCTW8moOS2/t34w2FvdMuoeFfhxd3C3 lpGxe38SeN9FRla2F7CQj+HfDeuKrTNaiS41rV9BuLV5JfDd9NNbW3tFhY22mwra2dtFa2kSgRRQ qirlmG8lVVQS7ctI26R2JZ2Ztxq6gA+XBAOMc56nJIY5z9ehzgd8MkZUUOflww569TjAUYyTnn/v rtThDkjeTk7a80kvu02sk+/zd2Z1cRKvaEIqlSvFRpxu0np771anUkldyfRuySslIpHO0gH3PTk8 Y79PasTX/E+ieGLC41LXNRgsLW2immleUSSSNHbRmWbyLaFJLm6dEw7R20MsgUghOc15vrXxNE+v TeD/AAFp/wDwlfiO2lu7PVriGQnw74QuIIbeV18S6rCTFDqEjX1jJa+Hlmh1TULUXk1o8S2czrq+ GvAC21/ZeJ/F9/J4n8aLYi2k1GZZY9H0YtLLdXFt4Z0gMLLSoo7iea1i1WWGTxNfaXFZ2esaxqP2 dGRc8p3UY/3fW1tLr5efzNFg6dGMauKbpRlyyhSi17aadnzPfki72jKcfe+ynZj0i8UeMfO+3W93 4T8NzQ2bJarLGvifUiskct1BfsomtNIsXWN7Ga3t31C5v7O4mmjutNmVVrv7TT7SxRYLS2jt4kBY Ii8uWRU8wtuUvMFQK0kvmSMqr89XMBc44x0APXp3IIOQee/0pw27iNxLD1/l/P8AnjHUjSS96TvJ 3vr1/rt2fQwqYmVW1oqjSXuU4QvHmsl7z5m5OXW8rtrRWjoImEVVORkcA4HYZIxwCTlmyxO4nk5G UD4JLE+mOnfA4/Pr9ap6hqVrpsEt1fTwWtrCN8lxPKkcaLk5Yl+m0At6N0x1rBhv9Q1rixtbjSbI t+8vL6AxajNGYZB/oljchmt5I7jyx5t3HNDJB5nlqr7XXTmSkovr+C/UmFKTXNL4H8VSXu3tbpvf Vbavy1a6K5vYIAqOzGSV1SOKPDTOzBmVVTPAYRv8zFVAU/Nu4qFEupx++QW8PIESkySyLngvJhRD uGN0arI3H+u9Y7Owt7Ni0cbvOyhZLmeR553UtnAnlZ2Ee4F/Jj2wq5+VV76wIAHU4HYHt16gUxNq LtBc2+sr+W279L+ewiIsYAUdep+nrT6KKCQyM474z+FFMZ1TliBxwO/vj9PypoZ3PC4Xghs9f/rc 9OvHSgCWiiigAooooAKKKKACiiigAooooAKKKKACiiigApAOSfXH6Cjn5v0/L/Gq0MxfzFLfPCSr DjJ3AFGPt16YpN2aXcLXT006/MmY7RjlshsEjOD2yfxx+HFZVtM4v9QttoSNTBcWwyN0nmoTdSY+ 9hZiqtn5VZvTrqkHaM/eAGe+cDk/gSa4/VLiPTPEnh+ZhLJLrAvtARUz5UBW1n1x7iXB2jdHpbQr xgGRP92pmm7NdJLTbeS+RdGEXeEdW0+WN93FKT/Bder+7rXcEHOMqDkZ4Ixyf5fn3rz+8/s3T/iP pFxNKV1HxL4fn0izgLcSJoc1xrNyfU7Uvvf3OK7xWDkgAnAxnOSRgHnH1H+TXjnjvSrgfFD4Q+Jn mEOmaFceMrG73sFje68RaHa6fpsJ55d7iMiNf4nOFzzU1vdVruL54aae8pOCt1/vP0XodOAg51Z0 5rkl9XxNkr6yVGVSnBW0cpTil2u+uh7Yn3R+P8zXj/hn/ktHxN/7E34a/wDpw8fV7AhBUEYwcnjo cknNeP8Ahn/ktHxN/wCxN+Gv/pw8fVnX/iYb/r6//SJBhFalmPS2FV//AApwtz1m5O2GSRSQRG/Q nGMElv8AgPJr53/Zs1jUNa0L4mXGpl2mtfjt8X9KtGcHcunaX4uvbKxQE8sq26Js2/Kw6e/0NdkL BMzsQqQSOfQlUY/h0+leG/s43mmax8LNH8W6OEFn49udR8dRSR8iRvFVw+rPKxztLy+duf1btxwT cVXo07JOanPm/wAMqa17brfTc3w9P/hHx9aSvKGIwNNb8zdSFefLfXb2T5lp010bL/7Q/jCw8C/B nx74k1S3uLzTrfSodOvLa1RnuJYfEWo2PhwrGiZdiP7WLPt/hVmHeu68B+G7Twb4J8J+EdO3f2d4 Y8PaJ4dsSy5c2ejabbabahmB4Kw2se4tk8HmvEf2itR1WXUvgt4NsNJh1rR/HHxc0LQvG9lKA6x+ DodC8S6zeX5iYHdHa63pnh9WbPySTxfN8wDfSigQRMcFEjXAU8kqASzDHdmz3+79cUoyi61Wom/3 XLB/ypWUndd3zL5LzRden7LKcDSakp4utXxSlZLmp2o4anGL68tWnXdvhvKz1Pkn4tam3jP9ob4G fCbTtVazk8NHxD8a/GGjzWrtp/ibwZolheeCtP0+S4CNDFeab8QPFfhTxJbRyMJC2irNEcoDX1u5 Gx2GGZQTlRjaygjPXkcju2M+/Hxh+z7dN8S/jf8AtEfGaDU4dT8MWHipPgx4Pt57Ty9Q8M3nwwe5 0P4n2Ecucy6brXjOzs9StnVmFx9jWXCbUFdX+2j8bE+Af7OfxI8e2sjv4hTSI9C8IWNu6pfah4q8 U3cPh/QodOjbcZ7m3vtRTUnhRZJfs1jcSFNkTsvP7eNKnisa4xdNOUlfdU6S5IyVo8zbiuaMUndy srt6+vicvr4/M+H+G8ClKuqeBwqitFDG5jOnXxCrSc5U0qVSv7GrUlKMIxpXkoRg2vCv2fHk+PH7 V3x5/aBuJXm8I/CtrX9nT4WiMyS6Xq8vhphr3xH8YWPnAeRqUHjfXfEfw21QxKoki8GqGkYDaPu7 x54ts/A3hXVfEt2kc5sIFjsNPa+s9OfWtavZV0/QNAt7q/uLWyS/1/Wrqw0XS1ubiGOTUL61iLje M+M/sj/CB/gf+z58NfAF8Um8S2ehprPjvUVZpP7Z+Ivia4uPE/xE17eyq5/t/wAbavrurgMqiMXo jUBQqVW+KXi7w4PGVs/jXxLonhH4YfCazj8beOtc8QaxY6dpM3iB7R5PC3hvWLPVbIW97aQ2c1x4 zsrzTdSW+tPEHhzSYltpmkxVYKjiIYePuTrYjETVXkpxk26lRpu9tWkuWCuua0FFatIvP8RhMw4g xEKdTkybJqUcBhYt83Jg8vhGlzJxXKnjMTzVpOK5Pa4mU3dXb9q8D6de6b4ftZNUCza9rBGra/eL p1hpU9xqt5Gjyte2emyzWa3ljapa6ZNJDPKtybJZldvMZq89+N/j/WfC2i6b4W8DCG6+KXxDvj4a 8CWb3GivJY3EyxLq3jW60nVtQs5tW8N+BbS5TXvFlrpMOoaqukxtJZ6bdSyRRt+XvxU/4LFaR4nv r3wd+w18HPEH7SOsW0otL74q+ILyT4cfBDRTNFPGL7T9avNN1bxR4xvdNuon+2aHB4a0KzuoV8y1 8RMpzX5B/G74YftaftdfE3SPiF+0h8TtSnvNM0hfDtrpPw9vtU+EPwm8M6VeyMmoaZoWlwXniLxj quqaxBKf7Q1qPxLYtqAk8uS1hs44beL7rLeBs0x0YVMVVhlWEqRu5Yp2r/ErzVJL2qa6KfJzWTV4 u58bRzfL6eMnLEKeJjTjVrQp0VCVP28IP6vTqTk4QVCNRQ9pa75E4qN7Nf0MePP+ChP7Bn7IvhzR /A3i79o/w/rut6G3/CNT+H/Cmqa18ePifJrmnR+Xc2/i/TfhxZeMPFkGvXM8bxXl/wCJtPsTNduW vpoz5rL+Rf7XP/BcnxV8Qfhp4i8Ffswfs2+M9M1HXNTTR7rxj8bNb8MeGNI1bwekkbaw3hzw/wCD /EPifxtHcavasdKlg8ReH9EktrHULmW4jjlSNa+edI/4Jp+DfCqTXvgzRtJh128m8/UvE9/bzalr l0brP7s+dqdjfQXkjMJIby81TUZvMVXk8wM9fKP7THwAn+D+jar4k1nxVpFrFb3EcenzaXaXviDU 7i3hgkW+Oo6WLrTZtI+xtNErSWdxrCsZ2MjNsjVf0HJeC+C/b0cNWzCtjsROUabUr0KfNzJfDS5t NWrym76O+qR4s8/zSjXeZwpQqTo1IV5RnF1HGUWqinJzsnedtGndfNL2z/h7D+35nw5aeFvHfwB/ Ze+G/h7R9L8P+H/hT4I+HegfF6ax07SrC3sdM0y01fxL/ZN/BBZ2UEFhGXtoo0ltzCAGVo1+avG3 7ZP7bXxL8X6x4if9rP8AaY07UbaZLe607wf8Q/Fnwg8LrGwaR59P8B+HJf7BtWjVGaOO3IZl6/u1 Zl+Yv2Xvhfr/AMTPipqF7qPjPW/CPwZ8LeBfGXxJ8a/EmDRBqd6vgrwFpb+IfEL+GfDuoRW815qc NsJbLT7W4vLOPUryLbHfRlm2/tb8Qf2HZtE8B+FviT8cv2X/ABn8N/grq2t+D9O1H4k2v7S1p42+ MfgGTxRrWneGvBfi34r/AAbtfgj4N0e40CXXdW0iTxpo+h/FCW68LWM91dRahrS2P2S99ziCjwFw ljqeDr4LCTnKhTk3DDqfs7tKNSpPltKT1Tert+PnYbFZrm1Wri26seZzrPmq2i6spc3LBJu930S+ 7p/Pvda5qfj/AMR6p4Di8BeOviXf+Jda1HxL4j1fxP4n1fxJZX+vXf2e31vxVr8TTTTX2oXUUFhD eXixzXjeVarsZVbb7Xpv7Kfwz03Q7PVZfAuiHUJBJDeaVp+j6tE9rLEcMJDfWtqx85sbWb/SOcrG 3y19A+NP+CeX7cetfFXxZ4P8IQiz8A6VrJs7PUtIlYWlzoaiO8sLmK3tLCxkY31tNDebbjxRCqrP Gs0kjKdv6VfDL9mGy+Dfg2w0r4q+Nvh7H4iWKKXUbvxR8QfCHhq/jcorw2k1lJr/AIikFxb5EazM 2/5QZI93Tx86zrhfLcLTqKtl8I1qcakY0qlGMqcZ2a54tp8zTvbl0vZn0mW5BxJnfNUp4PMsVVpU 7t0MPWrPlp8tlB8rbUVb3U9I22tp8OfCf9knwJf2dpqN34JsdHfMT20GqWsMFxIylSj28bSsbllw GjkX7rbW+ULz+yn7O/wN1nw9Dpt74c8Sa94cmtiq28mk67dW9zAmwYS2a2ncKvPy7G+Vjt+9Xa/C 3wj+z9qIsRZ/Ez4TeINXtI4YY7S0+InhvU5beQvGWxIL62+ZkDr8sPzZ+71x+gXgD4f2NktvPY21 sLSQpJBc2dzbXtowBKuIryxa6twWAGFbbzx61+b4/PMnxcVHC1lUnPT3Z02rNxSu4tp/5fc/RrZD n+WqhLMsBjMDR+JvE4etTn71mnKDjdd07K9lq9CX4eeFviBbT2uqXXxM+IWrzQK7C21rxTqmpWLj OH8/TryVbO6+XlYWb2barLn27wT4J8VeFLrXb228RQ+IX1y7vdQkh1/T4reVr64kaaNZNYtBdaqN LsU32un2ElssNjA/lQqUXbXZaFosdrHHlQqkGRVYkSKSxK4cxmMDbj7yk/lXawQrGqqrAHAT5SQc YGCzFW3PkDLfKuR+A+aqxi5uUoUrfYkmnNv3dutuno79LGVOdSnTq0KdbljKaqTtK8qtmmrp/Co/ Z1suyOZTXfEdrDp0ep+FZrya6lddQvdBvLKXS9NijUnz5Y9UudP1W7Xg/u7XTridm27Y22sy8Lq/ xYSbXdP8GeEbNr3xLrFnf3Vvd+IoLzwxodjHaTXFmjzS6lBa6rq819fW9xY2un+HLHV761WJb7Ub ey0u4tLyf2wjcwDAHBILYxtZQvBHzBtxbcW+UfKPvcLWXqeh6TqyKNSsLa7Ee8RySRDzYfMXa32e ddtxbswA3NBJGzfxHkYzlHmjbR2av218r6fe3bZdR0KsKc+aWHVSXSUpXj0s3azeusYqybte65kc T8P/AIer4PtTc61qs3i7xreq0viDxnqtvDFqGr3k8gnlFvbRvLFouiQSjZpHh2wkbT9ItgttZjyl 3H0sbiF2kADrkjBOc8nv3/KvOh4U1bRZLX/hFPEU+m2ltbWtjBoOrwNrfh+3sIJYpDHp0P2mx1SL U5Io2tv7Uu9TvkjWWRv7PmZl28V49+KPjrwvpKWlj8PHufE2pX0WnaXfPq+7wLpZu3KW2q+J/EEO ntqlhZqkdzO1tZ+H79pbiC3097q1jvG1C1mT9jHmUOaTs9by3te9ry66cxslWxtZSdSEpaR9+cYQ pxvFcqg2lCMeyStFJRSVj0fx18QPCfw70Z9f8W6vBpViJY7W2UiW51HU76b5bXSdC0q0SbVNc1y/ l2waboui2d9q2pXDx29hY3MzKjePW8HxN+MM8d5drqfwr+HEOriW20uO4W38feN9MshMsE+oT2c0 h8HaFqV4tpqlpbwXQ8R3mlwzaN4k0jSDfXtrFt+EPgxpcOuN4/8AHGsyfErx3OLU2ev6lHDDovh2 G1jhBsPBmgRTXltotgupR3WsW/2q71rWrXUb+7VfED2629vbe7RLlRkgkZJO0gYB7gFtpHH5VhBV K3vuTjSj8VKUUpPbsrcu60eq73sdrr4XLoxhg+TFYxT5J4yrGSopvS2Gozi22k1atWjGcZ/BTi1z vC8L+FtA8H6Rp/h3wxpVjoui6ZFJHZadYQR21rbrPPNczeXHENu64uppriVvvPNLNIW3Sc9MTyOA QPfnPfr1Cj3/AJcVwcFsqQFPy4Cgj5TycFsnn+7/AA42mvKde+Kun2uoyeGPCVlN458YRW6XEmla XIsVhpkNxf3OlQ3niDXGjktrCwh1CzuLXU3sotT1SxaCaU6M6qsbbKUFH3fhtZR93TyS7/yx+88+ nRxeNqtxjKcm+aVSbajGLavKrNtRhFyb9+clFu3menT3VvaW093e3EFvb2sc1zcXVy6QW9tbxI0k kss7MqxRQwq8k1xLtWONWaZlUGuDPjG812ZrbwRZx6pHi5WXxPdk2/hy2lh+yeSLWcqJta+2RXU0 1peaLb6hpTSWFxb3l/bysqtlWvgbWPEssGq/EvUhqCKRJB4M0yRoPC2mzLf29/ZSXrnbfa9qmltB 9hGpyPp2m38E06z+Holm2x+r21rbWsMcFtBBBbxLsSGGJIoo1BJCpGgCgcn5VUKMfdGKlt1NVdQX wr3d9Fr/AF06Gk44fDXjKUcVW0d4X9hCVouThezm1azSSjfWLmt+V03wosFzBqGs30uvazCZCmo3 sSQLaNNAttO2k2MRkt9LW6t441u47VlWdg0snzyOtdXCD82dvJDYGSRj7yg4+df7r7sZxgekuBnI GcHIzngkls9Rzn8G96QsFPBIyMAhRjPIUNwxxk8cfRfvZ3V0m3fTX/Dtp8krL8DkqVak2lUqf3Yx 5dGv8NlZenu+ZIBnGQckHPJHTGM/p/8AXpSRnOQCBx/eBPt3HP4GuV1XxboulTQ2Et0brU7qU2tl plipu765uEiafySkYWG1lkjVmRr2W2icK22QH5arg+INaR2lP/COWMq7I0jdLjXJoJbWFmnaQqLX R72zuWmje326tHN5St50e7as8yV2u3Tt/UtfU0jhqllKranB7Sn7rd/5IcvNO75tVGSTvrHrvz6l bWhCXFwBLtEggjVpbqSMSpE08dpAJrp4VZwJJI4WjXO6RlXdTIpdQuwJBGdOQ7tySCOa5IDfLwjP CgkT5hiQzLnDJuXia10y1tNzQxJ5rySSSzMC0zyStvmIkdmaNZG+Zo42WPk7VWtBUGOfy6Y/I0Jt p8y/PX5bky5b+7qvmv8Ag/1v0VeCKJSWUMzjgyOxd8EZ5LfMDzwrKG+q4NWV785PfrgdemaFAx0x nt/+unU1ZJW2Ju3q92FFJnHXA/H/ABAppce/1AH9f8KYD6KKKACiiigAooooAKKKKACiiigAoopu 8ZIz2yDxg/Q55569KAFPpjIOc89P/wBdc9qF8um6tpyyMkdtqrnTizhy7ahsaewih2nAWSKK9a4Z lfb5cIXbubd0JPIGOuefTFcf41sLjUfD2px2Utzb38UX2iynsgGvUuLVluFjtclQktysJtN25SqT t83zGlJNxdvL80aUFGVaFOWiqvkb6Ru0uZ7P3d9O1jqwCcNgHk5wc9eCOM5/pnOa4b4jLdweG5tT s7qCwfRr7StZvNQucBbXRtM1K0vPEL5+Xa0ugw6jb7uyy4+6dp2PCutp4i8P6Vq6KkUl9aRPd2gn gnewv1Ty9Q0yd4JJITdaZfJcafdLG7eVdW0kbfMjirOv6bZ+INC1jRr2PzdP1jTb/S76Ntw82zvr eW0u4iCNyboJXU/KSM9Kh3nS3Tet9ezvbrby6JrsVSTw+LhGUVH2dRRkn0Tkk9Fq9E77Np29btld 219aQXtrIr213bRXNvOgO2SGaNJYn567o2Vv7v14r50/ack1qPw18NZdEllWUfHf4NnUHgJB/sT/ AITGx/tUuV58prPf5mflKjDV6J8GtbvPEHw58O3+p6adG1FILywutIf/AFlgumX91plpHImdyu9j aWtxtbrHMpGN2a8y/bF8Uz+Bf2avi545s7Zp9R8E+DNZ8V6aiKDKNS0Czkv7J4Vb7syzwqY2ONrd /lrKU2sM6yjzyjBVuWUle6s0tFvZW9T1ctw/JxBhMHJty/tCGGV17rvNU76pXWt09Lqztc+mrYsL e3xz+7XeT1J2jOOwHv6emK8Z8PX8MPxz+IVi7AXF34J+H0sa8cpa6j44WVhzzta4i3cH76/3uPX7 KQNZWjgnMltbtjs3mQoxIPTjdjHr0I7fPNlLt/ac8QQbj+++Gvh6QAdvJ1nWw4bp94TLtHzfx5x8 oNVrN0ajdoyrQtf7PNp+KdumrJy+hGrLNoSvb6liJ27OlWoSs7P4bxX6n0Tfq8lndRqyh3gmTjPI eIgYP97J4+vvXgv7Kvw91r4V/s6/B34c+IpfN13wd4B8N6BqsnXzb3TLGG2uG47M4bt35HSm/tW/ Eu7+DX7PHxg+KOmq0l/4H8A+JPE1qqruYzaTps10iqp+UtuQfL/Fnpyc+72knm2lrKSdzW1tIOMM DLGjAn/eLBfvHr83HJXuSxLctJUoRUO7VWUby+UqdvS+7SvkliqWTRbjBUMZmDUX9r22Box5l12j jU7tqzsntY+f/E/hXXPEv7R/wz8S6brth/wj/wAOPAPxGsvGHhgXSNfSap4+1PwNJ4H1yS1Db0ht YvBvi+3t5nUbjdTqpIV69A+MXxG8O/CL4Y+O/iR4uvPsPhvwZ4W1nxBrN4AT9lsNNtJZ7qY46BI1 LhivAGfWvLfhDJ8PvFPxl/aD+IvhO71KfxPpuq+FvgV49t7kMtnbar8LLLUfFlomnIzbSZ7T4uf6 VcKF81ooV3N5OV5v9qPV5/EF98Hvghouv6Hp/iP4s/EjS59R8O+JdNbUbHxz8KPANzY6/wDGnwq8 L288Cy3/AIKle3RbgLHO1wqxlgSa578uHxLjJKVSc4Jyjyp1ZONKCl16Qfm5W1PQjCOKzTKsJWbn h8BhsPVkrODhQSljsU225LlhKdaSnp+7SbWjZ2f7K/w08RfCr4FeA/CPjK9sdV8fLpVvqfj7X9Li SK38ReOdWRb3xJ4j+QBWfWNSkmvZJZNzTySAyM+47vkz4+WVz+0T+238AfgzZpLd+Av2dLVv2jPi +sttFJZDxTqR1Dwl8C9GvBPHJDcW+txx/FnUrm3KfuLjw3p0zlW8sj72+KPxT+HfwP8AAGv/ABK+ KvjLQvAPgfwrpsl5rPiLXrtLaztooYyY7a1iG+61LUrpwtrpejabb3WqateSW9jpdneX01vbyfw7 fE39s/8AaS+LetftH+MbPxNf/APwL8fviRLfXlh4VvdSn+Nvjz4b6JZR6F4I8FPqckFpqPgH4Z2N pc+IfEFxpd8+m3uq3Hju/iTTHSxnA+r4b4CznjLEYHLsrpeyy2lWofXsdUU40qNGlBVVFSUX7Zyq UoRlBSvKLcZWUrm+F4sy/KcRxRxRmmMw9PN6mAxkcqwtZRk8RmGZ1YYOtOlGTbg8Ng8TisRQq2l7 KvToyVpRUl/Qp+3d/wAFrPgl+zFf6v8ABz4C6bbftF/tFRxX2jp4b8OXr3XgbwP4ljludPgsvHeu 6a4SXU7DUYhJq3gvSr208RGzKkS2nnQyV+P/AIQ+Dvxq/aS1PXfjB/wUL+LcnhfSfEOu3vjO2+Fv iTxLJJ4X8Ki+1FdS02HSfhfqFy3h2G10N/Kt9DvfiRo3ia702zX7PpFxZrJsr4Y0Hxr4X+AR8OXH w3uvCPhfW7a0+xXOsWtlBrVz4X0+W2SSextJ7eOfUrLV7iKRvs8lnDJNIzxyS7b5preNieAvGvxt 0bxd498QeOdc0iC7uJNS09fEE81yPEV1ZWlxPDNfreuqxR4jNnHDb+dI0M7Yj8wKtf01hOAsg4Tw VL6vVhGrJRpYjN8XatXdZpc8MLQlGNOjFWai4qTbceeTd2/w2txZXr/WafPNQqNVJU6dlTnFSsua WsqkW2pNXUW1rtZfp1L+1/8ACj4Uahd/D39nTwKnxGsdCtYv7b+IGpX6NpllPiWOODTnv/MjmkUg SRQ2LR6bbwtcR29pHGyqvS/C74o+OvHd9q/jTxNosHiLV7JLe78EaWNZ8mC8upTiec27S/2Lo2g2 LJ9jW/msRJJJbTTR3Cxsqr/PTbazqNle31xqL6rJ5BeH7OjXcGnSJFIFlgMjJFCIpPKHkxs3nMry jy9u6v1Z/Z8+KVj8TfD1kLzRLPV7FZ/DPg7VtGCSGSwtZ1g0/RY7PTLZGbZCyjdqk0ccNqytIszb a+Uz+WT4WlKOCrYic5O7nio/vZyvG8tGoqD6JLoktDLL8wxOLmueMlTT5uWyircyb0ild37cyf4H 6BWmsa5q+o+MvFXj3RPFXg/TrttA1AT6RreoajaXsemKmq6hp+jwxztaSJdTWa2Ml1YxxtHazTRQ tHcSQzL4l8TtW+FP9i3Xi+3+HfiTxdeveSfYr3WrrxFPEL3VYZFTRLa9uL6TTbH/AEW0mkvIpoWt VItftUMs0kMi1PFvgjxxqniHwZ4C07xN8UpfCHi/UJ7fUtH06+vVgh0s21xK6auqS7XsY0TypL6/ 8ra22RfmUV86+Ef2PP2gJNX1O3uPEI0HQtI1LUYtPtdQ1681NHie5kWG3trGYNbyXTW6W80kd81u vkiTyWkWRq+IWOVBRUKipx/iuUYxi4qLTTUrKXNouvfVLR+vVlUnWlOFGtNV6ahUhd8vMoxcFy7P 3NFdPz1PpX9njTNL8S+H/Hdno/w+u/CNx4w1n4KfBr7de380+7QPi54zm8MXWhadp1+9xIbbzZbi Caa122LTeZ5cKxARL+rX/Bdv49X/AOz9/wAE5/Hmq+G9OTW/G/iXxz8GfDPhHw3OzLF4huLX4peE Nc1/S7l1PmG0uvCui66t7IjKyWYmfzF2bq/M74beFp/2bvjV+y5+z74x+JWtfEn4yftG/tH/ALPn xKufC9vK3/CP/Cr4Y/B7x1D4psL0xGRfsEviq6W8ij0WKMotk1tdkeROjta/4OUviw11f/svfAG1 uYyseoeKfjJq9siBwU0nTb3wTpsMozjCy+LHnQN94wCUfMlfiHiHxdSw2WcQZ1QqVMTUwFH2MJVZ 869suX93GUpf34yfW/of0/8ARz8IcV4j+LXhrwFj8PPD0eJszw1bFKny80csjzTrTaip+zk40XC1 RRu5JtapH4EfHH9vn9vv9qNJLb4ifHPVvgj4Dmht4LD4U/s8XDeBbK1s7W0htDb614s0pk8UeIHN rbwrJPca1PDEVkg2IGXb2fwd/YD/AGXdN+Fln+1P+27r3i+bwh4rvruz+HHg5dc1XXfiJ8Vrqyna G+v5LnxBdarc2umrPHLHLc20VtIIIzcvdxgx7/kF0ZkZVADSL5bmJAAUUMdrRgbWRiSzM235lX6V +vnjD41fsKftN/CT4FeFPih4m+K3wN8W/BPwLp3gxLjRtCTxPoXimK0gBuru2srGa/WC7kv3uLiK 7uYLS5CuInG1Ex/H2QcZ5jn+OzbFZxm1GliaGGjPLMBj8W6GBq4iU4Juo2rSdCleahUqQU5OKvJX g/8AoT8Xfo6cE+FHDnAGQ8CeHmdVMgzDNq9DjnirhTKaOccUYHJ6GElUoUMPTUHOjUzPGezwzxVH B1nhqPPNRpT5Ksfinxz+yj+xN+0H4P8AFzfsa/s4/F/4P/ED4f6JP4z8Q/EBfi1qEWg6D4Y0RftF 5e6nbXl9dWr39yii1sLSBbeR7y4hlIaBJFPyR8OP+CkX7fv7Bl3CfCPxR8Z/ErQWeCHw7ZxeIf7S eYJKoTSdT8C+IE1Xw/eLKhgQahpWjWeoqomxfHzVZP1su/iL4N8b+FU/Yo/4J6eAvEsCfFjUrf8A 4Wf8XPGwL6/4m03TJBdz3eoyo9xcaH4U0xLYT3cdy1tJcLDHoVhYXF3qSwS/dV9+zz+xD+xv+zVL 8K/jt4k8NadcfGG50XwP4n8dapai58ZeNPHusvJ/wja+H9OsoLzWPK0fUoXm0extLdrS2to7uW6N ubqcn67A8S5hTzDL5KvSzCEKUYY6GDjJYadf2icfqM6UaVRQp0k1WrKThObainFKUv4F+kDk/AnD /BfE2VUOF804f4sxWJ9twPSz7Gwr8QUMrp4VOrPiuniZ4ujS/tLFy5cFgFSjXwuHSdSUKs50aP4h fFz/AIO8P+Cndj4WttF0T9nr4G/CfUNMY6Hq/jO/8PeMtZ1i712KCOcRLZa54ln8O299HYT2l3fW K6TKIZpZNsUFv5MK+U/snf8AB3f/AMFIfAHxd8NXH7S918P/AI9/CPUvFNhB4y0I+A9C8IeJNH8M Xl/HDqcvhHUvBFl4fjl1XTbGSW402LWbfVLe4mhjjuoZAzPX5a/8FivBXxB+CXx8g+APj7wrcWD+ D7ea/wDDXjZJ5ItH+JfhvV5pTpniuxsCq28d/NGPsuvSZ8631y21HTl32tnbzS/Sf/BED/gmb8Lf j5+2B8CtZ/bS1s+E/g/qmoad4o8E+FLSewlPxU8UWM0Wp+FvC3iC9WZodC8P63NAkzqzNea20cGg /ZQmpSV/SGCzXA/2bg8XiJxw6xLpww/tK3Pz+0aglFtv3+bR3s00+a1j/HLLa+b4qrTwmc4Khlue YqviaccsUoKVadFznJYfRSm5U6brQpxjpGSjFPS/+tJ4N8UWPjTwl4U8Y6alxHp/i/wzoXijT4Lp CLqKw17TLbVbWO4Q/LHPHBexJN8o/eK+4YWumJPIwASTtAGRgcEnIx1HXjv265mmWFhpWn2Gm6Za xWemafZWun6dZWo2w2ljZQRwWtpCg+SOGC2ijhjVP4Y1XnbWip4GPlHJ54IHPfrz9cc17lPmScpR 1irW1tLRcsnpe7vtbbrbQ6ZJX9nzKMl70vJKSvZ7X08t9R5hQ9Rz8xJ68sMH/gPX5T8vtVe4soLh NkqK6lGjkUqm2SJwA8TAj7jYG7ndj5d21mFXaYXUEqSAeykjJHqFzkj8uhqwSUbtbvXfd7+n9eR5 nqPhfU9Gdr/wTex6dciGYDQ71JLjw9fMIz9njFmhWSwW1lzOq6PJYzTyOwkaQViX/wAYtG0BDZ+I 9L1nTfErXqWWm+HLO0m1rVdfedj5c+hW+nRKdYMVmJdS1SG1WR9Hsbe6u73bHayOPZJOeBjORuzy CucMO3O38OorifEvhPSvEVhJZ6nZxSR74jCQVja0eCRZba4hlwu2dZ0imWTcrQyIrRszLSklUaa0 mre8u118UfP0/Q1pyhGXPVjOrSg25wS96W2kX1ivtbaI8w/4Rz4l/Et1PjfUZvh14RuoLJx4L8J6 j/xVmotFPqS6nZ+I/Gto/m2en3MI0K+01vBjeHdbspRqFnqWqXUMohr2Xwz4T8P+EdNi0jw9pdrp mnxGSQwwQorz3UzGS6v7ydg1xe6jezO9xf6hdSzXl9dSSXV5NNcTSSN41aeKvEXwynt9O8T/ANoe KfBguzB/wle2W813w3FNtW3GtwqZJtX0m3cGNtXtTdan/pSG4s1sbNrhferXUbO8tobyxuYbyzuP ngu7SWK6trmNv+WkE0DyRyoGBXcrfMQxXNQ6DjPnqaye3a2m62vfotL7dltWx1Wvy0YJUqO8aFJO NOV+W095SlJWs51Jynpa6VkWCuQBtBHTbjG0EENkc5BB+624Z6cjgLhQgZk5YJg7VGcHGdw5K4GF HJx7V5jrfxV0Cyur7SPD0Nx478U2jX1u/hjwn5F9exatZWVxfjRtb1V5odA8JX91b2s32NPF+q6H FcSKIopXkZY6QaJ448WSJceINYPhfQ5Ib2JvDfhyR01idJ30O+0i+vfE6eTeaRq+lT2mrafqOm6K 19o2pWt5GxvpFUrU+1SaUYuTemv2b21a+e1rfyk/VZqMZV2qUHK6fNabtZ/w/iStazaUZPTm0dtD xJ8TfDfhu+XRWku9a8QOllP/AMI94dsZtd16OyvruWxj1afSbASXcWkx3MM0d1qUifZrbyZnmcLG +Me2sfiJ4vcP4hubfwRobxwuui6JcQ6j4ilJRobyz1TX8TactjdRyvJBNoVrpur2kiQsmooysG7n QfCfh3wtDcWvh/SNO0i3vdQv9Wu4dPtYbaO51LVbqa/1O9lSJBvub68nnuriXh5ZpZJGYs7Z3QDG pIbg4/iAQY+6qgn5S3CnnLMRx60oyk7zlbvGPw/Ztfqra6LT7y3XoYdL6pR5pqKTrVrTqX0+CHwQ VtLP2j0upLZ4uheF9E8Ow+TpdmlvK6xLcXk0kt3qd+IS5ibUdTvHn1DUZI/MkVZb64uJEViqvtxW 8qgAHIX7xwAq8kknkDjk5PHzfxbuaj8wAnAOVwOmTkg9QN2Bx944X34NKJUGM4CtnnJP3c5zjpg+ n9DTcYJpRfvbLe+nS2um3b5HLKVWcr1W5TnqrSk21pdvzvvbvb1n5IIOMnI4zj8aiaUJnOFGQo9j zySf4cYXP972PHLTeMNIMhg0kyeILz9+sVtpG26jNxbA+daXGo5XS9OulwwWDUr20kdlwgZ/lqeJ Nf1H55mg0a2Yoywov2rUGiZfnt7zP7i2mV8hZbSe4X5dyOT1UpJqy1uWqEoa1Pcg+s3ad7LaKu38 46aX1NyS8SBN9w8NuC4UeZIqjJbAAYnazEYO1eQD1701Lp5g3kxMNpwDNE8aseu5SSA0eM/Mp9Pe q9ppNrauJVQyXJUobq4Zp7oxjnZJcSfvJBuLBS33V2r/AAqK01Qg5J7EYHvjByRnOM//AF+auOy9 F+RL5FblvLTeXu66dF/n8lYYsbEAysWP8SgkKOvTvjOD1qYKAMDge3/180DIwOvuTyfwxj9aWmSF FFFABRRRQAUUUUAFFFFACFgOpoBB5FMdSSCPSngYAHpQAE4BPpUE6sF3xAs6fMqAj5/bk9P51ORk EetG0ZB9BgUpOybC/S+/TvYghuoZ40licPHIiyI2CCytgr8rBWBwRlWUFf4qZICzMCAQCOvJXjJ4 HXkDb9D7VgR3P9mauba6lQW+ru76c00gJ+3pFJcXVnGj5kJkhinvlVWCRx27BV7V0YK7RjHHIOSe MA53E855xy3YVF1KLvp6dL9fVO79H11KnFxats+Xll53jdfPVdu+x4P4DvU8M/EXxz8LphDbW9zH F8RvCtlZ2dxFa2egeJrqe21yG51GaeZLnW73x1a+Jtant4FjS1sNStAVVfmb3YglWGFyxyVHJOcf MOnf5mHQY9+fl/8AaPun8CSeAfjlFKy2Xwy8QCHxebvWG0jQNO+HXir7PpPjfxVriB4l1H/hEtEj m1rSoJmZI7tHdV3uzD6bt7hZ4IZwRiWNJQQc/eQNgDqpwRk/xE1lQnrUpP7Ljya3coTSSb63clJf 4Ypo9PH0nKhg8wik4YiDp1ZODjGni8PyxqU09bt0pUKsmtHOq0rWu/nz4TXNpovxY+OvgT+1rzU9 WXWvD3xSnhuFK22k6N8QbC80LSdJsSRt8mC5+HmsXTqpysl6WZV8xd3oXxc8H2fxB+G3jjwbfxLN ZeJPDesaVdxuAytFd2U0Thgeowc+v515V42udR8J/tG/CjVLJtL0/wAL+O/DHjPwr4yuZwiX+r+L NOufDmo/DHTIHJDSmHT5viNcLGu4KNxVetfSOoIDY33cNa3KleADmFx09W/xqKUX7LEQk23Gc4ct 9UlCMoq9lo1JdO514lzoYzJ8wheP1mhhMRSlbWNTDVFhqjldu162HlONrWUloeM/s1/EaL4u/An4 WfEmBt0HjPwT4e1+Eq24FdSsIpwQ2ORhjtPXOCVxgV5/HeFP2vp7Q5UXHwmtnCtwW+za7cqW256r 543N/tDPeuf/AGA4bLRv2Y/AHgXT3Up8KoLv4VXQUljFqPgGZ9AvUZiW3Mk9u4bdn5vpTru68v8A bf0y1GQJvgpqEuG7tD4isV79T++JHf19K5Kc5VcJgKj09q6FRt2bUmo3j6N3e1/nY954GOE4g4xw fImsPgc6jBJpqEadSLW1tVFrZNb28/X/ANoRPCmqfDa+8H+M0gbRfiTqGl/DV4pyvlS3fji6GiWk bqfviSa5VGjyN+dqnmvYpCbexHl4PkwIEBI24jQBTkjp8oIznpXxT+3Tpeq634Z+AWk6HLKuoJ+1 n+ztrs0cTsrvpHh34iabqesBtvLQx2kTNMp+Xywyt8te4ftC3uvWfwE+KNv4U1aDQvG+p/DvxRoX gXUp7mG2Fp498QaBe6L4ISCWY7RdXPiq+0i3sUXLTXcsMKqzSIrdcqiVWrz0mlCnTcZ82knJSbjp quVK+rXxXSVzwoYScsuySCqOaxWNxbVKTulrhaUq1t2p8ji3Hf2bTd1Zc3+yhr8njf4P6Z8UNX8D x+APFfxL1vxR4n8YaGYPJmOtWet3fhdL+6BBLXGoaP4c0mfzGLM0Jh4IXj4v+Pv7Wnwe+CPx6+Kv x3+LvizST8Mv2avAXh/4eaP4dtbBL74gN+0T47im8Val4e8C6ZLPatq+p+MPhd4k8AafHGt3a2Ub Sf8AEwu7G2Wa6H098Wv2kfAP7Ff7LGnfFr9oXWodKXwv4S0GwvdMtQj614u8eT6JCT4b8NaZEPtG oa7rGpW9/NHa2sMrQ2sd/qM0f2a0ndP4utH8Ra/+1T8ZPiP+0D8SrTWbu7+IPj7W/H2meHNavBe2 nhfRmhh0bRdM0rT7VYdBh1Kw8D6ZoXhG68WRaf8A2pq9rpELR3whWFY/0ngPw8xPEsI5ljoVcPw/ gKtH6/ilZTxdayksNhnVupVrqLqTScabafxHj5vxPlmT1s9lGpJ5jjKdbC5Xh6c26dKjXrRp1FOU bydClhVKly3XOpWbaTR6z8Wf2r/jp/wUL+Lknjn4kaRqlt4XsNRll+C3wB0eaW78N+FIIZGWHVta uZkt4/FOtSQBYNd8Ratp+n2crySTaPoejslq0E2l+C9L8I3j+Lfi7qGjD7XqhsIvDehTR6pq8jW8 QEtg1oxWSK3s1lWOFWmZvOn8yOSaOGSOPuNR+Jvg74daJr3hb4b6E+k+MLq1fT9S8RXEllNcW0N3 GYLux0iaOFb0y26SO9kzXElvuiX7RHNN5Ug5r9lH4JTfE7xJ4v8AEGs3ckPhfwhb3WoeIfHeqQCe e0Z0UWVtb216sgbUpriSaO3kVfMg33DR7Y5JFb90x+bRyrBVMNkuHWVZThFGnhaFNxVWpCmoqM51 FeUudXlOTbc5XberZ+HuhWxlZVcTUljsVUcuXmk50qXM01FRu9YrorX20PMdZj+F6a7JrupaFJoY m1Bh4a8ORWsWoawllHcubEPGkUay6jqEeya8kmjkWGSUtbiRVWNPvj4Ofspaj8VNDt/F/wASPE0P w58ER30j6XYX0mn2H/Eua1nKobN71VV5ov3Um6RtsjJIv3fLbJfTvhnolxpGg+Bvhs3iv4sazfrp FjPObnWNYae+hi/s/UIbmaWZdO1CNZY5BtRbOzULHb28LRtXxz+1n4i8W/DoWPg/xWdSPiFx9rut ButT1Ge201lYAWixQ3S6PNcqSI7iNbPdbzfK22bay/m+a8Q5hmNOFJYybhD3lOrUclCUlHWnTlsl Z6p3vZxPTw1DDYZqpPDOs4RUJezleKm+XRxlLlWtrJJPfU/QfV/hR/wTT8G3Vrpt3po+IPiqfUYr SLQYb97uyvr8llAmgM+mrIsxLSeZHeqqlf4l3V9OeHr34a+E9Pi03wvrPw28Bac1xZxalodhb6Rc 67o+nW6omnaRAI0kktmaBFmur24ur77PNPIwYbRX4K/syfs9fHL4+eJLzx/pGkyweBPh/LBqXivx jrQgh0bRLLDSGwsWuY/LuNV8tGKwhmuI7d5Jl2xq1eu/FD4d/BCHWtKh8PfEnxH4q8X391qureOb /wAChrPw9a6PeXU/9ieG9K1eNJJNXvYbUQ2viC6hupIYbgXC+VDtZR8biqs5y9/EzrVUtZ1Kr97V LRN2t06at73VvewKq10pUcFGCj8cXaLa93aT0lfpv1uz7t+Kd/4U17xlr/ivSvF3ifxJ4KivR4ai mglHhbwlBqFixuIJ9L1WJ7vUtSiWztLi1uLWO1t4/OmVftE3yiX3f4SfHXSMaP4cbSdC0/RfA2ga t8QfF+vrcNepF4P8HW8s08cpuXkk+1XmqajounreXksckn9oSRRwvt+X8W9V+JfxK8NeF/DfhjR9 QlHh/Stfnm8vUdMtvE0CLqLveW7Tm4tpljltTGsLQ2f2dVmZVZfO2MvbeHfGN54W/Yy/a88TzjGr /Evxd8Jfg9p2oiWB7ufTvFEvjTxD4rghKR+dBp1zN4T0BobVW3RyW0ijK7lr5DiPNpYDJcbiIybq 4ehUVGHM+ablFxi3G92772tfpqfXcN4SDzSnXxdGcMJgqc8xxqUXUi8NhaXt8Q9eb3lCEoptWvur Hc/sC+P/ABH+1J/wWH+Dfxf8UiW4vvE+q/GDx7BZXMu2LRvD/h7wtZv4T0WG3CssEfhnRbfTtNhj jZY5ZLTz2XzJpM+Df8Fmfiyfi3/wUg+NKW15JdeH/hPpvhv4V6Mu4GK01XSrR28bW8K7tqE69Zwb 8hVwmSCxUUn/AAS4+JXjD4fftpaJ8W/BHwg1v4s+Dvhd4T8c+D/FXiDTdb07wl4c8PeLfGuiRWth pFz4q16CfSZdYe3ltbq70eMpdWkN3DKyMjIg+fE+CPxA+Mn7VH7VukftE6f428AeI7vVdc+K2s3f w71Dw54wuLjW/ib4usYtM02w8R3ek6noE94lzrMWn6focdp9tvNSmtY7VlZlUfzNxT9czbgyGR4K r/woYzMY4nMIVHy1I0GouU56axcmrtbcu2x/ZH7ODxHyjhDxPzTxu8WFjMLlmHhncuGYTpSlPFSq 1qFHKqOFpNctKmsLhkpcsUk3zJrmbfw/qniaGzu10mwt/wC1dbmAZdPs5iFtoyzKk2q3CpJFbRDD fulJmYJny1Rg1a2lWWtz3VlYJBf+IPEesz22n6ZoHh2zkvL2+vb2UQ2tlpdqitJPO0rLHuYRRhvm ZlWv0I/ZI/4JQ/E7xX8W/G+n+OPiLGP2btL0bTtY8EfE3Q9DttL+IPj3VNWvtShvvDfiK31a3vLb SNe8InTfI8RxXliZ9uo6XJYNaR3Uscn70/Bv9if4Kfs+xabq/wAL/Dlp/wAJ/ouq6P4i0zxt4rUa 1q0mr6Hd/bLHz3l+XSdKmugV1K10WPT47yzKwt8p+X8UlwbRwmbUMDjsRQWEpyoPGYik1VdRTVNy s7KMZR1Tg1eNrN3Wn+zvE/7RDhvF8K5lmPCuWZlmXEWKwuKWWYDG0JYDLcDWSccPOpOd54l3tLmU nGTacYpb/mx+yH+x54L+Dv7QfgbH7SXiTwR+1xoWhXF38avgW194Y1Tw94h8C36Jdx+Choun3t1f 2Nx4b10aRfX2vtqlrfX02meTNoNjDcTLD9p/th+A/AUGveN/2mr34f6l8Z/jF+zF8Btb8X/A34M2 XiDSNFvfFHifVtc0mw1fVNH/ALc0rVtNiufDtslreTTf2VrWoeVKI7CO3Zpmn+Y7P/gnl8Dv2UP2 x/jN/wAFONU8W+PfCdx4p1PxF4n1Xwz4s13QvG+i6X4z+Kd+dC1HVLa90fTbPxNd+EbOfxBcP/Yu q6vfXcX+jzLOLqytpYv078PaXoPxP1vw98QNSsfBHjrRdN8OXEfg3x3beF9W0ptTj8RyWkuswW2l +JLvULhdLtzpemCz1CbzFupnvY7OSPybhW/WoSybIc1wdbK6tPGZfgaEaCozShOo6tOKcHazlBSk 43s7LXS6t/jzxRnPG3iWs0z3jGOKpcQcQ5hPFPMG6lahScayk1zyco0IQi7wpxS0W2jP57P2x/2d vH3/AAVf/wCCU+iftG+P/hgfh3+1T8IrHxh4u8I6d+9vNY1rw3oOoX6ar4SvbqbT9IuL251C209j Cn2G1tYNamurq3Wa3kjZvyk/Yk0/xn4a/Z4+HFxquqT2fiCGQeJPDWo205nu9Ht4rqC/8OXUE5ZW hudMkiimgjVlW1njjQebHuFf3P8AxV8VeFPhv8KviF4x8UzWOleDvBvgnxDreuzzLFb6dYaNpulz veSeSQsK2pijMa/LtjwMda/iN/Zes7m0+BHgIXcDQm80tr+0tpJXd4NNvZGe2tBk5XbaylVjP+px tr0cHnFbMslxuH9h7LCUcz9thHHV0Oa8pwpyk5PkhJcySekndu7d/wDPj6bmY4nw7wPAGd5Zi6az rD55gcbUrxnGniKzwFv3kVT5JqlXhUnSqrR1I2UnZH+i1/wTX/aeP7Vf7Kfw58f6hMD4w0m1k8G/ ECBZDJ9n8VeHIoY7gFyN0jXVhd6dfSzMqq81zKoUKnzffm9CBgj0znAzkrt+rMDt/vduK/l3/wCD eD4j3dvfftIfCa4uWOlwyeCfGuiWjyExQXuqDxDpviGSME/J9oj0/Ql9zD+X9O0EtxJC8l1ai2kS WVUtjLDcbVgndLebzlXy0E0Sxz7ZFZrfft3Ky4r9u4Vx9TH5JhK9V+0rQi6NSb+Ko6T5OaXW7td9 fM+2qYqlmeEyrO8N7JUs8yrLc5SpRUacJ5lhKOJr0qcLtKFDEVatKMdVaC2SsbIIxnORjOfX8qrt DG0q3BQ7gpQPk8A9G28Y/n0oRzjIG0cdcf19P89Ka0rDjKkHn64/Htj1r6MxEkbaAAdwAyD68k4/ OoZJlkXy3QMNo3DjB7gcnjadp5qKVyemMKSCPTn9evX3471nTXAVtvAJ4ycgE44xz19fYfQ1UItS 5l1815r1/wCCaxh7ylf7PLy9FJ2u+mulrPqjP1i1iuoWguVjmhkR1KugESgqV2Oof96rAnduGefv fJXyr4s8F3Wg31vLp2p+KpfAFzczHxr8PdC1KGxs/EdlewR2d4IPOtbi6jW3towradp+paUNWjXy Y9Q0qUvc19TXEpCncgcFmBUdTweAfUH+Wc8VyGqRRTwvlVYHI8kgEjPY5HXr/SuxKNWPJNNN7S/r T+tu1RqVKLSg43ty88oQbWqd4yasuWys47PWOp0nw8g8Ax+H7Sf4eQ6QNBeC3tYZ9NSQSypbRiGC LUprhf7Rnu7dBtL6qz3mS3msGdifQwQoyevOR9PX0/8Ar9+3xrbXWp/DXxLceJNHgml0fUHU+KNF i3Ml/E7jOtW1uBtbVo8iSTyFWa6HmW7bpplevZZPjR4Pu57Ow8LS3/jPVLvUrTS7mz8KWdzrS+Hr vUrC/vLCbxjLYCVfCulTNp1zZyanqojs7e8MdvN+8ZVrirUvZTt9l+6n9qXL9n+t18xKFfFTvGLq zWspylJtR0vKc3dJO97t9rnsIZQevT3P0+8Bz61zXibxf4Y8JWdzqHiLW7HTLe1tLm/kWZzLdfZb SN5ri4g0+3SW+uxCilmW1gmfjhc15B/Znx08b3D/ANrarpXwi8Oy2lu8Nn4agsPEvj2z1W3v7j7S l3rmqw6r4MuND1OxWBlhs/D0Wq2skk22/STDL2/hb4U+DfDFx/aNvps2rasl7qF/b614nv8AUvE+ t6fcaizPfR6TqniK71K/0iwuCzqNM0qez06NX8uG1jjURjnjN8zUY8iv8M9HPa7i9N+zs7ba6rse GweHXNiMUqlX3X9Xwdql0uXmX1l3oxlbbkVb+9a3vVYPHPiPxJJCfBnhG6l06ae1B8SeJbpdG0y4 0e/tZp11rQLWG21C+1uW1ljtlbStSj8OSSRzs32xGQbr8PgS71ULL428R33iKSSCKO40uzhOh+GB PbXEk0F3a6XFcXupWl3saOG48zXLyGcxNIsUYby19HRc5AA2cbSAc5HJLAcE8hVyN2AfepFXk5Xa M8DP3sckkEcg8U4w157uMtPv921vx3fldswni4w93DUoUO00nUrW3vOpK7TtZPkVNXs+W5RttPtb OMpaWsVqrFmdIIo4xKz8bpNipvkfPzlv3n3v3nTdfTKj5lC4HJzkcdOvt6d+KAQDhBnI9T/Wms4B DEgY4+b5VB6nqeW/w7Grimnq1735/wCWupySk56y5pN/Nu/e2vnrb80SKVyQD/tHr9M5P0pSQOpx n6/0rn7vX9Ntnlh843V3CnmPYWMT3V60eSN8dpCWkkHBXKq36U6O61G6BNvZ/ZFkiEkE18zHduKn bPZxmO5t3VS25WkXbgq3zYBptLdopQlZNpxXaXuytvez1tr527aG8WUYyQM9MkVG08SnBcZ9OT/I GqItZHZftErSIUU+UmwQiUZLOhA88j2kmdRnGO1X0jjQYVQOBnPJ/M807p7O4mktmn/XUAzn+Ar/ AL2MfoaeM98fh/8AXpaKBBRRRQAUUUUAFFFFABTH+6ecDuR1HU5HvnH55pWyCDnA4BH4+n0/Gmgs eT93vwOnelfVrtb8QIEn/eiF2USclR2dOQGHP3jj7vUfqbQOcjuOvpn2rPvbWO6iG3Mc8B8y2mQ7 WimAIDAlWUKwZlbcrZVm43YrL0jXrfVZL6zDCDVdLmEGpWMg8uaBmRZIpQhP7y2uoXS4tbqMyRsj rHJtuI5reNbyS2Tja3Te3/DlOF4uolpHR9XH+9tqtbeTYuv6e+qaZcWtvK8F2x86xnJkCW2o2xF1 ZvKyLuNsLmGJriPHl3VuJLVtyzbWz/C/iKPxFppnZGg1CzuptN1nT3ltpbrTdVshEZ7O8FlNcQQT NFNBex26zNttbyFmRGyq9dhSCpGQNx5yBzwSRnPQnj3rxjxJcSeAPGtj4oVZT4V8Xtb6B4qZRbpb aLq0TSyeH/EM7vLZxWNhdLLqGmeIdQklvbq6uW8MWtvaqsc7jKT5ZrS9N/H5pctv7vxWv6s6cLT+ sxdK160YuVGP801a8F/LOUG+W0byklGN+e8e58YeF9H8Z+F9d8LeJNOtdZ0PXtLvNM1LSryKK4sb 20vIXintru3mys1q6MVkRlPyn7tfPf7H3jnW/EnwuPg/xrqOo6t8QvhJ4h134VeM9X1mKOz1LxLq /gm9k0VvG62KySS2+leMUtn1nRpJVj+1WUgkjG37v1VkyBSr5BOCwyFKk/MuCPlZf4WO75j9cfAO r3T/AAO/bm0fV5jFZ+Cv2s/C48LT3Mskry3Hxo+GGhXWseGbC2jLC10/Trn4WaL43ubyZl8y81az sbdNzyYHPiaioVcPVinaVRQla3wVXBQfop8iXZTm7ansZJQWY5dmmTNKdenRlmmEjLmlN4jBpuvQ ho+VVcHKrWm2rOWFprTQ9A/bThtvDvwy0D4xvpV9rmpfAr4heEfiTomjWCtJPqOp/abvwR5Tqh5h t9P8a395NkYVLYufu8fWccwu9LM6FZBPaGRXVgyMrodrI2drIw4Rl+UjBGAVrj/in4auPGvw18be F7RkF7rvhjW9MsZJVDLDf3em3MWn3DKQQTa3rQThuqtGrfw149+xx4sTxd+zl8M4J9Uk1zVvBegn 4XeLNXnJaXUPGfwovLr4beNLmVs/NI/izwtrDs+f3u7dxRKbjjKsObWrh4uK6qopWk+V6WcJ09Fr pqna4lB1uHsPXS555Xmbo1p3i3HC4ulTqYeDd+aSjWw+JcXovfto3Y8g/YHMmj6X+0n4OvZAdS0r 9rT9oHWhAWzJb6N4w8e6lreguykfKj6e5kh5KtGFx0q3rl0Yf+Cgngu1zzcfALxfOCcfdh8UeGkJ I7bvOHPp6VzX7Ot0NI/bq/bt8GK7Q2aSfs++KNNg4SNpdc+H2pza1PEmGBMuoCIXDfxu3O2l8W3X lf8ABSj4XWm7H2r9nL4mSOoOAy2vi/wBtyuP+Wfntt/3v4q8+lJuhhIp3dLMlSqtfDCVKu6agtdb 2VtXrfyt9r9V5eIM8qxjLkzHgmWbJ1E+acMfk+Exspq9r3nUk4/JI9G+OPitbb9rL9jrwFNGlxa+ LpfjlqTxyAFBdeDvAem6xptxg9JLe4m3I2Mq2CuOK88/4KS/Ej4VeAPhL8PLT4teNl+H/h/xF8aP hjrEHiWQyrDbv8HfFOnfHnULFlt1eaeXVtC+GGq6fZWFvFPfanfXVtpun21zfXVvayyfFRI/EX/B RX9l6xjYtJ8Nfhp8YfGVwgY/LbeN9HfwfBI/HKmbR5I13MuGVsbjX4R/8Ffv2vvC/wC0F8Uk+H2m waTrvwZ/ZV8WajeG6juFvW+Ivx5i03U9CVbEIiW8Phb4eWt/rEWqP9ov49cu9klnNax7Ff8AQfDr gzHeIPENfJsHCrCisdF4zELX2OHp0sNzN6WtOcvZwjFuV5uS+CTj8xm+Y4Pg98FZjjYurSqcPf2j GhTmk6lWtmec06bbckocvsaUpJ6NQSd+Y+Hf+CgP7YWuftP/ABB/4Xf8TJ9RtvBGnXupaJ+zf8Fp bj7Je6J4SlntzqXi3WNPjfdaa34zEFjcahqV5bwudP07TNNmaH7L9nj+O9S+KuozeCtJtrOC18J3 vj/xBaeGvB9ot1I5jtIrs2974guFjDCNbNS0emWq7reT7OrWskkzNGvyf488Wp4kudW1m9vJdY8T 6/eG0tEkmkZNDt96hVigCxoXvCy2+nxwvDDaw203nrM00bR+52+j6D8T9f8Ahq+naulhb/BbwRaX XjiWeCS3is9Rsr+8mEMkyG4jeCK5V476RVWWFlaTdIu0V/opjuD8q4Q4fyzK8Ph5So4FVZzhSjen CVOmp026bt7SVao2pyknOpUbvc/mOvXlmWNxNWMk/bSqWqP3pwpymrRhLdWvbTWysfSHgXStel1L T9NuoZLt2uUmnuZbiBYoYJVdLy8S8MpWzlk3G18tmjbzp1/u7q+5/jl8aPhj+zt8OdDfS5rzw9Dq 1npSX3h8anam5urm1S+a8c2sdyy6mblpraaRWaSRZFt2vFhVLVpPh7wd8b/AbX3iGyg8Y6Dp1h4f guLTVZ1hvrpb3V3Q/ZIUv4bGZZFmvFi092ht/lt7ma6WMtGtfBnxN8PfF748+NNc8T/EbxE9jZae Z4/Dtk9s14yW+1I7e10ixtHjjSznhS3kuLi8khmXMLbmZmhj/n7KuH8FnefV6vFGLhkeWZfOVSft qrozxVNyXLTp0m03JtxUklJxV9LMfPPB4OdLCxqOtVtCM4xckpSspvZ7vzT2s7H154J/bN1rxUfH 3i3TtPHhWw8OF/8AhHdctri7sfEVpLLuKajeXFnG2mp9ukLRNJNqC3FqysYY2mXbWd8O4rb4wa7B caxFbw6PNeWl5PqFrqTPdGyvLuGK6g0yzjaSW8uGaYMsjKqWeN1xJDCkki/IGh/sPftX33gPxJ8R rL4QfEXUvhjoMcF14i1XTWistMuNMhjE5nXzpV8+38rL+asdxJGp3NCzfM3tv7P+s/FXxr4Kn/4Q bSdF8C+BvAljcyhPDot9LuruCaVLnWNR1rVtbudUuNav1s4rnVpm02302NprUWsNiqzDb6HiNw9w zgOH8yz3hfE5XisNKNBT5alGX1ejTspxjFS5vbzupOy5rN69/Lo0cfVxWEhiamKpQpTVRRXNH281 b3ar/kv0Se19j9J/jb8TfHfgeW2/Z68D6zqHg34e+CniiuPBcO/S4LnUL+0srwX3iTTZDDDrGoXk UlvMt9P5yybYVWRjGtfPXhjxEvgrxlcebpV/4jn1WynufEepGM2FhpQXfPNdahqmom10+7vZImW3 j023uJm2xIu3Lc/HunfG3xdY+Kr261W5l8RXrXFxdnX9Xkknu7wJGkEbymVZvMkkgSGKNZJvLVUj EbKxZF+H/GP7TniHXv2gfDuueO7q4uvhtoXizSY/EngtJ7ltLl0C1vI7fV0ltrCexuJb+azjaZma 4kjt5pGUeZt21+IcCcLUuMpZnicTKcsJllF1pU8NPlrVHHX2UU2ne2t30fc+szPOM5wFPCUeH6eE WNxVqdbGY/mlRwUIyjHnpU4RanKy66p/I/cb4Z/tN3P7RXjNPhTpvg3X4tP8CJqLR+LJre0s7FFs y40jULWWynmkuBboq+X9hW4mk4+1LGrOy+6/HzwTd+Df2E/F8ZtnSS4/aY+Hcj3sRMqXIfwl8QXh JOFeF7SaV5j5irt+2M2VbdX6YfCH4UfCX4geFvhp4s+EyaVqHgifw5p2o6NqGk2Fto93Bok9gsmn /wDCRQyW0F9c3cMLL50dxHbzMyt5kL5Y1qftp/Bq18T/ALFf7T3gvwzbLf8AjzSfCVp8U/CthGYW N14g8AW+owSWNtaxeXNFfrpviSS6ZdrzSQhWZdqrj+duOczo5tjc0w2VYPFYDA0W6MqNapOdVOi9 bupZ2c0n7t7xdrPr+/cEZXiquCeXY/HUMdmmeYLE5WsXSSpwpvNKH1ZSceWyip1V10XVI/Iz/glz +0HrrfshaT8M/gv+zL8UviVd+GPHnxYuPif420i/+F+iaDP4pn+Jniy9NvYj4g+NPC934qln0+az h/tCxt7zTY5B/Zst4s1nNDD+Z/xr/aV+LPwD/ap/aV/ah8Z/D3xL59/a6N8OPGv7OHj7W7fwx4jb 4R+G76zn8OeL/D15o19fWWn+JLDXdL0HxfoGqeHbq704Jpr2tnqMlvcqzft7/wAEgfH3giy/Y58J eKdEih0nwNpqyaf498R2WnSxeEPCnxMv76bVPEFl4p1XU3sJtH1u91LUHvruBY9S0uaS8GoNqWnx 3f2W1/Rv43fsv/Az9o7QtUtviP8ADvwj4vvdZ8N6h4csPEt3bC51Cxgv7GWysru01W2mt/tX2UyR XNilx9thR4oyvlx5z+K1c3/sfNMRLEZZiKmGxMIU26k26lWEnHlpwaUUlKUL3i1b4ktdf1yHhxnO a8O8N5DlPElDK8Xw9mOCpY2UKCeHnTwyVKtTqqF21KDlK710V9JHzH+wH4h8ZxfCkeM/ifJ4Y+GH hDxtonh7xN4I+HniD4nWvjj4haQLqPVL/W/FHxI8aXl1JZz634msbvQgunW+qXtvp+n6FbrcSQzN 5K+yX/7fH7F+m3lzp037TXwevdQsri4try00fxvoWuTw3FhM8NxG1npV7eSB7eZHW4hjVppHWWRY 23KzfyL6noK+GdX17wzNc39unh7Wtb8PT2zeItceOKPSNQuNOtImjOp+WkUllHE022NljV41WPa/ y/pr/wAERPFngf4d/tyQfA/WPAfgDxF4M/aX8K69cW2meIPBvh7xTNoPxD8A6SNQGsaPcX3kXUTe JdLOn6XeQ+bFbSi0+0lTdSzTt8dkuJyvifiLE5RiqOKwjqc0aDhFTpqqmrRqTvzt2la8m3dWl3X+ gPin9FXiXwl8FcH4m4DibIOIctWX4DHYrAUa9SOO+r4yjTrSrUouKSdNybdNbRTUbyP19+JX7RP7 EHxe0fRLHxn8bvAOpeGvD+u2fip9Dm1+GHT9autOjkNgNXsbgx/b7S11FrbUPsjRybbq1hby1aPc vFeNv+Ct3/BPD4ewnT/+Gh/CviXWoIXh0/wd8NdN8R+O/EFzJaRRoNNh0Dwho+sNauqokcMl8lpa w5XdMqiRl/fm7+Bnwktop53+D/wi02C1ikmuJNU8B+FdNGxQTM8Mgg1NYkZd26SZFjjB3t6V+eH7 TH/BNT9iv9s/wV4vu/CPhHwD4V+JfhDM2gfEn4W6FZeHNZ8M+KLqOVbKaLUrTRLSw1rTprm2gg1S NLe8t7i0e4EdzbTR/vP1ePhpglOKlVnioxpvkUans7cqjZ1Oa7Vu9lp16H+feceKWe1Mkrwymlh4 42lhprA08TOrLDyxTinCm+SEklOSUdVZN6tLQ/lu/bb/AG4Pix/wUA0yP4ReFPCXiH4F/srXN7Bf eMh4hu7WD4p/GCwsGWW30S8t9Ju76z8K+ErlkMd5a3GoW+rXsbzW99pcbAq/hltaw2VtDZ2kMUNr aRRW1vBFGIY4IAnlrCIQEWExx4Vl2r833h8tSXmm+J/DXiTxx8PPHNsth48+F/jLxD8P/G1mqNCp 1rw5fz2KazBbyfvItJ8VWcVr4m0Pc0jS6Nq9nI0mWapWXcXDAqG3PKQ2MgqzRop/vYBXcwbbu3Nu 53eBiabwijl8MP7ChhJypxgnLkUnKDnW5tpS92N9bcr00P8ADjx38T/EPxO42xOH42m3jcuxzwGE ymhBqnhLVI02qVNazdRpNWjdprS+/wC73/BAGzu5/wBpL4y31vFIbLTvhxolvfSIDtWe61W6ayUt jrJHa3e3d/cfaK/rnS7EqiQAIdzKBMdpIyI88jk5XGO/TpX84/8Awb5fDCbRvhv8dfjZqNu0Efjr xRoXhDRpJUK/6D4Htb+5ubiKRvllhupvFUcYaMbTJaMNzcqv9EjyqQu6RXAO6MPwBk7xjbjnOTz6 /n+0cBYerHh7DOrHlU3XqRUvidOVVqE+1pqPNF7Wdj/TrKcteUcL8HZNOfNWyzhTJITjJvmVXEYO lip05Xs1OjOv7GcJawnCUZJWSNF7sAHbgNGeT2YcgjOf84/JrXZw5HGec8AHgcnqawLm6cswRTMr HJKMERD/AHiD8x28t9786pG6fa4aQ/Kd7SBwQQAPlCbeAvT7xOK+7jQjJJrT/t3b4ddPX/LqdJvS XOEDGRTlmHzD5wNo6dMjn/JrElvUhiCqGztYKxJChnOwY98sevb6Csi4v5mZtspUbd0aPGI19C3m Evycfd29OfpiTaks0e0MQI/9Y4G4KQc7kk+Xcy/e27R069qcYcrtyytH7X3X5b6/P9DSM0kk09P6 7o6KS7Mq/vJMhgS205bbErcD1LZA69/zwZfKljVZI42TMMkSzcMkrEXEBwcn928nzc9qyre+OSHV kCsTycMVZhuZM/LniNvm+XDN0pJrp5JQGbzNxLMRgP8A6xl5ONv3QFG3PT5e1atQ1aeqX9LXX8dN yZNN3RV1WGG6juU2hwvET8E7SA5wP+uiKuc9a47wj4iHw48RyNPNInhHXLhjrIMZZdM1WYQxw6wk MaNIYnVBb3z26yTSf6PLMqw2bSR9XLchy7AghDhfb5GfA4xjzlRSPfPNcHr8SXsNwrrGx3hHLjbH IsqnfEVJbzJlKiTcm1OdvPzCuebjVTjOMdPhk9Lar4e2n46kOXLZOTipaaN+9/d0T7n2VbvFJBDL bSxz20saTRSxOskU8UyiSOaKVCY5UmVhJ5qllbcHDkYJnZiq9CTngY9PT0P+eM18pfDX4q3ejWN3 4R1DTr/xDfaRGZfDdpo0cH9tavZpIzXFjHa391Z2csumqC3mfb7ctamC3ht2kjZm9ke6+IutT6va Q2mg+ELeKexk0PWLqa58TXGo2bKHv01bw/Gnh9dJuI2H2eFYNc1RGD+a0i7Vibz5OVN6KVRadVdq 66aa6tatee2m9LCynHmU6VKm7ScpVIO3ux+GCbk3tooOz6aHoUkixqXZ8Iu5izkY2qCWBYnPygFt 2PurzXBn4m+EbiWK30fVl8RvPdzacn/CM21z4jtrXULb/W2uo32iQ31jpM0bjbINYuLFI3B3MuGa sG3+D2mXl1f3HjHxD4o8drc6rBrGnWniDUo00/w7cRxlXt9At9Gt9HmtrCR8N9l1K51dl2orXDLy 3qGm6Ppekxyw6Vp1jp8cshmmSytYrUTTNjfNL5CRrJK/VpG3Mx+8WpJykm2+W6T5X20v536WTd/Q 2awdKKTdTEzVvgi6dJ6Ru3J3k77SXJBJ3SvuuKstW8b67BDLB4fj8Gxym7guF8SXdne6xbFNyW+o WNvo1zqukXCOpNx5N1fW8px5c0cfzZ0rTwq1xFEfEWuXviG6Fu9vcxsiaZpd6hZmLzaJBL9kcgMq 7n3BlAYY3cdqBHyMA54xycjGAOenHv70oG3og+uQP6nHp17UKnfSXMum8f06Pa1r+ZnLEtXdKEKC tpGnHmeiX/LyfNU1t3163uUtO0+y061jsrC2gtbO3+S3ggjEcUSZyURVAUDJPC5Xnj0rQ3DI5Huc jimDj1UHkcg/0z+Z9hTSoBAOee/TsTgH145zt9q0tBae7p6HPzSk05Xcna+kn72i037b+hIMZ4PP 1J9eoz9adVZ3RASWEe0ZJlOwD0+bG3079x0qq2o2qSLG1ym9wSgQNIpxk9YlZc/3tzL0/Nq3S3y/ 4A1HTS/o+Zvp39e5p0VSSeaVSVglQjtPtiB+jIZO/wDntUqGZgBIURiOVRi236SFV3f98qfypiLF FNUEA5LHn+LH6Y7fnTqACiiigAooooAgkJD4AyWHyjnlh2OPujA5b3/ONrhUyZWWJQdoMhCK7MMh EZiFJ4/2se/Snyruwc8H0OCpGdki+pXA/mOtfgn+2/8AHfwd8P8Axl+3P8ZP2h9D1n4n/CP9izSv 2SbDwV8Jo9Yv7LwfZXfx31XQ5PEfxJvNDti1vqfxA8KahdLd+GPEskLaloukpf6ZZMsN7IBjVqxo 0p1Ze7ClGUqjl7sVGK5pO/ku1196OrL8BiM1x+Ey/CqVTE4mtSoUKMOXnrVq9WnSo01dxTdSpKMU m0vNXP3t3AhicAEAhsg5Y5ygA7ADqfvbvavPPGelakpg8SeFrKGfxXo8OIYHnWwGu6YHM9z4enun KwiO4V5BZXF8s9ppt7PJeRRpM0sh/Bb4Q/t3/ss+IrzU/E/w0/a7+OngbxR4s0u0isP+FofFmf4w eAfD8U8JlSPQvhL8Qdeh0+zuYUdFWSKytpwIwiO64CfY/gb4+ftA2XguKy8HftJfszftJ+Ib3VJr tPGfxx0bxD+znHFptzMzxaXBo/wv8J+L9JvFsbd0ghv5pI5LzyllmYMzV5GE4jyPMYN4TNcFVadn COJpxnd2i1yTcZ35ny2sm352P0nPvB3xV4MqKpxBwBxPgKKj7T2lbJsZVw86coxtJ16FKpQnTnB8 y/eJuDvsrn6b+DvGuieOtBtte0V7nyZZZ7G6sb+3ks9Y0nVrJzDqWi63pc+260zWNMuBJb6lpt0q 3NnPE0ci7sVb8VeHdK8X6Bqnh3WreC60zWLOS0uIZ7a3u4wzsr286Q3cVxavcWlzHHd2bTQyrHcw xSKp8uvi/wAP/tL+IovHes+F9c+GUmkeL9C8HaD478QWfhrV/DfiHSvi38NpG07SPEHxX+C99pur S+INd0f4Y67q2m6VruieMtK8MeJNXsb6VfCWja/rH9nWF765pf7XX7OOv6quk6H8VNC1mD7PcSX3 ijRLfVNX+Hfh+6sWUXuh+KfiXp1hcfD7wn4qsxIkl94R8TeJNL8UWkUsEl1pEayRNJ7ClFRUbR5X G8XzL3oyUUl07/j3ev5vVw9XD1PrNKM6fLVtCNnz0q9Nxfs56KXtINXV1F6Xto0um+DXiTWprHWP h74ua4fxf8O9QGg3l9dW15CPEugrFFdeG/E9pd3Tn+2ptR0G40+LxJqtiy6dD40h1/TIYbdrBrWP xf8Ab1+HWr+Nf2e/EHirwha3U/xC+D1/o3xr8BR2Uczatea38MdUtPF1x4Z07yWWeK48b6Lpep+B bxLdlknsPEV5B8yTOr29V+NvwP8AFeuXPxW+C/xi+DnxJ1T4YWv9m/GG0+HPi3QviN4gt/h4kpvt QttS0/4dzeKfFI1Hwz9qvte8PaD/AGcTqWp3TROsIuPOr7ClWO6s9hYPHcRISxBdZEcLtIUjgSAj jjqW/hrmnRWIpVsLJvnVNx52rNRbThKKejaaSuraxT8j18Hmc8qzbLc/wkHScMRSrVaKvyucHGOL oydm3SrQk+ZO/wC7rODvaV/LPgf8UdJ+NPwi8CfE/QZobi08Z+GdP1ZVtJBJFDdmHyNVsgVYsH07 VY7zTp1LMyT2sqN+8DV80/siTv4M+J37VnwVntotL07wn8Yf+E08C6esckUuo+F/ip4Y8PfEPxLr 0cUjZlguPip4m8eWclxGvlpdW80LDfHIo5T9i+/Hwo+Kf7RP7H948VjpHwp8QaV8S/g9pQuYJILL 4L/F99Zl0XSYpprj+07zU9K8eeEfiLe6rJPbmKytNb0OCO6n3lYuu8Wto3gP9vr4S6/PJqt3qn7Q HwU8S/CbTbGIIdJ0WH4NajrfxXvNavXMis93rMXjEaTHsic4skZm2uDXIqjqRwVaTXtqdb2NbljL SpJ/VqsUr+7H2qi482iVntqfQ4nBxwOL4lybDUlHAZpgI53l6dSlKUcFRSznAy9ok6c6scBOpTrR puDUp1YW5lyHn+jJc+HP+Cqnii0iUx6d8SP2UpPFd2QDtudT8CfEHwX4Us5HxhWaOw1y4jUtllUl VC7qr+N3kT/gqT8EoWR/JuP2YvjK6y4OzzLfxl8Kx5fHBbbIGO7P05rd+Nn2nwB+3p+yj8RGgaa1 +LHhj4nfs6SMuMW0x0i9+OMNxtHQvH8LZofMclfLkaPd5rIjWvjdqtjo/wC3/wDsqapfXCWWm6d+ zp+15q2q3ssbNHBZaXrn7ON3dXTbUeQJa2ollZVRt6lgiu67a5oYeU3Vw9BuM4Z1TrTi781SdatS qLlW7T9t7qivJaK579PG1atfA4ut7OccV4a47LKc6bVqdLKMuxWBhz+7ZTjHAxUrO7upX3S+Cf29 vir8RfCf/BQH/hV/wWju1+M/x0/Y98J+AvAniGKC6u9N+HGnz/GL4jx+P/iNfiErDZ3vhPw1ewar o7XX+i315AkNxDcQxGKvjL9rH9if4G/CT9nWe7vBqWm+Evhd4bu7zUNVmnhtNT8X3jTRQXNt/aKR w/aNW17V5oLe3uPmhWS5Xy4fL3K36Q/Bc3nx7+LXxG/bK1+0gNv4/urj4ffA6OdTMdE+A3hK8mtd J1iwkuUjuLeP4lawmr/EJVZI5V0vxTaafJGpt/LX8nv+C/Y+JMvgv4NXfh671CP4NQX+q6P4utrH VWXTpfGbLLcaGdZ0lJPJmii0q3vfss0itDbsVWORJjGrf1J4UU6uE4tyDhXLMx/syvjcXh8VmuJj Z1Z4lRhUlhYtazcILlSd03KdnZI/IOJ8whmWTYfH1MvjXlk2TrLKVOpOUqVWn7adRVmn8E06jSUV a0b7ykz+abW/F/hqDwpBYaP4c+z+JY/E+v6lJr95NLLfweH7yLT10PS0TeYJp7XyL1prhoWZZmja Nk/i0LTxro3gb4Pa1p66zqF54r+KVlqkl/Hp13II9K05JJtOiGsz7nVBeTW8kl5attmmjkW6Zt02 5vBdY1ASSSIXUlBvjHlgTNtJV8QtiRYeI1ZZFXduMkasqs1cjrGp6KthprWVjd2eswLc/wBotLdR yafdqZZZITE7y7ok+fy3tVjW3bb50bPJIy1/oRnuWYfGUKeGjiKlenTqKpOrFxc/a01GcIVZJtJR m9YWu7u5+IYZSpVFVlBU+daUYRcV7zi0tUtlZuWx+yP7MHwm8J2Hwj0vUNannFxqcmn6lcujw3Ft P/awVobVmiTc97ZpIwhZSsjMm6LbD5it+qHjz4S/DPwT4W8KXcem6HoE3iDRJGSVrJvtlzJItmLb 7Xc3TSee10wkklhb5rdYmZdrTE1/MJ8GPjt8Y7HU9F0nRfGeg6Z4e8AR6r4xGjeJ9YtvDWh6gqwS oLS5ZpVutan8+eO303S7G3vLwSSRxx24hWSVf3x/YAuPjj+21b+MvE3jyTw5d2ZuLCy8OppGk21l ptj4bssuscWpXKWt5O0l4HWFbm3haORZGbasnzf55eNvCufZVj814hx2a0qeDo4mpUhRdecXUhOz hTo07KLnb3nHm0s1rofqnC31PEwjRWXxrV6mj5oxbjH3XKdu3n+HU9K8X/Hj45eEtI0jwFoPxRur jwnZ2dvC/gjSbTQrvQ7q1MCfa1u9Kn064WeCSImNWvPO8y3EaszSbmb5qtPgTo3i1Tqc5stPstd1 Cz0hINCto9D0rw9danpt1PZA2GkpZ6Dbz3FilzdLHdWM0k0Mcir97NfrnrX7ACahcf2pp+sHSfEF lBLHf2t7p1rdvGzzyXkAtpLR7p1NxBNGtxJErL5O3c3ysq/PXx78J6j4X1L4V+A9f1K5TwbpGXiS yuTe2M+pWWq2eptOVJ22/wBrazexvIVX5obmVfnPy1/LlHjOlWhXwdPH4n2Kh7WVCVSSp1KrslzQ 5rO3ZR79Vc+zxfCdem4VZYSjUpL2cp8sVzU4z5Emul+1ran4sXfgXQvC+l+LNG8fappdt4V8H+JB plr4iWXT9L1t43M9zNamaWLzL61aKASWclz5377zIbdl+7X4zfFs/D/WfilqNx4Kk17S/CGs+Kbe zW71Q29zqCWcl4lvPqbf2dBaqP7QCtfWtnIpu5PPWO4kmav6VP22P2cPF3xO8FWej+E7J317WtRX WtXUvHCh0zTobxrG3RY2aSaS6W4Pysu3bbx+YVWNWr8K9Y/Ze1zxF4n8EeFrTwJ43t/Fra9FY6os +k3My6qYbpJJbaw+wrcJNO8WVj/5YxW7Q3XmKsm6v6F8DeI+E8pyriXOc0zylgszxNJ4eGDqVlCm 6caVlKMXf95z6fcnufk/HOU5vlWb5Rl2ByjFYnA4io51MVTpNxpKcoXVWUdeVp20W6fXf+zn9kjw jY/A7wJJLoninxv4ssfFFppHiiG/8c2NisUb39iJ4ntW0+w0+VYPn+zyW/mN9ljkZW2yKrL9E6Jr PhXSvGN54ylthqtxr+v3GteMIJ9T1K8S5TVNGXw9qkNtaXl5cR2UFxpbCP7LYxW9qzQwytE0n7yv h/VfiFrnxP8ADegeG9K+Hd98F/BXgLStL8H+FvD2o313N4kuI7P7NCkl/o+kpeReHdI8yBZmk1KS zvppBGbq1jtftU0fofgnxV4rncaDqljp3iXUtDnt2hn042VvPNblJENhqEaSqtvcSLGk0bTMsV1H btJbySPHceX/ACDn2c4vMc3zHFuu5Rr4mfsbQjTtT9suSUkvibiuaTt+J/RXD+Bw+W4PBVFh3R5F TUHCUpzouME2k23JpyV0nqpaaI/AH/goj8H/AIjfsR/Gfxt8MdI8XfESy/Yu+P8ALN44sfBeheKf FFt8Ob208RXMs+nanrWg6bqMFhMNKVovBmvwzRtakeH3vdTgmS5k3fI6fFDUIdPtbG2/aA+MlvY2 6CS0sNM+PfxVtYoI1jLxxWdpaeMIViVYUaNI7VY4bdTtEagLX9inxH+D/hT9q/4Ry/Bz4qWtlod9 bX15q3wx+IdvPFPffDbxBNECJHiuGWa40G+nC22v6fAZoJrdZpokuPOG7+bz4x/AL4g/sz+OtQ+H nxR8IJ4U1dJHk0vULeEHw34u0oMYrXXvDHiCFGs9Zs7qJ0mUW8zX1kzqup29rNujX884lyPG1sVh cVSzLF0KMIwcZ0p80Jwi4OMJrVQmm6mul42Xdn9CS+mdj/Arw0zB5b4DcPeLMfaVMXmGIqydHNcp rTpwozxcsPClWrY3CTioTnCEoyo1ueT92cWfpP8A8Eivgt/wTc8YfsjwfEj9qzwv4I074oaX8ade +FZ8d/GP4teNbfUfH99cNomq6DqD+Grjxhbw3uoX83iJ9OM8Vkgu1trfzTI64r7i+J//AATF8V/s 6/Hj4WfG/wDZYi/Zg+HvgH4RfFbxh4+8QXfxbi8bS694TvfGOg6VpS6JB4n0vxdpPiG/+HsIto/E 9po39qtJY3Gr3en20kemW9tZ2/8ALZc/Dvw9Y6f4tbwzolno2ueII5dQkv8AT7RUubjWbRBd6Zez rF8qTw6la2c0M2VkZllZRlmr+jj4TftgeK/2jPh1+w38UviL4H8deOvhL4V+B+oaR8SJfD0UMmj6 l+0l8Ida1f4bNe+M9Tur210zT7uC+8GweKdJXVbuCQSanDeIoDru+/yvNMro4KNangcK8Zh/YUFW hhoOtWq1VThLFVZU6Up8sNZ1G3e0W17zR/K3gR9ITiP6VPFXFOQ1sbm/DWCo0sXnFThuecYuWFhh KXNiFlWXYHHYynhqcpP/AGPCUtIpum5Q5U7fsJ8OvBWvfGbwvZ+L/j/+0T4f+I/hSLxFquj+IPBv wdtW8CfC+NoJJ7aOefXo7qT4oXwi1EW8N/pOs+Ob7Q7hXZL7T7iLcK+gLT4o/CjwZoug2NhfaJae HNCnvPA94uk3GnaVoY0+5R7iyvLWSERW0tvBseOJ4ijLdSXcjM0hkkr+Y7wp4++P/wC0/wDH7Uf+ Fe+IPEXiDwDB8QvFC+I/C3wsstf8OfDn7Bqenaxp9zp/iTUvHFl4R0PW/EVw12L3Xr7R7jVNTbUL d76GKW4jjWu98Df8Er/iVq3jddA8YeKLPRfg3Lq+u+JtJ0Gx1nUwmqeP9ah+xx2ep6Okf2eB/Dem Wk/9m+ey/a21vUJ49212r0qfE+YYiUP7OyCriYVKroTrzqeypzdNR552cbxhJP8Am0u972X9ZYzw G4JyJVHxV4p5dktR4BZhSyujh/r+Kp0qkZxlg5qFWlOWMhK/LL2UYt2ko+5d/In/AAXC+GY+Dn7Q 3gL9r7wVoKT/AA1+PcNj8I/i3Jp8zXdrYfE3wzbW9r8NPGN5cQnyc+L/AAO3hHwyLmZv9MvdJubr e00zM35beAtS8a/FXxz4X+GfgnR7S68T+MtZh0bT2Tz5rewhnbOo69fGOXEOkeH9OF1qeqXUzeTH ptpdXDMsMbNX9RP/AAUF+FHwh1v9gfxH+x54u8Rzax4v8dfDseCPg3otpY3GueOU+LfgITWfgTxB ovhnT47rU2t9BvYLC0TWlhSztbCyjuL27tYl3L+KniT4N3v/AATX+AXh/TPiTrum6t+1t8fPCiaR 4t1uwEX2f4Y+BI4Y5dc8P+HLhB/Z7atrUcCWfiKWzudpsptQg02S+jl+b5zjDCUo0/ranGiqUVLG 0YTlOMKkoxcaUJ2cZVKl1C1/ds5NWTZ/InCv0IMP4w/SP4T4gw8lTySvmMZrD1KMqVXOsRgKsZUs cqLTdOhGMXWxdabcGoUqUIynNt/0rf8ABNz4/eH9d8EJ8G/gf4EuU+C/wCU/D/UviTqF3Fbab448 aad5Vzrl54ftkWO41WC81K9vopNW8+eO3jsLWK4ZvtNuE/VtPiNbm7trW40uZVlfyVUSpthYhdsk /wAu548n5lRlbAbbX8vn/BEvxX/wgPwC+OHi7V2ih8NWviW3VdSSSM28p0eyvdR1O5kjd1aKGGDU 7BpI9pnZmEkke1d1fo/+zL+2p4T/AGpvH3ivRvhtYaprlh4O1yw0q98UabbXN3oaXElpaavFHPfR I1mrTRX0ciQrM0ywSK0saqys333Ame0a+SZNTxFsPisTCtThhmryVGjUdOEUr25XGKle17O5+v8A jx4a1+DfEfjTKcro1MblXDWJo4eeY0aTWHVWtQo1JxrT5nThUdWVSKpx5VFq0Vpyr9k7q6QmVllh kmb/AFQAkSMDI5fYyqwUf3cVlvdSrGA0kJzMQ5hQqhXapzGzFpD82fmZm6VUeW4tY9rn5Y0VkikX btBj3ZLZ5OAf9nd2FY15fO6vvmUA7I4wBhhLjdgkfKNwYfMv/wBc/qTpxhG/WPu/Ffl2/wCBv2tf v+AxvJN22+Ly+/8A4JburoN5jF5yqyAkOVZRvxHCiI4YFN6kycbtp+X2yJ5yu6RyBEPv26ALEhIJ MhUde0bf7351JLjhDM7MdwWNVxuSQqEAkwdvUCRfmbr6YrHadmmdZpJVYLIEVTGdpdk8xmG9f+Wm Fj3fLtP8LBaxjVi48r3j118/LXqZOTbdtvL4df73/Buu/U1Y5HEsfm75zKrMATtBAONqEbWX+Hdu ZsbV/ip0tzKRKsbxMwGEgKkOPmLffB7Fv73t9efN8uBt8yX90yPISn7zlsRDDfI2UZt33diN81VZ LwJACtx852v5SA7lVgG5Y/KdoILbWP09eecL80k9Ftfttp/w278y4ttXfc0jeJl41kZ41thdM7Y3 Z2ldgK7FDZbd03bl/u/LXP6hdRytKUIZY4873AKRyBQVZAPvuwc7m/75xVF70RfaEDSKTIcBgCxJ 4JBB/wBWoJ/2uPu1z+oXw8mOKBvNRAkSXJCr5fMkjl1JViCzBfu7s9MLXA6rcpQtZr3n9n/gef3b dCMnJxUHBty5XzPTfrt/w/ocfrl/e6XdWmsaXcG31DSb6LUdOvShuBBdw7bhGZZ/MgA84sscdxHJ DI3y+WzA5+9vhl46tPiL4SsPElvE0NxKJ7PU7SS3kgez1aylWHUbeKKctM9rHcKy2twJHiuI1jkX duWvzr8QXUTNcSNsmZAsbNEwRWm3GRT5hKtGYw6ruTdtYNtx1ZPgN8Y7X4afEaXSdbuLhPDPja4g 068aO2u76a2152Frot1b2mmw3t5NPeXEkWj+XDAyq199quGjjhkK8bxL9pFc0Vfmaaf2Vy8zUb/3 lZL5HY8PPkvGC5lZt001o0k2nzWvs/8AJn6sKQSPkI3LyxXDZGAAQRuz1/u/LxtJ+65nVcA4XOBn HXc20Irc5ZiAAv8AFkfSvOk8TeKtS1TxPomneCdR0z+y7Kxl0HxT4gv9ITw14ivLgTGS3itdL1G+ 8T2H2EJGLyTUtDsizXCLa/aGSXy9GPT/ABnPe6DfXmv2GmwW1lIPEfh7TNPhv7TVb+aPCyWWr3aQ apZW1tJnyRHbJJdKq+dHGzMg6VNTjF2up6xv7t9E+vXuu3VrUiWGlCynOnSbinaVVSbjJJqS5Ob3 pdE7csvitq12TT7MlscMFCgbnYEhQcAjG4kN0wqg55xXGXXxE8LwNqVvaagmtajpCSSXejaCG1jW x5RQSJHpdmWupJU81N0SoXAbvyKvt4U0S4sVs9Tt5dat1u4b1U1q4fU2S5gnWe3mVrtiyPbzqklv yrRsq7QGVRW+IoUAURgBhtB2DICheGbHO3HVvvDaRkAU4xnJ6ta/Z7Ws+kvVr8wSw0NWp1LaP4ac fs6XfM5K78vO99OLsfFuta2lldaT4R1RdOugDLLrj/2BqNmQ7I/2jRb+P7apG3cqYDMp445OhZ2P i28hnXWNZsbGUXIa3k8O2ZUC2AYNBdJrR1JGl3bWaSARHjiupA3KQFDKQcd8hh/eGO34c8U/5hg8 nO7I+8RnnGTzgnGFA/ujgUrK3NzbaX6835tWtbyCVWKSVKlTgvd5dXOTfu2bcm1e6e0EttDFg0K0 ine4lmvbuaRNkxur25ltpcYO42Bl+wxliB/qrdR0HNakMEUKlIIYoVbkpFGkak+pVAqk/wD168Nk /ao/ZpXxLrvgpP2gPgveeOPDDPF4h8B6X8TfBmreO9JuFV2Fle+C9M1q68TQ6hJ5UghsG0v7bOyt FDbySfLXmQ/bW8C+ItI8SyfCP4ZfH34q+L9AlltbTwKvwT+I3wjvPEV7ExVodF8X/H3w78K/hwbd iB5epXnjG00qVWWSO8aP5qatG0XJa9XaN2uXTXS7377eRKVeu2uWdVxjtBOajFb3UY7d9fyPsUMe wOc9CGIDD74JB2+qqe7cduZBnjOQe4+UgfiAP0r4Vv8A9rzx1oXgi4+IXjL9l/4k+DdJ0F9Mm8f+ GtU+IPwD1jxh4E8MXGsafZeIPiDqMXhP4seIfDb+D/h/oc+oeK/GElrrlxrf9k6VdLomkateiCzu PtzS9RsNX03T9X0u6ivtN1Wxs9R0+9gO6C8sr23jurS6gbA3RXFvLHNG3dHU8ZpQnCpFyhKM4pyg 5RlzWnCyktOq0+fQmpQrUJctalUoyajKMKkJU5OLSlGXLJJ2lFpxezi0aFFJkDqQPxoyD0IP41oQ LRRRQAUUUUAROMFmJ4wM+3bP6fT1Hev5Wf8AgsQX/wCGf/8Agug8bhSmkf8ABOkPkE5WS98PIwwF bl0cqvy8Z3Niv6o5cgsVIyFAwTgdc5OfUY9elfzD/wDBVbwL47+IXwi/4LeeDfh94O8S+OfGGveH /wDgn7eeH/CXhHTLrWPEuv2+hnRL7WpNO0uzjkur2PTrK1u7m+WGN9tpazlscEeXm8PbZbjocvPO WGxFOlCLvKdR0ZJRcVrrfTS7dt9T6/w9xFPCcecI4mvVhQw2H4iyOviK9VL2dKhRzLDTq1JPZRhC PNJvaK6Jn8bmljZYaZJkLJ9g09lki+SQFbWMAefGV2MAUbcq9P8Ad49F0D4m/EXwtJJN4f8AHHin TZJAELR61dzZUDAWJbo3NvCMY27bc9j9PKtJvrpbm78La34c8U+D/FPhy102DXfDfi3Qbrw7qunz SQGOMyaZfww3UMT+RKqtKvzMjZ77dzJwVxweuf8APtX+cmJWa5Vn9XDVliMHio46Mp03KVNKMqsZ K8FZOLi09nftqf8Aapw9Pgfjvwpy/OcCsk4lyqpwxP6pj6dLDYyhOrQwLp1PZVXCdp060JQlZ3jJ NWuj+5j/AIJzXt7qvxm/4J+3ep3tzqF5e/8ABG/Wru9uruVria7urj43/s7SyzzzPhpJnfcWZly2 eegx+XnxX/4KA/Ej9gP9mD/gl9/wgWg6Fq3gv4+Xf7Zr/FvwnJY6Tbp4t1vw18XtJTQPEWoXMmlX S3mp2Fvf39sz3MDPeW9xFFNcYtINv6cf8E2ZE/4W5/wT0yyoR/wRo1RRkgbmHxr/AGdlABJ5OeeM /wA6/m6/4Kx6taWH7JH/AARiSR1kuReft03K20bDzTCvxi8O25lyAcJ5soVWP3iGXHynH948Q4vE YXgGvjcHV9jjaGSYarSqwcvaQrKhQldPfV/Ff7N/I/5LfCDh/J+JfpYZbwxxDgKGN4fznxOzfAZl luJhGWHr4ermWY0JQ5WnH3Y1JRhKKvGbi42cYn6N6D/wWa/Zl8caZdaD8Wf2cPDFna6upGsx+GvC UXgyHURcIEnXUta8Ia3pOo3p2grK08BDqNypGx21+nn7Gnxw+GUlz+xR47/Zf0zxB8Mfgr+0f8YP jn8APFnwg1HxdqHiTwd9u8C/Cn4q/Fm1+J2lz+KP7R8Sw+LBqfwotPDdsF16HRR4a1zUopdGkv1t b2L+DO71e4l3rGxjG1sbSVboRnd94c9t1f0CfsqL8Ybr9hj/AIJear8FNRkPxR8K/t+/tceLvCej XUZv7fxjL4X/AGYP2j9c1L4fyW8wkjRvHujWN/4Ps7wKsml3mswalC0c1rHIv5P4Tcf8TcQ5tisJ nNaGIhhst9rTcKa9rKdOpTinOVrtuMpaXt6tH+g37Qv6Ingh4O8AcN8S+GWWVsjzDN+McLlFaeIx uJnluGweIy/HYidOnh6tSVKP7+jSn7Rw50lyp2k0/wBf5fi3q/jD4qfAj9pzx/8AtofCP9m74++N vAfxqh+G/wAL7j4PX3jjwC/wlh+IOl+G9Rs/GksfxN8Jap8Rda02+8K6RqlnrEGpeD10t9evrHT9 DKrdahf+3/FbxT+0x8Sbb4R698L/AI2/sj/GDx78MviZ4a8dt4nXW/Ef7OFl4m8Ladd20nir4eJZ 3dl8c59BtvHGlW7aLqGtR6rqAtLaRZJNMvlQQt/Il/wU/wBV1h/Cf/BLDWbmGfw7r178C/jfqGoW lneSW93o2pXvxVhutT0lLq2eOYf2XezT6e0iyfvmhZt33q+KdL+KvxQ0ORZdF+IfjK1ZRtVJ/EGq ajbAA8Ys9Rubq1PA/jhwv517XF3ifR4YzeWVV8pnWw9Z0Mb7SnXnRrQk+ST5ruUfiipcvL1s29T8 y+jn9BDEePnhpQ49y/j55PnWAnmHDsMLXy3CY7ASo0eaCVLlp0qns3Srzp2ddpxk5LR2P7wv2kvi Z+15431j9kv4hD9lW51TxH8CvjbffELx54d/Z5+Lnhf40QXfg7VPhT8Qfh/qcHhPUvFWi/B+XxBr yyeMIhbaZeaboNtPbrcTPqUTIsD/AAd+3f8AtleHPj9+0P8AAXxJ+z94m8Y+Mfg9cfCD4g/D747e NPB3g/xNqEvwM0Hx54s8G3ev6fri2Fi0+neN9Q1L4VXPhXV9FtG1efTrK3vHuLYW1/p11efh9/wT 8/a6/aV1b9s79mPwDqfxc8QXXhfXPiRa2msaXDDpenfb7KDS9RuVs57nTrG0uZbbzYYZNsk7b9ij 7vyj7j+Kv7bfxx/YF/Zc0X4g/AHWbfQJPHH/AAU4+Nmm+PtL+xaa1t4u0288I6JcXkWoEWu9b6Z9 NsCNQQrdOLSON5iny19nwhx3gc5yzMeJ44SrCOW4mhip05NSbqYalGSmrKKXJGC0b96SWnQ/C/GT 6OnGHgj4m8D+En9p8PZrmmf5ZjMryfFxw1WjQUs9xThUhjJ1XiakpVK1ecaUoaYeNWpGKasz9s/h T+2/+xxd6dYeGfCnxe0TTYdJSLStE0C68F/ErwtY6LYaUiWumaXLc+KfBeiWaQ2tvFDayNHI0O6N tsjL81eNf8FJPgJ4b/bn/ZnsPCPwo+MXw3m+JHhvxj4Y8Q+E9K/4Wl4M07TtWk1O9i8Na7Jr1mb5 r4WGj+H9a1bVlzatceZYxqsLSba/MrQv+DgPxT40sodJ+MfwZ0Tx6m1kni8S6T4N13SXiLMd8djq WhTSfdwskJL7mUyfeLV3eh/8FS/+Ce2s+YfGv7EP7Pul3F0d93q3hn9n7w3pHiQuxOZE8SeG9G07 UIZeWZntblG8wK+/Kq1d+TeP/DeXZ9heIMBnX9nZnhcQsVSq16V+WtKPI3N3kk2m9XJ7XudfEn7O z6VOGy+rRpeHtHOMHKEYueSY+jiE4QUWnCnKFCrJPorc2sfd6H6BfFb/AII5/BDx7+xRZfs2/C7Q PC2h/EnSbHQfEGn/ABQ0O7t5pPEHxD0yxuoZLfX9ftoNYupvDV8+p6gtxHa29ru+y6fIkedyr/Ft 8ef2MP2kv2dPi9rXwh+Kvwr8U2HiDw7ciS6udNsZP+Ef8Q6RvPkaloOvXaR6fcWN5CoazVmivNx2 3FrC25a/qN0r9rL/AIJKeMJre5k0H43fD2YOtxFJ4K/bA/af+EemWs2SPMOh+HPjHommSCIZYW9x Yy2yL8vk/Lx3/iXUf+CcHxu0PStAT9sP9oLS9M0zVrLW9Ksrn4oeH/jS+m6lYXIurSZJ/izovj66 u7TzgJJtPvp7izvlOL23uPMfd+68A/S0qZHXx7xfEmDz7B5liKmLlSxWLknRxVSSbUZScHCnLZQ5 uSKtt1/nTjD6Gnj7l0Y08b4TcW5dUo0lR5qeV1MZ7VRX2Y4VVaqs9LuMXorH8h/7O/7K3xP/AGr/ AI6Wfwo8J+Etd0fTbrWUn8SXN3pt3bx+HtItZxLJm+urVYUvbiJDa2PlmbzrqaFnhWMsy/3x/sff DbR/2dPgp4e+D+keBtP8GXfheKPSp5UEd/Lr8sKmU3N1eG3tZMymbz2/uzNIqnatfPupeL5/2bNP 8M/HLw98Vx+0h+ylr+vW3gj4zeLdZ+EXwZ+H/wAXPgJ4s8QOdG+HvxCum+DHw6+HOmat8N9S1240 vwzq0uuaLe6hos3iCz8VDVo9L0m8jm++9M8Z+A7lNO1S/wDECETWdu3kQN9tWRJEE8GpiVXZpY7i J0dZvMZZFbcvyMtfC+N/jFjvESphVNfUsmhBSw+GoVvaUsRUlFXrOrCTjUvqlzSk0nr5fFcG8DYj hirjKGdYOphc7wdaphcfg8ZRq4bF4SpTUU6NXC1lGpTldc3vxTbd9rXzPE17qmh6TrniAXltp7+b aJDJJp11qls7XrfZZhc21tLDcLGqoY47hpo4YcbpmWM7q+Af2ifB+t+Pvhz4N8Y2ljpt5LHePea7 b2cLx3Ol31ukkdqkiK8zBZrpowyqvltu3eYyrur6f/aC/a/8BfDC88K/DPwp4H8S/HX42/GqS/0D 4b/BP4f6zY+Htd8W6TDAieINe1/Xru3u7PwP4G0G1c3Xibxtr0LaDo9ik9xdBVt5Gr5j1G9/bouT Lp3hf9jDwfcaFNALe9s9C/bJ+CFncTrFA8CW0lxrmk6gzG33+ZLNbtFIs0S/ZWhVitfgWHy7MMRT oY3CYZU2nZc8uV1IaKXxP3r305U3fqfQ1cXHEYrEx9jXdGiqUajpUpzjDok3CDUdY/as/uufIPhf VNR12NrOfdqeraXqEeqpFIWiu5LGzbyb7S18wx7WZCv2eNv9ZIdu3Em6vpLw1rvwt8ZXMv2TwnY6 I7MYJbp4hc6lbtGfLNjPcLY2NxpmrRspS6a3jdbGQNHHNqEcas3h/wAQfCH7atr46h8T6b+wBrei WNvaWQu4PDH7QXwx8fXV3qls7SPqDN4a0WFbtZNsC/Z41/1iM03mPt2z6j8SPjPpusjVNZ/YY/a1 0sapJo+o+J4/BPwk1nxvdLq+nXBmv5bC78PaQq3dvqzDF3Gm5fmbbtr04ZZmNvewtWNJ+9KFNc3J LTV66rq+jTu9UyqWNoU2vbyjKUbez9tTk5Rjde770d7fJK7Po7XtC8LS6J52j6G0htL6W1a/ttQl F5rLS2V08cNxf3Aw81wVWSTdCyrAJI1k3MrVheD/AAdp0uoSXOkT39tHbWyLq1hez263llds26zl V4xG16qKb23jaSSP7PHMzbpvMCw+F+Df2pvCXi691/4eah4W+Jfwl+KPw906LU9V+GXxz+Geu/Cj xU/g++mhGn+NrTwj4sghuNR0FXkto21pbeQRpcrD9oVZmVvov4T6PF4y1G7vNK1yz1LSWsY7q71C zmtnNz+8dobG3niT53j/ANLaP7z+T5i/w/Kp5bWjUisSnG9pRjZxlZpW/FeV9Ca2Ow6pTqOMeSfu wcVtJWvp0/roei+G9fMupy2sFg0AtLpIY7xZ0W3hCbYGTDxSZEhiKfMFXdubc27dXtfinwn8O/jz 4HuPhz8bfC+j/ETwi0Uq2CXyRW+saFdrGRHqPhrxBETdaLdQviWNJItRtJmXa9km5dvzD8Qfip+z /wDCbxBo+l+LfiHpOieINatprzTPCUGpwXXiXW7OyZ45r2Dw7Duu9Ss7OSKTcwhaP923m+YtVNG/ bJ/Zl0eWJL74oeEbBZI8v/aKT6XBBKy7ZQWuX8uDcxLSSSLshYbbfy/lI+synL6E4OjXoLEYepH+ FK1pRdlq5bde258Ni8xr4essRhZ1acqcpqbpJyjWuoc1Gd7pxty3i7qSurau/wAlfGf/AII2atBL Lqn7Mfxj0HxXZyyGVPAXxVFzoWsaajBX8mDxdpUOpWeuzQ4WGFJtH0VWDLuZdrtWX+wRpH7YP7BN r+0p8D/j/wDs2fEPXPgr4s8faP8AFb4Sat4GHhXxbp9h4tu9D0bT/FGlXNhda/pawaHfXmmza6rK k0095qd0s8KsnmN97wft5/smWsaCX9qD4KWAIaSaDUPFGnQCONyVICxyR2t62Y1/0ryWK/6tdred u+TfFP8AwUC/Y3m1DW3H7WfwniMeoXQkZPiPaCB0WV0Qx2cF0sNoNgHzWcdvJz8zbsY1ocL4LA16 lfLatfA1KkW3QUadSnLZ8kY1Iyau9E001ez025uGKvB2TZ5X4lrcC5PSzrFxjHF5rgp4vKq7jTcX TawuCq0cF7SUleU5YeTd7p8zcj64u/2zLDSIdah+H/7LPxnt9Onn0/xAsc2i/C7wFpNhqunzxS3j 3dzdePLWNLbUJQ/9pXhjkmW1eaTa/wA1fIPxw/4KhX+kN4ktfEfxS+Bv7Mmm3Vxa6pD9g127+Ovx bk1JreWO8/snwt4ftfDvhnRLx4YVt7W+l8Y6nb28jl5LecNivG/2vf8Agn144/4KV/sz2x/Zq+N3 hDR7vXNX0rVdL1m78TXeq6B4s8Mzfv8AULO3vNO1CLMk1mZJnjuZJLW6tUmtBbsbhSPxJ+G//BKH 9nn4C/F9fh5+15/wUU/Z+0u10XUoLXx14I8D+LbTQvFlhFGglNhqk+qXV2lk91IyRrb2scN5CsbS b18yPbzZnlvEUaEKeEr051KlXklG8KVFQq8ukpUowmqi5m5SVRbarqv6Y8OeMPCLEYupi+M8olhn QhGvhsbCvVzHMKlSlyuFKdHG1a2DqqrKnBNPBu3Ndzl7yftnxd/4KW/EfRPEGleLf2M/Cvi3xf48 fxPDqfjL4qfEjTIvHHxc+JWkWUkOpSeHrSw0e4WLwLoV5DLJZ3On6L4dnvZtOaEDXZLgSNXwH+3n +0f+1F8YPi3pvjj4w/Cr4l/DRPGGlaZY/DXwv4r0K/ga7sLi1+xw2ulSSW/k3Go6k8oBtIz/AGgF ba0K5BP9VPwJ/aH/AOCQH7GGkW+j/s63Hwa1LxXbw5/4WMNZtPGfjO7ZJHCwzeNdXfUvENjcSBTH b28OpxWO3attbLHtWsL44f8ABSr9mv45XGk6V428NW/xY0rwr4g0zxZ4RGpeEY9ei8H+JtEu47/S fFWl6tFZfbtNvtNeAteTW91CtxYvc2t4s1jcXEMnn1uD6k8ulg80xrqzlWVeFGhByoKpBJ8t07vR tc0ruXW71X31X6UeR8N8ZYTO/DrhCtlWGwuX1cs+vY3Ee3zGopxjF16SUIxw0Zyiv3cWoQV1ThGO j8Y+GGieIv2Rv+CZOo6D4jkW28S3/ha31jVLSSOSz1mDXfGCRRys805a3uBHpbxW83nRr9n8jy5I 5GkjMfsH/Bvb8QLmf/hfnhfSmdvBmm+I9B1G2kuUtCf+EogjtdJ1JpLm2EDSW/2SxgaFZo93llY1 3KqyN+dX/BW/9tvwt4v/AGfPAnhHwj8QfDevR/EHVYvEU+qaTLDLDL4V08yRzWkb2jLGUm1aOO3m Myt+805rVdrK1ez/APBEDxF42/Z1+Hnj3xh4s/Z7/a116H4t+MtP8U6FdfDv9l/4j+O9NvfDsug6 Qllf2Umj2clrd6fqFzHPJZyRqySW7Rurba8PB5ZXXGuTLCVMVDL8swtNVYR92nKTjzTi1/e3t/wD 6PO86yrF/Rm41zbiCtga/GHiDxTDN6FGtOM8y+rwxSXtYtt1PZQcGpPl5VGVk7qy/sA8TfFXw1F4 n/4RFtXshrt1bebaadcXdvFd3CB0TdFGzrvyr9PvDnYvSrUeplobdmMc0jGYCNc4hSEKZVkz1kjD K25dy4Pys21q/nO8KeJ/ir4x/bl8WfGj4kfsp/8ABRm6+FH/AAjiWHw+s7r9lH4j6GNB1mG4t57i 6ktn0mPUib6OCaOO6uLiS3tfOTaq7Vr9R3/bn+Atn8Mfin481S2+Jfw5b4ER6TbfEr4e/FbwJ4g8 DfFXw5Lrt3Dp/hSM+BtZWHxBqFt471K8i03wzqSxtp+tX0F1HYpJLZ3G79jy7M6+JWKnVwk8M6OL +q0uZ/Hh3b975XbSutPNn8B8Q5Jh8plgoUcww+ZSxeEoYqc8HXdSlRq1aalPDVUr2q0vhmvJ36n2 pdagxjkclQpiRbdY2DMGmkZopJM7fnkyNoUfKu3dtZaxLy9U3U0PzxlV+yyzI2WmmELTLHEM7Q32 iONmdvl2hmDbK+LJvjl+19qFjb6zof7AupR6Zf29pqFtYeO/2nvhL8M/F8NteRpNHFqfgrxVoz6t 4bvLeKRFuNP1BftFrdLNHNmRWZvLdc+Nf7dd15v9n/s0/Bb4ab5Z3ml8e/tPeAvGckeIZIYhnwdL orbJEkLTMrKvk7kxuZRXXLFYSlzKdeKkviTnFNbab9PkebhcmzfGt/VctzCupRThDD4apOLvy6xa g7xl0d+uh+ijXwR4ZIWnIaRGMbABTCqPAwBJKq6ySMzY+9v3LSy3rRkRmI+arxQ+Uxw/lM/2cvub 5SAqbuW+bO1N2Pl/Hn4jfHL/AIKHfDzwN40+LkU/7HPxW0X4XeFNV8d+Ifgn8MtT8XWPxO1zw3oU S3Wu/wBh+Ldd8a6x4RguNLtVS6eTUNDuvtBiW3t/L87a3mnhH9oT9pPx14b+GHjf4u/twfBD9na/ +O/wo8M/tJfD34QeB/hnaeJviPoXwT+Iatf+ANS8SX3js+KNL1bW/sTJb6reaPptnocOvQX9ra6f brbtCvLVx+EjQniJV6MaMf8Al9OpyQjqm9W2ktvmrHoYLhPiTMM0pZLhMizWpm9RqdHLKeFrVMZX jG05NUFDnleN2vc1WqP25n1ArEWYuZnm+9gMI18wIVI5z87eX68+1clqN1csWSO1nNuQzOFRyASR kkYIxlB93+9jj5q/G7Wfj18M9BMv/CYf8FWP2p9akfK3ml6f8F/2WtB0SQGQSyR2upWXwNt9VtI2 KEeZ/aXnRqNyyK21q8Y8QftSf8Ey1ikX4h/E/wDaU+M9zH8rJaftYfEz4VXDNvLtILH4W+MPBEa+ YWZgkarGv/LONa+bxXGvDOGg5TzrARad5L2sZygr78sW3p5K3kfreU/Rk8d87lGpl/hXxbNO0Yxq ZVXwzlKSXIuavGlB83nKK66WP2I8VeN9A0qa4h1rXdB0hAm9o9T1zTNNkV95JDi9uocFQFUfxc7a 8O8X6zaafbP4iOqQafplnby6sNej1C3gtrS1tk+2R6lFqnmPaxQQLEtwt8sjQqqecsm1d1fnB4Q/ bd/4JIW2uaT4f0L9mzWfFlzq2p2WlRJ8VviV8VPjFNO9/Klrl9W+InjTxTCzLuBa6lMgj/1jEMdw 6D43+A9L+HXiT9ob9kzw9/al58N7X9rj9kTQfDfhPXNU1nxBHo3wk/ag+NngKXXPAFtqer315fv4 NtfA2qavo+m6TdXdxHb6O8mnw7beRkbDLM3ynPva1cqx1LHxws4wqVaLknS9suayUor4uV2ule3m jyfEXwd8SfCGGTUvELhbMeGp55TxNXKqOPlSjPEQwrw6xN1GpUi3SnXp3i76T0ufvJ8FP+Cq/wCx n418P+FNF1X412C/EGXT0stY0fTvAnxXvbRNRsnNtIYtcj8CzaPfpJEsE32y21Ca0maeRoJGULt+ gPFf7XdppF9psXg/9nf9pb4xaDqiCSHxr8MvBPg658KxRnBP2mbxr8RfBGtRlVYFyujyY6dTX8r/ AO1b/wAFk/2jP2dv2tP2o/2V/hZaaF4Z+E/7P/jjRfhv8MtF8OaPomkadpeiaf4Q0S7uLCX7JYQ3 C+TdXxjiEMwJCyb2LcL8CeM/+Ctf7YHjSaWW68Z3GmM+8E6brfiiOPdkMBJp51ltNcjPG21U7j6V 8dxD4y8NcNY2tlGJw+Nr4rBe7PljGK9oktp80r3fVq2+h/YPgx+zJ8cfGjhHI+OsqzHhnLeHuI8N QxeXYjE4ivXxCoTUHL2uFjTo8sqbbg4xm0mrXvqf20eOv2mP2iIr7RZvhV+zr8MrvwvdMg1+6+Pn 7S1t8D/Fuj5BZ/sPhPwz8K/jRa6sY3AXbL4k0sNzhuK9J+Cvxu+JXjjx94u8C/FH4Z+CvASaf4a8 M+Lvh34h8DfFe6+KGg/EbRNbuddsdfKzXfw+8CT6PqPg+/0ewi1S1MepQTweINMnt7xi1xFB/nW+ M/2w/wBpLxpFcnXPidq1wJYp3TZBpsUg3KzL/pa2aXyDj7yXCtzX9s//AATdufFOo+B/2LtQOo6d d6XN+yZ4ofxC2pf2reeILrVZvGGiyaPc2d6b37JHZQj+2F1CPULe6u7lpbH7DPbpa3Cyen4feJmE 47zDGUMJgauEjhcJ9YlKpNTb/fU6a2j7rtLre9rWR8t9LX6DGefRT4Z4WzziHirCZ5ieI8zq5dHA YPBzw1HD+wwVXFOt7apWqyquU6HJyJRSUurWv7JorbW9SwPYAjHQDPC/3foPevi79v7UfFFr+zNq +n+Er25tbvxh8V/2cPht4gNnJLb3N78P/il+0V8Lfh38TdHiureSK6tP7c+HfibxRo7X9jPb6hYp eteaddWt9Db3MX2VGJGaRnd3TJRRjbg8AgMMbwpB5yWX7rHevHzF+0nq+gRzfAz4W6pGbif4u/HP wfYaTHM5kAv/AIYJe/HORwGOT5Nl8MbqYejJuwelfqLTvDld4rmlL1a23Xnr/wAE/gmnGLqRvJub 9nbR8q5nGTjK3lrt69b/AMq/7RP/AAWB1P8AZ8/aX/aT+Avwv+BHwl0LTPgN8Sz8MvA3ibw/4a0y 38U6p4d0Lwz4faG/13xfqdnq+p3ms2WoXOoQq863Ek8axyzXTTtKz/DHxH/4LD/tfeP1uYJPF1zb 2tzuiaHUruW9eKJyT+7OkDw8VK7iq89l9a/Nf4v+MP8AhYn7Rn7UfjsyvM3iX9oj4nTtcOd7yf2f q0ekkFu4X7CF79O1cXxxznpnGOPUfXpX8J+IXiFxTU4lzfAYbN8Zh8DQxUqcKGGqSjHlVtbxeytZ LXbzP+r76Hn0PvAaPgn4ecV514ccO5jxRm2Q4TH4zMsdgqeIxGIr1qcantXOpGSU5xacmrXl3Vz9 y/8AgnL8efi38c/E37Y3grx1401jXE8bfsEftIeEdM024up5bGHVdW8P3TQy2tvcTTzJdRiNo42k mum+zmRDIoav7f8A4MafLpfwe+E+mSMfM034aeBLCTcBu8yz8LaVbOW/2t8ZyPWv4HP+CK93bTft 7fDbwfdsDZfEnw/8RvA96oIBls7n4eeJ9SuY2HKsGFgOWXDMMV/cH+xD8V5Pjd+y18JviXKWZ9d0 /wARWKlwoby/CvjLxH4RhBAwAVh0JF/Ov6M8D8wrZjwRSq4itUrVo5hi4yqVZynN6UpO7ltrLp37 q5/i9+1J4MyTgz6T+NwmRZfgcrwWN4S4dxSwWXUIYfC03GnicKpU6cIxipShhoKbV3KSbfn9UmMN jcSSO/T+VKqKhJGefen0V+xH+cAUUUUAFFFFAFOeJyR5M/kyE5U7RJuI+8PKY7ScY3SfeUV8Iftc /Anwvq3h/wAb/tGwax8Svhx8XPhH8LPGeoaD4w+EvjzxH4OfxdZ6Lod54j0nw549sfDE0c3jnwnZ a7pmm3F34f8AEdtNpbNbqzBrWNmX76IBOSBnBAPcA9cV4f8AtLqF/Zv/AGgXUYb/AIUh8VjkdePA Wv4we3PPFQ0udP8Auy/BwsOMrO39+C891s+m/mf5/wB/wWWvJ7//AIKb/EbUrtomvNV/Z9/Z51a8 eKNIFnvNS0bxFd30xijTaryXMrSNuVQpYKx6bvzaJ6+/6c5/nX6Of8Fjhj/gpT42wAAP2bf2a8cA Ng+HdeLAH0bOW7t+VfmvqF0tjY3N0QGMMTuq5wWYKSq5xzubgc/L+Yr+BfFe68SMx5NXLE4K6Vuk KHrrfd7/AJn/AF0fs/JL/iSjgqpOTa/sniBSVS7XL9axjTSv20vol0R/YD+zV4LvfH3j3/gm5p3g /wAba/8ADv4l6D/wR9vfEXgXxlobSvHpGpn44/s6aeieINElaCw8SaBeRyz2mqeHtWY21zHMzyRM 8KEfzu/8FI21lv2Mf+CJJ8Q38Wq66ND/AG401fU4Ifs0Goainx50FL29itdqrax3Vwkky2qr5cCu IY8xqrH+i3/gmxeXN98av+CcF1cSLJLdf8EZr+WSQowJkb9o/wDZ8yF+f93GoO1Yfm+X5jJuVVb+ eH/gpw2f2Qv+CLJ/6h37dufmLdP2gNEH3mSPP/fK/wDAvvH+s+I6cP8AUDG1r2qy4fw6nHWythqK T5bK17R7WXpr/wA9fgni8Q/pf8OYGapSw9LxfzCrTm4RVePPnWKk6cZ2UlSvUcuTma5/eSi3I/OO UDDnHJDc49Af/wBX0/T+oD/gl0gl/Z9/4JFQjazzf8FC/wBsKGKORiqyPJ+yf+0ugRgOqkMdwb5V ++33ef5gJSSr+gDD9D/hX78/sufDv4j/ABM/YT/4Jc6B8H/HH/Cu/inaf8FCf2qfEXw+8TSRPcWE fijwp+zb+0N4l07SNciieOZvDniaTS/+EZ8SNDJ9pj0PVdQlt1aZY0r8E8C5OnxDms1TlWlTymtJ U1vPlxFC6jfS7189z/Xf9qvhKWN8GuBcJVxVHA0sTx/l1KWKr8ypUHPK8xSqVFBSaipPXyv6nkP7 d37Jf7TX7X3wJ/Yp+NX7JXw50/41+EfgD8Of2jdE+Mq6b478AeGtY8BX1v8AFPW9blttc0Xxb4n0 DUre9t9J0LUb5dLjtZNTmtVt5ltGW6tWm/ELwt4gt/E+h2GswAxpewRS7WOcEjBUZO0/MMEEfNjK gryf68fBHx28HfF/9qPw7Dc/DlPgf+0l4T/YT/4KTeFf2o/hRZNdadax+LtM0f8AZ5/4R7xR9gsZ bXw74g0TWobrWNS8J+Jv7Hh1Mx32rafMytazSXP8anwVjb/hANB3MWH2JCAeAvzsB3zmvd8a8vy6 rgMr4io+9isXWeHlUhdQ5Ka/hcrslOk7KaavGS5Xe2n49+y64y44yziTjPwizeUFkGS5bTzrB4eU acpPFYrERg8XTxEW3Vw+JpLnozjJwqUZQqQ0ld/oz/wTsB/4b+/ZLIwQ/wAU4VznoTournkD0Hvz 9Ca+pv8AgqBqtnpH7Bvgm81K6gsrWH/gp/8AGV/MnlRF+XwXZgyKshU7QuSvlqyoisWxu+b5d/4J 2qP+G+v2SzgYHxUh46ddE1cdf51+4X7PMnxU+HFx4hvX8T/CT4o/s+/F/wD4KM674T8W/Aj4y/BK 38dax4f1bxbo9yNS1/4a/EmfxdY2PhC1aHwxp0baVeeB/EFw0jzSR6lCsjRj3/BrArM+CM8wdSp7 KnXqvDymrf8AL2l7O2z6NdH3fQ/LP2lnE1fgj6TnhjxZQw1PFzyDL8Fm9PD1XJQqVsJjadakm04z SdSKuk1to1dn8tGi63p+s2y3+l31vexMcia2kEiBsAgEjBU+3pnBr0DT7tbi3BkKmSM4cMcKwwRu Yn5VGR99gF3Ds1a/7RGgaL4U/bO/bP8ADnhzS7TRPD+i/tC+OrDSNG022istP02yj1SQra2NpF+7 t7dWZjHHGiRhSrKEXK1ieAdA0vxd8Rvhx4M15ZH8P+MfiP8AD/wtr8NvO8E9xo+ueMtE03UbeOWM +YjXFtPNAWTDKsjFGU1/OfEHDkMJxNiMgp17xo46jhY4iS2U5Qu2lZNR532T5b2R/s14S+NGL4g8 Dcm8XMTldOjXx3CmKzvEZVTqy9i5YWnVnywqSTcef6ve7u4qbTk7Nmmqh1LRgyAnA2qJMt/dTr8v X5v/AK4qGWXyImeVjEq/6xCZFbnGEwo4LZ+Ve2a/pS+LP/BMH/gl/o3i34v+G9I/Y6/bi13SPgbp 8E/xG8c/s9+MvCt5Y6dLD4Th8Uam9pYeM9asZWEGnSm4AaV2lmDBAnSvw0/4KQfsxfs/fsofG39l K3/ZV8RfGrV/g7+0r+yp4T/aItLP4565oms+L9Ofxpe6td6TY3SaDouj22lTW/h8aTFqOls2rtZa nHeCLVbmFk2fdZ74MY7Jcrx2b0c8w2Jo4GCq16VLnjUUG1+6tZJNNW1stX00f8k+EP7ULgrxc8RM j8OX4fY/BZnxHjv7Pw2LqywuIwlGpKapqrNuXtOS+qSje2ve31d/wT0/blf4aeINQ+CvxfMXin4F fEjQ9V8B+MfBesKLjQ/EXgjX7KbTNc8P6nDIJI3WHSri4bTw6gmxgn0az3TXscMn6WyfHbxt+xpe +GP2NfDHhzUv2jtQ+Kctpc/8E59etbyK6uvi54F8Q/b5b34d+OPEFxKselap+z7c24vPFHiDWLi2 0V/Buv8AhnQ9O1W+1q3h0hf5XbuQx20zo5jdI2KOh2sjKMhlcHcDkfeVuM/n/SF8KJJJfjZ/wb9T yyO9wv7K37ccq3Ejs86TKfhptmSZz5yTLtG2ZWWRdv3gOv2/g9jP9Y8HjOHs1pvE4fLKUMZhG5OM 4qFSmnTlL+V6LWSVm+rZ/H/7U3wn4d4NzfhPxV4dgsuzni7NJ5LnOHwtKnSw2Jl7CdaGNcKai3Xh 7NwcnHWNlJ6K3hP7UH7T6/sg2vxG+Efwv+Itp8Uv25vi7Yw6b+1v+1doMrDT/h3pymSSz/Z8+BE8 ircaF4a8DRynTLRbOHT3h1AXnifVobHxrqmu6bY/lb4b/aS+OHhays9O0n4haulnp8Sw2cN2wvhB GnQRm4dup+833mzXztDcT3XjX4tTXM8t1O/xb+JjtNcSPLMzv4415neWWRmklkdyzySSM0jM25mL V1PhjwJ42+KnjvwB8LPh6+kw+L/iP4s0jwjol1r1zJaaNaX2sXkdnDc6lcQwzyxWkLSGSdoYJ5Nq sqRMxxX59xbnme5zxbVyzC4l4SOFxby7L8Lh6kqVGjBTUYppWvKTtKU2uZy0Wlj+4Po5eDvg34T/ AEcMo4ux/DGEzaOZ8N0OLOKMzzPBYfMMwxlSphqdeqoucJKNKgm40aEZRhBXk3dtv660X9v/APax 0QKum/FCWAJjbu0WwkZeoyGYccfyr0LTP+Cpf7aOllSvxNurjYeDCz6YWAYHBFmzccZ/Lb6Vo6v/ AMERf29dF12fw6f2gv8Agnr/AGva3a2E+jaz+09B4f8AEcN85URWNx4fvfCT6jBdymaLyrWSJLhm ljVYRvTd8C/GH4R/F39l/wCPPj/9mj47Q+Eh8S/h5D4duNaufA2t3XiDwxND4o8PaX4m0xtN1W+0 rR7m5/4l+rWy3TS6fbGG5E0I3rGsknfm2Q+JfC2AnmWLx2Mo4SHs4zlDGS2duW0XLn9bL5as+d8O vFf6EXjjxRR4G4d4U4dxnEGPp1pRw9fhuhCUvYxXOnX9lOEdLq3Om+11p/RV4C+Itp/wVF+Dug6T L4k07wX+3F8FRqOq/AH4j6hfLbSa3cywySeI/gf8Q9RQ/bNU8B/EbSzfaNNdXiXEdrNcWvjKGFvE Gi6fbycJ8Nf2tfFuhz6f8L/hp8MNdvv2tPEWuax8L2/ZkaLT7bxH4U+Jvhr7Cmr3Hi+Ge7jbRvhv 4Xs9atvEtx48vvJ0O40fWtL0+O+k17VrXS5vwN8KfFXx38FL+68ffD3Xp9C8R6bYzz2t1EzFFnt1 FzZ3LKjKGnsbyKC7tWY7VmhVZEkgkmhl/p3/AGnvEN/8PNC/4Kb/ALWXgwWHh/8AaE0T/glf/wAE 89W074n6bp9nbeJdM1P4meOPjjpnjnVbG7eCXytS8UWVtp1vrF80Zur6PSdJjmmYWNqIf13wz4nq cVZRiZZjGVbH5HSip4mUdcRQ5bwg5a3knBJt/Fv3b/zJ+nl9GfI/BnxN4ZqcK4mll/DfiRjpU6GV pS5cmxDxOGo1p0lFcv1dqvGcYRvKLUraNW8d8Xf8FAbL/gnfrGq/Cr4W694b+On7ZXi/VtK1v9sr 9qBLW3vdBi1GwkWa2+AXwwF0vm6d4P8AA1rHD4fsbO3isrWyaGbWdWgt/Gl1rWladBqH/Bw9+0jp 7QR23g/RbguhMhnjsjGYznYY2VWZ35+YSKrI27tiv5tfDl1c3+kafql5NLcX2pwJqF7e3Esk9xeX 16Dc3V5czyM0txc3U8slxcTTM0kk0sjM25jXpfgD4UftGftCeMLn4d/s2fBLxR8b/G2i+GrjxXrO g+GLnSobyz8Owapp+jHVWOrX2nwtEuo6pYWvlxzSTtJdRlIvLEjp+R4njzjrPeJK2ByPE1KPPVq0 cPgaMqceSFKUrWnLlTlZScm9W3okj/S7hj6I/wBEnwc8Dcrz/wAUuHMqzWGEy/AZjnHF2dYariqm IxGZww7nzwpxqTp0YucYUKaXLGLtu23+/EX/AAcY/tJ4KSeBPDjYBz/xLdHlHIxgNI6MQT8xwvGO tYOh/wDBe/40zeIbJvEXh7w/b6Jc3ytqUv8Awh3hicRW0026fzTAZbs2aqzeYbaKe7UbzFDI+1W/ Jpv+Ca//AAVliQtJ/wAE8PjbGFyHcyeFNqgYO4v/AG/t2hWPOdpJbptIr5C0281YXviHQPEei3Ph 3xT4S8Qaz4U8UeH74xm+0XxH4d1K50jWtJumiZ4ludN1GzuLW4EbuvnRSbGZNrV05vnvixw7SpY7 Nq+Ow2HdRU1OrKMoykuV20lKyly2b031PK8P/CT9nz4yZnjuG/D3I+FM2zieBq4mdHA4OrRq0aCU YKvTdSjCLnBzTtzSlF3kk9T+r288QQfBix1f9t39kOwOp/sx/EDUl8S/tffADwtG2p3nwK8W6pcL qWoftHfC3SbPzJLrwdqWrD+0Pipo+iwtHdaPeal4wa3uhofmL8hS/wDBRT4kfsI/sT/8EqNS+DGn +DtR8N/tV+Df2qviF8Tr288OaPqWueNPE2kfFnSIvDfjF9Zvo2vDeyaNrRsr37RIr3lpDptvdbW0 u3jX4+/4Jp/tV/Ff4O/tGfB74YeG761vfB3xP8faP4K8QaPrCm90+Xw74muV07WdMmsZVktb6xur edytpdRtF5wjjdWs2mt5P0S/4Ld/sN/G74k+E/2BIP2H/wBm/X/ij8LP2d9I/aetPF2m/DIaGdF+ G0HiTxD8PdftbPUkvdXsnsDqU2n+JtQhsbeKY262NwJIbVJbRJv2rJOK8bxhwRj8fllPEUs5wlD2 dqb92pjIwi41Ia2UpOLve1rvof5heJv0c+EPo1/Sr4P4e4wxGXZh4a5/mlPMksxpyqww+R1cR7Kt h8ZBwkpexjNcklzSa5WveVzxuf8A4LzftJNHsTw7oAU9f+JDoUPIz8uYxuAXH0x/v13PwR/4Lnft Pa18cfgv4Wfw54VNn40+Lfw18F37XFraqIdK8WeNtE0DVZoxDbsftK6bqF19nbP7ucLIWwpr+dTQ tXk1m1mkuLKWwurO7urC9sZyPPtL2xuJLS7tpdruhkguIZYWw5BZHIO3bj3r9nYD/hpj9mYE5z+0 T8ENo64I+J3hY4J7E4J6ncPpX4Bl/HfGiz7AYDH5vjE45jQoYii6mq/fQjUV1dX5bqXfXdXv/rzx p9FP6Mk/CLini7hjw84dnRnwdmWbZPmNLCJRd8tqV8PiIXUZb8k4X1i3rqfdH/BQH/gm74m+Jn7S /wDwUF/bZ8K/EH4ceFvAXwJ/b38N+GpPgndw6/Dc6jpWmt+zvP4gutG+waDP4d0mXWL7x/Hcw2LX tnb3oh1RrgwsId/6C/t/f8FfP2ov2dv+CjX7TH7OvgS7trf4YeCI/hRH4G0Wz1O60ePwxFqvwo8E 61exWg06ApLZT6hf3Nw0flqsYlbyFZSu74O/4KD/ALQmqeGPj7/wUr+CNpq9uE8U/wDBQrw1fTaM 10bW5ktdVT9lxYr9IS0i6jGsuh3MRj2xjKszfdrxv/gr4Mf8Fj/2u8rgFfgruKjGCPgp8OwABzgb QPl4+UZ96/oHxFzF5bwnnONynEyoY2hi6Xtq9Go6daNSUY3T5Xde44u3mtD/AB5+g/wjT498f/Dz hzxGyTD5xw1j8nx9HAZdmuEjVweJwFOb5K1OlUjKE0qymlX5ea6fvb2+m/F3/BZ/9tG60fWri18d aros6aXqjW91H4o1S5jsZE0+523vk3qwqRA224U92jGOcV1P/BYD9pj412v7d3wp8IeDRFP4I+M/ 7L//AATluPjf4jluEjvL0WvxV+K2raG0NuzpNNHdX+p6pcNKscjRuvzhFkiY/iB8Qb5j4d1y1gyY zplysxB5YCNsID94ICQG/vbdv3fvfod/wWO+Itr4C/br/Zmn1adrTQ3/AGQf+Cfmt69fEk21lo3h fxp8QL6/u54FiaSX7Lb3E86BGXbEk37uVmUL+deEvEOeZlluc4jNMyxWLccdlUabxFSU/ZU6mIUJ 7yuk4ybatbRXR/Zn7Q3wL8J+FON/DTI+B+Ecn4bweI4a47xOLhlWCp4aONxuXZVSxOFUo06d60oV qUYwbvZzla1ztP8Agpd+0j8bfB3/AAVG/bp8DeH/AB5rMHha08efD+ez0i7YXtrYPcfB74fXE402 OaRvsdvdXM0t28cKrHNc3E1xt8yZmb4mvP2hPjffK274m+KrJcBSmm6hPp42ryFUQSrtHyj7vp3r 7z/4K9fsffE+/wDiz+1N/wAFU/hd8Wf2ffiR+yr8SfGPwiuNGh8GePp9e8e+RrHgbwf4Rs5NS0S1 0f7Jos1xcaU2pRWOoalHef2ZdW1w0ETP5C/lBayvcWttKy7fMhjk9TiRd3XpgBiD0xj6V8j4q0c8 yniSviXiq9HA5g3PBqnXnGMoQhT52oxkkryd72ae190f0n9ADMvCnxA8GMpyWhkWV5jxVwhQhg+J Z4vK6DrUsRWr1Xh4SrTp3lyUqdrS96HLytJNH67/APBMbxp428X+L/2wovFvjHxL4nii/Ye+NzwR a1rN5qCwSS6daoWiS7lkwzBRvZfQ/wB7dXz5/wAFRkVPGf8AwSpgLEC1/wCCQv7KVttJxkfYNcJB AOedw3L+New/8EnfNfx3+2HHBGss3/DEHxpSGFm8sSytY2wijLkNtEkmFZgD96vYpf2cv2YP+CqP h39jC/8A+Gj/AIo/s/ftG/A3/gnT8M/hzefAfVfhY0eo63a/CDwSfEeteK7LxNJq11ol1ol/HfzX mjxWc013d6BLp19eQ2N1PJp9r+p8JYDH5/4UTwFOq/rOL+txhWqScnJRqXbk9Zbp6WvdXS11/gX6 RPGXC/g9+0Cy/irMcvjDh/IJZHWngMDRpU1KUsJhoSpworlpt3m23JKNt2fiaI0IO6NeOQCD19hz z/ie9KIk3KAignOeByQPyrgPhfrd/r/hLT9Q1CYz3EqMJJWHzSEOV3E+p25Hf8a9EIweex/Xp/Wv 5WzDD18DjcVg61RyqYWtOjUcZSaco6S5ebWztpdaWP8AfnhDN8q4q4ayLibLcLGjg88y/CZjh6dW jShVjRxVOFaCqKCceaMJRi7Nxveza1Kt1JJawSXNqxhntgJ4JkGx45o2V43Uj5gysoG9fSv6tPHf i8+I/wDgrv8ADbwJqO660f8AaG8ffsMeM9MUfvJVtfgl8BPEXjm9uoSC32i3iv8Aw1DJcMoYRkbv vKK/lMvADbSg/wBxvx4zg54xxX9LXhS6uNS/4KSf8Efvjgdkuk2f/BPr4vftB67cElx5vgj4T6n8 ObZ7l/utF9m8XPIsjcrJjaowM/0D4A15OXEGG5nZrB4hvf8Ahe1Wqe/xJdLaH+Of7X3JIYjCeD2b RSUqOPzrLaa0V5Yv+zqjS0bT/cLSzdk3tY/Dr9o3x3B8VP2tP2uviXbzx3S+Lv2i/iBcrdxMrx3F vpsmn6NblGU87Tp8qsMfKysuMr8vldeZfD7U3v5/F+oO+6HxD8QPHWuQMTkbr/xRqc2FJGf3kZVy zEE7emWr02vwPj+vLEcW53OT5m8bWpqX83JUcb/+S733P9fPoi5bSyn6O/hVgqcHS5OFMqq1KTSX s6mKwtLEWdurdRPXTXsNn/49pcdoZT/n8a/0EP8AgmSAPhV+xv6n9lHVgT648X2GM+tf590//HvN /wBcJP8A2av7/v8Agmhq2n2vw3/Yy06e7ijvrv8AZI8RX1taukhkls9L8X6Kt9cRyorIsdu1/arM rfMxnhaHdtkr9m+jc2s0z572wUfu9tQ/V/ef5jftrk3wD4T26cWYq/8A4a8Yfsu2AQDy3QE5AyeA CB2we39TXwl+19pEQ+KH7GPxEmDfY/g58YPjJ8Qb2RhtSG2t/wBkD9ojQ5Hkz0h3awqM7fLvZfmw ymvuSC5iuctFIH2gMThhjcu5MblTPBH+1tHzfNX5Nft//FnUPDXjD4xeEnglGmeDP+CZH7YPx+06 4DARJ4r8NrovgWzhIICrO+leMNRWJ1bdy0eMNX9cVZezpVmtHTpOfZ7PXp2uvPS5/wA8mXUVXzLA 4dR53XxWHouHLfmlUrU6aj3d+ZpabM/ztvC0636eKNXBDNr3j34ga6X67/7R8Z63KHBxzuRFP49B XTY24x3Gfzz/AJ+tcV8NA3/CBeF5Jx++utOe/nwePM1C9u7+RtxHXdcj1/irtuGYjIO3HzBgobjo h24LDp7YPtX+aHE9eWJ4kzrERfx5hipb7tVHFddFd/8ADan/AHE+AuW0sj8GfDHLfdg8NwbkFPll paq8uw7l001u9fwP0J/4JV+JB4V/4KAfsx6x5giNv4/vLZnJAyPEPhfXPDsaA9NzSaqi9e9f3o/s MeDrf4e/su/DTwPCUjbw3P45guLZWVnt7i9+IfivV3tp0B3RSqmpxSNHIqt5csbbdjV/nZfsha7L 4Z/ak/Z41mFirW3xw+ENvM2dhW21X4j+GNLuJFPotreSbv8AZLfxc1/oN/sR67rWr6v+2hpuqNKb Dwj+2p8QfDXhaByDDbeHB8KPglrscFsAihLcatrmrSxrlh5ksjbjuwP6u+jriXV4YzGhf/dsxT31 XtqcJL/wLkt/mf8APt+2ZyOngPHTgjN40+WWdcGSTmo+7L+zsfOm4c3Vx+tRaS0s2+p91rwCAO+S BjCsQCQMn1O78adnGSQRj6f40xVHJPJJPPTIHA6HpinbF9P1P+Nf0Of45Cgg8iloAA4FFABTSeSO AeME98+g9v506mMitncAfTPbjHH6mgALckZA4yO/vknoBwRk/WvDv2lnz+zh+0ApB+b4I/FdePmP /Iha+eMZHoP975epFev3Wn+bgw3NzbSLlomilYxhyuFMtvvWOdFPPlyZDdOelfN/7SGn+MNP/Zh/ aFT+2dN8RX0nwi+JUitqdiuhW1tpreENY+3RoukxXjzXkNgbiSxaRVWW+jt0uJIYWkmSHpUVtfcf /pUb/dqaQpxklJ1FG0ouzvvp2TWn+Ja33Z/BV/wWLyf+ClHjZgPlH7N37NQBPHXw5r4X5T8x3YOf TY2a/LPxVKWs54FP3YJGYc4LFOAQOoxt9+fev1K/4LGgL/wUo8bkfw/s2/s2ZJ5J3eHde5wTxuAA b0Yf7VflNrcoaK/PU+VMMnuNpA9eg/zkV/B3idCT8Ss0l0jVwend+zo9eis2/Xvof9Zn0E8Sqf0I uBMPGTUq2X5+nvZxWLxctNX15e2nMj+t39ijwn8S/E/xJ/4JlzfCv4hj4f8AizQ/+CN2salax6jo dhr3gzxXMP2gPgPb2fh3xzby2r65D4eXUJbbUbpvB+peHvEkjWKw2+rJaS3EMn4Zf8FIf7X/AOGL /wDgiQuvixGtjQv2401Y6YlxHpraivx40FbyTT47yae8isZLgSSWcd3cTzx27RxzTSSKzt/RH/wT OJT4x/8ABNkhCFH/AARkv0zglUZ/2jv2fT8xA+WJRnb/AHf97ZX89f8AwU3/AOTQf+CLHO7/AIl/ 7dvIVU/5uB0X+FSygf7vUf7Wa/qviSEP+If46pGpKUp5BQ5o32th6OqW27b363fQ/wABvBTE4h/S /wCG8NUpUvYx8W8dUoV/ZxjWknm+J5lKpFJyi3ryybUXFWsuZH5yyfcfI6hsHPoCMY/z+lf0B/sn /HrTv2Z/2Hv+CWfxo13wr4n8X+GPBf8AwUL/AGprvxVp3g7TptX1+w8NX/7N/wC0NpWt+IrbTbeC 5uL218L6dfXPiPVLeGPzJNL0y8WOSORlkX+fyQHbIe2G/PB/+vX9JH/BPr4hfDX4Zfssf8ElvFfx d8RaZ4R8AQ/8FFf2qtL1rxDrKOdJsDr/AOzP+0VoWnrqNwsM0VjaXGp6jaW0uoXnl2NhHM13f3Fv aQzTR/gHgdNwz/Npe1VBrKK1q005QpyeIw6TmopJxu/ed1ZXvZan+vn7VCNCp4Q8AwxOAxGZ4eXH +XqrgMNLkxOKpf2VmbnSoT5KjVVxTcGoTkpL3YuWh+ifxFsPgf8AGT9sP4LftP8AwHfQPEx+Ln/B Nf8A4KKaZq/xA8PTLJa+KNJ0a1/Z6PhWz1d4pZLeG/0a78RazbqJFW9hmvLy1u3cwp5X8K/wc068 tvhz4dmliOx7AMjg7gQJZUJOOANynIz2z1xX94+r/smfAX4GftxeHvi3+zF4mtE+E3x3/YN/4KD6 3L4C8IalZaj8LNL8UWFx+zdNqHjDwUdLurjS7NvFg1CNdYs9ORLT7VpK3cReW6ulj/hu+DDZ+GPh IMAc6bIORkY+13GM5/2T75xmvqvHKpiMPw1k31ijRUp5liH/ALPPmo1I+zpyjVpvljyqpzSm42ur 2cpO5/PH7KrLsoxvjR4i08pxuc4nCR4QyqOElnWH9hj8HetUU8DioOU1UWBqUVhadSLhGpGmpRhC LUV9s/8ABOw/8Z8fslk9/ipb5/8ABJq5r+hfwjZ2sHwV+G00ahZLz/gqvC9yQSWlkGj+KVUlSduV AO3aq9fmFfz/AP8AwT30+dP+CgH7Jht7eWSJvinCw8uJ5QmNC1lmU7Fbb6rn+EHPrX9Afgtr24+E XgHTf7J1FZNO/wCCqFhI8zWNwIpFu9I8YhBG5jOWUwsW3fd3Lt6tXt+BF8RwtjfZ35fr9OUtG72j HT/t22vX8l+SftdqEsN44cK0Kuk4cMxUv7zWKhyyS6J9H1SP5fv2q8n9uz9uQlidv7R/jxQOwC6g VUeuVAK/gPpXN/C+b7L8WfhDdR8yW3xc+F06EZVt8Pjzw/IoDD5gcoPmHNdZ+1ZbTr+3X+3IDDMr D9pDx4rCSJ1ZW/tAkhwUUhuQenzD5hwRnkPhvDO3xV+EyiGVmb4r/DIKiIzOzt450AbVVR8xbOFH 97byK/EeK5W8ScY7q8c5w2nkp0dGvzv/AMA/1X+j9SnH6EvDrdOUubw2zj3uVy/5hsdrf18/vR/e p4F2X2rf8FQA0qG1tNOvtQuImSKQXQf9n2ZWiuDKjeZGsiq67v4kVuNlfx8/8FXpzc+LP+CTs+SR P/wTE+DUmSxfljqpDKWJPKlVU/d28L8qrX9Zngi9vLPV/wDgpTFOGg+16bqUWoqSFKwj4C3qLGw3 ZD/PG6kL+f8AF/Ld/wAFaPBVnY67/wAEkJYL6cpN/wAEu/g46pJHG4UQWF9dYEm4MwZptmXz8q5y Bha/ovjScVwpxRVcVFLBJz5el4x15Yr+aUf12P8ABz6HmAmvpTeFEKbjOeI4pjGirJXjTxE5Si5O yt7Om93Z2XV6/ltfKos7n5Qf3T9fXHr1r+kD4SfL8Z/+Dfvvn9lL9uQ4+p+GgFfzv3ehNLbzRrOo Z42UFgcDKgjOB34//VX9MXwm+H11/wAL3/4N9bCPULYmf9k39u2ZZHSUALbL8JnZWARuW+3Rhdu7 /Vvur8u+j5ONbNs65G5J5faWrWntKXW1002lbzP9M/2wGFr4HgXwnhiIezdfjKUYaxk52wGIclo2 tEpN7qyd3d2P5b9Mt5ZvGfxaSJSWHxb+JeSOg/4rbXMZbGBzyAefx5r7O/Yf8J3eq/tn/stQi5ig 8v40+B5WZ0aZQI9btJBlEYbjkArn7uN/vXzfaaYNN8SfE+EsrTH4w/FlZ5EBw8lv8QvEVqCpI3FS sQ27lHuPX7F/YOuIIP20v2YzNPDCD8YvBSqZpY4wS2tWnC72UlmxgAcnjivziviJvxQlStHk/wBY op/FeS+sQ1vfb8T+2cpyjD0/oIxxdTmeJh4NTlCN1yxnHJZbRXxOLS11V91ZI/Vv9qj9g39m+8+F f/BSL9onXfg78PvFXx1t/wBswwaT8TL7THm8YaQug+LP2ejpv9g308sk2k+Smva2Jl0v7L9sW/mS 885RHt/Kf/gsW23/AIK4ftOqyjLeGvgnkkfMM/CDwSCjA/d28/T/AHq/oV/aL13Q7j9mn/gpSZNS tpX0L9sjU7/7JbubiSVpPFn7MiKqm3EkKbnzu8yRV54Nfz3/APBZOcXf/BXv9qS6CeWLnQvgxcKn GUE3wj8FzhGx8vyiTHHpX7pxti8bjOEuJ3iq9StGjmUaVKM7WpU4uPLCPpy9D/Cz9n3hKOF+k9wL OjGmqtbA5rKs0venzd1rfe3lpqfnZ4rUf8I3rQ7jTbvn28h+COMjiv6m/wBs0Bv2Wf8AgqacYI/4 JOf8EuvmBPIPxH+O/BBLZxj+LnuK/lm8V/8AIua1/wBg28/9EPX9Tf7Zf/JrH/BU7/tE5/wS5/8A VjfHivE8CG1l3Fqvp9VX/pub+R/aH7VqMf8AW/wCt1zqtF97LMctX38rsz+WHwiNvhfQTk5/sq0B 7gYgTnGOtfrH/wAEs9V1Xw9ff8FGvEWg6pqWi69ov/BL39qDV9F1rRr240zWNG1bSrDSdQ07VdJ1 O0khvNN1WxvLeC70/ULOaG6s7yKG4tZo5o0dfye8I/8AIr6B/wBgy1/9EpX60/8ABLDR5Nbf/gpV ZJNHbs3/AASv/atxLIGZVZtK0yNGIAbAV2VuM/KpxzxX594dxcvEjAqPxPHYy3nywnLfp1fna3Y/ rH6afJT+hHxROT5VDhLhhp9pOtlaT699/M+sv2PbPXfBP7T/APwTl1zS/in+0xeXfxE+M3w/0Xxp ZeN/2o/2i/iN4T8TaRrvwY8b69rGmaj4J8f/ABM8SeFL62vtYtbPUFZtFZbGa1jjsxbowWv5+PiH r+j2f7Rn7Wcd3f29vOn7Ufx9Zo550SVdvxX8WfM4d1ZTxtbcd24Mciv3y8K+CfiX4X079lf4v/Cf WPCf/Cy/gHrfwv8Aix4W0jx7P4ii8M+I3034c3/hu88La7eaTpOpTWGiavY+Irq6jv8ATYbyaO+0 6zXy9omaLlfF11+zz4j8X+KfE/in/gkp+yTq3irxT4j1rxJ4m1hfihq0x1rxNrerXmq63qU1xNpE TM+pandXN1M98IbiYzYmRW+Wv6Z4y4YjxjlCy3EZhLCSjio1/aODqe7BcvL8UVy3flrftr/gd9E/ 6Rcvo1+IGO42jkMeIfrGVV8uWDni3hIx9tKElVVRUqu3K1bl369vzB/YY1/SNT/bW/ZUt7PULaad /jX4MCRxTJK5A1SMsAiFsDA+ZlVdv3v4c1+1H7OmveItH/4Kr/HLTdM8c/EG00fxd8T/ANsfT/Ef ghviX48ufh3qlpoPwz+ElxpTxfDebxC/w/sb+zn1fUGk1TTfDttqUyzrFcXUkUESr4/4A8Z/A/4Y eNfDXj34bf8ABKD9krw58QfBmq2/iLwlrM/xM8QWaaN4itZRdaZem8tdCluo4badVZriwjuZYbfz PsqySFVbof2OrfxY/wC3b8PfE/xD1bQtW+IvxJ0D9rf4m+O5PDqXi6Nb+KPEvhjwVaz2OjG/tLK8 l0qx0rSNIs7e4ure3uLp7eS4khVptzrgbhKHBuX18DSx/wBdeJrus5cjhyxdPltKPPKL3fV77I9z 6VX0m39J7jrhTiepw8uHauT4KOXSwscU8XCt7TEUqntVUdKk76crXLurt7o/no8KcX3jZcDjx341 Hy9OPFWrDA/2VA49ulfRX7OcbN+01+zKd4GP2ifgly2cKB8T/C2ec8FsbR9R+Hzr4UAF/wCNx3Hj vxmDjpkeKdWHtx1x9eK+nP2YNNl1b9qb9l/TrcxiW5/aL+CoVpsiMLF8TPDM0jkgM2Y0RnTaG3Mu 0n5q/lHGPl8QZ8rs1n8N0t/rS2v069tOx/0OZFyy+h5hed2UPCGq3Lty5Fe93q+t+9+4f8FPvhP8 XPE//BWX9uH4leGtCkuvhj4C/bD8Ar4n1yWZUhhvIrn4Lwz2sMTkNJcqPEGmzOF5aDdg5VTX0H/w WHLR/wDBYj9sSRWwyp8FjHtJK4HwR+HRYknr8xbaM19Fft+b9F/aQ/4KWaFDfH7X4u/b98GweSJr loks7uD9le6LyQLH5byxNEibV3N8ztyvzHwn/gtPo0uhf8Fj/wBru3kuIrgz6f8ABW5BiBXYsvwX +H6JHIGCqJMR7sDjay4z1r+lvFXC06HBWcSjGKeIxNCrWlb46j5Yybb7xSt+Gx/h/wDs9eJcdnf0 nvD6ji6tWVPJMizHL8HGck+ShFTq81O0Y8qVSu7JXtzK93qfm34qJHhvXXY5ZtNu+eT1iY5GOfXr X17/AMF89Rjtv21f2fdLlCsdX/4J6/snWsatjyy8978Q4YywJwSplbJ/uluMk18heKmU+G9bUkAn TroYP/XJgef8K/Xn/gql+yBqf7RH7Yvw6+L1t4t8KaTo/wCzt+wT+wlqPiDwl4ilure98Z2Hiyf4 5ShNBmjt5LE3ekzeGFlmi1C4s4ZIriNI5WkZVb8y8GcE8flHE+Haly82Al7unwSlKCjbzSu9OXqf 3L+034onwdx34J57TcH9WwXFdJucVJNYqhhqM+aMm73jUkrdfhejM/xP4c0Dwp/wST/4KNaB4e8N aH4Vg0v44fsT2t9p/h+z0+ysbjVV+A3wXGpaq0emwQQyXesXTTajeXDJ9omubqSW5kkkd2b8rNPP /EvsQPlxawdOMny1P9B+X1r9Qdc1e21r/glV/wAFULyzvo7+2X9q79liGKSKMRrEifCf4T7YNg+6 Iwdqj+FQq/L92vy+07/jwsv+vWD/ANFLR47QlTlw3CafNDB1Yu/ksN+O/wDwSP2SmL+v4LxnxbSi sVn2W17RjGMV7V4yekYqPKnfy8tkfq5/wSS/5KT+12CNwP7FfxeBXnkeVZ+n+cZr9FP2StTeX4j/ ALClmJR/ov7B/wAWJzCp2mJz+zToEYfap2x+ZEka7Y9q+YWcqjNur86/+CSWP+Flftc5GQf2Lfi6 D7Zisxu/4Dnd+FfQn/BP34y6J4y/a2/Z/wDhTZzxT6x8Kv8Agn941l1xFB8yFvEH7NXh+6sI5Sep msLm1mX/AGZF+av0jworxo8EZapS1nLEQhHa8pN9fP8Arofwt+0Rw1Sp9LPPK9Om5wp08gdX3XKM Yyo4VNy/LqrH86fwWYv4D03KhcCQDGO0rDqB19f19/VirKMLknPc5P5k/hivLPgv/wAiDpZHfzAc enmPx+deoO6owLsFAyPmOO3XnHr+nNfyhxL73EOcWV/9vxGmvSb7an/RH4JShT8HvDl1JqP/ABiO R/vJcsFGLwWHcru9unz+8bOC0UicEGJwxPQ5Vh+een/1q/qj+BPhBbv9hPwB+1NcBAPgX/wSB/aj +EWj6g23Ft4suk0fULGy8xh5iSTWmkzwqqMD5jDauK/lcciUFUIKyIQG7Ec/MPbmv6SvA/xQl8Mf 8G2/x+1mW5WO70278cfDSMl13LaeK/iXoHgazhUkrjzoNe8tV+VmY7QrdD+reBuO+qZznVOb5YSy XEVnFO1/ZTp2v/4E7dVbU/gf9qRw3Tz3w98L8XGm6sqPiVlOX06kLS5Y5jRqwaTWrUvYx1bSbeu9 z+Xv4ULNb+BtAeVi0zxPdySdGaS6me5d2B/2pW56817tBIJYo5McOoJx2IxnuO/Htn2ryTwfa/Yv DmlW5IxHZWynB6YhQkAemfvZ+63avSNGvILm3aGKeKR7ZnDorh5EUKHy0YJZVbcdr7dpPf5a/FOI ufF5lmOJhHmcsZiKkpKPwxqVG+ZvS3vcuvmz/TbwYhDIOC+Dcjq1KVH2PDeTYOlSqTjByrYPA4eH JTi9W+RP3Vd+6jUmGYJfeGQfz/xr/QK/4Jl28L/C79je4aKNp4/2UNZWOdkVpkik8X6YZYkkYbo4 pmjiaRVbazQx7uiiv8/WX/j3k/65zfzr/QO/4JlMB8Kf2O+vH7KOrblGSVB8X6eVJGd2G2Phtuzj /dr9y+je7Zpn3ngqS3718Nf+v0P8p/21rl/qH4Taq3+tWM73/wCRXjLWfp+p+we3G3AH94ggc5JY 5x3zluO5r8Kf+CyGsaR4d+Bv7ZHxKsr5BqnhD9hbxl8HtalRlElg/wAZ/iR4BbTbG4ZTuQ6taWrt DGWXzEZvlZSMfuyTkoAB0BHI5H8WMHuv8/Sv5Qf+C4Wq694e/Zu/4K/JdXkosPHvif8A4JweE/CV uzMFX/ib+GbvxDBCsm3aLuK1uvOWP5tzHzAvzMP6rzerGhleY1Xo44LEtvS/u0ZuPrZ/pvsf4F+G mBeaeIHB2BUfafWOJskpSjZ3cnmWFi/Vcr5ra3s9tUfyJ+G7QWPh3QbNQFS20XSo1Q8gAWUJbO7+ Lc+W246+nTDbUPEdh410nTNQjU6B4n0nVdS0KcxqFb+ybq9sLxYygUZiu7GXBIJ2FMjflh19rH5F paxjA8u2toyD1ASGOJkJ67vkH5fifZ/jJ4Fi0L4F/sG/ElYdn/Cc3H7SOgPcFSGmbQvG3iaK0jL4 2sFMkfRi3ONuK/z7yTL6WbVeKq9WkqroYPF4mEpL4Jp83Opa8sr26O131sf9gHiXxbjvDzA/R7yb BY+rl9LNuJeHcgxVGlLlWKoVMPh6U8POLT5oJc7cUkna6s0jnPhbqw0L4l/DzXfMMY0Hxx4L1suS QIxonibStW3nBXAjNmG3diDt521/pK/spto9hqHxt0y3lUa34p8e6J8YdUgBXe+mfEL4d+ENH0fU CFO7ZezeB9UijdhkmzcBm2tj/MreaSCC6lhbbPBp+oSwPhv9ZBaSurgqN3UfKMBt208Gv9EP9hy8 1fXf2hPit4oknkl8Oa7+xL/wT+bSUDMY11ewvP2pIdflAx5avMj6SrMrbnER3fdWv3L6Ntb/AGbi HD8yuquFqcl/iTVSLlv9mz1t9pbn+V/7a/LV/bHg5nKpcynl2f4P6wo/w5e2y6rGlzafxE5SXnT2 2P1SQYGM8DgADAUAAADPPT+tPqNWUg856E9cHcA2VJwGXn+HPcdeKfkeo/MV/Uh/g2LRSZHqPzFL QAUUUUAMIGcsR07jsOTjn8/8K8Q/aZUf8M4ftAkEAn4IfFfA7nPgPX89SOoHt09q9qnmihwZZEjz whdyoJxyMA8n/PbnwD9pjWNMH7NX7Qk4v7TZF8GfihbySmZNi3Nz4K1u1t4WLHhri5ljtowfvSSK q/NUNLnT/wCncr+S5o/mOMZbpe65Q+H5PXlv/XW238A//BZOQJ/wUj8duOo/Zq/ZsxjoSPDmvjqQ R1PP07V+UmobpbO6ABZmhlVAFyS5U4AA5PP+ea/Vf/gsuCv/AAUb8fA7QW/Zq/ZpOwD/AFZHh/xB 8nXgjDZ92WvyyKsNhViGU7lfqFOcg4xyVwO46V/CfihKNPxBzio7tQr4WTXeMKFGXrrZX06XP+sT 6BtCeJ+h94a4Onyx+sZZnlJPVWnVzLE0lJ92vXpo9j+rn4KfAPxl4p8H/wDBNz4y2nh/4nXXh/wN /wAE1LX4Q3OtfBjxronhP4neA/iTrvxK+FvjrTb2DTvEcVxpdxbf8I34Y1uFn1KG8jh1CS1tZNNb zDdW/wCQn/BWD4T+Nfgh+zL/AMEa/g/8RY3j8f8Aw78Nftf23jC1l1iz16/tLnX/AIpeCvE2nSav qVhBZWtzql5pOsWV1qEkNna2zahJeRW8flw18tWH7af7VulW1tZaf8aNasbSzhhtrW2t9I8PxQ21 vDF5NvFDGukrGkUMeEVVTbtH3W/i8w+J/wAZ/ir8apdGf4q+LrjxpJ4fe6k0SbU9P0pZtMa8WAXY s57eyhmt0uvs9u11FHIsczQwtIreXHs+8zXxdy3GcOVcnoYDEKrWy+ngnOc4qEeSnCDnpHmaVuZK TbV7bn8k+Hv7OrjjhjxkyPxAzDi7J5ZVlHGGK4pWDoYevPF1ZYjGVcUsM6jn7NOLq2cuWN7N2bse ZyMCrdOVYj1Iwfw/Kv6b/wDgn74/+CHwk/Yb/wCCYXjX9om/0HSfhZ/w8C/avsvEeo+J9Gk1zRIL bUv2YP2ntMs01C0hsdRcQz6qloiTi1cQztHI7wwq80X8yEg4du5Rtq8YGAR1z659Bg/Sv6ZP2Mfi 78D/AIFf8E+f+CXXxC/aA0efxB8MLD9vT9qK08Q6XbeDZfH0t1Nrn7O/7UWjWNuPDNvbXs2oI2pa haLcFbaY28BmuJVMcUhryPBCahn2b1JTw9OKyes5VMSm6ELYnDPmqpOLlTS1avG+2m5+j/tScNPF +FPh3hI4fM8XUreI2ApRw+SzjTzWv/wj5t+6wNScKkIYmpZezlKnUs7e437r+69A8FfsRWn7YnhX 4lfsTfEOw1vwl46/YI/4KDx+IPBHhjxVfap4G8P3mm3v7OV1ba1oPhjUma88K3mtTarfRaoEb7Df Lp9gtnZ2TWlw1z/E18Ghj4Z+EcnONNkz+N3Ofyxx/wABNf2b+B/jP+wJ8af24tH1j9jv4YXPw98S WH/BPz9vaP4gzf8ACptS+FGn6npk93+zu3hyOGylsdL0zUpra4TWWmktrRp7VJoxcSYnhC/xk/Bl T/wrHwkuR/yDZDkk5y11cHBJ9Acf5NfQ+N0qdXhTJp06+Cr03jsTOFTL+b6rtTUlCE5ScFs3C7Sd 4p21Pxr9ljhcZgPH3xNw2OwnE+GxFLhLJ3UocXypTz+gnWxLjDHzpU6MK8nFpU6nsoSqU+WpKEW2 fp7/AMExRn9vv9lUNjA+J5OGAPXw5rmDz0wPTtX9IHgzV4dN+HPgHRr8h31//gqnbXWltEINsEVh o3itHtbklvM33TXJkt9q7f3E24r8u7+b/wD4Jjf8n9/srD/qppP5eHNb/wDrV+7Pg3SZ7rUfh9r7 3O20sv8AgqxY6I1s9206qU8PeL7lp1tGdltyxdFbaq/dUkfMa+2+jXRlW4UzNu/LTxlSqu11Gm+/ lf5fM/n/APbK1HT+kLwlKMm+fhPBQkui5sXW2fonr93l/N3+2mB/w35+3lkICP2nPGgARQFx5dlt A75xjd/00DdfvVwnwcVf+Fw/B3cBgfGD4TkEAdviJ4aJyTz0yO3X+8K7v9tIs37ff7eO4Yb/AIad 8akgc/KY7Qo3fG5Nrfj71518LfFuk+A/iD4Q8Za5osviPTfC/iHSfEL6PDcrZPc3eiahBqmmsty+ I4xbajbWt0yyFo51haFlbzNtfzTxlUp0fE3MK9WoqdGlndGpWk7tRhGpSlUly2k2lG99PRs/2d+j VgMbmv0IuDssy/DrFYzMPDXHYTDUoKPtKuJxGHxFKlTg7r3pykknKUYp2u4rU/q++MH7Rnw8+Dfx d/4KCeDPGfiIeHdY8W6Pc6hpFndaF4run1mK8+CsemWJ06403Qr6xuhdXZe2jWO4Lecu1tvy7vw4 /wCCv0q2Orf8EhjfLJYyD/gl18Ho5ba6hktrq3lk0e4Qw3NrNGtxbyrL+7kjmjjljkVo5FWRWU/c Wvf8F/dY+ypJc/AbSda1BLeKysp9as/Beo3AhtoUjQ3Ut3odzMFjWNVRMlnUqwzjj8av27f2uNa/ bu+LfgX4x+NNHu9E17wD4IPw/wBF05JtMGlWfh1NU1HWIrSxtNNsLJbYw3ep3KrjfGsCwxhV8vFf unGPiJwfmXDedYDLMXiMRiMxoqjT/dcsNLWle+11FN272R/kv9Gb6D/0hvDzx+4C434ryPLMsyLh XN3mGKnPHupiJ0vejyxpQpJqXLUWnMr2smlY+XtR1tYbaeSCPeUjJVpDhfukA7R1GFH8Q+lf0j/C 7xprlx8cf+Dfi8jlhtJo/wBk79umGNrePbtS4/4VWkv+seTLMLWL5u5BO0Div5i9UuoYdMvJriSO GJIJWaSRlQAKvHLH2z+mM9P6RvhA8cvxj/4N9pYZVmhl/ZQ/bieKVPuyIX+GoDKOu3IK59q8H6Pe H9jmmcyUJKEsDyyk1Jxk/aUtHLZydlotX6n7Z+2BzeOY8G+FNCtiKM8RS4u9vTw8ZQjVpwngsRTc 3CPv8j5nBTd1ra9j+buG/vbnxp8W2nupZD/wt34nHLMBky+OtelkYhQFBeWR3btubjA4H1F+xqzN +2R+ywWZiP8AhdvgPPPrr1qBwTivlKy/5HH4t/8AZW/iX/6m+t19W/sZDP7Y/wCyzncR/wALt8BE hWCsca/aNgsTwvHzf3lLL9fz6tFLxJnZRv8A2/HXlVv95jrbpp1P7CyidSp9CjDqU5S/41ElrJtf 8iZu2tuvW3fufvv8ZvEnhDRP2VP+CoNvqGsaJp2tah+2RfafBb3+p2dtf3tw/jD9mV47KytJZluL q4ZBu8uGORsBm+6u6vxk/wCCw4x/wVv/AGnd3B/4Rr4Igj0Zfg74IQj/AL7BWvyu/wCCm/i3xU3/ AAWI/aD8Gv4l8RHwrH+2d4e1RPDDatejQF1C61PwGk18NHWZdPN5Imn2StcfZ/M221v8+6PNfqj/ AMFjEx/wVw/afXDADw78EgATkhV+D/gcdT34Oa/pvxeyDD5FwNi3QnVq1M0dDMa3PyqFOpUqypyp wslt7O8btuz30P8ADP8AZz4yri/pT8LyqWToYbM6MIrmtyqm9t9dfK/zPzy8VkDw3rZPT+zbv/0Q 9f1N/tl4H7LH/BU4ev8AwSc/4Jcnv3+I/wAeSQMjnqN3TbnFfyyeKQD4Z1vJz/xLrvvkf6iQ4/Qf 55H9Sfxx13wF8U/id+0D/wAE9NS8e6L8OfjH+3Z/wSm/YV0H4B614vLWvhDWPGvwo8QfGXxJc+Cr jUGmt4YvEniaHVbZNB01ZFur23sdYvts1vpNwq/mngPBzwPFUIaznRhThH+aU4TS/rbXU/t79rJi qeD4m8B8ZXlGnh8PmmLxFWb2hTpY3Lqs5N7WjGL1dlofy1eEyP8AhF9CXv8A2Xacf70CY59/071+ 1/8AwRb8HeJfiF8QP2+vAng7S59Z8V+Of+CbP7RXgvwppVu0Ucmr+KPFD6Bo2g6TDNcvFaJcahqd 3bWsP2ieFPMkVpJFiVmH4knSPHHwn8b+KPgF8ZfCupeAPi58LdRk8M+KfC2swPb3UFxZpGbe+tGk VVv9J1Wya11TRtVtTJY6rpV5a6lYzy2lzDK31/8AszftN/Fb9mjXtf1n4WanBpF94h09LG/v43vL LUTZxzRz/Zk1PS7qyvvsrzRRzvaGdrZpkSbyTIisv5llGNfA3HUcxznDVoQwOKxVWVKK9+pCqqkY yg3yxknzxad2t/U/uHxB4WpfSr+ijV4M8Nc8yzEV+KuHcjwGDx1WpzYbC4rBTwFWtSxkYNzpyh9X nCUXZqTV9L2/dvwv8E/2z9J8F+GdBuv2Bv2t7S40nwz4f0i/s9NsPhBJatqGjaNaafcT2l3cfFt5 vJmmglaFmj2iNv8AUbpv3fzvq/wB/bVkvL+aL/gnr+2M0Jvbqc2EvhD4U3CTMJ5DgyxfGSFmLY3f KFXnrXzyf+Crv7YeNp8e6i+VO3HibxoPmIOc+Xr6sRjurds8LXlNj/wVB/az0/X4NWvfiFr2pWsW pfar2wXxT4vAuoDP5ksKGbXpIVZlysbSRsODuVhuz+0w8cuFMRUhyYDMk/d5lOUIxs2tZJK9tb7+ dz/KTHfsiPHfK8PPEYjirhFyjCdSlTo/WZyrThFS9i05NWdrJtNJu+qaPVPDvxCsNeuPEWjyaZq3 hPxp4O1vUPDvjr4c+O9MfR/F3gjxVpkjwXGj6xpkVxeKjq0U0Nu1vfXGnXijztP1K8t185vob9j/ AFn+0/27Pgiitp58r4OftIySpb/aDKgPhvwyoLGaNcjcpX5XbaBt+farV6p8SPCGk/8ABSv4eWP7 TP7Nx0XTf28vhz4Wij8T+Fytppmn/tU/D7RYomvvA3ia1iEduvxQ0e2hH/CF640a6pp+sW9roscj eHdQ1TR775f/AOCfHjWz8dftt/A7WLSPU7KZPg9+03Y6rpGt2J03WvD2u2GjeH7DVvDur2TRwtDe abf2txbtujTz1RZ1VY5lr9jyvE4DNMLTzPLsQq2GxFFThyyjJUpSjGXs5tPSSdrpW67Xuf5s8Z8B 8T+GXGtfg/i3K6uXZ1lmYRpV/awlGNWMa0VGrQ5vdnQqL3oTirO6vaWh+GvhX/kIeOP+x88a5/8A Cq1b+mK+uv2PIpZf2vP2WPKjlkMX7Qnwjnk8lDIyQQePNBnuJWUDPkw28UkszH5YoUkkbKqxr5F8 K/8AH/434x/xXnjXjuMeK9W4P+e35+2/C/x14m+Gvjvw/wCN/B99FpviPQpbq40u9lt4LlYJZLS4 gaQJMsirKiSuYnVdySqpGRnP8PZzi4YDjfGY2snKlhM5eIqRiuaUoUq6nNRXdxi7a/M/6wPDbh3F cX/Rd4a4XwU6dPG8Q+GdDJ8JUrycaNPEZhlFPC0pVZpSapxnUi5NJysm4ptJH9Hv7aH/AATR/bE+ K/7T37Veu+EfgjbeJvCvxZ/av8IfFjwH46XxzoVlpMfhCws/gSL271HTZFS+ivLVvAfiBDGJJFkC W6/xV+Sn/Bba5W+/4LMftjXUBjmtFtPgbBFNCwkifyvgP8NS4Ei7kLxytIv7tmAx8xEisq7Lf8FJ v2xn2lvi7qzdVkfyLNCysAEA/cbVPDL07V8MfFvx94r+LPxD1z4i+PNQGs+Ldbj0+PUtXe3t4ru7 hsrG3s7I3E0MUbTeTbwRRxySMzrAkcKt5Uaqv6Xxt4xZTxXw/WyfB4DE0q9epCo6lWUXBRp2WkVG 95e6tWrPmt1b/iD6LP7NvxD+j74s5X4lcU8XZJmOBy7CYrC08FgKFVVqlXEwi4+/UqSjGEIwfM+V Nuy2WvjXitR/wjutueGXTLokdekbYPYcfl61+sH/AAV0+Kd38Pf2pND0HT7m9sr/AMbf8E4f2L7S 0uorlLfTLaGwPxthvZtRLR3DPJt1WD7FHHC0hkVvnRWaRfyi8VYbw1rhPfTLwfh5bYB/l/Wvun/g uD8O/HPxN/bw/Z48OeEV+z2kv/BPf9kca1qrkiHT47if4nLbu0YZTLPMsV0LcfeYRybcqsldfgvH FvKuJ3g5RjWjLBLXZXlNXlbX3Nbd3Z69fF/aYT4aw/iB4G4ji+g8TkFKhxNicbQTUHWdKGFlSjKT 0ip1VFSfa9tXpzn7NFrdWn/BDT/gpKl5rVzr9z/w178A45NUu123M8dt4W8CWlukwWSbDW9tBFbK POk4jAZmYszfJ2nf8eFl/wBesH/opa/Qnwl8PdL+Fn/BHP8A4KZ+BdIma5g0T9qr9mRZ52lM0k19 efDj4Y32oTTOzNiaa8ubieZY9sUckjxpGiqqj899OBaxsgBk/ZbfgD/pkg//AF1j45QrU1w3HEy5 qywlf2ku7/2e7v22t5and+ysxmU4+r44YvIcP9WyivxBltTL8PGU5ezw0ni3TheTcpJRsrvR+lkv 1X/4JLsV+In7X7AAlP2J/jE4B4Hy29q3P5f/AF65n/gkvrdrq/8AwUZ0N4dNtbfVLn/gnldahqGo Rk5vjB+zX4c0S0WUD5itvBp0Mbf9NEOK7P8A4JKaPqt348/bFe0067uFX9iT4zLvjgkdFcWVswDM oyGAwwHU+/SvAf8Aghvpmrah/wAFGbS2t4dVu/s3/BOzX8vexuZI5JPgzbGSOIlVHlR3TusXPyrt RPSv0Hwxw8qvBGUTjJ3o4ivLS1pWb0Z/GP08MVRwn0ouPqNelTbr5ZkcYSqb0pqjh5qUb2afm7aL qfmV8EmP/CA6cG4bMvH0lf8Ax7D/ABrofGml6pqOi+JL3T7hrV/C3hi68UyqoLNcw2GraPYywgA5 U+VqZmJ+bYsJyvrl/BfTb4eBNLdraUK6zFWZGVWAmcZUkcjI25/vcdev2d+zL8KdR+LHxV1zwKum TXcWt/Bz4qsY/KaRHbSvDra2oJAwcNpqyIp6lcAGv56pQp4nxAxFBqFRVc2rwUG01Jyna1lv6eu2 p/s1i8Rjcn+iLlWaU5YrCywHh7lddYmnGVKVL2eBw8vae0taHLbV8yt18/mLQrn7boelXbPmS5sY Ji3XO+JSf1x7f0/VjWPiklr/AMEIPjt8MWuIy/iL9qX4Z+H4Id2HBvPiZ4d8fTbU5JZoPDUkm3nd GrN/D835JfDYXV/4F8N3X2aYxnSrVRIY2Cv5aCN2VgOR5isoOMbht+nvvjbU9eH7Fd54Hji1CK01 z9tP4a+IFiaNxb3OmaP8G/iMLxVJXa4XVW025bZj54g2AK9Lg3FwyfifPKcpxpqngc2o+842UYvm Ude6Wi1f3o+G+kpkGI8R/ArwqxUMPWxVXFcT+HuZr2dKVScp1nh1Vq7Su4upPnkk7J30Su/JbO2+ xWaR7sqluoB6AbYgCMfxdRjjt09MTwx4a1Dw/wCJPA2uz3Vw9j8S/AXifxVbwyZMYXQ/iT428BME A6xNJ4TffjcwlM3stdBqHm2+n3ExRx5Vo7H5SMbYieehGDz/AFr6L+PPw+n+Gh/YQ0C4tZIH1H9i e88bl3Qq8i+Pf2gPjL40guXJALqsWuROuf8AljsX7pBrxsjwqxeS8X4yajJ0MCpRk4/bqVUk79Lb rfU/SvFbPJZB4k/R14Zw8q1D+1OKlTlTjOpT/cYbAwcrpW5o6OnKMrpRk76XR5lL/wAe8o7iOXr7 nIr+/T/gmvaa7L8P/wBia4sNWsLPRIP2SPE6azpM+kS3d5qd3N4v0QaXc2urpqNumnwaeIL8XVo9 hdNetd2rRzWotZFn/gKmP7ibngQSjvwcnHQZ/wBr8fy/vd/4Jua1f23h39hHRoZFXT9V/Y48f3l6 jDJN3pPjXwdHYMvP3dmp3oYfxfLmv0T6N1nmmfarTBUdOv8AHw3fbVb9rn8Y/tp6cqnAfhM4uyjx Nj2+ZX/h5NjJ9tNU/nc/bUH5dxZNwyFYA5Dcqc4I3DC9Pl/u7v4q/jg/4Lx/E2DxB+xt431GLU7n ULv4jf8ABTmT4KXa3gt1eGH9nc+NYbfTYPs8ECvY2L+FrhbVbgSzJGu6a4mlfdX9jczKqhiAMK7Y wWG0BmccfdZQNu7PPbiv4Zf+C4M+mWfwO/Z18J2bb7P4o/8ABQj9rr9o+1j3H/SLHWbrx9JZXi/9 My+uttPC4kwOuK/pPjXELDcMZzXTtyZdiZLVfFyxja+32j/E76MGR1s98dfC/BqmpU6nGeUKtKy0 hGsqiaj603db2V+5+CEreWspGCEBdh0BKh2A49RnH/6q/Rn9tLwa3hj/AIJdf8EftdNvtuL74w/t QwXkxjYBYfE3ifU9V06KRhlsPHMTGW+XIUH7xz+bt8wWzvJWySllcu20klD5Mzqc9Qfl9e+B61/Q D/wU1+G/9j/8EWv+CY/iBoQB4X8ceCdYeQJgxD4hWVpdFsgZU3H2oFucsSfvEZr+QvCrBrF5dx7K UW75HVhHRaSnVp7f9uqSvpp6n/Rf9PriOWQcY/RNw8MR7KEPFbA4iUItRjUhhssqxUZpfYjUlByX R267/gSqF/3YLFpkaBFwBuFwfKdMk7ctvK/N8uB97Ff6Bv8AwTd+IGhzeFP2W5ZljfXPjv8AsmG4 0y5LFmbT/wBn7xamnaxGm1lU+XP8XNLDhopOGXyZI181ZP8AP1t2XzYdwwgmWQpyCF3qVwPvDnH3 efpnNf2uf8EkLGbxN4K/4Jj+KBNMyfDv9l79tTwRdgsSvm+IPiR+zbqNuJwC26WJNGkSMN8yrJle tfT/AEc8QqWfZ5hZS0qYHnir/FKniKUY6X/lk7adfU/DP2zmU1MV4Q+E2fUqUZSocVfV8TUsm4Yf E5Liqlrq75ZVYUnv9leR/RcqoxYtn5jxkENhfk5wzKdxG9dqp8pX5fl4kEaAcDOfUnp/n2pNnGcY PQj1wTg5z759KkHQDjIHT3HB/XvX9fJtqL3ve79LJf5ei02Z/wA5N9WtbLl+97/LYQLg9APxJ/mK dRRVDCmMiPkOFYdgQOBjB9+c0+igCobS3B+WCPJ5BwMg98A/qfz4FeKftLxrF+zb+0EFVFz8Efis CFA6HwHr5I6dP8K91JGRnr269+K8O/aZYN+zh+0EDjH/AApD4r/X/kQ9f56cYA/XviodudX/AJJX vta8RqcrJdFOKe76r5L+lc/z7v8AgssC3/BR7x9k9f2av2aucdh4e18g4+lflcwKgsDhQCxz2AHJ 5zxx1/wr9WP+Cx6hv+CknjpGAZT+zX+zYCDxgnw3rwUgA9c/oPy/J7VTJHa3qKTG6wTqG6EEKw6+ x69T+Br+EvFCPtPELOqaaSnWwsdV9mVClFu2/a197ep/1i/QPqrB/Q+8Msc4ymsPl+eTtGXvOdLM cTV5U3tfXe1m/LSs2vaTEG8/ULWJgTkSyRqevfLcfkB/Om22vaTfTCGy1G0uJhnKRTIzAd8qv0HQ 5r+gb9nr/gn1+ybr3g79h7wF4a/YRh/al+PP7RH7Idr+0t468R+Ofjxr/wAL/Afh+ysPEfhDwVq0 +q3+keGvE15D/aXifxlpht4LHS5vsto8gbzCm+vgb/gpt8Jf2YvB/wALf+CY3xx/Zt/Zp8Mfsv3P 7Rmj/tMXfxJ8F+GfF/ibxvE+o/DTxz4L8EafZXPiTxBLb/2xBp93b69c6fqFroehtNb6wy3Fpuij 2/XZh4NSwHD9fPHm6qeywMcdGjGglGSlGM1Bvn0dpfd6H878IftK6PFni/kvhXS4BdBZjxRV4brZ m81U6uHq4fFPCzrOgqMX8VPRNpSWz7fA82RExGSfLYA+xHB46DA/A89K/pv/AGCfjpp3wA/YN/4J ffEzU/h548+KqeHv2/v2rLNPAvwz8MSeL/GWu3Op/s1ftQ2lvbaVoUQ8y7a2a/jvLiRQq29pBNdS NHHDJIv8yUgXY465Vhj0ABAHuMflX9HH7DP7S3h39lX9i3/glx8VPFfhzxX4t0XTv+ChH7VOnJ4e 8D6EfEfijUdb8Q/s1ftEeG9Et9N0pbi2aVZtT1e2hvp/OK2VjJcXciiCCQjLwNahn+bSdb2HLlFV usqaqKCWIw3vShJNSSsm4+ffb1v2plJVvCjw+jLBSzNVPELAKWXrGTwH1vmyjNYew+uRlGWGdTmS dVSvFJtPQ/UW6/aM+Mv7QP7YXgbWPGH7KviL9nX4Y237AP8AwUDvfAWp+OL/AMPQeM/Ft9ez/s0p rFtq3hXRNT1CTQYtHig09401AxTzSajINg8lsfw2fBvJ+GXhEEjH9myDI44F3cDHTA/+t+f9x8/x Q/bE+NP7YfgL4h/tA/CTwn8Cfhdq/wCwF/wUJb4R/DWLXH174m2kktz+zU2tal8QbyG0tNHhGoWC aHcaTp+nK7abI2oQXdxdSNG8X8NvweeOL4ZeFC8iqBpkhIbgjN3cZyB8xOeBxX0fjlOdThjJnUqV K9SWOxCjUq0Fh51U1RlCfsacI+zUlqouKlb4tbn4h+yooUcN45eJ1KODyzKqVLhbKVLA5XnMs8wW FhHEYu9H+1Klas8XVhJOOIqRrVIKupqDUUkfp3/wTLmig/b4/ZYlmdUiT4mMXZjgADw5rXGOuc8K ejMQi/NX64eB/GGhTfF3wJNKmpw21l/wUmgvYbiJbg6femXTvFMLXFzZBdqS2+xY4bpow18szrGz fYW2/iT/AME+tTlm/b3/AGTLWFits3xWgeTGcyldF1jCnGRtzh8H+Ibq/Vz4D+K7zUvE3jbwtqtj OB4e/wCCpXg+fw/fTxJEk2lX+ieORLFay4aS4ht7i23Ku6Nd0snykV999GWMocIZ7zWjKnUnNp6y ftPZwjs+lru/TXY/BP2yk6WI8fuDq9CpeP8Aq1Qp828bU8Vry9WnKo1fVOytfW/4z/ti+IdLvP2+ f27pLaVzFN+0145mTdC6/u99vCxCsq7f3scg/JlzkZ8BuvEGk2UTT3VytvCoJeRzhVwCN245PBKt wOcbcEmu5/asBP7dn7ceCM/8NH+PDnkcm/I75x3/APZeOa818NeF9H8Z+Ofh14W16JptC8R/EbwF oOsxIxVpdK1jxdo+m6hEpUq48y0upYwUZT833siv5l44y2hjfEHNaNWc4LEZnCnJwt7vtVTTcYvT 7V92mk+2v+w/0WuNM04X+h/wFmuEw+GxFTJ+CMRjadCv7RQqPBvEVFCcoyUoxkqdptLS/XYoSalD qeLy3nFxayKRbyIwZCikhSrg9GYFhn5hgqU61maheTWMcH2fTr/VLy6uYbGx0vS7Sa/1O+vbl1jt rOysbVJbm7ubqV1jt4LWOSSRnVEUs6Ay658N9e+BXxd+MHwC8TFRrfwm8capoM8AZ3EdhdeVqmjt ul+bLaVf2shOW2uW2sw5fp/C+pXmi+KNA1zTXii1bSNVsr7TLmYbltL+C4ie3vEP3lmtZFEscnzF WCtsP3a8jF5TTyjPnlOMU5UaGKp0p29yc6MpQ5ZJPSMpU5J3s9b+Z+lcOeION8SPCinx7ww8PSzb NsixWMwlOd8ThcPmtGlUVSi2pKVWlRxdGVNR5ouytZXjb6s/ZR/YQ1H4oDV/2k/27tE8ffAD9iz4 R61p1ve+E/E3hfXvD/xY/aP8e3lzFH4Z+Efw08F39hbeI9auPEurSWum/wCgWErX7T+TADG808H7 1eH/AIQfE66/a0/Yt/aK+MfhPSfhDb3Wi/Er4a/s3fs0eHN0Wl/s6/BWHwPLe/2RrtzYI2m6l8S/ HRTRtU8ZMJprXRYdJ0XT476a+/tK1sfctH8XeD/i/wDt3/Dz4r/FjUNa+InhPxP+yf8ADn49fsie DvEV7a3fw2+Dz6Xd+Ffhj8XPFWg+HIrW1TUfHeu+IPGcV1DqWsXuoSaTayXd1pOn29xFDdW/1d+1 XJbTftCfsUzRXMc80/i34skrHMsytA/w5kkSWQ7UJO7G75Vb5trbtu6v7n4VyPKOHsrw+FyujGnR nRVR1bR9pWdSmpKbnu1JWvJ6bWTSSX/KV45+LHiJ4ueJOZ5x4g4+tWzLA5tLAvAuU1hMveDxLovD YegpOnRjT95KEdU23K8nKUv4E7Uk+Mvi2eAT8W/iWcDBx/xW+uZGR1+ndeegr6t/Yy3D9sf9lraW DD41+BGyoyQF121Zs/7O0Hdj5tu7aN2BXyfaE/8ACZ/FjgDPxZ+JZwBxn/hN9dHHsOn4V9XfsaH/ AIzI/ZZJOc/G3wFjt/zHrX0I4/xr+Pa7b8SaltJPP4W/8KY/j2/Lof8ASbk1l9CmhfW/hF07rJW9 df73n1ufH/8AwU70b4cP/wAFUP2gNdi8Y69P8TIv25dBs7rwNc6KF0OLRJLz4cufEmn+IbWa4WRp bgnT5LXUVsZ/3cTRxyFd7/o9/wAFjMf8Pcv2n1xgf8I38EcLnO1f+FP+COP+AnPf0xX5Gf8ABTeR v+H1/wC0Su4hW/a+8KZVSQG/4m3g48qOo+UN7MFOM1+uH/BYok/8FdP2nvbw38Eh+A+D/gn+v61/ Xnj7KE+BMLyR5UsvwkZ3lduaxNfVS0dtNuj0XVH+E37N1P8A4mp4cbejjmsfOzp3XT+vQ/PPxSFX w1rYYgH+zrsjk/8APCT1I74H8hX6ff8ABYPTrDVv2t/grp16ZFkm/wCCfP7IV3pVxaO1vqmlazp9 78TLzTdc0S8j23FprWl3Mcdxp01m3neYrMzLtDV+YHipfM8Oa3uG0/2deAHuP3DgHnGTz9fyr9MP +Cvy63f/ALcH7O2keF/CHivxr4kuf+Cen7LF3pmheD9B1XxDqkhsZ/iIZryeHTrWSGxtLYzRbpry 4hWZplWLHlsG/Ivo5KHPns6nvKMsNdO1m+WbVtbdLbf8D+zv2xCfN4S8qag6edxjdOUpe/hFFOFu a2sbcsbrqdBd+PPg/wD8FI/hV4c+E/7bXxS8Kfs4/t0fBfRo9M+Af7dnjeGbTvh38e/h/YyzTW/g X476/HAF0nxvosMkh1G9110h1S6uJ9f0i81XX9Z1jTE5zwR/wTDsL7VmtJf+Cxf/AATQjdbHzUa3 +JtvqEMhUqX3GfT1gCCPdsbfvMiqpUMxU+BeH/hx8bdd0+OLWP2Zvjfq1vdCVrrTb74X/bbN55WZ 2YW1/MsbN9oZ/wB8fLbj5dqha9O8N/DrXfhst34l+Iv7LXjr4b+DreOxs77xl4u+Eeh2XhLRWvNR tbe2S+utOh1i+02K6uZIoWvrizksbcPuvZrW38y4j/ac64R4dzvG+2x+V4PHTacb1acWoRbjaKmt W73fa9z/ACu8PvpF+NfhdlMsr4H47z7hzAznHEvDYDF1aWGjUgow9o4OSUZpJR9+Gyir2SS+s/h/ /wAEddU+KXi3Sfh/8OP+Csn7A/jzxz4heaHQfCfg/XLfxDrmszw289zJbafp1lps15d3K21vPMtv BDJMsMMs2wRxsy/jDPpWu+GPGvxS+HXibUbHV9c+F3xO8dfDTVNW02OSLTtVv/A/irVfDF7qFlFL HDNFY39zpclzbpNDHIsMiB0Rt6j96/2GtH8JWv8AwUD/AGFrvQ/D3hqzmm/aBWRNV0nRNMsrieGf 4WfEh9iXVlBC0kEiCKTK/u9vlt83mfL+HvxJA/4aX/bCJ5/4yx/aHH5fF3xd04PrX4n4wcHcP8P8 NYfFZZlGFwGLeMp051qCS56VkkuZ3drdFrdbW0P9RP2b30lvGfxh8ac1yDxD47zriXKaXDOKxVLB 5liHVpQxEakYqry8qSmrte6tle+6f1J+wN418WeFf2x/2cNM8N+IdX0fT/EHxi8G2+tWWn3UkFtq MMl6tq63cSSIsivbyywtuVsW8ki7Pmr9CP2aBaW3/Bab46WFvFawrF8Qv2zVgigQKsQPwz+D8jBV CptDO7NtOPvM1fmf+xOB/wANofsr8Dj41eCse3/E2gr9GP2Z52f/AILkftBRRzblh8d/tj/uHUAJ I/wy+DxaRGx8xwF/i/oK9jwIlVqcNZqnUnKFPFRcYSel/ZX93X3dN1sfnn7WTCYbC+N/AE6FCjRq YnIZTrypUoU5VZxx9FKc5xSlUklJpOVtPuPwg8KAi/8AG+ev/Cd+NM/X/hKtWH9K9V8CeC/FfxL+ JXwz+GPgm+0zTPEvxK8e+EvAOk6rrUcsuk6Xe+L9dsfD8Op6jFbw3FxJZaa+oi+uVt7eacxQMIY3 k2K3lXhTP2/xvnr/AMJ540z6Z/4SrVuntX1x+yASP2vP2Vsdf+Ghvg+OuOD4/wDD4b/x0n/69fz9 mFGjiOPq9CvBVKNbPPZVYOPMpQniFGat1bTZ/r1wjmOY5P8ARGyrNsqxdXAZllnhVDH4LGUXath8 VhsljWoVYPpONSEWr6aH6A+K/wDgjD8SvBHjTUPhv4t/4Kt/8EwfCfxD0nVbXQtT8A+L/ilY+G/G mnaxqK2T6fpGp+GtU0+21i01u8GoWIstNls47qeO9t/s8couI935l/tPfs/fFT9j39qf4nfstfGL xR4M8ZeNfhxa+DrvUPEfgKDVIPDV/H4v8KaN4psFsYNa0vSL9JLay1iG3u1mslVbqKUxySIVc/oh /wAFENJ8Ly/tq/8ABQW+ufDPh7UdcH7dPw4EerXuh6bc6paKlr+y+YjbalLatdRtGGcx7Zv3fmSb du5q5j/guLZGf/gsF+1zcL1s9E+BkhUfxCb4PeBI2PT+EKW+p61+7+KHA/CuR8KYrHZdlOHwuKp1 MPShXhFxlyzalNPVq7b1aV3+J/kz9A76VXj74p/SCyHhPjfxEzniLIsRgs0r1sux04ypTnQhTcJW ioyTgpS5Vqtt9LflF4swvhzWlHH/ABLbr/0U3f3PT1/Gv0y/4LFeLtU8F/tnfC3X9Myz2v8AwTx/ Y1Esf2GG9SWNf+Fyu7yiVkCxW+zzNynO4t71+Zviznw5rTd/7Nuh7Y8lq/Xb/gqPoFlr37bXw7hv rGXUbZf+Cd37GEVxasyR2s0Nw3xnjkgeRuEkmh85flVvlPUNXk/R+hCrS4gpyuozlhYf9vOUuVvX pZfM/Qv2ws1SxnhLN6pUc+iox0911MCmtOkk7aL87v5Z/Z8+Ic/xU/4Ip/8ABUTxxPdtenV/2zPg FCtyY/KWRdM8GfD3SS0MX3Y4m+w7olUBdpVgOa+T9BkEUGns33fssCnI4AMKqPoFz/8Arr7l+HXg fwj8Ov8Agjv/AMFTvCvgaxOl+G7L9sj9ni4stL84zrpz6l4B+GupXNpHKfmeOO6u5yuWbb9z7u1V +D9O/wCPCy/69YP/AEUtcf0haShi8jpPWKw+Jjp2f1e34M+q/Y61ZU8h8Uq0VFShmmRVFFaxTjHF NR16WavffRn7nf8ABHaXZ4o/bLkByF/Yq+NLZA3dNKtTkAfTj0/Wvgz/AINrPF3ifx3/AMFCPGPi fX9G1fSbVf2JvHvhzSLi+s7qKy1Cy8NfDeLSY5dOuZ4kj1CN0tBdJ5LP+7k3HFfW/wDwRx8WwaZ4 8/bE07VopJrCT9ij4ySedCMyRA2dukiOu5fMiZMkfMpjCt97cu36C/4JQ/Fv4Wax8d/2bfDPhD/h FtJg8N/sFfE9r2PRtOexubi8b4L2TXE17L5bNNOVDSsWm++W2DfX6H4Pr2fAWWwk/glit/8Ar49d bWtG2vntofxh+0dxntPpZcXVIQmliqXDui5XFr6thYzTak3o27K2ttrOx/PJ8IP+Sc6B/wBcLr/0 rkr9dP8AgkppX/CQ/tw+ANAZBIuueCPinoYjCksf7V8G31pIMYOSS6D/AGs9+lfjf8I9ahf4d6NF bKzNHFcRvIygLl7hzlcbs8Ecnbx2xX6q/wDBH+4l/wCHkf7PSGSbZJca+kirLIoYPYAOrBXHyMuV YY5yPSv5qyTDzl4o0ZzfKlxBJOPWSWIs9dl6633P9vvE/OaEPoI4+jRtKf8AxCGlJzi1aNspg0un O2rbSSUeq3Pzz8OaAPB7eJfA5VopPAfj74h+CZImQl7dvDHjLXdFWJwR9+NLJF2k8Y56Zr1++8eX eo/DTTPhpeaXp1xpmjeJp/FFhqTKEvLbU5ba8sRIsfl7mYWuoXKbyW4OMcZPm3xs0G98Gftdftne FLt2VtO/ae+MV/BEpdEhs/EXjfWvEWnoqM7sVjstUt1DcmQDfwrcckZXBJ3njqcnr2PUZ4Pt2GK8 fjHC1su4sz6FGq6SqYirTaUf+XVXlqW36xa9X36fo/0bs+yrjb6P3hHjs2y2GYTwuR5ZiacqtSLc MZgIyw8avw2Tg4y5XqrXvpc6rU7eS8spLCJSJNRa00xQxyfO1W7t9OjlQff37rkbceq9a/T/AP4L HeEf+FfftH/sL+B2QwS+Fv8Agmv8HdAuEaNlZbnTfEHi7TbguuNwZ5oXeTq2XOea/K/wjoWpeMvi J8LvCenGWS98RfErwLp0SIzszq3iSwuJwFB3Ntt4JWCrj7oPy4LD9qv+Dg3TJdI/4KG/AbT33iG3 /Y00qKyhPWGxi+LXxNigjBYsxTylBTczMI2ULnauftOEcAsP4a8c4ptN4j6rSg7axVN8zfN1u5dN dLvc/mX6RPF8c2+mz9GDh+H7mngFmuOdKU3JOWMdCimkorWEKSa91aSkot2tL8bJv9VP6+VN+eef 16V/c1+wf400jwhY/wDBPU6rHrcxv/2MPislqmj+GvEWv7fsvjX4eSXEsz6FpmoRW3mCaJVF08LO 0bBdxL1/DNPu+zzenlS46dMH+uK/vK/4Jzl2s/8Agn4m47V/Yt+KAAxgf8jx8P2O4c8nA7kgj2r6 D6OSl/ameNNXeCob30/2jDro1+afbU/IP2zPJS4K8JpVqar0Vn+bQlBTdKTl/YWPcZJqE0rb6xbv pY/Wm5+MPhRtPvp/s/jBNtjcOVl+H/jpCAYXKja/h5JHG4E/u1YKeHZe/wDA7/wVd8Ta7q3w6/4I 4aNrhI1Wb9ijWPiP4pty+6QeI/E83huOe6mIO0ySz3eoAyP+8cOdzLzn+9T9pb4g2nwm+Afxe+J9 5OLez8AfD7xV4sup2cxiK30XS7m8lkMmOBGkZdf4cj5iR1/gs/4LVBNB/bU+CvwaUoqfAr9iz4W+ GIrZSP8AQn1mPRtQliEX/LIt9ncBc/N8x71+6+KWIeE4Ez1zfvSwzjzLmirVJw5Ixu3LmvB312uf 5S/QEyennn0o/CmhhISpqjnssfWozn7f93hKXL7Rp0oLlj9Yttdys1bW35S6sC1hfxxlhJNbzW8Z BIIeeIwoSR23TjPT9BX9ZP8AwWG8P2ukf8G/n7O3lKj6l8P4/wBiprrYp8y0urnTfCkN7KxC5Tzl vBcSNjAR/n+YNn+Vzw/d6RY6/o19runNqujWeo2t3qemxzCCS+toZEla3WYpJsLMkZ+4Syrt+Xdv X9jf2wv+Cpui/tY/scal+yRqXg+bw74be28G2+kzQ6AjyWn/AAghs30JlvhroSQQtYQwOxsVxHGE TAOa/mLwp4nyLh/KOK6WbYmNKvmmEVHDQceaUpQhO13tFOUo2u23Jfy7f7mfT68CfFnxg8Qfo/Zh 4fZPLMMs4M4jeZZ3i/rFOhDCUatfAL2jpt81Rwo0a93GGkZWTs2n+LGPlRuwij6DuQgPT3/z0r+v n/gj98YoPCH7L/7Jl40x+26t+2h4m/ZigBHmYs/HXw1vfHl5bcf6uNpfAFpJuxtMiqfvV/IRxs2j J5XAxj5VxyfQ4Xkc/T1/qJ/4IsaSvjX4JfDHSpCjx/Dj/gon4T+KA8wAi3F58G/iJ4ejn4+WNt05 jV2+8zbT8zV6HgFiKceN8VS5rfWcDiKcezdKUa7mnqrONOW3VnzH7W7IcTW+ixkWN5byyLibIq2M crzjCNfDyy2ST7+1xMGnfy9P7BdyKoO5R0xuO0nAxnrwM/8A6zjFOWRGOd6HKDhWyeT6df8APanB AQSQDk5BIBONoHHpwKQIpAJVcAHsM5BPoPT3r+1raprblt289v6+R/y+q3ItGpKUb367fl/W2kuQ ehBopoRR0AFOqigpCcZJwAO5PX/P60tJjPUD+f8AMCgDKu9SigkijS3u7h3JUNbW8ksUbAgATSIr LEM4OW+6p3etfN37UV541u/2Z/j+dMsNC0S5j+E/xISZteln1eC60ZfB2s/2k1sNIurB7fUJ7ISx 6ebhpYYbySFriC4iV4ZPqIpuzk4JBCjGQvuVHyk9OT7Y5rw/9peML+zf+0DwMD4JfFc7SzBWz4C1 8AMccL0J2n5cZ6ZrNq8l0vB3t35o37fr+ppGcIxa5eaXMlrd2210snst0/kf5/X/AAWNDH/gpR43 cDCf8M2fs1ZHVst4d8QbM4+6uA27d3Ar8rvEdtsivSAdkkEkikjodjA8nPG7dxjPA49f1P8A+Cxq gf8ABSfxzzhf+Gb/ANmsqqkqBnw5ruN2fvbcN971r8zdbs3vdMuooADceTJ5IOPncqRsyTwW4Wv4 L8Uajp+JWY2dlKvhI9rNUqOuvZq33n/Wn9AvA/WvoS8Eysm6eV59Vh/M3HF4zmWluWPLfV21Selj +w3/AIJmgx/GP/gm4uwk/wDDmDUtpU/ulc/tIfs+LtWQd2BLK2//AFaM3uP56/8Agpsc/shf8EWC PunTv27MfLt6ftAaKOnbnP8Avfe71+137HVt8d7r4i/8EzdH+BcvgjQPEmof8EctS07XfF/juPUZ 08HaK37Q3wDjk1jw/wCH7GwvrXxF4k0+8Fvc2fh/Xn07Qb4RSQ32oW6tz+H/APwUhttQsP2Lv+CI 1lq2qSa5qlvoP7ccGoaxLbxWkmqXsXx38PpdX7WkLNDafarjzJltYmaG1Vlt4WaONWr+ruIqjn4f Y2mqLhGOQUJe125pPD0k1rf1/Lqf4BeC2EdL6XnDeLeKwkniPFzGxlhoTk8VSUM3xMeerHl5IU5N NR9/md7uKTjf89pR8jnHZuc8H73brX9Ff7EPxd+G3wH/AGM/+CXPxb+LPiPTfCfgfwR+3r+2Lq2s a5qToogQfsp/tK29tZ2ERIkutX1S7mg0rSNPtWW81TUr210+33TXCo386cpwsp77Xx+R6/5Ff0lf 8E9fh34I+J37L/8AwSJ8O/ELw3pXizw8v/BR79qfWxoeuWsV9pj6v4a/Zo/aK1/QNQuLS4RoZp9H 1vTdP1jT2kXda6lY2t1D++hjr8D8C4znxDmkaTgqjyms4OaThzRr4eSlNbNRtdpWbW3W/wDrl+1Y rYKj4OcCVMfHEVMHHj/LvrMMJP2eJqUnlmZKcKNRQko1Jp8qbjJRvdroe/8AhT9of9pP9pr9tHQP i/458Aal8IP2fNV/4J/f8FG7b9nTwxrLS2HjrXdLstP+AE+veNfFti/k3VvHrQm8PyaIFht7OCO2 mWOP7VHcSyfxvfBWaWX4faASzHbZIAGYnjexwMnjr0A7dK/uB+L37Unw7+Mf/BSSP4H/AA5hl1dP 2fP+Cen/AAUOtvGni+zjjHhg+KPF+m/Agp4Q0e7hbyrrVPDll4eFxrrRD7JHHrGlRWk085u47b+H 34LBf+EA0Fc5zYoSR/10fjn/AD1r63xolCXDOUTWL+vyeZV3UxPLGKlOL5Jxgo+6oxknGEU3ywST el3/ADt+zKnUXjf4gNZBHhahU4MymWGySM6jnRwc6tOeCrVqlVurWxGIw8oYivUlGKqVak5qnBS5 V+j3/BOz/k/n9kz/ALKpb/8Apm1av1M+H/xC8Bad8T/DPgi11Vp/HXiL/gp9paX+m3shEdpZaBo3 jCUpp4LLg3h1iKTZ8y/6M21d241+WX/BOsgft9fsmDv/AMLTt+v/AGBtW9+vf9a+h/CVusn/AAUF +FlwHRGtf+ClV6pVgGEqy6FrQJYHo8Oz9233fnk+Zflr9L+i7gYYvhbiuTdvZ0as+W72jTUk7+Uu VWPw39sPWdLxr4C5VdzySnHe1v8AaYX/ABPhP9qzB/br/biwSwH7R3jsAnrxqBGM/wCyPl/DoK4/ 4as0fxT+Eaofmf4s/DJF7EsfHWgbcZ9yO4P9Ov8A2qyD+3X+3JhQo/4aR8ecZP8A0EWGeTgFsbm9 yapfBPS11D4zfBkzgfZY/jD8KmmVlysi/wDCwfDimLPbfnBbPyru4Y4Wv5c4qcV4k4vnaUf7bwyl fb4qS+8/15+j7TqV/oUcOKl8b8Nc5cX/ACxWHxqlzeSS1ettEt0fd3/Bdb4Lj4Kf8FCPCfxK03S1 0zwz+098F/DOu3F3sEbar8SfBZXS/GcsgRFV5F0jVvBy7nZpHU/M4VFz+YGTGHIO0qdykHkYI5Xp gk/lX9Ov/BxBo2g/HP8AZ/uvij4a0hpvH/7BH7QHhTwr4ogtGWWTSvhX8W/AGlTX3iLUFQ7rW01X xFoGhWlqJtqzNpc3l5dNtfy+2VzFf2dtdIwaO4hWVCD95ZACD696+j8acneA4iw2YU6fJSx+Hpvm jHSVSilG+vXl5dd3rI/GP2ZPiRHi7wezzhDE4mNTG8I57jaVHD1KnNOnl2Y1alaDacm+R1XVaWiV 1GOi0/pJ/Za+IWla/wDs6fsDfGHWGhC/s/8A7ROvfs3fFGUyyqtt8H/jR4c8T+EvhDo08nmYtY2+ MupfDDUDdSFY1W0Pl7Tsav0e+OzCD9sL9iPTtDt7yfw9pk/xstL3VU1L7fpsmqQeDYVig2zNNdJc MGuPmuLiR/Ki3LtV1r8Bf+CfZl+K/wAAP26f2Y41ln1jxF8Drr44fDm1Eis1/wDGD9nvUNN8f/C7 S7G33eYL19f8NafcrcRKdq25PmeZtVv0T/Zn1vxDqfif/gnLq+veOLHxm3jfSPix4zDwW0tgbO9b wTJo+rIYpY4/Oistf0/WLFpP9Y09vcMylfmr988PMznmnCOSYp1fbSp0Hg62qclUw6VGKktXdxSb eu99D/HX6ZvANPw7+kp4hZNGk8Phs3z2PEeX0oxcacqGc8mNl7KXLGLhTrVKlJKN4x5VFvmTS/lw tiP+E2+LOMAf8La+JuAMYUf8Jzr3y5xyMfoeK+q/2MyB+2R+ywW6D42+Ax+evWuOvHXH5+tfKVox PjT4s525X4s/EzOwZQn/AITjXj8hGFYZzgqzLtx1+7X1Z+xoc/tjfstHoF+NvgJiWKqABr1oWJLb VHGenpxwK/l+vp4kzvp/wvQ/9SYH+/OTWl9CnDxWt/CKXztkt1p6pX77H51f8FOFI/4LZftD5x/y d/4V5wcf8hXwf09//r1+uX/BYvj/AIK6ftPDv/wjvwTB/D4P+Cen4fyr4e/4KFfss/tJ+Nv+CvH7 R/ijwf8As4/HzxfoVx+1v4V1jT/EHhf4L/EvxBodxpNpqnhGS81OPXtI8MXmjtpsUHnSSXX27yVW JpWbbtevuP8A4LFhj/wV1/aiO0/L4f8AgmjEjARh8HvA5KksOq5CnnHPys2ef638eJ0JcC0lSrQq OOCwkakYyTlTqfWK0nTaT3UZRfXSS6n+FP7N6NR/Sm4dXJNWjmrvyStyqknzbe6tGtflrY/O7xez L4c1jaTn+z7zgd/3D4Hf/P5V/W78afib4w+A3w//AOChX7QPwt1CDw78W/hV/wAEp/8Agmde+BfG C2Fjealobaz47+O2n6zBayXlvPts9Tt/JjvrQ/uLpre3laPz7W2lj/kl8VIo8Pa2WBIGm3YwCCT+ 4cYA9c9eu76YYf1Nftmvt/Za/wCCppc5x/wSb/4JdEYyw3H4j/HcqFZVw2c/MQzjgFtvf8W8Cajp 4Dij2bcaioRlCcbq0o0qr9eqs76H91/tW4KfF/gPGsozp1M4rQq0px9pF0pY/LlPmhJcsozhdPmu mt1JM/ODRv8Agt1+2/qGg6NeXHiLRWnuNNs5LhnGuASSm2iMrbYNVh2hpA0nyt/Fn5lAr7j/AGKP 2+f2h/2ufDP/AAUS+HPxj1vTNY8GaZ/wTO/ae8TW+iQQXksL69Z6FDp9tqNwdSvL5pZI7PUbmONU 2qjlZk/eBWX+aDwgQfC2gkj/AJhdmzdDhfJQAntjpj9Otftp/wAEUPBWvfEX4rftv/Djwylude+J 3/BPP4+/DTw019cR2OnP4r8bSaFovh6xvNQlMdvard6hcxDdNIu2JZZj8kLsvg8BcWZ9jOP8FgMb muLqYKpjsTGpQqVP3U4wU+WLT0VpKPn56n6v9LfwB8I+G/og8VcVcM8AcP5fxGuFuH8TRzHA5fCn jYV8TiMtliK0JxjdTqRlUjJRSvzSWzsb3/BOK7+0ftr/APBOuEQtEkXxP8NxRqpDR7Yvgr47XeUO Wjb5gGZWXdtXcG2rt/Gn4k/8nLfthf8AZ2P7RH/q3fF1f00fsG/8Ewv24fhJ+1n+yf8AEz4weAfA HgP4d/BDxcniTxbrSfFTwJrl9LZ6d8PfEHhdVh0zQ/EWo3k0tzf6tDJCqwlI4Y5GuDDJtVv5l/iW GX9pT9rqTA8q5/ap/aCuLeVSHjmt5vi14teKaJwWEiSKyyI67ldCpDsGFfpvjvKmuFMPGE075hTc YOcXJqMY7JO7trt5H8KfsnMDjqP0gM6rV8LXpUI8I4iMak8PVjTjzVI2UqkoRipScZNa6307nvv7 FBJ/bR/ZXJ/6LV4K/wDTtBX6CfswyBv+C7X7RiM8wKeNv2w1RCsQhO/4Z/CHLKQnmE4A2lmb+dfn 1+xOQf20/wBlVM/MfjT4M2jjkrqsLlQSQpOFPG7H970r7x/ZcnLf8F8P2krcvKfL8YftgyqjI3lj /i2nwhAjQj7rE5+9t/irh8CeePDeZ2TtPGwf+L9xZa+t/mkfWftaakJ+N3h5GEoSccgkpJSV4t46 i0pLpo7q9t77H4keFOL7xsuPu+O/Goz3P/FVat3r62/ZB/5O8/ZW/wCzh/g9/wCrA8PV8keFW/0/ xsXyGbx341yGGMEeKtW45P8ATr619cfsgZP7Xv7KwGM/8NDfB4gHHI/4WB4fyAD3wD9PWvwjFpvx Dml1z+mv/LqB/rLkcor6G1G71/4g/Vj5q2QO3Mr+7t5+p9n/APBRS/eL9ub9vuyiaUeb+3N8N5Zw 0Q8oRvafsxg7JAqsGyinlm6/7tO/4LVDd/wWE/bGU8g+HvgSCOxB+D3gXIPt3rh/+Ck99DF/wUM/ bstHaUOf26Phl5IR5gGkez/ZnAEo2+X5eFP8Xf5ec13P/Balh/w+F/bFHf8A4R/4FAdunwg8C5+o 5/zzX9N+NmnAmNb29thmunWCdvndeZ/hX+y+5X9LHhPms4yy/Nk7veNqS29Xy/1Y/JLxzbG30DWw B8jaddshznIMT8d+R3//AFZ/V3/gqxfGx/bP+HxV71Hf/gnj+xOYxatw8iy/GrrGwaN2x8oaRW+9 tFfml4o0+PUvD2s2svG/StQZGDLuiaO2mZZMF13bWHzRq25l3K2OK/UH/gtb4B8f/Dr9pT4XfFfW PAfxFT4Q337Bv7JHhhfjDp3gLxlqXw1sNa0K5+J0eo6P4g8eabo1x4R8L30R1vSSLfxBrGnSyNqV qsKyeYu784+jvUdXC59Oz5oVcHd+aU3fzuk9PXTY/sz9tHhaeCzLwkp05fu69DPqlONpXivaYC8e q091Kz2kr67eI+CZhP8A8Eg/+Cqb7J42P7Yn7NrSJchPNEknw0+FryZ8uONcMxLfd4ztz8tfAunf 8eFl/wBesH/opa+3vhTcC4/4I3/8FTp9sgLfti/s6H94/mOcfDr4Y4DHIAbr8v3l+ZT9018Qacf+ JfYnB5tbf/0UvP096z+kE5SxeRSkrN0MRf8A8t/8n9x6/wCx6cY8OeKsXpL+0MkdvLkxXTyt+nY/ VP8A4JPjPjz9scElf+MHvjV8/PH+gQHPB3f5718Sf8G53xU1r4g/tx3ug6g5bT/BX7Gnxj0PT18s edK9h8OrjT55C67VA8uIRw7gSFRGbfzX25/wSeAPj39sZeQD+xB8agx2hwFNjbgkgjk8nr/vdq8P /wCCC3gTwx4P/av8H3GgaJa2MniT9ir4w6rrGppawLc6ne33wmFzctcXaHMoa5kluNkxUJJK2wYr 9H8JJxXAuD0vLmryjry2TlZvz2a2tr8z+LP2iU3H6WGee9GMXDIW48qfPejhlGN+jjq9lfVbNn5q fBf/AJEDTP8Atp/6Nav1x/4JB/L/AMFIf2emzjFzrhHHf+z9x/l+FfkZ8FmU+ANNAYHBl7/9NX/w /Sv1x/4JCypF/wAFHP2fpZWCxRv4id342xxx6aZHdj2VVVmbPXHqa/nXKL/8ROpaa/6wNWfniV+h /s34hSivoLZjK3M/+IP03FLa/wDY1PX5Wenk0eRf8FTPDsPgn/gq/wDtqeHrWE29jqniL4aeK7NC oUTN4h+EPgDUdRuE2qqkPq9xf/MobLKwZi29q+QyoyQTwMZ+hxn+fpX6nf8ABfHwpa+GP+Cn+l+I 7cx+V8Xf2fPA/jWOeL7t9Dp2r+IfCFvc5+XeGtvDUKq3/PIKa/Lm1tZbqTCrhF+9KwJUEjp0yTjP C5Y449jxcwqwXGmZ3tGNV06qvpo4RivL7GnVm/7PLOpcQ/Rn4HpUr16mA+tZb7r52p0qzqyj/dSV dfFZJb+f2p/wTF8Av8Tf+Cjf7IHhKW0N3pcfxPTxHrwCqVi0nQtC1m6eR94YFTefY4ipDcyAjG3c v6Of8HJSQJ/wUx+C/lACNP2NtJijCnKqi/FX4lom0Afd4DBs7WBOG9PHf+CIuhw2/wC254i8dPCo s/g/+y58dviBJfttC2esWEfhOLSWd227ZWhk1FoWZl+RZMOPu0z/AILf+MZ/iD+1h+xB4/u2dp/H f/BNL4LeL7iSQjzJLjxNrfi3XJWbaWzI0l8Sx5UseGYivuclwkaXghneMlDllisTUcZSvzShD2a1 XZNNr1fVI/kvxMz7+0P2pHhlk3tp1Vw5lOAws6S/hQr4j2lepya6zcHTUn0UE95O35Qzf8e8n/XK Sv7xP+Cc7gWv7AAB+Zf2LfieNpYDeG8ceAQAgx1jAPmFjzvULjpX8HU5H2abocQy59On4f561/dL +wD4ci16L/gnZO2reI9Lk039jL4syJFo+uXul2d19o8Z/DtMalZ2zLDqQj8sNFHdErA7Fl+8wrj+ jpeOZ57JK9sJho7aJ/WsP7vN16/lc+n/AGzyjLgfwojOVkuIs1fMldL/AIQseu2qdto69Vsfo1/w UX0NfF/7DH7VXg5JCLnxn8EfHvhGxCHEkuoeItFu9LtIouuZWmnXaoPzH8a/he/4LO6/B4s/4Kz/ ALT2p27q0fhvwf8ABfwK21mkCXGieDYYryMMGKp/pdvIZI8DLnd8u1q/tQ/b5Xxt4f8AB/wHsLLx ndv4c8c/tg/sr/DHxLoreH9OvpdR8M+Ofirpmha9bz6pPKLmKKezuSskqozQRrwrK5C/wTft2eJJ PF//AAUV/b+1uRvMjs/2nviB4RtZ95YGy8H63qeiwhAOsSeUBGBltm37u4qP1fxxxc6HBOLhJWji K9CjHa8tW5dW/dstNLX11ifwB+yt4fw2ZfSk4exUKiqVMpyjNswnNRny042wtOFOXNGKTneUklzL 3dGtbfNwzuGOSOvpgcdee3tmgkjI9lHJyQF5UdTx/wChZy3WoW/tWe60zTNA8P674r1/XdRt9J0L w54asJtS13WtRuxKYLPTrCFTLc3LiJysKBmbb9w7WrX8UeC/jd4BS9n+Jn7NH7Snw1s9OLrfat41 +CXxE0fRLaOJQ01w+tzeHBpBt4VJaSdbtolUM27tX8YZfwxn2bYSeOy7Lq+LwlKXJUq0ouShOMU2 nZ3tqvmj/pf4t8dPCjgTiHBcL8YcbZHkGd46hGvhMvzKuqFStSqVeSnKEpqMHzTVuXnvdapIzfc/ Xnvz+vvX75/8EofijqfgL9kf9vTVtIWR9c+HF3+zH4z8OsDIPK1DxD8TNS8L3s0Ai2SK8enXM8Mz xsrbZ03NtYhvwEsru21Gztr+zmWe1u4EngmTdtdHUMMAhfmwe/TDdzX7mf8ABG+3h8V6P+2T8N7k 77bxb8LvhlrEkZR2Bg+H3xFt9bvJ0ijRpJfJhvBJM0cbIoVfm5NfoHgvWlhPELLY1oShJwxtCopX i4t4arHlktfhlt92h/I37TTA4bij6HHHGIwNSniqMa/DeZ4OvScZwqUqWd5bWc6Uk7ShOjGVnHdO +quf3nIxGQecknj05P54x+OacucgdtoI/TP+f5CsrSNX0/W9M0zW9MuUuNM1jTrTU9OuACq3NhqN tHeWlwquFYLNBMkiqw+6y961g6HgMDxngg8evFf3s376S25L9evLb79fy6H/ACR6b2s9nfe60/Tz HUUZB6EGiqAKKKKAGllXgkA4zz+Q+teH/tMMD+zd+0Bjkj4I/FfjB6jwFr4/nXs1y5R1KRtM4UlU XGN2SE3MwKxqxLL5ny7f4iy/LXz1+07pb6n+zR+0LFqt1KIG+DXxNuYYtNurvTzELDwbrV5bM9za Tw3c586CP7XC032G+h8yzubeaxuJoJJfxx/wy/OBSStdvecfvutPnp93mfwLf8Fjef8AgpL43Pr+ zd+zQfpnw54gx9eh/nX5w8jnn1H/ANav0e/4LGMzf8FJvHJbGD+zd+zQEJKxlx/wjniDDiMjD87h hVBXJXhcqfzh/wA/Sv4E8V7LxKzBdFisH+NOj+LP+uT9n1Fy+hRwU+ZRcsm4hpp+9LX63jLaPS9+ tut/M/tY/wCCfXhgaj8af+CderWPF3a/8Ea75JLc4jS6iHx9/ZyupXY4VUmX987M2dxfa2371fzF f8FPY5of2SP+CLcUyPHKlj+3aHSRSsisP2gtFBDDPVQP++fwr+kX9j7x3438H/Eb/gm7pnwz8C3f jX4g+Mf+CP8Aq3h7w2bmG9HhDw1K3xn/AGeLi98T/EDWYmX+y/DGj2dvc6hLE1xbaj4mvre28K6D dwa5rlg4/An/AIKi6Fe3f7GX/BE9vEk9hdeJUT9t611fU9Gt57PTprtvi74aub4afa3Uk80Vh9uW RrSO7kmu1h/100szyyP/AFvxNWjHw7xLa5Irh3Dydk+mHoOz07SXXRvbY/57PAvL60vph8OVI+xa xHi/mNOnD29OWIbhnGOlKcqHM5wp2pSipTik5Kyb1Z+SU3CyPycK/A6nHPt+Pb8K/ef9nZfjxffs D/8ABL3QP2bpLKw+Lvi//goR+1H4U8M65qNsbu38KW2v/s5/tCaP4n8aJbie3E174N8K3mt+KNNj kmVJtQ0i1hlWRZGjb8LL3S7iNWaJTcAq/wC7iUksAuSFUf3Qfve/5/1B/wDBPH4e6Hqv7Jf7F3gD Xfjn4i/Z8+Ovwy/aW+Lfxg+FN14d0Twh4obWr/4m+DfHPw9s9D8Q6Z4v0PxFYy6Fq3hrx1qNzeLZ W1rrMPlq9hqFrcIs6/zr4I4jDPiDMIVMTGjCvllakpufJOLniMPdQbaalJWStrd9dWv9k/2o+Az6 j4R8G4jK8oqZpisp42wWa1ME8K8XTWGw2U5iqmKrU4qUXh6TnF1W9NUna59Oy/sq/D/9kL4t/s9/ C3wUZtQ1B/2BP+CoevePvGmpzLc+JPiH451XTP2Z7jW/FfiS98sPd3uoXXmJaxosUFhZQxW8MalJ Hl/h2+DCpF8P/D4HLGxQsBycl34/Cv64fhZ+1J+0B+1Z+2hY6l8XfA+geEtK+CX7Cv8AwU7+C13q XhdNRg0bxf8AGHw43wFm+IeraJZ6reX2oReGv+EXuvhfeac89xdSRaxqPiSGG4W1S3tbf+R74IwT y+AdB3RMSLJAp2nkB359znrx1x9a+88blhqfDeUU8PH2OHo46pSjT5eTSEIq9na/NJNym7c3xXdz +UP2XLzuv40eIOIzyusxzfMOE8Dj6uIjUjiKcI4vFLEwpxlTbjD2cKipqirKi4uklHlsfo1/wTs/ 5P8AP2TP+ypW/wD6Z9Wr33wPqEdx/wAFBvAVsB+8s/8AgptcW7cnd83h7WX5B+v6H1rx/wD4Jt+H dS1L9v8A/ZOEKpEifFGNpJZWC7Fj0PV5CRHlWZiBwq/nX2R8Kvh3pOjf8FH/AIfz3c8Wrz3/APwU pluYmPy21lqNnoOvrc2flA72byri3kKzO3X7tfsX0Q8P9a4S49aSapZViKsJdOaPsk1fbXT03ufi f7Yzmp+OHh/SqJ05rJaNRxkpRlySxUUpcr6S5Zrys9EfmP8AtQadcTft1/txyNG8duf2k/Hq72DD c/2/zNihstlkdW5/hI+9V/4LxpH8X/g8iKqqnxd+FP47fiF4bYFj0J3Y+uK7z9s9Yo/2+f28UhQR xL+0741VUChVTEVluCqoVVXeG2rj7vX1rhvgzt/4XF8HtwBH/C3/AIUgqWwWB+IPhwMB6naTX8Zc XqrW8T8VFQk4rPcLZRu9OelduyX9a9bH+0n0eKeAwn0E8gnUrUqVev4X5s3OpVhGTUsPjGowUndJ 832dZaPsf0e+NvCuk/Fn/go3/wAFP/2O/F9zPd+CP26P2V7LRINOMzW/2H4n/s5+G9A8T/DSPTJQ yKmreJn+IPiGeCOP/SbuPwvJsVXhiNfyM+DdK1zStAj0jX7JrbW/DF7qXhTX7AtuudN1zw5f3Gja pZXqBQYpobyzmRlOQ23jGRX9N/7Zfxlt/gJ/wUj8dfGOO3kl1n4I/tA/s8fEiC3h3K+s6Rf+EZvh 3rej3JjZZW0qTTvHEupX0OVRpNHt5m+a3Ur+Qn/BTzwB4U/ZQ/4KOftZ+BhexWHgD4jeK9N/aA+G mqGR2tPEmh/GHRtM8a65LpDRfu7m3svFes67aQpDujMVuvl7UYKn9JeOnDmIx/DmXYzBUJ4jEYSd N+yhHnnUp1KcYvk5W5at3dtNNb30/wAZ/wBl54r5HwJ418U8N8SZ1hsnybijA4n/AG/HVoUcLRxm DrupT55VXGldrljHmbdm1Hlu+Zv7BHx90b9mf9pXwV8XPEOoTWekeF11m6uLEQs9prkmo6HqOhtp eoSCOZorZrbUpriNvst1H9ot4Vkt33bl/er9lfwZ/wAE6vidqnwa/bB+AHwe0X9mvxfov7UHjv8A Zo0aeDx14muPCnjjWviD8Pdb8Zapp01n4u1SbSbB9Y1QxXmjSafa6LHb3R1aFbe5+3W8cf8AKr4b 1eT4hTeR8Pfh98TPiFdySCOGLwV4B8Qa0k0ueEEtpBIxLHHTp7HNfpz8ePgn4y8E/wDBAYS/Eb4c /FP4NeLdb/4Kh+E9f8MaF400fxD4D8XSW1v8K9bOleJdChvPsOqQWwnsLibT9esmjU3Om3IWRvIb PzngPhOL55rQ4fxOWYjB5ZieadKeKw7pRWJryp04NVLcybdtNvI/bf2oH/EAM8yjCeI/CnGWR8Se ItHH5flE8Pk+Ywr1KeVUfbVZyrYelUcL+1tF1Zc0kmoRajqvyx8feGvF3wY/aG+OXwa+LPhjV/AP xC0X4peOdSbQNft2tZ7vSNb8T6rq+iatp7svlXum6ppt1b3VpeWrSRyRsyvsljmhj9b+CfxMT4O/ FTwd8VE8OW3ii98F6lHrWjabc6g2mRRaxaES6fffaUtL35rWcJKsbW7K20/N/FX2V8AP2hf2cP8A gqb8PfB37GH/AAUh8XWPwj/bH8EaafDf7Hf/AAUKmns7NvFrLZwSeGvhV8eryIW9prd1dKbO1juN UaBvEcV1FqGmT2/je51rXtR9Nh/4IbftveD4DafE/wCNH7FPwzs7N5I4df8AEvxd0+5nv9PtyUj1 SSyXW08pZof9KaJo8Q8R7q08S/ArjDI+L6+LyfD1KlepiHipc6ajSq80ZqdObjJOEm1KLtbRrVHt fRi/aG+D2L8HKfhr421HldPKMpo5FRlhKVavHOcr9gqXsqkaUoONaFP93UlGcVJNStHr6Vf/APBc L9rfVJ5ZNEibw20zyPI2m+IbZCVYBcTyHwsskq4yW3YY/Lvb93tb8pP2gfif4k+Ovxi8UfGvx5d3 WpeOvF9tpMeu6vf3UF3d3yaLptrpNisj29np8LRWlhZ21nblbeN1t7ePzGZt1fe+pf8ABMP4eeGF Q/Eb/gth/wAE3vhzIhzcWUus6XeTwqpUSIsl34usIWkU5RRtfkZx2PY+Fv8AgnF+wl4muLfSrr/g sT4R+LuoXsbILL9nf4XaH41vbqQBt62BtrTXZGVf4dssi/7VeFjfDTxfz6l7POMbOeF92VWjVrTd NW5Um4qKSaj5W7n1PDn0xv2f/hVj6uceHvA2IwufYeNWjSzbA5HCliVCajzwhVk+a1SSjdqq5tJv bf8ALD9n/wDZ2+LP7cPxw0f9nL4KiCwE0Eut/Fn4m6uDD4P+EHw1siJPEPjLxNfOY7eI21kJItI0 6W6t21PVJLS1lutPsje6nY/rl8Qf+Ck37HPxT/aq/aE/Ze8YeJdTT9hn9pb9mz4EfsEar+03op8i /wBE+KP7Nus+Mrrw98VYtG+zXn2X4S+JPEXj2TS7rWpppLqPVNDazjs30+8Os2vzD+1j+1T8Bf2d v2db7/gm5/wTBT4h3+k+P7qe8/ba/at+IXha58DfFH4rKjyCT4a+HJLiw0y8j8PXsWYNWGlRw2Z0 mO78NJutNRuPtn5I+B/BWjRxpo/2awsLI2n9mNpc8MFxFqlqFZTpzaXYJDc3DeWzyXEdwZmhbypP l8z5v6X8NvCGlwtw7J1nGGJxtFrE1Wl++coe96U7NpbW73u3/lP9Kz6VvEn0hfEejxD7Wrg8kyOv L/VfLZK6wWHp1YSp1aqTklWrezpzqttycnryq0I/RPx9/Z5+L/7B/wAbL79nL46QwX1s1qms/CP4 qaQDJ4J+L3w6umZtC8XeFb9HntX8+1Cx6rpaX11JpWopPbx3WoWDWOraj1Xwx/aE+InwSuby9+G/ jm88KSam8Ml6+n3EUMl4IZFdUlmj23BjJQboxM0X8W3cqyr+iPwW/ae+DXiH9mvRf2MP+CgvwW8R ftYfs/8AgW6tvEf7O3jzwTr48P8Ax9+AtzB+8m+H0fiGJh4mv/BZZEg0Vre5ZdM0R4vC2qtd6Bpm nafYasWm/wDBEKKIfZv+Cev7WHiNY40ffrX7T/i/Q5Cucbyia3abDuIVk27vm3Y+UY/EOKfA+q89 q5hk+ZLLKdWUpyS54y9rKSU5UXBqSU7q9tHrLROy/tfwh/ae4LIPDLCcD+LHBM+Oa+AVLA0K81hq mGxGCoqmqFHF0sTGcK8qbglTlKKaUYp35eeXzs/7fn7T2oWvmH40a1Et5Fl4otSiRiNjHchnnkZE dCyyqytjarK3zZr4B8T+OtLa81/xHrOq2z3+o6hfatqt68kHmXd9dTyXF1duEK+ZLNM7SO2zdIzM 7fO1fsLJrP8AwRatGdY/+CTPx51ZVX5Wuv24PH1m5UcEqsfjy3ChVwfuZ/8AZvNp/E//AASO0zVU 1TTP+CLfxe1l7G+N/pi6n/wUC8S3emXcsEv2iz+2aZrPie90+6tmHkrPb30NzZsqtHdwyLu3eM/A /N8TVhDM+KKuJw0ZQmqNadSoox91zcfaSVpSV23Z9EkfoUv2qnhpklDFf6ieBeC4fzSphqkHi8JH L8InJwUaTrPC0VUqQpTblyKcY6tJu7OV/Yq+E3hD9nDwHov/AAVa/bUOsab8OvCWshf2Lv2dbGVd P8cftK/F6SKaLw1qr286m5s/BmnXLf2k2opD9nt7aFvEM011BpK6LrOj/wAEtfHXjP4qf8FUX+LX xCgsbXxx8YvA37VHxJ8WWmklhpWnaprHh3wlappNgXLSSf2XpNhplncTMf8ASLuC4uI441kWNfmP 9qL4ufHn9s/4wj4yfFjTdD8N6boGnf8ACJ/Bn4MeF72zh8EfAn4c22yCy8JeE7G3X+z21m4tYrdf Enii1j8688q4hsZLXS7q4tZIf2UPid8Rv2SP2l/hn+0VpPw5sPiVY+DYfEvhvxn8PX8WWXhy/wDE 3gDxrp66f4ktdE1y9LWOh60slnpMlnql1DNb+Qt5HJDJNNayQ/vOQ8O4Ph3KFgsvoxp0IU4wjJcq dWr7sfau6u27u8r3s+mh/kt4reLnFnjFxzW414uzTEZjj8TiKmJoYepUc6GDw0aiqQwlCN/3cIQi oKMbJcsbo+V/DuoacNS8ZobuGN/+E78a/K8ybuPFWqj5gxVh0Gcrn2r66/Y7vLaf9sH9lNIZopHb 9ob4OqgEgZgT8QfD6kqqFnPJ/DO77tfSGoeIf+CPusanreqX3/BLT9obQ77WNU1DWb+XR/22Nc1L F9qV1NeXkqW1trX2eKKa6mlmEUcKxx+Z5cKxxLHGvefBn4gf8EevhJ8XPh58XtH/AGLf2u/DXiL4 Y+J9F+IPhuOH4+6x4vsB4i8KX0GtaHHeW8008MtoNTs7UXcd1utZLcyRzIYWkUfi9TwVzGvxEs9p 5jThF5j9dVKdO8ko1o1OVvne6SSbjprdH+m+XftNOFsH4LrwsxXAmOjiocFz4XeZU8ZD2Uqjy36l GuqcsNqryUnHm2drrQ83/wCCmFy6/wDBST9uSDznK/8ADc/wvLRhAykiz/ZqLKzAbl/4F3XjGcN6 z/wWpjLf8Fif2xNoz/xTnwIOAMkAfCDwKWbg+oHGN3cV8S/tLfFrWP2jf2hvj5+0ifCKeENQ+M3x 50b4323w/Ou2t9caJY+F5vh5DYeHrzXbVItPvr6707wFbSS3XkiNbrVGj2f6Gyr+m37V3xb/AOCL v7fPx21/9qj4v/FT/gpD+z18bPiZ4d8D2/j/AML/AAw+Cl54h8EaRq3hPwvo/hiOy03xFL8NvEdj q0VnFo8KyX8d6tveMrXUEaQyR4/T/EHh3EcVcM4zKMLWw9GtUqUOSrUl7vNSaevfTTTzVro/g76I XjXkP0f/ABryTxH4kwGMzDLMrw+KhWwuX616n1tUnBx0a93le+l1rY/J3RdTTRtV0/VXsLPU0sLq C4m03UE3WV/FBIkjWd5GNzz295GGSZgYCpfcA6Ltb+kr9kj9uj4r/tnfB/8AbJ+Bvxds9J1n4WeF v2RPGup2fhDUIrTULN73TbS3GkuglsV8q30o2MUtllJnjnjilEwZIwv5V3H7N/8AwRee0NxoX/BU /wDan8AuDiE/GL4LaBZRK/OBOzeBNDZ9x/hEYYZ2816t8G/i1+wV+wT8L/2uPHngL/gpF8O/2r/E PxY+APiH4ReAfhB4f8N2ll8V7rxD4jmhgt7i10fS/JmmsreKRp9QWSzljtLeEzZj3O1fkPh74Z8X 8H55Tryx+FqZZUk5Yyhha84+2jGDUXKLvF2ctL31e2p/on9L76dX0b/pK+FObZTheDs0hx5h8NTo cL5nnWDhOeVVKmKw9TFLDT5ZOhKrSp8rqQ96SSTbSR8tfADwPbv/AMEKP+CkWqWdw8Nwf2k/2Vr+ 4hkka7juW/4U/wDCOaWQTFY5I55nkaS4aTzN1w0kn7tWVV+CrbSdQtrW2ilhOYbeJGMZLISkYztL KGxwedoHHvx90/8ABPK40r49f8E9v26P2BNS+Pvwn+DPx1+JnxM+BHxK8Baf8VPENn4b0bxT4Y8E +APAvhXWZNHu7i7s21CZ9a8M6pazYlna1jiS6ukkhkVa6G2/4I0/8FRdQgWfwJbfs3fFHSIoFI1T wz+0F4JgaZFT5THbalq6zusiAbfLaTeW+YdGr1/GLg3iDiivlVfJsJGrDD06qq+0qa801TacXtHR W17aa3Pz39mx9Jfwe8BMl47y/wATc7xuVYjPcfl1XL6lKisTCdPDQqxqOoo++veqNpRi9JWT0PQf +CUFtcReOv2yZUin4/Yf+Nas0cLuVZrC3KqMKygtjLZ/hGa8G/4IJzy3H7WHgZSg3x/sQ/FqNI0S 5PlyJ8IU3+Y7yOqlunyx7eflbn5f0O/YD/ZU/bT/AGNbz9tHx/8AtR/DSz+FvgMfsafFrRYfGT+K vD+v+FrzXb+zhhstOivrJ54POumIRWjnVmYorK+5TXxj/wAG83jW31D9r3wbo2raXa299N+xf8Wb eGeCzSJLqaP4XL5lmkRVmleGMfM6nbzhq+18NMkzLJuEaWXZlh6VHG0I4i9Jy5p8rk2uWSSTTTXz Wh/NX02PErg/xN+kdmHGPBGYrNeG8dDJpYXGqEqXtXRpYdVY1IVLSjySg07rS1+tj8k/glCx8Baa qxsTmUZAOP8AWye2096/Xn/gkZ4Z1fWv+Cg3wYtrK2Kg6T45LTSP5aKB4buh1AZgysyt932HavyZ 8DeNtB8C+HtJ8I+NLTWvB3iKxS5t73TvEOgahpEkckdzJsZ2nij3BgobzB8ozwdrCv2W/wCCMPxD 8E3P/BQ74Mi38S6Xeu2jeOCLWzuIpbkg6A+QIM+axZQSPl9/u1/NWVZXncPEvDV6uV4mjh5Z86qr 1KdT2bjGupKUZWs7pfjbqj/bbjfjvw2x/wBCDOcqyzjjIcdnVDwllg5ZbhcfhJYmnjIZRGDw86Kq yqc/NFxcYxTvp6eg/wDBarwqPFuv/wDBPL9oC+vGvv7e+GXxj+B881vkxvP8Hvif46tEtmuGOZpY Z3cSK0a7fMba3zbq/KNIo1UBQqoR0XICqp4B4LEsD29a/Rb9u/4kD4g/8EyP2KvF0Cvdaj8Gv+Ch P/BQXwN4gvJmVPLsvEP7RfxMvPD9oTHtkGdHudHiWNtojWFgpYPsX8w4vEZkSN1+zkyqnRnbaWHs /Tkj8fXaa7vHvL68uLMNiacG6eIwVGTdm17SLXMt31bXp0Pmf2SPGuUQ+j3mGUYyrCnj8t4kx8nG Uouq6FeNGNJ2etpOlNpWe6vtr+t37AfiI/Cf9kT/AIK//tHMsltcfC39mDwL4V0+8TKky/ETxFr+ l6jHDKCG3LFZWKSov3/OjXqFrB/4K8II/jZ/wTjjADeT/wAEnf2bYyCpA/drrw+UDJJ+Utx2x8xr vf2N/DmnfEH/AIJg/tA/DnxAtxpWh/tf/td237PGsaro7rHqYsPh78EvHHxns4YpL0XVq0Tar4at opFmgkiWKaXaiyeVIvin/BVnxha658Xf+Cbl9Ok1jNc/8En/ANmV2Q4dBc3dprdyscboRmA7yjly VXJXFfpGLwP1HwOWHUJKdXL/AG04xV/enUlNvTRPl5d/XyP4oyTiePFf7VCtnMsRGWCp8Yf2bhZy nFKMMHgMFhXFXb1delVTtaz0fn8A3ACwzN0At5nI7hTlt3HsD78V/eR/wTkZVg/4J/LlQ3/DFnxQ cIGUuyf8Jx8Pl8xVDbmRWYKzrhUaRFZlaRVb+EK3W1ae3F55psXmhW8MGBOtkWCTtb9BMyxsWVTu 3/d9Mf1a/sg/tJ/sZ/tZWn7L/wCyJcaX8WLD4o+BPCGu+Cfhr8TvA3xB+Kvwc8T+FFkis9bvJb/V fh14q8If8JLo0usaXo11e+GtZ/tLw5rDadDb6rpd5aNNBJ+efR/zbLsvzrMMJj8fDDyzGlQwuEpS 0lVxDr05RjHeTvy9rbXfU/sX9rtwBxjxn4b8F5nwxw/js2yvhbMM2zjiLG4aKlQyvLqeT4ujLF1p TlGKgpVYPlvzNc7im4s/oC/a1fT9e8Ufsw/D25Kteat8evC/xI06LCtIf+FK3lp42vJkRvmYW0QS aSRf9Wq+Z2Ff5q3jPxL/AMJ78Yv2iPiEXM03jn9oX4ueKHuAdyTjU/Fl7PE4fBDhlmbc3941/cf4 5+Ifwq/Zo/aK+Gvhv9qX9sr41/Hf9o/4F/Bjx/8AETwdpfijwP8ACfwl4X1XTPi9YX3w91XVEtPh d8O/Bz301nFoEmmWVrdXM0dmLdtRuFe/u7u5m/gt8DeH9Y8M+GodH8QbxrMF/q82qiSQSPHfXF88 8wYnEhkkfJlO75m+b72a+6+kDnmHlkeDyqOLpPEvHqrPDRlH2lOEYRXvKLvG75pNSP5V/Y9eHHEF LxS4h46x3D+YUcip8LLCZfnNbC1IYLGVsRiZScqFeVPlqThCKjeEpWtZ2eh+hP8AwTT0SPxF/wAF D/2NdGeMyRS/Gqwu7gPHvjWLTfCviy9kk46LG6RKrMyjzHjr+p3wP4p+JnxIu9P0n4g/F74kfEfT P2wPGf8AwU6+Ft78KfHsvgzUfhv4H0f9mXx58S/B3w6/4Vnpem+CNK13RpZtD8OaXJrE+teIvEb3 txLNNam1WQIv833/AAR205Lr/goT8JtZeMOngTwb8UfiI5bB8k+G/DcUCTrxkENqx6dd23Oa/q+8 D/D6z0qb/gnD8S40B06PVv2kvEjsoASbU/2sdButeglc4O5rjVPEb3MneRnZs5avV8BqDXBFaM4J QxWZ4qfM4354whh4a3/lu9GvxZ+eftZc5nX+lFlEMPWSnkfCuStU+ZRnTqPGY/EzrJrWDlGNLq1L kTa0V/8APE+Et2bv4e+G5AQVitntSFOdgspZLcs2Tzuxn6c4r90P+CLOvXGkftFfF/SrdyJ9Z/ZG /aFls0Z8xSavpVj4Wu9M4CqVYyu4jG1j8rt61+Jfhbw//wAIe/jHwhgxN4R+JHjzws0J/wCWY0nX rm2WPB6bQny/TNfrz/wRwu/L/bj8C6EXVD4z8HfEXwLCrdJ5PEnh/wA0QOM/Msg0k8fxY24O2vwz h6u8u8XaMU1yQz6pQs4uK5Z1fZ/dyt77vyZ/q14y4Jcbfs5czqqrepW8JcJmVOomm4ywWAp4mMk1 1/dc3M17tr9Ef3WfsX3+s6z+x5+yjq/iP5/EGqfs1fAjUtdJAYnWb34WeFbrUzuJ3MPt007DcFPJ 9s/S4A3Ebeg6ABfT3/qc8V4b+zJqGj3fwE+FdjoMiSaf4U8IaX8PSEACw6j8No/+EB1q2AU4AtdY 8O39uFGCoiAPt7sDkZxj2r+7YvWUt37sUttlH5by/C/dn/Jm78z1vdybv30V/wANf+GAADoMZ9f/ ANZpaKK1AKKKKAE7n6D+bV4j+01/ybd+0H/2RD4r/wDqB6/Xt3c/QfzavEf2mv8Ak2/9oEevwR+K 4/8ALD1//Cpfxx/wy/OAdY/4o/8ApSP8/P8A4LGAn/gpR42x3/Zs/Zp/Tw5rx/nivzkIIU59c47n jt69efpX6N/8FigT/wAFK/Gw3Lx+zb+zVg4OMDw3r3B56nA+rbfx/OQqQMndznaGGSvHJdgdqrkc D/627+CPFWnz+JWZReiWJwMrqEpOyhR+Gyenlr56WZ/1vfs/a1Gj9CvgypVrRpxWTcQ35pxjHXEY yztJpXu9EvxP7jP+Ca5U/F7/AIJ5bhnP/BGfV35HQH42fs6kfqR+XHv/ADqf8FXIGtv2S/8AgjHA 2C0Wp/tybmGDw/xc8PsBz1HTH9M1/RV/wTWYN8Xf+CeR2uu7/gjLrGGUfuR/xe79nMbd5CneMDC4 wy7vx/Cb/gpB8Dvjt8cP2T/+CPMfwA+Dfj3446rpOpftsx3+lfDvTItUltHvvi3ocVmL67knh0+w E81rdpDLdXka77W4XazI3l/15n2FrZhwDVweEoyrYjEZLhaNGmlyzlN0aCUeV9+t+qXR6/8AOr4O cSZPwp9LvKuJc/xsMvyXJ/FHOcfmONqN+yoYalmuPnOpJxTdlG7ut07pM/Ew8jAwCxwT04+g9zx2 46V95/8ABMq7vJP29/2U0mnmkjg+JTrAkru0YP8AwjmsbWVSWXPRV+X5d38Irb8H/wDBHj/gpD4s isL3xz4c/Z9/ZZsJxHJeQftD/GjS9K8TwWm0ST3Fn4X8PaZrE17cQw5kW1W/SKaT5FvUVlcff/7B X/BOf4S/BD9orwP8bH/bX8c/tg/E/wCDF1J47i/Z6/Zh/Z41e30rV0Gl3ltALD4g+OfFmj+FfE9j dLc5s5tN1KyjuLj7PtkeBnmX+bOCvCLi7BZ3leZYynTwFLD4yjiK1OrNKpUowqwlKMYpq693bfyV rn+2f0n/ANon9G3PPC7jTgrh/M8XxTm2d5DmWTYLE4LATq4PD4zG4Z06Up1a0I8sdb88bWi78x+u FlBbx+OP2eHhgjV7n9jn/grBNcskSIzyHxr+ziBkhV3MUVhub0+brz/n/wDwj+I3g628DeEPD41V L3XZLQ20Gi6TZ3mra1JKbqdha21ppNveS3E7L84ixuwc/dxX9+nxgf4z/BHw7/wTzutA+Gng/UP2 vPH/AI2+MHwwm+BnjnxJeR+Drr4J/HG9k8XfF3Rde8SaPo9/caNrOlWXgv4WSXGuw6Zqtlo1/c6v oS2WprqFrqcPqvi79kv4pfs+/Duy1T4PQfsMfs6XOuahofg7wr4H0T9k248f6rB448WXcWkeGdMs /i3rHxZ0GebfqM8MKX914C+dh5w0+J/lb+geNOD8v41w9LC47EVaVLLcU6k4Uo80pe0o0ZcqtJK9 ve5dH76bWtj/ACA+jJ9JLi76L+dY/inh3JMBmmJ48yqlgcrqZtiXTpQpYPH4ijVrxpx5q06Ea0Z0 o1FB0XOlOPOnGXL/ACvf8Eofg5+0X4r/AG6v2a/Etp+zF+0Npfw90Xx0urax8SvE3wp8WeFPBOma OdF1OJb06x4i0vTLS5iVpo4VlsZLkxrLwPKZmr9KvjX8Ovhf+zd8UP2R/wBq1tdh13wP8Y/2ivFH x/8AEqaFbXvie88P6p8LPFeseBvHfiLRotIt766ntLyDxh4TjvNP0aO6bTYfD2rX11FDbw3k0f7I ftYfsgeNYdL+Hmnp+1p+1r42h+J3xe+FXh7Wfhz4g8eeC9P+HE3hG28TaXrXxF0C00rwP8OPCHib TtL17wBpvijSLkJ4te6trW8drK7tbhI54+N/4KGfsn+Hvir8fP2HPgl4AMnw5sfAPwV/an8UfDrT PC2m2k2nwan4WuvgJBZaBcaPcS28GpaXrdtql7Y30M19bzT3d5DeT3UrfaPO+68JcDl/hzUxeTZb XxNHL8znTweYTrv3ZQzKMKClJ68saEpxrSinqorufFfSB8XuMfpV8XZNxn4gVclweIhkWfwy+ngM O1HCYfhynWx0YSTjzc+JqU/ZRnZOzkm7Jo/nu/aY/YH/AGR/iH+03+0L8e/E/wDwV0+CHh34ffG3 4na/8S9P0D4A+GLz4+eNNMsddEctvZX1l4MstUI1SO2VEurC3mmmhlLF1MjMtcV4C+DP/BHn4Ka9 4Z8Xr8Xv2/P22vFPg3xHoXiXRYvDPgXXvgHYTa9oOq2ur6XF9m+J03w7sns1vLOJJYbu7t7SaEsk t2EZpa928Y/BjT/D89zr+leDNA0Ce41HULbWtHsvDui6VLo2vWV/cWXifw3fLpUTRw3+g6zBf6Te LDcSKtxZyrHM0e1m+Y/EmiXehalNaXCSyxQ3kQjnmZmV4WkDwzLg52sgEcnRfJdsDdtr9zpfRz4M jiamYy9liMdVmsQ8SsPSftJy5JRnGbd2pq0lJ7PZ7H4Li/pSeN6yHC8JQ40z/D8O4HAPLMLlFPMa 1LA0MCrQdKFGPLGmrOXwON76tvU6T40eN9a/a2+Mnx7+NWqeANR8EQfGXXJ49L+HF1fafqXijwH4 B0bw5p+heH7vxBq+jXmo+HrrxJDcrqV9qU2maxfaNaySaStnqU11JJHH+gHw8/aC/ak8OfDH4QeH Na0v9lfxL4w+Gnw/8N/DPwz8cPHHwbvvEHxg0vwN4c02C38DaV4vj1jwq3hm21GTTBZfZ8eInvtY kY+I72GGHVVmf4T/AGftV8U+EPih4S12zu1tZE1KWG7l1NITo2paTdMbfUtMuTPb3EZjvLa4ihhH lsyukci/NGGXd+Pfxh0Lxd408e2/hvxB/wAI54c17W5WtPC2jawbnw/oV/4Cij8AGL7Vc29nfSaj cWfhe3hulkVoVx/ou1vmbDPeFsJh3SoqEauGwEYKpzU/aLl59L+6+it+K1PyDD59i8NCeJo1prE1 pSftadSSqp1Lc15RlFu7bvr1e5xXif8A4K3/APBUE+Pb3wV4z/ap8F+GfDdpqV/o8qfCv4K/DPw9 faK8lhdtplydb0TVZdS1CyZoYltZrdZdPjvnghuprfza/GH9pL9q/wDas/aK12xi/aY+OPxc+Mmh +DtU1G88G6X4/wDF2r3vg2w1G68+0fXdL8OwzXmhadq01tbQwrNZs0ixJJb7lWZlr9gvC3/BOXwl 8WbjX/F8nxL0fw3a+J4En1m3124tl0/V3kmiddW8D6rLqumzWT6TOUuLizuLe6jXT47qRpN0e6vy 8/a50Tw18IrrxT4M0XVY/iH8L/htJb+BJvEq3i2mt6F4pIbU7fVrmwk0iOO50fUIri6g02aLVLqO +ks7tvtUfkqrf0BwhkfAlWngq2V5VgKuPVGjJ1HR5JUaijFTqRbVuaNR2dlu33PPr4/MqkJPGV6k /aXdpznKXR680tnvZL8rn5w61oN94hOmW7aXY6dEbaSXLTRwwahM99csLue0maGSzeZSFj86OPaq xtCzWbQzN91trGmaJ8NfhvpPhz4UfD0zeJPhX/wjra9o+nolzDbaDoj2Hia81PWokazbxZ4ovALr xH/al7b3jM11pNv9pa88uT4In8V634y0fxXceEtNbWdN0WK0uL6a4uItLmgtobeK1bUxHItwyxqY C1wq3TL5Y86ONfM21u/Ab46eMrLVJPhxPe6XD4Z18XOnajpms3YTTEtr8me6vEvhayTWskZjNzvt 0Xzmi+ZlZttfSZ3k2CxdWVTEYehUrUVBqVWMG3FcukJW/RdvXnwlaok43cU47X+GV1Zb9fPbqeT+ MY9Y8O65f6be2SaLfaY8flW0rFWiZ8yQRRO/7ySSaGSJ4WkVY9sW2Nm21+mv/BPH/gp74q/4J96n deMPAfhbw5rmv6rcRw66fF9gmq6hqlvMRFqS2E7wXDW6tZ7Y47G4e2s/tCNdrJ51xJt+Efj/AOG9 N8FeLoZ5vE+j+IF1z5tD1ewmnvdHuoLaNBd2Ey3q295DeWHnWiWrTbo51lmkgmk2tHH4DONR3w2+ g21/eatq08ek6HZaVZyarqGo6lqKRww2VhpVvDcXl1qF1M4jsY4VmabMarHwzN8zmuX5T/Z+Jli6 GGWDVJ+3dVQgqaildKXXq/v72O/DTr+1o04PETnUSi1yyqSlXlJKMaNOKlKctVsvx1P7a/Cf7Geh /wDBUbxrpX7Vnj/xB4QmsviDp+j+MvHmkadFpuna9Ab+3GqWXhbTdPlNrY2dzosQOn6pJDcf2jHC syyQeU0zL7X8Wv8Agmd8Gvg/4O0y4+Ffw6L3ep3V7Pd6l4s8Wwi08JWctuUvbrTbfTrm+sbnUNQh sofsqrMLGNYpBc3ENx5Ubfz6fs9eAfjF+zl8ErX4b/tQ/tU+NPgzdXR/t+P9nj4NeHU1j40/2Rfz w31v4c134wt4jn0T4X+IfGF4La1sNNs/AfxK1GK2uJEvoNMlWS0r6r8WeHbLS/Bs/i7xn8G/2mtR 8DaDodjretHxL+1X4c1v4reHNCvZjaWviaLwdofh+3uNHstJnuLWGbXte03/AEO+1mNr7w21veQ+ X/GXFHitkOGzDE4LLsbiMbgsFJ06n1PC1Z0cNGMoxarOMWlGO7TcXbdH9U8KfRh8U+IsswGaV8rw OS0s1dGnlaz/ADDB5Ni84lXSlRhl+ExlejXxE6k1FR9lTktVdppnh/xC0200bxPJ4f0f7G2m6Wt/ FaW1hqIu3kuHu7k/aLiRT+/uFhMa3MkfmQxyK0aybY64HUPFlnpLCC5NxJOkCH7LbASPukdDueRi salfu7ZJFfnO35a9P1zxdafD/wAMWXxd0jVdR+Mn7Pz6lpngPxTqfjuw0xfjn+zv4u8TLDZeFE8c apowsdB+J/gfxI89rYWXjfT9L8E3Gm6smp2+o+H5LWzj1K/+WvE+seHtXmM+mSSJAjSG3jjZytwi t+7aZZIkkV1Uj5vNkWTqqr0rhw2dYLPYQxWEr08Zha1JSp1qSfs6VSNnyyTtyyvfmTs1vc/MOMeB +JPD7Psfw1xXlWKyrO8G/Z1sHiY8s4WlaFWnKyU4Ti24VIXUk7p237G4+KduS8J0uYrE6s3myxh3 GMYJDspOMN9773y9a6XTdcj12whu7beg3yJ5MxXdGyOVPKFlwwXcvz/dOflbK183z7BucKWklUBo UbBChshixDbTtz/C3Sun0zxeujeHLixtYGN7Jfv5MxHmrHE8UZ3Nho9/7wsir8u7H7xo921Snhpz dWtOrGXNDRenKvdfys+p84ouFOFoRineKlGXvTaaTcr9b3sn6WPY9T1ix0uIrfT2lnE43wyXDAyB eSdsY3TPwP4VbgZrzm7+JmhpK4tFubz72ySKNYYSBwdvmPHJhiMr8vdt2PlryTUby4vZmmvJpLy6 kLGWWYkxhj/zzAAVRjPyrtXj3rBuAY1VSxbIIXAAJY5+TIC8Y/8Ar1eIpyqww8IuUn7NNcj5eWS5 bSfaPR37N9GxaLsrfI9YuPinBgxrpgBKfMZ5m8x8sfmUpuXb2+9u3A8VVHxM04TLHPYXUUUit+9i aN+dhPCl92eCflU8AHmvGZGkibDnO8EhQAxU9PJBPzBMDdz8+5vrVHc0oc7tqqW3Mwy0ZOV2ADoC GPzdf6FJQhTlTvVjUhbnnKXuOyXurVdUZypxa5lrbzuvz+/fsfVen69petWrJZ3fmIDGXiuCVnQc 7sRPtkwrfLu27f8Aap1xPFAJFUwlUQu0zZVVUJkk8fLtA5/OvlWG6vrOWOewuJUmVkMUsUgUsyZw G3blK4yNretezW/iJ9e8F602Y4tUttOuo7yLeoZn8ohJY8LvCyAj+6Fk3L823dXC6c8RLknVioJ3 0svhst+/6G9FNrTVf/bWW/8ASPOPEHia512+mlllWK0Usun2sQ/dwwDIGQQVEkigMzfxMK5aK6jT zikKxSAApIUQMU3HcCVG4Fjn8vXNYd9NLBCz2sUcsfnxIBIW2yq04Vtig7gdrY+96dKSKcmMZR23 t912H7n5s4G3qq9++3/arKLUai5dbaadV/l/WhEacmueXMu2n9LvfW34mjfWtrrJ8nUEt7jTC4Ml vcQrM3mKg5EZ/eMg46fKWP8Ae3Yy08BeBLa5iv4/CWlpqDbjFdW0clncwvgqs6HzIvKkhBM27hvk 2/xVcNzIBK0uNp2KRkbnUdBkAEcfL8u3pT1uYGILLKpfepaVwI1UMACWG5k6bdxXvtx1r0YyTabq RhKX2Xur8q69Ph+bNLe0jGMY3UV/6V/Wm3ojd1XxB4r1fwxN4Q1b4h/ELUPBFzLb3M/gbUfF2s3/ AIRv47KQfZhceGTPJZyNDMPMj8+JY9yxtuZlU1o/Dn4n/EX4EfEbw18Z/gl8QPEXwu+Jngf+1n8N eMvDFxNbXllZa7Zx6d4j0u/tBJDb6xpGtafCtrrWk3Un2O+tS1rcfxKuDDF4fAR9UudRRpG8z/RY o5IXkwyqI5WmjaRVTOF2xq3Xbld1bkGmeCNRkitLbVbmVWgMUsU1zHZMXcZkR4JIJll3Z+bbcKzN uIxUTdLDyk4z5qzipJX93lfLf8v/AG3YSjKSvZtJcutvdWnurtbt+h+qui/8HCH/AAUw03wxDoXj zxx8B/jXYbYLGLQPHv7OngS0jutNCkMZ9W0gajcXUrpiMy3VrHLHvMm5mVc1fC//AAW2n8Ga5efE 3Sv+CXf7BekfH+20nXbLw18dvDMvivw1400bVtW0+bTm1TGl+CUhVraO7N4bdblbW5kiS1ll8t3Z fxe8WRQadq+oWNgHhtrSfZCkpCS7Y2IB3Yb/ANB/WuEvdUUA7XkLvIYiA5ZV+UE/NhVcZ+bO1d1Y YeisQvbzpwU4y05oxcldLVafFfzu03szsjmmPo0J4WjjMVSp1dK1KFerCnUikuVSjGVpR6tOy9bn 6yfslftyfstJ+y58T/2OP+CiXwe+Ofxf8H+Nv2gdU/aM8JfFL4A+IPDXhjVvCnjbxVDa3/iuDV9O 1nxBod+NPk8WNrGuWtjolrqX26y1K0tnVDFmL0/T/g9/wRZ+IxWT4a/8FNv2h/gPrMqlLDwJ8Xf2 bfiB4h02ykzviS/8b6fol1o8KKuIiy6hcM+3eife3fiBb3y7iH+bAdCeMyO7EkEkYB2sPmXay/w9 69f+A/wg8bftG/GT4dfA3wFBPd+Kfin4y0LwjppitTqK6cmpXsMOp69dWm9GfTfC+kG/8Raoyt5i 6fpdwyt/EMMw4fy3NVGePyuhilG9nVUZ30jd8jTu/l03ufW8HeKXHvACceFOLc2yGNSUOb+y8ZVo KVpRklJUpwlZNybtpq9PeZ/ap+w/8D/h7oX7O/w7+BXwh+Ib/tReDfAfhX9rD9prxF8dfA/gvxJY /D1vim/w1sfBfwz8M6Xq+oaRZ2Os+NNa0vXPGEK6PoM+qalpa6cY9aj09tU0ldR/Mj/goJ+xp+2H 8ctF/wCCe37QX7PX7Pniz42/CvwV/wAE5/2fPhF4y1nwPqfha91Pwz8SvBmm38Xi/wAF6r4Vl123 8U2/iHw3d3J0/XLH+xHbStYgvtFvmt9Z0+8sYf7Dv2ZfgbN+zP8ADH4W/s3/AA+8G+ENL+Fnwt+H 1po8Gq6Lqr6Vdah4ng33GtfZ/B50u4jmh1TUJrq7XWLzxTJeSvcR28lv5UcbR0fE/wCxF+zh4t8R P8WvE/w5j+HXxF8UXVvpcXibTvFPjjw7r8V60gjhmt/DvhLXL7wXZ3s0jC6lvJNBYXlxK11qM0k8 0zPxZhkGV4/KJZFUjOOAqR9n7Gj+7iotpcsWrW5b6WVk99tff4O8V+OOCfEXAeJmXZlHHcUYTGyz GnjsZyYuVbE1qrqTrVoyU5VZzqNuUZxb11s7M/zn76D4r/Dqea1+MPwH+OXwns4WuIxqPjz4UeO9 D0tJLfcZ9l/f6DDY3NuoVm8+1nmgKKsgk8v5q/Un/giF468IeKP+CkPwBg0HxHpGpXQm8SutnDdQ JdOi6S4LR2ocTlVB+ZWjUrhtw5Ff2Q6N/wAE/fiV4Ynv59C/bU+NPj7UBLcXOk+HP2mLP4c/Hr4d aAlzG6w2Fv4M0vwZ8Ltbl0mOJ/LS1l8YLdSW67RfK/7ys60/Ye+I3gPxH4d+K2geAP2I/H37QOmv q9no/wAWtA+BOvfs7S/D4ajps9vB4itvD2kePviknjeSO48mG60G81Pw6bmEtMutQunlSflmX+CO SZZnmBznL8Xi8NLB42hilh6jVSD9jOE5e+tYp9F/5N0P7u4r/ajeKHHPhZxT4Z8ZcP5LmFLifIsy yatmuCjVwuJoU8ZQnQp1HQSVOTjz8zcdWlyqC0P5fv8Ag44YD/gqJ4BcPhv+GSPD4IOY2KD4h+OV IySu87xuP/fPavxSAHODkLhiWUqw3MqMmT2wxbuFAr+xH9vL/gmHpH7cvxJ+F3jT9qP4V/tdeH/2 ndB+F+nfDPUPjD+yDqHw88Wfs7XdjpGp6lfx+INZ0zx9eeD/ABfpl5ruo6jea3ceF7OC/j8Ox3kW grr/AIgbT/7XuvxL1r/gjVfa1d+J4P2XP+CjXwh+LGr+HtQu9L1Xwd+0j8LPHn7Pknh/ULGVo77R 77x3qP8Abug39/aThreS40+xlguJo2ktVmjYSN8r4oeEnEPEefYrOssq0a0asIeyw3M3K0Wr9Ert u+nnc/or6Cn7QvwY8FfCjI/DDjTBZtgcdgq9apVzejhlUwvJV5XJ1Jr3o8ijzO/53Svf8EXdLurn 9qr4x65AuV8L/sUftFywTMSUj1PU4PCdtpgYgfK7tHcBDncWBCjiv6jptS17wZ+w7/wSv1fXtQ26 xfeN/wDgnJ4L1O0azjixf+NbbwB4e1CATKpmRo7i6kVtwX7Rs2XBww2/hd/wT9/Y5/aa/YW0H9sX 4y/tP+H/AIc6F4Xm+Evgj4f+BfiD8O/iHp/jrwb4y1Lxr8QdM0XV9M0a6sbW2vzdpa3Fi3kGzLTR XClV2xSEf02ftg/D6z0v9nr4OQRQqul/AL4zfs2/EVI1Koltp/wa8WaJqsQZgCoijj0xMyKF2R4+ X5ST+q+GWR43hnhDCZbmeH+r4ik6tavZxlrOcU2+WT6Ri1ezeu1tf4E+nT4q8L+NH0iM8444HzaO Z5LmeGyvK8DiZw5E6WHwlOU3aqueP73E1KcrRVuW6bR/nX/H/QU8IftfftseCIkKxeFv2tvjXp0c bDAWKLxrqqRYBAwNkO5R93kfw19Z/wDBM/xXofw//bS+A/xC8S+JNK8OaD4C8ZHxLrkmrXkVlFfa Wuh6zpU9laz3Ritvtslxq1lNFEZt0kVvcFQzcV5X/wAFC9DTwp/wUw/b50lvKgl1j4/614xW2Mg3 uvi19R1dbiNSVYtcPIN6LGyjzGYt1r5dJKsu4FcshAySQ6h8FSFXy2XLf7v+6ef5J4yr1uHfEjF5 pQpur9Xzb69SgqcoxqOlONSF7xacXa7tzaXXQ/6GPo35PlfjL9CXhfgbG5pSwsOIfD+fDWYVaUoV a2DoYrBywtVRg6kJe0pwqScLuPvRVr6n973wO+Ol1+z3a+Hz8NvjD4c/ad/Z3+Kf7aMfw51DS5dD tPBnxH+Avi79rH4p3ni7R9I0q706OXTfiH4Z0zxZ8SZ9V1fUPE+oaZrlr4Vm06Lw7Z6osMFo37Ww Bx8rHOCxXI5K56MwHXOM7mLN95lyCB/Ez/wSikmm/ZKsXuJZriQ/8Fif2Gd0k8rzS/JrXwaEYLvK 7EKuEXLfLjbgKu0/21jAYjAJ2jODw3THB445578n2r+3uFM4q5/w9lOc1qcaFXH4SNarRjflhJya Vr+Uerfqf8tf0g/DjAeEfjN4geG+WY7E5ngOEc8qZVhswxUaUK+KhHD4es6laNKMafNzVnGKikmr O17slooor6M/HAooooAYxI5HTHJ/P/H0rwH9qrU7TTP2X/2j9V1CdbPTtN+Avxhv7+7mIWK3srP4 d+Irm5nkJDbUhhjeRmPQIeoPPvrZ3KMZXufT6n+f5nNNwuSAx9uAefY9f6cfmkk3rovh/wC3Xb/g +hCduZx5pSjKOkvh/wCG6s/h/wD+CkP/AAS//aR/aM/auk/as0T4ufs3/Az9l/xl+z38BtKg+Mnx a8e2CpBceHvDV9NqFzF4Ztb+0vjbwwanBIZZi8dx83kqoiYnJ+C3/BDz9m/W774eSePfjJ+2F+2f e+O7WW68O+Iv2ZvhtefD/wDZG16NEQudc+PEPh/U7Pw9p/2hLi1bUZ/FsMccsbwj7TJGzL/Xp8MP 2I/2Q/gl44u/iV8I/wBmz4L/AA48fX1rqlld+MfB/gDw/oXiCe01zUH1fWbeXUrO0juXh1LVHbUL 1S2ye6YSyK0g3V7N401/UtD02Kx8LaZaat4p1d3sfD+m3MpsdMinCKJ9T1WeICaLR9MR/tmotYw3 GpSW6mPTbO6uCkLfLVOEOHZ5lXzavleEr47EVISqYirBzm5RUVHfRWSS0Vu2mh+8YH6RvjVheD8q 8Pco45zrKeF8spzpYXKctxM8JhoU6k5VazqODU2nKc5TvNJpvRWTX5Zfs3fs7atbeM/DGg3/AMON b/Z6Pwl/Z0X9lXwX4J8J/FT/AIWRrngP9n0+IPC3iW91Dxj8WLKa4gk8e+P7/wAE+HbPwkmlTaX4 30Hwpea54ij1FNcsrfVLT7D0r9iH4N+HdJ8Q+EPCF98S/Avww8W3GoarrXww8AfE/wAd+BvDa+I9 Qh0+2utd8Nal4X8QaT4q8CGaOwF1caL4H17w74dvtYvdW8R3uk3Gv6pqGpXH0z4T8NS+HdFt7O9v /wC1tUkaS71rVTaQ2J1bVLhhLeXv2GB2hskmm3OljEzQWwZFi+4DW3qd7a6bp17qOoXEVtY6fazX l5c3B8uG3tLWJ57ieVjwkcEMbzSN/ciI/hr6WnTjGMXslGMYLtGKTjGMYq0VZWta9uujPxzF4yvi sQ4xqVarqVpVKuJd3UxGKqP97XquXvznUqSk05NtJtO7cmfnD8VP2P8A9nDRvCPgT4HeFfhHoXiz xd4y1a/0vw18QPisg+OnxO8EaJE8d1418b6d8Uvj6nxL8TT6/wCGNLunv/DtjrmsahBe3sUVhaWr xK0cf6FeFfC/h3wL4X0Lwd4T0LSfC/hXwrpGnaNoPh/w9p1lo2iaPpWm28VrYadpOk6bDa2Om6fZ QxRwWtjZW0FrBEiRQQrEqpXgfwLtb/xzr/in4++II1EnjdItB+HEAj09jpvwj0W6kl8OzC+0i7u7 XWYfGeqS6n8RtO1GeUX9ro3izTtEuobZ9Ne3j7v4/wDxQ0z4I/BT4n/FPVVE1v4F8F+I/FK6eJUh m1e70jS7u/tNHtGkYK2oaxdQQ6bZpu3TXl1DGvLCuZ1YxhVxFT+HGm6jnKytGK0j6S1dtOitdJvs nhMRUxOX5BQtUrzxUKclS99VMdipU6c2pJXapr2dK3vJThUlGTUkl8VeAbY/tE/8FCPiZ8QruS7u fAv7IPgyP4M+Alk02zhsJ/iz8S7m18TfGphd3No1/c3Hh7w/4Y+D6aXcW90trbDX9ZijRmnl3fY3 xNht/EHjr4S+BdW8B/8ACU+GdT8Raj4vuvEDhja+CfEfw6tLLxH4P1OZR8q3F5rI+z6ezY23FvuU V4j/AME/fhTq/wANv2cvCereM3N38Ufindan8WviZrdxLJcXmt+KfG0yX0M9/PcbZJLuw8LweG9C cjJWPSIowPLjUn1zwtqmq+Kfj/8AEO/0zxS114T8DeE/DHw+1bwlgeTo/wAQZZZfHE+tYY4a51Dw d4q8OWzbVwI4Y1LcYrLCRcaUK/LaeMlGrNVFeSdTllCHePsoRVL4Vyxgr+8tPf4kxCqZxiMLg6in l/C2AjlGFnGp+6jPC/7NWxeHld8yxmZ1cRjoyV1Odd7qyPIP2q77XbP42/sHafo7Tf2bqf7QPjW2 8RpHGJIX0+0/Zt+Nt9apdnayxourWmnNGflP2hIVDfwtzfxuhZv+CgH7FNyCQY/gz+1dDnbuBMus /s5OoB6I2YvXjHH3a7Tx54in1/8AbM+DPwylmQ2Xhr4bePPjEbZo1Ltf2mo2Hw3inV+WjZLbxpcK cHb8/JySK4L9om6urP8Abn/YiFrL5cdz4R/aF0+7UJkyQXUvwjnZS3+/YxHG7nbXLjJOEK82rWx+ XpNaKTlWwa5uu7/VHs8OUKlbE5NgVyKrHg/jHEtu/vU6mXZ7iuaSV9XBWStraL2aPzo/4KQ/CbT/ AITfF4an4f0+yTw38e4LzXLTQo49MtI7L4i6JaD/AISaz8K6RpdrYyg69YwW3inWrq++3XWo+I9Z 1S8kuGaZol/Hv4j+BZBJLbTRIWUxz20wPmO2nl1aPzUX78CjbHNJBtZYyyq3mbWX+lr9uz4IWHx9 /aP/AGP/AAN4glubHQrzTP2mktvEFokbXnhPxTc/CvTIPDPiXT1lKRy6lpupZuLGKSSNJJoyvmLu Jr8bvih8LtW8K+KvEng3xfposvEPhy/u7SW2ljmFvZyiKaOR7EzxxyTeG9SA+2aHcBfseoWa/arV pFVc/wBQ+H/FkMzy2GW1p/7ZlVJUasqkveq4flpzo1I9H7OMlSlK99Ic13NH45neQU8DSy3E0pOs szwLxrhK7jTmsZicM6alypa/VlNxe3PbblPzz8J6Z4b8W6/o/hHUfFE3h7RY9ZgSDUgLZlttXt/m ijupFiX7PpkzMI42mZpBJtZpGZVrvvEX7BXhd9G+LOq6zeWYLeIE1/w7rtpqsdtaWNnIsWo+IJtR v7lpLVbuTXJdUvmmvFkhktZ4VaNm3M1P4i/BvxLqVvqXhfwbaN4vumtX1i1k0gmC5jV3iF1DJHc/ Z5rZrfYv2eaNWikVpI1k5NdV8Of2gJPhh4Y0Xwx8XbO91LTIblPCniHwxPbyJctoV3J9lilE7Kyy yxwP5bXFo826RG0+Rl+y7VfEVHFT9tiMFVg6eIhB1aM1ec6aqKXue9u+zXldbHz1PD0KNP8A2iVo 8ylKdrckly+6tV06aeh474c/Zel8X/BjQdK8WeI7HwtcSeIPGVl4U8Qa1fm/0a9hubHUhoMNjDJK 1rsvNSFjp81vpq2/9ofafsMf+g3U9q/5JftX/Dvxn4J+M/jq6TU/AfxMttH+GmkaX8WvhNObhNE1 azWWfTtJ0Pw7Jc3s1xdeL9LluZNes7jRbiG80+OWS1gaOwbULe4/oWh/aA/ZL1HR/EP7Ot5Lo+ke LRfJq3gHQ7mw1C612NryN/tGj6omkWV9eeF3VZW8681FbWOztUm1K4khW13L/ND+1J8UvEvhnwX4 h8MfDDwlq3gXSfA/jkaZNrEFrrMT61L4gm1seJ7DxbLqVpaw61LfCz0JtPmvJmkktYFmhVl+avuP C3DZu1VhXpfV6Sm/YvEUuTmpTcffje3NzPRLmetn1SOXGVMO6fPRftFHRTd7yUeXT06f0j5J+D/7 IPxF+L/g/wAWeOfCejeMtG+HXh/4maZ8PPGz29jqV4dTsbxbOKLSo5lLW9zr+nmZv7Ss7aNYbqHy 3jtVjdVriPF/wy8PeG/CnjX4fTLNqvjzw/4kgbwhqGm3OjQw69p93ObUL/a9paRXkiTRzfvNHW6+ 0Wt4YbVdhba30d8BvFf7XPgvwlo/wx0bwl4w8LfBnxv44g8XeKtb0kXenaTq2oulrFDcx+JINunr PZ20ECx6f9t3faEa1mWOSNlX3n/gp58BfA/w1+An7Nfx+8JaDaeDfjN4lis9L8evpc8qw3stppsu t6F4jt7ezRrGz1q1j05bPVrpZlX+0LlVjmk3bq+tzDiHCUs+pZLWxUK9bFTcKEaEk4LlUGudrWLk 01JeWj1JpUZOhGu4xpxl9p3t0t1Wq33XyPxD8VaD4xi0H7R4xeSxaFpjpWna1cXD6tLZ2p8ua5gW 9lkvpNItWxHb3Rdo45pJoIWUSNu/ZH9gTwppf7LPwm8MftTeOtBkuP2i/jDb67Y/spz+I9Lk1PS/ hR4A0mWbRdT+Ma6UFVp/HHiPxDaa3oXgC71D7RP4bg0qw8UacY4by3mH5ceE7nxJ+0L40+GPwx17 w7P4m8UeNviZ4a0t/GCTXE2uXuiX19bf2lp8jACGSLTdIh1e8JabzpVlkk2MbSM1+zHxk8YX2pfG j4o6Z4c+IF94L8I+C9ch+GHgG9ifWjpcHgT4KafafDHwBNHY6La3lxFcXnhPwjo1x5kNr5f2yaaS eRVZpq/kL6XPiLieG8vwfDWW4ieExOaypqvLDzlGUYSfL71m3ZKzcWn8UZJbJ/6J/s7vAvBeK3iT jOJ+IMFRx+R+HmDecVsDXpuph8xxWs8PRlGSlCStBynCc7yTineLcjktR+KcX7Pnwn8S/tYXOleH dc+JeuePYPh5+zrpviu/1HV/DGkfFLUNF1XVvFn7QXiK217Ur2+8U6h8PLPT9Ti0ldQuLu0PxNvf DOpaxa6laWklncfMH/BNyH4i6n+2vefFzxr4wm8S+FdG8JfEfxn+1J4+1HxB/aWl6x4A8TaJPpTa f42uZZWg1aLxF441HwpLpWgXbvLcT6W09lCBo5aD9PdE8WSWH7Y+sfDj4c7vEHxF/Zi/Ys0nXf2T 4fEljZ3vinWvjh8S/E/w78YfHrxfpWi28l9DqvjfXPhsfijrVlo9k91q8NjY30mlw3V/GtufE7j4 w23xG1PU/hJonwa8MeEr3xxrMmr/ABB8BfAL4Vnw14z+I/xP0iK/TSNa8WaN4d01da8QPpD6nrDW ujXFvL/ZV9rfiK+aGO41KZm/mnDcQYHgHhKrk7yStmWfZ9l9Ou8b9XlVjUq4lxfs+dpq6bfM7bdr n9F1vD7ib6UPjbmHHk+N8l4V8P8Aw44xnlMMmxWaRy7HZbl+SVYVIVsuwN1CMsS6UouftPdXuqUr NvM+GsC6b8Lv2q9B1mZprG9/YS/aNvfFujXAhutAGuaX8PNQu/Aes2TSrJaTajDvsNQ8Pai5bUIt SkbZcNJuryW/0BPD1hp8Gq3c7aumn2x1No9jQRTQwLEYUCphEaVlWBvvSZPzO1dz8T9Ll+GPwr1X 9m2aDRIfj78d9Q8Cal8UvClh4g0ee++CPwb8C+KbzV9N8O+NZ47/AOzv8SPivqp1LTdQ8C3119u0 Dwa/h7+24bOaSaxtz4RfCz4m/EzxvdeCfC2i2XivxdBp6eIvEr+I75fDfgD4V+E0ngjPjf4qeK79 rePQvCswljj0vRY/tHirxXfXNjY+EtB1nU7qzs5vq/DLKMdkPCc6+axeFo4yriMZNV4qnDD0pxhN RcnK8WuW9klu00kj+e/prcY5V4n+PjocDU3nTynKcr4aji8v/wBrlmuPws6kKtSChFSqTm6kYSdu Zyi/ekrteTht5UkKQ6l4pYGUNNCP9ZIiSiRZPs5CrMq/MvmKflqk9uIwX82NY5NsqOkpVVLuykyF Dtg8wL/H95j+93H5a/RWH9mD4MXupDQU1P8AaJ/a+8SaXBPqvjPSP2eNDm+Dvwn8DIlvKFEPjbwt Pb/ExdNuiLtdKj8d+FdEvNak065ZLfaLfz/Ctd/Ze+B9imleP9P/AGoviFofwH1SK8Wf4U3Pgq91 P9o7SvF2mXdza6v4Og8eeIYrDw4PCWmmBFuPEGseK7Hx/Zyvd2Nr4ce6sYoG7Yce8L06MsOsyoRh TVRvEOElTmk4tRpVH7tV3dlGLbbWiPy7D/RY8b69TL6WF4NxVfFY+rh/+EuFSnPMcFDESvGrmOFj J1MHRndSU60YRSak2o3PkyQoFEYOUYB2XoI1Zv3TAN+8TzCVH7xmaPO5/lArKuVMihoxuO4JkAyC NiSRIhTb5yqFbzfK+aNmVm+Vttep/tGeAvh78J9d+CNz8Brz4m+KF+Mfw113xG/wv8d69eeLfE2l +IJviF4Z8GfBp9D1y8nlvzZfGCy16O70zR70Wwt0uVZUVYd1e16J8Ff2U/hlrVn8NP2jLz4o/HT4 wahe6HpPjTxD8Ofil4x+Enw4+GfinxLJbwy+Ffh3pvhCCZfG0vhGPU7VtY1jxhb6H9s1yzvtJiku LOLz63xHFWVYDDYbG4vE+yweN9nDBy19tWdRJqPKk5Qslquz3Z8tkHgN4l8XcR8S8L5Bkjx+a8JP ET4gjTqwVDA08NL2dS+Ik1Tk3O6ik3dp27r4oKvIC758xpXSGT70R2ytGC8n3VbAG2TbtbA2p1qm 48vfu8za8ZeWQKArNtO07gNu3zdkbKvzfMWzX13a/sseH/gdr/xL1/8Aa8sfiX4y+HPg/wCI+v8A ws/Z++HWjeNPEPwp+IHxx06x8Walpx+LHizWtAgOu6P4U8P+Ff7Ls7BraO60zxJ4/wBN8Q6ZFPMs H2mbw39oDwP4R+FX7R/xv+F/w5HiWHwX4C8R6P4dj0jxZ4k1HxlrHg/x3Z2U8fxI8Cjxbq2NW8Sa V4Y8Qquj2OtX0cUlxbjdtVZK6sNmuCzHFSwVDFe2nQhDEYj2cW1SjU5ZU4Tqc9lNrVxSb0bdtj5v P/DTjDhbh7Lc8zzK5Zfl2a4/HYXL62InGNbFPAVIU68oUZRU1QhN29so8km1yt2Z5JcSspjiiK70 kG9DIVIUpkMsIPmSDcVzJ91cDo2K6DwlfHTtaS3uAjWupodOvW2rEii4GELCQNhI9+4lsofvLzXp Hwc+Cmg/Erw3q/xQ+LfxJ8S/CX4E2/iq++G3gmTwB4e0fxF8RPi94+0W2stT8axaFb61f6bY+H/A ngGx1bw8viPxNNfWt9d6h4o0e18O2usNbax/Zv0Jcfs/f8E9pPD66tp3xu/aU8E6t4Z1q0tntrS+ HjHVPiqk8FrLeWS6f4v1bS9L+HsWkxMJJvE1hdGe4Er2+jLfX9r5K+FiuLeHcqxjwWYZnCjiYqc3 QcXOSpNJ03Vat71top38rtH6RwZ9Gbxm4/4Zo8XcJ8G47G5HjMXSwGFxklGMMVVlOFOVTD+0lT56 cajfPVbjTgk23ZM+Fdd0SbQdRuLWVCUgkEkF07MqzxCVXUeU/wAoZk+bcqqqqCv3q5yWbBjVFXBV pUCOxDgsT82X5OflHP8AOv2mj/Zf/YN+Pel2nhf4T/GD4pfBT4kahHa2vhzWfiN488Q/FPwRf67N JHDpDeMNP8cG1Hhzw1d6i1tBquo+E7fV9S8P6dLc6hBaPb2cjr+T3iP4cT+GNa8TeFPF2pQ+F/HP gnxDqnhTxb4evLqO+Sx1/S5A7G2vIXmkm07VLCew1rTZJFSSTTdVsmaNW3Rx+jkOe5NxJGriMmx9 GrSoS5a0WrVYSvHVRura6L/hj5vxW8E/EjwZxeCwPiBkNfJ6uNgp4SdWKlh8XTcU706ilyylBuzc XrrZnmXnF90zfKCFQQ4kYAoc7id2Q2fl2lvu/U4gluJFYLGqMNrSM7yFjuJVtpjctGVPP3lP/fVT anbLYAtDqFvfOWDyG0adY1JUAfLNFHnkbWZT94fL8prnjc+a5Ezg4cElY12qcEjJHzdcfwlen4e/ DBwc71asuVfBPZT+HWV/W34dD8h53G1lyJ/Et7y9299ZedttTcW8E0LpIyiTBEasy8EAEOgXasIw D80PltzjdWBPKYmZt6f63zA7M8jqykKPLklZpFHmK33W+7071Xnu5WkDKy7h8kjxoojMI5BUkq4f O3tz6YrN1GZFC4RzkZlVWUlBjcC/zbT+8Zm+Xd8uf4vlo+rxqVfaSg0oK0bv4o79Xu/87Aq3LFq3 M39rvpH+th2rahNNceZJK93PJn97O7yOwAwXcudzNj+9u/rXMvKWKfxKCc4CKWJPJYAcH/d/Crls xmvLCN5F8q4nhhwCwkEckyI4HH39pbv+dd/cfDDVEn8zTCmoW0mZEiJKXirlciVMbN2WXbtk3yKG ZdxVtvfCmklKK5IUrSkk3eVrf5L/AD6GLbm25SsvtPr0tb9enkcFb2DTFAiZYEOEJLFgxJaQlfuF R1LfK2MY+Rmr+zj/AINp/wDgnwuj2Xib9vj4i6Ui3Wp/218PfgDaXEtncS2dvFIdP8cePTB5C6lp eq3EQufC+jzNcLY6p4d13UriOGRvLmj/AJ5/2Dv2AvjF+2j8efDnwd8DaBqllahl1vx54uubO6n8 N+BfBlpIG1PW9avreKa1tJbm3ilh021aRb3VLiNrPT7e4vI2hr/Ru+GIk+AngXwJ8JB8J7rQfAvw 2+HemaNY674Ali1/wPoVhoNtb2Vh4X0fR5Ht/iNql0tuDIs0Pg9oWWJvMm8wKH5Z4lVasJwvCMU9 dXHW38ullrfma1frftoYOtWp80Pq6n9nDucFXaio++uaST5tko3k/wCW59MmFcnDHBB+U4Kk8AMR jdnAOPm/i+bjaKmhuJ7Qj7Ndz2zDGDFLJGxK5I5RlZv9rdvXH8NcRovxF8Ga7dWWm2Wv6fFrmoae NWtvDOpTLo/is6YztGt9N4W1Y2niC2tiylfOuNNhj3AruDV2Pmrx3BIHBU4J+6CQerZ7YX8quLhJ aNyjLXmi0vedpP4VKS8199rmM6VWg0qtGrTWrXMpwWtryUmrSTv0trc77RPFixzTRazBFLHfRNa3 Op28SWmppHIrQ+Y13arDcMY4nZFmWT7RGD5kcisu6vZ9Ps7e2srKOwuLiWyitykbTXEl7JOkhDRv Nd3jTXczREsVaSYsd7CTfgBflzzBnGCCcgcgZwcEgE4IzjDJ6/3a90+G99JeaLLbyOCLK4KRHcGK QyKWWMkMy4Vldl57t0qlFXvzOT20k/hv+f3GDnZ7yaurX02sl+en43O7gjmAk8wxNmXMflqVAQKu C4Yuok3Zz5aqo67d2a4r4g/Dr4dfFDRG8I/FH4f+EviV4XvJ4pbjw5468J6H408PSzxKxjnuNG8Q WGpaczxjeqyNa5j3/K3Nd+pyDznkjPT8sUpGSOTgdgSOfcg5P0qyfPr3Pki1/Yc/ZY0/xZpPjDT/ AIQeHbSbQGjl0bwlY3OqWXwt067gZTaarb/CC31CH4XJren4zputt4SOr6bl1sb23Ej7vQ/2i/hd f/G74FfFb4RaN4lfwfq3xC8E6/4Z0fxfFaxalL4Z1XV7GW30/XlsrpJo7kabeyLceTIrR7Y9pVV+ 77iUDAD5dufmGAwYc4GT746c9qgaCQrLsmZZJCSHc+csRxtBjif5VRtoZo/u7i2Kx9lGClyx+K11 vF7LZ37JmqrTdSFSU5SnTceRv7HLy2t2S/le/mj+ZX9rj/glF8P/ANpv4h+Lfiv+1D+wz4km+JUH hu3vfG37U/7IXx916y1nxnNodmI0j8Hfsz6rrHiDWNU1NrdMafYXVtf6xfTosf2uXzPLP41/Ez/g i74J0UeGD8GP27NZ+DWp+NkuH8G/BL/gop8LZvg/8XfGV1bsFFpo322w8IXVykTt5El2NImCB4zM 8KEO39/aRXUSKDLHOwQrnYYA3QqQkYdQwYD6KWxVS9s7a9imgvdPguoJ7ea1niuIo5YpLe5jMNzC wcMwhmieSGZdv7yN2Vlrwsz4TyHPFKWY5Xha9SXxTnSjztuy+JKLvvZ76Lo7P9j4C+kH4w+GdSiu C+Pc9yejQ5XSwNHH1vqdoSpy5PYVJTjGGjjyxSspS2dmv5Kv2L/2RP2if2MP2bvAPgD9pTRvAuk+ MPiF/wAFcf2LvFvgNPh54x0vxlpvi3wVpfiX4WWd14ls10y4mubKG1fRtRm1CC7Bks7WBbuYrbSw s39dKMG6Y6A+pwRxyOOmB2/nXyl8Mv2Hv2PPgx45sfiZ8Jf2Zvgr8OviBph8Svp/jTwh8P8AQdE8 SWL+Mnml8V/Y9Vs7OG7gPiKW4nfVmjkX7c08jT72kYV9VQ5Y7uANuAMZ+bJydx+bGSeD977x5r1c uy3C5XgcPgcHCNPC4aChQpJ3UIKXMkm22+XmfL1t8VtLfnvG/GvEHiFxVm/GPFOLjjuIeIMUsdme KjGyxGI9lRoSqS3SbVOD0trv52KKKK7j5kKKKKAGMuecnjtjP5f5/ShVB5KkEHjJ/l/9f/HDsnOM ceuf6UjdOM5z2/Hr7fXigmzutXbrovz0/BFW8uobK3eedgsaLwOTuYkBUAAYszsQq4XqefUcvo3h 9LXU7zxBfSz3uraiqxq0xCxaVp6KPs2nafbAt5USkNNeSNJJNcXslxL5i28kNrB1DxpM6yyIj+Uc xHJYq+SpJXoTgsPun8qlAOMkktzh2wB6joOme1Zyg3a8tFrsvL/LyNY1JQjJRly8/uztu1p7t7bX 0ffa2lxQwxzwCSM5yB3649gPw7d/n34xre+N7zQ/hHpdxcwWniWRtV8c6lYOom0vwZo89pJNaQ3Q lLabrfiLUp7G20r7Xp99Y6ho+n+JrdxFKkTr7dqd/baVp99qN67Ja6fZ3N7euiPK32a0gkmlaOMf fk2IfkVd0n8O7NcL8PdBntE1XxdrcKL4k8ZSW95dnZZzNp2iWnn/ANhaBBqFrBHNeadYR3F7qVst 5JcXFtea1qEYm8t1jXOp+9lFQdkpe/35Hulf+Ze6+6bavyo68FUp4RyxVRNVKVlhoRT5ZV5OPJPm vdOkv3qlfSUYp6S09AsrO10+ztbGzggs7Wzt47S3tbaJILe2tbeNY4oIIIlWOCCGEJGkcaqsKKqR jAU1+e/7akUvxe8ffs9fsvabMbiDxr8QtH+J3xQtbSVRd6X8L/hDfr4607VJo3QpcaTrfxR0DwH4 H1eJhtnsPEl1CUKOSv6GSuPIeQjbsR3IYll/dhj8xXarL/eXjPK/eXA+F/2fLBvit+0P8ev2iLtV m0nRNUufgB8Norqz+zapomn+A9RFr8UIkn2qbrRfFfjnSNM1vTLj5y1vYxOkixsN3LjoSqU6OFVk 8RWjGrZLWhC0prV6KSSpt6P953Pe4Wryy/FY3iCpKCllWDq1cK6kYyUs0xL+rYOCUr3qU3Vni46O zwsm1Hc+5IIrbT7SG3iSOCCCIRJEiqsUCJEAioAqqkahcAKCoHyj5Qa8N+AFtJd6R428aX+gHQte 8bfEXxndawpAD6lH4V1i6+H/AIa1ZzubeNQ8JeFtCuIG3bTDJH0yoHoHxR1ex0D4f+LNT1C9bTbU aNcWRvUyWs7jVMaVZXCH74dLy+gKn1C8Yq78O9CvPC/gTwb4e1G7Oo6joPhbQNI1C/barX19pulW 1le30mAuZb26hnuZJG+ZpJWZzlq63G9VWSUKMXyxutG4pRltbbmSttrr38SnUnTy7EymlKWNxdOn Od3Jz+rv6xKKb1kuarSlO903GD1aPluDwzHq37e8njiJ96+Ef2b9c8CXqggiK48V/EHwb4stDJz8 khttAlaPP3kDH3rlf2ibMy/tmfsX3oU7bbSvjXCzcEKbiL4fOgJ55k8ltvrjnbXVfCA6xJ+2L+2D JfQsNJtbT4BW2g3DEsjibwFqU2qxRbvlVTeCJZAv3pMFu1Q/Hq3839qX9km64LQ/8LQhAGT8s9r4 UJ5HH/LD9PxPj4qFSeBqucr/APCph5Rt/JDMaKit39mP4I/RcgrQocTYNp2jDgTMqTV72niuDcbV nbsnUrtOO8dvXC/buv7vwxZ/s1eMtIUrrNl+1d8CfB6TxhxLHovxD8c6d4a1+NWXkRzWEgjlVv3c ir82K83/AOCjPwp8ON8K5f2hJxdWus/D2LRrfX7azsFvYNa8Natq+naPPdaksZt7i3Phpr6PWrrV mkuo9P8ADun6tAmnyNNHcQfTX7ZeoeFvC/wF8UfEvxbbx3GnfBmfS/jLBG4BH9pfDS6XxLp8nPOY 7i0Uhwfx6V3Hx38CXHxb+AHxZ+G1rdR2N18SfhR428E2OoyrvXTrnxh4T1PQrXUGT+IWk2ox3BAY N+7wBxXvZXmNfJ81rY3DynFQoYapNRvadOXPCrTlFO01OMEpReqcYyWtmvk4KGKyzh6OJjbDUsyx mElUuoz9m6mErVIKUo2UYPEzqJtu3O1ofyr/ABI8Ja5Y2lt418B6nPZWWohRb6lpLtMbK4miW4tV ulVebSZf3ltJ5jRyR3P7yOMLury7Sf2ePEet258Y/FGONbO8ubHULLXNQMupW+h6jfy/Zrqa+sbW C3zaW9zE2uQ263Ey7rtoFm+UzN+uGpfDS31T9mT4WftH/Bjw7c+IfBl34Nj0T4oeDLeyeCS7/wCE JmvPBl54y0fSY0xaubjQLtdUsbeNbWWBrfUVhjlW5lm0fg9q/gzxt8PtOm8PNpev+F7lY0ttOuXi lksry1CpcaHdKm2O4gt2UrardRySfN8zND5ca/stTiSOYZRg8xwNKNeDUZtQTdaEYRhP2NVO/Kmm pRUoqU09ve1+R4gyuhSzXNsui3Cjh8VXw8OdqTlPD1XSldx0abhZSjK19U2j+DH9vfSvin8JP2jf iTdXmstL4i1K7SaTxjorGN5LO53TRQ2d/AIY3gV1jhuLeFppY2P2OS6aORmrjPhB+0/8ObT4afFv 4Z/H3TvEfikfFGPQ9SuNTE8U8Oja34IM7+GNbtIZYlupNZkTWNXs5rr7XDa29uywXFrqDTQzWP8A Sp/wW3+Cfw58SfBjTpvDvhDSfC+v+FPEWnTjXbe0sLFZLbxBfxWVzJCYoY45LKHULy3urq1kWSO3 t4Zdqoqiv5uR+wj4k8W+GNX1K08QaavjHS7a0YeG4ZIr99QszFdzX2pWLWhjkudPWJbGSGeNmt5J JLq2ZWa1+T+uuE89ybirgvL8TjcP9RxEqdPCVHQpxhWg8NytNOCUk1KKbS1k930PzTF4arhcRUox bcEotRn9rmcW3Gz1S2fT7j9Af2bPF3hr406B4B0Gxsr280q51AW3h9ZtRTTtKt7+zvGBl1yw3zLD d28Kx7ZofMinjSOFYZJo5Libuv8Agrx4W8NJ4i+BmkXuna3eeDy83hXxppVuVjh0zw4beQrqFqv2 WSM3/mww6hp99+5VZoY47iN7Np5l80/ZE+BPjHw78HND8VeEPC962r2OpX0eq2d3p0ltqVrrPhbV LrUY9S0xbtZLO80vVrJrWaGSO3aOFZfsu7dDX3z+1Ktz+0/8Mb3wd4Y1rQPB/wAXdJ8N6vfWNz46 s4bIm1t/D2oeE9b0uddV3LdBk1iSGx1SRWsbO3LXCxrPHDNH/M0cLDBeIsPZVJ1aFLGVnGvVUlNc 8lyuUX72nNv+d9PssQ4VMkw1P2S5+VXUdE2uRq+t1tsunXofjZ+zr8MvA/wu/aZ/ZK8J+FbC61jw 9rPxL8ReOPCGteIINPsPEd1faN8J/ii+k+HvEhsb3UILiCO4d7yzuNPuIlmZPJuEWSaBV8j0o6n4 6tzeXupaTpms63Jd6hqN7q7XFjYDULy4kvL5JDb215NDI11LNHDD5LKjbYyV618i/ETXfjT8HviZ 4J1gXemXGo/s86voHiGGHwXrCajpOnw2GoSC9Wy1ON53gttdsf7R0y9hWR45vtjK0RCw+X+hPxhj 0Gbxnb/EzwWLVvhP+0XpY+NnwwvbJ4n0u0h8Yzy3vjfwFbSQ7Y1ufhT8RD4r+G99CzfaFl8LedJl phX8r/TU4Wzehm2ScURU8dlz5Eq8YylBOLi3TlZbqzvLbVdVp/sH+yU474dw+ZeInh1mOLoZbmvE uUxeAre0hCdapGk6cqcJ1G4upT5rxVr2to0nb5M/b7j8fWf7bfxo1Xwlr2oeH1vNQ8B/EX4Wavpl 1JYlfCeu6OL/AOHPiHT9csWhv9E1G48MyyG2hiW6sJbWaa2uHaGXB63SP2p/2yvEvhu98O/F39qD 4m6RoV3p8em3iaH4b8A6brUluiSoHbxjp/hjTvEV3aW6yxJdNZ6tpuo3T36sb0GMu33J4j8AfCv9 tH4f+G/D+oa7o/wi/aM+G3hvT/CXw/8AiC9hdX+g+MfBelwJZWPww+ImhWE0Vxq3h6zsV+y+EfFE Ulvq/gYRWq3urS6SLy3uPEL39g79q9rZtK8X+J/2QtN8MWotki8Ra1+074A8QyaNodqT9q1SPwl4 d1Kw1jXpLQBZY9KBk1a5cxaZdS3ckUfkfbeH/iD4W8S8FZTPOcPgqWZ5NhaVHEQrxtVapJSUopNN 25LWnpfZq9n/ACT49fR+8evDPxZ4syjL8q4kxWW5/nOOxeAxuUPFVMLmOExVZ1KU6tTDv2c58slG p7RKzdlo2l+bmn+KvAfw/vtSMsHiDxlrV3dylJDpupT+I/EFzEyzzapqGpPqup37W0rSrYxXNzJd bZLWSFJVWNbiT9qfHSQ/AT4X6X+xx4P8UaZaeKPCFjY+KP2nteja6lvviT+0lLdWk2v+H08RZe41 rwn8Ob2W/wBK8D2F0LDTU01FnuLObUobWaP1P9hDw38Cfgt8So9S8G2PhHxZ8OrPxJ4U0j9pz9sX 9oDw5pkHhbxQ0N7Hc6Z8Gvgz4W122Gk+B7bxXfymy8MeHdPtB8QNenvI4dd1vWNMksbOHz/wn4o0 HXvjrrMnxm0mG38R2fxn1vXPHnhrQ/DQlm8R6np/jKDXvE2ma9qGpQ3lvBpE+k6fqUfk2MdjeWdq WkhuI5445k/DfGrj6jn+XYPAZAqmEynEZksNTnShKipYaHslVk7RipU7Ss2k03GVm0rn9f8A0F/o /V+EuPOI+KeOcLl+ZcV8NcJwzjLeH3Wo43G4PH4xVnh3WoqpJRxtN4b95CSU6Lr029ZaYX7RmkfE O3+Jv7NX7D/wc1yfwndeB/Fnw0vvjPd+H7++0G48e/tP339ofFXx/rPxC8RwXMl5rHhP4Y/BXQvD sPg/S/s1tYw6t421oXYkuHsbi18S+KN5ZfGH43/EnUfhzHe3tt8V/jj4+1DwRC9w8Vrq1p428bar e6LcR6UYWTS59S+3pqDQxtIluLpbZUYw+ZJ9yeJvhRZw/F79o3x38KPiIf2nv2lf2hJfFuq/DW28 MaLeaJovwM+El54d0F/G3jTxJ9qeWO6+IN3pPhDw/wCC9HvrhzaeHdD0K+je2+0+MLaQfIv7H134 ct/j5+z54nvxBpekeEfGfhvxLqepEXF7bRrot4l9Fq17p888kdxb6eUjkuLO1WGOaGDbt3NIz/mf HWPyysuFMjwM6VPK8LLDU8Tj4U4qlVqyjRjVh7SKUZOMbSm227vVpn9JfRY4Q44yjEfSD8U+L8Li 63G2e4PNMdk3DeNrSeY0MBQlingMRHCOVTEYenUqqeHwlPlhz06XNFVErHj/AMV/iR4dH7bel+PN CfUPEngr4RftW/s7/C/4baL4WtoNU8TeL/hP+zF8UPC/h/wjD4S0Xz7X+09Y1rw/p7amlv5sNtd6 jb2/n3cUbG5T6Mg+B/xg1f8AaO+M/wAKfAOhL8R38AeMdd+Kvi3XdJvYLLwxoOjPex+NbPVPFHie awv49HvdMlvbXTb7T0a8ll1my1DT7L7YsMk0Xon7Ofw1/Zw/Zo0HxyfDOr+Fbc+AvCXiDT/F/wDw UL+OGj6/psdh8YvGmk3OlaD4Y+CXgnxPekaFqOiXGpzzaPF4cjh8dapZ2d34hOqI1jFOkfw1/a+0 Dw1+y3+1/wDDP9nfTNe0r4dTeOP2ffhp4u+Jviuyu9M+Jnx31j4n2nxg8QeOviD4iS+WPVtB0BZv h3oun/Dnw/FLGLSz1Dxbe6jLf3WuXPkfacZ0MFxBldGrhqdaOVcP4epiHi6MnRjialClGNOnht3J Tmopz95qKbV2kfzH9GnM+IPCXxBzbKs3x+Tf6/8AjDnOX5VPhnMKccZPLcHmuPjWx+YZ3yxfsK+H wc6zhhH7NTxEoQnOCk5HGeC/iJ4z+K/xX8fftQfGiO8+JS/Af4b+Pf2gtYsNWuAmk+IP+FZ6PeeI /CPgZWNvFbWWl+KdVtY9Ks4bbTYZLh5GkkjkupLiWT87dB8CfFv4ia5YeBPCSy/Er9or4reJNSjW O2uhqF5rvxA8TC4v9f8AFet6gFXT7Sy0U/afEPifULm6EGm6dp15NciOWNYm/Sn4Yax+zpdfA74/ fD742fELxr4J0z4qj4UaWJvhrpkOp+PZ/DvgHxdqPifxF4S0KO7tdQ02xPjnSb2Pw8NX1GwuNM02 ZN2o29zbL9lf7B8O/FLwBYfAzTfhVc23wu/4J76f8TfHfg3wF+zdpNv8P9G1P9pTxF8Fbi6Twz4+ Tw/rt1ZXHxV8SeIviDqFzZaBrOv63rmpL4wuNYuXuzeaPLe29x5nhfneGw3D9V0cNicwzbH4jE4i rCClKpSVKyprEVZ8z5Fuk5Xak3bofU/Tw8Ks5z7xay7CZhjMr4P8MODctyTJsDia0sJhcNj545wq 4+tk+Bw8YurOpZ03FU1GNSEYvSXMvhT4t/DrwS/iHTvgZ8PviJolp4S/Zh8EaH8NfAt8L67v9J8d T+VeeI/iLrxuYdIspJfE17411K/0N777C4vtM0LSUMsiWMLSctqviE/stfCz4SeOF8D+Bvib8bfj Zc61q/gzwr8VrGfV/Dvwx+AmheJdU8I3fiWPRbCbQbvVfGnxF+Imk+M/C+nNf3Qj0vRNO0zU7a3k e6aGFn7QVt4Q0346/Erw58J5byz8EeF9etPB3gjUby4nj1xbDTbC3ivL3V7yOSKeXUptXvNTuL+S f9/amNbOPyYbVIl7Lxr8FvH2uft423xc+Kng7xNYfsv/ALMHgD9mrxfDr/ijT7tPCnxF/wCEP+Cn w98SaN8J/Bup3Komu3Pxk+Lsviu+1T7BNPNayeIJNQucLPivnuD44TNOK+J82z9YWpSyqliKsY1Z e77WTdpJ1OZ1I04xajF2dnfV6P8AavpGV888PPAXwM4A8HKeeYTEcdYrIsuwrwcJ0cdTwlGjQlOc 44eSeErY2VSNXFVYvljNyjzqMos8o/aJ8IaZ8Mvjb+0L8P8Awos1rofgH4sfEDwl4Zt7WWaWaDS9 N1i806wtLWdWaaRVi228LK3mMp2ruPyN4X+21Ncj9tf9qHMhkaXxR4Ei1ByYnifXYPhR4B/tOS18 vcqnyJbJJldt/nRybm3Hav1r4DsZbjxB45/an+J7Sar8PPgNdR/GD4oX93G88fj/AOKE+sW8vwz+ FEKD5r/VviV8R7vw1pGt6dbOl5a+E7vXdZVY4NPkmj/LS/1zXvFms+I/Gni2Z7nxX458Qa14x8QM ztI8F/rV89ylgzsWZ00PTU0/RIdzMy2+mxqzfLX2HgxldapiM8zenGGDweY41xwlOpeEHThNy5oQ aSat8KultZuyt/Nf7SjjPBVsH4R+FtTF0844p4N4foVeJcfGcatanjq+EoQjRq1XKpKNXmXNNNtr kaaV0VryUBZlTIwcbZOCNrEEcDowHmD/AHv4Wrn57lWMhTdEvBLKc7znBBH1I7Y59s1Zu7kt8vnB hucRsAMlHdpAGx1Zd23/AHdnP3TWTO6xsqSHcvJ2oOpYbRnHuR+Vfu8IzcpOcvaRTUVeNtmtoxsu nNvZ306H+TzbaaSs+397Tm9eZ2b5ey06kEk8qKSpXapK/M3zFmBIwCTk49Bz9azzM2xJGZtoldIw T83mADesmByqg7/l/h77qe6+ZvL74hHGRuyAFclmBY9jtVl/H3qxpemXurTx2VhbTTXRHnqEQspM rF2djjaqLG67m+6mP9iuilSbi787UpcsV0ck9YfD7vRJ+voZWk2n7vLH3p/E5W087bvT0IrNQJ4n UMJLZo54ZMEkMkimNioBbPmbflZe/r194+HumfEjx14m0Dwn4aOr654i8QavY6LoWk6bbtc39/qG pzLbW1na21rBJNdLJIwaZlXdawo043xxy7ZdN+EdydIiltopbnXI5HnnS2EzGdZHwbaGKRpJrq5Z WP2dVZmkkAWP5mXP9lP/AARg/wCCRvxH/Z38N6L+198QrfRfDv7QOuaLKnwt+HPxF0CfVdH8A+GN el02dvGOu2do1n4o0b4h32n21zb+H2sdU09tJ02+u5LqGa11hlfmxGKco/V6cGmvcqyV/cemlkrP e34nVQowqyUXVUIVLcvMnySTcWlN20V1e69d9D9VP+CWH7AumfsE/s82Wh6tLc6n8bviNBY6/wDG PxBNcLILbU5o457XwPpaRBfI0PwnE0VjcxyXN42pa5BqWtRyWsN9Hp9r+mCxtkhm4+UbFA+UjG0o xYN8pwzbj82O6kLXisnxa1Dw1evZfEXwN4h8K2TXl/HZeKtJUeLPCUOk2MSyS+IPE+s6TEtn4Ls5 m8zy7XXJJLiNY2ZpH3V6pofiDRPEun2ut+H9WsNZ0q/ghuLC/wBPuori0ubaRQ0U8UkR+aKQYdWb 7397bis6cqa5KVuWSdoycV7zst9mt9++xviMvxGFipSg3SvzRrUZe2hJrlso1IOSbXRdF8S3M3xD 4C8I+K47qPxDoGn6k17bi1urqSD7PqM1qriRLYatZSW+qRwK6mR4o7yNGY7vRa5WL4davoE00vgv xvrmjWq2MFjpnhnWBD4h8F6THCCgntdKYafrEl3Io3SSXHiKRW/ugfLXrI55LZ46KeMfgef89qfW kqUZq0uV7e9Bcjt/iXvNP1W7HTzHGwpqDnOpTXw0q/LVgtldU6kWkl5WfmeYxax4/wBLe6GteFYd b0u1tbYW2qeFr1ZNa1a7LxrO3/CJ3sdvDpVvGWeT/kZtQby1Pys1fR/wm8U6FNY6jBNefYtRjnQ3 thfwS2U9mAgaNJ5pl+xPJmRvltbu4XcH+bOVGN4c8L3mv3CsY3h09GInvGUhSoI3xwk8PI33fl3b c7myq17hJoekTWUOm3GmWd1ZW6qsVvdQx3MChD8rGO4R4vM3MWDbeGLY5xUxhODbTlKKfrp7ujem vXrfbcyqYnD1GlVpKm2rL2LcbPu4zU1/isorsbavGyK6OrJIFKMrBlcNjaVbO1gwIxt9ep4rPvNc 0nT5Vgvb+3tpmUOI5WIcqcYOADx8w/Osf/hGYbeSebTb/U9MnnaLzWiuWu7cRwgKkVpp+pi70+wj 2KF/0G1t/r65euafefYdWuL3T9M1Xy7S7FnJHF5V5DBHaTMr3El1JMssodU+W2WEbvmVVHyjRua6 J+a/4f8AQx5INNxmpLt8L1tpdc2uvqdPb+ItEu547a21O2lnlbZHEjEu7FWbaoK8napb8Pwq1Dqu nXF1JZQXcMl1EXEkCk+YhQkPlSBypBDeh75rz7wEujvoml3c9gltforMLi6tGhkMm5kBhlkC+ZtD Mu5f4e461zo8zTtZv/EcLbo7PxHLaXuMnNlclOFwepZmG7pt/Vxbau1Z9jNpp2Z7Pe6hZadGst9c xW0bvsR5TgM+0vtGAcnarN+BqaOWOaNZoSskUihkdTw6nuOOnXnivJfG0p1i5vY4nLWWg6eLiRkI aOW8upI4kQsBw8SSN8u4dG/2q9J0D/kC6b/16RfyqhGiFKjIDZBPAAyc+5Hbnue31p4U5ByPcbcd sdM8H86eCDyKKNN7Wb/q39MmK5dE9ErW/X/h/k9gooooKCiiigAooooARhkEf560nQ9RgDkd/XOB /nrTqhlYRo8hBJAOMfiAOvp/Olrfpa3zv/kBx+t2X9t3tppjhG020mt9T1NT9nYTS2lzHdafbGJ5 POgZbuODUluljKmO0a3ZlaZVbrlQfKSwODnkjJGMY9MHg8f/AFqrWlqsMTeaFklkbfPJgbt2cjOB ubBwAv3c/dG2p8AAgHaMrj/ab5tynORjGMf/AF8UuWKk2m1f3b9lt99r6936F1JudOMLXjDlcI7S cm4ybbfVNW3u0ktbs8h+PPj/AFD4afC3xZ4n0TTIdd8UQaZPZ+D/AA3LfQWEnirxZfI9v4e8L2dx dSwxNf65qDx2VlH5m+WeRVX5trVb+CPw2svhD8LPBPw5stS1HWY/Cvh7TtLk1rV5Fl1jWrqC2QXO q6vMHdp9TvpN895M7SNNKzO0jtk1xXxCsV8e/Fv4eeBLlbC+0TwgIfip4l0rULG5aY3em381t8Ot V0bUIZVhjvNK8WaVd3t5bzBla0EJZfmUH6HQKF2jlUX5H6khRg9uCuQMHsWPrjmglLEzqNq8IKFP +6pcs5NebainZ7w7np163scpw+Bg3F4qs8di1CV+bkToYaM1Ze9RXt5pXaaxF1rY8q+K0D6ta+F/ CkulxaxpPinxbpel+JbaQjFvoUFtf6pJqABxlbbU9O0pHYL8puF5BavUJCIreQnGEhAyoztYDcOo xgf3u+OOlcJexR6t8SNKeC7kR/CXhy+/tGx/5ZzDxdd2X9m3B45ltz4Z1BV4wvnsP4s1390g8m4G OPJkJOMcFW4yDwAB9ePTGNYO6q3VubVdbWSSu91azty6a9zmqu0MBRTfLF+1qRsvinNK1u8qcKd+ Zu8bJLqfM37PGqab4x1D4zeOrYg3kvxc8ZeB9QmI+Zj8N9Wu/DMC9PmFukcir/u/LWH8cbcv8ff2 Ybv7wh1fxpDux1+0abprBs9s+SeO591Ndj+zV4Qt/Cvg/wAYT2rI9t4y+LPxL+INtKmCkkHjPxLd 6zFKCCd3mLMvzc7t3yis/wCMenzXfxZ/Z+u4Ld5/sfirWfOliTc0EEmksJJXwQqwBkiSRtrZcx42 7jnza0E8DSjB3UsThqiv5YmlNvZb6/Pc+tyzEKjxVjXOTUKOV51hISdrRisjxmFpw33WiWnnc6/9 oz4U2nxv+B3xQ+E983l23j/wV4g8LTSEcRw6zp8tpK5z/Dsc59MV6L4b1TS/EXhjSdT0i4hv9H1D TbWXT7yFg8VzavCvkzRvnaVZMMhIwxwM8YrYvg8lneImQZLSdEJwCGaJwjKS2AdxA9iCDXzh+xz4 U8S+Af2Y/gn4L8YXMl/4q8LfD3wzofiOdmUzPrOm6fFa6mZ8PJ+/WdJBJG20qwKg7q7tsRJJPmqU XN82il7NwSpx7/xZOV1Z2lqfOU5Sq5JO9ayweZUpUKL3vjKMvb1Vrb3VgqEVsry8zzz9jy3m0jTf jx8Hn8Lw+HPAnwk+OPjPwF8OtHlhAg1HwDfaD4U8WHUirqDcwah4i8X+KbcyFWSfyHiLNsYL+Ef7 XnhDxl+xZ+1Zb2nwL0HxHqHwt+NuneMfGt94T00216nh7xB4Pu77VPGz+FNHtrmTVZbTQfDosfF1 xHa6f+7tdTXSdNjumtfJX9/PD9g3gn9sT4hXOv8Ai6B7f42/CbwFH8OfBBLJLFc/BfWvGUnxK8QR xAeWTPF8VfAFrc3HzSSC3topG2wRIPk3/goJpVp4Sh8G/H61/sbTNS+APxP0LxZ4n8W6yJjFoHwL 1+SytPj01rbqJPtVzqfgWE2ccMylZJE/5Z/ersybPcRkUfaQTqYV4hUsfhJ3UKmFjU1jFu6hJU2p U5JXirWWrZ77y7B5xxBQpYiMqks3yuMsHWSUV/aWKwUIxxEn7iqKGYKcazatKUZ7yPyg/aasrL47 fDbwjp9lPo+tJ4mma18VabfQw3N1Bp0zC0vb1jai48ifSdSmtnuljzarcKsPnN5lfz8fGv4DftFf A/xp4ciXwDd+NPh9FeauuhW+iyTeVr/hu5WAap4P1W8tVb7Bcrb2q6hptreGD7RI7LYrNItwsf8A QJ/wUj/4JlePtXS8/ac/Yu8ReKdD8eWNi+o+KfhPo+pP/ZWuWt00d7eaz4LsppFt7bVGmCX2qaLd FrfUPLk1C2urVrWPTbj8aNT/AGvfjz4c+F0N/qT3T+JdI1ltC8Q6T4l0SXU9F1nXLKNPt0GsaPv0 3VvCGrwxRx+TE1xcQyeVJcLdRx3Ecbf2X4cY+licqw88hxeDx2Gk6tLF5fiZuliME6kVK7stdFaF SLtq1e9z8QzahVw2MxFPG0qsHh5qPtoRlOlUimlrKy5OWWiTta6udT+zj+2F+y94b0q2+Fw03xL4 FvJtaS88FWXiK119LnTtbldbHVPCOqSadZ3lxapYvB5cd5IqrbM3+nNbssm3y69+MHgT4v8Aivxr 4CvB4o8FePPD062vhfxDpfjjUl13xbcTXsf2W/uvE981ro8tldXn2dYbq61RbOWSWOWaZYFaRfnv xN+11pfxC07UdN+I/wAA/CWjNqxnsdX8W6H4c1K2tmsL6R5f7TFxHKt3pOtYnb7RfQ3F4rFVuvJP meSvNt8O/h78Jz4K+Jd18Q9E+K/wkt9Z0W4sfFvgjUp9M+JXwv1awvbfUItM8XaNrNvcN4g8PWqW 0nk2Mdnb/wBpNDCrahp5Zmr6LE8IZV9Zr5g8FVpZjVjz06VOp7aLnFJt+0UnG0ny+62m09rGMMwr VKMaVOS9lBpT5rpwjJxS30bdntd9N9vyZ/ach17Wviz4tuPE1n4g0H4hQ6/Louuabr+mW9heanBD Gq2er/aI5mtS0kURW6uJJltbhZbW6s5rhZpnSX4A/tT+Pfgha3Hwj1/wp4F+LXwSv/Etz4huPhX8 VEuBpfh7xRd2sVjqGveAvG2nWWo618Pta1OC1tV1q+8NqI9TjiLXEksbrIn9YviD9pT9g347aJp9 l8XPhlomo6Zr2lW1pe+OfEmlQaHrD2UYjgt7mx1Lw/B4guLbWPOX7VZ2+oWvlxqGE00kfyr86eP/ APglr+wx+0h4K1/wJ8AP2htK0f4mLK+p/DAeNRatqR1HUR558O+ItatV02G+0fUJHVYWt9DjuNJ8 6S887UI2jsovmOJJ8NcUZTSyHjHIa8MJGapqbw0qlKE4pLnpyUW1zP4m7K+rvsfR8N57n3COb0M+ 4WzzE5PmWGbqYbGYOtKhiKdR8rvz0rNpSdkm9Vo7bH5G6b8Yf2XPHWlSa3dfAr9oX4ZWFtevpqP8 E/iJ4I+L2j3d+sUsv2SJ/i/4w8E+IoZZBC7WsH9l/bLiFG2w7srXoHgj4sfDTxprFt4Z+H/7Pnj/ AMf6nb26w2GrftU/Fy18NeF/C6I7FbuT4eeA9Y8XWfiae4dc/wDCOa3BbaTceQVmuNqtXjP7Yn7C v7R/7Cth4X8NfEjwclvqnlX93p3izwsup6/4a8U2t7HJcTXlpqek2klo01jEGtbKG6t7O8s1m3fa rpY23fG/w8/aE8YeCtbtdUfw3eajqlvMsl5I0pt11OKTygYbmKSym23EccCFNs3y7Wb5XkkVvyen 9GPwvnXqZrlVCVSnKXPDDQmvYKS5eWLjGPPZu+j0vpY/fsf9Mn6QeZZZDKMx49zarQp4eOGjXlOC xCjaMXJ4vlddt9W5NtNq6TP0T/aG8F+LviDFp8Xxw8ZXHjXSPC0B0zwH8PfCPh/Tvh98MfhxYX9t FHef8Kx8AeHZm0Dwxqcd+J5L3XbSOG/vpB9ujEk0hWvojwL8eNP+Mmmacn7T/gD49a18aV0zTfDG q/GX4EaB8HvHGm/HbQdFsSdG8SeO9I+KvjvwVceHPilotvaxJfapoNvqcevRrqE02oSXEsUc/wAU eMf2oNH+JNnb3B8LanouoC0jiku7142CzmFVQM8U0ahY5Q0at9nVtqhmbd07L9mvxLPqLeLU0/Vk sV0e2TWRNd3MsqRTxyIZ57OBktxGbcuyr5dwytnb5cn3W8/jbwh4ex+V4fL62U0KNPCaUfZQ1p25 OX4U3zWW711fz+Z8PfGbxB4H4hxPFHDXFeaYPO8xozoY/G/WJzni4V0udV+eUnUV7Nc9+VpPRn6P eNf2ivi54U16fxP+yf8AC3Rv2T/CMV9pWsavpXjNNC8U/F749W+n6fBous+Efib4i8P3Wu6V4C+G 2vaU2oP/AMK/8Fazr2my6xqEetXdvBdaYjV+dHxR+Pf7Cnhrxhrus3vw4/az8NRzXk+tz/AfRIfh NefDfRdYvXN6/gjTPitp3xHufFMXgkXUr2um6l/YUXiaz0oRxzaRBeQm3HmXxf8A2j/HniM3fhIe IdMs7afUItPv9d0y1uI9Sit5pktxcxtJO0e6GOYtMyrC2JNqrhvMXhPAv7NqWvxQs/DXxg1SbV/A GtQStoHi3RLtfsN40xa4sx4kl1FI2s5bpJI3kaN7hbdpPJW4l8tnb8C4k8PcjpYejThldCph8tcf ZUakGuWraHNUlZLWTV277rXU/a+C/pA+J+QZ1nmb1+PuIMDjuLMCqOZYunU+syxFGmmqVL985uNo zajFJqN3ZXueFfFH42fGT9sT4o+EJ7rRLHwL8FPhbdpB8OPhD4Oubu08B/DPw8byOU2lg8UKSat4 t1LZbyeJvGF7bf294i1FZdX1N1Z3VPpTwH8avDvwFk+I+m+PfCkvj74G/FbSvC9p8SPC0esnQfGO jeJvh9da5N8NviT8PtWuTBbXXifwnbeMvHNkuiarqGnaVr1pr9wl5M7QwlPR/jyfgj8IdJs9E8M6 xoujxQ28kGnaFpLW2tXN68drI6TRtZXSyRl0RhJJe3Em1WZvMZjtH5eeJvC3xT+NOqIdD8J63qlu 4kTS7DTbW6ex2Bl33Ml5cGOzkchkHm+b5aANHGw2uz8NXDUp4ehga2EpvC1sOqUoQhalCnonRUI7 6NNyduVxjK+iv8RhMdxJHP58aZPmmOhm2Bx/9rUc3xmL9pjnjlyzVWU5Wkm3FNRty68qVrn6WeC/ 28fgF4F1l7T9kXSPjlqnxr8T6TregeHfjF8d08J+E3+C6atprWd14m8CeFPhz4k8Zab4m8X20Mk0 mi6j4luNIh0e8itruGaOQF4ofgLoOv8AxK/bZ/ZzvtR1nxV8SPiLrXxm8O+P9f8AFPiXV73xd4z8 Q2fwZtrv4xstxrF+8+o6hbJB4GeVbZVZfJTy8ebtVvj34c/s3678LU/tfxBZIfFNxDvaU3CQ2ug2 hTdPbvey4jjupE3C4m2SRqhEMas0fmt9uf8ABP641i6+Jv7UnxW8KajcW2u/s8/ss6rq/hvU9Khm 1S/sfEHxJ+KfgD4O3FxpKxW7SC8i0r4g30aSRxhmtjNEqiNmWuSeFyrh3LMdRyzArB0aeGr4n9zF e1k+S7lTXvTbcklpd2S8me9HinxE8aPEPhOpx5xHieIMZiM6yfL/AG2Z4mX1LDw+t0lTpTguWjGL jzKUoxs3N3b1v734P+B/xH+Jnxpj8N6v4J+JPhi18XfELxh4h1rWrvwT4p0n+z9CtLrX/Ger363t 5plrDay/2Ppl39nvJJo445njk8xcV0cvx/8A2W/Fccd02jft3fEnwlY319d+BfC+sv8AAbQPC39h 6jdSSWU8vjZPi6fHeoQaxYPC51C60FdTW1lSeK2km2JX1T4C+P3x+i+Dv7TXjD4hQeKdN8J/D79l jx5q/wDwkeveFdZ8MW2q65qPiD4feDdP02x1TWHha91G+tfEmoTLY6bvubiNLqWPbAJ4j+BWs/Ge y8M6x4I+FGgTWsWpwWWheGtTurmMS2ekxQ2VrbiBFhmjMl7sxtb7sa7Y1XCNX5r4f8LZXmOBxuYY zLsRWeOx9WT+uN0pezvFzjyxlG8HNStzJ6JaI/uL6Y30hfEjgnjHhDgvhPibJMLHhvhbA0Z4jh+v DG0KdRwjTh+/mpqjiIUlFylRqQmne70SX3v8XPjP4i+MUXhfwhF4T8M/CL4FfDK/vNZ+HH7P/gu+ 1LXtIsfF8trcadc/Eb4heMNUsrPVPiX8T5NOur+1s9c1q3ml0GC/v7XTbqS1mllPz7r/AIW0DXGM 0losNw6lvtVs/lu7kcvNt2+e2c7t38VdJNE1jawbpnEyx8zJ8yzFwN0jqeSWj3SeYv3WH92smQyI ozG8at8sZiYSBu5JUcKHzu8zceu3y/lNfuWBw1DC0aGHwuX0qFGgrU6NP3Kad4a2Sttstb/Ntf5X Z/xBnnEua43OM6zjFZpmmMxE62KxuKqTxGIrSnK9RSq1G5Ny21b6roeR3/wz2cWmq9iR9piCxBCS Sr+V5m5s/wDjv8J6DC/4VncF1ZtUt/KjZXVbeKVtz71XIDxqv3Cc8c5r2l47cyLK5y6r2LMUIZtk JcbY5PMbczMI1PO3+GrFtZzzTgxZYSKdjEKBG5wdhXDNneFhQKr7WdWk+VWZfTjQ5FCMmlKa5lBP q5X16Xj2d7W7bfNydRPmlF8l93aNkrfF8PfVu63vqeVWXwu03zVnu5ri/WWYBomVYI1yDgttbLKh y2GXr0r2Tw54VtLMwWOn2UUALIjcxqt3G20rJ5s3lrIs0jOkcEbNIzfKse6vRfh/8LfFfxE8VaN4 U8FeH9V8V+JvENzbWWlaBodpNqGo6jfSSpCIYLSCPfiSWWKGaZpI7e13RyTSLHJ8v9v3/BK3/ghb 4M/Z+sfDvxu/aw0fRPGfxjlWz17QPhnME1bwp8MpZEjubOPVpJ4vK8Q+K9NVo1uljjj0fTL5J7O3 bWIbePUrle2nFShBxvF8zUv5vd0TXRrdpX8zehyKUZ11Jxna8YtPmso2UdUr3/Dbz8P/AOCK3/BF dvAj+FP2tP2uvCXleKLcW2v/AAY+DHiW1aR/C85khu9K+IPj7SLlP3HiWBli1Hw34b1KP7VoN01r rGsWem+INNt7e3/qQ1vwbpGtl7h1NreyDJu7YAO5P8UseVSU56Fvf1ryW1+EfiDwKwm+E3i6+0vR bSCwgtvhz4nMviHwfFYaXA5ksPD11LPBr/h/U9dudn9oa/qeqeKre0zNLDoMhbZWxp3xeGmSabpX xR0G5+HuuahPZ6faOLuXX/CWravdpqV01hoHieGwsJ7mOxstP86/vdb0Pw9bW7XEMMRnyzHkVaKm 4tWco3nKS05vdXKuZXfzS1vodk8vdRRqYSpGsoRSVCH8enZXipUndz91Xbp+0imvelFuwy9+F96r MbW9srpCpUi8R0dwTkAqEaHBPctu/wBnvXk+o/swafqeuX3iC2tB4c8S6o1idV8U+FtRn8P61q9t probPT9U1LTgtxe6fGFSNrCb9y0Y2su3e1fXFle29/aw3trcW95a3Cia3ubd4praeCT543glhlki lQqV2yxuytgMowavI27ORkMvODkHIy2Gwu7/AL5WrcKc+rVui6fD8NrW9VvokzChi8dhJyUak4N6 SS5uW3u6NNWtrbltb03Pj/T/AIX/ABd8MRudR1rR/iFYRyXdw32Kxi8N+KjCTCtlo2nWbLD4cu2t lE0kmravqtpLcF280+ZsVvUvDsHgiKeGDWTf6dq5ktYpLDxOh06MXt5HGRptrcS40fXbqNmWNho9 5qCKxKxM3y17kwHAweR2PXHbGDnHH+RVC+0+xvkjS8s4LkI4eLz4o5WikByJY3dWaGTJ+WRCsi4+ QrzUqk4W5Zfe9d15pdPtGs8XCsv9opKN3d1aNoS1srOCsmn5qMr/AGuhPEI0jSOFUREACRqqIiAD AAKDaOOPlJ6cVOuQeTye2c7uoGSOP0rio/Cj6TtXw5ql3pMccRig065J1LRt4ILyvbTOt9JKw34k /tONVYq3ktt21oxapqlu7LqmlHyQ5WK702f7YpgjiDSXN5DJFatZhnDbYYWvmVNvzMzYq02lZpu+ /V/Lf84/Mw9nH/l3OMoW93mio1PsvVJtf+Aye6WvTqMjvjg+vf8Aoap6hbtdWF9bRbRLc2dzBGzc LvlgeNdxA4XLAE9QOnSorG/s9Rt457OaOeOQMylWZWIRzGxKSJFKDlMHdGv/AAJSGa+p+70HB4BJ 7+px/wCg+vIqzFxa01TXlZfOJh+G9Mm0jRbOwujE00CMsjISYySxPylgDjHqv/18Ky8IiO38T20x ijj127nnieAtuQSRhVd9y7hIrAv8td5RgZz3xj8KAV+rv8rHm9l4P1C08ManpklxBPqmpuHnuGdh GfLlVogzldxPlg7jt+8fxrudKtpLPTrO1m2+bBAkT7TlSyjBKn0q/RQMKKKKACiiigAooooAKKKK AEIz3I+nFIyBiCc8dux+oxzTqKAGkKMk98ZOOuOBn/61Vp2WNHdmXYu52Z8ELgDL56oFU7mKjjHG Od1usDXxPJp13bW+wz3irZxRyDKMLglZwxAY4ktxNjj5WVaTvZ21aHFXlG+3NFy6O3MtvPY434f6 ZNLceJ/Fl4l9Hc+Jdene0tdRaKVtN0rR4odDs4tNnVFmXSdYGlnxJHE0jo02sTyLhZNtel8KOvOM seoHGAQv3QSCAdo5yaq6fYQadYWmn2kYS2sbaGzt03FilvbxrFDHuPLbY1C5fnHWpLy4jtrW6unJ 2W8Mlw4XhtlujTOFz1JSNsD2rOK5IczUVJ7v+Vf0/wAXvY2r1JV6zk2uVyiklbSEVGMY9NFFR31u nr25Tw2rXGreKdTuLWOKc6tFpMd0indeaXp1sLizZmJ2lYbnUL9Rt+X5m43V1N0xW0uWHeCfHcja r8fT9f51meH7A2GkWVoJzOYkZ2mZmJbz5ZblCxb5i224Ct7Ljjiuc+KPiGTwr8PPGPiCJGeXRvD+ pX0SJgNI9ravKRHuKLnIK/My4YfMy8UlaNNuWl5a6P8Au7f1+ZpFuti6MYq7c6VOMVbaLhCOnmk5 b2s/M89/ZYGo/wDDPXwkGseYNT/4QTw8b/zBtlN01lEZzJlVffvBLBu7e9d/4igB8ZeCrjYCY11l A+OVEi2XyjOFG7y/97C/L/FnrNF0y10fSdN0ywjjhtLO0tre3iVQoWGOIKq7QNoGOCq/yzWRr0Qb W/C8nA2Xd2nJyPmhQkLn+9tH5UlBewgpK1pUpW/lcXG/bfv632OpYr2maYrERTpwr/XmofyqrTqR t32nbb08ujuVxbTKg+URyPgjcCX3llbcDkbiWwCByAF2LivlT9kXxLrHibwr8XLjXI5optJ/aS+P fh+wWYNvOkaR8QNRstKaIsSRFJapG0JBKNGUb7o5+s5FyrqQSpUqSCAeVxgAkDPqT2/GvmT4Nalp Vh8Vvj98NtNjCr4U8ReG/Fd0SoUNf/E3SbvxLeMNvLHz42wzL82eNxyKmcv3lCTVlzyhut5JTvrb b2ffr6FYNU6uV5pSaXPRWGxSajd+yhWjQml0vz16fotk22eWftNyW3hL9ob9jr4oJp897qtz8QPE vwHS6iVjFpmgfF3Ql8U63e3LKP3cK3vwj0G3Mjt5YkmRZPmaMjq/2jfhz4a+KHh/4geAPF9hHqvh nx34W1DQ9c02ZmaO+03UdM+xXNtICdyRzKArKrJ/s5rV/bU8PeI9c/Z48a3HggW8Xjbw7N4e8SeF 9RuMr/ZN1pXiTSZ9T1CCRUaSGRPDv9sx+bHg+XLIG/du2NzxNqWn+IbTwx4h0+4S+03xD4asNRsr yJleK6stQBuLWdHjLK6zWskciurMpR1Zdy1z+yjLEY2lZy+sxpVZ8z/d8riqNoLpK1KLsrayu3rc 9Wriqkcr4azSnJU5ZVXxWWp00lO9CtTzKnOco6tT+uzjFy1iqTirpHw7+wv431/xt+zX4Hh8ban/ AGt8R/h3Lqnwi+Kd8MbX+Jnwzuv7A8ZRgvvZlg1SB1jkZt20fe/ir8+f26/2E7P4h/tR+DfiD4K8 YWXw01L42+DNY8F6i2t6f4XuPhj4p+MPhaaz1X4faF4p8MNpS614l8Q/Erw3qPjptS1jTdStdfjt /h/ov+nLY2ckMn238H8fC39rz49fCNLuCz8P/E/Q9J/aD+H/AIcto5NtsftVp4b+MGv3DlFtxc+I PiF4j0q8ZY5Gkk3NJMFZefb/ANo7wdd+LvhXr0+h3DaZ408HG28eeA/Edpo9trmt+GvEnhR5L+TU PDNpdNHGniDUNAOueF7G4WSOSKPxFcKsn7xq7uH8+zbI40cVlmKrYfFYZunVk5uMKkcPNR5Z00rS 9tCKW32m9d162cYfCf6zVJ1MPhqmXcSYWOKw2Hm4zo0o5pQjKlreXLPCV5q97SUqbT7P8PPGH7Bf iLS/hWPBfiLwFZeB/Gsp1FILmfS7HxH4C165eLyWfRNXt7bztRsJLZIZvscF811oMkj6fJJ5lq23 +dD9oP8AZS1vwvqXxCsNY0C60Txb4VktdKkbS7LULKTxBb3uY7bW5Z7x5obzR9QcxwxyWqRyWrXM McckbMtf6RPwC8S+Dv2gPgd4X8TXuhWd7oPivStP1m88M68ljqVzoF5qNjBqN34c1yOGW6tYfEHh q9uZ9F1y1WZ20/VrG8s5GWa3kVfyg/bv/YR0jWfGngfwr4BubfQYvipp2u+G/DOs+IlfWobfxvo+ gah4li8KS3kqTrBF4i0HRNZurPWNeksdNsdQs7PR7O8a61O1tJP6M4D8ZKdPFpZ9UdFYr2cnWlJS wilNwjs5N0VqkrN3vq1oz8kzDhHG1MbiMHg4SliqLqJ4bSEpToLmqJPRS5IRckuii2mfwcWXwj+J OiafFptrr8+iLHcTT6la2GpQRmfNrE1gy4XkRkXKzNqHn2s3zQwxxyfaWl7DwD8TfEngHxRZatf2 Gk+IvEvhm106OfWoNJgWGa1t5PPisnudJitVF01sYi1zpbWt9bh1hluD5K7fvr9q74N/HP8AZp+I Or+Cvjj8LtY0mC+lks7LUbrSZdY0/wAQraR2pWfw3qM0f9h38sMc8CzLoeoXkdrHct9oaKTatfOP h/QvDt/rLC38Q+G/Dui26R6lDF4gXVNTPhXUIbeOUxW119gn+w3N9qf2i3t7GRo1t5t3k7rPyZpP 6aVbLc4wkcTTeGxuCrUozpTw86c1NyitnFPf9Ox8NzV8PVnSqOUZUn78ZRkuVp2avaz1W/Nr1P2N /Z8/4KK/Bf4++GLD4f8Axq0W90NNQhltL7wxcSw694TvXdgiXegzlHutGvlbG2z0+8tvLtTNDcRy wNNG3jnx7/4I3/s6/Hvw/c+Lf2N/HWjR+Irq/luZNKuvENvc2iXkj757A20srfZbqOSRma3Xa20f L8zBq/IHUNM+HXj17S403WIdL8X6BII49ZmvLzTnt0s5BHZGyNtE0dzdqgWa1VmRV2feDV9IfCT4 wfHHwT4gvPN8UXJtSscOl6/4b1FPDWvTzWyQkNd2vm2za0s0T+XJb3DfaGkHmRxsrbq/Pcx4ZxGB q1MRkOKrYGrD3quFqtvDNyd9Nb+vm9j16OKhVjGFalGUZxvGXNHa0fete7v176bnyN8ff+CXf7Wv 7OdlNqPxA+Hl1eeHkub61l1bw7BNqttHBau80d9cG0DG2juY3W4j8xv9H3bZt3l7a+MdE0HWvDF2 s082rWFpdWpIgE95bRXULYkaJ7YuvmO06Rqtuf3kbhXfdtav6V9E/wCConxysL3T/BuuXui+PEiv Et00DxTpN74c8SyR2spAtI9Wksf7LvnW0Eata6pqFquoKVaPz2lZa1tY+KX/AATd/aT1eRfiz8Nr 34V+P7qGGz1XU4tMmtdMeaV1ixqWo6DDeaKYftDJMWkvNsjRrNJtjjaRPnsZmOcRpOGcZdGtTjGz r4FKU5OyXPLRLTuu1u50Ybkup4fEKPJ7yg5W0jyvra+qvfb01P5WvG9pPpupXGtx2K6pYaqvlvHv mMmnvKqiWRow+XnY28bR3UyyQo0bKq7q+rvB2szfEf4Evpeqi7a6sLWfQ7ZJ4jJLm1V0sLmSUKqy xfZBb+ZtHkySK0kqtIzM/wCr/wAUv+CZ3h2V5PFHwH+Ivhfx5oztM50mFrK8U2UyEhEk097uxjmj j2QyQx3O5d6yBfMaZY/knVfhb468B2Fz8PdW8NXmjWccbm1nttOAjhjMYl+xwXVurK6CWR/MaRo2 VW2bWr8L4loYfEyrSw0rRqXU6dRcs1srvmXT1btufo+W5/GWHwyxFKM5Ua1NRq83NJwi4XSSTVr+ vnqz8G/A9tYWPxW8LTXtumo2s+qnSJoGWOWMR6jbXGmFL+J1ZWW3+0iZ1kTdiL2r9CNd/ah1z9nW 1k+GaeE7DW/B1tpElzoUsU0umavZiaZmaxDtL9ln02GZxNDG1u037+b98w8tVTTv2SrCw+IGn+Lr jxFixg146vf2k1rLDf2iwNJLBbW0SR/ZbgyTCOO4aaaPbC8jLubareNftdaHe+JPG9ovhTRdcv7W y06ZL9rbS9SlihkiaI+eJlt/KmiaNgo8pm2su1tvys34ri54nCQqYaUJpQrKdOaTbkrrmi5W2cfu 9T9cwtXJ80xtKNHGQf1vCy56MX7L2WJtGMbxk1GTXXR+XU8f8ZePfjH8ZfD1v401I22m/D2bWX02 90nRZHQ2cZuCjXd+ZpJLrUACzH7LNJJahl3RwLuzX6K/Bv4e+J/2No9d+Inwx+Pmt+ENf8XeC20b xPrGm6d4V1Tw54k8Ly3thrEGnT6T4o0fWNLv4rfV7DTNUtbqS3kvtLvLC31Czura4s45l8P+D/gD W/CPwCuJNatpbddXm1TXUgmjazubawTzIXnvIrgQ7nkEDNCu5lZQrKzs1fm2TrvjHWtC8JvrGq3e mtqcX2XTJr6ae1s45ZC9ylujSNDGY7UTMrYUrt2vsXcyaSnh66ptQhUnUp2bm7qMXy80HB737bv8 /HpPMsOsfSp15Sw2CxNKKq0UqNR1op2dKvSfNGUFZ88Xou3X7p/aA/ay+KPxGtLvw5q3xn+M3xet 7idLySz8Z/Fbx9r3w/hvYwUjuNF+H914gk8DsLX5Ps403QobO1kP7uGNm3DxH4M/BnW9V8SW/wAR fG9nNb2lnef2jp8N9CY7zWdTWUXEM8iMNzQLLtmkYFT5bYyqKqp6L8N/jF8JfgadV8J+JfBF5eal pDTS6b4r02xsLy+neYR7bO9iuZopIvuybHj8xcFWZkVlxB8TPivr3iK50C41a8XwF8PPE8DRJrLG G71+1t71fNDS2aOyhvJlVf8AiWyXSW8YVZmhkVo1WBpV3OUPZ0VST5VSjaCjaSV9OvLytpt8voGZ 4qlXo4XDXre0lTVapisbVniqkk3G79pVXNLW71lu3vqM+Mfxv1W9vf8AhCPh3L53iW6mj0yS8swZ 4dOhz5ckFsy74xexsBHdNMs32eEzMyrIqsvpNx4rsfhN8P8ATI/Fur3V9fW0KyajOkgu7q+v5I95 gjaP94qb3EbLGwjQLvZa8O0/xB8MfBlo0fwn0HXfH3iCVCsHiiTTbmKFZooHFxAWuI47i1spCS81 rFGxuiFjaP5hjynXPCXj7x3qKeI/ibq8PhyxlnitdIsLwst3qU8zER2Hh/RYRJcXd0zlIVt4YTcS SPGqxsCa9FYhwUoxnHmha8I293lt+d1/wx8/jcnoQjQlTp8ntHFyqfZcZKLc917vW6vbp2PV/CPx 117xr4mMstnb+G/CNgst1cXk/mC2gsYSZS97dSN9ljnX5mXYqxsx27WkVmb9pf8AgnR+w7+0L/wU Y8YxaZ+z14Mu2+HGl6lp8Hjz47eKbG8034d+E7e6liN0llfyCFda1yO2Z75PD+mXS6hf2sE6wssb NXsX/BGX/ggT8Q/23PHmm+K/2p9P1X4L/svfDHWtJ1LxL8IfE9re+D/jh8a0gkhv9Kt9Q8G3SWni HwZ8OdVwUGu6xb6XPqcEk994ajvjOtyn+k98NPhl8O/hB4G8N/DP4U+C/Dfw78AeDdKtdE8L+DPB 2lWmheH9A0ixhWKysNN03ToobW3ghijSNY40+6Pmy+cc1GVevUjN1LU5Svu3JL3Vyp68t3HXZb+i 8rOaeGwNSGG9lGrVpRhZvSl7yjNJq69onGSejs7/AH/k/wD8E/P2DfgT/wAE2PDotvGfhGw1L4va pHeN4g/aX1KwjvNAvrHT59PtbWz0O5uPtFt8IdP1GXX47Oy0KS5j17xbe2uoTalqer2mk6XHp/7J w3UFyvmRMHiYKA6MGySx4O3hQM/M3RfunpST2cN3DLDPHHJFPG8UsUqgpLHKhjeKRHU7kkQlW3L8 wbp0z4ifhJqngZze/BrVrXwzbIL+6n+H+ppNN4F1K7uUkmihsY4FuJ/BsUmrTXWr6re6BYT3Wq3l 5cS3cTucjsSqU5St8nfdL7MttX8rPu2eYlgMRTS/3Sv7so6P6tKVo7/FKlJv4f4kW39iKuvdQnBG CMvuwHYc53Y67sZx8pwuRt21WvdMsdTtbiz1Kztb60vIZLe6tLqKK5tLu3lUrLb3FvOskMsEiErJ HIrKykq25TsrznRviZZNqS6D4v0+78E69JeXNpZQ66YI9N10RXa2ljcaRrlrNPod1ca1vS6sNBbU F8TC13NeaRbtDMsfqIlRmwAGwfmwQCoAPzEE8jgcds/Wrco1Lc0Hzq0m9G4x0sr9fNfF80clShXw c+WXuy92UakZOfOtOWSqRfK4uyacXbbY8YuPhKfD0txf/DLXbvwfeSCOVPDrySX/AIEu3sdOttP0 zTj4euWlTw1oltDawGaz8DN4bmmcy3DSPcTSSPetviDq3h51s/iLocujbBMD4q0uOe88Jy29jbPP d6nf3AMh8J2chj8mytNbupbmaWWGPz5W3bvWWHmbgVypHIYYBB7MMdMdd360nlBz84jbJyQQDjAO 0AHrtPXsw5xScXdNWsmpRUfd/l6L8Xb5a69Dxkq0VDGKNdJKKmmo1o2S/wCXkY6q386m7aaJK1e3 vYbuGG5t5Yri2njEsE1u4kjeOZBJAQ6lt/mI28OvyldrdGq0WfjqCu0NwcFiASQTjIGffp161wl1 4Cs7Z76+8L3MvhbVr6a5vbibT4lm0+81G7NmlxqOqaKzR2OqX0ltZx2qXF02+GMl4zuSpota1nS5 TF4h0stagOE1fRg13BGpbbHBdWCKdSS+lwHb7DZ3FjGsiqbj5TRCcrvnTVv+Bpp+dvIxlRjL3qFT 2ivH3JrkmttleSmrvpNOVldK9juAq4IBILfe6HoRnjG38dvekMSnrnrkYJyD9eo/Sq1pqFlexGay uILqFWeNpLaRJ0WWM7ZImaJmAmjYFZIifMRhtZQeKtb8gEEKMDJbAOT0BBOVPsefatTnSlG6V43+ f48zT/TbqUbjTLSdjI0IEjMCZIma2nJXgEzwNHMwwOVMm0j+HtSpBdQkFJhMgXA84AygAjCB49u9 cDhpNzcfN3ar4B5yQe35Z4PHvQQBzwPXjqPT8aCr6339dSukpBHmAxEnAV2Bzgc4I4PfFWQc8g5B 6UmPZR047H68fl70wxZJKsVJ6Y4AOP60CJaKKKACiiigAooooAKKKKACiiigAooooAKpvCslxG5G 4w72UEcBiFCsefvKNyq3uwq5SBQCSByep9aAGxjaoHckk855JyQD6KTtH0qjqYZrOSJE8zzXihdD 1eGSaNLhBnrugaQHttJq+TgHHYD9SR0/CqUqiSW33OR5TmUjqGDI0QU/8CdWx/sii19N7lQSun0W vyVtPyJo1EYKIMKqooVeCMD5QP8AdVQv4fWuE+JulQeIPAuv+H55Fh/4SDT5dDjZj/y11ZDbJHxk F2d9q9s9xXoAG0E5G7GGIHU8YOP8jk1w/jiKSax0JYyQV8W+GJZMZyY4tUiZ1IXOR5ed2OOKyknK ml5/rb8bI1wz5cXSrfy1Ivrb3eWT2/wuyvtbbU7SNdqwr/djjU+2ABzWFrQze6C2M41YAYyODbXG 4g59l6evHbG//Ev/AAH+QrG1VSbnRCR93VVJ9ibeXB44q5O0Wrbq3paS/pE0XatFt292r8m4P/P/ AC1NlwdwC4OSAxzyASSccHkE8dPevnrwjoGl+Hf2gfixqay/8Tb4meH/AAZrbQcbvsfgeyHhnzFH 3iPM1KFXZtvzOq+pr6GY4x82PmIxx3Y8+v8A+r8/ALvRL5f2l9G8Ujeuj/8ACm/Efh1mywibVrjx v4W1G3XH3TKLOxucfxbQ2K56i5vYvRONVNvVfZUWr+j8tfx7Mum4QzGnyuX1nAzpNK+nJWoYhSXS 6lQjprpfTZr1jxr4ci8X+DvE/hWeVoIfEXh/WNFlnXh4U1bT7mwaVOfvRrcF1PsOma+LPgfqmman 8BvhlpGhpdGy+G8Ov/BNJrtXkubyT4J+INU+Fs99NuXduv7rwlNeBmxuEysrMp3197sDhvoctz07 dvXNfMXwNt7/AEfxt8e/CGpaLZaV4f0j4k2mq+ArdYowb/RfFPhHw34j8Ra2EcfeuviDq3i6OaZR lp4pc/NmlNOGKw8ov3ZKpTn71km1GUHy9dYtLeV2n3OrBOFXJ80pzTnOhUwmLoJX5nebw+IUVe0r xrUpNNP3YPbY+Hv2n7SbwL43/Z6+OtszaTaeE/iVpvw8+IV3Bp09zqOueCPiws3gbwx4Xhljj3R2 X/C2fEHgfXLrcvlqultM23YJF+4I/DmvSPth0i5m2k4xGqqHGQGy7bSP9nbt67sY+b0X42+A5viH 8JvHvg/R2srLXtV8NarF4W1K6tIbqDQ/F8NrLN4S8QGBkKvL4e8RRaZrVtgbkmsY2T51FUP2dvHt r8S/gn8PvGVpfXGppqGhrZXWo3ULQ3F9qWgXVx4e1e9kgYK0ZudW0q9lVdoBR1K4Wop01DE4qlLW NeNOrGCWnNaManK7Pa8JWvdttre504rFfXcgyqvGKVbKK9XL3LRN0cQ5YvBK3PztxlDFRUuXliuS KleyXyZ+x3ouofAv4r/Hf9nPVoF0/Sb7XpPjv8KtOjhnm+y+D/iZqVzP4yTVNSklaCbWrr4yx/EL U7fT7VQtj4bvdI3eXGygfVn7QnwpHxj+F/iDwrY3FtZeJbd9P8SeA9XvGmFrovj/AMJaha+JfBGq 3f2TyruTSrLxPpOlS61Y2s0MuqaML/SzKkd42fLP2orZ/AmpfDX9o6wk8ofCLxFJH41a71V9K0C1 +Ffi8W2k/EDxHrqK8f8AaTeDNDiuNf0K1mZo4dRWSQREyNj66t3W5toZUKmOSOOX5ACCrqHULgNg NkAdtp+X5huqKNKHLVwla8o01KMbytKVGdnB2s2uVqUYrWyinds1zPG4ieIyziPDzca2IUY4mpGL jy5hg1TpVopQvf2lH2Fac7rmlWlFq6k382eGtI+Hn7U3wV02x+LHgTS/FMOo6RN4f8Z+GPG2hWEO rWOr2kq2Wu2d5p9tf6pdeHJL+7sYdVsbeDV1vRpV3pcs/ls6gfh9+2T/AMG//wABrnw149+JH7NS eN/D/ixNN13Vh8JrG5stb0jxDLLHLJbaJ4RXUH0uTRbmH5YbEanqGrBlWOJrqBw1w/7iX+q6R8Hf jTpds8aad4X+Puoz2wlWHw3pGjaf8WdKs4nhWU2+l23iTxJ4r+J3h2OZHudQ1W9tdM0/4ZxR21tA 13M0n0oVMsZDbQHUj5SGVlbIIPrxjsA3cZr6jh7irP8AhyUVlWaYrCOmruHtZTpTlZKLnQm503J/ zODklbVNaeBmWAwk8VhcXUwtOrgsW1i6dOon7KpTlPlrUZTpuMl7KrGpS0lFy5eZK0ot/wABvxT/ AOCIH7Qfg7wfZfEn4ZafYfEPQNS0CHxiPF/w7vl1nwpceGpokvIL60h1Gy0vWkvY4WW5/suPS752 ijkWO/Z9ok/MzUvAPxq+GmqzS+J9C1QXlu37qLxRot/p0NxGizRNPDFeW+nzMirKqtNb7trCNfNP 8P8Ao7+ENSsfgZ8VE+D11FbaR4C+Jc+r+IfhJMZNW+zWfidVn1nxb8PIJdVv7rTYHaxi1XxH4N8J eGLbS9M8P+D9C1WGHTVjtVkj9k8f/Bz4S/FSMR/Ej4aeBfHbfY5LCG68U+F9F1m9t7Oc75Lewv7+ ynu7KN3HmeXbXELMwD5ZkzX6vlXjpnCjClnOCo4/2do150JOnWatB6xlGcJN8zkvejo4rlS1PnM2 4Pw9GrGphJTp4evGNbA1JScqXsJNKVO8eWUpQanSkn8NSEn0iz/L98QPpur+H7m38VSXtob63gkj n0HTQL6xngkZbs6ff3Gp+cl7Gsf7ln87dINu1V248l8Qa94eWGO/s/HVzbR6bJPaafpWt+F/st66 6vBLaT3U7waxfQ3Fnp6ztN5k2biG7jhMds0e6v7lPi5/wSd/Y3/4XHrnw+8feBNV8HeAPjZqMV/8 KviH4S1N7eLwV4pXS7Wy1f4X3yamuo6Xpj63fWsviXwpq99bifVtU8QS+FtMcyaRFBXyp8Zv+DWb 4P8AiWxkk+D37SHxB0DUpImZI/iHpGh+INLVzGTEJI/Del6BfujHa00huPtkilsXBb5q+uwfi5wn j1OnXljMDUd+ehWourGnezim4Qd04yTXe732MMz4XzHAzwc6U6FbC4ihGtRxEYztUjpGceael6dS MoVIJu0k77o/ko8JfHzxt8JZbXVLPxG0lnFeWUcb6Rqskd9DC4lNsL6Jo1sZY7pEumkhht9yxmFZ LhTX2Xb/ALePhLxfZJbeJ/D1wsQBSPVrcWLrNcbQblXsprhpoJI0IZpvtkiyZzHH/DX3J8a/+DbP 45fs/aToPizW/jd8JfiR4DvNasfDfi/VIPBXjPQYvh1pmqrdRW/jXVbeXxNdSX2l22pGw0yYWMlt cQvqMc88zQJtHGXn/Brd+3A07ah4c+KfwX1/TbmNJdJksryTT4lt0Aa1VjcXkwuoJE2zQTFmulWV VkmZl5+az3PeD84jKVDGYWFVQ0lKl7Cd+bT3Wov+ZXa/BI6cPlea4Cjhcwq008JiKjo03RkpRjVg 6blGdNXcGoyg3fpJPqj4j1bXfhh42i+16Ff2DGU+dtVxHcNuPyuyMi5Xey/7Qz82VrzC/W0sWMIS 1mVgImm8lGnZT5jRx4KqpVdpb73y5O7zNybf038O/wDBs9/wUZt75BN4o+Duk23mlRexeKzd7FZS JJTDDd/aXRlJSOGORWjdlb5ggFex/AX/AIICftL/ABJuvFvhHxz+0V8Lvhr8Rvh1qi2Ov+Atd8H+ IfE+rw6VqUcjeHvFOm6hYa7p9trvhTxOlpqEej65FC0LajoutafDMLrSr5R+KZvTwlOo3RxVOs3J qCS91tJaf+A/1ofWYGWNq0a2JiqdN4K0pxp6zpwc4RVduK5lHmko8y2lJXtoz8CvH3hOw8daNPoO v39/HpksDpMmn3A07y42UybVKRTKRGGLIvyrNNu+VVYqvz7o37Png/wH/bepeFdHh1DXb6KWDTtR 8Q3Ra20a3c8uttFAGnupFG2TbNCqhm+av7ePhh/wbLeGFikX45ftO+JdYwGW2T4T+GtK0CMfIG2z f8JrZeL1lCyl5MsrNzti219Kv/wQF/ZC+FcXhjxNY+DvGfx+t/DZuF8a+EfHnjPVNI1HxZp0gaYa 3oM3gKbwlDD4o0mdIJk0qSKTQtc0lNR0kaR/bF3p97b/ACksDKnU9s4ycpv33f3Ka93VRXbmvZLV LSLtY9jA51ibvA4fGUaMa8lKf1mKdOctGoKpKyhOo4pOpNqPM1zNRu3/AJuF1+yf8UPGni57i0sd U+IE9xdve3lr4I0HUNa1NVkRFgT+zNOt7ySCBZYkhkkdpv3bLt27mkXifjL+y3+0/p+vJY/En4H/ ABn8NXNhpUEeg6Q/wv8AFt6jWU1jDc6Y1v8A2fp9zp8K6hFNFNI0l79ot1lCyQySRtGv+xr+zh8N v2W/D2hwa18APhJ8M/h9LpcbeGdUl8P+AvD3hnxtpF1p8US3Xh3xPew6fD4j/tSGKeCS7g1e7mun huI5pmlFyrn6iYAEIeQVYlWG/dznIL7mO0j7u7+72FdFLALkUqVeel3DX47pfE76qVkl8up34ri3 EqawuPynDTlR/dOnUjKlOKXKrNJNJp+8rLVv0P8AHD/4J/f8Evf+Ch37UXjO/wDDvwH+CvxDg0SK 8t9L8Q+IfE1jF4J8K+HdUvkaLTbvxXqXiO3OraNpaysk1zdaZ4f1q+WxSeaHTbgRstf6Ef8AwSD/ AOCBfwc/4J9+HLv4lfH5/DP7SX7WPi9EOseNfEGixat4Q+GGjOIZpfBvw00rWY7iKd5L+GK51Xxl e6fYalrLWemR2Gk6Atldf2n+13jH4VXV14gPxF+HmqHwf8QIbWe1uvNWWbwp4wswoa2tfGmhwyQx Xr208VvNZ67atZ+K9Ohik0qz1mLR7/UbC70Ph98UV8TTP4Y8WaZL4K+JGnfaF1bwnqMrFbqGyNuJ db8L3wEEeveHLj7XbGDVrMSQwzyTabcSPeWNytbYehCjP2ted607K1lbpy3s3eXne+ml9lwZnj54 /DReWr2eGp0ksRhuaVTE0JLl5uZy5W8I5aKUI8kbqFSzavX+IXwP8K+PZ7LXYZ9S8IeNNIinTQPH ng+eDSPFGjpdQpaSwxXEtpeaffW0tnHHa/Y9Y03UYIIxm0S3kIkXm7D4neLPhxPFo3xvs7CHTlj0 q0074seHYLqLwtrmpX17Z6QLbWtAc3174I1K71G9hksrJtU8S6W2mx3mo6h4i05bVrd/o1DhOeck gHaASATjIHykDI247fiTR1TT7PVNOutPv7a2vrK9t5rS6s7uCKa0vbW5ieC5tbu3nSSGe3uoZHt5 4Zo5IZI5GWSNkZlrp9k+bmpyVOU0ufS8Jax+KPdRvqmn/wBu6PwqWZOdOOGx0I4jDxajBzajWoXa 1oVbOUY31cJKdN3b5XK0lPBNBeQxXVtcRXEMsaSxTwyJJDNG3IkR42aNkPVWVivPD96sDnB3DIBz jnnkn9D7818/v4A8VfD64m1T4VXX23Sb3UYb7Vvhrrl7K2jiJ4Gt71vBmpXTtN4Vu5Et9NFvpRuG 8GWdvZXbWfh+31DUZ7yT0Hwd480jxbFcW0SXmk65pkk8GseHdZhew1rSp7W6mtVlurGYR3TWN/JB 9s0fUFX7Nq+lXFnqdqZbW8hZrVS9oSjblsu8ZaR5nF21Wul9U9HFK14xGCfL7TDVViqEVzNxSjWp apKNWne6SulzpuEnpGbbaXR6xoOkeILGTS9bsbW/sZkeNreeIyAJNDJA7RSZWa2uPJlkjW6gkhuI 9zMkittrhl8N+J/Bqyy+Frs+IdF8ySVPC+vXTQzafEUsoYLbQtdjhuJbfT9PjtrmSPTNQsNRuL+8 vWZ9ZtIolRvVAFyCQM5ByTnAHTAxwccY9eKYcZJyuBlQCAv3gMpkDkfL2+bOPwuVOLta6trvffpp 6dfWxhRxNSEVFJzpbThUXuXTi3KPNyuDWvvRal0vY53RPFel61JNbA3OnapayrFd6TqkItdQtpZI kuURo1lmgmElvLDcK1pcXKRxSosrpIHQdMSnBLYOeuMZJ6HuB9fz5NYWqaHpusRBby13lYpoI7iG Rre9tY7iIRziyv4GjvrZ5V+V5rW4hn44Y4XGYn9vaIHM7vr+lAmRW8hE1qAENIQYrdI4b2OHb5Nt FDbC9csrTzTMrPU+/GSileH8ztzL/gfr3B0qNX3qDlCf2oTsoyemkJPlTbeltHaybd7nYOzDIzng jGOvTPHpyOf8aTYcZC9AAFD5GF4GTs68D1PaqlndwXq+ZHKrsp2GMDZLbsFR5I5EctKsyrJH50bM dv7v5VP3r5UgfKT6445/l/8AXqk4y1tqu5lJSi2vhkv6/ExJtItDM01vH9juSoi+0WjeSxhM8c86 eXj7OGmZNskjQtIysw8wDrKJL22IFxGlzHghri3Qo4BJID2zvJhVXG6VZmLN/wAs13CtcqD6g5zk dc/jmmlB6n06Z56+np7VQ+a29mv7xBaypImVcFcnaBuwMYBALBWbBP8Ad7irdQGBTg5O4cZBwMZz 0HHFOzInHDL/AHjnI69fXsPxoJ06bdCWikBBH6EHtS0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABUajMjN7bf1/wDrf57SUgABJHc5NACP90/h/MVg6hvbUdHgaMSQSyXcz8Z2vawJNCcf9dM1 0BGfUfTrVCeHzb2ylA/49xcsx9PMjEan81/Ss6nT5/oXTlaTeuiknbde7/w33ljB9D+RqlexF3si QTsvEbkH/nnLzz78/nWoBgAegxUUq7vLOAdrhhnswBAI98EgfWtCU7NPsGMxnb1ORn33Y/L9K8i+ Itxe23jP4OR2btHDqXjPWbTVAikCazTwD4uvIopGA4T7fa2brvP31XvXsBGBxxz1+rAn9a8++IM9 vYWOj6zLCJZNN8SaHDaNjLxTa5qFv4eMqMT8p8rVZVZs8xll/irKs7Qb7K/3Sizqy+VsXBXS5/a0 99/aUpU1ez25mvR67o71QNuWw3A69iFBwf1PPpzz0+bdQs7XQf2n9D1291mVG+IfwzfwXomghXME t74J1nWPGOq6qSAEEz6ZrlrbMzfM0dvGoAwK+kWIC5B5wFJ9SFzj3+9z9Py8P+L8MWkah8NPGtpo v9qa5ovjzSPD1nOoO7StK8eXdroHiTUQwzhIdN/eS7tyrHEAAtZ1lJwpy25Jwnra/u8t+mmkmnfv 1NsslbEVKbs/rVCvh4J30qTpt02uW+1RRlZp6LVOx7c67w6j5t2UbGAMgEbXGPu4z785Xnp8s/Ax n8K/Er48fC+61Se+GneJNI+JXh+wWxe10rw14K+Ilpc6bonhjS5NiwTvZa34H8VapeRwbhbnWoGk CmcbvqdCfLiZc4ZEJ69cd/x4x7185fEiQeFPjL8HfGX22+ttP8QTa/8ADDU9K06zWaDWtY8TW9lr nhjVtanG2SO08Mw+FPEMFrIzNHDN4knAXdNkKtdqhUUYvWN2mrxUko3fXlV4vS7tHXQ3yuXtY5jg ZLWvhZypyk2lGtheXEQaV0nOcIVKEW03GVXTuvbvEmgaX4q0TWPDuuWFrquiazYXWn6npl9EtxZ3 trcxPBLbTwyq0csEiHEySrsYN833q8O/Zm1vWpPAUvgPxdeaxqHjL4XapeeAtd1PxBNY/wDCQeKr fQppNP0j4g3dlZXd01lZ+O7KAa/pcdw6TNaS7vLVlZR9GbWwNpz984IJG4nOWAPzBifu/wD6q+a9 Wsx8PP2hNG8TwLb2+jfG7Tz4Q1pbawuJ7u68deFNIutY8L6xqupNeLZ6Zo1p4P0fX9CjhW0Mt3rW oaZD5jNIpokowqQm1anBKk3vz86XLLRW92emq6vqGAqLEYPGZdO8ZyisZhovpXope0gk1b95h3Uc 2mnKVOlGzW3oXxo+HQ+Jfw/1zwzDc3Gn6wY4tR8PavYXUum6jpXiDTJUvtMurLVIVNxYmeaBbC/n tmWf+zLu9gUss7qx8GPHVx8QPh/o+sapAlj4jthd6D4r0+O1v7S3sfF3hu+utA8TwafBqtrZ376O de07UG0O8mtoU1TRmsdVtvMtbyGVvVdpILFs8YJGcYYA7iMtkjB4+XrXzPJbn4V/G6bUokaLwX8a nt11adLcLaaZ8S9H0600nT9R1LVLrVQtvF4p0Gx0Hw3oui6ZozG41nTbq/nuGmviKJxVKcKzdnPl pTfSzdqd1v7rdum7d0kPB1PrmArZdJP2mGlUx2Bi7X5lCP1qnCTevtaVOM4U0/jpuMYN1G32/wAb vhmvxR8A6joNrqMmieJLC4s9f8E+IxNLG+heM/D95Dq/hjVJXti01xpi6tZ2ketacTt13RJNQ0O6 iltdQnieL4G/EeX4j+DYrrVrOXSfGnhi9ufCPj/QLltPa50Pxjosdu2o2V02mXN5p+6/tbyw1yzj s7ueKCw1a1id0uBcQQ+zELIvVcOBnABXHVep+jdOfoa+WPiPbj4NfEaz+NVhHHbeC/FX9leE/jEs drMy20ME11/wiHjx5LeWTyl0K+vr/RNZtoNIvL/Xl8R6NNcajY2nhlVuVU5qM1VprSpJQxHnTbXJ Vv8AFeD912+w3d7DwVRY7CSyyq/3lJyxGX3V3Cs0va4VR2/2lKLjFautTglpOTPX/it8M/Dfxd8H an4M8Uw3P2C/WGe0v9KvJtN1zQ9bsnM2k674f1i0IvNG17Rb1Y7vS9Ws3S4sbuJJomyteZ/AP4me INVbWfhR8UZxF8X/AIdeXb67M9jHpMXjbw+pWHRviNoFtbE6ZNpPiKAQ3N9YaNdXv/CLahdx6Lri aXqMsVqfpK3kWWJJY8OhG6N0IKurgEOrL8rKwIYbcgg55NeA/G34e61fNo/xQ+HLNa/E74ftLead bLHHJbeNvDsmZNd+HusRyPbtLZ67bq0ui3Ed5aro3jC30DXLn+0LHTbvSL91ocrjXheSWlSK+KpT 0s7780d4eso7S0rA4mFejPJ8ZJU6dSbngq07uODxjUY3bbXLRxCjGnXS1TjSqtP2TjL3HVNO0/Wd NvtL1K0ttQ03UrO6sL2yuolns7uzvIWgube5gkVopobiJ5IZoXXEkcjq2d7V8X+CLi//AGW/HWk/ CbW7qab4E+M9RWx+Dmt6hI8h+HWuXsuy3+EF9fTMRJ4cuLh1T4avcSCfT7a7tvA1jbDTPD+nsfqP 4afELQPid4O0bxf4fuI5rTU4mEtqRLFc6dqNnI9tqel31vcwwXFtd6depJbzxzwQyOY1nWPyZYWb Q8deA/CvxG8K6v4N8ZaLa694d1q1mttQ066aVUdZt5WSK4glhu7O5hdhJbXljcW95ayqktpPDIiO FWpubU6LXPCMalJ9Hflk4T/mhNb7NOzWsURgsV9QnicuzGlKphK7nTxdNJKpRqQbVPE4fmtGNajK 7SbUakOanJ8sm11ysrBSpBU4YOOcg8gjjjg9uvvXgXxn+Df/AAn76P4x8Iasvgz4u+BTeTeBfHFv D5phS/Nq+seFvENqCn9teD/Ev2DTxrOiXBltprjTtL1aOF7/AEWyxzXwl8V+KPAXiZvgV8UNeuPE Oq2NlLf/AA48e6sYk1X4heFLZlhaHXfs8MNhN400BJLeHWrizS2XxAoudbtdF0ezjmgT6hTbtZ9n D/Mc5I44BGenHpVQlCvCMpQfacH7tSnOLinbW903eMuZ7KUW9DKccVkuNhOlVUoygqlCtT9/D43D VUrqSa5ZU6lN8tWlNXT5qVSF1KJ4n8I/iz/wndvqXhrxNpa+Dvit4SMMHjjwNcXHnPbly0Vp4l8O XUhQa74I8RJH9t0DX7XzFHmS6JrcWl+LNL17RdM9oKEj52LKWyOAMKOVjCjnC8bsr82Pmrxv4p/C keMLnSvFvhXUl8JfE7wqssnhbxbDbC7AgZhJc+HvEGnLPa/294W1RsxalpJvLOcJNNNpeoabeSC7 F74ZfExvG0N9o+uaUfCnxB8NCK18YeEZbtr06ZdSIxgvtKvmtrNdc0DUjH52lavHb2jT27xi7s9P vCbRSnOpCU6dW1RNJ0qn2akHb3W72U4r4ktGtY6XUTF4WjiKLx2BXs6anH6zhac71MJOVveSbbqY ab/hzd5U2/ZVdeSdTkfiT8Ldah8Qx/Ff4Ry2Oh/EizggtPEGmTubfw98UPDlm0ssHhnxZHCkgj1D TnmuLjwl4mFtc33h6e71Sxga307xFqzj0DwF8SNJ8b2jQi3utF8T6ckK+IfCOtLFZ6/oMz/unN1b eY0V1YLOk1vb6vp815o2oSQu2mX12gDD0QZHyhflwdwIDZAAPy5O77zN97/aPI27vKfiH8MY/F5s fEPh7VG8HfEPw/KLjw94rtLZb1BtC79I8RaZ59mdf8MaoiLb6rpRurG6ktnkGm6lpd3i7EKnyT9t RlzQTSdHeLva/s9uWV7Pa0ne9tyaeJpYyjHDY2U1OHLChjW25wUeVRp1VrOpQ3TavOl9lSj7j9cU BhwPXccZzjIwDnrz0xXB+N/h74f8eWVvb63DLFdadf2+raFq9jLJZ61oGtWsc0drrGjX8W24stQg huLm1MsLr5ljeXtrJmC6mRs3wL49m8QRjRfEumr4U8dafEkes+HZLw6ha+Yo2vfaDqr2tj/bWiXI V5dNvmsrG7ktysl9ptg4aBfTMghTt3E8ls5IPI3DjBGO/Hyn0rosqqa2b6e7v7un+VvydjllGvl9 a8XOnJRSU02+anLl5ZRkrxnCe7teLT7PXxSy8YeIvAt5Po/xJaCfRYo0uNJ+JUMMVto01ux8uex8 UQIQvhvUrF0lke/nVfDsumNZzHVl1A3tpb+1RurKBncNo5VQqjGPujOQD0+7j3HejeWNtfwzWd5b w3dtPG0c1tcpHNBPHKCjpcQShopItpwytuDfMNvOK82tdI1v4fPpsfhiO58QeCQ72t1odxcM+teH bXy2axn8Ozzg/wBqadZyLFY3GkahJDdQ2c8mqJrNzJYjTb/OKlTkl6JS+ytI21Xz0f4vVbz9hi43 UYU8Q1zVFFKNKvN21j0pzkre58LaaXK7J+syZKNgZP3QMYznGOdx46tnNcV4j8E6B4lksb2+t5Yd W0drp9I13TbibT9Z0qS9gjtdR+wajbD7TEL62SO3vVRwt1CiwyD5QtdBouuad4gsl1DSrqK8tJGe MshKtFNCxSaKWN1SaKWNxtaGaOORQN20oyFtcfMemFHt6e+Oev8APvWrSnDTRu1mpd+V20v6dNTj hKtQq2vKny6Silyt3dnGT6rR3T7tPQ8osNd8S+Flj0/xy41HT4LCDd48sLWO2tJZ4XhiuJNf0mAb dEmmDSXxubSO40LT7SC4a81K1dYY5fToLiGeOOWCSOeOVUkglSVJIpo3UFJYnRmVlZG3KysdwJZR 81PeCKWOS3mRJI5RJHNHIivFJE6kSJJG+UdJFZlZWVlZTgriuRPh+fR7me88NSxos8kMtxoV5I66 ZO6B0kls5lSSTSruZWj8yQR3lu0drDDHZwszTGU5QVrWWivFvT4ej6f9vdzac6OIXM4+zqW1SXuS lotYqyhJPSyvFrsdsoVhnkgk4yTnrg5985obByuATxweB1HT3wfxxWLp2sQ3rPAUmtLy2keO5sLy NYbiMoxxKFV5I5YriILdQNDJIy28sMkyxSM0K6kThwrMDnkAEcqynaVLYGW/2uB9K0TT2ZzuMotv p9l/52/rsZ11ptvNIJyHiu402JeQsY7oR5LFGkUbmh3YyjfKwA3YXgvgluoPluFMyDpcQoFfGwOx lgB+Zmdiv+i+coA3MyturWKgkEjkcUmFUZwAB+nP+Jpjcm1Z2GIyuA6HepxjP8P58/8A6u/Wpar+ SobcmY3A5242N16g9c56/XrT0dhkOoXHQjvye2OKCSWiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigBr/dP4fzFRbf37NyN0YQgYxwWbPTrz/nq09NwcsfXGPwFJpPdAOox09jn 9CP60UUwGMTnbjOcH9f5cfzOa5Xxlp0Wo6LMkrNHFZXul6xI4CEhdF1K01ckBwy9LM7t38O7aN22 uswM5xz61VvraO8s7mzlGYrqCa2lHrHPE8Tj8VY0mk001pLSXp+uvQqnUdOtCUdJQcZJ/wDby0+d kLBItxDHKpBSaOOVD6hlVkP1KkdPTp68F8UNF1fxB4A8XaRoVx9j1u+0S8ttFvMjFrqb27fZbtGY blaGcqysG+XaP4smu7t0CQpFEAUiRYYzwV2QqkYyRzyuRxz8v1pZIg6yRtja6lBnJwCCATjnODUz inBpq6ceVKy0Tsu11319TTD1XRxFKrG8ZUakKi3teLi3e3kurv37mdoWqWes6PpupWEyXNjfWcF1 aXEZ3JPC8QZJQwGGWQHd2wTXA/Gjw9P4j+G3ie0s9Su9H1C1tItXstWsIUk1GwbRrmDVbg6eXSXb c3dpZ3FgjKu4JdSKvJatT4bxW1l4Xh0Kwt5Lay8K3t/4Xs0mwzva6HM9jBP1yVmVAy5x1G6u7dUK bWXfuXaV27lZVyCrAjbtbcflPDc1Dhak42d1+75bWtdRWmnZ9GreupoqksLjpVIPl9hiI1INaXUZ KSv/ADJpWldaq6elr8/4N1228WeEvDfiW2gubO28RaFpOuwWd6pjvLSDV7C3v4ra6VgrRXMEdwkM qZVo5kZflZcjkvjF4OuvGHgTVrPSg769prWHiTwzEL2WwiuPE/hbUrTxH4cs726t5IpY9LvNb0ux s9YWKWM3GlT3luzqsrNUPwrWTSE8XeEZJtUvH8M+LtY26jqagG9h8TS/8JhBHYEOxOnaRFr8eh2+ VRY103yY12RivVJNsiFSPlP3lADZHB29eDkbuB/DUqKlSjD3ndq8U3u5ax+TTd9FZfM1qTngMxVS nKyhKNWErXvTkoVIvVu6lTmuaLbfRu6Zx/w+8V23jbwfoPia2ntbmPVrBXuHtCxs1vrZ5LPU4LYS MzmKHU7a8hjZizYiBLvuqj8SfA9t8QPCeoaBLcnTLxlj1DQdaitNPutQ8Pa/YH7RpGv6Smo2t5Zx arpF2sd3YXE1vL5FwiyBTtWua8Eibwv448aeD7ma5bTNUubfxd4Ue8nsorZYdRVrPW/DXh/T0n+0 jT/DU2n2OpXkxt4YvtHitFUMzNXspOM5+bJICnHI7AEnaPTqo9KLe0hJVLtO+ib6Wvt57a6JsdeU sFjoV8O3CL9nicO0laMJqNSkuzcE+Sa0u4tStql578MvGT+M/CNjql7bWmn63ZTXWi+KdHtL6PU4 9A8UaM5s9e0WW+g/c3Eul30UlvNIq7WZflzxXWaxpVhr2m6jo+pwG403UbSW0u4g7w+Za3ETRSxh 4mSeKRUkYpPA0U0TmOWKVZURl8umgl8EfEz+0lkmPhv4kLDpt3H5up3a6d4r0e0mn0+aGBYG0rRN L1HSbXUY9RupJ4ptT8RyaVbLHNcXKCvZdoZRkAfMSuRyCBhWAIG05J9OP9qik3JSU1zOlFwi39pt Rt2vfrp37kYtOliKWJwy5YV2sRTlC6cZJp1KSeqjKlO8FK7bSUrK6t4F8HtUvvC9zq3wa8QXLXF/ 4Jt4rrwhe3Gox319r3w5uppYPDl5PES2oRT6B5Uvg66uNYmvNS1q58PyeILq6nbVfNb3s7pECuoG 4OGBU5BAPOThccH/AGT0x6+UfFPwnqWoW2keMPDEMcnjfwNdzatocflWUjavZXEccOu+GVmv5re2 05fElhANObVGcS6aWF3D8yOr994c16x8U6Bp2uaVJNLp+qWcF7avc2t1Z3JjnRZUM9jeww3trMpY eZbXUEM0bZSSNSGopylCaoSj7ihdS8tPda1uk9P+3b7srGKOJjTzOkpQc17PE0kuX2eJtG8rJf8A LxfvIvROTqKK5YXPn/xLBc/BLx1P8Q7A2MHwz8dX9tD8TbS4SO2/4R3xNJ5Nlo/xBtbyHyY2g1RN mg+LotUW8urqSDwe+kzafHZait/9NxzxyIsi8hsHght27JXkcAHI7/dbBqlf6fZ6rZXGn6jbx3Vn f21xZXtpOoktbm3uYzDPFPC42PHLCzoysu3ZJIvKs2fF/h5LffDzWx8JNYS1XQY4Lm5+GGpw3FvG tx4ct0Ly+D5tLkdLi1vvBcebOxj0+C50o+E4NDme+TUnvLG3iCVKok5Xp1G3FX0TvGyV9dXa2rV7 Lqkazk8xw0KklzYzDU0qjSbliMLSikpNWt7ShTVpN2bpqLs+STfWfE/4ZaJ8S/D40vUpLrTtT0y9 g1rwt4n0mUW3iHwp4kssnTtf0K+Cs0F3aszQ3VpN52l63o89/wCHfEFjqfh/VdV0y7x/hT441rV4 tX8E+N3tIPiN4M+zW+vLbxtaW+s6deGcaL4t02ylPmLpeupZ3kPmRt9mj1TTtUggWGCKOKP14kEg MdpBwMnDFtrFlUHk7QDwu4bQW+VVryv4mfDn/hLjpHibQb19A+IXhD7VceEPEtvGhmijvTbtq+ga lEWiTU/DuvJY2aatpNyxs5rqy0vUgjXWl2zrdSE1KVde44vWEVdVEuW7elut1LS92m7O6yweIp1K McDiZp0OdvCYipe+GrSlFuMlp+5m9Kis7JRqRu4uE/VlG4Bm+8o47ggDr12kkDqTu2n5WyK8z8ff D+TXZ9O8T+GrwaF468PljoushGMF3DKc3Hh/XokK/wBo+HtSYBLmzlybS5FvqmnPa6nZWd1Ds+BP GMHi7SZJ5YUstb0m5fSfE2jiRnn0bXbaKNruzlVwlwIZFaO906aaKNr7Sbmw1KJWt7yKRu2yWAVg QDknHIxyMZB4Kkr0x/s96LQxFLmjpCb5uuko291bct3ttpsZQqYjLsVNRXJWptxqRfLOFSMkk09H CdOcGlbVNdbWZwngjxhH4ngubS/s20fxPo0q23iLQ5XDSWN2y5SW3kOPtOn3wR5bG8i3RTKskBZ5 becjuwAfmAGcjkKM4yeOnRiSSM8YPG41w3ijwo95c2viHQWitPFGmK6Wczb0h1CzkZDPpuoMisz2 8zKrxsyt5M8aP8qNKw2PDevxa5bS74JLXUrOQWuq6dOY0ubO8QAusqLIylJAUmhljZo5oHjmieSO RWa6c3dwcLWX/gO3/pX4JXvYrE0aVSEMVhX+7jpiKLXv4ec2ryj/ADU5PWL1avyy15ZSy/F/g3Tv FNkscz3Njqdswm0zXdNl+z6vpN4kgmhubG6wVcRzKjzadcLPpmowLJp+p2d5YT3FrJj+DvFOuQz/ APCKePIra18U2alrXVLKOSHRvF2nqcJqmjiWSQw3cQKR61pJlkn02d4bjallf2S16aEGTg9QeBn5 jg89BtOf7v3u4rN1LRrDV7R7S/hSaJm3qxJWaGQDCzQSgb454yN0cybXRvmXAVack42UEuX7XL8U tn3/AMrdVsiaOIjKEKNfnlSgkoNa1abdtU3e6u7uF+XT3bSdzTKiQbgdwYFCVYgEAkHDKRyD1Zdv 3fvfKBSPEJAAwIOF5DFW+UgjlTyuQN68K3RlZeK8/wBI1PVPDeoJ4b8SyzXttcMx8O+J2K+Tfxby V0bWSrH7JrdnGUihurjbba7D5E0NzLq8l9ZQ+irIrAMM4IB+6QeecYIDZI5+72OeTVJ8yV/s/n3f rv8Ah0MJxdKXuvmi37s1onqmn0vr31urdrcZqfhqS0mvdZ8Lywabrt08VxcxSqx0nWJYvlY6nZxN Goup4f3Tana/Z9RdobNbi5mtLRbatbT9cS8lezuIzYapBFHLPp9w37xVlUfvoHAVby1WXfbrdQqY 2mikj+8praIycKcZ6MO2DyBz1+ox/WjeaVaXjxSyxf6TAHFvdLxPAJVCzCOU/NH5qja+1vm/i9aj kad4NR79ebvfT+t7FKtCrFQrNv7MKsX70F9lPa8X1vdro7aFxXLhXIGSAxUNuXBGflbG1h/+1jpT tobqDjBHOMnOM4Iww4X+E/N/F04wrS5vLJEtdXnjlkXEa36xCKK4YAqDOqL5do7NtCqGMbMdiMzM qnejb5QdwbhegwOfT1qlLm0a/wAv+AZuEqb1ale3LNbNe6t/5nbb5aFC8062uvLMylpIX8yKVHMM 8BbA/dSxlZEWQKI5FU7ZowY5lkQ7ajhe5tgsVy32iJVyL1VAfjHM6IBGGYkY8lY4/RV4xrEZz0Ix 0PTPUZ9un+FIFxz3x07dOh9R+VVyq97a/wBfIPaOUWmr9LS2WnT8vzjsIjqyqyurK2MNnIbOeBz1 6f5FOKg9ScemeKiEOxi8RClvvA52Eey4+U1Ir9Aww3OemPw5PHpTEPpCAeopaKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACmtnAxzg5/LNOprdOvT9SQQB+ ZoFZXvbXuZml7lsLdSSWxMxY5PJnkCgj6fd/3fxrS56k4AA6gHk9+nG3P8+9RQBUEiKAFSRgqj0I VuPxLfnU7DIIFJq6a7j636s5LSop7TxB4giZVjsLo2F5YxAABnMDf2lKBu6vdOnmHauW5xzz023G QCWBxuyQB17HscHt6Yx65dxAkerWV5hmkmtbjTUAPyjLLfb2A74tSvzH+Ic1rIMgjOeg+91xnvjn 8vyqI6twvor/AJ6X29d9fQ1qzcrTabbhCLtrdxjGKbfd2u+q2tuedXcK6T8RdL1ENdtH4l0K40WS GNVGn2cmizXOrLeXBzxd3yXi2aEBiVgjjHyqK9ABYgbcnAUg4+Ylc7/9ncRlV/2v9nmue8W2xn0z 7WqXcsmkXdprMNtZuVmvJNNmW4SyyBu8u7K+XKo4Kkq3FdHCwKoRyuwbWDbgVxu656qflzyWByeK Lcsk1r0/w3tt90m9X2KqyVSlRnLWSg6Ld9W07xk/7yjKEdUlaK0Tuea+PrZ9OfQ/G0EBFx4TvSL1 oLMXuo3fhzWGhttW0mxXzoVia7vYtFvrq4fdsi0vaqndx6LDIJFWRSHR1LBlO9XXaDG6sBtOVxtZ d27GFxzS3drHeWlzbTbjDdQSW8oU7HEUytHJhwQynDNtddrK3zLzzXK+D5Hj02XQ5FjSXw3cf2N5 aPPLixgRH0dzPLK0stxNosthJcSMzMbySb/dpQfLKUbWWjt84rdPq1rfS2zte1OTq4ZN2cqDjFtP /l3JprTtzqV7W+NWS3H+MPDMfizw/e6RMYoZmWC6065ljkmjsda065i1LRdSKQz2sk39marZ2l79 n8yJbhoFjkcQyMrP8H65JrWh2015HLBqtmzafq9ncCGO6tdTtQqTLcwwTXEVu91EYr1Ilmk8uG6h w3p1rDAHGCMc++D19f8A69cDPCnhzxTFdxbIdP8AFrra3S5traCPxBbI0lrKkUMUdxdXusWbXC31 1NLIyx6NZRLsG0MTX7yLva920tm9OW9r2s9u15fIoydSg8O3ZU5SnQv0aX7yGr+GaXT3rxWurv3J XduIGeCGBxjByG4I55zx7V5Dp8TeAPGtzp4WK38JeOr65vdLLXU4fT/GMomvdStI7Z4Joxa67Cl7 qrXUt/aw211bxabZ2Ej3cbL7FGRjGSfmA5ORkKM4LfMRuzyedwNYviPRLfX9KudMuHeIT+U9vcxr G8tleW00d3p99EkySQSTWOoQ215DHPFJbs8KrNDLDuQlS8lB7ax+fwrrbfp231sLC1lB1KdX3qVa PJONr2tKLhOKv8UJJWbd0uaKdpO+t/rCw74GeQeBnDAA8ZI+jY9DxxnjbwZZ+MtK+x3Ye31Cxubf VNB1iD93e6JrdiyS2OpWUiMCGhmjjke3laW0usNBdwz27mNrfhHUb2+sJIdVilt9a0y4fTdWR02J PcQqrxXtvJtVbi1nt5InWS222ouHuYY1VoGVeuXq31/qabiqkWpLT7PRxdlrHyeqI5qmGrQlGbTo zU01rGSVtHe94TVtL2cdGraHA+CvEd/rtlPFrtgdD8S6XOLHXNHEyXUNvdbWEd1YXmyJr/TNSRDc aXey29nPc2jeZcWVrKzRr25QgphCy4cnk7gxI2BT2GA2c+q4zXBeJtHew1CPxnpFvfXGrWFqIdR0 zT5Gdta0XzY2uY2sWEkN1qemhEv9LmhgXVLiW2GjwXX2XULi3m7fT7631OwtL2zcvb3cKyxsVKOu QCUljYbopY2DRzRuN8UwaN1LKQCMnFxhJ3SXLd/a0j5raL1Td77Pe5XhRnavShFxqcspU43jGE7c 3Kt0lpJxbu7LVtpnmnirwfPaa/B8RfCqvbeJLSCKz1rTocfZPF+iwM0h0zUYC0anUbQSTPoWpoyy 2N1Iq3iahYpHYp3eg65pviDSrTVtLuku7C8RXhlQsgPIBWSORUmhnjOFnimjhmhlDLJHE3yjUdWZ wrcjnIyBknsFx243M2RtI2jNefXWkQ+EtVvPFWlRyW+mapMJ/FWmRs5sTKxKnxJbW7FobO8iLGTW pLNIYtQt3ub7UkubuGG5jXJKk3JL3NNPsrRWat108+naxrGrDFUYwlpVp6Qm781la1KV91vyy6X5 b6px9EzxtTBbbxxwcHHXGAD0yP8AexXJa1oNy88Wv6O0drr9sgRgxZbTU7dSWFhfmIbmRclYL3a0 lux80xyIogXrIXilSOSJ0likRJEeM5jdWXejqR1VldSOWXaVqddxyCOPTGPy/wA+lNqE1zRSba01 1X5Wt/WuphTqOlNSjolpJSv7yfLeL6STs1aX5mJo+s22sQmaHdBPDO9peWUwCz2V1CGE0Ey5PzK6 sFZWaORcNG7Kd1bGMlcg89DkjPPf1/TjvyK5fUNLmS5Or6SqR6tEEjmV22W+rWoxi2vlBCiYIP8A QL7as1jIFjkdrGS6t5tjTtSj1CAShHhdCY7q0mXZc2lwoG6GeP5dpPDRkqPMjKyL8rLTjLVr4rR3 t7z6/n/WoVoJuM4NpNJqNr8t7e7pq01pdu/d6a2LmzgvInhuYElhbrG6BvmByGBPzBlP3WUKyN86 tuHHNCe90C4ijud9xoc7rHFdlme40meV1WG2ucLibTpHby4bolZLWQwwzrJHI11F2SnPP5jOccD+ mD+NQToGRlKB1cbGQhWVlYYZWRhtKsMq275QpLN8oNPl97mu/wAP6tbTv5hCpy+60pQ/lv8AC/7v bbe/qns0RgxDMACQdxU55yNvIHPBb5hjr+ImIzhlPToO3X8Mf59qxmLacyGNXayGPNQsztAHO0SW 8jMxaOMjbLAd23dCYfLCybtiNhIiyKSVcAjcOcfTjHf1qjOUUpNwt/X4dOm/8xXaPzYwjxKVONyN h1A6jgj5+cfMdrdJOq7agSOS0Mh3vJCSWWM4LwAgYSMj765z1+bn+LmtOmsMggAZP05oKT3S+Fr4 el+/9dNxsT70DDkEDBPU8DO4YGDnPH8qfk5xjj1z/SoymDvXIIH3ATtyfYf0p6tuHIwe4/z70CHU hAPUUtFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAMUYLD8v8AP4jNPpMDOe5paAKV0p2o4BaSCVHB4wFkYRSn6LFI7fhVwEEAjpj9Ka6hkZcD BUqe+QQQR+RI/GhB8igjoAMf7vH9KlRak30d/wAXcBjqOQQSAu4gAnJ5x6/l6fWsnRFW2sI7AIyp prPp6bvvOlrmIS8ndtmAEi/7Peto4OF6Dt6HHUfl/niqKRLFeSNgkXMauzE9HhwiRjHbYxbnnjlm 7nL76k3olt/X33Hf3Wt+qX966/Rf11tlgFAA3ZGeSACMnjOcAk/d/nXMXCPZa9aX+6RbPUbYabPC ZQLW2u4pZJrS4MeSZbq8eUWjFFbEcMe5guzPUlR17AHI65HP+NULuzS9tjGjeXIux7dwAfJmjO6O UAqyllYZDFT+tKUbu609R05OEnf4XBxkl9rm3fS1n7y816l4jOMngYPc7iew9R/KsjWbBdUsbqwd nAnQtGVeSIpLE8csLiZBui2yqm5R/rIzIPmA21et5/tEMcg4LqOD/A3Q9OpU5+tWyq9SMnGD7/h+ fT1+lUlok9RJyhPmV04uLXrFt9/RPb16mJot3Je2CNcELdwM1pertaLF3bEwTusLqrRQzPG1xall Uy2ssM4+WRa1mIAG4jbgnJPAwCc56LyOC20DGPvYrIeFbPUzPHlbfUiiXK4wn22NFihnJ2ljJNEs Nr94LthX5c7mrYCK4GR+eCAemMd8g+tOKtFJu7Tl+Nrfd28h1I+8qkU1za+i0fKu3vXt95x+r2w0 3UovEdrFEr+QtlroAbzLzTlk32dwzQxySXFxp8rTiyjmVYY4rvUJPMViN3UpJG8SNG+9JdrLICCG 3ANG+8n94CMdG54UZ6VJNFHIHR0VlkXY6kcMpUqVIxyCGP51jWCPZytp7lmiiXNhNIyhmgH7z7Hg Iq4tdxijO3d9mEe5mbc1SopX8/y7FSfPTgvt03rJ9afuq1tfh2jvdW7G1hJFYED5vl5zjHfBHJGf px361xwT/hG9RkX7RcSaRq86+QkgaS00XU8HzFM6lpLax1CMr5Ucix2VncW8n7xZNSVZO0VQFGFz nrzjoTj39fzqvdQxTRSwyDcs0ZX7qMM9chWBXevBjZsqG28fLROKlZp2ad1+i+/deYQn7Png1elK 3uPo9LN2/ld2rdNNiaMkDHLAEA5yCDgAgr91f931OaSVRtYnccfMDgsQUG4nYPmc/KdqqGJPRT1r L02eSJfsVzKZZ4gRFI4HmXFupKxSS7QF+0RhfJuG+VZLiOSRVVWVV2MFjhgSpAI6YBGD/vZz0+nN Nq+jSs/iXX5f8EhxlBtq1/sy8tPnfy6fecXZWtt4TLR24e00C4cSRWwGbTSrm4md5Ut4VDfZrW8l fzGjVVgguPMcMr3TV1oYOMFOCxQliCFA+7yC2VkBDL6A/NtOArri3inikieNJEkBV0dQylWHII9D 1x6nI71mWca2Cx2ZZjDt8u0eTLMqRAfuWbP3UI/cs3zNEVVnd1ZmUYqLdtnr+dzSTjUipcqVSK21 cZPu+8vzt5a7Jw4wCOCDzn39qw7yxkFyNQsnEV9GBHJGxIhv7dfmEFyUDfMhJa1mZS1szyKu1LiT O6FA+uOetLtHORnIwc9wKJJtWREZOLVtu1k/wZRs7uO6j8xEdWUsskMoAnhkUkNG4HynbzhlYo6b HjZ1Kk3s8gY5xn6f56cVQntSsgubbCzrjeOgnjH/ACzbH0+Xgtx19bMEgkXcu4DGGRsbkYfw4A6Y 6HvimlZJdhPlbbirJ7f8P1J6q7DCS8eBHnLIByeecZHH55q1Rgc+/X+VMQwMGAKn14PBP58inDPc Y/HNJtXIOBkdKdQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABSAYAHpS0UAIRnuR+XHuMg81HIudhGflk3YHQkhgcjv1PF S0UAFJt9CRxgDsPcd8/jS0UAUIU8uR0HR28xBjAXBAYcdt5+UcZX15q8DkA+tQNGRhuMq2RyeM/K T07qT24b/vqpwcgH1oG227sq3MHnxunOcblIwCJFIKMM/dZCAy/+zU61kLx/MAHUlXx3I6n165qz UGzy5C4+7IMMB135yG54xjP4n8KAu7W6IlZcj3HSqN1bNMqMm1Z4HWWIkDO5cEx5HzBJFGyTay7l 6+2hRQCbTuiKKQSorrgBxlQQcjHUEcYI/CnMmQcE84yM8EDPHPQc9sdKj2iNtwHEhAYZPyk+g+v+ elT0CKEluc74lQTKNysQCSCSShY/Nhjndtb7x3fxNmzCxZAxwGwA6gkhX4yByeMnr+vUVKQDjI6V C6lG3oB8xw+egH97r1zQNttJPpt/XyJiAQQehqtNaxzLtbJGQcA4GVOUIHI+U8+/8RNWQQRkHIpa BEMbMGMbkEgZGARkf4VNTGXcBzyDkH3H09+tPGe+M+1ACEA9RUZTa/mIPmb5WHYjrnjvx698nvUt FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFIQDjPY5FLRQAUUUUAIRkEetAGA BnOO9LRQAUUUUAIBjgcDP5/5/p6UtFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAH//Z --=====================_814695437==.REL-- From gregory.ietf@gmail.com Sun Nov 8 20:49:41 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683E528C15C for ; Sun, 8 Nov 2009 20:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzNMW0dYV6rK for ; Sun, 8 Nov 2009 20:49:40 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id EF66228C12B for ; Sun, 8 Nov 2009 20:49:35 -0800 (PST) Received: by yxe30 with SMTP id 30so2935372yxe.29 for ; Sun, 08 Nov 2009 20:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:mime-version:content-type; bh=UBXd1p373yGpEzJFoJ6Ah9keMZ7KrkJqEO6oaqJwwGA=; b=PnsHf4fUE0cX0scWpnMFzN+OwVkR/VQFr2+Mp1jPeSX/IhCybi//2kXivOE69+3jXi 5uNYAsjp7oWZuOYjqoEOztFJiymC2tOaEd3D6Xyi71wnX0PSPYK4Gei/ZWf6MzLgMXnu bXKjN54+puvReKLL0NUJ8x5nmFkvBpItMm1Eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:mime-version:content-type; b=k3M/f0JHBVtgf2qWEsL9h4Xhg8mp3OOY+DEGrybctBeBydidsZdXGkZzGGJupX/0NA s4ihBdiTl9DCNvZ5Zbt7gDYGFrcyTgx8kOzQUjM7uWuWUJYjUkCCCttSR6cbutjZ2uDl JSAPGMGzfo06e1gExq4fOZ8ivrlzXvHg3tivI= Received: by 10.150.42.3 with SMTP id p3mr12528664ybp.63.1257742201725; Sun, 08 Nov 2009 20:50:01 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 16sm1196972gxk.3.2009.11.08.20.49.59 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 20:50:01 -0800 (PST) Message-ID: <4af79f79.100bca0a.52ec.3a01@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Nov 2009 20:49:56 -0800 To: karp@ietf.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [karp] Fwd: New Version Notification for draft-lebovitz-kmart-roadmap-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:49:41 -0000 Folks, The window for I-D submissions opened today, so I uploaded ver -03, and it's now posted to the I-D repository. This is the same version that I sent to the email list last week. Gregory. >Delivered-To: gregory.ietf@gmail.com >Authentication-Results: mx.google.com; spf=neutral (google.com: >64.170.98.32 is neither permitted nor denied by best guess record >for domain of wwwrun@core3.amsl.com) smtp.mail=wwwrun@core3.amsl.com >From: IETF I-D Submission Tool >To: gregory.ietf@gmail.com >Subject: New Version Notification for draft-lebovitz-kmart-roadmap-03 >Date: Sun, 8 Nov 2009 20:45:24 -0800 (PST) > > >A new version of I-D, draft-lebovitz-kmart-roadmap-03.txt has been >successfuly submitted by Gregory Lebovitz and posted to the IETF repository. > >Filename: draft-lebovitz-kmart-roadmap >Revision: 03 >Title: Roadmap for Cryptographic Authentication of Routing >Protocol Packets on the Wire >Creation_date: 2009-11-05 >WG ID: Independent Submission >Number_of_pages: 43 > >Abstract: >In the March of 2006 the IAB held a workshop on the topic of >"Unwanted Internet Traffic". The report from that workshop is >documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for >"[t]ightening the security of the core routing infrastructure." Four >main steps were identified for improving the security of the routing >infrastructure. One of those steps was "securing the routing >protocols' packets on the wire." One mechanism for securing routing >protocol packets on the wire is the use of per-packet cryptographic >message authentication, providing both peer authentication and >message integrity. Many different routing protocols exist and they >employ a range of different transport subsystems. Therefore there >must necessarily be various methods defined for applying >cryptographic authentication to these varying protocols. Many >routing protocols already have some method for accomplishing >cryptographic message authentication. However, in many cases the >existing methods are dated, vulnerable to attack, and/or employ >cryptographic algorithms that have been deprecated. This document >creates a roadmap of protocol specification work for the use of >modern cryptogrpahic mechanisms and algorithms for message >authentication in routing protocols. It also defines the framework >for a key management protocol that may be used to create and manage >session keys for message authentication and integrity. This roadmap >reflects the input of both the security area and routing area in >order to form a jointly agreed upon and prioritized work list for the >effort. > >Status of this Memo > >This Internet-Draft is submitted to IETF in full conformance with the >provisions of BCP 78 and BCP 79. > >Internet-Drafts are working documents of the Internet Engineering >Task Force (IETF), its areas, and its working groups. Note that >other groups may also distribute working documents as Internet- >Drafts. >Internet-Drafts are draft documents valid for a maximum of six months >and may be updated, replaced, or obsoleted by other documents at any >time. It is inappropriate to use Internet-Drafts as reference >material or to cite them other than as "work in progress." > >The list of current Internet-Drafts can be accessed at >http://www.ietf.org/ietf/1id-abstracts.txt. > >The list of Internet-Draft Shadow Directories can be accessed at >http://www.ietf.org/shadow.html. > >This Internet-Draft will expire on May 9, 2010. > >Copyright Notice > >Copyright (c) 2009 IETF Trust and the persons identified as the >document authors. All rights reserved. > >This document is subject to BCP 78 and the IETF Trust's Legal >Provisions Relating to IETF Documents >(http://trustee.ietf.org/license-info) in effect on the date of >publication of this document. Please review these documents >carefully, as they describe your rights and restrictions with respect >to this document. Code Components extracted from this document must >include Simplified BSD License text as described in Section 4.e of >the Trust Legal Provisions and are provided without warranty as >described in the BSD License. > > > > >The IETF Secretariat. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m From gregory.ietf@gmail.com Sun Nov 8 20:52:16 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF8E28C100 for ; Sun, 8 Nov 2009 20:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI8eGQ9mNHnH for ; Sun, 8 Nov 2009 20:52:15 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 712D128C0E5 for ; Sun, 8 Nov 2009 20:52:15 -0800 (PST) Received: by ywh13 with SMTP id 13so2936467ywh.29 for ; Sun, 08 Nov 2009 20:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:mime-version:content-type; bh=6BAwREVR3rH+0q5a04CrJswIfcNnhMuxBQ5j/oUZ/CM=; b=qserk3cSJlLrqRP2uTgVWdZMYFxqTrHbARWtkK0dsBts/iRIKy5+TVurKJqeDOd2e4 JFCVFYbrIRuDy4M/aNTsVVdyIDZrrgcbAtNp7rgy9Jnh08rOAi2KmaM/fMFqbxXQEn+t jbePEO6ycXfv6UkuzLvaY50Rce4PjzoFUlV4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:mime-version :content-type; b=lpz7Q0bZQPbp2uFDFeUxV/nEqypXQgaZ4aXeBh/cEzSIB1ggLVXm6gLUYqNMPEtjo8 Tj/hCVhCkcPy5tfaywg9eylg3LN36TSLoVjKGuTXtB9RDgeCFK3IVPLawYSgHwe9ObxV vpU3S0w05nVrJ0r0/VucxrxSbmiurX8NB3ems= Received: by 10.151.18.40 with SMTP id v40mr12577415ybi.11.1257742358455; Sun, 08 Nov 2009 20:52:38 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 14sm1284415gxk.14.2009.11.08.20.52.35 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 20:52:37 -0800 (PST) Message-ID: <4af7a015.0e0bca0a.5229.4354@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Nov 2009 20:52:31 -0800 To: Brian Weis ,"Joel M. Halpern" , Ross Callon From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_824956140==.ALT" Cc: karp@ietf.org Subject: [karp] updating I-D links on KARP BoF and Agenda Pages X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:52:16 -0000 --=====================_824956140==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed BoF Chairs and AD, The ...kmart-roadmap-03.txt has now been posted to the I-D repository. Could you pls update the agenda and BoF pages with the appropriate link? http://www.ietf.org/id/draft-lebovitz-kmart-roadmap-03.txt Thanks, Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_824956140==.ALT Content-Type: text/html; charset="us-ascii" BoF Chairs and AD,
The ...kmart-roadmap-03.txt has now been posted to the I-D repository. Could you pls update the agenda and BoF pages with the appropriate link?

    http://www.ietf.org/id/draft-lebovitz-kmart-roadmap-03.txt

Thanks,
Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_824956140==.ALT-- From bill@cse.concordia.ca Sun Nov 8 21:00:15 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC9D28C17A for ; Sun, 8 Nov 2009 21:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUOvrQKRxo+G for ; Sun, 8 Nov 2009 21:00:14 -0800 (PST) Received: from perseverance.services.encs.concordia.ca (perseverance-96.encs.concordia.ca [132.205.96.94]) by core3.amsl.com (Postfix) with ESMTP id 49A6E28C185 for ; Sun, 8 Nov 2009 21:00:14 -0800 (PST) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.208]) by perseverance.services.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id nA950dn0003007 for ; Mon, 9 Nov 2009 00:00:39 -0500 Message-ID: <4AF7A1FC.2060304@cse.concordia.ca> Date: Mon, 09 Nov 2009 00:00:44 -0500 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: karp@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2009/11/09 00:00:39 EST Subject: [karp] On-the-wire security for PIM-SM X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:00:15 -0000 Hello, In keeping with the goals of the KARP effort, I wish to report a small increment in the achievement of the first phase KARP goals. draft-ietf-pim-sm-linklocal (Authentication and Confidentiality in PIM-SM Link-local Communication) defines the router-to-router (link-local) communication for PIM-SM. It is currently in IESG Last Call. (Any comments from routing or security folks will be appreciated!) This past summer, a student in my laboratory has implemented the procedures described in the Internet-Draft. The XORP (software) router on Linux-based platforms was used to provide the multicast routing, and the setkey() function in the Linux kernel was used to manually establish the keys and parameters for the IPsec multicast security association. Interestingly, the required security is achieved entirely with IPsec rules---there was no need to modify the PIM-SM source code. This fall, another student is duplicating the implementation using hardware routers. Given our experience with the software routing, it is expected that the project will require only the use of the IPsec commands to achieve the security (at least for manually-specified keys). The Internet-Draft for PIM-SM security is heavily based on RFC 4552 (Authentication/Confidentiality for OSPFv3). However, it goes somewhat beyond RFC 4552 in that it explicitly acknowledges that while manual keying is all that we can do for now, automated keying is very much desired in a future revision. This is in keeping with the second set of KARP goals. In the future, we expect to explore possible solutions to the automated key management issues that form the second phase KARP goals. I thank those who commented a couple of weeks ago on my paper about AKM issues. Bill -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From gregory.ietf@gmail.com Sun Nov 8 21:40:01 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1B73A6AEA for ; Sun, 8 Nov 2009 21:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3El0N8HG+5AA for ; Sun, 8 Nov 2009 21:40:00 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 4CAD63A6AE7 for ; Sun, 8 Nov 2009 21:40:00 -0800 (PST) Received: by yxe30 with SMTP id 30so2960862yxe.29 for ; Sun, 08 Nov 2009 21:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=PVcSPWpbEJMCTGYIxZe/0F8Ljk8NeGviGm2/XVjzYq0=; b=k4aGrem8pgt6B7c/dn+x420CU+UQJ5Djqfsre8W6k6KGmuIqEMz9TGkGQcjOAvyErj 7KD0EFSNKrqMtiTiNfiHAFTmWZzTFhJNDD5/oV0iCl691aWaHZJ72IO9y0O93oFVeGfq Zl4PjgUMfy0tsHcZClxKFn5sWiNDfuNFl/T0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=IOvcocxB74olImWHAHHfdE40h6qAfqEffByWLi15emNHilAoeTAc3xYFN+1ixU6Niq 0nBSAXcR2skQFPmaZlkIJm6IrC8UyXnI37nDizoLN8mbnD15s+aMo/Dtg52n3Ii+QQ35 OJLbyqWTseGgWcf90R2VGRNRUUbTUejynylZc= Received: by 10.150.125.3 with SMTP id x3mr12589848ybc.28.1257745221864; Sun, 08 Nov 2009 21:40:21 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 15sm1213852gxk.0.2009.11.08.21.40.19 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 21:40:21 -0800 (PST) Message-ID: <4af7ab45.0f0bca0a.3785.3c6e@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 08 Nov 2009 21:40:14 -0800 To: Bill Atwood ,karp@ietf.org, Brian Weis From: "Gregory M. Lebovitz" In-Reply-To: <4AF7A1FC.2060304@cse.concordia.ca> References: <4AF7A1FC.2060304@cse.concordia.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [karp] On-the-wire security for PIM-SM X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 05:40:01 -0000 Bill, Good stuff. Are you presenting this document this week in either PIM-SM, or MSEC? Brian - is this document on your list for the survey you will be presenting at the BoF tomorrow? Gregory. At 09:00 PM 11/8/2009, Bill Atwood wrote: >Hello, > >In keeping with the goals of the KARP effort, I wish to report a small >increment in the achievement of the first phase KARP goals. > >draft-ietf-pim-sm-linklocal (Authentication and Confidentiality in >PIM-SM Link-local Communication) defines the router-to-router >(link-local) communication for PIM-SM. It is currently in IESG Last >Call. (Any comments from routing or security folks will be appreciated!) > >This past summer, a student in my laboratory has implemented the >procedures described in the Internet-Draft. The XORP (software) router >on Linux-based platforms was used to provide the multicast routing, and >the setkey() function in the Linux kernel was used to manually establish >the keys and parameters for the IPsec multicast security association. >Interestingly, the required security is achieved entirely with IPsec >rules---there was no need to modify the PIM-SM source code. > >This fall, another student is duplicating the implementation using >hardware routers. Given our experience with the software routing, it is >expected that the project will require only the use of the IPsec >commands to achieve the security (at least for manually-specified keys). > >The Internet-Draft for PIM-SM security is heavily based on RFC 4552 >(Authentication/Confidentiality for OSPFv3). However, it goes somewhat >beyond RFC 4552 in that it explicitly acknowledges that while manual >keying is all that we can do for now, automated keying is very much >desired in a future revision. This is in keeping with the second set of >KARP goals. > >In the future, we expect to explore possible solutions to the automated >key management issues that form the second phase KARP goals. I thank >those who commented a couple of weeks ago on my paper about AKM issues. > > Bill > >-- > >Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >Distinguished Professor Emeritus fax: +1 (514) 848-2830 >Department of Computer Science > and Software Engineering >Concordia University EV 3.185 email: bill@cse.concordia.ca >1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill >Montreal, Quebec Canada H3G 1M8 >_______________________________________________ >karp mailing list >karp@ietf.org >https://www.ietf.org/mailman/listinfo/karp From bew@cisco.com Mon Nov 9 05:20:56 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CCF3A680F for ; Mon, 9 Nov 2009 05:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4qwMeyR-zJv for ; Mon, 9 Nov 2009 05:20:55 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 616003A67E2 for ; Mon, 9 Nov 2009 05:20:55 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJCm90pAaHte/2dsb2JhbACBTsQJiSkJjSKCVIFqBIFoeA X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="scan'208";a="48606432" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2009 13:21:20 +0000 Received: from host-113-114.meeting.ietf.org (tky-vpn-client-230-86.cisco.com [10.70.230.86]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA9DLJJV014534; Mon, 9 Nov 2009 13:21:19 GMT Message-Id: <2237FD58-B743-42F9-BD9E-008428F275D3@cisco.com> From: Brian Weis To: Bill Atwood In-Reply-To: <4af7ab45.0f0bca0a.3785.3c6e@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 22:21:19 +0900 References: <4AF7A1FC.2060304@cse.concordia.ca> <4af7ab45.0f0bca0a.3785.3c6e@mx.google.com> X-Mailer: Apple Mail (2.936) Cc: karp@ietf.org Subject: Re: [karp] On-the-wire security for PIM-SM X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:20:56 -0000 Hi Bill & Gregory, Thanks for the reminder of the link-local draft. I have added it to the Survey of methods for PIM-SM. Brian On Nov 9, 2009, at 2:40 PM, Gregory M. Lebovitz wrote: > Bill, > Good stuff. Are you presenting this document this week in either PIM- > SM, or MSEC? > > Brian - is this document on your list for the survey you will be > presenting at the BoF tomorrow? > > Gregory. > > At 09:00 PM 11/8/2009, Bill Atwood wrote: >> Hello, >> >> In keeping with the goals of the KARP effort, I wish to report a >> small >> increment in the achievement of the first phase KARP goals. >> >> draft-ietf-pim-sm-linklocal (Authentication and Confidentiality in >> PIM-SM Link-local Communication) defines the router-to-router >> (link-local) communication for PIM-SM. It is currently in IESG Last >> Call. (Any comments from routing or security folks will be >> appreciated!) >> >> This past summer, a student in my laboratory has implemented the >> procedures described in the Internet-Draft. The XORP (software) >> router >> on Linux-based platforms was used to provide the multicast routing, >> and >> the setkey() function in the Linux kernel was used to manually >> establish >> the keys and parameters for the IPsec multicast security association. >> Interestingly, the required security is achieved entirely with IPsec >> rules---there was no need to modify the PIM-SM source code. >> >> This fall, another student is duplicating the implementation using >> hardware routers. Given our experience with the software routing, >> it is >> expected that the project will require only the use of the IPsec >> commands to achieve the security (at least for manually-specified >> keys). >> >> The Internet-Draft for PIM-SM security is heavily based on RFC 4552 >> (Authentication/Confidentiality for OSPFv3). However, it goes >> somewhat >> beyond RFC 4552 in that it explicitly acknowledges that while manual >> keying is all that we can do for now, automated keying is very much >> desired in a future revision. This is in keeping with the second >> set of >> KARP goals. >> >> In the future, we expect to explore possible solutions to the >> automated >> key management issues that form the second phase KARP goals. I thank >> those who commented a couple of weeks ago on my paper about AKM >> issues. >> >> Bill >> >> -- >> >> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >> Distinguished Professor Emeritus fax: +1 (514) 848-2830 >> Department of Computer Science >> and Software Engineering >> Concordia University EV 3.185 email: bill@cse.concordia.ca >> 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/ >> ~bill >> Montreal, Quebec Canada H3G 1M8 >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp > -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bill@cse.concordia.ca Mon Nov 9 06:42:28 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DBA3A692E for ; Mon, 9 Nov 2009 06:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TqwIFo-g6+4 for ; Mon, 9 Nov 2009 06:42:27 -0800 (PST) Received: from perseverance.services.encs.concordia.ca (perseverance-96.encs.concordia.ca [132.205.96.94]) by core3.amsl.com (Postfix) with ESMTP id CD1A23A63C9 for ; Mon, 9 Nov 2009 06:42:26 -0800 (PST) Received: from [IPv6:::1] (bill@grace.encs.concordia.ca [132.205.2.208]) by perseverance.services.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id nA9EgTmL009677; Mon, 9 Nov 2009 09:42:29 -0500 Message-ID: <4AF82A5B.3070900@cse.concordia.ca> Date: Mon, 09 Nov 2009 09:42:35 -0500 From: Bill Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <4AF7A1FC.2060304@cse.concordia.ca> <4af7ab45.0f0bca0a.3785.3c6e@mx.google.com> In-Reply-To: <4af7ab45.0f0bca0a.3785.3c6e@mx.google.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2009/11/09 09:42:30 EST Cc: Stig Venaas , Mike McBride , karp@ietf.org Subject: Re: [karp] On-the-wire security for PIM-SM X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:42:28 -0000 As I am not attending IETF 76, I have no presentation planned. I assume that Mike/Stig will note the IESG Last Call status during the PIM WG meeting :-) Bill Mike/Stig: You might want to note the "implementation experience" reported below, for benefit of those PIM WG members who are not listening to the karp mailing list. I leave the decision to you. Bill Gregory M. Lebovitz wrote: > Bill, > Good stuff. Are you presenting this document this week in either PIM-SM, > or MSEC? > > Brian - is this document on your list for the survey you will be > presenting at the BoF tomorrow? > > Gregory. > > At 09:00 PM 11/8/2009, Bill Atwood wrote: >> Hello, >> >> In keeping with the goals of the KARP effort, I wish to report a small >> increment in the achievement of the first phase KARP goals. >> >> draft-ietf-pim-sm-linklocal (Authentication and Confidentiality in >> PIM-SM Link-local Communication) defines the router-to-router >> (link-local) communication for PIM-SM. It is currently in IESG Last >> Call. (Any comments from routing or security folks will be appreciated!) >> >> This past summer, a student in my laboratory has implemented the >> procedures described in the Internet-Draft. The XORP (software) router >> on Linux-based platforms was used to provide the multicast routing, and >> the setkey() function in the Linux kernel was used to manually establish >> the keys and parameters for the IPsec multicast security association. >> Interestingly, the required security is achieved entirely with IPsec >> rules---there was no need to modify the PIM-SM source code. >> >> This fall, another student is duplicating the implementation using >> hardware routers. Given our experience with the software routing, it is >> expected that the project will require only the use of the IPsec >> commands to achieve the security (at least for manually-specified keys). >> >> The Internet-Draft for PIM-SM security is heavily based on RFC 4552 >> (Authentication/Confidentiality for OSPFv3). However, it goes somewhat >> beyond RFC 4552 in that it explicitly acknowledges that while manual >> keying is all that we can do for now, automated keying is very much >> desired in a future revision. This is in keeping with the second set of >> KARP goals. >> >> In the future, we expect to explore possible solutions to the automated >> key management issues that form the second phase KARP goals. I thank >> those who commented a couple of weeks ago on my paper about AKM issues. >> >> Bill >> >> -- >> >> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >> Distinguished Professor Emeritus fax: +1 (514) 848-2830 >> Department of Computer Science >> and Software Engineering >> Concordia University EV 3.185 email: bill@cse.concordia.ca >> 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill >> Montreal, Quebec Canada H3G 1M8 >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From vnktshsriram@gmail.com Mon Nov 9 08:52:30 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0978A3A6B6C for ; Mon, 9 Nov 2009 08:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93yoGUYZqj2g for ; Mon, 9 Nov 2009 08:52:29 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 3F8A13A6B7B for ; Mon, 9 Nov 2009 08:52:29 -0800 (PST) Received: by qyk41 with SMTP id 41so1488385qyk.29 for ; Mon, 09 Nov 2009 08:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=0wNLNwWuU5dWLlgjrCRESXqdvEC4Ihe+Dqvir/k7eaw=; b=XZI/dIyDlRmZYK/7iR77MKUg4onbMEZbh/ZIebfP8Qe1SgRyIlPhy5E0bkxD1lVjyR 1TMFEXzMTdyhEYOLFv4XvfFH7XjTcbrKnatDB4NQ7oCnbrHsJrTiN2ZH1/U3/9WhiqIU zdVLE1jvMPEW8evfs/RxnHfu+24EmkcpXE9UU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cxpa/X2RTiryuD5oEbQ/XuUFiQEWb7uu11MzZ6KWj3J6U+CWDPHj64kNj+sc2mbSI2 5nOsAGTdo3VEJifYuAEFacAX5qd54/oqe3nU+jVgsKPDyKeEW3mvUq8HS0k+LObr/qQC CxCnBPwKvgxiCp+OvSqBCCZJDhq//MiYaCeoo= MIME-Version: 1.0 Received: by 10.224.0.157 with SMTP id 29mr4238885qab.373.1257785572070; Mon, 09 Nov 2009 08:52:52 -0800 (PST) Date: Mon, 9 Nov 2009 22:22:52 +0530 Message-ID: From: Venkatesh Sriram To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:52:30 -0000 Morning KARPers, I was reading RFC 5310 (ISIS Generic Cryptographic Authentication) and comparing it with RFC 5709 (OSPF HMAC-SHA authentication) . Both deal with similar ideas and add support for SHS family of authentication algorithms for ISIS and OSPF. However, while the latter RFC is very clear on what algorithm (hmac-sha-1/256/512) MUST and SHOULD be implemented, there is no clear indication in RFC 5310 on what kind of algorithms MUST and SHOULD be implemented for ISIS. Can we have some clarity there? I would wager that KARP is indeed the right forum to address such issues. I would believe that the set of algorithms for authenticating OSPF and ISIS should be similar and see no reason that while HMAC-SHA-256 is recommended for OSPF, there is none mandated or recommended for ISIS. Sriram From vnktshsriram@gmail.com Mon Nov 9 08:56:56 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD463A6891 for ; Mon, 9 Nov 2009 08:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n5u5KsJPBJO for ; Mon, 9 Nov 2009 08:56:56 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id E6F093A6BA4 for ; Mon, 9 Nov 2009 08:56:55 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so694658qwb.31 for ; Mon, 09 Nov 2009 08:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=i9/YqcdDjKqMA5J+3c+vKbYH7furlgPCSOILumi+6yE=; b=VD5WO2erL9Hu34uZjSykOiarIcYEmuMRVzrKbSvluYcJzYsgPWlBySBY3wiX2cdNw9 rXszPRp93l2sukmU/P9DfC93yFAdOSMpYEQDTv4GzDMMSaoDoUIdhK7YBoonlKVA0mFi siVqhEJPP2mtHVbpPWFzLtkBNEs9qhoLwJ/g0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BXv1zow/juOLGVLor6EaW18qr2lUiitHs87MOF18oaZG65qUpC3wZPsZUwitDbph1j fFov8zCIS/S0Ian4WLp1EqPAmMLLKIKcYXtuWLelT6ZhoOqW8ZllXQtX3VtrXMhmd4vq UQNc2YduEy6d0B2n/5b0hknkRb9zbYE3720K8= MIME-Version: 1.0 Received: by 10.224.81.138 with SMTP id x10mr4199994qak.299.1257785837850; Mon, 09 Nov 2009 08:57:17 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Nov 2009 22:27:17 +0530 Message-ID: From: Venkatesh Sriram To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:56:56 -0000 .. Include RFC4822 - "RIPv2 Cryptographic Authentication" too in the list. Sriram On Mon, Nov 9, 2009 at 10:22 PM, Venkatesh Sriram wrote: > Morning KARPers, > > I was reading RFC 5310 (ISIS Generic Cryptographic Authentication) and > comparing it with RFC 5709 (OSPF HMAC-SHA authentication) . Both deal > with similar ideas and add support for SHS family of authentication > algorithms for ISIS and OSPF. However, while the latter RFC is very > clear on what algorithm (hmac-sha-1/256/512) MUST and SHOULD be > implemented, there is no clear indication in RFC 5310 on what kind of > algorithms MUST and SHOULD be implemented for ISIS. Can we have some > clarity there? I would wager that KARP is indeed the right forum to > address such issues. > > I would believe that the set of algorithms for authenticating OSPF and > ISIS should be similar and see no reason that while HMAC-SHA-256 is > recommended for OSPF, there is none mandated or recommended for ISIS. > > Sriram > From christopher.morrow@gmail.com Mon Nov 9 08:58:57 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07903A69B2 for ; Mon, 9 Nov 2009 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V53pDFv38xmp for ; Mon, 9 Nov 2009 08:58:57 -0800 (PST) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 223663A6891 for ; Mon, 9 Nov 2009 08:58:57 -0800 (PST) Received: by iwn40 with SMTP id 40so2623708iwn.32 for ; Mon, 09 Nov 2009 08:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=JXQESHSOBeFcXchuTkMB7Xl2/iTOGzPxDDvKocDIoeU=; b=IN0D3zLgbsVsleotL1BZgcMIyhArh7ycplVNWlR0YB6ltz81YZpvpOzEN7ULB1qwmp ViPJHSlUrpf5KiAwmjLhoGWcAAkYIKcD30uCO1AgcYU85lv6jYchzG931CJZGaH7ZDwl AfkvJS/JOi+RGQa+sUiZIzJY70kT21k6yQyFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RpL59R+7kWjCGVKM39BIJhr0G/cO+Q37+EjSEikUQxlbzPpZwF367jcGKaUPQnu+VI v2bGcRyqqk9o1KxQkJBGYb4tbJ63aeHTNenT57G4oweNLZG6U0t9ejp/4/z2RS9LTyN7 bWMpiElDAH0qzHqKp1pislNfCRN/UgI5KV1n0= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.231.73.131 with SMTP id q3mr384790ibj.6.1257785961012; Mon, 09 Nov 2009 08:59:21 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Nov 2009 11:59:20 -0500 X-Google-Sender-Auth: 2504a2d8f4eca6ce Message-ID: <75cb24520911090859x46a3b9c6s218aac37a1324b85@mail.gmail.com> From: Christopher Morrow To: Venkatesh Sriram Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: karp@ietf.org Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:58:58 -0000 On Mon, Nov 9, 2009 at 11:52 AM, Venkatesh Sriram wrote: > Morning KARPers, > > I was reading RFC 5310 (ISIS Generic Cryptographic Authentication) and > comparing it with RFC 5709 (OSPF HMAC-SHA authentication) . Both deal > with similar ideas and add support for SHS family of authentication > algorithms for ISIS and OSPF. However, while the latter RFC is very > clear on what algorithm (hmac-sha-1/256/512) MUST and SHOULD be > implemented, there is no clear indication in RFC 5310 on what kind of > algorithms MUST and SHOULD be implemented for ISIS. Can we have some > clarity there? I would wager that =A0KARP is indeed the right forum to > address such issues. > > I would believe that the set of algorithms for authenticating OSPF and > ISIS should be similar and see no reason that while HMAC-SHA-256 is > recommended for OSPF, there is none mandated or recommended for ISIS. as a question... are you asking that someone put in a 'must' list? Should KARP work toward defining that list? or defining the state where 'a list' can be used, and 'that list can change as future requirements/algoritms arise'? I see that: "There should be a list, as a starter, and that list will be changing. plan accordingly.' is important. I'm not sure that 'the list' is the important part here. (to me at least) -chris From vnktshsriram@gmail.com Mon Nov 9 09:20:37 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0113A67B2 for ; Mon, 9 Nov 2009 09:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23r9xvE2qgPM for ; Mon, 9 Nov 2009 09:20:36 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 63BA73A6403 for ; Mon, 9 Nov 2009 09:20:36 -0800 (PST) Received: by qyk41 with SMTP id 41so1501589qyk.29 for ; Mon, 09 Nov 2009 09:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zfeDAzK9IFDV2rz++Ml7d4v55KUMtin0qoZBfLn6Is4=; b=iyqBik9AoPBIN0UKVolF8pzz9vNQccmWyryOQgI13bBMCnSF3FDPcNQfA0uMJFMrkx vNE4lHBxs0og4WveoMjia4Z0IF9Ih69QgGCyoKUjsvieqSb5CCeXh3teX4Z28o98VPrO qUUXGvp5iIUuq0/oJ5ZNPVY2gwTxCalyBHsas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ij9st2IGtfK3w15pHw9xmyTuqEnFNDh/JSeAyPlZUJI1ZX9cxnvFNPySrChp2tDo8M sCo12WLfV1xp9HySuPE+WF4LsaLUD7Jpi8dwcSWNLls3UrnrANWPWG2VnAQ9AJ/PhWgg sf2o1xxiOwKaePYVMkH4nyTT0C01wCY7/Vg7I= MIME-Version: 1.0 Received: by 10.224.96.100 with SMTP id g36mr4236593qan.384.1257787257512; Mon, 09 Nov 2009 09:20:57 -0800 (PST) In-Reply-To: <75cb24520911090859x46a3b9c6s218aac37a1324b85@mail.gmail.com> References: <75cb24520911090859x46a3b9c6s218aac37a1324b85@mail.gmail.com> Date: Mon, 9 Nov 2009 22:50:57 +0530 Message-ID: From: Venkatesh Sriram To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:20:37 -0000 Chris, > as a question... are you asking that someone put in a 'must' list? > Should KARP work toward defining that list? or defining the state > where 'a list' can be used, and 'that list can change as future > requirements/algoritms arise'? The list will be dynamic and will obviously change with time as new algorithms come and the older ones get deprecated. KARP must develop protocols keeping this flux in mind. Additionally, we must also have this list somewhere. This could either be maintained by the individual WGs (RIP, ISIS, OSPF, etc) or we could have one WG that keeps track of this. Sriram > > I see that: "There should be a list, as a starter, and that list will > be changing. plan accordingly.' is important. I'm not sure that 'the > list' is the important part here. (to me at least) From christopher.morrow@gmail.com Mon Nov 9 09:49:11 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C64128C1F1 for ; Mon, 9 Nov 2009 09:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMN-j5qWx5OU for ; Mon, 9 Nov 2009 09:49:10 -0800 (PST) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id BB8F728C0DF for ; Mon, 9 Nov 2009 09:49:10 -0800 (PST) Received: by iwn40 with SMTP id 40so2669779iwn.32 for ; Mon, 09 Nov 2009 09:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=alkeo6KEyY00d0G8lZQ5EEw8ebhc+Vl1zdnbivoHV2s=; b=XV0pvJ/IZIA+YTWCXM5DYY9DOTrZyOLc5Isr0GEgGOa1KUK1V+YyIb2rS0NGbKCaGJ OVbIf/M8OJjloXXO+KgLreQvdmkPX+k3EmVJ6JjKElYUQOBZK8yWbT+q+/jk30ei7LU0 10CJZaohvPo53Rzk759BKqqxdh2nzHd206TKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=dvnBYAbeZkbl7DbFTZJikCtpBium06WkwXLSj1+iq0hoAnzZGveNh1H/HeIpLppQ7F GkyBcbEePPXZ/+NHKYXiE8NR4CmAhM9zoxG7cn9ZSnZghMQ1M6dSSRBpmjvaffm6++Bb 4SuvgSshlT+8OoAhvijsCeIdy5R6qIvHBnOkc= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.231.120.90 with SMTP id c26mr170469ibr.1.1257788973847; Mon, 09 Nov 2009 09:49:33 -0800 (PST) In-Reply-To: References: <75cb24520911090859x46a3b9c6s218aac37a1324b85@mail.gmail.com> Date: Mon, 9 Nov 2009 12:49:33 -0500 X-Google-Sender-Auth: 2d66721da41d11b6 Message-ID: <75cb24520911090949p65cbfd3cwaedb65b6ca1eb8cf@mail.gmail.com> From: Christopher Morrow To: Venkatesh Sriram Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:49:11 -0000 On Mon, Nov 9, 2009 at 12:20 PM, Venkatesh Sriram wrote: > Chris, > >> as a question... are you asking that someone put in a 'must' list? >> Should KARP work toward defining that list? or defining the state >> where 'a list' can be used, and 'that list can change as future >> requirements/algoritms arise'? > > The list will be dynamic and will obviously change with time as new > algorithms come and the older ones get deprecated. KARP must develop > protocols keeping this flux in mind. good. > Additionally, we must also have this list somewhere. This could either > be maintained by the individual WGs (RIP, ISIS, OSPF, etc) or we could > have one WG that keeps track of this. I favor the one-ring approach... > Sriram > >> >> I see that: "There should be a list, as a starter, and that list will >> be changing. plan accordingly.' is important. I'm not sure that 'the >> list' is the important part here. (to me at least) > From vnktshsriram@gmail.com Mon Nov 9 10:00:45 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8831128C12F for ; Mon, 9 Nov 2009 10:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSafOTp1N0Hb for ; Mon, 9 Nov 2009 10:00:44 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id AFB193A6879 for ; Mon, 9 Nov 2009 10:00:44 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so707135qwb.31 for ; Mon, 09 Nov 2009 10:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WtvQBjMHvPdzfe4H3dq2UN5JgYatL8eHOnLApBvCWwc=; b=VRJbYrWj/co7xS53YBXmwd5kr6qRgG1nrCTM2lO8QqZvS4pTSOapcyggmJBzRSPHrl FmrQ2SWuD9Bux/prb4j6LKKY+w/bKUnhpYu5kpypjkh2xIBvOj/gHaT8Lv7ujGd6QVsj uf/AYdYU3ApgXJfsfluawa7dinLM8rRvB2diA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aSv8/nKAuheVNeT1+FS77HD7i0heySHDI8cZF9askwVx0o19+9YqSl/via+57q7XEu mJKmmFA+eDVaBCwXlj0rxTz+Va4ykczUE/hiChP770x3JUYJzUEpZK/v81xF+tlbZRk2 oeDeBuClvhoekvW+St5f2pKhiuiNNlWIHVQL8= MIME-Version: 1.0 Received: by 10.224.56.145 with SMTP id y17mr4244494qag.317.1257789667522; Mon, 09 Nov 2009 10:01:07 -0800 (PST) In-Reply-To: <75cb24520911090949p65cbfd3cwaedb65b6ca1eb8cf@mail.gmail.com> References: <75cb24520911090859x46a3b9c6s218aac37a1324b85@mail.gmail.com> <75cb24520911090949p65cbfd3cwaedb65b6ca1eb8cf@mail.gmail.com> Date: Mon, 9 Nov 2009 23:31:07 +0530 Message-ID: From: Venkatesh Sriram To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:00:45 -0000 > >> Additionally, we must also have this list somewhere. This could either >> be maintained by the individual WGs (RIP, ISIS, OSPF, etc) or we could >> have one WG that keeps track of this. > > I favor the one-ring approach... Same here, which is why i posted this in KARP. Is this then a candidate for addition to the charter? Sriram From vishwas.ietf@gmail.com Mon Nov 9 12:42:39 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652CB28C201 for ; Mon, 9 Nov 2009 12:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drgg+nSiOufC for ; Mon, 9 Nov 2009 12:42:38 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 7964E3A687B for ; Mon, 9 Nov 2009 12:42:38 -0800 (PST) Received: by gxk28 with SMTP id 28so26294gxk.9 for ; Mon, 09 Nov 2009 12:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=+d67ACqaubup+PRSs6e3B0ZzSWAAzT/yzu0hOfW7PO0=; b=DviuEOa5shr2jr4VX1pBOF0hThsOp0ucgiz/Q5nSQ0KsGfhXZ/DORd4aIbErm5leeH vdDH9OrcyerZT9tsRx6N+zr+kUNjUKW/a1MVOaSjIhA2ji3TAMWgEOHymag/Mv4JYSw+ c1+7Ulw8zSH4z+iVLAXMCzFsUG4cJp48w7PvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QnHuxR/lxIfzJRmDpCdJ/azQck1d3Dv6B+ZNgVkTlwKgblSu7uOkh9Njzn+u8881rk 3I3sfbvoyRQX89cEaIQqOSIL91cqZPK9+xP5JzTeA6+YaGXqLy3jwfgOGb7543zuaaqj qPxpGiEHDJrm6kDcRZsIL7RnWrG38Iht6opjU= MIME-Version: 1.0 Received: by 10.150.72.25 with SMTP id u25mr14302627yba.57.1257799382362; Mon, 09 Nov 2009 12:43:02 -0800 (PST) Date: Mon, 9 Nov 2009 12:43:02 -0800 Message-ID: <77ead0ec0911091243h663c087cvbf704e1c28b1de8e@mail.gmail.com> From: Vishwas Manral To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:42:39 -0000 Hi Chris/ Sriram, I just subscribed to the KARP list and noticed the conversation: I agree with Sriram that we need the same set of authentication algorithms for all the routing protocols as their requirements are the same. Infact we have a draft that states the same however as we did not have a central WG doing all Routing protocols because of which the draft has not gone too far. http://ietfreport.isoc.org/all-ids/draft-bhatia-manral-igp-crypto-requirements-03.txt Thanks, Vishwas From vishwas.ietf@gmail.com Mon Nov 9 12:47:57 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4223A68F8 for ; Mon, 9 Nov 2009 12:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLIKooLljW49 for ; Mon, 9 Nov 2009 12:47:57 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id D5FF03A685A for ; Mon, 9 Nov 2009 12:47:56 -0800 (PST) Received: by yxe30 with SMTP id 30so3660294yxe.29 for ; Mon, 09 Nov 2009 12:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=pRoXFu4sN2q5TTG3zNLu+BwyMGgwdglHSNfgvEJB/qE=; b=i4ZH4lQP0vl8lSn0xNuxjjHUIIczuZA1iD3hDOBbIb/ef8+/OYKhwWLT6+e87nbNTo BONDgL0JqkrQQW3EWb9OFA1NllpHyO20STj2YlV+8h+vW/n9ebuxvIPgpchGYzhuMIZe eI7hi8lZ0dBpCvYV9kjVoQ/sunlimnzxQUOAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=xEkOITdaFB6zu0BWUdKpWZdlZ5Np5/Q3hyJJFj/3EZrtcc+JGWJOFg4xCiEW5u0hDH czNROOPPQiq4NFGsGQs40/fkaEuKXcpRvL2wdeanp+uw1fVlgifaV9V3aIBcPeIyzzSM iYCNQV0ejJ8IcC6naLGxHHdJrV/wrlr5Bxzjc= MIME-Version: 1.0 Received: by 10.150.119.42 with SMTP id r42mr14255975ybc.68.1257799698822; Mon, 09 Nov 2009 12:48:18 -0800 (PST) In-Reply-To: <77ead0ec0911091243h663c087cvbf704e1c28b1de8e@mail.gmail.com> References: <77ead0ec0911091243h663c087cvbf704e1c28b1de8e@mail.gmail.com> Date: Mon, 9 Nov 2009 12:48:18 -0800 Message-ID: <77ead0ec0911091248w446eb0f8yf8a8ed509c7ce79@mail.gmail.com> From: Vishwas Manral To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:47:57 -0000 Hi, Infact look at version 02 it aligns even better for the discussion here. http://ietfreport.isoc.org/all-ids/draft-bhatia-manral-igp-crypto-requirements-02.txt Thanks, Vishwas On Mon, Nov 9, 2009 at 12:43 PM, Vishwas Manral wrote: > Hi Chris/ Sriram, > > I just subscribed to the KARP list and noticed the conversation: > > I agree with Sriram that we need the same set of authentication > algorithms for all the routing protocols as their requirements are the > same. Infact we have a draft that states the same however as we did > not have a central WG doing all Routing protocols because of which the > draft has not gone too far. > > http://ietfreport.isoc.org/all-ids/draft-bhatia-manral-igp-crypto-requirements-03.txt > > Thanks, > Vishwas > From vnktshsriram@gmail.com Mon Nov 9 16:12:50 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F3E3A69A4 for ; Mon, 9 Nov 2009 16:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI7i+GnjCwxC for ; Mon, 9 Nov 2009 16:12:49 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id C2DE03A677E for ; Mon, 9 Nov 2009 16:12:48 -0800 (PST) Received: by qyk29 with SMTP id 29so1432025qyk.32 for ; Mon, 09 Nov 2009 16:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rmPdwP78PbK+AqsFPSp1YZc4uUd1uE5xiQyaqsMrtwU=; b=cJip24UkK7mvTeiKs0x9TWpwi94yNCx3LjcWM3kE9LHDQ+4eLDtM/q5/GiXmL+ezhL P4m2jcXy2jQXzefMqYjhTsRldBdDNsYbAOuhOdqBeK4YcCNTWSee9BXm1ZqgZn5BLzPd VxDwYE6LqoxKJOdoVpn4Ui1vr3X+EvplT40QY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EDAjje7RcL5CwHnokw0+EsEAyHV+Uc9Q9MWH6xmFBimvIFi6Pozt6QQrssIdv7wdvL De+70YLxWUcewZI6Kqlet+7ujaIpuILlpVrXbvwMBdu4xT2Z5mhLJujJZzrNHv0w4v4W VH1qPwkXHiQwXG2jq4rR9qSu+DD0IadUVCs1o= MIME-Version: 1.0 Received: by 10.224.73.78 with SMTP id p14mr4480635qaj.56.1257811992714; Mon, 09 Nov 2009 16:13:12 -0800 (PST) In-Reply-To: <77ead0ec0911091248w446eb0f8yf8a8ed509c7ce79@mail.gmail.com> References: <77ead0ec0911091243h663c087cvbf704e1c28b1de8e@mail.gmail.com> <77ead0ec0911091248w446eb0f8yf8a8ed509c7ce79@mail.gmail.com> Date: Tue, 10 Nov 2009 05:43:12 +0530 Message-ID: From: Venkatesh Sriram To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:12:50 -0000 Thank You Vishwas. This is exactly what i was looking for. I see that these documents have all expired. Are there plans to resurrect them? Let me know if you need help in doing that .. Sriram On Tue, Nov 10, 2009 at 2:18 AM, Vishwas Manral wrote: > Hi, > > Infact look at version 02 it aligns even better for the discussion here. > > http://ietfreport.isoc.org/all-ids/draft-bhatia-manral-igp-crypto-requirements-02.txt > > Thanks, > Vishwas > > On Mon, Nov 9, 2009 at 12:43 PM, Vishwas Manral wrote: >> Hi Chris/ Sriram, >> >> I just subscribed to the KARP list and noticed the conversation: >> >> I agree with Sriram that we need the same set of authentication >> algorithms for all the routing protocols as their requirements are the >> same. Infact we have a draft that states the same however as we did >> not have a central WG doing all Routing protocols because of which the >> draft has not gone too far. >> >> http://ietfreport.isoc.org/all-ids/draft-bhatia-manral-igp-crypto-requirements-03.txt >> >> Thanks, >> Vishwas >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From joelja@bogus.com Mon Nov 9 16:24:24 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A373A67AF for ; Mon, 9 Nov 2009 16:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnvEdzOHHSsq for ; Mon, 9 Nov 2009 16:24:23 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id B259C3A69A2 for ; Mon, 9 Nov 2009 16:24:20 -0800 (PST) Received: from [133.93.17.104] (host-17-104.meeting.ietf.org [133.93.17.104]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id nAA0OhRe009083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Nov 2009 00:24:45 GMT (envelope-from joelja@bogus.com) Message-ID: <4AF8B2CA.5070900@bogus.com> Date: Tue, 10 Nov 2009 09:24:42 +0900 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: karp@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 10 Nov 2009 00:24:46 +0000 (UTC) X-Mailman-Approved-At: Mon, 09 Nov 2009 16:29:30 -0800 Subject: [karp] regarding my comment at the mic on the fired employee problem X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:24:24 -0000 Regarding BGP the set of people that know the static keys associated with BGP sessions includes people in other administrative domains, e.g. peers, customers, etc. joel From russ@cisco.com Mon Nov 9 16:50:11 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773903A69C5 for ; Mon, 9 Nov 2009 16:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxvt8-WYH8Al for ; Mon, 9 Nov 2009 16:50:10 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AAE4B3A6843 for ; Mon, 9 Nov 2009 16:50:10 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAA9H+EpAaHte/2dsb2JhbACUILFZl02EPgSCYA X-IronPort-AV: E=Sophos;i="4.44,712,1249257600"; d="scan'208";a="103216295" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2009 00:50:36 +0000 Received: from tky-vpn-client-230-98.cisco.com (tky-vpn-client-230-98.cisco.com [10.70.230.98]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA0oZ6J001576 for ; Tue, 10 Nov 2009 00:50:36 GMT Message-ID: <4AF8B8DB.8030301@cisco.com> Date: Tue, 10 Nov 2009 09:50:35 +0900 From: Russ White User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: karp@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [karp] Document Editors X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:50:11 -0000 Y'all: I'm willing to co-author and/or edit the drafts Greg needs help with in the KARP space. Just let me know which docs, and what needs to be done on them. Probably requirements and/or the suggestions to the protocols WGs would be the best thing for me to work on. :-) Russ From manavbhatia@gmail.com Mon Nov 9 19:58:04 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5318F3A694D for ; Mon, 9 Nov 2009 19:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5KN9lsv7Lgs for ; Mon, 9 Nov 2009 19:58:03 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id 3B5153A6930 for ; Mon, 9 Nov 2009 19:58:03 -0800 (PST) Received: by qyk29 with SMTP id 29so1501399qyk.32 for ; Mon, 09 Nov 2009 19:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=x5Zd5SEzOEVFBgq6nCoUbqs8YwUWmSZNQ/TM2TaQ3Lc=; b=yGwZVCTWrFQW3soySJ3w80gJidmL2vRhjvgIDkgwsYXGXRVWDhnML2ul2oML6YcGlb G8eDeoZzSTQaQLedDypavdO9Dj97cpZL3YbJm3thyC1QHViS9dzhFHzu0m7PT750JbQ0 +P44VHWt4rJf0nHUNJwcO/obkTLxO1sjAinhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HIOqSiNEg4RlFxFkDICU12nBVZ5chlMD+a0d+mMmuIqwi55wbT5B+EQS3LQV8fe1AC 5/5DBN9h5uTroECh1+mQ0S29EHoSXTNtpqbqrDglh/12nBbh4WKpRRA3twolMwcb2ybk LV0Dz3LyHMB3VShCXRdMpPQCdZOlYlmvs6rQQ= MIME-Version: 1.0 Received: by 10.224.75.132 with SMTP id y4mr4614819qaj.116.1257825506391; Mon, 09 Nov 2009 19:58:26 -0800 (PST) In-Reply-To: References: <77ead0ec0911091243h663c087cvbf704e1c28b1de8e@mail.gmail.com> <77ead0ec0911091248w446eb0f8yf8a8ed509c7ce79@mail.gmail.com> Date: Tue, 10 Nov 2009 09:28:26 +0530 Message-ID: From: Manav Bhatia To: Venkatesh Sriram Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] Algorithms to Support? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:58:04 -0000 We just posted the revised ID: http://www.ietf.org/staging/draft-bhatia-manral-igp-crypto-requirements-04.txt Should be available in a few days time. Cheers, Manav On Tue, Nov 10, 2009 at 5:43 AM, Venkatesh Sriram wrote: > Thank You Vishwas. This is exactly what i was looking for. > > I see that these documents have all expired. Are there plans to > resurrect them? Let me know if you need help in doing that .. > > Sriram > > On Tue, Nov 10, 2009 at 2:18 AM, Vishwas Manral wrote: >> Hi, >> >> Infact look at version 02 it aligns even better for the discussion here. >> >> http://ietfreport.isoc.org/all-ids/draft-bhatia-manral-igp-crypto-requirements-02.txt >> >> Thanks, >> Vishwas >> >> On Mon, Nov 9, 2009 at 12:43 PM, Vishwas Manral wrote: >>> Hi Chris/ Sriram, >>> >>> I just subscribed to the KARP list and noticed the conversation: >>> >>> I agree with Sriram that we need the same set of authentication >>> algorithms for all the routing protocols as their requirements are the >>> same. Infact we have a draft that states the same however as we did >>> not have a central WG doing all Routing protocols because of which the >>> draft has not gone too far. >>> >>> http://ietfreport.isoc.org/all-ids/draft-bhatia-manral-igp-crypto-requirements-03.txt >>> >>> Thanks, >>> Vishwas >>> >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >> > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From vishwas.ietf@gmail.com Mon Nov 9 20:08:14 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04B03A67EB for ; Mon, 9 Nov 2009 20:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd+wxuzvC-XK for ; Mon, 9 Nov 2009 20:08:13 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id B39C43A67DD for ; Mon, 9 Nov 2009 20:08:13 -0800 (PST) Received: by yxe30 with SMTP id 30so3994424yxe.29 for ; Mon, 09 Nov 2009 20:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TwJo/K2IeSeXsZAGqARt3LKvlkIWwHAJvbb67ZxL6tA=; b=KG0Tweeg8+gSCxibe9ZvAfDg257lMR9qEb1xXu+152A1C6ab7kngkZximOEL24F5Eb /qVGxZs86m0F7lCV9CtKk9WTFa9PkcnYh1zCJ5W0xMXhmlWE/6qlyshshc024w+1lLEB dbvtFePOCfc4HDPcxf3BVcXQf8U9TvFCeucw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GJo2CjImUBTg4flKL3CW5T8m8+MRcT2++q9XyQ5DQoJZ5sZPv3zYhfGMJoHw5SPmxA 3L2BdZI7pFuvW3FQVmNPtKCyXOQ1x/bJcT0odBzaEt8DBFHaKDPwRMw0htLuyarul4yb LFOutTFjUbjkxBcFEbcFtpwL0/Brn5eV6vwxs= MIME-Version: 1.0 Received: by 10.150.74.6 with SMTP id w6mr14745823yba.317.1257826114814; Mon, 09 Nov 2009 20:08:34 -0800 (PST) In-Reply-To: <4AF8B8DB.8030301@cisco.com> References: <4AF8B8DB.8030301@cisco.com> Date: Mon, 9 Nov 2009 20:08:34 -0800 Message-ID: <77ead0ec0911092008n9fb48d7n3d18169d00d01bea@mail.gmail.com> From: Vishwas Manral To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: karp@ietf.org Subject: Re: [karp] Document Editors X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:08:14 -0000 Hi Russ, Great!! Your inputs will certainly be of good value to us. Thanks, Vishwas On Mon, Nov 9, 2009 at 4:50 PM, Russ White wrote: > Y'all: > > I'm willing to co-author and/or edit the drafts Greg needs help with in > the KARP space. Just let me know which docs, and what needs to be done > on them. Probably requirements and/or the suggestions to the protocols > WGs would be the best thing for me to work on. > > :-) > > Russ > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From gregory.ietf@gmail.com Mon Nov 9 20:48:26 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FA83A68B1 for ; Mon, 9 Nov 2009 20:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBM0PqNl0D+C for ; Mon, 9 Nov 2009 20:48:25 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A66AF3A6820 for ; Mon, 9 Nov 2009 20:48:25 -0800 (PST) Received: by yxe30 with SMTP id 30so4017776yxe.29 for ; Mon, 09 Nov 2009 20:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:mime-version:content-type; bh=hgMWyX/+2SshIauocVM0xhEb52S9lP5u8YZ63kJVllg=; b=csLiRlzwnfLmQum2ozceb4QT1Byu3BY3op2qxi6o9NvDTkyoH1NL0N+W3/3kOYvwjE iIgYV3cW6Jj2irroKE7KgnMHksaKsZ5h8mfiYhFuQnAk8tSC0o3sNqhpTLTPYm06XC/w DOrvAFTugB6p4W5dLnrh4Lo2wGYZhe5lmfniI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:mime-version:content-type; b=uhE/V1OGX+PyjaEQEcFxUKtO70ZYVS57yi9BAEb3osmrE58DR1LUB63cz5cfStv0IK Ydp8BORn5Z1xO5OZfISR869GN5CsjzbVCUx/gwCp7cJVrB5T/Xlic8WVumVfArGnd9/X x29YPlmeXvMyWMTpocR0VpYCPPXz9fUQfM0Mg= Received: by 10.150.159.8 with SMTP id h8mr14953707ybe.302.1257828527943; Mon, 09 Nov 2009 20:48:47 -0800 (PST) Received: from Gregory-T60.gmail.com (host-32-108.meeting.ietf.org [133.93.32.108]) by mx.google.com with ESMTPS id 14sm181788gxk.6.2009.11.09.20.48.45 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Nov 2009 20:48:47 -0800 (PST) Message-ID: <4af8f0af.0e0bca0a.666f.112a@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Nov 2009 20:48:41 -0800 To: karp@ietf.org,Brian Weis From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [karp] Bill Atwood volunteers to help X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:48:26 -0000 For the BoF Chairs: Bill Atwood volunteered to help as a document author/editor. Pls add his name to the notes of those who also volunteered. Thanks, Bill!! We appreciate your participation, Gregory. >Date: Mon, 09 Nov 2009 21:20:34 -0500 >From: Bill Atwood >Organization: Concordia University, Department of Computer Science >and Software > Engineering >User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) >To: Gregory Lebovitz >Subject: I am not in the room, but... > > >I am willing (eager) to help. > > Bill > >-- > >Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >Distinguished Professor Emeritus fax: +1 (514) 848-2830 >Department of Computer Science > and Software Engineering >Concordia University EV 3.185 email: bill@cse.concordia.ca >1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill >Montreal, Quebec Canada H3G 1M8 +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m From manavbhatia@gmail.com Wed Nov 11 04:23:57 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E79A3A688D for ; Wed, 11 Nov 2009 04:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMDYzU4BiVEE for ; Wed, 11 Nov 2009 04:23:56 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id 523B028C252 for ; Wed, 11 Nov 2009 04:23:41 -0800 (PST) Received: by qyk29 with SMTP id 29so485629qyk.32 for ; Wed, 11 Nov 2009 04:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=he3pxhjD09dJX7geo1xc0Uql56RgyR5GeX/OmpGn1bc=; b=pm1n+E3KcwOp9zL280bjSI0mooyjAzJumjdtyXq51CJ/BxZmBX3Y9RV/ELedRJ2lH+ fQoEc3DUmeOpEEmPsluLvCXoffWA7Wv9P7h4Z/7IQPK9va0xYwR14qoUlAueE/Kwg68O PpVc9YbjHZuP2m6JDF5iKhYtrvA3DTqqM0i98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=yCY66bb4wfYyaTlJQUQYTub04tE02f0p2a4oI5Hdi7V6HnRpiUUw8uNnddoIiqUoKd xGJR4Tl8mbtn92yXPOaIxihQKR6apyO6YmbR7pYvNL7exLFo+xyWQhNm5tGIRcVUuTvY uFl9jqx2G8Ca+leIBc7Ek8fy3xgnzTpYDOn0U= MIME-Version: 1.0 Received: by 10.224.66.35 with SMTP id l35mr766411qai.131.1257942246801; Wed, 11 Nov 2009 04:24:06 -0800 (PST) Date: Wed, 11 Nov 2009 17:54:06 +0530 Message-ID: From: Manav Bhatia To: karp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [karp] Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:23:57 -0000 Hi, We have posted the revised version based on the feedback that we had received from OPSEC and its available here: http://www.ietf.org/id/draft-bhatia-manral-igp-crypto-requirements-04.txt Would be great if folks in KARP go through this and provide some feedback. Abstract The routing protocols Open Shortest Path First version 2 (OSPFv2)[RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and MD5 (Message Digest 5) [RFC1321] methods for authenticating protocol packets. Recently effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP [RFC4822], IS-IS [RFC5310] and OSPF [RFC5709]. To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms thereby ensuring that there is at least one algorithm that all implementations will have in common. This document examines the current set of available algorithms with interoperability and effective cryptographic authentication protection being the principle considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. Cheers, Manav From mcgrew@cisco.com Wed Nov 11 04:59:34 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D87C28C179 for ; Wed, 11 Nov 2009 04:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hdEHYKTxI+F for ; Wed, 11 Nov 2009 04:59:33 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 67C4D28C0D6 for ; Wed, 11 Nov 2009 04:59:33 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 1760 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOJD+kqrR7Ht/2dsb2JhbADDdZgZhDwEgWs X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="p7s'?scan'208";a="202340976" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2009 13:00:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABD01f3028792; Wed, 11 Nov 2009 13:00:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 05:00:01 -0800 Received: from stealth-10-32-254-214.cisco.com ([10.32.254.214]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 05:00:00 -0800 Message-Id: <60E386F6-2694-4D43-AFA2-F1CAE66A64FC@cisco.com> From: David McGrew To: Manav Bhatia In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-266-464325498; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 04:59:59 -0800 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 11 Nov 2009 13:00:00.0858 (UTC) FILETIME=[E0D8F3A0:01CA62CE] Cc: karp@ietf.org Subject: Re: [karp] Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:59:34 -0000 --Apple-Mail-266-464325498 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Manav, suggested improvement in terminology inline: On Nov 11, 2009, at 4:24 AM, Manav Bhatia wrote: > Hi, > > We have posted the revised version based on the feedback that we had > received from OPSEC and its available here: > > http://www.ietf.org/id/draft-bhatia-manral-igp-crypto-requirements-04.txt > > Would be great if folks in KARP go through this and provide some > feedback. > > Abstract > > The routing protocols Open Shortest Path First version 2 > (OSPFv2)[RFC2328], Intermediate System to Intermediate System (IS-IS) > [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] > currently define Clear Text and MD5 (Message Digest 5) [RFC1321] > methods for authenticating protocol packets. Recently effort has been > made to add support for the SHA (Secure Hash Algorithm) family of hash > functions for the purpose of authenticating routing protocol packets > for RIP [RFC4822], IS-IS [RFC5310] and OSPF [RFC5709]. ... to add support for the HMAC message authentication code [RFC2104] using the SHA family of hash functions ... regards, David > > To encourage interoperability between disparate implementations, it is > imperative that we specify the expected minimal set of algorithms > thereby ensuring that there is at least one algorithm that all > implementations will have in common. > > This document examines the current set of available algorithms with > interoperability and effective cryptographic authentication protection > being the principle considerations. Cryptographic authentication of > these routing protocols requires the availability of the same > algorithms in disparate implementations. It is desirable that newly > specified algorithms should be implemented and available in routing > protocol implementations because they may be promoted to requirements > at some future time. > > Cheers, Manav > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp --Apple-Mail-266-464325498 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDnjCCA5ow ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM 5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+ SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W 6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7 mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR gCmxsHqcL1uMMYIDBDCCAwACAQEwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dyZXcxEzARBgNVBAgM CkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEfMB0GCSqGSIb3DQEJ ARYQbWNncmV3QGNpc2NvLmNvbQIBZDAJBgUrDgMCGgUAoIIBZzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTExMTExMjU5NjBaMCMGCSqGSIb3DQEJBDEWBBSnWnc9 B85jcErz+UWpVUGBVPDH/TCBgQYJKwYBBAGCNxAEMXQwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dy ZXcxEzARBgNVBAgMCkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEf MB0GCSqGSIb3DQEJARYQbWNncmV3QGNpc2NvLmNvbQIBZDCBgwYLKoZIhvcNAQkQAgsxdKByMG0x FTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMx ETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMA0G CSqGSIb3DQEBAQUABIIBAM5cWa0s1trOAbiaP+lGnzx8/6XxyLw7YgsPbXkrN40qSN3C6KQy+a5K GMSRKowe7kP4scVBmZ/9UbHpGxV4JNYLoPGoRXePMR1MWy4EUNQfhd4H6oI99qFZOf8sIPtKiOYn ZDNrayMUwPOtnTlf5dt0I6fNhXO29YJiXfg45pXw0mAuhPytnUipmBCktdbvtlsOAKfXLr2LvBkE r+T671jyfDoRHFdeGr4n0XAPoPaiuaxu5SBuFNi9rChxtCW0c/Vfm3NY7O+CxIQYsEkcJ326GTBY JUoWnNzehtKxwKhkdHacUBJuP8YUBHqqAWT+wEAiq8nNxv8Tj5/4ET5UThgAAAAAAAA= --Apple-Mail-266-464325498-- From gregory.ietf@gmail.com Wed Nov 25 09:30:18 2009 Return-Path: X-Original-To: karp@core3.amsl.com Delivered-To: karp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F72D3A6AEE for ; Wed, 25 Nov 2009 09:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzjMSm77tvs4 for ; Wed, 25 Nov 2009 09:30:17 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CD7AE3A6AB6 for ; Wed, 25 Nov 2009 09:30:16 -0800 (PST) Received: by bwz23 with SMTP id 23so7512880bwz.29 for ; Wed, 25 Nov 2009 09:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=09eLXLQcMMso2QpaP2zkkpDSmx17Zd44CQNyoLlsgC4=; b=bXNqR4/iYEfjNMdlGAf2AZMrotDj8Mr9Xcc2I5ZTImlQbE+XWJRC9iv7IsrrDzg2Va 9wlu+gs/JMXA2VI53mMuPPFBrrPcJK1+95RjamLMacyHp60Xu2j1MPjxu88EszSAMBXY KIbPbM/vaLVXCPk/JWWrk4UY5v26eDiGCuzlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=geYGrhjlV+G04AqfkvCUYfZcZbsmqJgHSjc0QPmCWH6+ns9IfOGZRMTlwhZc3ikKPv zuI9WlPKTUmZ+wnp00p5w32JmevHIDM8nmmoZH9nDXJYwFD5mmyOQrZEzcc29zOfVSBu dUTJm6EnMHRLsucRpqolEL4FtVSoNxK22zy/k= MIME-Version: 1.0 Received: by 10.204.15.132 with SMTP id k4mr3936222bka.139.1259170206422; Wed, 25 Nov 2009 09:30:06 -0800 (PST) In-Reply-To: <4AF8B2CA.5070900@bogus.com> References: <4AF8B2CA.5070900@bogus.com> Date: Wed, 25 Nov 2009 09:30:06 -0800 Message-ID: From: Gregory Lebovitz To: Joel Jaeggli Content-Type: multipart/alternative; boundary=0003255550cedd983704793568f2 Cc: karp@ietf.org Subject: Re: [karp] regarding my comment at the mic on the fired employee problem X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:30:18 -0000 --0003255550cedd983704793568f2 Content-Type: text/plain; charset=ISO-8859-1 Joel, I have this on my list for an update to the "-kmart-roadmap" document (which will become the "-karp-roadmap") document shortly. Gregory. On Mon, Nov 9, 2009 at 4:24 PM, Joel Jaeggli wrote: > Regarding BGP the set of people that know the static keys associated > with BGP sessions includes people in other administrative domains, e.g. > peers, customers, etc. > > joel > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0003255550cedd983704793568f2 Content-Type: text/html; charset=ISO-8859-1 Joel,

I have this on my list for an update to the "-kmart-roadmap" document (which will become the "-karp-roadmap") document shortly.

Gregory.

On Mon, Nov 9, 2009 at 4:24 PM, Joel Jaeggli <joelja@bogus.com> wrote:
Regarding BGP the set of people that know the static keys associated
with BGP sessions includes people in other administrative domains, e.g.
peers, customers, etc.

joel
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp



--
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks
--0003255550cedd983704793568f2--