From paul.hoffman@vpnc.org Fri Jun 1 19:29:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FCD11E80C4 for ; Fri, 1 Jun 2012 19:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUhnlITj+Feb for ; Fri, 1 Jun 2012 19:29:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ECEBC11E80BB for ; Fri, 1 Jun 2012 19:29:15 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q522TC2C011643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 Jun 2012 19:29:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 19:29:12 -0700 References: <20120602015052.A0A13B1E003@rfc-editor.org> To: IPsecme WG Message-Id: <004A2FCF-EF3B-4D80-8366-D612C8740976@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPsec] Fwd: RFC 6617 on Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 02:29:16 -0000 Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: RFC 6617 on Secure Pre-Shared Key (PSK) Authentication for = the Internet Key Exchange Protocol (IKE) > Date: June 1, 2012 6:50:52 PM PDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6617 >=20 > Title: Secure Pre-Shared Key (PSK) Authentication=20 > for the Internet Key Exchange Protocol=20 > (IKE)=20 > Author: D. Harkins > Status: Experimental > Stream: IETF > Date: June 2012 > Mailbox: dharkins@arubanetworks.com > Pages: 24 > Characters: 53805 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-harkins-ipsecme-spsk-auth-08.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6617.txt >=20 > This memo describes a secure pre-shared key (PSK) authentication > method for the Internet Key Exchange Protocol (IKE). It is resistant > to dictionary attack and retains security even when used with weak > pre-shared keys. This document defines an Experimental Protocol=20 > for the Internet community. >=20 >=20 > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. From paul.hoffman@vpnc.org Fri Jun 1 19:29:31 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF10D11E80BB for ; Fri, 1 Jun 2012 19:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81Dl9vjdB6bJ for ; Fri, 1 Jun 2012 19:29:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2F811E80D3 for ; Fri, 1 Jun 2012 19:29:30 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q522TC2D011643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 Jun 2012 19:29:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 19:29:30 -0700 References: <20120602015104.8E43EB1E004@rfc-editor.org> To: IPsecme WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [IPsec] Fwd: RFC 6628 on Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 02:29:31 -0000 > From: rfc-editor@rfc-editor.org > Subject: RFC 6628 on Efficient Augmented Password-Only Authentication = and Key Exchange for IKEv2 > Date: June 1, 2012 6:51:04 PM PDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6628 >=20 > Title: Efficient Augmented Password-Only Authentication = and=20 > Key Exchange for IKEv2=20 > Author: S. Shin, K. Kobara > Status: Experimental > Stream: IETF > Date: June 2012 > Mailbox: seonghan.shin@aist.go.jp,=20 > kobara_conf@m.aist.go.jp > Pages: 20 > Characters: 45831 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-shin-augmented-pake-15.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6628.txt >=20 > This document describes an efficient augmented password-only > authentication and key exchange (AugPAKE) protocol where a user > remembers a low-entropy password and its verifier is registered in > the intended server. In general, the user password is chosen from a=20= > small set of dictionary words that allows an attacker to perform=20 > exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE=20= > protocol described here is secure against passive attacks, active = attacks,=20 > and off-line dictionary attacks (on the obtained messages with=20 > passive/active attacks), and also provides resistance to server = compromise=20 > (in the context of augmented PAKE security). In addition, this = document=20 > describes how the AugPAKE protocol is integrated into the Internet Key=20= > Exchange Protocol version 2 (IKEv2). This document defines an=20 > Experimental Protocol for the Internet community. >=20 >=20 > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. From vishwas.ietf@gmail.com Tue Jun 5 08:48:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3DE21F86F3 for ; Tue, 5 Jun 2012 08:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo6Isokk7Pwb for ; Tue, 5 Jun 2012 08:48:00 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40CE021F86EC for ; Tue, 5 Jun 2012 08:48:00 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4566167ggn.31 for ; Tue, 05 Jun 2012 08:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=76cjOcUJmfpp62vLy0mk5Q3GicBQgQKWo8POYSvW2y4=; b=kVFTgizl+jOnrpOH+EjFiB7OTkEV78Z6ZM1wQDzxQEt2/V+sW/vi3olwQ89a4AiPB5 oh2Xo9m+RSwyJ2mIAn/J3Wo6mLvCIUrvpK+YeyXv4FQ+cryF3HaMRMtvMSRyR+qnWSrB TTCeZPTlGcfHUOTTCIVa9snIqsFLkUCWQSFn80kZyKa0s/m8/KPfhH2YlWDntdAtv4kr I5mORQO4ZRquN+zRGdAMoqvXVg7y3N4bK2/+KJMUxk3hO4SVQdqal0dQDtN8ldYBYM+7 ekS8iisdWrMQyrBitRvWZNpeO2PIxKcris+iagio/d+zwPsOrTtuROkz7RY4AaDJym9F 7lMg== MIME-Version: 1.0 Received: by 10.60.2.35 with SMTP id 3mr16535348oer.63.1338911279520; Tue, 05 Jun 2012 08:47:59 -0700 (PDT) Received: by 10.182.214.33 with HTTP; Tue, 5 Jun 2012 08:47:59 -0700 (PDT) Date: Tue, 5 Jun 2012 08:47:59 -0700 Message-ID: From: Vishwas Manral To: IPsecme WG Content-Type: multipart/alternative; boundary=e89a8f234829339a2304c1bb93d4 Subject: [IPsec] ADVPN requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 15:48:01 -0000 --e89a8f234829339a2304c1bb93d4 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I am just beginning to write the ADVPN requirements into the document. While putting in the requirements, I realized we could as well have a separate documents for ADVPN for requirements. I looked at other efforts in other working groups and found the problem statement/ use case and the requirements document as separate. Do we have a view on weather we want to have the requirements and problem statement as part of one or different documents? Your views on the same will be greatly appreciated. Thanks, Vishwas --e89a8f234829339a2304c1bb93d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

I am just beginning to write the ADVPN requirements into t= he document.

While putting in the requirements, I realized we could = as well have a separate documents for ADVPN for requirements. I looked at o= ther efforts in other working groups and found the problem statement/ use c= ase and the requirements document as separate.

Do we have a view on weather we want to have the requirements and probl= em statement as part of one or different documents? Your views on the same = will be greatly appreciated.

Thanks,
Vishwas


--e89a8f234829339a2304c1bb93d4-- From fdetienn@cisco.com Tue Jun 5 11:07:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F88E21F87B9 for ; Tue, 5 Jun 2012 11:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVy68LhazwLl for ; Tue, 5 Jun 2012 11:07:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 94E7D21F87B7 for ; Tue, 5 Jun 2012 11:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fdetienn@cisco.com; l=5651; q=dns/txt; s=iport; t=1338919647; x=1340129247; h=from:to:subject:date:message-id:mime-version; bh=PtDc3ztDFZ7p+Mzi+beCmDRE+99ipvX+SlB0bwv2Fk0=; b=e7qVhF4J1FB8ANo6mRhz8fXMP+HWkeLfjW3C7656q/VhaLhr6I72bmNh 1jPLxKuyootyAoYsrwdu8SOK3Kk+D94HzJCBjGpfvBBGEy5gap5RxlecE vma3R5sfI8OYl1i5kqcx0XtN9IRhHUlAPv95eGdqfJy5A6bFVv3YrC6mz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEAACNKzk+tJV2d/2dsb2JhbAArFwOFTp4Kj0iBHIEHghoBBBIBEEMlASoODAYCBDAmAQQbGodpCymVUIEojRaEA45sjggHggIyYAOIDY4djQGBZoJggVYEBQ X-IronPort-AV: E=Sophos;i="4.75,719,1330905600"; d="scan'208";a="89748933" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jun 2012 18:07:27 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q55I7R4w021254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Jun 2012 18:07:27 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.14]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Tue, 5 Jun 2012 13:07:26 -0500 From: "Frederic Detienne (fdetienn)" To: "ipsec@ietf.org" Thread-Topic: IPsec WG BoF Thread-Index: Ac1BhtByiLrx8QN5QVCPcpD5qpo5TQ== Date: Tue, 5 Jun 2012 18:07:26 +0000 Message-ID: <1A87A395651F8F439A0C9D8FE20EB0F5014C90@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.208.139] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18948.005 x-tm-as-result: No--39.314500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_002_1A87A395651F8F439A0C9D8FE20EB0F5014C90xmbalnx06ciscocom_" MIME-Version: 1.0 Subject: [IPsec] Canceled: IPsec WG BoF X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 18:07:28 -0000 --_002_1A87A395651F8F439A0C9D8FE20EB0F5014C90xmbalnx06ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Wednesday, November 16, 2011 12:00 PM-2:00 PM. UTC Where: WebEx - 201 123 128 *~*~*~*~*~*~*~*~*~* ----- WebEx Invite ----- Meeting Number: 201123128 Password: NMRhBGcT ------------------------ To join the meeting online ------------------------ 1. Go to https://cisco.webex.com/cisco/j.php?ED=3D179670317&UID=3D0&PW=3DNN= WY0NzM2YzVh&RT=3DMiMyMw%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: NMRhBGcT 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------ To join the teleconference only ------------------------ 1. Dial into Cisco WebEx - view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 Access code: 201123128 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, do not join the sessio= n. --_002_1A87A395651F8F439A0C9D8FE20EB0F5014C90xmbalnx06ciscocom_ Content-Type: text/calendar; charset="utf-8"; method=CANCEL Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6Q0FOQ0VMDQpQUk9ESUQ6TWljcm9zb2Z0IEV4Y2hhbmdl IFNlcnZlciAyMDEwDQpWRVJTSU9OOjIuMA0KQkVHSU46VlRJTUVaT05FDQpUWklEOkFzaWEvVGFp cGVpDQpCRUdJTjpTVEFOREFSRA0KRFRTVEFSVDoyMDEyMDkzMFQwMDAwMDANClRaT0ZGU0VURlJP TTorMDkwMA0KVFpPRkZTRVRUTzorMDgwMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlMSUdIVA0K RFRTVEFSVDoyMDEyMDYzMFQwMDAwMDANClRaT0ZGU0VURlJPTTorMDgwMA0KVFpPRkZTRVRUTzor MDkwMA0KRU5EOkRBWUxJR0hUDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCk9SR0FOSVpF UjtDTj1GcmVkZXJpYyBEZXRpZW5uZSAoZmRldGllbm4pOk1BSUxUTzpmZGV0aWVubkBjaXNjby5j b20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049aXBzZWNAaWV0Zg0KIC5vcmc6TUFJTFRPOmlwc2VjQGlldGYub3JnDQpERVND UklQVElPTjtMQU5HVUFHRT1lbi1VUzpXaGVuOiBXZWRuZXNkYXlcLCBOb3ZlbWJlciAxNlwsIDIw MTEgMTI6MDAgUE0tMjoNCiAwMCBQTS4gVVRDXG5XaGVyZTogV2ViRXggLSAyMDEgMTIzIDEyOFxu XG4qfip+Kn4qfip+Kn4qfip+Kn4qXG5cbi0tLS0tIFdlYg0KIEV4IEludml0ZSAtLS0tLVxuXG5N ZWV0aW5nIE51bWJlcjogMjAxMTIzMTI4XG5QYXNzd29yZDogTk1SaEJHY1RcblxuLS0tLS0tDQog LS0tLS0tLS0tLS0tLS0tLS0tXG5UbyBqb2luIHRoZSBtZWV0aW5nIG9ubGluZVxuLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tXG4NCiAxLiBHbyB0byBodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNj by9qLnBocD9FRD0xNzk2NzAzMTcmVUlEPTAmUFc9Tk5XWTBOeg0KIE0yWXpWaCZSVD1NaU15TXcl M0QlM0RcbjIuIEVudGVyIHlvdXIgbmFtZSBhbmQgZW1haWwgYWRkcmVzcy5cbjMuIEVudGVyIHRo DQogZSBtZWV0aW5nIHBhc3N3b3JkOiBOTVJoQkdjVFxuNC4gQ2xpY2sgIkpvaW4iLlxuNS4gSWYg dGhlIG1lZXRpbmcgaW5jbHVkZXMNCiAgYSB0ZWxlY29uZmVyZW5jZVwsIGZvbGxvdyB0aGUgaW5z dHJ1Y3Rpb25zIHRoYXQgYXBwZWFyIG9uIHlvdXIgc2NyZWVuLlxuXA0KIG4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS1cblRvIGpvaW4gdGhlIHRlbGVjb25mZXJlbmNlIG9ubHlcbi0tLS0tLS0tLS0t LS0tDQogLS0tLS0tLS0tLVxuMS4gRGlhbCBpbnRvIENpc2NvIFdlYkV4IC0gdmlldyBhbGwgR2xv YmFsIEFjY2VzcyBOdW1iZXJzIGF0XG4NCiBodHRwOi8vY2lzY28uY29tL2VuL1VTL2Fib3V0L2Rv aW5nX2J1c2luZXNzL2NvbmZlcmVuY2luZy9pbmRleC5odG1sXG4yLiBGbw0KIGxsb3cgdGhlIHBy b21wdHMgdG8gZW50ZXIgdGhlIE1lZXRpbmcgTnVtYmVyIChsaXN0ZWQgYWJvdmUpIG9yIEFjY2Vz cyBDb2RlDQogIGZvbGxvd2VkIGJ5IHRoZSAjIHNpZ24uXG5cblNhbiBKb3NlXCwgQ0E6ICsxLjQw OC41MjUuNjgwMCBSVFA6ICsxLjkxOS4zOTINCiAuMzMzMFxuVVMvQ2FuYWRhOiArMS44NjYuNDMy Ljk5MDMgVW5pdGVkIEtpbmdkb206ICs0NC4yMC44ODI0LjAxMTdcbkluZGlhOg0KICArOTEuODAu NDM1MC4xMTExIEdlcm1hbnk6ICs0OS42MTkuNjc3My45MDAyXG5KYXBhbjogKzgxLjMuNTc2My45 Mzk0IENoaW5hDQogOiArODYuMTAuODUxNS41NjY2XG5cbkFjY2VzcyBjb2RlOiAyMDExMjMxMjhc blxuU2lnbiB1cCBmb3IgYSBmcmVlIHRyaWFsIG8NCiBmIFdlYkV4XG5odHRwOi8vd3d3LndlYmV4 LmNvbS9nby9tY2VtZnJlZXRyaWFsXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMgVw0KIGViRXgg c2VydmljZSBpbmNsdWRlcyBhIGZlYXR1cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFueSBkb2N1 bWVudHMgYW5kIG90DQogaGVyIG1hdGVyaWFscyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmluZyB0 aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZC4gQnkgam8NCiBpbmluZyB0aGlzIHNlc3Npb25cLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IA0KIGRv IG5vdCBjb25zZW50IHRvIHRoZSByZWNvcmRpbmdcLCBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5c bg0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpDYW5jZWxlZDogSVBzZWMgV0cgQm9GDQpEVFNUQVJU O1RaSUQ9QXNpYS9UYWlwZWk6MjAxMTExMTZUMjAwMDAwDQpEVEVORDtUWklEPUFzaWEvVGFpcGVp OjIwMTExMTE2VDIyMDAwMA0KVUlEOkYzM0Q4MTJBLTg0RjktNEZGRi1CMTQ4LUYwMERCQTExREYy RQ0KQ0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1QOjIwMTIwNjA1VDE4MDcyNloNClRS QU5TUDpPUEFRVUUNClNUQVRVUzpDQU5DRUxMRUQNClNFUVVFTkNFOjgNCkxPQ0FUSU9OO0xBTkdV QUdFPWVuLVVTOldlYkV4IC0gMjAxIDEyMyAxMjgNClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVF TkNFOjgNClgtTUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDotMQ0KWC1NSUNST1NPRlQtQ0RPLUJV U1lTVEFUVVM6RlJFRQ0KWC1NSUNST1NPRlQtQ0RPLUlOVEVOREVEU1RBVFVTOkZSRUUNClgtTUlD Uk9TT0ZULUNETy1BTExEQVlFVkVOVDpGQUxTRQ0KWC1NSUNST1NPRlQtQ0RPLUlNUE9SVEFOQ0U6 MQ0KWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjANClgtTUlDUk9TT0ZULURJU0FMTE9XLUNPVU5U RVI6RkFMU0UNCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_002_1A87A395651F8F439A0C9D8FE20EB0F5014C90xmbalnx06ciscocom_-- From shl.gannon@gmail.com Wed Jun 6 07:54:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE6821F8507 for ; Wed, 6 Jun 2012 07:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD+YYhTrYpUb for ; Wed, 6 Jun 2012 07:54:48 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2CE21F8666 for ; Wed, 6 Jun 2012 07:54:40 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3973291qcs.31 for ; Wed, 06 Jun 2012 07:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dzLPr5CAyLhU20RPuIZ+oh9a83KqDEk8SxFx3EioylY=; b=GIJrmHDz6s4E5E0ycMk4qvFWrcSf8026LzeyePHWSbQZYN8Yl/gThkpLDJrgcxLwJE v9X7cqNrYNxbQv8KFc+eOYGQi7FBWFcmgLQyc2Tghpww1vlz4Rphcs/yw0IcLY8PVsJ0 Ycfic1nS5LY6RPIrWibnj8KAiLqR/DWm2eu7AieHoNUhZyMslkzYEyhZcB2Kk6Ikuw+6 VaPFeFzJxrFJ6bSQu4KMh5iVwna0SDeSn1VBQMA8U4qobJ4FygnXZkhZ5ddsjF90bd4I 8zdRJJedi1lK0D9xdP23NkPqHD6fKRIqd8xhFbWo/HNo5dSQwnkjkJjIWGXKsOV+4rGD qqGQ== MIME-Version: 1.0 Received: by 10.182.77.170 with SMTP id t10mr8941039obw.70.1338994479768; Wed, 06 Jun 2012 07:54:39 -0700 (PDT) Received: by 10.182.167.67 with HTTP; Wed, 6 Jun 2012 07:54:39 -0700 (PDT) Date: Wed, 6 Jun 2012 22:54:39 +0800 Message-ID: From: Sheng Hsin Lo To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=f46d044517c152a46404c1cef221 Subject: [IPsec] IPsec SPD search X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:54:49 -0000 --f46d044517c152a46404c1cef221 Content-Type: text/plain; charset=ISO-8859-1 Hello, Should the SPD search in IPsec support longest prefix match(LPM)? Thanks. --f46d044517c152a46404c1cef221 Content-Type: text/html; charset=ISO-8859-1 Hello,

Should the SPD search in IPsec support longest prefix match(LPM)?

Thanks.
--f46d044517c152a46404c1cef221-- From ynir@checkpoint.com Wed Jun 6 08:06:45 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3926221F88C4 for ; Wed, 6 Jun 2012 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59ebQ5S2RgKb for ; Wed, 6 Jun 2012 08:06:44 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5204921F8851 for ; Wed, 6 Jun 2012 08:06:44 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q56F4dtX019039; Wed, 6 Jun 2012 18:06:41 +0300 X-CheckPoint: {4FCF7D76-3-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jun 2012 18:06:32 +0300 From: Yoav Nir To: Sheng Hsin Lo Date: Wed, 6 Jun 2012 18:06:25 +0300 Thread-Topic: [IPsec] IPsec SPD search Thread-Index: Ac1D9fSwSvECawqHQDWPcHvAEoWeOg== Message-ID: <9D76FE42-E2E0-48DC-87AD-A45DD4F15714@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 118156b74516c179d70091761969b9a245d4a32629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IPsec SPD search X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:06:45 -0000 On Jun 6, 2012, at 5:54 PM, Sheng Hsin Lo wrote: > Hello,=20 >=20 > Should the SPD search in IPsec support longest prefix match(LPM)? >=20 Hi The answer is no. The SPD is an ordered list of entries, and the first matc= h is the one to follow.=20 RFC 4301 defines a decorrelation algorithm (section 4.4.1 and appendix B) t= hat remove overlaps for quicker searches, but that does not change the resu= lt fo the SPD search, which is first-match. Hope this helps Yoav From paul@cypherpunks.ca Wed Jun 6 08:11:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788721F8879 for ; Wed, 6 Jun 2012 08:11:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYbwIh1BHJiq for ; Wed, 6 Jun 2012 08:11:15 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11221F8664 for ; Wed, 6 Jun 2012 08:11:15 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 1907385642; Wed, 6 Jun 2012 11:11:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 0CF38803A3; Wed, 6 Jun 2012 11:11:05 -0400 (EDT) Date: Wed, 6 Jun 2012 11:11:05 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: <9D76FE42-E2E0-48DC-87AD-A45DD4F15714@checkpoint.com> Message-ID: References: <9D76FE42-E2E0-48DC-87AD-A45DD4F15714@checkpoint.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org" , Sheng Hsin Lo Subject: Re: [IPsec] IPsec SPD search X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:11:20 -0000 On Wed, 6 Jun 2012, Yoav Nir wrote: >> Should the SPD search in IPsec support longest prefix match(LPM)? >> > > Hi > > The answer is no. The SPD is an ordered list of entries, and the first match is the one to follow. > > RFC 4301 defines a decorrelation algorithm (section 4.4.1 and appendix B) that remove overlaps for quicker searches, but that does not change the result fo the SPD search, which is first-match. The *swan implementations when using KLIPS use longest prefix match. When using NETKEY/XFRM you get the first match behaviour. The latter causes all kinds of problems. Apart from the RFC stating so, what is the reasoning behind favouring an "arbitrary top down list" over longest prefix match? Paul From msa@moth.iki.fi Wed Jun 6 08:15:33 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9732F21F888B for ; Wed, 6 Jun 2012 08:15:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmVtgXSzFV8X for ; Wed, 6 Jun 2012 08:15:33 -0700 (PDT) Received: from moth.iki.fi (moth.iki.fi [212.16.111.74]) by ietfa.amsl.com (Postfix) with ESMTP id C34FE21F8760 for ; Wed, 6 Jun 2012 08:15:32 -0700 (PDT) Received: from [212.149.201.161] (212-149-201-161.bb.dnainternet.fi [212.149.201.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: msa) by moth.iki.fi (Postfix) with ESMTPSA id 5AA8E1E581D for ; Wed, 6 Jun 2012 18:15:55 +0300 (EEST) Message-ID: <4FCF7412.60109@moth.iki.fi> Date: Wed, 06 Jun 2012 18:15:30 +0300 From: Markku Savela User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <9D76FE42-E2E0-48DC-87AD-A45DD4F15714@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] IPsec SPD search X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:15:33 -0000 On 06/06/2012 06:11 PM, Paul Wouters wrote: > Apart from the RFC stating so, what is the reasoning behind favouring > an "arbitrary top down list" over longest prefix match? For example, if your policy only specifies remote or local port, like 80 (to cover all HTTP traffic, regarless of origin). It would be hard to see how longest match would apply to it? From paul@cypherpunks.ca Wed Jun 6 08:22:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF3621F86A5 for ; Wed, 6 Jun 2012 08:22:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDQHZSA5xfH8 for ; Wed, 6 Jun 2012 08:22:05 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0882521F88D0 for ; Wed, 6 Jun 2012 08:21:55 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 1D69385642; Wed, 6 Jun 2012 11:21:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 117D2803A3; Wed, 6 Jun 2012 11:21:55 -0400 (EDT) Date: Wed, 6 Jun 2012 11:21:55 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Markku Savela In-Reply-To: <4FCF7412.60109@moth.iki.fi> Message-ID: References: <9D76FE42-E2E0-48DC-87AD-A45DD4F15714@checkpoint.com> <4FCF7412.60109@moth.iki.fi> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec SPD search X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:22:06 -0000 On Wed, 6 Jun 2012, Markku Savela wrote: > On 06/06/2012 06:11 PM, Paul Wouters wrote: >> Apart from the RFC stating so, what is the reasoning behind favouring >> an "arbitrary top down list" over longest prefix match? > > For example, if your policy only specifies remote or local port, > like 80 (to cover all HTTP traffic, regarless of origin). It > would be hard to see how longest match would apply to it? You first match on the longest prefix. If you have multiple candidates, you match on the most specific traffic selector, favouring protocol over ports. That seems more predictable and stable then "whatever connection loaded first"? Paul From ynir@checkpoint.com Thu Jun 7 08:21:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05C321F861D for ; Thu, 7 Jun 2012 08:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW4EU+WHtRSQ for ; Thu, 7 Jun 2012 08:20:59 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6458321F871E for ; Thu, 7 Jun 2012 08:20:58 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q57FKufq020337 for ; Thu, 7 Jun 2012 18:20:56 +0300 X-CheckPoint: {4FD0C6D5-10001-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Jun 2012 18:20:55 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Thu, 7 Jun 2012 18:20:56 +0300 Thread-Topic: Fragmentation causing IKE to fail Thread-Index: Ac1EwSGsRo0B6v80Q7eoNC4XmHpNIw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11bdfee70a0832a378f42c371a255d886947e67d43 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:21:02 -0000 Hi I work for a vendor selling and IKE/IPsec solution. In the last few months, we've heard a troubling complaint from some of our = customers. They say that some ISPs have begun to drop IP fragments. While s= pecific ISPs were not named, most of the issues seem to be in south-east As= ia. One customer has speculated that this has something to do with preparin= g to deploy CGNs. According to draft-ietf-behave-lsn-requirements, CGNs MUST comply with the = NAT requirements for UDP as in RFC 4787, and that RFC says in section 11 th= at NAT devices MUST support fragments. So these routers are not compliant, = but that doesn't help our customers much. Most traffic on the Internet is either TCP or small-packet UDP. The IKE pro= tocol (both versions) has the rather rare distinction of having large UDP p= ackets. These are packets #5 and #6 in IKEv1 Main Mode, or the IKE_AUTH pac= kets in IKEv2, especially when using certificate authentication. For now, the customers managed to "fix" the ISP with an angry phone call. T= hat got them into an exception list where fragments are not dropped. One ha= d to change ISPs for that. While this can work for a while, it won't work w= hen the carrier doing the dropping is not the one that the customer has a b= usiness relationship with, but another one downstream. Trying to think up ways to deal with this, I can think of some: * Get all ISPs to stop dropping fragments. This would be great, but as the = saying goes, you are so not in charge. * Find ways of making the packets smaller: move to PSK, fiddle with trust a= nchors so that only one cert is needed, avoid sending CRLs, hash-and-URL, e= tc. These are not always successful, and often require more configuration t= han we would like. * Build a fragmentation layer within IKE, so IKE messages are broken into s= everal packets that get reassembled at the destination. This is the path ta= ken by one of our competitors [1]. This means that IKE has segmentation in = addition to other TCP-like features such as retransmission. * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is alre= ady allocated to "ISAKMP". We have had IKE running over TCP for several yea= rs for remote access clients. This was done because remote access clients c= onnect from behind some very dodgy NAT devices, and some of those do drop f= ragments. Getting this behavior at the ISP is novel. Have others on this list run into this issue? =20 Yoav [1] http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configurati= on/guide/sec_fragment_ike_pack.html [2] http://www.iana.org/assignments/service-names-port-numbers/service-name= s-port-numbers.xml= From mcr@sandelman.ca Wed Jun 6 13:30:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B6D21F875D for ; Wed, 6 Jun 2012 13:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31FK5bkMMERA for ; Wed, 6 Jun 2012 13:30:46 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F01F621F8776 for ; Wed, 6 Jun 2012 13:30:45 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id E28C681FC for ; Wed, 6 Jun 2012 16:28:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B47B39823C; Wed, 6 Jun 2012 16:30:43 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A3C0698147 for ; Wed, 6 Jun 2012 16:30:43 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: References: <9D76FE42-E2E0-48DC-87AD-A45DD4F15714@checkpoint.com> <4FCF7412.60109@moth.iki.fi> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Jun 2012 16:30:43 -0400 Message-ID: <17165.1339014643@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Thu, 07 Jun 2012 09:01:27 -0700 Subject: Re: [IPsec] IPsec SPD search X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:30:47 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Paul" =3D=3D Paul Wouters writes: Paul> That seems more predictable and stable then "whatever Paul> connection loaded=20 Paul> first"? 1) Please don't confuse the Linux NETKEY/XFRM's API with RFC4301. RFC4301 says that the admin controls the order of the policies, while XFRM does not give the admin any real control, and embeds policies in the kernel in a really really really bad way, rather than in a policy daemon.=20 2) Please don't confuse KLIPS with RFC4301. KLIPS implements the policy, and yes, it uses longest-prefix match for destination, then source, then port ranges, etc. in essentially the way that the decorelation algorithm describes. The de-corelation algorithm with independantly invented by Luis Sanchez/BBN, myself and others, around the time of RFC2401 hitting the press. 3) Pluto actually provides an ordering mechanism between policies which is the ordering mechanism for policies as specified in 4301. --=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT8+984qHRg3pndX9AQKufgQA2f6bYNCGnZCb7B+32KC6rZP3pBnA2eip CRohClis0TUopauaEZ9kT/IY7jpyWjzvGIRSPZxM0BiUwu3y5dYckVVqEZioJ2Ku TyhTSYi3/upBY36lXmqAgFKL7Ougsh+CcGsvg50uN41K7MdP2u/YU5CFJqdx9LyA sqRNjRKB09s= =vWqW -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Thu Jun 7 09:15:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B1E11E8108 for ; Thu, 7 Jun 2012 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVo+9APiCyKA for ; Thu, 7 Jun 2012 09:15:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AF9E611E8085 for ; Thu, 7 Jun 2012 09:15:51 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q57GFcNn045441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jun 2012 09:15:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jun 2012 09:15:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> References: To: Yoav Nir X-Mailer: Apple Mail (2.1278) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:15:52 -0000 On Jun 7, 2012, at 8:20 AM, Yoav Nir wrote: > Trying to think up ways to deal with this, I can think of some: >=20 > * Get all ISPs to stop dropping fragments. This would be great, but as = the saying goes, you are so not in charge. >=20 > * Find ways of making the packets smaller: move to PSK, fiddle with = trust anchors so that only one cert is needed, avoid sending CRLs, = hash-and-URL, etc. These are not always successful, and often require = more configuration than we would like. >=20 > * Build a fragmentation layer within IKE, so IKE messages are broken = into several packets that get reassembled at the destination. This is = the path taken by one of our competitors [1]. This means that IKE has = segmentation in addition to other TCP-like features such as = retransmission. >=20 > * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is = already allocated to "ISAKMP". We have had IKE running over TCP for = several years for remote access clients. This was done because remote = access clients connect from behind some very dodgy NAT devices, and some = of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of = a packet >512 bytes. That would be interoperable with current = deployments (although they would not see the second attempt, of course), = it costs little, and is trivial to implement. --Paul Hoffman From paul@cypherpunks.ca Thu Jun 7 09:44:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5191011E810F for ; Thu, 7 Jun 2012 09:44:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2krTmftF8Vr for ; Thu, 7 Jun 2012 09:44:00 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id AC93611E8108 for ; Thu, 7 Jun 2012 09:44:00 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 1C6E385643; Thu, 7 Jun 2012 12:43:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 0DEB08032E; Thu, 7 Jun 2012 12:43:57 -0400 (EDT) Date: Thu, 7 Jun 2012 12:43:57 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> Message-ID: References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:44:01 -0000 On Thu, 7 Jun 2012, Paul Hoffman wrote: >> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to "ISAKMP". We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. > > * Use IKE over TCP only after IKE over UDP fails during transmission of a packet >512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. Is that compatible with some vendor's tcp port 10000 implementation? Also, if we are doing this, I'd prefer to be able to signal which tcp port to use, to make it more flexible to bypass port 500 blocks (which is part of the tcp 10000 implementation I believe) Paul From paul.hoffman@vpnc.org Thu Jun 7 09:55:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AF211E808C for ; Thu, 7 Jun 2012 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmNMKvJto34R for ; Thu, 7 Jun 2012 09:54:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB4CC21F85C4 for ; Thu, 7 Jun 2012 09:54:55 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q57Gsafa046811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jun 2012 09:54:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jun 2012 09:54:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <301D4415-9FBC-41E6-BAF9-5DA1D772ECF6@vpnc.org> References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1278) Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:55:00 -0000 On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: > On Thu, 7 Jun 2012, Paul Hoffman wrote: >=20 >>> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 = is already allocated to "ISAKMP". We have had IKE running over TCP for = several years for remote access clients. This was done because remote = access clients connect from behind some very dodgy NAT devices, and some = of those do drop fragments. Getting this behavior at the ISP is novel. >>=20 >> * Use IKE over TCP only after IKE over UDP fails during transmission = of a packet >512 bytes. That would be interoperable with current = deployments (although they would not see the second attempt, of course), = it costs little, and is trivial to implement. >=20 > Is that compatible with some vendor's tcp port 10000 implementation? Why should I care about that completely non-standard use? Seriously. > Also, if we are doing this, I'd prefer to be able to signal which tcp > port to use, to make it more flexible to bypass port 500 blocks (which > is part of the tcp 10000 implementation I believe) That seems fine to me. However, assuming that a firewall that blocks = TCP/500 will not block TCP/somerandomnewnumber is not wise. --Paul Hoffman From TMacKenzie@mocana.com Thu Jun 7 09:59:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4327311E811A for ; Thu, 7 Jun 2012 09:59:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yzTzT6pD2tb for ; Thu, 7 Jun 2012 09:59:28 -0700 (PDT) Received: from smtp.mocana.com (smtp.mocana.com [38.113.118.196]) by ietfa.amsl.com (Postfix) with SMTP id 5E99C11E8110 for ; Thu, 7 Jun 2012 09:59:28 -0700 (PDT) X-ASG-Debug-ID: 1339088364-01c78808d8117fd0001-2ho77O Received: from email.mocana.com ([10.200.16.9]) by smtp.mocana.com with ESMTP id x2h0obZcLWrh1gHW for ; Thu, 07 Jun 2012 09:59:24 -0700 (PDT) X-Barracuda-Envelope-From: TMacKenzie@mocana.com Received: from yugi.mocana.local ([10.200.16.9]) by yugi.mocana.local ([10.200.16.9]) with mapi; Thu, 7 Jun 2012 09:59:24 -0700 From: Tim MacKenzie To: "ipsec@ietf.org" Date: Thu, 7 Jun 2012 09:59:23 -0700 Thread-Topic: [IPsec] IPsec SPD search X-ASG-Orig-Subj: Re: [IPsec] IPsec SPD search Thread-Index: Ac1EzuPEFszi8x8MTkK4k51Ig4XYGg== Message-ID: In-Reply-To: <50DADDE6B33B1B47904E685AAFDC1824464E70FD0C@yugi.mocana.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.200.16.9] X-Barracuda-Start-Time: 1339088364 X-Barracuda-URL: http://10.200.40.6:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at mocana.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.99213 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: Re: [IPsec] IPsec SPD search X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 17:00:44 -0000 I think the key point here is that XFRM allows the policy administrator (be it human or software) to manage their own order by specifying the priority value in the policy when it is added. As I recall, the XFRM SPD just adds the policy at the correct point in the list to maintain a monotonic sequence of priorities. Tim MacKenzie > >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Michael Richardson >Sent: Wednesday, June 06, 2012 1:31 PM >To: ipsec@ietf.org >Subject: Re: [IPsec] IPsec SPD search > > >>>>>> "Paul" =3D=3D Paul Wouters writes: > Paul> That seems more predictable and stable then "whatever > Paul> connection loaded > Paul> first"? > >1) Please don't confuse the Linux NETKEY/XFRM's API with RFC4301. > RFC4301 says that the admin controls the order of the policies, while > XFRM does not give the admin any real control, and embeds policies > in the kernel in a really really really bad way, rather than in a > policy daemon.=20 > >2) Please don't confuse KLIPS with RFC4301. KLIPS implements the > policy, and yes, it uses longest-prefix match for destination, then > source, then port ranges, etc. in essentially the way that the > decorelation algorithm describes. The de-corelation algorithm with > independantly invented by Luis Sanchez/BBN, myself and others, around > the time of RFC2401 hitting the press. > >3) Pluto actually provides an ordering mechanism between policies which > is the ordering mechanism for policies as specified in 4301. > > --=20 >] He who is tired of Weird Al is tired of life! | >firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device >driver[ > Kyoto Plus: watch the video > > then sign the petition.=20 From nico@cryptonector.com Thu Jun 7 10:26:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EEA21F873E for ; Thu, 7 Jun 2012 10:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr-SZBG1rAZm for ; Thu, 7 Jun 2012 10:26:18 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4D821F8740 for ; Thu, 7 Jun 2012 10:26:17 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 511F32AC079 for ; Thu, 7 Jun 2012 10:26:17 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 20C6F2AC059 for ; Thu, 7 Jun 2012 10:26:17 -0700 (PDT) Received: by vcqp1 with SMTP id p1so515066vcq.31 for ; Thu, 07 Jun 2012 10:26:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.69 with SMTP id i5mr2489972vdh.84.1339089976507; Thu, 07 Jun 2012 10:26:16 -0700 (PDT) Received: by 10.220.7.65 with HTTP; Thu, 7 Jun 2012 10:26:16 -0700 (PDT) In-Reply-To: <301D4415-9FBC-41E6-BAF9-5DA1D772ECF6@vpnc.org> References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> <301D4415-9FBC-41E6-BAF9-5DA1D772ECF6@vpnc.org> Date: Thu, 7 Jun 2012 12:26:16 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "ipsec@ietf.org WG" , Paul Wouters , Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 17:26:19 -0000 On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman wrote: > On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: >> Also, if we are doing this, I'd prefer to be able to signal which tcp >> port to use, to make it more flexible to bypass port 500 blocks (which >> is part of the tcp 10000 implementation I believe) > > That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise. Use port 80. (I'm being half facetious, half sarcastic, and half serious with this.) Nico -- From paul.hoffman@vpnc.org Thu Jun 7 10:40:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BAB11E812C for ; Thu, 7 Jun 2012 10:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDi8vMBziM0N for ; Thu, 7 Jun 2012 10:40:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2F11E812E for ; Thu, 7 Jun 2012 10:40:39 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q57HeJYl048571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jun 2012 10:40:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jun 2012 10:40:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F26449E-D1B4-4102-89C1-6DB05266FA84@vpnc.org> References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> <301D4415-9FBC-41E6-BAF9-5DA1D772ECF6@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1278) Cc: "ipsec@ietf.org WG" , Paul Wouters , Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 17:40:40 -0000 On Jun 7, 2012, at 10:26 AM, Nico Williams wrote: > On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman = wrote: >> On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: >>> Also, if we are doing this, I'd prefer to be able to signal which = tcp >>> port to use, to make it more flexible to bypass port 500 blocks = (which >>> is part of the tcp 10000 implementation I believe) >>=20 >> That seems fine to me. However, assuming that a firewall that blocks = TCP/500 will not block TCP/somerandomnewnumber is not wise. >=20 > Use port 80. >=20 > (I'm being half facetious, half sarcastic, and half serious with = this.) Being non-all-of-the-above: that won't work. Many firewalls that are = blocking UDP fragments do deep packet inspection on port 80 and will = throw away traffic that doesn't look like HTTP. (Don't get me started on = "look like"...) --Paul Hoffman From nico@cryptonector.com Thu Jun 7 10:55:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E9B21F86C2 for ; Thu, 7 Jun 2012 10:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyIbsfYdyXUw for ; Thu, 7 Jun 2012 10:55:48 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9E21F86BE for ; Thu, 7 Jun 2012 10:55:45 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 2E9F8438072 for ; Thu, 7 Jun 2012 10:55:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=cw7gSaLceqPTr74ZlRJU9 OxvwbAfYFb6C7a8B+/5xPnBVhb+LUAjM2/hv45W0hg5aFf515lNfvcl08sus/QRe GMTe7AdlPtq0CTD5psAR7wM/fPHD6E4vXfWz4Z8PfEMRdp4wBmNu7Cb2p8z4Uy1y zi8ITJAtqwLvTSXZdb+x4M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xTkU2XBO+jlp/glsGmf+ ChXZ6N4=; b=WXNMj/1dUVYg20cpStdDvghq4Q/Mk1B2axCOfgLdGu+CiGag0+A/ ebM4Ft1/dU8V1nLCBo6dLIVlPkODqQrmEjwra9YtNLKStj0wLmdfJxDmdNddLPxD w6C6beKjyVUq0+ERTUrh7pTMQvglYR7rlYlKX3pdvBem/k0w0Gq7A4Q= Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id B653843806C for ; Thu, 7 Jun 2012 10:55:44 -0700 (PDT) Received: by vbmv11 with SMTP id v11so803840vbm.27 for ; Thu, 07 Jun 2012 10:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.93.50 with SMTP id cr18mr2614771vdb.41.1339091741942; Thu, 07 Jun 2012 10:55:41 -0700 (PDT) Received: by 10.220.7.65 with HTTP; Thu, 7 Jun 2012 10:55:41 -0700 (PDT) In-Reply-To: <7F26449E-D1B4-4102-89C1-6DB05266FA84@vpnc.org> References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> <301D4415-9FBC-41E6-BAF9-5DA1D772ECF6@vpnc.org> <7F26449E-D1B4-4102-89C1-6DB05266FA84@vpnc.org> Date: Thu, 7 Jun 2012 12:55:41 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "ipsec@ietf.org WG" , Paul Wouters , Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 17:55:48 -0000 On Thu, Jun 7, 2012 at 12:40 PM, Paul Hoffman wrote: > On Jun 7, 2012, at 10:26 AM, Nico Williams wrote: >> Use port 80. >> >> (I'm being half facetious, half sarcastic, and half serious with this.) > > Being non-all-of-the-above: that won't work. Many firewalls that are blocking UDP fragments do deep packet inspection on port 80 and will throw away traffic that doesn't look like HTTP. (Don't get me started on "look like"...) To be closer to 100% serious I'd have to advocate an HTTP mapping of IKE and/or use of port 443. I'm not sure that I want to go there, but really, if you want to get past deep inspection nowadays then your best bet seems to be port 443. Which, of course, would not be enough. You'd find that ESP (encapsulated in UDP or not) also gets filtered, so you'd have to start sending ESP over HTTPS. And that's all kinds of not fun. At some point though one has to give up and declare the ISP useless. If you're a dissident in Iran, well, you're not using IPsec anyways, and Tor and all things port 443 are really your only friends, and if in the end the great firewalls get good enough, well, what can we do as far as *standards*? Not much. But I don't think Yoav was talking about this case, just a lousy ISP case, and for that I suspect deep packet inspection is not really the problem. For Yoav I suspect that IKE over TCP + UDP encapsulation of ESP is the way to go; worst case scenario: ESP over TCP. Nico -- From mcr@sandelman.ca Thu Jun 7 12:19:05 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E950F11E80C7 for ; Thu, 7 Jun 2012 12:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az4xxlP-Qxvg for ; Thu, 7 Jun 2012 12:19:05 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1775F11E80B0 for ; Thu, 7 Jun 2012 12:19:04 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 73B9981F1 for ; Thu, 7 Jun 2012 15:16:50 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 645849823C; Thu, 7 Jun 2012 15:18:49 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5F07398239 for ; Thu, 7 Jun 2012 15:18:49 -0400 (EDT) From: Michael Richardson To: "ipsec@ietf.org WG" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 07 Jun 2012 15:18:49 -0400 Message-ID: <19592.1339096729@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 19:19:06 -0000 >>>>> "Yoav" == Yoav Nir writes: Yoav> Trying to think up ways to deal with this, I can think of some: Yoav> * Get all ISPs to stop dropping fragments. This would be Yoav> great, but as the saying goes, you are so not in charge. 1) better diagnostics would help the end users point the finger properly. I wish the POSIX/BSD APIs would give the application an error when a fragment assembly times out.. Yoav> * Build a fragmentation layer within IKE, so IKE messages are Yoav> broken into several packets that get reassembled at the Yoav> destination. This is the path taken by one of our competitors Yoav> [1]. This means that IKE has segmentation in addition to other Yoav> TCP-like features such as retransmission. I proposed this for IKEv2 awhile ago. I twould be worthwhile for people who like certificates. Yoav> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP Yoav> port 500 is already allocated to "ISAKMP". We have had IKE Yoav> running over TCP for several years for remote access Yoav> clients. This was done because remote access clients connect Yoav> from behind some very dodgy NAT devices, and some of those do Yoav> drop fragments. Getting this behavior at the ISP is novel. And ESP over TCP on port 4500? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From ynir@checkpoint.com Thu Jun 7 14:53:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDA121F872E for ; Thu, 7 Jun 2012 14:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcgQ4GXskcrm for ; Thu, 7 Jun 2012 14:53:29 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE821F84DD for ; Thu, 7 Jun 2012 14:53:27 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q57LrH2l019420; Fri, 8 Jun 2012 00:53:25 +0300 X-CheckPoint: {4FD122C7-10003-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 8 Jun 2012 00:53:16 +0300 From: Yoav Nir To: Paul Hoffman Date: Fri, 8 Jun 2012 00:53:19 +0300 Thread-Topic: [IPsec] Fragmentation causing IKE to fail Thread-Index: Ac1E9/Dc+BREUCVBTlyFU/RBKfIvGw== Message-ID: References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> In-Reply-To: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 113baa6a029880f42edf67d86f6ab5200cefa31e3a Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:53:30 -0000 On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: >> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is a= lready allocated to "ISAKMP". We have had IKE running over TCP for several = years for remote access clients. This was done because remote access client= s connect from behind some very dodgy NAT devices, and some of those do dro= p fragments. Getting this behavior at the ISP is novel. >=20 > * Use IKE over TCP only after IKE over UDP fails during transmission of a= packet >512 bytes. That would be interoperable with current deployments (a= lthough they would not see the second attempt, of course), it costs little,= and is trivial to implement. This is possible, but since UDP is not reliable, you'd have to retransmit s= everal times before giving up on UDP. Even if we shorten the "at least a do= zen times over a period of at least several minutes", it's still long enoug= h for users to feel - get the "connection with Exchange lost" message in Ou= tlook, for example.=20 You could begin both UDP (first IKE message) and TCP's 3-way handshake at t= he same time. If the 3-way handshake completed in time, the larger packets = would go over that connection. If not, they would go over TCP. But all this is implementation-specific details. I'm more interested in hea= ring whether others are seeing this (I would guess yes, otherwise Cisco wou= ld not have developed the IKE fragments), and on whether there is interest = in the group in an IKE-over-TCP draft. Yoav From paul.hoffman@vpnc.org Thu Jun 7 15:01:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7938621F8754 for ; Thu, 7 Jun 2012 15:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCKqrBMQWNbG for ; Thu, 7 Jun 2012 15:01:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CBD8821F8735 for ; Thu, 7 Jun 2012 15:01:50 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q57M1fpg057422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jun 2012 15:01:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 7 Jun 2012 15:01:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> To: Yoav Nir X-Mailer: Apple Mail (2.1278) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 22:01:51 -0000 On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote: >=20 > On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: >=20 >>> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 = is already allocated to "ISAKMP". We have had IKE running over TCP for = several years for remote access clients. This was done because remote = access clients connect from behind some very dodgy NAT devices, and some = of those do drop fragments. Getting this behavior at the ISP is novel. >>=20 >> * Use IKE over TCP only after IKE over UDP fails during transmission = of a packet >512 bytes. That would be interoperable with current = deployments (although they would not see the second attempt, of course), = it costs little, and is trivial to implement. >=20 > This is possible, but since UDP is not reliable, you'd have to = retransmit several times before giving up on UDP. Even if we shorten the = "at least a dozen times over a period of at least several minutes", it's = still long enough for users to feel - get the "connection with Exchange = lost" message in Outlook, for example.=20 Good point. > You could begin both UDP (first IKE message) and TCP's 3-way handshake = at the same time. If the 3-way handshake completed in time, the larger = packets would go over that connection. If not, they would go over TCP. Yuck. But possibly the right answer. > But all this is implementation-specific details. I'm more interested = in hearing whether others are seeing this (I would guess yes, otherwise = Cisco would not have developed the IKE fragments), and on whether there = is interest in the group in an IKE-over-TCP draft. Please consider "IKE-with-TCP-and-UDP" before "IKE-over-TCP". --Paul Hoffman From ynir@checkpoint.com Thu Jun 7 15:06:12 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D110B21F879F for ; Thu, 7 Jun 2012 15:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij+akmv6PwJw for ; Thu, 7 Jun 2012 15:06:11 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 43FDE21F879D for ; Thu, 7 Jun 2012 15:06:10 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q57M5pOl021495; Fri, 8 Jun 2012 01:05:52 +0300 X-CheckPoint: {4FD125B9-10007-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 8 Jun 2012 01:05:49 +0300 From: Yoav Nir To: Nico Williams Date: Fri, 8 Jun 2012 01:05:47 +0300 Thread-Topic: [IPsec] Fragmentation causing IKE to fail Thread-Index: Ac1E+bKOVoupp2JvQdC7WNoMXCo4ow== Message-ID: References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> <301D4415-9FBC-41E6-BAF9-5DA1D772ECF6@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11ab20a62f3ff0cbbc6224db6209fa893ee3497fbf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Paul Wouters , Paul Hoffman Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 22:06:12 -0000 On Jun 7, 2012, at 8:26 PM, Nico Williams wrote: > On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman wro= te: >> On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: >>> Also, if we are doing this, I'd prefer to be able to signal which tcp >>> port to use, to make it more flexible to bypass port 500 blocks (which >>> is part of the tcp 10000 implementation I believe) >>=20 >> That seems fine to me. However, assuming that a firewall that blocks TCP= /500 will not block TCP/somerandomnewnumber is not wise. >=20 > Use port 80. Well, we came up with IKE-over-TCP for clients in 2002. That worked OK with= broken routers and NAT devices, but not with firewalls. So in 2003 we came= up with sending both IKE and IPsec over port 443 (because at the time few = firewalls other than ours validated that what goes on port 443 looks like S= SL). Finally in 2005 we came out with a client that actually uses SSL for t= raffic, so that firewalls have to either be SSL proxies or do traffic flow = analysis to recognize non-HTTPS. But this arms race between tunneling clients and firewalls is not the issue= here. Without getting into the whole net neutrality controversy, ISPs are = not supposed to, nor are they trying to block the creation of tunnels. What= they are doing is saving themselves the need to keep state on received fra= gments, which allows better scale and better performance with the same hard= ware. Yoav= From paul@cypherpunks.ca Thu Jun 7 15:09:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E9D21F865A for ; Thu, 7 Jun 2012 15:09:57 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh7ORWaOpPXB for ; Thu, 7 Jun 2012 15:09:57 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7602C21F8659 for ; Thu, 7 Jun 2012 15:09:57 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id A081885642; Thu, 7 Jun 2012 18:09:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 97EC78563F; Thu, 7 Jun 2012 18:09:55 -0400 (EDT) Date: Thu, 7 Jun 2012 18:09:55 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: Message-ID: References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 22:09:58 -0000 On Fri, 8 Jun 2012, Yoav Nir wrote: > But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft. Yes we have seen this in the past with openswan, though people affected would usually use 2048 bit RSA keys instead of 1024 bit RSA keys. And usually in combination with a CAcert without intermediary CAs. We would advise them to use 1024 and the IKE fragemntation problem would go away. Paul From ynir@checkpoint.com Thu Jun 7 15:13:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AF621F866C for ; Thu, 7 Jun 2012 15:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5uCkM6Ws9sH for ; Thu, 7 Jun 2012 15:13:48 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E338021F866D for ; Thu, 7 Jun 2012 15:13:47 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q57MDkio023555; Fri, 8 Jun 2012 01:13:46 +0300 X-CheckPoint: {4FD12793-10001-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 8 Jun 2012 01:13:44 +0300 From: Yoav Nir To: Paul Hoffman Date: Fri, 8 Jun 2012 01:13:43 +0300 Thread-Topic: [IPsec] Fragmentation causing IKE to fail Thread-Index: Ac1E+s2NMJUFnbOISZK8p2RybQToqg== Message-ID: <0418EEC3-EC1D-4B3F-8704-452E24F9D332@checkpoint.com> References: <259BBFFD-32CD-4117-97CF-AF38566ECF21@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11bbb8a90a9947640d1b43fc9c3ec3de94d4bbe966 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 22:13:48 -0000 On Jun 8, 2012, at 1:01 AM, Paul Hoffman wrote: > On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote: >=20 >>=20 >> On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: >>=20 >>>> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is= already allocated to "ISAKMP". We have had IKE running over TCP for severa= l years for remote access clients. This was done because remote access clie= nts connect from behind some very dodgy NAT devices, and some of those do d= rop fragments. Getting this behavior at the ISP is novel. >>>=20 >>> * Use IKE over TCP only after IKE over UDP fails during transmission of= a packet >512 bytes. That would be interoperable with current deployments = (although they would not see the second attempt, of course), it costs littl= e, and is trivial to implement. >>=20 >> This is possible, but since UDP is not reliable, you'd have to retransmi= t several times before giving up on UDP. Even if we shorten the "at least a= dozen times over a period of at least several minutes", it's still long en= ough for users to feel - get the "connection with Exchange lost" message in= Outlook, for example.=20 >=20 > Good point. >=20 >> You could begin both UDP (first IKE message) and TCP's 3-way handshake a= t the same time. If the 3-way handshake completed in time, the larger packe= ts would go over that connection. If not, they would go over TCP. >=20 > Yuck. But possibly the right answer. >=20 >> But all this is implementation-specific details. I'm more interested in = hearing whether others are seeing this (I would guess yes, otherwise Cisco = would not have developed the IKE fragments), and on whether there is intere= st in the group in an IKE-over-TCP draft. >=20 >=20 > Please consider "IKE-with-TCP-and-UDP" before "IKE-over-TCP". I think we can accommodate different implementations by requiring: - that initiator MAY switch back and forth between TCP and UDP - that responder MUST respond in the same transport where the request arri= ved - that responder must not depend on all requests for a particular flow com= ing through the same transport. For example, it's perfectly acceptable for = the first request of Main Mode to come over UDP, while the next two come ov= er TCP. Yoav= From svanru@gmail.com Thu Jun 7 22:04:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7502F21F87C5 for ; Thu, 7 Jun 2012 22:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMhGkYi3OkLP for ; Thu, 7 Jun 2012 22:04:44 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C76D21F87C4 for ; Thu, 7 Jun 2012 22:04:43 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1260454lbb.31 for ; Thu, 07 Jun 2012 22:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=2aiwiiZKcr6QkCQkYVxdXz7YgPPEh8JWIenarmVSiJM=; b=hEyiWTGKKh3At6NUObWaWBW0ASNPjPem45i9WHUe2BzHnEcY2lvX7WknXB6FkTN8St IhURj0bFeNzpv8BifOLN43ku3GaZBX3s/7UbPcZGHu4L1z+IXpOT0l+0kZSTYiabicJn wav6zj4bFwiOdS40xVKWtcni5iyrAVJNUmFX8ic2cm8jMLXnyS0IhrqSiT4NgDM1v+Tk 9L4f1fYCxIIvFKSEpwC0l0PAenK4q4W9URE9vnlYi8EGKtA2a7jGljavQuOToN0xn/HU DuOCVX0hsDmFMfq+VnDOLWXCTAsEIz+iEF+nQ1XXFoOB1py6Up6ZCG4FOq93UCcwDjdb C/bQ== Received: by 10.112.101.169 with SMTP id fh9mr2792261lbb.18.1339131882569; Thu, 07 Jun 2012 22:04:42 -0700 (PDT) Received: from svanpc ([93.188.44.200]) by mx.google.com with ESMTPS id hg4sm7915054lab.11.2012.06.07.22.04.39 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 22:04:40 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" , References: Date: Fri, 8 Jun 2012 09:05:03 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 05:04:44 -0000 Hi, we've being running into this issue constantly. I think it is serious problem for road warriers, who have to deal with all kinds of buggy or crippled SOHO routers installed in hotels etc. Many our customers complain that they are unable to connect to main office while being on business trip and most offen the reason is inability (or unwilling) of some intermediate router(s) to pass UDP fragments. > Trying to think up ways to deal with this, I can think of some: > > * Get all ISPs to stop dropping fragments. This would be great, but as the saying goes, you are so not in charge. No an option. > * Find ways of making the packets smaller: move to PSK, fiddle with trust anchors so that only one cert is needed, avoid sending CRLs, hash-and-URL, etc. These are not always successful, and often require more configuration than we would like. Not an option either. Corporate PKI has plenty of requirements to deal with and the requirement to make certificates smaller is the least. Hash-and-URL is a nice feature, but it requires an additional infrastructure that not every customer is willing to deploy. > * Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission. I like this approach, but as far as I know this is done for IKEv1 only. > * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to "ISAKMP". We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. IKE over TCP has its drawbacks. It eliminates the ability of IKE to be stateless (with COOKIE), thus considerably increasing its vulnerability to DoS attack. Switching between UDP and TCP (especially in the middle of exchange) considerably complicates protocol that is already complex in that part (remember switching to port 4500 on the fly). > Have others on this list run into this issue? > > Yoav I'm in favor of developing standard way of fragmenting big packets in IKEv2. I beleive there might be relatively simple solutions not breaking core protocol implementation. Regards, Smyslov Valery. From svanru@gmail.com Fri Jun 8 23:39:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750B921F8A02 for ; Fri, 8 Jun 2012 23:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 241Ns0J7GZZm for ; Fri, 8 Jun 2012 23:39:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66421F89FE for ; Fri, 8 Jun 2012 23:39:43 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2560303lbb.31 for ; Fri, 08 Jun 2012 23:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=0U9efGbho6y4tZKprqvbFkpLrUI5G4sTb4OE3g8+Mcg=; b=uF+sZCvlCN36gyxt7I1hxh0Fz/bwxkghLUt2QXz8e0cv0xgWfNulcdonZkMpntir6Y qk6MWXsuXE/7ykcGXXFyW+nKh8pWnHpw7ZsYIX1YejfcfpoMwQe7B+JOHI+T+gBe0Qkx LNEzNMRpK/z/iGojnz2sVDmFtMOCevzTzcsbhcxaOnPQimnJEBcbmIv+eBqMnldJV6DC UOD4rOqRUZQpSzzt8dnmOeSqKb8AF5wg832KOC6Jmo5eGVK3wPBRQzuhpRoxfFSYxTRq vQi0taItt0Tdfk5umaUi+ekMS91yCn4t1g7XKgBlCKsLeQhcH++kUZXK3NPXfadpmRoj Fp8g== Received: by 10.112.54.37 with SMTP id g5mr390418lbp.104.1339223982209; Fri, 08 Jun 2012 23:39:42 -0700 (PDT) Received: from svanpc ([93.188.44.200]) by mx.google.com with ESMTPS id lv13sm13229085lab.8.2012.06.08.23.39.39 (version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 23:39:41 -0700 (PDT) Message-ID: <660C85B6862C46E28EE68BC18B81DAC4@trustworks.com> From: "Valery Smyslov" To: "Tero Kivinen" References: <20433.61690.62853.184793@fireball.kivinen.iki.fi> Date: Sat, 9 Jun 2012 10:40:06 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 06:39:44 -0000 Hi, > Hash-and-URL do require customer to deploy www-server. I admit that > for some enterprices that might be burden to deploy, but quite a lot > of other enterprices do already have working deployed www-server they > can use... > > The url can be static, the certificate stored on that url can be > static, new certificates needs to be pushed to www-server only and > only when the new certiticate is enrolled. The url can be something > like http://certs.example.com//. > > Hash-and-URL should make the packets small enough that fragmentation > is not needed (especially if network supports 1280 byte packets). > > > * Build a fragmentation layer within IKE, so IKE messages are > > > broken into several packets that get reassembled at the > > > destination. This is the path taken by one of our competitors [1]. > > > This means that IKE has segmentation in addition to other TCP-like > > > features such as retransmission. > > > > I like this approach, but as far as I know this is done for IKEv1 > > only. > > This also requires finding pmtu and so on which means this whole > protocol gets quite complicated. Not necessary. For the sake of simplicity you may always fragment to the smallest packets guaranteed to pass through (576 bytes for IP4). IKE is not bulk transfer protocol, so performance is not an issue here. > If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not > enough, then I think IKE over TCP is the way to go. Most likely it > would be better to do it similarly we do NAT-T, i.e. instead of > switching to UDP port 4500 we would switch to TCP port 4500 for the > IKE_AUTH packets. Nothing prevents starting the creation of the TCP > connection while sending the first IKE_SA_INIT packet over UDP. > > As with NAT-T we can either start over TCP port 4500 immediately from > the beginning, if we like (i.e. we know from previous experience or > from configuration that we should do that). As with NAT-T we can use > either UDP or TCP port 4500 at will, regardless whether NAT was > detected or not. > > Also either end can send requests either over UDP or TCP and reply > would come back over same channel. In some cases we might want to > send packet first with UDP, and if we do not get any replies back for > our requests, we might want to fall back to TCP. In the other hand > there is no point of sending retransmissions to TCP connection, i.e. > we always only send one copy there (unless the TCP connection is > reset, and we recreate it). Anyways it is possible for both initiator > and responder to see same packet coming both over TCP and UDP, so > normal windowing and duplicate packet detection needs to be done (and > resending of replies if needed etc) > > Using TCP port 4500 instead of TCP port 500 has the benefit that it > might bypass those filters someone was complaining about. > > If we want to support ESP over that TCP channel too, then we need to > add some kind of framing which will tell the simulated UDP packet > length, i.e. similar what DNS does (prefix the packet with two byte > length field). On other hand we might want to add also non-IKE marker > somewhere too. Don't you think it looks too complicated? Two different transport each with two ports, special framing etc... > Adding one notification to the IKE_SA_INIT to indicate the support of > this feature would be need. > > Note, that if we run IKE_SA_INIT over UDP, then we can still support > stateless cookies, Successful COOKIE exchange make you sure that peer is real entity, but in case of TCP this information can't help TCP/IP stack to distinguith between bad and good boys. Or you have to constantly update firewall rules enabling and disabling incoming TCP connections from different addresses depending on success/failure of COOKIE exchange. > and for packets requiring fragmentation there is no > stateless processing anyways (whether the state is in the system > reassembly system, new IKEv2 reassembly system, or in the TCP does not > really matter). Any IKE exchange after COOKIE request is already statefull, so I don't see any problem here. > One open issue is how this fits with MOBIKE. I.e. if we get address > updates over UDP, do we immediately also create matching TCP > connection, and what do we do if that TCP connection creation fails, > even when the UDP worked etc. Yes, It will become more and more complex. > The ESP over TCP do cause some problems, as some implementations do > capture those packets already in the kernel without ever giving them > to the userland, and doing that from the TCP stream is bit harder and > requires bit more code. Oh... ESP over TCP is very problematic... And if the transports are different for IKE and ESP, we will catch all kinds of problems when IKE goes smoothly, but following ESP doesn't work at all. Regards, Smyslov Valery. From yaronf.ietf@gmail.com Sat Jun 9 09:34:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D1021F8633 for ; Sat, 9 Jun 2012 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE3PKeQVI7ZR for ; Sat, 9 Jun 2012 09:34:58 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C93A21F8630 for ; Sat, 9 Jun 2012 09:34:58 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1206504wgb.13 for ; Sat, 09 Jun 2012 09:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yzMTj9CHd/JNxeOKsX/OYUvY3aCNjgfRT28ZFL0foeA=; b=Q6h6c2HOgUDkwkkKXmxeHp2gvKOgNh6pFX/LBI7kdHeD1ku2fzeAu1VohaoBL2w2iK pS7fh1zkzhq6j6sffVf/fI66GgrlhAs2IFK7GKyRQQat9u7E7ZnQYt6q1efrF7+5y/s8 bCl2tKGtHV+Ygo2Q2JqZpfuzcjtrbd+AERViUcWz7hcuys4m0zNZkCsZ55+ok5JTH3RU cqeXLrkokMgO2BwDOd6QmNbEpoj0gm+KjJVtXDJfr/gp6CU2rhNf9W5aZ/0flV/1NR+Y kTbYP2TXQGMINgU6zmdDN7PgL9SydNOWC10gj7oBSUNRizOWpIKkqirrZapCR3Cl+SMl 22mA== Received: by 10.216.145.153 with SMTP id p25mr3495156wej.112.1339259697456; Sat, 09 Jun 2012 09:34:57 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-161-38.red.bezeqint.net. [79.176.161.38]) by mx.google.com with ESMTPS id ez4sm10324849wid.3.2012.06.09.09.34.54 (version=SSLv3 cipher=OTHER); Sat, 09 Jun 2012 09:34:55 -0700 (PDT) Message-ID: <4FD37B2D.4080005@gmail.com> Date: Sat, 09 Jun 2012 19:34:53 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <20433.61690.62853.184793@fireball.kivinen.iki.fi> <660C85B6862C46E28EE68BC18B81DAC4@trustworks.com> In-Reply-To: <660C85B6862C46E28EE68BC18B81DAC4@trustworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 16:34:59 -0000 Hi Valery, There's something I'm missing here. Let's say we go for a solution where we fragment IKE packets into pieces of 576 bytes, at the application level. Now, how do we determine the length of the ESP-over-UDP packets? Are you suggesting we fix them at 576 too, or do we need to have a (proprietary) path MTU discovery for this to *really* work? Thanks, Yaron On 06/09/2012 08:40 AM, Valery Smyslov wrote: > Hi, > >> Hash-and-URL do require customer to deploy www-server. I admit that >> for some enterprices that might be burden to deploy, but quite a lot >> of other enterprices do already have working deployed www-server they >> can use... >> >> The url can be static, the certificate stored on that url can be >> static, new certificates needs to be pushed to www-server only and >> only when the new certiticate is enrolled. The url can be something >> like http://certs.example.com//. >> >> Hash-and-URL should make the packets small enough that fragmentation >> is not needed (especially if network supports 1280 byte packets). > > > >>>> * Build a fragmentation layer within IKE, so IKE messages are >>>> broken into several packets that get reassembled at the >>>> destination. This is the path taken by one of our competitors [1]. >>>> This means that IKE has segmentation in addition to other TCP-like >>>> features such as retransmission. >>> >>> I like this approach, but as far as I know this is done for IKEv1 >>> only. >> >> This also requires finding pmtu and so on which means this whole >> protocol gets quite complicated. > > Not necessary. For the sake of simplicity you may always fragment to > the smallest packets guaranteed to pass through (576 bytes for IP4). > IKE is not bulk transfer protocol, so performance is not an issue here. > >> If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not >> enough, then I think IKE over TCP is the way to go. Most likely it >> would be better to do it similarly we do NAT-T, i.e. instead of >> switching to UDP port 4500 we would switch to TCP port 4500 for the >> IKE_AUTH packets. Nothing prevents starting the creation of the TCP >> connection while sending the first IKE_SA_INIT packet over UDP. >> >> As with NAT-T we can either start over TCP port 4500 immediately from >> the beginning, if we like (i.e. we know from previous experience or >> from configuration that we should do that). As with NAT-T we can use >> either UDP or TCP port 4500 at will, regardless whether NAT was >> detected or not. >> >> Also either end can send requests either over UDP or TCP and reply >> would come back over same channel. In some cases we might want to >> send packet first with UDP, and if we do not get any replies back for >> our requests, we might want to fall back to TCP. In the other hand >> there is no point of sending retransmissions to TCP connection, i.e. >> we always only send one copy there (unless the TCP connection is >> reset, and we recreate it). Anyways it is possible for both initiator >> and responder to see same packet coming both over TCP and UDP, so >> normal windowing and duplicate packet detection needs to be done (and >> resending of replies if needed etc) >> >> Using TCP port 4500 instead of TCP port 500 has the benefit that it >> might bypass those filters someone was complaining about. >> >> If we want to support ESP over that TCP channel too, then we need to >> add some kind of framing which will tell the simulated UDP packet >> length, i.e. similar what DNS does (prefix the packet with two byte >> length field). On other hand we might want to add also non-IKE marker >> somewhere too. > > Don't you think it looks too complicated? Two different transport > each with two ports, special framing etc... > >> Adding one notification to the IKE_SA_INIT to indicate the support of >> this feature would be need. >> >> Note, that if we run IKE_SA_INIT over UDP, then we can still support >> stateless cookies, > > Successful COOKIE exchange make you sure that peer is real entity, > but in case of TCP this information can't help TCP/IP stack to > distinguith between bad and good boys. Or you have to constantly update > firewall rules enabling and disabling incoming TCP connections > from different addresses depending on success/failure of > COOKIE exchange. > >> and for packets requiring fragmentation there is no >> stateless processing anyways (whether the state is in the system >> reassembly system, new IKEv2 reassembly system, or in the TCP does not >> really matter). > > Any IKE exchange after COOKIE request is already statefull, > so I don't see any problem here. > >> One open issue is how this fits with MOBIKE. I.e. if we get address >> updates over UDP, do we immediately also create matching TCP >> connection, and what do we do if that TCP connection creation fails, >> even when the UDP worked etc. > > Yes, It will become more and more complex. > >> The ESP over TCP do cause some problems, as some implementations do >> capture those packets already in the kernel without ever giving them >> to the userland, and doing that from the TCP stream is bit harder and >> requires bit more code. > > Oh... ESP over TCP is very problematic... And if the transports are different > for IKE and ESP, we will catch all kinds of problems when IKE goes > smoothly, but following ESP doesn't work at all. > > Regards, > Smyslov Valery. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From mcr@sandelman.ca Sun Jun 10 17:38:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD7D21F854C for ; Sun, 10 Jun 2012 17:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etaticaa33Pu for ; Sun, 10 Jun 2012 17:38:46 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFA21F8535 for ; Sun, 10 Jun 2012 17:38:44 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 68D40836F for ; Sun, 10 Jun 2012 20:36:25 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 091029823C; Sun, 10 Jun 2012 20:38:43 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 03A7598239 for ; Sun, 10 Jun 2012 20:38:42 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <4FD37B2D.4080005@gmail.com> References: <20433.61690.62853.184793@fireball.kivinen.iki.fi> <660C85B6862C46E28EE68BC18B81DAC4@trustworks.com> <4FD37B2D.4080005@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 10 Jun 2012 20:38:42 -0400 Message-ID: <31123.1339375122@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 00:38:46 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yaron" =3D=3D Yaron Sheffer writes: Yaron> There's something I'm missing here. Let's say we go for a Yaron> solution where we=20 Yaron> fragment IKE packets into pieces of 576 bytes, at the Yaron> application level.=20 We need to know what problem we are in fact facing. It seems to me that the "routers" causing the problems are in fact CGN, and therefore NAT is likely involved, and so ESP-over-UDP.=20=20 If we have a network where 576 byte ESP packets are required, then regardless of IKE fragmentation (or not), we have a problem to deal with at the IPsec level. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9U+EoqHRg3pndX9AQKtHwP/dwOxp1ekQM+lPDeAUQTru7hq47X4Z1Sp ie4AmwtOKgVRBxD6lCrkbaTgV3/N/RxZFhQOacuTAE+PyRHomEdy53lQnjNncO5n TSEKUBMxD6ix3FajFNFJBk4XkwJUY5EZH3ioNvNR/cRrjhW1dRAVThipC11Kcy/y oC1lGQyXZx8= =++5e -----END PGP SIGNATURE----- --=-=-=-- From zhang.ruishan@zte.com.cn Sun Jun 10 19:06:05 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E99B21F84B2 for ; Sun, 10 Jun 2012 19:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.238 X-Spam-Level: X-Spam-Status: No, score=-99.238 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfoUHlX9-RU6 for ; Sun, 10 Jun 2012 19:06:04 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E874621F84AF for ; Sun, 10 Jun 2012 19:06:03 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286205521606; Mon, 11 Jun 2012 10:04:15 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 71343.5521606; Mon, 11 Jun 2012 10:05:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q5B25pJb075038 for ; Mon, 11 Jun 2012 10:05:51 +0800 (GMT-8) (envelope-from zhang.ruishan@zte.com.cn) To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 9F9CD1CD:A524C2F1-48257A1A:000B1244; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.ruishan@zte.com.cn Date: Mon, 11 Jun 2012 10:05:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-11 10:05:52, Serialize complete at 2012-06-11 10:05:52 Content-Type: multipart/alternative; boundary="=_alternative 000B869B48257A1A_=" X-MAIL: mse01.zte.com.cn q5B25pJb075038 Subject: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 02:06:05 -0000 This is a multipart message in MIME format. --=_alternative 000B869B48257A1A_= Content-Type: text/plain; charset="US-ASCII" Dear All, I've submitted a new draft " Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity". This draft analyzes some issues in RFC 6311, and proposes some updates. Look forward to your comments. BR, Ruishan Zhang --=_alternative 000B869B48257A1A_= Content-Type: text/html; charset="US-ASCII"

Dear All,

  I've submitted a new draft " Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity". This draft analyzes some issues in RFC 6311,
and proposes some updates. Look forward to your comments.


BR,

Ruishan Zhang --=_alternative 000B869B48257A1A_=-- From svanru@gmail.com Sun Jun 10 22:37:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABE221F8503 for ; Sun, 10 Jun 2012 22:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tMQkO8iK5p0 for ; Sun, 10 Jun 2012 22:37:21 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D123F21F8471 for ; Sun, 10 Jun 2012 22:37:20 -0700 (PDT) Received: by lagv3 with SMTP id v3so3842878lag.31 for ; Sun, 10 Jun 2012 22:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=zhqEDc8nqErumY0MB7SAlzboPPYhZ254q99W1N08b3A=; b=gVQCejc72wWZtnVVU0QNxs+ruCy/NNDvtXYR7fh4tUToWE8IVhxzU3Eoy8HnFv/YU4 exb/or3VK5y8aPWucKMrWqbQ2as6XFUTdP8OmhWRUnMtvYiJPwdd4E1UC/VIpc/V1wLb wsixvTr1CUUkw0ttexu2LnkpJLSrwHDL7LYTTBpQllUWEjg/1PNfSOWx13wvwJNv5XKe Qg95ksSmZDrw9G6EI80Hq3N4kF8rVB1muFdx6ZHTr+WqgFpcf2QJoZSJD47zpIGgHX4M fQHiihBA4CRNqy0Gv+T0/5C3WFzfppis+GarkmC5lXWVTS5QVLXE6gDsmPoP0vAm7ipL HyYQ== Received: by 10.152.131.68 with SMTP id ok4mr15883692lab.47.1339393039741; Sun, 10 Jun 2012 22:37:19 -0700 (PDT) Received: from chichi (ppp91-77-179-39.pppoe.mtu-net.ru. [91.77.179.39]) by mx.google.com with ESMTPS id hg4sm22821269lab.11.2012.06.10.22.37.17 (version=SSLv3 cipher=OTHER); Sun, 10 Jun 2012 22:37:18 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" References: <20433.61690.62853.184793@fireball.kivinen.iki.fi> <660C85B6862C46E28EE68BC18B81DAC4@trustworks.com> <4FD37B2D.4080005@gmail.com> Date: Mon, 11 Jun 2012 09:37:12 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org, Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 05:37:21 -0000 Hi Yaron, I think this is a different problem from dropping UDP fragments, and, from my point of view, less important. For most of UDP traffic this is not an issue, because packets are small. For TCP traffic IPsec gateway usually copies Don't Fragment Bit to outer IP header, and usually this bit is set. If some intermediate router has smaller MTU, it should drop packet and send ICMP Destination Unreachable. Having received it IPsec gateway may store needed MTU value in SA and then report this value to any host in protected network that tries to send bigger TCP packet. This behavior is irrespective to whether ESP-in-UDP employed or just plain ESP, and is documented in RFC4301 section 8. Regards, Valery Smyslov. > Hi Valery, > > There's something I'm missing here. Let's say we go for a solution where > we fragment IKE packets into pieces of 576 bytes, at the application level. > > Now, how do we determine the length of the ESP-over-UDP packets? Are you > suggesting we fix them at 576 too, or do we need to have a (proprietary) > path MTU discovery for this to *really* work? > > Thanks, > Yaron From yaronf.ietf@gmail.com Sun Jun 10 23:53:55 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A612111E808A for ; Sun, 10 Jun 2012 23:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqnUVTBFI1RO for ; Sun, 10 Jun 2012 23:53:54 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5111E808D for ; Sun, 10 Jun 2012 23:53:53 -0700 (PDT) Received: by bkty8 with SMTP id y8so3788729bkt.31 for ; Sun, 10 Jun 2012 23:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3C41dAV3Y1pXPfMx8KiTbrLOk/lY5Ff+qvZS4IL6zKQ=; b=j8fkmbAOEgJQojpAYrVrBTfFJhlBQeieeXFSAAEpls715w7kr5Mf6jC4hWsB1iXb07 TjQ/dCMz0+HZa7Dhg9Fsi1Rjp3BBupfgGO/DgY5nw/uBIHf+R5WY9qn8FNJ0gn0PiT2p 5tF5v5zHI0Vji2rGkNaF1et7F+78I5lF/KzKRnv4uMu1Y3/RHRNJj9+NIAM2Ivlb2srm YppJEXjEyUKcgZkSwnBTTy7JDozhbJf1LlfK6GRl1qWPccqXJNh+24dCMI/ji8eoWevP zHyoQLNeC+IVLDLbhtmGlMaTrHnF6jPtODyc34Oh5HAnl4LLJRQT+w6SssU5CZVGi0e5 CBiQ== Received: by 10.205.137.17 with SMTP id im17mr10023220bkc.9.1339397632934; Sun, 10 Jun 2012 23:53:52 -0700 (PDT) Received: from [10.0.0.30] (bzq-79-177-232-245.red.bezeqint.net. [79.177.232.245]) by mx.google.com with ESMTPS id fw10sm14856751bkc.11.2012.06.10.23.53.50 (version=SSLv3 cipher=OTHER); Sun, 10 Jun 2012 23:53:51 -0700 (PDT) Message-ID: <4FD595FD.4030807@gmail.com> Date: Mon, 11 Jun 2012 09:53:49 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <20433.61690.62853.184793@fireball.kivinen.iki.fi> <660C85B6862C46E28EE68BC18B81DAC4@trustworks.com> <4FD37B2D.4080005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 06:53:55 -0000 Hi Valery, This is not a different problem, because whatever solution we choose, we must ensure the whole system is functional: both IKE and IPsec. Routers that drop IKE fragments will not hesitate to drop ESP/UDP fragments, too. Thanks for pointing out Sec. 8 to me. I suppose you are right about the behavior of implementations in the case of ESP-in-UDP, but from a formalistic point of view, note that: - RFC 4301, Sec. 8 says nothing about NAT traversal (ESP-in-UDP). - RFC 3948 (IPsec-in-UDP) says nothing about fragmentation... So we have a hole here. By the way, I'm not sure that UDP packets are still typically small. There's more and more video on the Internet, and I'm sure some of it is NOT on Skype. Thanks, Yaron On 06/11/2012 08:37 AM, Valery Smyslov wrote: > Hi Yaron, > > I think this is a different problem from dropping UDP fragments, and, > from my point of view, less important. For most of UDP traffic this is > not an issue, because packets are small. > For TCP traffic IPsec gateway usually copies Don't Fragment Bit > to outer IP header, and usually this bit is set. If some intermediate > router has smaller MTU, it should drop packet and send ICMP Destination > Unreachable. Having received it IPsec gateway may store needed MTU value > in SA and then report > this value to any host in protected network that tries to send bigger > TCP packet. > This behavior is irrespective to whether ESP-in-UDP employed or just > plain ESP, > and is documented in RFC4301 section 8. > > Regards, > Valery Smyslov. > >> Hi Valery, >> >> There's something I'm missing here. Let's say we go for a solution >> where we fragment IKE packets into pieces of 576 bytes, at the >> application level. >> >> Now, how do we determine the length of the ESP-over-UDP packets? Are >> you suggesting we fix them at 576 too, or do we need to have a >> (proprietary) path MTU discovery for this to *really* work? >> >> Thanks, >> Yaron > From ynir@checkpoint.com Mon Jun 11 02:05:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8617621F854E for ; Mon, 11 Jun 2012 02:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ3WnuN1O2w7 for ; Mon, 11 Jun 2012 02:05:30 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2FE21F8535 for ; Mon, 11 Jun 2012 02:05:29 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q5B95Ppn019522; Mon, 11 Jun 2012 12:05:25 +0300 X-CheckPoint: {4FD5B49D-10004-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 11 Jun 2012 12:05:23 +0300 From: Yoav Nir To: "'Yaron Sheffer'" , Valery Smyslov Date: Mon, 11 Jun 2012 12:05:22 +0300 Thread-Topic: [IPsec] Fragmentation causing IKE to fail Thread-Index: Ac1Hnvtb4C69hHUzQySF9hOxxF0p8AACWKQA Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A7C056C8A@il-ex01.ad.checkpoint.com> References: <20433.61690.62853.184793@fireball.kivinen.iki.fi> <660C85B6862C46E28EE68BC18B81DAC4@trustworks.com> <4FD37B2D.4080005@gmail.com> <4FD595FD.4030807@gmail.com> In-Reply-To: <4FD595FD.4030807@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11bae5de9a650bcf64998e51fff579694ab9c4fcbe Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:05:30 -0000 Hi Yaron IPsec usually reduces the effective PMTU by 50-100 bytes. There are ways to= overcome this: - the encrypting gateway can send ICMP fragmentation needed packets to the= origin of the packet - the encrypting gateway can fiddle with the MSS on TCP SYN and SYN-ACK to= reduce the size of TCP packets - the encrypting gateway can fragment before encrypting, thus making the E= SP (with or without UDP) small enough and apparently not fragmented. Yoav=20 -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: 11 June 2012 09:54 To: Valery Smyslov Cc: Tero Kivinen; ipsec@ietf.org; Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail Hi Valery, This is not a different problem, because whatever solution we choose, we mu= st ensure the whole system is functional: both IKE and IPsec. Routers that = drop IKE fragments will not hesitate to drop ESP/UDP fragments, too. Thanks for pointing out Sec. 8 to me. I suppose you are right about the beh= avior of implementations in the case of ESP-in-UDP, but from a formalistic = point of view, note that: - RFC 4301, Sec. 8 says nothing about NAT traversal (ESP-in-UDP). - RFC 3948 (IPsec-in-UDP) says nothing about fragmentation... So we have a hole here. By the way, I'm not sure that UDP packets are still typically small.=20 There's more and more video on the Internet, and I'm sure some of it is NOT= on Skype. Thanks, Yaron On 06/11/2012 08:37 AM, Valery Smyslov wrote: > Hi Yaron, > > I think this is a different problem from dropping UDP fragments, and,=20 > from my point of view, less important. For most of UDP traffic this is=20 > not an issue, because packets are small. > For TCP traffic IPsec gateway usually copies Don't Fragment Bit to=20 > outer IP header, and usually this bit is set. If some intermediate=20 > router has smaller MTU, it should drop packet and send ICMP=20 > Destination Unreachable. Having received it IPsec gateway may store=20 > needed MTU value in SA and then report this value to any host in=20 > protected network that tries to send bigger TCP packet. > This behavior is irrespective to whether ESP-in-UDP employed or just=20 > plain ESP, and is documented in RFC4301 section 8. > > Regards, > Valery Smyslov. > >> Hi Valery, >> >> There's something I'm missing here. Let's say we go for a solution=20 >> where we fragment IKE packets into pieces of 576 bytes, at the=20 >> application level. >> >> Now, how do we determine the length of the ESP-over-UDP packets? Are=20 >> you suggesting we fix them at 576 too, or do we need to have a >> (proprietary) path MTU discovery for this to *really* work? >> >> Thanks, >> Yaron > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Wed Jun 13 14:59:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CB621F8507 for ; Wed, 13 Jun 2012 14:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxGXenXnEuDs for ; Wed, 13 Jun 2012 14:59:05 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EF06C21F8505 for ; Wed, 13 Jun 2012 14:59:04 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q5DLx31Q031786 for ; Thu, 14 Jun 2012 00:59:03 +0300 X-CheckPoint: {4FD90D21-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 14 Jun 2012 00:59:01 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Thu, 14 Jun 2012 00:59:04 +0300 Thread-Topic: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt Thread-Index: Ac1Jr71hpPbaDPzwSkmGyyOwyLDbRQ== Message-ID: References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_DD01F18C1DA84FDD9C096242500B0792checkpointcom_" MIME-Version: 1.0 Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:59:06 -0000 --_000_DD01F18C1DA84FDD9C096242500B0792checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I've submitted this draft as a possible solution to the problem discussed i= n the thread about fragmentation causing IKE to fail. Comments are welcome. Yoav Begin forwarded message: From: "internet-drafts@ietf.org" > Subject: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt Date: June 13, 2012 7:13:55 PM GMT+03:00 To: Yoav Nir > A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-ipsecme-ike-tcp Revision: 00 Title: A TCP transport for the Internet Key Exchange Creation date: 2012-06-13 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-= tcp-00.txt Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 Abstract: This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are dropped. The IETF Secretariat --_000_DD01F18C1DA84FDD9C096242500B0792checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

I've= submitted this draft as a possible solution to the problem discussed in th= e thread about fragmentation causing IKE to fail.

= Comments are welcome.

Yoav

B= egin forwarded message:

Subject: New Version Notification for draft-nir-ipsecme= -ike-tcp-00.txt
Date: June 13, 20= 12 7:13:55 PM GMT+03:00
To: = Yoav Nir = <ynir@checkpoint.com>
<= /span>


A new version of I-D, draft-nir-ipsecme-ike-tcp-00= .txt
has been successfully submitted by Yoav Nir and posted to the
IE= TF repository.

Filename: draft-nir-ipsecme-ike-tcp
Revision: 00
Title: A TCP transport for the Intern= et Key Exchange
Creation date: 2012-06-13
WG ID: Individual Submission
Number of pages: 7
URL= :             <= a href=3D"http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.= txt">http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt
Status:          http://datat= racker.ietf.org/doc/draft-nir-ipsecme-ike-tcp
Htmlized:   =      http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp= -00


Abstract:
  This document describes using = TCP for IKE messages.  This facilitates
  the transport = of large messages over paths where fragments are
  dropped.



The IETF Secretariat

= --_000_DD01F18C1DA84FDD9C096242500B0792checkpointcom_-- From yaronf.ietf@gmail.com Wed Jun 13 15:40:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABFA11E80B6 for ; Wed, 13 Jun 2012 15:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTpYhxjXZg8E for ; Wed, 13 Jun 2012 15:40:25 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFB111E80B3 for ; Wed, 13 Jun 2012 15:40:25 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so762467wgb.13 for ; Wed, 13 Jun 2012 15:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Cw0K0OoQ3xvWpCb97afQlHO+jfmNuXoaYxe8CPZBqbE=; b=U2JiWvhaYFk3Fal+jW37lR+z/ql1aGmVWMNTaDlLIbIYnRjaQHPK6r0UnKTmcIbkTZ yrJMsRitaMiCxYylMAekIlBn1V5nJaOBsgj8ZfbbsGqb6nVAJm6j1kE6gtEEbSujuEX8 x4AU2HGHstV93EriweWHpsiZpr07qID6yJhXNzwNVZSscNwTzcYS8hgunUrWHy+2Cro4 srSJw5WS8mqPlxeXx8FdEtXFWuyDrcVFO/xqYKjwThfNevfXrLFlIPFPS2hp8x7NEJg2 sW+mCps/9iiXl0XTrQlImA1M8a+L9ZI0Sb3B8T1VtheHopfFuuzZbaDwppTeYv4hCZGI JU3Q== Received: by 10.216.140.2 with SMTP id d2mr12222086wej.0.1339627224244; Wed, 13 Jun 2012 15:40:24 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-161-38.red.bezeqint.net. [79.176.161.38]) by mx.google.com with ESMTPS id fo7sm14749857wib.9.2012.06.13.15.40.22 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 15:40:23 -0700 (PDT) Message-ID: <4FD916D5.3050207@gmail.com> Date: Thu, 14 Jun 2012 01:40:21 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:40:26 -0000 Hi Yoav, thank you for the new draft. A few comments: - Please mention the question of IKE keepalive messages ("liveness check"). Do you expect these messages to each be on a new connection? Or to preserve one long-lived one? - The draft kind of skirts the question, and I would prefer to be clear: we are standardizing new behavior for IKEv2, not for IKEv1. - In the security considerations, we should mention that (under certain assumptions), it is easier for an off-path attacker to reset a TCP connection than a UDP "connection". - There are obvious advantages to negotiating this capability: you don't have clients sending SYNs that will get rejected by firewalls/endpoints. Especially in IKEv2 where the heavy stuff only happens on message #3. - 2.3: disallowing retransmissions implies a change on both transmitter and receiver, and I think this is unnecessary. You can change the IKE timeouts on the sender to achieve the same behavior, even if rarely an odd retransmission does slip through. Thanks, Yaron On 06/14/2012 12:59 AM, Yoav Nir wrote: > Hi > > I've submitted this draft as a possible solution to the problem > discussed in the thread about fragmentation causing IKE to fail. > > Comments are welcome. > > Yoav > > Begin forwarded message: > >> *From: *"internet-drafts@ietf.org " >> > >> *Subject: **New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt* >> *Date: *June 13, 2012 7:13:55 PM GMT+03:00 >> *To: *Yoav Nir > >> >> >> A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt >> has been successfully submitted by Yoav Nir and posted to the >> IETF repository. >> >> Filename:draft-nir-ipsecme-ike-tcp >> Revision:00 >> Title:A TCP transport for the Internet Key Exchange >> Creation date:2012-06-13 >> WG ID:Individual Submission >> Number of pages: 7 >> URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt >> Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp >> Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 >> >> >> Abstract: >> This document describes using TCP for IKE messages. This facilitates >> the transport of large messages over paths where fragments are >> dropped. >> >> >> >> >> The IETF Secretariat > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From project.secpro@googlemail.com Thu Jun 14 02:55:42 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7021821F865F for ; Thu, 14 Jun 2012 02:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erdGCzJ4md6I for ; Thu, 14 Jun 2012 02:55:42 -0700 (PDT) Received: from mail-bk0-f66.google.com (mail-bk0-f66.google.com [209.85.214.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6221F866A for ; Thu, 14 Jun 2012 02:55:41 -0700 (PDT) Received: by bkty5 with SMTP id y5so294652bkt.1 for ; Thu, 14 Jun 2012 02:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=eIBljLYcyKXuprfpV4dsEzaTP62avFg6P2vn76P5KLo=; b=gOgtF8JMaMsj0p+SZSK7YFB0Wl5jm6Fa/vIe+zD2WelG7Bdnaiq6dE+rVkAtH80vGk TieYlZp4O4hXhItx7mwo1TL1WwHmT2B6XbEp5c1LMoMDDLpG3OXhf/QBt8rd1HdiIKg6 rqcuRdQ1iatVRwJqXbeUq9Bp6756xVzo3cM8NeI9PiNkPidfM+p8qsTYndVEYFXuEths UypIppGsykao7gNc2+qNZ8Mdx0rsSr+L0ck/vK88VH0QNqhKyzlMZyJ9Gas/XVRiVhxf 949ag0Q4IfY6/r7DYO96eCrZ4qi1KSL/00tiChCDBVc1p/oAF/a5oW/FWNhcHc+ZwdU6 XtmQ== Received: by 10.204.150.92 with SMTP id x28mr604082bkv.61.1339667740484; Thu, 14 Jun 2012 02:55:40 -0700 (PDT) Received: from SECPROTebbe ([141.71.48.75]) by mx.google.com with ESMTPS id h18sm5913431bkh.8.2012.06.14.02.55.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jun 2012 02:55:39 -0700 (PDT) From: "Sec Pro" To: Date: Thu, 14 Jun 2012 11:55:39 +0200 Message-ID: <06b101cd4a13$db9595e0$92c0c1a0$@googlemail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B2_01CD4A24.9F2088C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1KE9q7+dWaLWE0QJqD9uyPCvSK/g== Content-Language: de Subject: [IPsec] documentation of pf_key extensions (not in rfc 2367) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 09:57:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06B2_01CD4A24.9F2088C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I do not know if this is the right place for posting my question, but I hope so. If not, I am very sorry for the inconvenience. I just started digging me into the topic of PF_KEY and the manually manipulation of the SAD and SPD from the user land of Linux. My problem is finding substantial documentation of the extensions of PF_KEY. I know the RFC 2367, but this document does not describe the newer symbolic names (not mentioned there) and their corresponding message types like: SADB_X_SPDSETIDX, SADB_X_SPDDELETE2, SADB_X_EXT_SA2, SADB_X_EXT_NAT_T_OA, SADB_X_EXT_SEC_CTX and so on. I would be very appreciated if anybody could provide me with some kind of documentation. thanks in advance Chris ------=_NextPart_000_06B2_01CD4A24.9F2088C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I do not know = if this is the right place for posting my question, but I hope so. If = not, I am very sorry for the inconvenience.

 

I just started = digging me into the topic of PF_KEY and the manually manipulation of the = SAD and SPD from the user land of Linux. My problem is finding = substantial documentation of the extensions of PF_KEY. I know the RFC = 2367, but this document does not describe the newer symbolic names =  (not mentioned there) and their corresponding message types like: = SADB_X_SPDSETIDX, SADB_X_SPDDELETE2, = SADB_X_EXT_SA2, SADB_X_EXT_NAT_T_OA, SADB_X_EXT_SEC_CTX and so = on.

 

I would be = very appreciated if anybody could provide me with some kind of = documentation.

 

thanks in = advance Chris

------=_NextPart_000_06B2_01CD4A24.9F2088C0-- From kagarigi@cisco.com Thu Jun 14 04:14:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFF321F866D for ; Thu, 14 Jun 2012 04:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy3QmdTm6Pjy for ; Thu, 14 Jun 2012 04:14:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BE1A621F8664 for ; Thu, 14 Jun 2012 04:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kagarigi@cisco.com; l=20738; q=dns/txt; s=iport; t=1339672467; x=1340882067; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NWa7ZBZDHkLO6Td+M0TXiEew0Gr32H4qD+gtvMkhUns=; b=Qcxqi5scxQtaTSzde4CG0UkZPaLtI3OlY18RxDtsaXImrjpD+VnYdyRi BrBWyVbXckLWT2ZFyXE6t5ByPV1CgygWfeumUKToZwVB583cdbZk4/DCK X1XrK7EUmdlEKU98yCPD55tx5DO5GDeOd/Opv2h0MMKbnZ6Gbodj3FsYk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABbE2U+tJXG8/2dsb2JhbABFgkWyd4EHghgBAQEEEgEaRRcCAQgRBAEBCxYHBzIUCQgCBAESCBqHaZoMoACLMoUxYAOjN4FmgmA X-IronPort-AV: E=Sophos;i="4.75,769,1330905600"; d="scan'208,217";a="92197679" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jun 2012 11:14:27 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5EBERZt027708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Jun 2012 11:14:27 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.20]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Thu, 14 Jun 2012 06:14:26 -0500 From: "Kalyani Garigipati (kagarigi)" To: "zhang.ruishan@zte.com.cn" , "ipsec@ietf.org" Thread-Topic: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity Thread-Index: AQHNR3bOGp+psiXqGk6SDQUQJfTZDZb5reng Date: Thu, 14 Jun 2012 11:14:26 +0000 Message-ID: <52F04C02CB538E4DAAA0B493EBCA4A7503F03196@xmb-rcd-x11.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.236.236] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18968.006 x-tm-as-result: No--45.453300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_52F04C02CB538E4DAAA0B493EBCA4A7503F03196xmbrcdx11ciscoc_" MIME-Version: 1.0 Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 11:14:29 -0000 --_000_52F04C02CB538E4DAAA0B493EBCA4A7503F03196xmbrcdx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zhang, Thanks for going through the RFC 6311 . I have gone through your proposed draft and felt that there is some confus= ion regarding the message id concept of ikev2. I have seen that in section 2.3 you were comparing the higer sender value o= f x2 with y2. That is wrong. when x2 proposes the next higher message id to be used to se= nd a request , then on y2 you shld tally it with the next higher message id of the request= to be recieved (and not with the next higher message id of the request to be s= ent) in ikev2 the message id of requests to be sent are entirely different from= message id of requests to be received. that is why RFC says a message id is used four times on a given device. 1. message id X is used while sending a request 2. message id X is used while receiving the response 3. message id X is used to receive a request 4. message id X is used to send a response. please find the comments for each section Section 2.1: This is a known issue and that is why using RFC 6311, we are= synchronising the message id's Section 2.2: The peer is assumed to be proper anchor point which has correc= t info of message id of requests sent and recieved, even when peer is cluster member , among the two devices one of them would = be less wrong and have higher accurate values of message id's . so we pick up that value. I dont see any issue here. Section 2.3: First of all there is no relation between M1 and P1. on a given device. --- M1 is the proposed message id of the request to be sent P1 is the proposed message id of the request to be received. when simulatenous failover happens, x2 might have higher value of M1 when c= ompared to y2 , but x2 might have lower value of P1 when compared to y2. It does'nt matter. both are independent. what we eventually do is compare t= he M1 value across x2 and y2 and pick the higer one. same process is repeated for P1. case 1 to 6 are already handled by basic ikev2 RFC . like if we receive sam= e message id twice , then we retransmit or drop it if it is outside the win= dow. Section 3: during simultaneous failover both the cluster and the peer mem= ber would be in unreliable state. Both of them are wrong , but one of them is less wrong !!! so we want to st= art from that point to synchronise the message id's. so we are allowing both the members to announce their message id's and then= eventually we would synchronise to the higher number. I dont see any flaw here. Please explain with an example. By your proposal in case of simultaneous failover, both the cluster and pee= r will be in UNSYNED state and both would end up sending and rejecting the synchronisation request. This would lead to repeated synchronisation efforts and the problem of mess= age synchronisation is never solved. so UNSYNED state is not required. Section 4: I feel that RFC 6311 already solves the message id synchronisation issue. I dont think we need to increment M1 by double the window size as proposed = by you. Please support your proposal with an example with message id values of numb= ers instead of variables. Like M1 is 3 , M2 is 4 etc etc. Numbers make it more clear. regards, kalyani From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of z= hang.ruishan@zte.com.cn Sent: Monday, June 11, 2012 7:36 AM To: ipsec@ietf.org Subject: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availa= blity Dear All, I've submitted a new draft " Updates to the IKEv2 Extension for IKEv2/IPs= ec High Availablity". This draft analyzes some issues in RFC 6311, and proposes some updates. Look forward to your comments. BR, Ruishan Zhang --_000_52F04C02CB538E4DAAA0B493EBCA4A7503F03196xmbrcdx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Zhang,

 <= /p>

Thanks for going through = the RFC 6311 .

 <= /p>

I have gone through your =  proposed draft and felt that there is some confusion regarding the me= ssage id concept of ikev2.

 <= /p>

I have seen that in secti= on 2.3 you were comparing the higer sender value of x2 with y2.<= /span>

That is wrong. when x2 pr= oposes the next higher message id to be used to send a request ,=

then on y2 you shld tally= it with the next higher message id of the request to be recieved

    &= nbsp;       (and not with the next highe= r message id of the request to be sent)

 <= /p>

in ikev2 the  messag= e id of requests to be sent are entirely different from message id of reque= sts to be received.

that is why RFC says a me= ssage id is used four times on a given device.

 <= /p>

1. message id X is used w= hile sending a request

2. message id X is used w= hile receiving the response

3. message id X is used t= o receive a request

4. message id X is used t= o send a response.

 <= /p>

 <= /p>

please find the comments = for each section

 <= /p>

Section 2.1:  This i= s a known issue and that is why using RFC 6311,  we are synchronising = the message id's

 <= /p>

Section 2.2: The peer is = assumed to be proper anchor point which has correct info of message id of r= equests sent and recieved,

even when peer is cluster= member , among the two devices one of them would be less wrong and have hi= gher accurate values of message id's .

so we pick up that value.= I dont see any issue here.

 <= /p>

Section 2.3: First of all= there is no relation between M1 and P1.

on a given device.

--- M1 is the proposed me= ssage id of the request to be sent

    P1 is = the proposed message id of the request to be received.

 <= /p>

when simulatenous failove= r happens, x2 might have higher value of M1 when compared to y2 , but x2 mi= ght have lower value of P1 when compared to y2.

It does'nt matter. both a= re independent. what we eventually do is compare the M1 value across x2 and= y2 and pick the higer one.

same process is repeated = for P1.

 <= /p>

case 1 to 6 are already h= andled by basic ikev2 RFC . like if we receive same message id twice , then= we retransmit or drop it if it is outside the window.

 <= /p>

 <= /p>

Section 3:   du= ring simultaneous failover both the cluster and the peer member would be in= unreliable state.

Both of them are wrong , = but one of them is less wrong !!! so we want to start from that point to sy= nchronise the message id's.

 <= /p>

so we are allowing both t= he members to announce their message id's and then eventually we would sync= hronise to the higher number.

I dont see any flaw here.= Please explain with an example.

 <= /p>

By your proposal in case = of simultaneous failover, both the cluster and peer will be in UNSYNED stat= e and

both would end up sending= and rejecting the synchronisation request.

This would lead to repeat= ed synchronisation efforts and the problem of message synchronisation is ne= ver solved.

 <= /p>

so UNSYNED state is not r= equired.

 <= /p>

Section 4:

 <= /p>

I feel that RFC 6311 alre= ady solves the message id synchronisation issue.

I dont think we need to i= ncrement M1 by double the window size as proposed by you.

Please support your propo= sal with an example with message id values of numbers instead of variables.=

Like M1 is 3 , M2 is 4 et= c etc.

 <= /p>

Numbers make it more clea= r.

 <= /p>

regards,

kalyani=

 <= /p>

From: ipsec-bo= unces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of zhang.ruishan@zte.com.cn
Sent: Monday, June 11, 2012 7:36 AM
To: ipsec@ietf.org
Subject: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High= Availablity

 



Dear All,

  I've submitted a new draft " Updates to the IKEv2 Extension for IKEv2/IPsec High = Availablity". This draft analyzes some issues in RFC 6311,
and proposes some updates. Look forward to your comments.


BR,

Ruishan Zhang

--_000_52F04C02CB538E4DAAA0B493EBCA4A7503F03196xmbrcdx11ciscoc_-- From ynir@checkpoint.com Thu Jun 14 10:39:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588FA21F8631 for ; Thu, 14 Jun 2012 10:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.442 X-Spam-Level: X-Spam-Status: No, score=-9.442 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la4iqdFt66sC for ; Thu, 14 Jun 2012 10:39:02 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 581D221F862F for ; Thu, 14 Jun 2012 10:39:01 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q5EHcwVd011693; Thu, 14 Jun 2012 20:38:58 +0300 X-CheckPoint: {4FDA21A1-4-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Jun 2012 20:38:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 14 Jun 2012 20:38:56 +0300 From: Yoav Nir To: Yaron Sheffer Date: Thu, 14 Jun 2012 20:39:05 +0300 Thread-Topic: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt Thread-Index: Ac1KVJK6ZHZ+GhkgRF6EcKPOWhn2Gg== Message-ID: References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> In-Reply-To: <4FD916D5.3050207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 17:39:03 -0000 Hi Yaron Responses are inline. Yoav On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote: > Hi Yoav, >=20 > thank you for the new draft. A few comments: >=20 > - Please mention the question of IKE keepalive messages ("liveness=20 > check"). Do you expect these messages to each be on a new connection? Or= =20 > to preserve one long-lived one? I think section 2.1 makes it clear that the TCP connections should be short= -lived. Specifically, I would not send liveness checks, which are very shor= t requests and responses over TCP. I would use UDP exclusively for those. > - The draft kind of skirts the question, and I would prefer to be clear:= =20 > we are standardizing new behavior for IKEv2, not for IKEv1. I think it's suitable for both versions. If this gets adopted by the workin= g group, and people object to standardizing new stuff for IKEv1, I can remo= ve all mention of it.=20 Our present implementation works with IKEv1, and has done so for over 10 ye= ars. I could submit an Informational describing how Check Point's implement= ation does IKEv1 over TCP. But just as new ciphers would apply to both vers= ions, I think this transport can also be independent of version. > - In the security considerations, we should mention that (under certain=20 > assumptions), it is easier for an off-path attacker to reset a TCP=20 > connection than a UDP "connection". Yes, TCP presents some DoS opportunities not available for UDP. I'll look f= or an RFC that talks about this. And if there isn't one, there d**n well sh= ould be. > - There are obvious advantages to negotiating this capability: you don't= =20 > have clients sending SYNs that will get rejected by firewalls/endpoints.= =20 > Especially in IKEv2 where the heavy stuff only happens on message #3. SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a notific= ation over UDP that says "I support TCP" doesn't help much, because it cann= ot vouch for the path allowing TCP port 500. I wonder if there's an actual= use case for increasing the length field of payloads, so that IKE can supp= ort larger payloads when working over TCP. One use for this would be to sen= d large CRLs in a CERT payload. > - 2.3: disallowing retransmissions implies a change on both transmitter=20 > and receiver, and I think this is unnecessary. You can change the IKE=20 > timeouts on the sender to achieve the same behavior, even if rarely an=20 > odd retransmission does slip through. I guess. There is a MUST in section 2.4 for keeping retransmission detectio= n, so when implementing the transmitter, you can do either. It doesn't make= sense to retransmit at the application level when TCP does it for you. >=20 > Thanks, > Yaron >=20 > On 06/14/2012 12:59 AM, Yoav Nir wrote: >> Hi >>=20 >> I've submitted this draft as a possible solution to the problem >> discussed in the thread about fragmentation causing IKE to fail. >>=20 >> Comments are welcome. >>=20 >> Yoav >>=20 >> Begin forwarded message: >>=20 >>> *From: *"internet-drafts@ietf.org " >>> > >>> *Subject: **New Version Notification for draft-nir-ipsecme-ike-tcp-00.t= xt* >>> *Date: *June 13, 2012 7:13:55 PM GMT+03:00 >>> *To: *Yoav Nir > >>>=20 >>>=20 >>> A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt >>> has been successfully submitted by Yoav Nir and posted to the >>> IETF repository. >>>=20 >>> Filename:draft-nir-ipsecme-ike-tcp >>> Revision:00 >>> Title:A TCP transport for the Internet Key Exchange >>> Creation date:2012-06-13 >>> WG ID:Individual Submission >>> Number of pages: 7 >>> URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.t= xt >>> Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp >>> Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes using TCP for IKE messages. This facilitates >>> the transport of large messages over paths where fragments are >>> dropped. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From yaronf.ietf@gmail.com Thu Jun 14 12:12:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E8421F8775 for ; Thu, 14 Jun 2012 12:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-95nGbFG56p for ; Thu, 14 Jun 2012 12:12:53 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B341D21F865B for ; Thu, 14 Jun 2012 12:12:52 -0700 (PDT) Received: by bkty8 with SMTP id y8so1990942bkt.31 for ; Thu, 14 Jun 2012 12:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tv3MxYR0ZWlNu6qyzhoYRZeXojza3OSvXEhvv3YD/+Y=; b=XJ85nrg8p6CVu8FpBWI+Rwd0Dig5uUPgxxVP1s6WwuyMpRaCol7YjOuObPB7dfJFR5 zDkTbPm40E8WYKmpT6BoJo3ZY+g4NkNllCzzHkQOjpI06gzPsc225w+Gfb12ayToUYo7 a1OSrh5JJHT3XXmLeEAZVKJxV99dtvRIF+ZrL09FhGrd8m5IgkYBdxcp5DUMU+8hmulw Xx9Si50wMo+jFkfcKJuVkYhbr1BgvRZVm4AC+u6nP29wgAFreL8eyMmP9NV4jqkYgoS/ gcZc+dOy9gyWlxxn8ul1OREyAjwXgOwqfIpNhHNIoBiQSPkaKu5T7qDKOeYoaa3NXZwx TFMA== Received: by 10.204.157.6 with SMTP id z6mr1831569bkw.15.1339701171645; Thu, 14 Jun 2012 12:12:51 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-161-38.red.bezeqint.net. [79.176.161.38]) by mx.google.com with ESMTPS id gw6sm7715482bkc.16.2012.06.14.12.12.50 (version=SSLv3 cipher=OTHER); Thu, 14 Jun 2012 12:12:50 -0700 (PDT) Message-ID: <4FDA37B1.6000909@gmail.com> Date: Thu, 14 Jun 2012 22:12:49 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 19:12:54 -0000 Hi Yoav, please see below. Thanks, Yaron On 06/14/2012 08:39 PM, Yoav Nir wrote: > Hi Yaron > > Responses are inline. > > Yoav > > On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote: > >> Hi Yoav, >> >> thank you for the new draft. A few comments: >> >> - Please mention the question of IKE keepalive messages ("liveness >> check"). Do you expect these messages to each be on a new connection? Or >> to preserve one long-lived one? > > I think section 2.1 makes it clear that the TCP connections should be short-lived. Specifically, I would not send liveness checks, which are very short requests and responses over TCP. I would use UDP exclusively for those. Alternatively, one could use TCP keepalives. If you have a NAT device in the path (and you probably do, in the cases we're discussing here), its behavior will differ between the two options. > >> - The draft kind of skirts the question, and I would prefer to be clear: >> we are standardizing new behavior for IKEv2, not for IKEv1. > > I think it's suitable for both versions. If this gets adopted by the working group, and people object to standardizing new stuff for IKEv1, I can remove all mention of it. > > > Our present implementation works with IKEv1, and has done so for over 10 years. I could submit an Informational describing how Check Point's implementation does IKEv1 over TCP. But just as new ciphers would apply to both versions, I think this transport can also be independent of version. > With a Chair hat on, I strongly object to standardizing this for IKEv1. > >> - In the security considerations, we should mention that (under certain >> assumptions), it is easier for an off-path attacker to reset a TCP >> connection than a UDP "connection". > > Yes, TCP presents some DoS opportunities not available for UDP. I'll look for an RFC that talks about this. And if there isn't one, there d**n well should be. > >> - There are obvious advantages to negotiating this capability: you don't >> have clients sending SYNs that will get rejected by firewalls/endpoints. >> Especially in IKEv2 where the heavy stuff only happens on message #3. > > SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a notification over UDP that says "I support TCP" doesn't help much, because it cannot vouch for the path allowing TCP port 500. I wonder if there's an actual use case for increasing the length field of payloads, so that IKE can support larger payloads when working over TCP. One use for this would be to send large CRLs in a CERT payload. Firewalls have been known to eat up SYN packets with no RST, as you well know... Also, if UDP/500 goes through, you are basically guaranteed to have TCP/500, too. And implementations can be simplified if the usual case is: negotiate in IKE_SA_INIT, then switch to TCP. > >> - 2.3: disallowing retransmissions implies a change on both transmitter >> and receiver, and I think this is unnecessary. You can change the IKE >> timeouts on the sender to achieve the same behavior, even if rarely an >> odd retransmission does slip through. > > I guess. There is a MUST in section 2.4 for keeping retransmission detection, so when implementing the transmitter, you can do either. It doesn't make sense to retransmit at the application level when TCP does it for you. > >> >> Thanks, >> Yaron >> >> On 06/14/2012 12:59 AM, Yoav Nir wrote: >>> Hi >>> >>> I've submitted this draft as a possible solution to the problem >>> discussed in the thread about fragmentation causing IKE to fail. >>> >>> Comments are welcome. >>> >>> Yoav >>> >>> Begin forwarded message: >>> >>>> *From: *"internet-drafts@ietf.org" >>>> > >>>> *Subject: **New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt* >>>> *Date: *June 13, 2012 7:13:55 PM GMT+03:00 >>>> *To: *Yoav Nir> >>>> >>>> >>>> A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt >>>> has been successfully submitted by Yoav Nir and posted to the >>>> IETF repository. >>>> >>>> Filename:draft-nir-ipsecme-ike-tcp >>>> Revision:00 >>>> Title:A TCP transport for the Internet Key Exchange >>>> Creation date:2012-06-13 >>>> WG ID:Individual Submission >>>> Number of pages: 7 >>>> URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt >>>> Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp >>>> Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 >>>> >>>> >>>> Abstract: >>>> This document describes using TCP for IKE messages. This facilitates >>>> the transport of large messages over paths where fragments are >>>> dropped. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > From John.Leser@oracle.com Thu Jun 14 12:34:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226AF11E809D for ; Thu, 14 Jun 2012 12:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMK8H98ateyE for ; Thu, 14 Jun 2012 12:34:33 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0289B11E808C for ; Thu, 14 Jun 2012 12:34:32 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5EJYLqw004503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jun 2012 19:34:22 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5EJYKOb026468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 19:34:21 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5EJYJ09001605; Thu, 14 Jun 2012 14:34:20 -0500 Received: from [10.152.12.36] (/10.152.12.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Jun 2012 12:34:19 -0700 Message-ID: <4FDA3CB2.7040701@oracle.com> Date: Thu, 14 Jun 2012 15:34:10 -0400 From: John Leser User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:9.0) Gecko/20120113 Thunderbird/9.0.1 MIME-Version: 1.0 To: Yoav Nir References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: John.Leser@oracle.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 19:34:34 -0000 On 06/14/12 13:39, Yoav Nir wrote: > Hi Yaron > > Responses are inline. > > Yoav > > On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote: > >> Hi Yoav, >> >> thank you for the new draft. A few comments: >> >> - Please mention the question of IKE keepalive messages ("liveness >> check"). Do you expect these messages to each be on a new connection? Or >> to preserve one long-lived one? > > I think section 2.1 makes it clear that the TCP connections should be short-lived. Specifically, I would not send liveness checks, which are very short requests and responses over TCP. I would use UDP exclusively for those. > This section is a little unclear to me. Is the idea that the initiator of the exchange(s) may send up to requests, wait for the responses to arrive and then must close the connection? Or can the initiator perform as many exchanges as it likes over one TCP connection, so long as "knows" that it has requests it wants to send? If this connection closing requirement is designed to interact with the IKEv2 request window, please make it more clear. >> - The draft kind of skirts the question, and I would prefer to be clear: >> we are standardizing new behavior for IKEv2, not for IKEv1. > > I think it's suitable for both versions. If this gets adopted by the working group, and people object to standardizing new stuff for IKEv1, I can remove all mention of it. > > > Our present implementation works with IKEv1, and has done so for over 10 years. I could submit an Informational describing how Check Point's implementation does IKEv1 over TCP. But just as new ciphers would apply to both versions, I think this transport can also be independent of version. > I'd rather settle on the best possible solution for IKEv2 without worrying about making sure it works for IKEv1 as well. > >> - In the security considerations, we should mention that (under certain >> assumptions), it is easier for an off-path attacker to reset a TCP >> connection than a UDP "connection". > > Yes, TCP presents some DoS opportunities not available for UDP. I'll look for an RFC that talks about this. And if there isn't one, there d**n well should be. > I suggest adding a MUST that a lost TCP connection or truncated packet from the peer should never constitute a failed exchange (which in many cases, closes the SA). >> - There are obvious advantages to negotiating this capability: you don't >> have clients sending SYNs that will get rejected by firewalls/endpoints. >> Especially in IKEv2 where the heavy stuff only happens on message #3. > > SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a notification over UDP that says "I support TCP" doesn't help much, because it cannot vouch for the path allowing TCP port 500. I wonder if there's an actual use case for increasing the length field of payloads, so that IKE can support larger payloads when working over TCP. One use for this would be to send large CRLs in a CERT payload. > I agree with the concerns Yaron has raised here. I would much prefer that this be negotiated via notifications during the SA_INIT exchange. I see a number of benefits: 1. The TCP listening port could be explicitly exchanged (as data in the notification), rather than always assumed 500. This would allow operation in parallel with any legacy/proprietary use of that server port, and in general more deployment flexibility. 2. Since INIT always happens over UDP, as responder, I can immediately close any TCP connection that doesn't present an IKE header with an SPI I recognize. 3. It fits better with the IKEv2 design of never assuming the peer has capabilities beyond the base requirements without a notification/vendor payload indicating otherwise. >> - 2.3: disallowing retransmissions implies a change on both transmitter >> and receiver, and I think this is unnecessary. You can change the IKE >> timeouts on the sender to achieve the same behavior, even if rarely an >> odd retransmission does slip through. > > I guess. There is a MUST in section 2.4 for keeping retransmission detection, so when implementing the transmitter, you can do either. It doesn't make sense to retransmit at the application level when TCP does it for you. > Do we want to specify (maybe as a SHOULD) a fairly rapid fallback to UDP for retransmissions? This would help avoid protocol failures when the UDP path is functional but TCP is not. Messages ids should filter out any duplicates that get through. -John >> >> Thanks, >> Yaron >> >> On 06/14/2012 12:59 AM, Yoav Nir wrote: >>> Hi >>> >>> I've submitted this draft as a possible solution to the problem >>> discussed in the thread about fragmentation causing IKE to fail. >>> >>> Comments are welcome. >>> >>> Yoav >>> >>> Begin forwarded message: >>> >>>> *From: *"internet-drafts@ietf.org" >>>> > >>>> *Subject: **New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt* >>>> *Date: *June 13, 2012 7:13:55 PM GMT+03:00 >>>> *To: *Yoav Nir> >>>> >>>> >>>> A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt >>>> has been successfully submitted by Yoav Nir and posted to the >>>> IETF repository. >>>> >>>> Filename:draft-nir-ipsecme-ike-tcp >>>> Revision:00 >>>> Title:A TCP transport for the Internet Key Exchange >>>> Creation date:2012-06-13 >>>> WG ID:Individual Submission >>>> Number of pages: 7 >>>> URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt >>>> Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp >>>> Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 >>>> >>>> >>>> Abstract: >>>> This document describes using TCP for IKE messages. This facilitates >>>> the transport of large messages over paths where fragments are >>>> dropped. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Thu Jun 14 13:30:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E16A21F8731 for ; Thu, 14 Jun 2012 13:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.437 X-Spam-Level: X-Spam-Status: No, score=-9.437 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfl97-DIh1uj for ; Thu, 14 Jun 2012 13:30:21 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7521F8749 for ; Thu, 14 Jun 2012 13:30:20 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q5EKUHcq004469; Thu, 14 Jun 2012 23:30:17 +0300 X-CheckPoint: {4FDA49C6-0-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 14 Jun 2012 23:30:17 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 14 Jun 2012 23:30:14 +0300 From: Yoav Nir To: "John.Leser@oracle.com" Date: Thu, 14 Jun 2012 23:25:16 +0300 Thread-Topic: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt Thread-Index: Ac1KbIBp5DAiZUWCRBGtxXgOCEV5IA== Message-ID: <336D04CD-E3C9-467E-8586-9FBDF2E5DC11@checkpoint.com> References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> <4FDA3CB2.7040701@oracle.com> In-Reply-To: <4FDA3CB2.7040701@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:30:22 -0000 On Jun 14, 2012, at 10:34 PM, John Leser wrote: > On 06/14/12 13:39, Yoav Nir wrote: >> Hi Yaron >>=20 >> Responses are inline. >>=20 >> Yoav >>=20 >> On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote: >>=20 >>> Hi Yoav, >>>=20 >>> thank you for the new draft. A few comments: >>>=20 >>> - Please mention the question of IKE keepalive messages ("liveness >>> check"). Do you expect these messages to each be on a new connection? O= r >>> to preserve one long-lived one? >>=20 >> I think section 2.1 makes it clear that the TCP connections should be sh= ort-lived. Specifically, I would not send liveness checks, which are very s= hort requests and responses over TCP. I would use UDP exclusively for those= . >>=20 >=20 > This section is a little unclear to me. Is the idea that the initiator=20 > of the exchange(s) may send up to requests, wait=20 > for the responses to arrive and then must close the connection? Or can=20 > the initiator perform as many exchanges as it likes over one TCP=20 > connection, so long as "knows" that it has requests it wants to send?=20 > If this connection closing requirement is designed to interact with the=20 > IKEv2 request window, please make it more clear. OK, I will. It has nothing to do with the request window. The Initiator can= send as many requests as it wants as long as it has any to send. When it's= idle (like if all the necessary child SAs are ready) it should close the c= onnection rather than leave it idle. >>> - The draft kind of skirts the question, and I would prefer to be clear= : >>> we are standardizing new behavior for IKEv2, not for IKEv1. >>=20 >> I think it's suitable for both versions. If this gets adopted by the wor= king group, and people object to standardizing new stuff for IKEv1, I can r= emove all mention of it. >>=20 >> >> Our present implementation works with IKEv1, and has done so for over 10= years. I could submit an Informational describing how Check Point's implem= entation does IKEv1 over TCP. But just as new ciphers would apply to both v= ersions, I think this transport can also be independent of version. >> >=20 > I'd rather settle on the best possible solution for IKEv2 without=20 > worrying about making sure it works for IKEv1 as well. If that's where the group consensus is going, I am fine with making an Info= rmational document about IKEv1 over TCP in CP products. >>> - In the security considerations, we should mention that (under certain >>> assumptions), it is easier for an off-path attacker to reset a TCP >>> connection than a UDP "connection". >>=20 >> Yes, TCP presents some DoS opportunities not available for UDP. I'll loo= k for an RFC that talks about this. And if there isn't one, there d**n well= should be. >>=20 >=20 > I suggest adding a MUST that a lost TCP connection or truncated packet=20 > from the peer should never constitute a failed exchange (which in many=20 > cases, closes the SA). Agree >>> - There are obvious advantages to negotiating this capability: you don'= t >>> have clients sending SYNs that will get rejected by firewalls/endpoints= . >>> Especially in IKEv2 where the heavy stuff only happens on message #3. >>=20 >> SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a noti= fication over UDP that says "I support TCP" doesn't help much, because it c= annot vouch for the path allowing TCP port 500. I wonder if there's an act= ual use case for increasing the length field of payloads, so that IKE can s= upport larger payloads when working over TCP. One use for this would be to = send large CRLs in a CERT payload. >>=20 >=20 > I agree with the concerns Yaron has raised here. I would much prefer=20 > that this be negotiated via notifications during the SA_INIT exchange.=20 > I see a number of benefits: >=20 > 1. The TCP listening port could be explicitly exchanged (as data in the=20 > notification), rather than always assumed 500. This would allow=20 > operation in parallel with any legacy/proprietary use of that server=20 > port, and in general more deployment flexibility. >=20 > 2. Since INIT always happens over UDP, as responder, I can immediately=20 > close any TCP connection that doesn't present an IKE header with an SPI=20 > I recognize. I don't agree that IKE_SA_INIT should always be over UDP. The first flight = of packets from the server in TCP includes at most 2 packets. Then the serv= er has to wait for an ACK to continue. Same goes for the request. So beginn= ing with the IKE_AUTH exchange for TCP can add up to three roundtrips. This= is a shame when dealing with a peer that we know supports IKE.=20 > 3. It fits better with the IKEv2 design of never assuming the peer has=20 > capabilities beyond the base requirements without a notification/vendor=20 > payload indicating otherwise. Just as clients may start IKE over UDP port 4500, they should be able to be= gin IKE_SA_INIT over TCP. We can still have those notifications for clients= using UDP for IKE_SA_INIT, but it would be silly to send them over TCP. >>> - 2.3: disallowing retransmissions implies a change on both transmitter >>> and receiver, and I think this is unnecessary. You can change the IKE >>> timeouts on the sender to achieve the same behavior, even if rarely an >>> odd retransmission does slip through. >>=20 >> I guess. There is a MUST in section 2.4 for keeping retransmission detec= tion, so when implementing the transmitter, you can do either. It doesn't m= ake sense to retransmit at the application level when TCP does it for you. >>=20 >=20 > Do we want to specify (maybe as a SHOULD) a fairly rapid fallback to UDP= =20 > for retransmissions? This would help avoid protocol failures when the=20 > UDP path is functional but TCP is not. Messages ids should filter out=20 > any duplicates that get through. Maybe as implementation advice. It doesn't affect interoperability. >=20 > -John >=20 >>>=20 >>> Thanks, >>> Yaron >>>=20 >>> On 06/14/2012 12:59 AM, Yoav Nir wrote: >>>> Hi >>>>=20 >>>> I've submitted this draft as a possible solution to the problem >>>> discussed in the thread about fragmentation causing IKE to fail. >>>>=20 >>>> Comments are welcome. >>>>=20 >>>> Yoav >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> *From: *"internet-drafts@ietf.org" >>>>> > >>>>> *Subject: **New Version Notification for draft-nir-ipsecme-ike-tcp-00= .txt* >>>>> *Date: *June 13, 2012 7:13:55 PM GMT+03:00 >>>>> *To: *Yoav Nir> >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt >>>>> has been successfully submitted by Yoav Nir and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Filename:draft-nir-ipsecme-ike-tcp >>>>> Revision:00 >>>>> Title:A TCP transport for the Internet Key Exchange >>>>> Creation date:2012-06-13 >>>>> WG ID:Individual Submission >>>>> Number of pages: 7 >>>>> URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00= .txt >>>>> Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp >>>>> Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> This document describes using TCP for IKE messages. This facilitates >>>>> the transport of large messages over paths where fragments are >>>>> dropped. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>> Scanned by Check Point Total Security Gateway. >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 > Scanned by Check Point Total Security Gateway. From John.Leser@oracle.com Thu Jun 14 15:22:05 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FB521F85C2 for ; Thu, 14 Jun 2012 15:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_210=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y06jMTrs3Q5u for ; Thu, 14 Jun 2012 15:22:04 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3462221F8562 for ; Thu, 14 Jun 2012 15:22:04 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5EMLrmt023110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jun 2012 22:21:54 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5EMLrqJ028481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2012 22:21:53 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5EMLqsS007660; Thu, 14 Jun 2012 17:21:52 -0500 Received: from [10.152.12.36] (/10.152.12.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Jun 2012 15:21:52 -0700 Message-ID: <4FDA63F7.4070702@oracle.com> Date: Thu, 14 Jun 2012 18:21:43 -0400 From: John Leser User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:9.0) Gecko/20120113 Thunderbird/9.0.1 MIME-Version: 1.0 To: Yoav Nir References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> <4FDA3CB2.7040701@oracle.com> <336D04CD-E3C9-467E-8586-9FBDF2E5DC11@checkpoint.com> In-Reply-To: <336D04CD-E3C9-467E-8586-9FBDF2E5DC11@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: John.Leser@oracle.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 22:22:05 -0000 On 06/14/12 16:25, Yoav Nir wrote: > > On Jun 14, 2012, at 10:34 PM, John Leser wrote: > >> On 06/14/12 13:39, Yoav Nir wrote: >>> Hi Yaron >>> >>> Responses are inline. >>> >>> Yoav >>> >>> On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote: >>> >>>> Hi Yoav, >>>> >>>> thank you for the new draft. A few comments: >>>> >>>> - Please mention the question of IKE keepalive messages >>>> ("liveness check"). Do you expect these messages to each be on >>>> a new connection? Or to preserve one long-lived one? >>> >>> I think section 2.1 makes it clear that the TCP connections >>> should be short-lived. Specifically, I would not send liveness >>> checks, which are very short requests and responses over TCP. I >>> would use UDP exclusively for those. >>> >> >> This section is a little unclear to me. Is the idea that the >> initiator of the exchange(s) may send up to >> requests, wait for the responses to arrive and then must close the >> connection? Or can the initiator perform as many exchanges as it >> likes over one TCP connection, so long as "knows" that it has >> requests it wants to send? If this connection closing requirement >> is designed to interact with the IKEv2 request window, please make >> it more clear. > > OK, I will. It has nothing to do with the request window. The > Initiator can send as many requests as it wants as long as it has any > to send. When it's idle (like if all the necessary child SAs are > ready) it should close the connection rather than leave it idle. > Thanks for clarifying. This does make the MUST in that section seem a little out of place, since the condition of the initiator knowing it has no more requests seems rather vague for a MUST. I'd rather just allow either side to close the TCP connection at any time. This may seem a bit drastic, but if you think about it, you're balancing needs on both sides: 1. to not keep too much state, and 2. to not incur the latency and overhead of establishing new TCP connections. I suspect the state (memory) for a TCP connection could be significantly larger than for an IKEv2 SA, depending on buffers and implementation, etc. So it may be in either side's interest to drop the connection to conserve resources, or leave it open to optimize for performance when plenty of resources are available. I think we're already in agreement that implementations will have to handle TCP disconnects gracefully. >>>> - The draft kind of skirts the question, and I would prefer to >>>> be clear: we are standardizing new behavior for IKEv2, not for >>>> IKEv1. >>> >>> I think it's suitable for both versions. If this gets adopted by >>> the working group, and people object to standardizing new stuff >>> for IKEv1, I can remove all mention of it. >>> >>> Our present implementation works with IKEv1, >>> and has done so for over 10 years. I could submit an >>> Informational describing how Check Point's implementation does >>> IKEv1 over TCP. But just as new ciphers would apply to both >>> versions, I think this transport can also be independent of >>> version. >> >> I'd rather settle on the best possible solution for IKEv2 without >> worrying about making sure it works for IKEv1 as well. > > If that's where the group consensus is going, I am fine with making > an Informational document about IKEv1 over TCP in CP products. > >>>> - In the security considerations, we should mention that (under >>>> certain assumptions), it is easier for an off-path attacker to >>>> reset a TCP connection than a UDP "connection". >>> >>> Yes, TCP presents some DoS opportunities not available for UDP. >>> I'll look for an RFC that talks about this. And if there isn't >>> one, there d**n well should be. >>> >> >> I suggest adding a MUST that a lost TCP connection or truncated >> packet from the peer should never constitute a failed exchange >> (which in many cases, closes the SA). > > Agree > >>>> - There are obvious advantages to negotiating this capability: >>>> you don't have clients sending SYNs that will get rejected by >>>> firewalls/endpoints. Especially in IKEv2 where the heavy stuff >>>> only happens on message #3. >>> >>> SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending >>> a notification over UDP that says "I support TCP" doesn't help >>> much, because it cannot vouch for the path allowing TCP port 500. >>> I wonder if there's an actual use case for increasing the length >>> field of payloads, so that IKE can support larger payloads when >>> working over TCP. One use for this would be to send large CRLs in >>> a CERT payload. >>> >> >> I agree with the concerns Yaron has raised here. I would much >> prefer that this be negotiated via notifications during the SA_INIT >> exchange. I see a number of benefits: >> >> 1. The TCP listening port could be explicitly exchanged (as data in >> the notification), rather than always assumed 500. This would >> allow operation in parallel with any legacy/proprietary use of that >> server port, and in general more deployment flexibility. >> >> 2. Since INIT always happens over UDP, as responder, I can >> immediately close any TCP connection that doesn't present an IKE >> header with an SPI I recognize. > > I don't agree that IKE_SA_INIT should always be over UDP. The first > flight of packets from the server in TCP includes at most 2 packets. > Then the server has to wait for an ACK to continue. Same goes for the > request. So beginning with the IKE_AUTH exchange for TCP can add up > to three roundtrips. This is a shame when dealing with a peer that we > know supports IKE. You incur the latency of the TCP handshake during either SA_INIT or AUTH; I don't see the difference. A clever initiator could even initiate the TCP connection for AUTH concurrently with computation of the shared secret for the IKEv2 SA. > >> 3. It fits better with the IKEv2 design of never assuming the peer >> has capabilities beyond the base requirements without a >> notification/vendor payload indicating otherwise. > > Just as clients may start IKE over UDP port 4500, they should be able > to begin IKE_SA_INIT over TCP. We can still have those notifications > for clients using UDP for IKE_SA_INIT, but it would be silly to send > them over TCP. > The difference is port 4500 is part of RFC 5996 - a core IKEv2 capability. I could be convinced we should support SA_INIT over TCP, since it would allow IKEv2 to work when UDP transport is not functional, and would allow transit of large SA_INIT messages (8192-bit KE with man SA proposals could exceed 1280 bytes) when fragmented UDP is blocked. I'd like to see more opinions as to whether it is worthwhile. >>>> - 2.3: disallowing retransmissions implies a change on both >>>> transmitter and receiver, and I think this is unnecessary. You >>>> can change the IKE timeouts on the sender to achieve the same >>>> behavior, even if rarely an odd retransmission does slip >>>> through. >>> >>> I guess. There is a MUST in section 2.4 for keeping >>> retransmission detection, so when implementing the transmitter, >>> you can do either. It doesn't make sense to retransmit at the >>> application level when TCP does it for you. >>> >> >> Do we want to specify (maybe as a SHOULD) a fairly rapid fallback >> to UDP for retransmissions? This would help avoid protocol >> failures when the UDP path is functional but TCP is not. Messages >> ids should filter out any duplicates that get through. > > Maybe as implementation advice. It doesn't affect interoperability. > It's the typical gray area of how far you go beyond simple interop in trying to standardize "good" behavior. -John >> >> -John >> >>>> >>>> Thanks, Yaron >>>> >>>> On 06/14/2012 12:59 AM, Yoav Nir wrote: >>>>> Hi >>>>> >>>>> I've submitted this draft as a possible solution to the >>>>> problem discussed in the thread about fragmentation causing >>>>> IKE to fail. >>>>> >>>>> Comments are welcome. >>>>> >>>>> Yoav >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> *From: >>>>>> *"internet-drafts@ietf.org" >>>>>> >>>>>> > >>>>>> *Subject: **New Version Notification for >>>>>> draft-nir-ipsecme-ike-tcp-00.txt* *Date: *June 13, 2012 >>>>>> 7:13:55 PM GMT+03:00 *To: *Yoav >>>>>> Nir> >>>>>> >>>>>> >>>>>> A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt has >>>>>> been successfully submitted by Yoav Nir and posted to the >>>>>> IETF repository. >>>>>> >>>>>> Filename:draft-nir-ipsecme-ike-tcp Revision:00 Title:A TCP >>>>>> transport for the Internet Key Exchange Creation >>>>>> date:2012-06-13 WG ID:Individual Submission Number of >>>>>> pages: 7 URL: >>>>>> http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt >>>>>> >>>>>> Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 >>>>>> >>>>>> >>>>>> Abstract: This document describes using TCP for IKE >>>>>> messages. This facilitates the transport of large messages >>>>>> over paths where fragments are dropped. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> _______________________________________________ IPsec mailing >>>>> list IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> Scanned by Check Point Total Security Gateway. >>> >>> _______________________________________________ IPsec mailing >>> list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >> >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ IPsec mailing list > IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Fri Jun 15 03:14:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7189E21F85B8 for ; Fri, 15 Jun 2012 03:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 048WgZPOLf-H for ; Fri, 15 Jun 2012 03:14:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B179721F859B for ; Fri, 15 Jun 2012 03:14:16 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q5FAE2xt019567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2012 13:14:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q5FADxUU007973; Fri, 15 Jun 2012 13:13:59 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20443.2791.228505.762152@fireball.kivinen.iki.fi> Date: Fri, 15 Jun 2012 13:13:59 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:14:21 -0000 Yoav Nir writes: > I think section 2.1 makes it clear that the TCP connections should > be short-lived. Specifically, I would not send liveness checks, > which are very short requests and responses over TCP. I would use > UDP exclusively for those. As liveness checks are supposed to check whether other end is there, not whether the path you send packets is there, it does not matter which path is used. And also note that you are NOT supposed to send periodic liveness checks like some implementations are doing. You are only supposed to do them when you suspect something is wrong (i.e. no traffic from other end, ICMP error message, or in this case the TCP connection we have with other end is reset). > > - The draft kind of skirts the question, and I would prefer to be clear: > > we are standardizing new behavior for IKEv2, not for IKEv1. > > I think it's suitable for both versions. If this gets adopted by the > working group, and people object to standardizing new stuff for > IKEv1, I can remove all mention of it. I would be strongly against adding this to IKEv1. IKEv2 was published 7 years ago, people should start updating their products... > > Our present implementation works with IKEv1, and has done so for > over 10 years. I could submit an Informational describing how Check > Point's implementation does IKEv1 over TCP. But just as new ciphers > would apply to both versions, I think this transport can also be > independent of version. > I would be more happy if you would as a vendor try to get people to move IKEv2 not add some stuff to IKEv1. IKEv2 is much more robust protocol and provides standarized features for lots of things IKEv1 does with private extensions (configuration mode, xauth etc). > > - There are obvious advantages to negotiating this capability: you don't > > have clients sending SYNs that will get rejected by firewalls/endpoints. > > Especially in IKEv2 where the heavy stuff only happens on message #3. > > SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a > notification over UDP that says "I support TCP" doesn't help much, > because it cannot vouch for the path allowing TCP port 500. I I have not read your draft so I do not know how you do it (I am on vacation now), but I think capability indication is needed, not really negotiation, but indication from either or both ends that they do support this so it is worth of trying to establish the TCP connection. At least that would provide some better feedback, i.e if the other end do support it but TCP connection fails, then there is most likely firewall filtering TCP packets, compared to the other end not supporting this feature at all. > wonder if there's an actual use case for increasing the length field > of payloads, so that IKE can support larger payloads when working > over TCP. One use for this would be to send large CRLs in a CERT > payload. We already have Hash and URL format for transmitting large CERTs, and we have mechanism in the PKIX to provide CRLs over some other transport than IKE. I think we can keep the current 64k limit. > > > - 2.3: disallowing retransmissions implies a change on both transmitter > > and receiver, and I think this is unnecessary. You can change the IKE > > timeouts on the sender to achieve the same behavior, even if rarely an > > odd retransmission does slip through. > > I guess. There is a MUST in section 2.4 for keeping retransmission > detection, so when implementing the transmitter, you can do either. > It doesn't make sense to retransmit at the application level when > TCP does it for you. With MOBIKE it does make sense to retransmit at the application level, as it might be possible that the path used to send the first packet failed, but some other path can be used. Also if you send request over TCP and get TCP reset back, it might be useful to try to recreate the TCP connection and then retransmit. Some cases NAT boxes simply forget about the TCP session (reboots) and you only get indication that this TCP session is reset after you try to send data over the connection. -- kivinen@iki.fi From kivinen@iki.fi Fri Jun 15 03:34:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0321F85A1 for ; Fri, 15 Jun 2012 03:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4NSsZyHeeQK for ; Fri, 15 Jun 2012 03:34:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D19F21F855B for ; Fri, 15 Jun 2012 03:34:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q5FAY99K017612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2012 13:34:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q5FAY9Qx013220; Fri, 15 Jun 2012 13:34:09 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20443.4001.272157.561773@fireball.kivinen.iki.fi> Date: Fri, 15 Jun 2012 13:34:09 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <336D04CD-E3C9-467E-8586-9FBDF2E5DC11@checkpoint.com> References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> <4FDA3CB2.7040701@oracle.com> <336D04CD-E3C9-467E-8586-9FBDF2E5DC11@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 15 min Cc: "ipsec@ietf.org WG" , "John.Leser@oracle.com" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:34:18 -0000 Yoav Nir writes: > > I agree with the concerns Yaron has raised here. I would much prefer > > that this be negotiated via notifications during the SA_INIT exchange. > > I see a number of benefits: > > > > 1. The TCP listening port could be explicitly exchanged (as data in the > > notification), rather than always assumed 500. This would allow > > operation in parallel with any legacy/proprietary use of that server > > port, and in general more deployment flexibility. > > > > 2. Since INIT always happens over UDP, as responder, I can immediately > > close any TCP connection that doesn't present an IKE header with an SPI > > I recognize. > > I don't agree that IKE_SA_INIT should always be over UDP. The first > flight of packets from the server in TCP includes at most 2 packets. > Then the server has to wait for an ACK to continue. Same goes for > the request. So beginning with the IKE_AUTH exchange for TCP can add > up to three roundtrips. This is a shame when dealing with a peer > that we know supports IKE. I do not understand your statement above. Especially what does "server has to wait for an ACK to continue"? If there is space in window there is no need to wait for ACKs, you can just send next packet to the other end immediately when you have it. In normal case I would expect the flow being something like UDP: IKE_SA_INIT ---> <--- UDP: IKE_SA_INIT response TCP Syn ---> <--- TCP Syn, ACK TCP Ack ---> TCP IKE_AUTH ---> (note there is no need to wait anything here this packet can go immediately after the TCP Ack, if I remember right the data could even be in the ACK pcaket, but operating systems APIs usually do not support it) <--- TCP ACK (this might be delayed and combined with the packet below) <--- TCP IKE_AUTH response (IKEv2 Negotiation done) TCP Ack ---> I probably need to read your draft before I comment further, as it might already be explained there. > > 3. It fits better with the IKEv2 design of never assuming the peer has > > capabilities beyond the base requirements without a notification/vendor > > payload indicating otherwise. > > Just as clients may start IKE over UDP port 4500, they should be > able to begin IKE_SA_INIT over TCP. We can still have those > notifications for clients using UDP for IKE_SA_INIT, but it would be > silly to send them over TCP. The reason UDP port 4500 is allowed for even IKE_SA_INIT is that the client might have prior knowledge that the other end do support NAT-T. It might have had connection few minutes ago, that got teared down for some reason and it wants to re-establish it, or it might have been configured always to use port 4500. Note, that NAT_DETECTION_*_IP packets are supposed to be included even then... -- kivinen@iki.fi From ynir@checkpoint.com Fri Jun 15 04:23:24 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA2C21F8516 for ; Fri, 15 Jun 2012 04:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.089 X-Spam-Level: X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLHWHu-k3FDU for ; Fri, 15 Jun 2012 04:23:24 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5C21F85B6 for ; Fri, 15 Jun 2012 04:23:23 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q5FBND0M016020; Fri, 15 Jun 2012 14:23:17 +0300 X-CheckPoint: {4FDB1B06-0-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Jun 2012 14:23:13 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 15 Jun 2012 14:23:11 +0300 From: Yoav Nir To: Tero Kivinen Date: Fri, 15 Jun 2012 14:23:12 +0300 Thread-Topic: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt Thread-Index: Ac1K6T8erQo7liBETE2s6kADlFds+A== Message-ID: <82F98564-51F6-4060-975B-4E5E4487B9FA@checkpoint.com> References: <20120613161355.27869.27961.idtracker@ietfa.amsl.com> <4FD916D5.3050207@gmail.com> <4FDA3CB2.7040701@oracle.com> <336D04CD-E3C9-467E-8586-9FBDF2E5DC11@checkpoint.com> <20443.4001.272157.561773@fireball.kivinen.iki.fi> In-Reply-To: <20443.4001.272157.561773@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org WG" , "John.Leser@oracle.com" Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 11:23:24 -0000 On Jun 15, 2012, at 1:34 PM, Tero Kivinen wrote: >>> 2. Since INIT always happens over UDP, as responder, I can immediately= =20 >>> close any TCP connection that doesn't present an IKE header with an SPI= =20 >>> I recognize. >>=20 >> I don't agree that IKE_SA_INIT should always be over UDP. The first >> flight of packets from the server in TCP includes at most 2 packets. >> Then the server has to wait for an ACK to continue. Same goes for >> the request. So beginning with the IKE_AUTH exchange for TCP can add >> up to three roundtrips. This is a shame when dealing with a peer >> that we know supports IKE. >=20 > I do not understand your statement above. Especially what does "server > has to wait for an ACK to continue"? If there is space in window there > is no need to wait for ACKs, you can just send next packet to the > other end immediately when you have it. The application (in this context that is the IKE implementation) does not n= eed to wait, it can send everything immediately. But TCP has slow start. De= pending on OS, the first flight can be either 1 or 2 segments. If your IKE_= AUTH message takes more than two segments, the third segment will wait for = a TCP ack, effectively adding a round-trip. If you do the IKE_SA_INIT over TCP as well, then the ACK for the IKE_SA_INI= T (usually delivered in the IKE_SA_INIT response) doubles the receive windo= w, so the next request can be up to four segments. I don't think this is particularly significant, but this issue has come up = in proposals for TLS, where the ServerHello-Certificate-[ServerKeyExchange]= -ServerHelloDone flight can be very large, and break the 2 segment limit. Yoav From kivinen@iki.fi Fri Jun 15 05:12:47 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6696821F862B for ; Fri, 15 Jun 2012 05:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40UNW91KS4HR for ; Fri, 15 Jun 2012 05:12:46 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 91DBB21F8622 for ; Fri, 15 Jun 2012 05:12:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q5FCChWG006634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jun 2012 15:12:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q5FCCeWu026016; Fri, 15 Jun 2012 15:12:40 +0300 (EEST) Date: Fri, 15 Jun 2012 15:12:40 +0300 (EEST) Resent-From: kivinen@iki.fi Message-Id: <201206151212.q5FCCeWu026016@fireball.kivinen.iki.fi> X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <20443.9912.451566.5914@fireball.kivinen.iki.fi> Resent-Date: Fri, 15 Jun 2012 15:12:40 +0300 Resent-To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 12:12:47 -0000 Valery Smyslov writes: > > * Find ways of making the packets smaller: move to PSK, fiddle > > with trust anchors so that only one cert is needed, avoid sending > > CRLs, hash-and-URL, etc. These are not always successful, and > > often require more configuration than we would like. > > Not an option either. Corporate PKI has plenty of requirements to > deal with and the requirement to make certificates smaller is the > least. Hash-and-URL is a nice feature, but it requires an additional > infrastructure that not every customer is willing to deploy. Hash-and-URL do require customer to deploy www-server. I admit that for some enterprices that might be burden to deploy, but quite a lot of other enterprices do already have working deployed www-server they can use... The url can be static, the certificate stored on that url can be static, new certificates needs to be pushed to www-server only and only when the new certiticate is enrolled. The url can be something like http://certs.example.com//. Hash-and-URL should make the packets small enough that fragmentation is not needed (especially if network supports 1280 byte packets). > > * Build a fragmentation layer within IKE, so IKE messages are > > broken into several packets that get reassembled at the > > destination. This is the path taken by one of our competitors [1]. > > This means that IKE has segmentation in addition to other TCP-like > > features such as retransmission. > > I like this approach, but as far as I know this is done for IKEv1 > only. This also requires finding pmtu and so on which means this whole protocol gets quite complicated. > > * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port > > 500 is already allocated to "ISAKMP". We have had IKE running over > > TCP for several years for remote access clients. This was done > > because remote access clients connect from behind some very dodgy > > NAT devices, and some of those do drop fragments. Getting this > > behavior at the ISP is novel. > > IKE over TCP has its drawbacks. It eliminates the ability of IKE to > be stateless (with COOKIE), thus considerably increasing its > vulnerability to DoS attack. Switching between UDP and TCP > (especially in the middle of exchange) considerably complicates > protocol that is already complex in that part (remember switching to > port 4500 on the fly). If mechanisms already defined in the IKEv2 (Hash-and-URL etc) are not enough, then I think IKE over TCP is the way to go. Most likely it would be better to do it similarly we do NAT-T, i.e. instead of switching to UDP port 4500 we would switch to TCP port 4500 for the IKE_AUTH packets. Nothing prevents starting the creation of the TCP connection while sending the first IKE_SA_INIT packet over UDP. As with NAT-T we can either start over TCP port 4500 immediately from the beginning, if we like (i.e. we know from previous experience or from configuration that we should do that). As with NAT-T we can use either UDP or TCP port 4500 at will, regardless whether NAT was detected or not. Also either end can send requests either over UDP or TCP and reply would come back over same channel. In some cases we might want to send packet first with UDP, and if we do not get any replies back for our requests, we might want to fall back to TCP. In the other hand there is no point of sending retransmissions to TCP connection, i.e. we always only send one copy there (unless the TCP connection is reset, and we recreate it). Anyways it is possible for both initiator and responder to see same packet coming both over TCP and UDP, so normal windowing and duplicate packet detection needs to be done (and resending of replies if needed etc) Using TCP port 4500 instead of TCP port 500 has the benefit that it might bypass those filters someone was complaining about. If we want to support ESP over that TCP channel too, then we need to add some kind of framing which will tell the simulated UDP packet length, i.e. similar what DNS does (prefix the packet with two byte length field). On other hand we might want to add also non-IKE marker somewhere too. Adding one notification to the IKE_SA_INIT to indicate the support of this feature would be need. Note, that if we run IKE_SA_INIT over UDP, then we can still support stateless cookies, and for packets requiring fragmentation there is no stateless processing anyways (whether the state is in the system reassembly system, new IKEv2 reassembly system, or in the TCP does not really matter). One open issue is how this fits with MOBIKE. I.e. if we get address updates over UDP, do we immediately also create matching TCP connection, and what do we do if that TCP connection creation fails, even when the UDP worked etc. > I'm in favor of developing standard way of fragmenting big packets > in IKEv2. I beleive there might be relatively simple solutions not > breaking core protocol implementation. I think TCP is better approach. It has already solved most of the hard problems, and we can use very small wrapper layer to support it in the IKEv2. The ESP over TCP do cause some problems, as some implementations do capture those packets already in the kernel without ever giving them to the userland, and doing that from the TCP stream is bit harder and requires bit more code. -- kivinen@iki.fi From yaronf.ietf@gmail.com Sun Jun 17 23:37:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A307911E808C for ; Sun, 17 Jun 2012 23:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUmgTAzxVCY6 for ; Sun, 17 Jun 2012 23:37:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD22F21F850D for ; Sun, 17 Jun 2012 23:37:00 -0700 (PDT) Received: by bkty8 with SMTP id y8so4217201bkt.31 for ; Sun, 17 Jun 2012 23:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=vzU2xkew2P2fHiLGAoLS/eksBzHekp3Volq9iHUkS1o=; b=pDSbgiKaTFdNYjVfg7thCvhncrAdCNFb0swPxuCZGSmgAuqh7T2nQdkEEs+1nR5nZy WSEIvTTB252cNrMBt0P2Jj65DWQum9OTxUROax8tj1Tk0nv3XEhDA/zixsx8Ta9Eqko9 GIdQnp0HuCfBd5dymwwLSSXsPD38B2a0IgsIuivLAPi1rLqp5pbHUgqM1/JIalRuxYMr hcEpTlJNdeFYUckn3zNBu6OlncXvKw6S0ltRSwmszu0HORTc1/KGzDmB79fkcYrHnU/S FA2kIgiiMxy5kj5rSpaZxlAjR3/R5coe5QEYgg3l3MK+AF5WveuMdi/M7bPyjyouvTQF ZSoQ== Received: by 10.205.132.13 with SMTP id hs13mr6227360bkc.78.1340001419712; Sun, 17 Jun 2012 23:36:59 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-161-38.red.bezeqint.net. [79.176.161.38]) by mx.google.com with ESMTPS id n17sm17175588bkw.5.2012.06.17.23.36.57 (version=SSLv3 cipher=OTHER); Sun, 17 Jun 2012 23:36:58 -0700 (PDT) Message-ID: <4FDECC87.4090708@gmail.com> Date: Mon, 18 Jun 2012 09:36:55 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPsecme WG References: <20120618062532.D417072E026@rfc-editor.org> In-Reply-To: <20120618062532.D417072E026@rfc-editor.org> X-Forwarded-Message-Id: <20120618062532.D417072E026@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: RFC 6631 on Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 06:37:01 -0000 This concludes the current round of IKE-with-passwords proposals: RFC 6617, 6628 and 6631. All three RFCs are Experimental. I hope we will get some market traction behind this idea and will be able to progress one of them (or maybe something new) to Standards Track. Yaron -------- Original Message -------- Subject: RFC 6631 on Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) Date: Sun, 17 Jun 2012 23:25:32 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6631 Title: Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) Author: D. Kuegler, Y. Sheffer Status: Experimental Stream: IETF Date: June 2012 Mailbox: dennis.kuegler@bsi.bund.de, yaronf.ietf@gmail.com Pages: 26 Characters: 53353 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-kuegler-ipsecme-pace-ikev2-10.txt URL: http://www.rfc-editor.org/rfc/rfc6631.txt The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration. This document defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From zhang.ruishan@zte.com.cn Tue Jun 19 19:14:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9211E80EC; Tue, 19 Jun 2012 19:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.136 X-Spam-Level: X-Spam-Status: No, score=-98.136 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4qWDov8vKqv; Tue, 19 Jun 2012 19:14:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6533B11E80BA; Tue, 19 Jun 2012 19:14:23 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 28620433787882; Wed, 20 Jun 2012 10:10:40 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 52926.2301296981; Wed, 20 Jun 2012 10:14:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q5K2EAvp016620; Wed, 20 Jun 2012 10:14:10 +0800 (GMT-8) (envelope-from zhang.ruishan@zte.com.cn) In-Reply-To: <52F04C02CB538E4DAAA0B493EBCA4A7503F03196@xmb-rcd-x11.cisco.com> To: "Kalyani Garigipati (kagarigi)" MIME-Version: 1.0 X-KeepSent: 52596691:33B48320-48257A23:000BCDD7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.ruishan@zte.com.cn Date: Wed, 20 Jun 2012 10:14:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-20 10:14:11, Serialize complete at 2012-06-20 10:14:11 Content-Type: multipart/alternative; boundary="=_alternative 000C496D48257A23_=" X-MAIL: mse02.zte.com.cn q5K2EAvp016620 Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 02:14:26 -0000 This is a multipart message in MIME format. --=_alternative 000C496D48257A23_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgS2FseWFuaSwNCg0KDQoNCkZpcnN0IEknZCBsaWtlIHRvIG1ha2Ugc29tZSBjbGFyaWZpY2F0 aW9ucyBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cywgYW5kIA0KbGVhdmUgb3RoZXIgY2xhcmlm aWNhdGlvbnMgdG8gZnVydGhlciBkaXNjdXNzaW9ucy4NCg0KMS4gQ2xhcmlmaWNhdGlvbiBmb3Ig Y2FzZSBDIGluIFNlY3Rpb24gMi4yDQooY2FzZSBDIGlzIHRoZSBtb3N0IHRyb3VibGVzb21lIGlu IHRoaXMgc2VjdGlvbiBJTU8uU28gSSdkIGxpa2UgdG8gY2xhcmlmeSANCml0LikNCjEuMSBOb3Rh dGlvbiBmb3IgY2FzZSBDIGluIFNlY3Rpb24gMi4yDQoNCng6IHRoZSBtYXhpbXVtIG1lc3NhZ2Ug SUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBwYXJ0eQ0KeTogdGhlIG5leHQgc2VuZGVyIG1lc3Nh Z2UgSUQNCg0KYTA6IHRoZSBvbGQgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyDQphMTogdGhlIG5ldyBh Y3RpdmUgY2x1c3RlciBtZW1iZXINCmI6ICB0aGUgcGVlcg0KDQoNCmEwW3RdLnggIGEwJ3MgbWF4 aW11bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiB1bnRpbCB0aW1lIHQNCmEw W3RdLnkgIGEwJ3MgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRCAgYXQgdGltZSB0DQoNCmExW3RdLngg IGExJ3MgbWF4aW11bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiAgdW50aWwg dGltZSB0IA0KYTFbdF0ueSAgYTEncyBuZXh0IHNlbmRlciBtZXNzYWdlIElEICBhdCB0aW1lIHQN Cg0KYlt0XS54ICAgYidzIG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9tIHRoZSBjbHVz dGVyICB1bnRpbCB0aW1lIHQgDQpiW3RdLnkgICBiJ3MgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRCBh dCB0aW1lIHQNCg0KDQpUMDogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgbGFzdCBzeW5jaHJvbml6 YXRpb24gYmV0d2VlbiBhMCBhbmQgYTEgaXMgDQpjYXJyaWVkIG91dA0KDQpUMTogQXQgdGhpcyB0 aW1lIHBvaW50LCB0aGUgZmFpbG92ZXIgZXZlbnQgb2NjdXJzDQoNClQyOiBBdCB0aGlzIHRpbWUg cG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiIA0K c3RhcnRzDQoNCg0KVDM6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIE1lc3NhZ2UgSUQgc3luY2hy b25pemF0aW9uIGJldHdlZW4gYTEgYW5kIGIgDQplbmRzDQoNClNXOiB0aGUgc2VuZGVyIHdpbmRv dyBzaXplIG9mIHRoZSBjbHVzdGVyLiBMZXQncyBhc3N1bWUgU1cgaXMgNS4gDQoNCi0tLS1UMC0t LS0tLS0tVDEtLS0tLS0tLS0tVDItLS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCjEuMiBBbmFseXNpcyBmb3IgY2FzZSBDIGluIFNlY3Rpb24gMi4yDQoN Cg0KV2Uga25vdyB0aGF0OiANCg0KYTFbVDBdLnggPT0gYTBbVDBdLngNCmExW1QwXS55ID09IGEw W1QwXS55DQooVGhlIHJlYW9uIGlzIHRoYXQgYXQgVDAsIHRoZSBzeW5jaHJvbml6YXRpb24gYmV0 d2VlbiBhMCBhbmQgYTEgaXMgY2FycmllZCANCm91dC4pDQoNCkFuZA0KDQoNCmExW1QxXS54ID09 IGEwW1QwXS54IA0KYTFbVDFdLnkgPT0gYTBbVDBdLnkNCg0KQW5kDQoNCmExW1QyXS54ID09IGEw W1QwXS54IA0KYTFbVDJdLnkgPT0gYTBbVDBdLnkNCg0KKFRoZSByZWFvbiBpcyB0aGF0IGZyb20g VDAgdG8gVDIsIHRoZSBzdGF0ZSBkYXRhIG9mIGExIGtlZXBzIHVuY2hhbmdlZC4pDQoNCkFjY29y ZGluZyB0byBSRkMgNjMxMSwgDQoNCiJNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNzYWdlIElE IHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gIE0xDQpNVVNUIGJlIGNob3NlbiBzbyB0aGF0IGl0 IGlzIGxhcmdlciB0aGFuIGFueSB2YWx1ZSBrbm93biB0byBoYXZlDQpiZWVuIHVzZWQuICBJdCBp cyBSRUNPTU1FTkRFRCB0byBpbmNyZW1lbnQgdGhlIGtub3duIHZhbHVlIGF0DQpsZWFzdCBieSB0 aGUgc2l6ZSBvZiB0aGUgSUtFIHNlbmRlciB3aW5kb3cuIg0KDQpBdCBUMiwgdGhlIG5ldyBhY3Rp dmUgbWVtYmVyIGExIGNhbiBzZXQgTTE9YTFbVDJdLnkgKyBTVy4gDQoNCg0KQW5kIA0KDQoiTTIg TVVTVCBiZSBhdCBsZWFzdCB0aGUgaGlnaGVyIG9mIHRoZSByZWNlaXZlZCBNMSwgYW5kIG9uZSBt b3JlDQogICAgICB0aGFuIHRoZSBoaWdoZXN0IHNlbmRlciB2YWx1ZSByZWNlaXZlZCBmcm9tIHRo ZSBjbHVzdGVyLiAgVGhpcw0KICAgICAgaW5jbHVkZXMgYW55IHByZXZpb3VzIHJlY2VpdmVkIHN5 bmNocm9uaXphdGlvbiBtZXNzYWdlcy4iDQogDQpBdCBUMiwgdGhlIHBlZXIgYiBjYW4gc2V0IE0y ID0gbWF4KE0xLCAxICsgYltUMl0ueCkuDQoNCk0xPT1hMVtUMl0ueSArIFNXID0+IE0xID09IGEw W1QwXS55ICsgU1cgID0+IE0xID09IGEwW1QwXS55ICsgNQ0KDQpTdXBwb3NlIHNvbWUgbWVzc2Fn ZSBleGNoYW5nZXMgKGkuZS4sIDEwIG1lc3NhZ2VzKSBoYXZlIGJlZW4gY2FycmllZCBvdXQgDQpm cm9tIFQwIHRvIFQyLCBpdCdzIHBvc3NpYmxlIHRoYXQgYltUMl0ueCArIDEgPiBhMFtUMF0ueSAr IDUuIA0KDQpUaGVuIHRoZSBwZWVyIGIgc2V0cyBNMj0xICsgYltUMl0ueC4NCg0KQXQgVDMsIHdo ZW4gdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHJlY2VpdmVzIHRoZSBNZXNzYWdlIElEIA0Kc3lu Y2hyb25pemF0aW9uIHJlc3BvbnNlIGZyb20gdGhlIHBlZXIgYiwgYTEgIHNldHMgYTFbVDNdLnkg PSBNMi4NCg0KYTFbVDNdLnkgPT0gTTIgPT4gYTFbVDNdLnkgPT0xICsgYltUMl0ueC4NCg0KDQpB dCBUMiwgYTBbVDJdLnkgY291bGQgYmUgYltUMl0ueCs1LiANCihUaGUgcmVhb24gaXMgdGhhdCBh MCdzIHNlbnQgbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBiW1QyXS54KzEsIA0KYltUMl0ueCsy LGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1IG1heSBOT1QgaGF2ZSByZWFjaGVkIHRvIHRo ZSBwZWVyIA0KYi4pIA0KDQpUaGlzIG1lYW5zIGExW1QzXS55IDwgYTBbVDJdLnkuDQoNClRoaXMg bWVhbnMgdGhlIGZpcnN0IGZpdmUgbWVzc2FnZXMgc2VudCBieSB0aGUgbmV3IGFjdGl2ZSBtZW1i ZXIgYTEgd2lsbCANCmhhdmUgTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0u eCszLGJbVDJdLngrNCxiW1QyXS54KzUuIA0KDQpTdXBwb3NlIGFmdGVyIFQzLCB0aGUgcGVlciBy ZWNlaXZlcyB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAncyBzZW50IA0KbWVzc2FnZXMgd2l0aCBN ZXNzYWdlIElEcyBiW1QyXS54KzEsIA0KYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltU Ml0ueCs1LCBhbmQgc2VuZHMgcmVzcG9uc2UgbWVzc2FnZXMuDQoNCkFmdGVyIHRoYXQsIHRoZSBu ZXcgYWN0aXZlIG1lbWJlciBhMSBzZW5kcyB0aGUgZmlyc3QgZml2ZSByZXF1ZXN0IG1lc3NhZ2Vz IA0Kd2l0aCBNZXNzYWdlIElEcyBiW1QyXS54KzEsIGJbVDJdLngrMixiW1QyXS54KzMsYltUMl0u eCs0LGJbVDJdLngrNS4NCkFmdGVyIHJlY2V2aW5nIHRoZXNlIHJlcXVlc3QgbWVzc2FnZXMsIHRo ZSBwZWVyIGIgd2lsbCByZWdhcmRzIHRoZXNlIA0KcmVxdWVzdHMgYXMgcmVzZW50IG1lc3NhZ2Vz LCBhbmQgcmV0dXJucyByZXNwb25zZSBtZXNzYWdlcyBmb3IgDQpyZXF1ZXN0cyBvZiAgYTAncyBz ZW50IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCANCmJbVDJdLngrMixiW1Qy XS54KzMsYltUMl0ueCs0LGJbVDJdLngrNSB0byBhMS4NCihNeSB1bmRlcnN0YW5kaW5nLCBhY2Nv cmRpbmcgdG8gUkZDIDU5OTYsIGlzIHRoYXQgdGhlIHBlZXIgc2hvdWxkIHRyZWF0IA0KdGhlIG5l dyBhY3RpdmUgbWVtYmVyJ3MgcmVxdWVzdCBtZXNzYWdlcyBhcyByZXNlbnQgcmVxZXVzdHMuICkN CiAgICAgICAgICAgICAgIHJlLXNlbnQgDQpBcyBhIHJlc3VsdCwgdGhlIHBlZXIgYiByZWNlaXZl cyBhY2NlcHRhYmxlIGJ1dCBtaXNtYXRjaGVkIHJlc3BvbnNlcyBmb3IgDQppdHMgcmVxdWVzdCBt ZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIGExW1QyXS54KzEsIA0KYTFbVDJdLngrMixhMVtUMl0u eCszLGExW1QyXS54KzQsYTFbVDJdLngrNS4NCiANCkZvciBhIGNvbmNyZXRlIGV4YW1wbGUsIGxl dCdzIGFzc3VtZTogDQoNCmExW1QwXS54ID09IGEwW1QwXS54ID0gOQ0KYTFbVDBdLnkgPT0gYTBb VDBdLnkgPSAyMA0KDQpiW1QwXS54ID0gMTkNCmJbVE9dLnkgPSAxMA0KDQpGcm9tIFQwIHRvIFQx LCB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAgaGF2ZSBzZW50IDEwIHJlcXVlc3QgbWVzc2FnZXMg dG8gDQp0aGUgcGVlciBiLCBhbmQgNSBtZXNzYWdlcyBoYXZlIGJlZW4gcmVjZWl2ZWQgYW5kIGFj a25vd2xlZGdlZCBieSB0aGUgcGVlciANCmIuIA0KDQpUaGlzIG1lYW5zIHRoYXQgYTBbVDJdLnkg PSAzMCwgYltUMl0ueCA9IDI0LiBOb3RlIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCANCk1lc3NhZ2Ug SUQgMjUsMjYsMjcsMjgsMjkgaGF2ZSBiZWVuIHNlbnQgYnkgdGhlIG9sZCBhY3RpdmUgbWVtYmVy IGEwLCBidXQgDQpoYXZlIE5PVCByZWFjaGVkIHRoZSBwZWVyIGIwLiAoVGhlIHNlbmRlciB3aW5k b3cgc2l6ZSBvZiB0aGUgY2x1c3RlciBpcyANCjUuKQ0KDQoNCkFjY29yZGluZyB0byBSRkMgNjMx MSwgDQoNCiJNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNzYWdlIElEIHRvIGJlIHVzZWQgYnkg dGhlIG1lbWJlci4gIE0xDQpNVVNUIGJlIGNob3NlbiBzbyB0aGF0IGl0IGlzIGxhcmdlciB0aGFu IGFueSB2YWx1ZSBrbm93biB0byBoYXZlDQpiZWVuIHVzZWQuICBJdCBpcyBSRUNPTU1FTkRFRCB0 byBpbmNyZW1lbnQgdGhlIGtub3duIHZhbHVlIGF0DQpsZWFzdCBieSB0aGUgc2l6ZSBvZiB0aGUg SUtFIHNlbmRlciB3aW5kb3cuIg0KDQoNCk0xID09IGExW1QyXS55ICsgU1cgPT0gMjAgKyA1ID09 IDI1DQooYTFbVDJdLnkgPT0gYTFbVDBdLnkgPT0gMjApDQoNCkFuZCANCiJNMiBNVVNUIGJlIGF0 IGxlYXN0IHRoZSBoaWdoZXIgb2YgdGhlIHJlY2VpdmVkIE0xLCBhbmQgb25lIG1vcmUNCnRoYW4g dGhlIGhpZ2hlc3Qgc2VuZGVyIHZhbHVlIHJlY2VpdmVkIGZyb20gdGhlIGNsdXN0ZXIuICBUaGlz DQppbmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2Vz LiINCiANCk0yID09IG1heHtNMSwgMSArIGJbVDJdLngpPT0gbWF4KDI1LDErMjQpID09IDI1DQoN CkFmdGVyIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSByZWNlaXZlcyBNMiwgYTEgc2V0cyBhMVtU Ml0ueSA9PSAyNSA8IA0KYTBbVDJdLnkgPT0gMzAuDQoNClRoZSBNZXNzYWdlIElEIGZvciB0aGUg bmV3IGFjdGl2ZSBtZW1iZXIgYTEgbnVtYmVycyBmcm9tIDI1Lg0KDQpUaGUgZmlyc3QgZml2ZSBN ZXNzYWdlIElEcyBhcmUgMjUsIDI2LCAyNywyOCwyOS4NCg0KV2hlbiB0aGUgbmV3IGFjdGl2ZSBt ZW1iZXIgYTEgc2VuZHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2VzIElEcyAyNSwgDQoy NiwyNywyOCwyOSwgc2luY2UgdGhlIHBlZXIgYiBoYXMgcHJvY2Vzc2VkIHRoZSByZXF1ZXN0IG1l c3NhZ2Ugd2l0aCB0aGUgDQpzYW1lIE1lc3NhZ2UgSURzLCB0aGUgcGVlciBiIHdpbGwgcmV0dXJu IHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVxdWVzdCANCm1lc3NhZ2VzIGZyb20gdGhlIG9s ZCBhY3RpdmUgbWVtYmVyIGEwLg0KDQpUaGVuIGExIHJlY2VpdmVzIGFjY2VwdGFibGUgYnV0IG1p c21hY3RoZWQgcmVzcG9uc2UgbWVzc2FnZXMuDQoNCiANCjIuIENsYXJpZmljYXRpb25zIGZvciB0 aGUgc2ltdWx0YW5lc291cyBmYWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjMgDQpGb3IgdGhl IHNpbXVsdGFuZW91cyBmYWlsb3ZlciwgY2FzZSBGIGlzIHRoZSBtb3N0IGRldmFzdGF0aW5nIElN Ty4gU28gSSdkIA0KbGlrZSB0byBjbGFyaWZ5IGl0IGZpcnN0Lg0KMi4xIE5vdGF0aW9uIGZvciB0 aGUgc2ltdWx0YW5lc291cyBmYWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjMNCg0KDQphMDog dGhlIG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYQ0KYTE6IHRoZSBu ZXcgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGENCmIwOiB0aGUgb2xkIGFj dGl2ZSBjbHVzdGVyIG1lbWJlciBvZiB0aGUgY2x1c3RlciBiDQpiMTogdGhlIG5ldyBhY3RpdmUg Y2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYg0KDQoNClQwOiBBdCB0aGlzIHRpbWUgcG9p bnQsIHRoZSBsYXN0IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGEwL2IwIGFuZCBhMS9iMSANCmlz IGNhcnJpZWQgb3V0LCANCg0KVDE6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIHNpbXVsdGFuZW91 cyBmYWlsb3ZlciBldmVudCBvY2N1cnMNCg0KVDI6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIE1l c3NhZ2UgSUQgc3luY2hyb25pemF0aW9uIGJldHdlZW4gYTEgYW5kIGIxIA0Kc3RhcnRzDQoNCg0K VDM6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIE1lc3NhZ2UgSUQgc3luY2hyb25pemF0aW9uIGJl dHdlZW4gYTEgYW5kIGIxIA0KZW5kcw0KDQoNCg0KLS0tLVQwLS0tLS0tLS1UMS0tLS0tLS0tLS1U Mi0tLS0tLS0tLS1UMy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiANCjIu MiBBbmFseXNpcyBmb3IgdGhlIHNpbXVsdGFuZXNvdXMgZmFpbG92ZXIgY2FzZSBGIGluIFNlY3Rp b24gMi4zDQoNCg0KSXQncyBwb3NzaWJsZSB0aGF0IGZyb20gVDAgdG8gVDEsIGEwIGFuZCBiMCBk ZWxldGVzIHRoZSBvbGQgSUtFIFNBIHNhMCBhbmQgDQpjcmVhdGVzIGEgbmV3IElLRSBTQSBzYTEu DQpCdXQgYXQgVDIsIGExIGFuZCBiMSBkbyBOT1Qga25vdyB3aGF0IGhhcyBoYXBwZW5lZCBmcm9t IFQwIGFuZCBUMSwgYW5kIGRvIA0KTk9UIGtub3cgdGhlIGV4aXN0YW5jZSBvZiB0aGUgbmV3IElL RSBTQSBzYTEsIGFuZCB1c2UgdGhlIG9sZCBJS0UgU0Egc2EwIA0KdG8gY2Fycnkgb3V0IE1lc3Nh Z2UgSUQgc3luY2hyb25pemF0aW9uLg0KVGhpcyBtYXkgYnJpbmcgc29tZSBtb3JlIHNlcmlvdXNl IHByb2JsZW0uIFNvICB3aGVuIHNpbXVsdGFuZW91cyBmYWlsb3ZlciANCm9jY3VycywgYSBzaW1w bGUgdHdvLXdheSBzeW5jaHJvbml6YXRpb24gIG1heSBub3QgYmUgYW4gYXBwcm9wcmlhdGUgDQpz b2x1dGlvbi4NCg0KDQoNCg0KDQoNCg0KIkthbHlhbmkgR2FyaWdpcGF0aSAoa2FnYXJpZ2kpIiA8 a2FnYXJpZ2lAY2lzY28uY29tPiANCreivP7IyzogIGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcNCjIw MTItMDYtMTQgMTk6MTQNCg0KytW8/sjLDQoiemhhbmcucnVpc2hhbkB6dGUuY29tLmNuIiA8emhh bmcucnVpc2hhbkB6dGUuY29tLmNuPiwgImlwc2VjQGlldGYub3JnIiANCjxpcHNlY0BpZXRmLm9y Zz4NCrOty80NCg0K1vfM4g0KUmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5z aW9uIGZvciBJS0V2Mi9JUHNlYyAgICAgIEhpZ2ggDQpBdmFpbGFibGl0eQ0KDQoNCg0KDQoNCg0K SGkgWmhhbmcsDQogDQpUaGFua3MgZm9yIGdvaW5nIHRocm91Z2ggdGhlIFJGQyA2MzExIC4NCiAN CkkgaGF2ZSBnb25lIHRocm91Z2ggeW91ciAgcHJvcG9zZWQgZHJhZnQgYW5kIGZlbHQgdGhhdCB0 aGVyZSBpcyBzb21lIA0KY29uZnVzaW9uIHJlZ2FyZGluZyB0aGUgbWVzc2FnZSBpZCBjb25jZXB0 IG9mIGlrZXYyLg0KIA0KSSBoYXZlIHNlZW4gdGhhdCBpbiBzZWN0aW9uIDIuMyB5b3Ugd2VyZSBj b21wYXJpbmcgdGhlIGhpZ2VyIHNlbmRlciB2YWx1ZSANCm9mIHgyIHdpdGggeTIuDQpUaGF0IGlz IHdyb25nLiB3aGVuIHgyIHByb3Bvc2VzIHRoZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlkIHRvIGJl IHVzZWQgdG8gDQpzZW5kIGEgcmVxdWVzdCAsDQp0aGVuIG9uIHkyIHlvdSBzaGxkIHRhbGx5IGl0 IHdpdGggdGhlIG5leHQgaGlnaGVyIG1lc3NhZ2UgaWQgb2YgdGhlIA0KcmVxdWVzdCB0byBiZSBy ZWNpZXZlZCANCiAgICAgICAgICAgIChhbmQgbm90IHdpdGggdGhlIG5leHQgaGlnaGVyIG1lc3Nh Z2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgDQpzZW50KQ0KIA0KaW4gaWtldjIgdGhlICBtZXNz YWdlIGlkIG9mIHJlcXVlc3RzIHRvIGJlIHNlbnQgYXJlIGVudGlyZWx5IGRpZmZlcmVudCANCmZy b20gbWVzc2FnZSBpZCBvZiByZXF1ZXN0cyB0byBiZSByZWNlaXZlZC4NCnRoYXQgaXMgd2h5IFJG QyBzYXlzIGEgbWVzc2FnZSBpZCBpcyB1c2VkIGZvdXIgdGltZXMgb24gYSBnaXZlbiBkZXZpY2Uu IA0KIA0KMS4gbWVzc2FnZSBpZCBYIGlzIHVzZWQgd2hpbGUgc2VuZGluZyBhIHJlcXVlc3QNCjIu IG1lc3NhZ2UgaWQgWCBpcyB1c2VkIHdoaWxlIHJlY2VpdmluZyB0aGUgcmVzcG9uc2UNCjMuIG1l c3NhZ2UgaWQgWCBpcyB1c2VkIHRvIHJlY2VpdmUgYSByZXF1ZXN0DQo0LiBtZXNzYWdlIGlkIFgg aXMgdXNlZCB0byBzZW5kIGEgcmVzcG9uc2UuDQogDQogDQpwbGVhc2UgZmluZCB0aGUgY29tbWVu dHMgZm9yIGVhY2ggc2VjdGlvbg0KIA0KU2VjdGlvbiAyLjE6ICBUaGlzIGlzIGEga25vd24gaXNz dWUgYW5kIHRoYXQgaXMgd2h5IHVzaW5nIFJGQyA2MzExLCAgd2UgDQphcmUgc3luY2hyb25pc2lu ZyB0aGUgbWVzc2FnZSBpZCdzDQogDQpTZWN0aW9uIDIuMjogVGhlIHBlZXIgaXMgYXNzdW1lZCB0 byBiZSBwcm9wZXIgYW5jaG9yIHBvaW50IHdoaWNoIGhhcyANCmNvcnJlY3QgaW5mbyBvZiBtZXNz YWdlIGlkIG9mIHJlcXVlc3RzIHNlbnQgYW5kIHJlY2lldmVkLA0KZXZlbiB3aGVuIHBlZXIgaXMg Y2x1c3RlciBtZW1iZXIgLCBhbW9uZyB0aGUgdHdvIGRldmljZXMgb25lIG9mIHRoZW0gd291bGQg DQpiZSBsZXNzIHdyb25nIGFuZCBoYXZlIGhpZ2hlciBhY2N1cmF0ZSB2YWx1ZXMgb2YgbWVzc2Fn ZSBpZCdzIC4gDQpzbyB3ZSBwaWNrIHVwIHRoYXQgdmFsdWUuIEkgZG9udCBzZWUgYW55IGlzc3Vl IGhlcmUuDQogDQpTZWN0aW9uIDIuMzogRmlyc3Qgb2YgYWxsIHRoZXJlIGlzIG5vIHJlbGF0aW9u IGJldHdlZW4gTTEgYW5kIFAxLg0Kb24gYSBnaXZlbiBkZXZpY2UuDQotLS0gTTEgaXMgdGhlIHBy b3Bvc2VkIG1lc3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgc2VudA0KICAgIFAxIGlzIHRo ZSBwcm9wb3NlZCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHJlY2VpdmVkLg0KIA0K d2hlbiBzaW11bGF0ZW5vdXMgZmFpbG92ZXIgaGFwcGVucywgeDIgbWlnaHQgaGF2ZSBoaWdoZXIg dmFsdWUgb2YgTTEgd2hlbiANCmNvbXBhcmVkIHRvIHkyICwgYnV0IHgyIG1pZ2h0IGhhdmUgbG93 ZXIgdmFsdWUgb2YgUDEgd2hlbiBjb21wYXJlZCB0byB5Mi4NCkl0IGRvZXMnbnQgbWF0dGVyLiBi b3RoIGFyZSBpbmRlcGVuZGVudC4gd2hhdCB3ZSBldmVudHVhbGx5IGRvIGlzIGNvbXBhcmUgDQp0 aGUgTTEgdmFsdWUgYWNyb3NzIHgyIGFuZCB5MiBhbmQgcGljayB0aGUgaGlnZXIgb25lLg0Kc2Ft ZSBwcm9jZXNzIGlzIHJlcGVhdGVkIGZvciBQMS4NCiANCmNhc2UgMSB0byA2IGFyZSBhbHJlYWR5 IGhhbmRsZWQgYnkgYmFzaWMgaWtldjIgUkZDIC4gbGlrZSBpZiB3ZSByZWNlaXZlIA0Kc2FtZSBt ZXNzYWdlIGlkIHR3aWNlICwgdGhlbiB3ZSByZXRyYW5zbWl0IG9yIGRyb3AgaXQgaWYgaXQgaXMg b3V0c2lkZSB0aGUgDQp3aW5kb3cuDQogDQogDQpTZWN0aW9uIDM6ICAgZHVyaW5nIHNpbXVsdGFu ZW91cyBmYWlsb3ZlciBib3RoIHRoZSBjbHVzdGVyIGFuZCB0aGUgcGVlciANCm1lbWJlciB3b3Vs ZCBiZSBpbiB1bnJlbGlhYmxlIHN0YXRlLg0KQm90aCBvZiB0aGVtIGFyZSB3cm9uZyAsIGJ1dCBv bmUgb2YgdGhlbSBpcyBsZXNzIHdyb25nICEhISBzbyB3ZSB3YW50IHRvIA0Kc3RhcnQgZnJvbSB0 aGF0IHBvaW50IHRvIHN5bmNocm9uaXNlIHRoZSBtZXNzYWdlIGlkJ3MuDQogDQpzbyB3ZSBhcmUg YWxsb3dpbmcgYm90aCB0aGUgbWVtYmVycyB0byBhbm5vdW5jZSB0aGVpciBtZXNzYWdlIGlkJ3Mg YW5kIA0KdGhlbiBldmVudHVhbGx5IHdlIHdvdWxkIHN5bmNocm9uaXNlIHRvIHRoZSBoaWdoZXIg bnVtYmVyLg0KSSBkb250IHNlZSBhbnkgZmxhdyBoZXJlLiBQbGVhc2UgZXhwbGFpbiB3aXRoIGFu IGV4YW1wbGUuDQogDQpCeSB5b3VyIHByb3Bvc2FsIGluIGNhc2Ugb2Ygc2ltdWx0YW5lb3VzIGZh aWxvdmVyLCBib3RoIHRoZSBjbHVzdGVyIGFuZCANCnBlZXIgd2lsbCBiZSBpbiBVTlNZTkVEIHN0 YXRlIGFuZCANCmJvdGggd291bGQgZW5kIHVwIHNlbmRpbmcgYW5kIHJlamVjdGluZyB0aGUgc3lu Y2hyb25pc2F0aW9uIHJlcXVlc3QuIA0KVGhpcyB3b3VsZCBsZWFkIHRvIHJlcGVhdGVkIHN5bmNo cm9uaXNhdGlvbiBlZmZvcnRzIGFuZCB0aGUgcHJvYmxlbSBvZiANCm1lc3NhZ2Ugc3luY2hyb25p c2F0aW9uIGlzIG5ldmVyIHNvbHZlZC4NCiANCnNvIFVOU1lORUQgc3RhdGUgaXMgbm90IHJlcXVp cmVkLg0KIA0KU2VjdGlvbiA0OiANCiANCkkgZmVlbCB0aGF0IFJGQyA2MzExIGFscmVhZHkgc29s dmVzIHRoZSBtZXNzYWdlIGlkIHN5bmNocm9uaXNhdGlvbiBpc3N1ZS4gDQpJIGRvbnQgdGhpbmsg d2UgbmVlZCB0byBpbmNyZW1lbnQgTTEgYnkgZG91YmxlIHRoZSB3aW5kb3cgc2l6ZSBhcyBwcm9w b3NlZCANCmJ5IHlvdS4gDQpQbGVhc2Ugc3VwcG9ydCB5b3VyIHByb3Bvc2FsIHdpdGggYW4gZXhh bXBsZSB3aXRoIG1lc3NhZ2UgaWQgdmFsdWVzIG9mIA0KbnVtYmVycyBpbnN0ZWFkIG9mIHZhcmlh Ymxlcy4NCkxpa2UgTTEgaXMgMyAsIE0yIGlzIDQgZXRjIGV0Yy4NCiANCk51bWJlcnMgbWFrZSBp dCBtb3JlIGNsZWFyLg0KIA0KcmVnYXJkcywNCmthbHlhbmkNCiANCkZyb206IGlwc2VjLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg DQp6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24NClNlbnQ6IE1vbmRheSwgSnVuZSAxMSwgMjAxMiA3 OjM2IEFNDQpUbzogaXBzZWNAaWV0Zi5vcmcNClN1YmplY3Q6IFtJUHNlY10gVXBkYXRlcyB0byB0 aGUgSUtFdjIgRXh0ZW5zaW9uIGZvciBJS0V2Mi9JUHNlYyBIaWdoIA0KQXZhaWxhYmxpdHkNCiAN Cg0KDQpEZWFyIEFsbCwgDQoNCiAgSSd2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgIiBVcGRhdGVz IHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIA0KSUtFdjIvSVBzZWMgSGlnaCBBdmFpbGFibGl0 eSIuIFRoaXMgZHJhZnQgYW5hbHl6ZXMgc29tZSBpc3N1ZXMgaW4gUkZDIA0KNjMxMSwgDQphbmQg cHJvcG9zZXMgc29tZSB1cGRhdGVzLiBMb29rIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4gDQoN Cg0KQlIsIA0KDQpSdWlzaGFuIFpoYW5nX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQo= --=_alternative 000C496D48257A23_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEthbHlhbmksPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GaXJz dCBJJ2QgbGlrZSB0byBtYWtlIHNvbWUgY2xhcmlmaWNhdGlvbnMNCmFjY29yZGluZyB0byB5b3Vy IGNvbW1lbnRzLCBhbmQgbGVhdmUgb3RoZXIgY2xhcmlmaWNhdGlvbnMgdG8gZnVydGhlciBkaXNj dXNzaW9ucy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+MS4gQ2xhcmlmaWNhdGlvbiBmb3IgY2FzZQ0KQyBpbiBTZWN0aW9uIDIuMjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KGNhc2UgQyBpcyB0aGUg bW9zdCB0cm91Ymxlc29tZSBpbiB0aGlzDQpzZWN0aW9uIElNTy5TbyBJJ2QgbGlrZSB0byBjbGFy aWZ5IGl0Lik8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEuMSBO b3RhdGlvbiBmb3IgY2FzZSBDIGluIFNlY3Rpb24gMi4yPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj54OiB0aGUgbWF4aW11bSBtZXNzYWdlIElEIHJlY2Vp dmVkIGZyb20NCnRoZSBwZWVyIHBhcnR5PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj55OiB0aGUgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YTA6IHRoZSBvbGQgYWN0aXZlIGNsdXN0 ZXIgbWVtYmVyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMTog dGhlIG5ldyBhY3RpdmUgY2x1c3RlciBtZW1iZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmI6ICZuYnNwO3RoZSBwZWVyPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMFt0XS54ICZuYnNwO2EwJ3MgbWF4aW11 bSBtZXNzYWdlIElEDQpyZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgdW50aWwgdGltZSB0PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMFt0XS55ICZuYnNwO2EwJ3Mg bmV4dCBzZW5kZXIgbWVzc2FnZQ0KSUQgJm5ic3A7YXQgdGltZSB0PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMVt0XS54ICZuYnNwO2ExJ3MgbWF4aW11 bSBtZXNzYWdlIElEDQpyZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgJm5ic3A7dW50aWwgdGltZSB0 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YTFbdF0ueSAmbmJz cDthMSdzIG5leHQgc2VuZGVyIG1lc3NhZ2UNCklEICZuYnNwO2F0IHRpbWUgdDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Ylt0XS54ICZuYnNwOyBiJ3Mg bWF4aW11bSBtZXNzYWdlIElEDQpyZWNlaXZlZCBmcm9tIHRoZSBjbHVzdGVyICZuYnNwO3VudGls IHRpbWUgdCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJbdF0u eSAmbmJzcDsgYidzIG5leHQgc2VuZGVyIG1lc3NhZ2UNCklEIGF0IHRpbWUgdDwvZm9udD4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VDA6IEF0IHRoaXMg dGltZSBwb2ludCwgdGhlIGxhc3Qgc3luY2hyb25pemF0aW9uDQpiZXR3ZWVuIGEwIGFuZCBhMSBp cyBjYXJyaWVkIG91dDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+VDE6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIGZhaWxvdmVyDQpldmVudCBvY2N1cnM8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlQyOiBBdCB0 aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNzYWdlDQpJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBh MSBhbmQgYiBzdGFydHM8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlQzOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNzYWdlDQpJRCBzeW5j aHJvbml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYiBlbmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TVzogdGhlIHNlbmRlciB3aW5kb3cgc2l6ZSBvZiB0 aGUgY2x1c3Rlci4NCkxldCdzIGFzc3VtZSBTVyBpcyA1LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi0tLS1UMC0tLS0tLS0tVDEtLS0tLS0tLS0tVDIt LS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjEuMiBB bmFseXNpcyBmb3IgY2FzZSBDIGluDQpTZWN0aW9uIDIuMjwvZm9udD4NCjxicj4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2Uga25vdyB0aGF0OiA8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmExW1QwXS54ID09IGEwW1Qw XS54PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMVtUMF0ueSA9 PSBhMFtUMF0ueTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KFRo ZSByZWFvbiBpcyB0aGF0IGF0IFQwLCB0aGUgc3luY2hyb25pemF0aW9uDQpiZXR3ZWVuIGEwIGFu ZCBhMSBpcyBjYXJyaWVkIG91dC4pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5BbmQ8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmExW1QxXS54ID09IGEwW1QwXS54IDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YTFbVDFdLnkgPT0gYTBbVDBdLnk8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YTFbVDJdLnggPT0gYTBbVDBdLnggPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMVtUMl0ueSA9PSBhMFtU MF0ueTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KFRo ZSByZWFvbiBpcyB0aGF0IGZyb20gVDAgdG8gVDIsIHRoZQ0Kc3RhdGUgZGF0YSBvZiBhMSBrZWVw cyB1bmNoYW5nZWQuKTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QWNjb3JkaW5nIHRvIFJGQyA2MzExLCA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O00xIGlzIHRoZSBuZXh0IHNlbmRlcidzIE1lc3Nh Z2UNCklEIHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gJm5ic3A7TTE8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk1VU1QgYmUgY2hvc2VuIHNvIHRoYXQgaXQgaXMg bGFyZ2VyDQp0aGFuIGFueSB2YWx1ZSBrbm93biB0byBoYXZlPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iZWVuIHVzZWQuICZuYnNwO0l0IGlzIFJFQ09NTUVOREVE IHRvDQppbmNyZW1lbnQgdGhlIGtub3duIHZhbHVlIGF0PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5sZWFzdCBieSB0aGUgc2l6ZSBvZiB0aGUgSUtFIHNlbmRlcg0K d2luZG93LiZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QXQgVDIsIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBjYW4NCnNldCBNMT1hMVtUMl0u eSArIFNXLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkFuZCA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90O00yIE1VU1QgYmUgYXQgbGVhc3QgdGhlIGhpZ2hlcg0Kb2YgdGhlIHJlY2VpdmVk IE0xLCBhbmQgb25lIG1vcmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoYW4gdGhlIGhpZ2hlc3QNCnNlbmRlciB2YWx1ZSBy ZWNlaXZlZCBmcm9tIHRoZSBjbHVzdGVyLiAmbmJzcDtUaGlzPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmNsdWRlcyBhbnkg cHJldmlvdXMNCnJlY2VpdmVkIHN5bmNocm9uaXphdGlvbiBtZXNzYWdlcy4mcXVvdDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+QXQgVDIsIHRoZSBwZWVyIGIgY2FuIHNldCBNMiA9IG1heChNMSwNCjEgKyBiW1QyXS54KS48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk0xPT1hMVtU Ml0ueSArIFNXID0mZ3Q7IE0xID09IGEwW1QwXS55DQorIFNXICZuYnNwOz0mZ3Q7IE0xID09IGEw W1QwXS55ICsgNTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+U3VwcG9zZSBzb21lIG1lc3NhZ2UgZXhjaGFuZ2VzIChpLmUuLA0KMTAgbWVzc2FnZXMpIGhh dmUgYmVlbiBjYXJyaWVkIG91dCBmcm9tIFQwIHRvIFQyLCBpdCdzIHBvc3NpYmxlIHRoYXQgYltU Ml0ueA0KKyAxICZndDsgYTBbVDBdLnkgKyA1LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZW4gdGhlIHBlZXIgYiBzZXRzIE0yPTEgKyBiW1QyXS54 LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXQgVDMs IHdoZW4gdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExDQpyZWNlaXZlcyB0aGUgTWVzc2FnZSBJRCBz eW5jaHJvbml6YXRpb24gcmVzcG9uc2UgZnJvbSB0aGUgcGVlciBiLCBhMSAmbmJzcDtzZXRzDQph MVtUM10ueSA9IE0yLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+YTFbVDNdLnkgPT0gTTIgPSZndDsgYTFbVDNdLnkgPT0xICsNCmJbVDJdLnguPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BdCBUMiwg YTBbVDJdLnkgY291bGQgYmUgYltUMl0ueCs1Lg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4oVGhlIHJlYW9uIGlzIHRoYXQgYTAncyBzZW50IG1lc3NhZ2VzDQp3 aXRoIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQs YltUMl0ueCs1IG1heQ0KTk9UIGhhdmUgcmVhY2hlZCB0byB0aGUgcGVlciBiLikgPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIG1lYW5zIGExW1Qz XS55ICZsdDsgYTBbVDJdLnkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGlzIG1lYW5zIHRoZSBmaXJzdCBmaXZlIG1lc3NhZ2VzIHNlbnQNCmJ5IHRo ZSBuZXcgYWN0aXZlIG1lbWJlciBhMSB3aWxsIGhhdmUgTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBi W1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUuDQo8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvc2UgYWZ0ZXIgVDMsIHRoZSBw ZWVyIHJlY2VpdmVzDQp0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAncyBzZW50IG1lc3NhZ2VzIHdp dGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxi W1QyXS54KzUsDQphbmQgc2VuZHMgcmVzcG9uc2UgbWVzc2FnZXMuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BZnRlciB0aGF0LCB0aGUgbmV3IGFjdGl2 ZSBtZW1iZXIgYTENCnNlbmRzIHRoZSBmaXJzdCBmaXZlIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCBN ZXNzYWdlIElEcyBiW1QyXS54KzEsIGJbVDJdLngrMixiW1QyXS54KzMsYltUMl0ueCs0LGJbVDJd LngrNS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFmdGVyIHJl Y2V2aW5nIHRoZXNlIHJlcXVlc3QgbWVzc2FnZXMsDQp0aGUgcGVlciBiIHdpbGwgcmVnYXJkcyB0 aGVzZSByZXF1ZXN0cyBhcyByZXNlbnQgbWVzc2FnZXMsIGFuZCByZXR1cm5zDQpyZXNwb25zZSBt ZXNzYWdlcyBmb3IgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5y ZXF1ZXN0cyBvZiAmbmJzcDthMCdzIHNlbnQgbWVzc2FnZXMNCndpdGggTWVzc2FnZSBJRHMgYltU Ml0ueCsxLCBiW1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUgdG8NCmExLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KE15IHVuZGVyc3RhbmRp bmcsIGFjY29yZGluZyB0byBSRkMNCjU5OTYsIGlzIHRoYXQgdGhlIHBlZXIgc2hvdWxkIHRyZWF0 IHRoZSBuZXcgYWN0aXZlIG1lbWJlcidzIHJlcXVlc3QgbWVzc2FnZXMNCmFzIHJlc2VudCByZXFl dXN0cy4gKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmUtc2VudCAmbmJzcDsgJm5ic3A7IDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgYSByZXN1bHQsIHRoZSBwZWVy IGIgcmVjZWl2ZXMgYWNjZXB0YWJsZQ0KYnV0IG1pc21hdGNoZWQgcmVzcG9uc2VzIGZvciBpdHMg cmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIGExW1QyXS54KzEsDQphMVtUMl0ueCsy LGExW1QyXS54KzMsYTFbVDJdLngrNCxhMVtUMl0ueCs1LjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZvciBhIGNvbmNyZXRl IGV4YW1wbGUsIGxldCdzIGFzc3VtZToNCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+YTFbVDBdLnggPT0gYTBbVDBdLnggPSA5PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMVtUMF0ueSA9PSBhMFtUMF0ueSA9IDIwPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iW1QwXS54ID0g MTk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJbVE9dLnkgPSAx MDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbSBU MCB0byBUMSwgdGhlIG9sZCBhY3RpdmUgbWVtYmVyDQphMCBoYXZlIHNlbnQgMTAgcmVxdWVzdCBt ZXNzYWdlcyB0byB0aGUgcGVlciBiLCBhbmQgNSBtZXNzYWdlcyBoYXZlIGJlZW4NCnJlY2VpdmVk IGFuZCBhY2tub3dsZWRnZWQgYnkgdGhlIHBlZXIgYi4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIG1lYW5zIHRoYXQgYTBbVDJdLnkgPSAzMCwg YltUMl0ueA0KPSAyNC4gTm90ZSByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRCAyNSwy NiwyNywyOCwyOSBoYXZlIGJlZW4gc2VudA0KYnkgdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwLCBi dXQgaGF2ZSBOT1QgcmVhY2hlZCB0aGUgcGVlciBiMC4gKFRoZSBzZW5kZXINCndpbmRvdyBzaXpl IG9mIHRoZSBjbHVzdGVyIGlzIDUuKTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+QWNjb3JkaW5nIHRvIFJGQyA2MzExLCA8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O00xIGlzIHRoZSBuZXh0 IHNlbmRlcidzIE1lc3NhZ2UNCklEIHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gJm5ic3A7TTE8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk1VU1QgYmUgY2hvc2Vu IHNvIHRoYXQgaXQgaXMgbGFyZ2VyDQp0aGFuIGFueSB2YWx1ZSBrbm93biB0byBoYXZlPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iZWVuIHVzZWQuICZuYnNwO0l0 IGlzIFJFQ09NTUVOREVEIHRvDQppbmNyZW1lbnQgdGhlIGtub3duIHZhbHVlIGF0PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5sZWFzdCBieSB0aGUgc2l6ZSBvZiB0 aGUgSUtFIHNlbmRlcg0Kd2luZG93LiZxdW90OzwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TTEgPT0gYTFbVDJdLnkgKyBTVyA9PSAyMCArIDUg PT0gMjU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPihhMVtUMl0u eSA9PSBhMVtUMF0ueSA9PSAyMCk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkFuZCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90O00yIE1VU1QgYmUgYXQgbGVhc3QgdGhlIGhpZ2hlcg0Kb2YgdGhlIHJlY2VpdmVk IE0xLCBhbmQgb25lIG1vcmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnRoYW4gdGhlIGhpZ2hlc3Qgc2VuZGVyIHZhbHVlIHJlY2VpdmVkDQpmcm9tIHRoZSBjbHVz dGVyLiAmbmJzcDtUaGlzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5pbmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uDQptZXNzYWdl cy4mcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+TTIgPT0gbWF4e00xLCAxICsgYltUMl0ueCk9PSBtYXgoMjUsMSsy NCkNCj09IDI1PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5BZnRlciB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgcmVjZWl2ZXMNCk0yLCBhMSBzZXRzIGEx W1QyXS55ID09IDI1ICZsdDsgYTBbVDJdLnkgPT0gMzAuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgTWVzc2FnZSBJRCBmb3IgdGhlIG5ldyBhY3Rp dmUgbWVtYmVyDQphMSBudW1iZXJzIGZyb20gMjUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgZmlyc3QgZml2ZSBNZXNzYWdlIElEcyBhcmUgMjUs IDI2LA0KMjcsMjgsMjkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5XaGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBzZW5kcw0KcmVxdWVzdCBtZXNz YWdlcyB3aXRoIE1lc3NhZ2VzIElEcyAyNSwgMjYsMjcsMjgsMjksIHNpbmNlIHRoZSBwZWVyIGIg aGFzDQpwcm9jZXNzZWQgdGhlIHJlcXVlc3QgbWVzc2FnZSB3aXRoIHRoZSBzYW1lIE1lc3NhZ2Ug SURzLCB0aGUgcGVlciBiIHdpbGwNCnJldHVybiByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJl cXVlc3QgbWVzc2FnZXMgZnJvbSB0aGUgb2xkIGFjdGl2ZSBtZW1iZXINCmEwLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlbiBhMSByZWNlaXZlcyBh Y2NlcHRhYmxlIGJ1dCBtaXNtYWN0aGVkDQpyZXNwb25zZSBtZXNzYWdlcy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIENs YXJpZmljYXRpb25zIGZvciB0aGUgc2ltdWx0YW5lc291cw0KZmFpbG92ZXIgY2FzZSBGIGluIFNl Y3Rpb24gMi4zIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Rm9y IHRoZSBzaW11bHRhbmVvdXMgZmFpbG92ZXIsIGNhc2UNCkYgaXMgdGhlIG1vc3QgZGV2YXN0YXRp bmcgSU1PLiBTbyBJJ2QgbGlrZSB0byBjbGFyaWZ5IGl0IGZpcnN0LjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4xIE5vdGF0aW9uIGZvciB0aGUgc2ltdWx0YW5l c291cyBmYWlsb3Zlcg0KY2FzZSBGIGluIFNlY3Rpb24gMi4zPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hMDogdGhlIG9sZCBhY3RpdmUgY2x1 c3RlciBtZW1iZXIgb2YNCnRoZSBjbHVzdGVyIGE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPmExOiB0aGUgbmV3IGFjdGl2ZSBjbHVzdGVyIG1lbWJlciBvZg0KdGhl IGNsdXN0ZXIgYTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YjA6 IHRoZSBvbGQgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9mDQp0aGUgY2x1c3RlciBiPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iMTogdGhlIG5ldyBhY3RpdmUgY2x1 c3RlciBtZW1iZXIgb2YNCnRoZSBjbHVzdGVyIGI8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlQwOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBs YXN0IHN5bmNocm9uaXphdGlvbg0KYmV0d2VlbiBhMC9iMCBhbmQgYTEvYjEgaXMgY2FycmllZCBv dXQsIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VDE6 IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIHNpbXVsdGFuZW91cw0KZmFpbG92ZXIgZXZlbnQgb2Nj dXJzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UMjog QXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2FnZQ0KSUQgc3luY2hyb25pemF0aW9uIGJldHdl ZW4gYTEgYW5kIGIxIHN0YXJ0czwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+VDM6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIE1lc3NhZ2UNCklE IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiMSBlbmRzPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tVDAtLS0tLS0t LVQxLS0tLS0tLS0tLVQyLS0tLS0tLS0tLVQzLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4yIEFuYWx5c2lzIGZvciB0aGUgc2ltdWx0YW5lc291 cyBmYWlsb3Zlcg0KY2FzZSBGIGluIFNlY3Rpb24gMi4zPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JdCdzIHBvc3NpYmxlIHRoYXQgZnJvbSBU MCB0byBUMSwgYTANCmFuZCBiMCBkZWxldGVzIHRoZSBvbGQgSUtFIFNBIHNhMCBhbmQgY3JlYXRl cyBhIG5ldyBJS0UgU0Egc2ExLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QnV0IGF0IFQyLCBhMSBhbmQgYjEgZG8gTk9UIGtub3cgd2hhdA0KaGFzIGhhcHBlbmVk IGZyb20gVDAgYW5kIFQxLCBhbmQgZG8gTk9UIGtub3cgdGhlIGV4aXN0YW5jZSBvZiB0aGUgbmV3 IElLRQ0KU0Egc2ExLCBhbmQgdXNlIHRoZSBvbGQgSUtFIFNBIHNhMCB0byBjYXJyeSBvdXQgTWVz c2FnZSBJRCBzeW5jaHJvbml6YXRpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5UaGlzIG1heSBicmluZyBzb21lIG1vcmUgc2VyaW91c2UgcHJvYmxlbS4NClNv ICZuYnNwO3doZW4gc2ltdWx0YW5lb3VzIGZhaWxvdmVyIG9jY3VycywgYSBzaW1wbGUgdHdvLXdh eSBzeW5jaHJvbml6YXRpb24NCiZuYnNwO21heSBub3QgYmUgYW4gYXBwcm9wcmlhdGUgc29sdXRp b24uPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+JnF1b3Q7S2FseWFuaSBHYXJpZ2lwYXRpDQooa2FnYXJpZ2kpJnF1b3Q7ICZsdDtrYWdh cmlnaUBjaXNjby5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPreivP7IyzogJm5ic3A7aXBzZWMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTA2LTE0IDE5OjE0PC9mb250Pg0K PHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3po YW5nLnJ1aXNoYW5AenRlLmNvbS5jbiZxdW90Ow0KJmx0O3poYW5nLnJ1aXNoYW5AenRlLmNvbS5j biZndDssICZxdW90O2lwc2VjQGlldGYub3JnJnF1b3Q7ICZsdDtpcHNlY0BpZXRmLm9yZyZndDs8 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJlOiBbSVBzZWNdIFVwZGF0ZXMgdG8gdGhlIElLRXYyIEV4dGVuc2lvbg0KZm9yIElLRXYyL0lQ c2VjICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hpZ2ggJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwO0F2YWlsYWJsaXR5PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SGkgWmhhbmcsPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5U aGFua3MgZm9yIGdvaW5nIHRocm91Z2gNCnRoZSBSRkMgNjMxMSAuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5JIGhhdmUgZ29uZSB0aHJv dWdoIHlvdXINCiZuYnNwO3Byb3Bvc2VkIGRyYWZ0IGFuZCBmZWx0IHRoYXQgdGhlcmUgaXMgc29t ZSBjb25mdXNpb24gcmVnYXJkaW5nIHRoZQ0KbWVzc2FnZSBpZCBjb25jZXB0IG9mIGlrZXYyLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ SSBoYXZlIHNlZW4gdGhhdCBpbiBzZWN0aW9uDQoyLjMgeW91IHdlcmUgY29tcGFyaW5nIHRoZSBo aWdlciBzZW5kZXIgdmFsdWUgb2YgeDIgd2l0aCB5Mi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+VGhhdCBpcyB3cm9uZy4gd2hlbiB4MiBwcm9w b3Nlcw0KdGhlIG5leHQgaGlnaGVyIG1lc3NhZ2UgaWQgdG8gYmUgdXNlZCB0byBzZW5kIGEgcmVx dWVzdCAsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPnRoZW4gb24geTIgeW91IHNobGQgdGFsbHkNCml0IHdpdGggdGhlIG5leHQgaGlnaGVyIG1l c3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgcmVjaWV2ZWQgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAoYW5kIG5vdCB3aXRoIHRoZSBuZXh0IGhpZ2hlciBtZXNz YWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvDQpiZSBzZW50KTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+aW4gaWtldjIgdGhlICZuYnNwO21l c3NhZ2UNCmlkIG9mIHJlcXVlc3RzIHRvIGJlIHNlbnQgYXJlIGVudGlyZWx5IGRpZmZlcmVudCBm cm9tIG1lc3NhZ2UgaWQgb2YgcmVxdWVzdHMNCnRvIGJlIHJlY2VpdmVkLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj50aGF0IGlzIHdoeSBSRkMg c2F5cyBhIG1lc3NhZ2UNCmlkIGlzIHVzZWQgZm91ciB0aW1lcyBvbiBhIGdpdmVuIGRldmljZS4g PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij4xLiBtZXNzYWdlIGlkIFggaXMgdXNlZCB3aGlsZQ0Kc2VuZGluZyBhIHJlcXVlc3Q8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Mi4gbWVzc2Fn ZSBpZCBYIGlzIHVzZWQgd2hpbGUNCnJlY2VpdmluZyB0aGUgcmVzcG9uc2U8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+My4gbWVzc2FnZSBpZCBY IGlzIHVzZWQgdG8NCnJlY2VpdmUgYSByZXF1ZXN0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjQuIG1lc3NhZ2UgaWQgWCBpcyB1c2VkIHRvDQpz ZW5kIGEgcmVzcG9uc2UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+cGxlYXNlIGZpbmQgdGhlIGNvbW1lbnRzDQpmb3IgZWFjaCBz ZWN0aW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj5TZWN0aW9uIDIuMTogJm5ic3A7VGhpcyBpcw0KYSBrbm93biBpc3N1ZSBhbmQgdGhh dCBpcyB3aHkgdXNpbmcgUkZDIDYzMTEsICZuYnNwO3dlIGFyZSBzeW5jaHJvbmlzaW5nDQp0aGUg bWVzc2FnZSBpZCdzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj5TZWN0aW9uIDIuMjogVGhlIHBlZXIgaXMNCmFzc3VtZWQgdG8gYmUgcHJv cGVyIGFuY2hvciBwb2ludCB3aGljaCBoYXMgY29ycmVjdCBpbmZvIG9mIG1lc3NhZ2UgaWQNCm9m IHJlcXVlc3RzIHNlbnQgYW5kIHJlY2lldmVkLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5ldmVuIHdoZW4gcGVlciBpcyBjbHVzdGVyDQptZW1i ZXIgLCBhbW9uZyB0aGUgdHdvIGRldmljZXMgb25lIG9mIHRoZW0gd291bGQgYmUgbGVzcyB3cm9u ZyBhbmQgaGF2ZQ0KaGlnaGVyIGFjY3VyYXRlIHZhbHVlcyBvZiBtZXNzYWdlIGlkJ3MgLiA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+c28gd2Ug cGljayB1cCB0aGF0IHZhbHVlLg0KSSBkb250IHNlZSBhbnkgaXNzdWUgaGVyZS48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlNlY3Rpb24g Mi4zOiBGaXJzdCBvZiBhbGwNCnRoZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW4gTTEgYW5kIFAx LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5v biBhIGdpdmVuIGRldmljZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0iQ2FsaWJyaSI+LS0tIE0xIGlzIHRoZSBwcm9wb3NlZCBtZXNzYWdlDQppZCBvZiB0aGUg cmVxdWVzdCB0byBiZSBzZW50PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgUDEgaXMgdGhlIHByb3Bvc2VkDQptZXNzYWdl IGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHJlY2VpdmVkLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+d2hlbiBzaW11bGF0ZW5vdXMgZmFp bG92ZXINCmhhcHBlbnMsIHgyIG1pZ2h0IGhhdmUgaGlnaGVyIHZhbHVlIG9mIE0xIHdoZW4gY29t cGFyZWQgdG8geTIgLCBidXQgeDINCm1pZ2h0IGhhdmUgbG93ZXIgdmFsdWUgb2YgUDEgd2hlbiBj b21wYXJlZCB0byB5Mi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iQ2FsaWJyaSI+SXQgZG9lcydudCBtYXR0ZXIuIGJvdGggYXJlDQppbmRlcGVuZGVudC4gd2hh dCB3ZSBldmVudHVhbGx5IGRvIGlzIGNvbXBhcmUgdGhlIE0xIHZhbHVlIGFjcm9zcyB4MiBhbmQN CnkyIGFuZCBwaWNrIHRoZSBoaWdlciBvbmUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPnNhbWUgcHJvY2VzcyBpcyByZXBlYXRlZA0KZm9yIFAx LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+Y2FzZSAxIHRvIDYgYXJlIGFscmVhZHkgaGFuZGxlZA0KYnkgYmFzaWMgaWtldjIgUkZDIC4g bGlrZSBpZiB3ZSByZWNlaXZlIHNhbWUgbWVzc2FnZSBpZCB0d2ljZSAsIHRoZW4gd2UNCnJldHJh bnNtaXQgb3IgZHJvcCBpdCBpZiBpdCBpcyBvdXRzaWRlIHRoZSB3aW5kb3cuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+U2VjdGlv biAzOiAmbmJzcDsgZHVyaW5nDQpzaW11bHRhbmVvdXMgZmFpbG92ZXIgYm90aCB0aGUgY2x1c3Rl ciBhbmQgdGhlIHBlZXIgbWVtYmVyIHdvdWxkIGJlIGluDQp1bnJlbGlhYmxlIHN0YXRlLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5Cb3RoIG9m IHRoZW0gYXJlIHdyb25nICwNCmJ1dCBvbmUgb2YgdGhlbSBpcyBsZXNzIHdyb25nICEhISBzbyB3 ZSB3YW50IHRvIHN0YXJ0IGZyb20gdGhhdCBwb2ludCB0bw0Kc3luY2hyb25pc2UgdGhlIG1lc3Nh Z2UgaWQncy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPnNvIHdlIGFyZSBhbGxvd2luZyBib3RoIHRoZQ0KbWVtYmVycyB0byBhbm5vdW5j ZSB0aGVpciBtZXNzYWdlIGlkJ3MgYW5kIHRoZW4gZXZlbnR1YWxseSB3ZSB3b3VsZCBzeW5jaHJv bmlzZQ0KdG8gdGhlIGhpZ2hlciBudW1iZXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkkgZG9udCBzZWUgYW55IGZsYXcgaGVyZS4NClBsZWFz ZSBleHBsYWluIHdpdGggYW4gZXhhbXBsZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkJ5IHlvdXIgcHJvcG9zYWwgaW4gY2FzZQ0Kb2Yg c2ltdWx0YW5lb3VzIGZhaWxvdmVyLCBib3RoIHRoZSBjbHVzdGVyIGFuZCBwZWVyIHdpbGwgYmUg aW4gVU5TWU5FRA0Kc3RhdGUgYW5kIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj5ib3RoIHdvdWxkIGVuZCB1cCBzZW5kaW5nDQphbmQgcmVqZWN0 aW5nIHRoZSBzeW5jaHJvbmlzYXRpb24gcmVxdWVzdC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoaXMgd291bGQgbGVhZCB0byByZXBlYXRl ZA0Kc3luY2hyb25pc2F0aW9uIGVmZm9ydHMgYW5kIHRoZSBwcm9ibGVtIG9mIG1lc3NhZ2Ugc3lu Y2hyb25pc2F0aW9uIGlzIG5ldmVyDQpzb2x2ZWQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5zbyBVTlNZTkVEIHN0YXRlIGlzIG5vdCBy ZXF1aXJlZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPlNlY3Rpb24gNDogPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0 OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5JIGZlZWwgdGhhdCBSRkMgNjMxMSBhbHJlYWR5DQpzb2x2 ZXMgdGhlIG1lc3NhZ2UgaWQgc3luY2hyb25pc2F0aW9uIGlzc3VlLiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SSBkb250IHRoaW5rIHdlIG5l ZWQgdG8gaW5jcmVtZW50DQpNMSBieSBkb3VibGUgdGhlIHdpbmRvdyBzaXplIGFzIHByb3Bvc2Vk IGJ5IHlvdS4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPlBsZWFzZSBzdXBwb3J0IHlvdXIgcHJvcG9zYWwNCndpdGggYW4gZXhhbXBsZSB3aXRo IG1lc3NhZ2UgaWQgdmFsdWVzIG9mIG51bWJlcnMgaW5zdGVhZCBvZiB2YXJpYWJsZXMuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkxpa2UgTTEg aXMgMyAsIE0yIGlzIDQgZXRjDQpldGMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5OdW1iZXJzIG1ha2UgaXQgbW9yZSBjbGVhci48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPnJl Z2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPmthbHlhbmk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxi PkZyb206PC9iPiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPGI+ PGJyPg0KU2VudDo8L2I+IE1vbmRheSwgSnVuZSAxMSwgMjAxMiA3OjM2IEFNPGI+PGJyPg0KVG86 PC9iPiBpcHNlY0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBbSVBzZWNdIFVwZGF0ZXMg dG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMgSGlnaA0KQXZhaWxhYmxpdHk8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KRGVhciBBbGws PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7SSd2ZSBzdWJtaXR0ZWQgYSBu ZXcgZHJhZnQgJnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+DQpV cGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYyL0lQc2VjIEhpZ2ggQXZhaWxh YmxpdHk8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mcXVvdDsuDQpUaGlzIGRyYWZ0 IGFuYWx5emVzIHNvbWUgaXNzdWVzIGluIFJGQyA2MzExLCA8YnI+DQphbmQgcHJvcG9zZXMgc29t ZSB1cGRhdGVzLiBMb29rIGZvcndhcmQgdG8geW91ciBjb21tZW50cy48L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpCUiw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N ClJ1aXNoYW4gWmhhbmc8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4N CklQc2VjQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHNlYzxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 000C496D48257A23_=-- From kagarigi@cisco.com Wed Jun 20 03:26:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A9621F86F2; Wed, 20 Jun 2012 03:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.897 X-Spam-Level: X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[AWL=-2.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn1pZROkw20k; Wed, 20 Jun 2012 03:26:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A1EB921F86EF; Wed, 20 Jun 2012 03:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kagarigi@cisco.com; l=71517; q=dns/txt; s=iport; t=1340187977; x=1341397577; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6UpDEw15Sbfem/XnzeD/U4fqxMFD2gYBbZadgKq9tTU=; b=gVchvbAbAEqzuY9qR58y3qAsYT0KChvgPl9nWgdiytZArEsCBLa6MyTX 4mg4mtrdiEnbDAc8HXC4TC9PHFeJv37MR3Ymb3PljKbu8QsSARDAYL4sV QRnW3HqySuG/HYqkBkwh50QYyUV9A9SOYchGxv6I3apX0g6u7RG1JFmkZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOuj4U+tJV2c/2dsb2JhbABFgkWDEq5ogR+BB4IYAQEBBAEBAQ8BBxM6BwQHEAIBBgIRBAEBCxYBBgUCAiULFAkIAgQOBQgTB4dpC5h9jREIkyqLLoUFNmADo0SBZoJf X-IronPort-AV: E=Sophos;i="4.77,443,1336348800"; d="scan'208,217";a="94140099" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 20 Jun 2012 10:26:16 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5KAQG2N009816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Jun 2012 10:26:16 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.20]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Wed, 20 Jun 2012 05:26:16 -0500 From: "Kalyani Garigipati (kagarigi)" To: "zhang.ruishan@zte.com.cn" Thread-Topic: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity Thread-Index: AQHNTopxQJYxarmHSk2nyPHhkmXS55cC/8Jw Date: Wed, 20 Jun 2012 10:26:16 +0000 Message-ID: <52F04C02CB538E4DAAA0B493EBCA4A7503F049ED@xmb-rcd-x11.cisco.com> References: <52F04C02CB538E4DAAA0B493EBCA4A7503F03196@xmb-rcd-x11.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.237.15] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18982.003 x-tm-as-result: No--52.966100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_52F04C02CB538E4DAAA0B493EBCA4A7503F049EDxmbrcdx11ciscoc_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 10:26:21 -0000 --_000_52F04C02CB538E4DAAA0B493EBCA4A7503F049EDxmbrcdx11ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWmhhbmcsDQoNCkZvciBBbmFseXNpcyAxDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KYTBbdF0ueCAgYTAncyBtYXhpbXVtIG1l c3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBiIHVudGlsIHRpbWUgdA0KYTBbdF0ueSAg YTAncyBuZXh0IHNlbmRlciBtZXNzYWdlIElEICBhdCB0aW1lIHQNCg0KSSB0aGluayB0aGVyZSBp cyBjb25mdXNpb24gYWJvdmUuDQpJIGd1ZXNzIHdoYXQgdSBhY3R1YWxseSB3YW50ZWQgdG8gY29u dmV5IGlzDQoNCmEwW3RdLnggIGEwJ3MgbWF4aW11bSBtZXNzYWdlIElEIG9mIHRoZSByZXF1ZXN0 IHNlbnQgYW5kIG9yZGVybHkgcmVzcG9uc2UgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBiIHVudGls IHRpbWUgdCAsIHNheSBpZiBhIGhhcyByZWNlaXZlZCByZXNwb25zZXMgZm9yIDIgYW5kIDMgYW5k IDUgICwgdGhpcyB2YWx1ZSBpcyAzLiBTbyBub3cgdGhlIHdpbmRvdyB3b3VsZCBiZSA0LTggKGlu Y2x1c2l2ZSkNCmEwW3RdLnkgIGEwJ3MgbmV4dCByZXF1ZXN0IG1lc3NhZ2UgSUQgdG8gYmUgc2Vu dCBhdCB0aW1lIHQgLCB0aGlzIHZhbHVlIGlzIDYgLCBpZiBpdCBoYXMgYWxyZWFkeSBzZW50IHRo ZSByZXF1ZXN0cyAyLDMsNCw1LA0KDQpiW3RdLnggICBiJ3MgbWF4aW11bSBtZXNzYWdlIElEIG9m IHRoZSBvcmRlcmx5IHJlc3BvbnNlIHNlbnQgdG8gY2x1c3RlciAgdW50aWwgdGltZSB0ICwgaWYg aXQgaGFzIHNlbnQgcmVzcG9uc2UgdG8gMiwzIGFuZCA1IGlkIHJlcXVlc3RzICwgaXQgaXMgc3Rp bGwgMy4NCmJbdF0ueSAgIGIncyBuZXh0IG1lc3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUg cmVjZWl2ZWQsIHdoaWNoIGlzIDYNCg0KDQpJIGd1ZXNzIHRoZSBleGFtcGxlIGhhcyB3cm9uZyB2 YWx1ZXMuDQoNCmlmIHdpbmRvdyBzaXplIGlzIDUNCg0KdGhlbg0KDQpGb3IgYSBjb25jcmV0ZSBl eGFtcGxlLCBsZXQncyBhc3N1bWU6DQoNCmExW1QwXS54ID09IGEwW1QwXS54ID0gOSAtLS0tLS0t LS0tLS0tLS1ob3cgY2FuIHggYW5kIHkgdmFyeSBieSAxMCB3aGVuIHRoZSB3aW5kb3cgc2l6ZSBp cyA1ICA/DQphMVtUMF0ueSA9PSBhMFtUMF0ueSA9IDIwDQoNCmJbVDBdLnggPSAxOSAgIC0tIHNh bWUgaXMgdGhlIGNhc2UgaGVyZS4uDQpiW1RPXS55ID0gMTANCg0KUGxlYXNlIGFkanVzdCB0aGVz ZSB2YWx1ZXMgYW5kIHRoZW4gdGhlcmUgd2lsbCBiZSBubyBpc3N1ZXMgYXMgbWVudGlvbmVkIGJ5 IHlvdS4NCg0KYWxzbyBwbGVhc2UgcmVmZXIgdG8gdGhlIHNlY3Rpb24gOC4xIGFuZCA5IG9mIHRo ZSBSRkMgNjMxMSB3aGljaCBzYXlzIHRoYXQgd2hlbiB0aGUgd2luZG93IG1vdmVzIHRvIHRoZSBz eW5jaHJvbmlzZWQgdmFsdWUsDQphbGwgdGhlIG9sZCBwZW5kaW5nIHJlcXVlc3RzIGFuZCB0by1i ZSByZXRyYW5zbWl0dGVkIHJlc3BvbnNlcyBzaG91bGQgYmUgZGVsZXRlZC4gU28gdGhlIGJlbG93 IGlzc3VlIHdpbGwgbm90IGhhcHBlbg0KDQpXaGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBz ZW5kcyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZXMgSURzIDI1LCAyNiwyNywyOCwyOSwg c2luY2UgdGhlIHBlZXIgYiBoYXMgcHJvY2Vzc2VkIHRoZSByZXF1ZXN0IG1lc3NhZ2Ugd2l0aCB0 aGUgc2FtZQ0KTWVzc2FnZSBJRHMsIHRoZSBwZWVyIGIgd2lsbCByZXR1cm4gcmVzcG9uc2UgbWVz c2FnZXMgZm9yIHRoZSByZXF1ZXN0IG1lc3NhZ2VzIGZyb20gdGhlIG9sZCBhY3RpdmUgbWVtYmVy IGEwLg0KDQpUaGVuIGExIHJlY2VpdmVzIGFjY2VwdGFibGUgYnV0IG1pc21hY3RoZWQgcmVzcG9u c2UgbWVzc2FnZXMuDQoNCkZvciBBbmFseXNpcyAyDQoNClRoaXMgaXMgdGhlIHByb2JsZW0gb2Yg YmFzaWMgSEEgc2ltdWxhdGVub3VzIGZhaWwtb3ZlciBhbmQgbm90IGp1c3QgYWJvdXQgbWVzc2Fn ZSBJRCBzeW5jaHJvbmlzYXRpb24uDQoNCndoZW4gYm90aCBvZiB0aGUgZGV2aWNlcyBkb26hr3Qg aGF2ZSBuZXcgc2EgYW5kIGp1c3QgaGF2ZSB0aGUgb2xkIHNhLg0KVGhlbiB0aGV5IHdpbGwgIGNv bnRpbnVlIHdpdGggdGhlIG9sZCBzYSBvciBicmluZyBkb3duIHRoZSBzYSBiYXNlZCBvbiB0aGUg YWRtaW5pc3RyYXRpdmUgY29udHJvbC4NCg0KdGhlIHN5bmMgdGltZSB3aXRoaW4gYSBjbHVzdGVy ICBhbW9uZyBhIGFuZCBiIG1pZ2h0IGJlIHNhbWUgb3IgZGlmZmVyZW50IGR1ZSB0byB3aGljaCBv bmUgb2YgdGhlbSB3b3VsZCBoYXZlIG9sZCBzYSBhbmQgYW5vdGhlciB3b3VsZCBoYXZlIG5ldyBz YS4gaW4gc3VjaA0KY2FzZXMgYm90aCB0aGUgc2Egd291bGQgYmUgZGVsZXRlZCBldmVudHVhbGx5 IGFuZCBuZXcgc2EgaXMgZXN0YWJsaXNoZWQuDQoNCm9yIGV2ZW4gaWYgc3luYyB0aW1lcyBhcmUg ZGlmZmVyZW50LCBvbmUgd291bGQgaGF2ZSBvbGQgc2Egd2l0aCBsZXNzZXIgbWVzc2FnZSBpZCdz IGFuZCBvdGhlciBoYXZlIHNhbWUgb2xkIHNhIHdpdGggaGlnaGVyIG1lc3NhZ2UgaWQncyBhbmQg dGhlbiBib3RoIHdpbGwNCnN0YXJ0IGZyb20gdGhlIGhpZ2hlciBtZXNzYWdlIGlkIHZhbHVlcy4N Cg0KUmVnYXJkcywNCmthbHlhbmkNCg0KRnJvbTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB6aGFuZy5ydWlzaGFuQHp0 ZS5jb20uY24NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMCwgMjAxMiA3OjQ0IEFNDQpUbzogS2Fs eWFuaSBHYXJpZ2lwYXRpIChrYWdhcmlnaSkNCkNjOiBpcHNlY0BpZXRmLm9yZzsgaXBzZWMtYm91 bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIg RXh0ZW5zaW9uIGZvciBJS0V2Mi9JUHNlYyBIaWdoIEF2YWlsYWJsaXR5DQoNCg0KSGkgS2FseWFu aSwNCg0KDQoNCkZpcnN0IEknZCBsaWtlIHRvIG1ha2Ugc29tZSBjbGFyaWZpY2F0aW9ucyBhY2Nv cmRpbmcgdG8geW91ciBjb21tZW50cywgYW5kIGxlYXZlIG90aGVyIGNsYXJpZmljYXRpb25zIHRv IGZ1cnRoZXIgZGlzY3Vzc2lvbnMuDQoNCjEuIENsYXJpZmljYXRpb24gZm9yIGNhc2UgQyBpbiBT ZWN0aW9uIDIuMg0KKGNhc2UgQyBpcyB0aGUgbW9zdCB0cm91Ymxlc29tZSBpbiB0aGlzIHNlY3Rp b24gSU1PLlNvIEknZCBsaWtlIHRvIGNsYXJpZnkgaXQuKQ0KMS4xIE5vdGF0aW9uIGZvciBjYXNl IEMgaW4gU2VjdGlvbiAyLjINCg0KeDogdGhlIG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBm cm9tIHRoZSBwZWVyIHBhcnR5DQp5OiB0aGUgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRA0KDQphMDog dGhlIG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXINCmExOiB0aGUgbmV3IGFjdGl2ZSBjbHVzdGVy IG1lbWJlcg0KYjogIHRoZSBwZWVyDQoNCg0KYTBbdF0ueCAgYTAncyBtYXhpbXVtIG1lc3NhZ2Ug SUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBiIHVudGlsIHRpbWUgdA0KYTBbdF0ueSAgYTAncyBu ZXh0IHNlbmRlciBtZXNzYWdlIElEICBhdCB0aW1lIHQNCg0KYTFbdF0ueCAgYTEncyBtYXhpbXVt IG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBiICB1bnRpbCB0aW1lIHQNCmExW3Rd LnkgIGExJ3MgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRCAgYXQgdGltZSB0DQoNCmJbdF0ueCAgIGIn cyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3RlciAgdW50aWwgdGlt ZSB0DQpiW3RdLnkgICBiJ3MgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRCBhdCB0aW1lIHQNCg0KDQpU MDogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgbGFzdCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBh MCBhbmQgYTEgaXMgY2FycmllZCBvdXQNCg0KVDE6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIGZh aWxvdmVyIGV2ZW50IG9jY3Vycw0KDQpUMjogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2Fn ZSBJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYiBzdGFydHMNCg0KDQpUMzogQXQg dGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBh MSBhbmQgYiBlbmRzDQoNClNXOiB0aGUgc2VuZGVyIHdpbmRvdyBzaXplIG9mIHRoZSBjbHVzdGVy LiBMZXQncyBhc3N1bWUgU1cgaXMgNS4NCg0KLS0tLVQwLS0tLS0tLS1UMS0tLS0tLS0tLS1UMi0t LS0tLS0tLS1UMy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KMS4yIEFu YWx5c2lzIGZvciBjYXNlIEMgaW4gU2VjdGlvbiAyLjINCg0KDQpXZSBrbm93IHRoYXQ6DQoNCmEx W1QwXS54ID09IGEwW1QwXS54DQphMVtUMF0ueSA9PSBhMFtUMF0ueQ0KKFRoZSByZWFvbiBpcyB0 aGF0IGF0IFQwLCB0aGUgc3luY2hyb25pemF0aW9uIGJldHdlZW4gYTAgYW5kIGExIGlzIGNhcnJp ZWQgb3V0LikNCg0KQW5kDQoNCg0KYTFbVDFdLnggPT0gYTBbVDBdLngNCmExW1QxXS55ID09IGEw W1QwXS55DQoNCkFuZA0KDQphMVtUMl0ueCA9PSBhMFtUMF0ueA0KYTFbVDJdLnkgPT0gYTBbVDBd LnkNCg0KKFRoZSByZWFvbiBpcyB0aGF0IGZyb20gVDAgdG8gVDIsIHRoZSBzdGF0ZSBkYXRhIG9m IGExIGtlZXBzIHVuY2hhbmdlZC4pDQoNCkFjY29yZGluZyB0byBSRkMgNjMxMSwNCg0KIk0xIGlz IHRoZSBuZXh0IHNlbmRlcidzIE1lc3NhZ2UgSUQgdG8gYmUgdXNlZCBieSB0aGUgbWVtYmVyLiAg TTENCk1VU1QgYmUgY2hvc2VuIHNvIHRoYXQgaXQgaXMgbGFyZ2VyIHRoYW4gYW55IHZhbHVlIGtu b3duIHRvIGhhdmUNCmJlZW4gdXNlZC4gIEl0IGlzIFJFQ09NTUVOREVEIHRvIGluY3JlbWVudCB0 aGUga25vd24gdmFsdWUgYXQNCmxlYXN0IGJ5IHRoZSBzaXplIG9mIHRoZSBJS0Ugc2VuZGVyIHdp bmRvdy4iDQoNCkF0IFQyLCB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgY2FuIHNldCBNMT1hMVtU Ml0ueSArIFNXLg0KDQoNCkFuZA0KDQoiTTIgTVVTVCBiZSBhdCBsZWFzdCB0aGUgaGlnaGVyIG9m IHRoZSByZWNlaXZlZCBNMSwgYW5kIG9uZSBtb3JlDQogICAgICB0aGFuIHRoZSBoaWdoZXN0IHNl bmRlciB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbHVzdGVyLiAgVGhpcw0KICAgICAgaW5jbHVk ZXMgYW55IHByZXZpb3VzIHJlY2VpdmVkIHN5bmNocm9uaXphdGlvbiBtZXNzYWdlcy4iDQoNCkF0 IFQyLCB0aGUgcGVlciBiIGNhbiBzZXQgTTIgPSBtYXgoTTEsIDEgKyBiW1QyXS54KS4NCg0KTTE9 PWExW1QyXS55ICsgU1cgPT4gTTEgPT0gYTBbVDBdLnkgKyBTVyAgPT4gTTEgPT0gYTBbVDBdLnkg KyA1DQoNClN1cHBvc2Ugc29tZSBtZXNzYWdlIGV4Y2hhbmdlcyAoaS5lLiwgMTAgbWVzc2FnZXMp IGhhdmUgYmVlbiBjYXJyaWVkIG91dCBmcm9tIFQwIHRvIFQyLCBpdCdzIHBvc3NpYmxlIHRoYXQg YltUMl0ueCArIDEgPiBhMFtUMF0ueSArIDUuDQoNClRoZW4gdGhlIHBlZXIgYiBzZXRzIE0yPTEg KyBiW1QyXS54Lg0KDQpBdCBUMywgd2hlbiB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgcmVjZWl2 ZXMgdGhlIE1lc3NhZ2UgSUQgc3luY2hyb25pemF0aW9uIHJlc3BvbnNlIGZyb20gdGhlIHBlZXIg YiwgYTEgIHNldHMgYTFbVDNdLnkgPSBNMi4NCg0KYTFbVDNdLnkgPT0gTTIgPT4gYTFbVDNdLnkg PT0xICsgYltUMl0ueC4NCg0KDQpBdCBUMiwgYTBbVDJdLnkgY291bGQgYmUgYltUMl0ueCs1Lg0K KFRoZSByZWFvbiBpcyB0aGF0IGEwJ3Mgc2VudCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIGJb VDJdLngrMSwgYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1IG1heSBOT1Qg aGF2ZSByZWFjaGVkIHRvIHRoZSBwZWVyIGIuKQ0KDQpUaGlzIG1lYW5zIGExW1QzXS55IDwgYTBb VDJdLnkuDQoNClRoaXMgbWVhbnMgdGhlIGZpcnN0IGZpdmUgbWVzc2FnZXMgc2VudCBieSB0aGUg bmV3IGFjdGl2ZSBtZW1iZXIgYTEgd2lsbCBoYXZlIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltU Ml0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1Lg0KDQpTdXBwb3NlIGFmdGVyIFQz LCB0aGUgcGVlciByZWNlaXZlcyB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAncyBzZW50IG1lc3Nh Z2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0ueCszLGJbVDJd LngrNCxiW1QyXS54KzUsIGFuZCBzZW5kcyByZXNwb25zZSBtZXNzYWdlcy4NCg0KQWZ0ZXIgdGhh dCwgdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHNlbmRzIHRoZSBmaXJzdCBmaXZlIHJlcXVlc3Qg bWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBiW1QyXS54KzEsIGJbVDJdLngrMixiW1QyXS54KzMs YltUMl0ueCs0LGJbVDJdLngrNS4NCkFmdGVyIHJlY2V2aW5nIHRoZXNlIHJlcXVlc3QgbWVzc2Fn ZXMsIHRoZSBwZWVyIGIgd2lsbCByZWdhcmRzIHRoZXNlIHJlcXVlc3RzIGFzIHJlc2VudCBtZXNz YWdlcywgYW5kIHJldHVybnMgcmVzcG9uc2UgbWVzc2FnZXMgZm9yDQpyZXF1ZXN0cyBvZiAgYTAn cyBzZW50IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltU Ml0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUgdG8gYTEuDQooTXkgdW5kZXJzdGFuZGluZywgYWNj b3JkaW5nIHRvIFJGQyA1OTk2LCBpcyB0aGF0IHRoZSBwZWVyIHNob3VsZCB0cmVhdCB0aGUgbmV3 IGFjdGl2ZSBtZW1iZXIncyByZXF1ZXN0IG1lc3NhZ2VzIGFzIHJlc2VudCByZXFldXN0cy4gKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZS1zZW50DQpBcyBhIHJlc3VsdCwgdGhl IHBlZXIgYiByZWNlaXZlcyBhY2NlcHRhYmxlIGJ1dCBtaXNtYXRjaGVkIHJlc3BvbnNlcyBmb3Ig aXRzIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBhMVtUMl0ueCsxLCBhMVtUMl0u eCsyLGExW1QyXS54KzMsYTFbVDJdLngrNCxhMVtUMl0ueCs1Lg0KDQpGb3IgYSBjb25jcmV0ZSBl eGFtcGxlLCBsZXQncyBhc3N1bWU6DQoNCmExW1QwXS54ID09IGEwW1QwXS54ID0gOQ0KYTFbVDBd LnkgPT0gYTBbVDBdLnkgPSAyMA0KDQpiW1QwXS54ID0gMTkNCmJbVE9dLnkgPSAxMA0KDQpGcm9t IFQwIHRvIFQxLCB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAgaGF2ZSBzZW50IDEwIHJlcXVlc3Qg bWVzc2FnZXMgdG8gdGhlIHBlZXIgYiwgYW5kIDUgbWVzc2FnZXMgaGF2ZSBiZWVuIHJlY2VpdmVk IGFuZCBhY2tub3dsZWRnZWQgYnkgdGhlIHBlZXIgYi4NCg0KVGhpcyBtZWFucyB0aGF0IGEwW1Qy XS55ID0gMzAsIGJbVDJdLnggPSAyNC4gTm90ZSByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2Fn ZSBJRCAyNSwyNiwyNywyOCwyOSBoYXZlIGJlZW4gc2VudCBieSB0aGUgb2xkIGFjdGl2ZSBtZW1i ZXIgYTAsIGJ1dCBoYXZlIE5PVCByZWFjaGVkIHRoZSBwZWVyIGIwLiAoVGhlIHNlbmRlciB3aW5k b3cgc2l6ZSBvZiB0aGUgY2x1c3RlciBpcyA1LikNCg0KDQpBY2NvcmRpbmcgdG8gUkZDIDYzMTEs DQoNCiJNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNzYWdlIElEIHRvIGJlIHVzZWQgYnkgdGhl IG1lbWJlci4gIE0xDQpNVVNUIGJlIGNob3NlbiBzbyB0aGF0IGl0IGlzIGxhcmdlciB0aGFuIGFu eSB2YWx1ZSBrbm93biB0byBoYXZlDQpiZWVuIHVzZWQuICBJdCBpcyBSRUNPTU1FTkRFRCB0byBp bmNyZW1lbnQgdGhlIGtub3duIHZhbHVlIGF0DQpsZWFzdCBieSB0aGUgc2l6ZSBvZiB0aGUgSUtF IHNlbmRlciB3aW5kb3cuIg0KDQoNCk0xID09IGExW1QyXS55ICsgU1cgPT0gMjAgKyA1ID09IDI1 DQooYTFbVDJdLnkgPT0gYTFbVDBdLnkgPT0gMjApDQoNCkFuZA0KIk0yIE1VU1QgYmUgYXQgbGVh c3QgdGhlIGhpZ2hlciBvZiB0aGUgcmVjZWl2ZWQgTTEsIGFuZCBvbmUgbW9yZQ0KdGhhbiB0aGUg aGlnaGVzdCBzZW5kZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4gIFRoaXMNCmlu Y2x1ZGVzIGFueSBwcmV2aW91cyByZWNlaXZlZCBzeW5jaHJvbml6YXRpb24gbWVzc2FnZXMuIg0K DQpNMiA9PSBtYXh7TTEsIDEgKyBiW1QyXS54KT09IG1heCgyNSwxKzI0KSA9PSAyNQ0KDQpBZnRl ciB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgcmVjZWl2ZXMgTTIsIGExIHNldHMgYTFbVDJdLnkg PT0gMjUgPCBhMFtUMl0ueSA9PSAzMC4NCg0KVGhlIE1lc3NhZ2UgSUQgZm9yIHRoZSBuZXcgYWN0 aXZlIG1lbWJlciBhMSBudW1iZXJzIGZyb20gMjUuDQoNClRoZSBmaXJzdCBmaXZlIE1lc3NhZ2Ug SURzIGFyZSAyNSwgMjYsIDI3LDI4LDI5Lg0KDQpXaGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBh MSBzZW5kcyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZXMgSURzIDI1LCAyNiwyNywyOCwy OSwgc2luY2UgdGhlIHBlZXIgYiBoYXMgcHJvY2Vzc2VkIHRoZSByZXF1ZXN0IG1lc3NhZ2Ugd2l0 aCB0aGUgc2FtZSBNZXNzYWdlIElEcywgdGhlIHBlZXIgYiB3aWxsIHJldHVybiByZXNwb25zZSBt ZXNzYWdlcyBmb3IgdGhlIHJlcXVlc3QgbWVzc2FnZXMgZnJvbSB0aGUgb2xkIGFjdGl2ZSBtZW1i ZXIgYTAuDQoNClRoZW4gYTEgcmVjZWl2ZXMgYWNjZXB0YWJsZSBidXQgbWlzbWFjdGhlZCByZXNw b25zZSBtZXNzYWdlcy4NCg0KDQoyLiBDbGFyaWZpY2F0aW9ucyBmb3IgdGhlIHNpbXVsdGFuZXNv dXMgZmFpbG92ZXIgY2FzZSBGIGluIFNlY3Rpb24gMi4zDQpGb3IgdGhlIHNpbXVsdGFuZW91cyBm YWlsb3ZlciwgY2FzZSBGIGlzIHRoZSBtb3N0IGRldmFzdGF0aW5nIElNTy4gU28gSSdkIGxpa2Ug dG8gY2xhcmlmeSBpdCBmaXJzdC4NCjIuMSBOb3RhdGlvbiBmb3IgdGhlIHNpbXVsdGFuZXNvdXMg ZmFpbG92ZXIgY2FzZSBGIGluIFNlY3Rpb24gMi4zDQoNCg0KYTA6IHRoZSBvbGQgYWN0aXZlIGNs dXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGENCmExOiB0aGUgbmV3IGFjdGl2ZSBjbHVzdGVy IG1lbWJlciBvZiB0aGUgY2x1c3RlciBhDQpiMDogdGhlIG9sZCBhY3RpdmUgY2x1c3RlciBtZW1i ZXIgb2YgdGhlIGNsdXN0ZXIgYg0KYjE6IHRoZSBuZXcgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9m IHRoZSBjbHVzdGVyIGINCg0KDQpUMDogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgbGFzdCBzeW5j aHJvbml6YXRpb24gYmV0d2VlbiBhMC9iMCBhbmQgYTEvYjEgaXMgY2FycmllZCBvdXQsDQoNClQx OiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBzaW11bHRhbmVvdXMgZmFpbG92ZXIgZXZlbnQgb2Nj dXJzDQoNClQyOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5bmNocm9uaXph dGlvbiBiZXR3ZWVuIGExIGFuZCBiMSBzdGFydHMNCg0KDQpUMzogQXQgdGhpcyB0aW1lIHBvaW50 LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYjEgZW5kcw0K DQoNCg0KLS0tLVQwLS0tLS0tLS1UMS0tLS0tLS0tLS1UMi0tLS0tLS0tLS1UMy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KMi4yIEFuYWx5c2lzIGZvciB0aGUgc2ltdWx0 YW5lc291cyBmYWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjMNCg0KDQpJdCdzIHBvc3NpYmxl IHRoYXQgZnJvbSBUMCB0byBUMSwgYTAgYW5kIGIwIGRlbGV0ZXMgdGhlIG9sZCBJS0UgU0Egc2Ew IGFuZCBjcmVhdGVzIGEgbmV3IElLRSBTQSBzYTEuDQpCdXQgYXQgVDIsIGExIGFuZCBiMSBkbyBO T1Qga25vdyB3aGF0IGhhcyBoYXBwZW5lZCBmcm9tIFQwIGFuZCBUMSwgYW5kIGRvIE5PVCBrbm93 IHRoZSBleGlzdGFuY2Ugb2YgdGhlIG5ldyBJS0UgU0Egc2ExLCBhbmQgdXNlIHRoZSBvbGQgSUtF IFNBIHNhMCB0byBjYXJyeSBvdXQgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24uDQpUaGlzIG1h eSBicmluZyBzb21lIG1vcmUgc2VyaW91c2UgcHJvYmxlbS4gU28gIHdoZW4gc2ltdWx0YW5lb3Vz IGZhaWxvdmVyIG9jY3VycywgYSBzaW1wbGUgdHdvLXdheSBzeW5jaHJvbml6YXRpb24gIG1heSBu b3QgYmUgYW4gYXBwcm9wcmlhdGUgc29sdXRpb24uDQoNCg0KDQoNCg0KIkthbHlhbmkgR2FyaWdp cGF0aSAoa2FnYXJpZ2kpIiA8a2FnYXJpZ2lAY2lzY28uY29tPG1haWx0bzprYWdhcmlnaUBjaXNj by5jb20+Pg0Kt6K8/sjLOiAgaXBzZWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aXBzZWMtYm91 bmNlc0BpZXRmLm9yZz4NCg0KMjAxMi0wNi0xNCAxOToxNA0KDQrK1bz+yMsNCg0KInpoYW5nLnJ1 aXNoYW5AenRlLmNvbS5jbjxtYWlsdG86emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPiIgPHpoYW5n LnJ1aXNoYW5AenRlLmNvbS5jbjxtYWlsdG86emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPj4sICJp cHNlY0BpZXRmLm9yZzxtYWlsdG86aXBzZWNAaWV0Zi5vcmc+IiA8aXBzZWNAaWV0Zi5vcmc8bWFp bHRvOmlwc2VjQGlldGYub3JnPj4NCg0Ks63LzQ0KDQrW98ziDQoNClJlOiBbSVBzZWNdIFVwZGF0 ZXMgdG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMgICAgICAgIEhpZ2ggICAg ICAgIEF2YWlsYWJsaXR5DQoNCg0KDQoNCg0KDQoNCkhpIFpoYW5nLA0KDQpUaGFua3MgZm9yIGdv aW5nIHRocm91Z2ggdGhlIFJGQyA2MzExIC4NCg0KSSBoYXZlIGdvbmUgdGhyb3VnaCB5b3VyICBw cm9wb3NlZCBkcmFmdCBhbmQgZmVsdCB0aGF0IHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIHJlZ2Fy ZGluZyB0aGUgbWVzc2FnZSBpZCBjb25jZXB0IG9mIGlrZXYyLg0KDQpJIGhhdmUgc2VlbiB0aGF0 IGluIHNlY3Rpb24gMi4zIHlvdSB3ZXJlIGNvbXBhcmluZyB0aGUgaGlnZXIgc2VuZGVyIHZhbHVl IG9mIHgyIHdpdGggeTIuDQpUaGF0IGlzIHdyb25nLiB3aGVuIHgyIHByb3Bvc2VzIHRoZSBuZXh0 IGhpZ2hlciBtZXNzYWdlIGlkIHRvIGJlIHVzZWQgdG8gc2VuZCBhIHJlcXVlc3QgLA0KdGhlbiBv biB5MiB5b3Ugc2hsZCB0YWxseSBpdCB3aXRoIHRoZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlkIG9m IHRoZSByZXF1ZXN0IHRvIGJlIHJlY2lldmVkDQogICAgICAgICAgICAoYW5kIG5vdCB3aXRoIHRo ZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHNlbnQpDQoNCmlu IGlrZXYyIHRoZSAgbWVzc2FnZSBpZCBvZiByZXF1ZXN0cyB0byBiZSBzZW50IGFyZSBlbnRpcmVs eSBkaWZmZXJlbnQgZnJvbSBtZXNzYWdlIGlkIG9mIHJlcXVlc3RzIHRvIGJlIHJlY2VpdmVkLg0K dGhhdCBpcyB3aHkgUkZDIHNheXMgYSBtZXNzYWdlIGlkIGlzIHVzZWQgZm91ciB0aW1lcyBvbiBh IGdpdmVuIGRldmljZS4NCg0KMS4gbWVzc2FnZSBpZCBYIGlzIHVzZWQgd2hpbGUgc2VuZGluZyBh IHJlcXVlc3QNCjIuIG1lc3NhZ2UgaWQgWCBpcyB1c2VkIHdoaWxlIHJlY2VpdmluZyB0aGUgcmVz cG9uc2UNCjMuIG1lc3NhZ2UgaWQgWCBpcyB1c2VkIHRvIHJlY2VpdmUgYSByZXF1ZXN0DQo0LiBt ZXNzYWdlIGlkIFggaXMgdXNlZCB0byBzZW5kIGEgcmVzcG9uc2UuDQoNCg0KcGxlYXNlIGZpbmQg dGhlIGNvbW1lbnRzIGZvciBlYWNoIHNlY3Rpb24NCg0KU2VjdGlvbiAyLjE6ICBUaGlzIGlzIGEg a25vd24gaXNzdWUgYW5kIHRoYXQgaXMgd2h5IHVzaW5nIFJGQyA2MzExLCAgd2UgYXJlIHN5bmNo cm9uaXNpbmcgdGhlIG1lc3NhZ2UgaWQncw0KDQpTZWN0aW9uIDIuMjogVGhlIHBlZXIgaXMgYXNz dW1lZCB0byBiZSBwcm9wZXIgYW5jaG9yIHBvaW50IHdoaWNoIGhhcyBjb3JyZWN0IGluZm8gb2Yg bWVzc2FnZSBpZCBvZiByZXF1ZXN0cyBzZW50IGFuZCByZWNpZXZlZCwNCmV2ZW4gd2hlbiBwZWVy IGlzIGNsdXN0ZXIgbWVtYmVyICwgYW1vbmcgdGhlIHR3byBkZXZpY2VzIG9uZSBvZiB0aGVtIHdv dWxkIGJlIGxlc3Mgd3JvbmcgYW5kIGhhdmUgaGlnaGVyIGFjY3VyYXRlIHZhbHVlcyBvZiBtZXNz YWdlIGlkJ3MgLg0Kc28gd2UgcGljayB1cCB0aGF0IHZhbHVlLiBJIGRvbnQgc2VlIGFueSBpc3N1 ZSBoZXJlLg0KDQpTZWN0aW9uIDIuMzogRmlyc3Qgb2YgYWxsIHRoZXJlIGlzIG5vIHJlbGF0aW9u IGJldHdlZW4gTTEgYW5kIFAxLg0Kb24gYSBnaXZlbiBkZXZpY2UuDQotLS0gTTEgaXMgdGhlIHBy b3Bvc2VkIG1lc3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgc2VudA0KICAgIFAxIGlzIHRo ZSBwcm9wb3NlZCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHJlY2VpdmVkLg0KDQp3 aGVuIHNpbXVsYXRlbm91cyBmYWlsb3ZlciBoYXBwZW5zLCB4MiBtaWdodCBoYXZlIGhpZ2hlciB2 YWx1ZSBvZiBNMSB3aGVuIGNvbXBhcmVkIHRvIHkyICwgYnV0IHgyIG1pZ2h0IGhhdmUgbG93ZXIg dmFsdWUgb2YgUDEgd2hlbiBjb21wYXJlZCB0byB5Mi4NCkl0IGRvZXMnbnQgbWF0dGVyLiBib3Ro IGFyZSBpbmRlcGVuZGVudC4gd2hhdCB3ZSBldmVudHVhbGx5IGRvIGlzIGNvbXBhcmUgdGhlIE0x IHZhbHVlIGFjcm9zcyB4MiBhbmQgeTIgYW5kIHBpY2sgdGhlIGhpZ2VyIG9uZS4NCnNhbWUgcHJv Y2VzcyBpcyByZXBlYXRlZCBmb3IgUDEuDQoNCmNhc2UgMSB0byA2IGFyZSBhbHJlYWR5IGhhbmRs ZWQgYnkgYmFzaWMgaWtldjIgUkZDIC4gbGlrZSBpZiB3ZSByZWNlaXZlIHNhbWUgbWVzc2FnZSBp ZCB0d2ljZSAsIHRoZW4gd2UgcmV0cmFuc21pdCBvciBkcm9wIGl0IGlmIGl0IGlzIG91dHNpZGUg dGhlIHdpbmRvdy4NCg0KDQpTZWN0aW9uIDM6ICAgZHVyaW5nIHNpbXVsdGFuZW91cyBmYWlsb3Zl ciBib3RoIHRoZSBjbHVzdGVyIGFuZCB0aGUgcGVlciBtZW1iZXIgd291bGQgYmUgaW4gdW5yZWxp YWJsZSBzdGF0ZS4NCkJvdGggb2YgdGhlbSBhcmUgd3JvbmcgLCBidXQgb25lIG9mIHRoZW0gaXMg bGVzcyB3cm9uZyAhISEgc28gd2Ugd2FudCB0byBzdGFydCBmcm9tIHRoYXQgcG9pbnQgdG8gc3lu Y2hyb25pc2UgdGhlIG1lc3NhZ2UgaWQncy4NCg0Kc28gd2UgYXJlIGFsbG93aW5nIGJvdGggdGhl IG1lbWJlcnMgdG8gYW5ub3VuY2UgdGhlaXIgbWVzc2FnZSBpZCdzIGFuZCB0aGVuIGV2ZW50dWFs bHkgd2Ugd291bGQgc3luY2hyb25pc2UgdG8gdGhlIGhpZ2hlciBudW1iZXIuDQpJIGRvbnQgc2Vl IGFueSBmbGF3IGhlcmUuIFBsZWFzZSBleHBsYWluIHdpdGggYW4gZXhhbXBsZS4NCg0KQnkgeW91 ciBwcm9wb3NhbCBpbiBjYXNlIG9mIHNpbXVsdGFuZW91cyBmYWlsb3ZlciwgYm90aCB0aGUgY2x1 c3RlciBhbmQgcGVlciB3aWxsIGJlIGluIFVOU1lORUQgc3RhdGUgYW5kDQpib3RoIHdvdWxkIGVu ZCB1cCBzZW5kaW5nIGFuZCByZWplY3RpbmcgdGhlIHN5bmNocm9uaXNhdGlvbiByZXF1ZXN0Lg0K VGhpcyB3b3VsZCBsZWFkIHRvIHJlcGVhdGVkIHN5bmNocm9uaXNhdGlvbiBlZmZvcnRzIGFuZCB0 aGUgcHJvYmxlbSBvZiBtZXNzYWdlIHN5bmNocm9uaXNhdGlvbiBpcyBuZXZlciBzb2x2ZWQuDQoN CnNvIFVOU1lORUQgc3RhdGUgaXMgbm90IHJlcXVpcmVkLg0KDQpTZWN0aW9uIDQ6DQoNCkkgZmVl bCB0aGF0IFJGQyA2MzExIGFscmVhZHkgc29sdmVzIHRoZSBtZXNzYWdlIGlkIHN5bmNocm9uaXNh dGlvbiBpc3N1ZS4NCkkgZG9udCB0aGluayB3ZSBuZWVkIHRvIGluY3JlbWVudCBNMSBieSBkb3Vi bGUgdGhlIHdpbmRvdyBzaXplIGFzIHByb3Bvc2VkIGJ5IHlvdS4NClBsZWFzZSBzdXBwb3J0IHlv dXIgcHJvcG9zYWwgd2l0aCBhbiBleGFtcGxlIHdpdGggbWVzc2FnZSBpZCB2YWx1ZXMgb2YgbnVt YmVycyBpbnN0ZWFkIG9mIHZhcmlhYmxlcy4NCkxpa2UgTTEgaXMgMyAsIE0yIGlzIDQgZXRjIGV0 Yy4NCg0KTnVtYmVycyBtYWtlIGl0IG1vcmUgY2xlYXIuDQoNCnJlZ2FyZHMsDQprYWx5YW5pDQoN CkZyb206IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86aXBzZWMt Ym91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiB6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY248 bWFpbHRvOnpoYW5nLnJ1aXNoYW5AenRlLmNvbS5jbj4NClNlbnQ6IE1vbmRheSwgSnVuZSAxMSwg MjAxMiA3OjM2IEFNDQpUbzogaXBzZWNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjQGlldGYub3JnPg0K U3ViamVjdDogW0lQc2VjXSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYy L0lQc2VjIEhpZ2ggQXZhaWxhYmxpdHkNCg0KDQoNCkRlYXIgQWxsLA0KDQogSSd2ZSBzdWJtaXR0 ZWQgYSBuZXcgZHJhZnQgIiBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYy L0lQc2VjIEhpZ2ggQXZhaWxhYmxpdHkiLiBUaGlzIGRyYWZ0IGFuYWx5emVzIHNvbWUgaXNzdWVz IGluIFJGQyA2MzExLA0KYW5kIHByb3Bvc2VzIHNvbWUgdXBkYXRlcy4gTG9vayBmb3J3YXJkIHRv IHlvdXIgY29tbWVudHMuDQoNCg0KQlIsDQoNClJ1aXNoYW4gWmhhbmdfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNl Y0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo= --_000_52F04C02CB538E4DAAA0B493EBCA4A7503F049EDxmbrcdx11ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Zhang,

 <= /p>

For Analysis 1

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 <= /p>

a0[t].x  a0's maximu= m message ID received from the peer b until time t 

a0[t].y  a0's next s= ender message ID  at time t

 <= /p>

I think there is confusio= n above.

I guess what u actually w= anted to convey is

 <= /p>

a0[t].x  a0's maximu= m message ID of the request sent and orderly response received from the pee= r b until time t , say if a has received responses for 2 and 3 and 5  , this value is 3. So now the window would be 4-8 (inclusive= )

a0[t].y  a0's next r= equest message ID to be sent at time t , this value is 6 , if it has alread= y sent the requests 2,3,4,5,

 <= /p>

b[t].x   b's ma= ximum message ID of the orderly response sent to cluster  until time t= , if it has sent response to 2,3 and 5 id requests , it is still 3.

b[t].y   b's ne= xt message id of the request to be received, which is 6

 <= /p>

 <= /p>

I guess the example has w= rong values.

 <= /p>

if window size is 5

 <= /p>

then

 <= /p>

For a concrete example, l= et's assume:

 <= /p>

a1[T0].x =3D=3D a0[T0].x = =3D 9 ---------------how can x and y vary by 10 when the window size is 5&n= bsp; ?

a1[T0].y =3D=3D a0[T0].y = =3D 20

 <= /p>

b[T0].x =3D 19  = ; -- same is the case here..

b[TO].y =3D 10

 <= /p>

Please adjust these value= s and then there will be no issues as mentioned by you.

 <= /p>

also please refer to the = section 8.1 and 9 of the RFC 6311 which says that when the window moves to = the synchronised value,

all the old pending requests and to-be retransmitted responses sho= uld be deleted. So the below issue will not happen

 

When the new active member a1 sends request messages with Messa= ges IDs 25, 26,27,28,29, since the peer b has processed the request message with the same

Message IDs, the peer b will return response messages for the r= equest messages from the old active member a0.

 

Then a1 receives acceptable but mismacthed response messages.

 

For Analysis 2

 <= /p>

This is the problem of ba= sic HA simulatenous fail-over and not just about message ID synchronisation= .

 <= /p>

when both of the devices = don=A1=AFt have new sa and just have the old sa.

Then they will  cont= inue with the old sa or bring down the sa based on the administrative contr= ol.

 <= /p>

the sync time within a cl= uster  among a and b might be same or different due to which one of th= em would have old sa and another would have new sa. in such

cases both the sa would b= e deleted eventually and new sa is established.

 <= /p>

or even if sync times are= different, one would have old sa with lesser message id's and other have s= ame old sa with higher message id's and then both will

start from the higher mes= sage id values.

 <= /p>

Regards,

kalyani=

 <= /p>

From: ipsec-bo= unces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of zhang.ruishan@zte.com.cn
Sent: Wednesday, June 20, 2012 7:44 AM
To: Kalyani Garigipati (kagarigi)
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org
Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec = High Availablity

 


Hi Kalyani,



First I'd like to make some clarifications according to your com= ments, and leave other clarifications to further discussions.

1. Clarification for case C in Section 2.2
(case C is the most troublesome in this section IMO.So I'd like = to clarify it.)
1.1 Notation for case C in Section 2.2

x: the maximum message ID received from the peer party
y: the next sender message ID

a0: the old active cluster member
a1: the new active cluster member
b:  the peer


a0[t].x  a0's maximum message ID received from the peer b u= ntil time t
a0[t].y  a0's next sender message ID  at time t

a1[t].x  a1's maximum message ID received from the peer b &= nbsp;until time t
a1[t].y  a1's next sender message ID  at time t

b[t].x   b's maximum message ID received from the cluster &= nbsp;until time t
b[t].y   b's next sender message ID at time t


T0: At this time point, the last synchronization between a0 and = a1 is carried out

T1: At this time point, the failover event occurs

T2: At this time point, the Message ID synchronization between a= 1 and b starts


T3: At this time point, the Message ID synchronization between a= 1 and b ends

SW: the sender window size of the cluster. Let's assume SW is 5.

----T0--------T1----------T2----------T3------------------------= -------------

1.2 Analysis for case C in Section 2.2


We know that:

a1[T0].x =3D=3D a0[T0].x
a1[T0].y =3D=3D a0[T0].y
(The reaon is that at T0, the synchronization between a0 and a1 = is carried out.)

And


a1[T1].x =3D=3D a0[T0].x
a1[T1].y =3D=3D a0[T0].y

And

a1[T2].x =3D=3D a0[T0].x
a1[T2].y =3D=3D a0[T0].y

(The reaon is that from T0 to T2, the state data of a1 keeps unc= hanged.)

According to RFC 6311,

"M1 is the next sender's Message ID to be used by the membe= r.  M1
MUST be chosen so that it is larger than any value known to have=
been used.  It is RECOMMENDED to increment the known value = at
least by the size of the IKE sender window."

At T2, the new active member a1 can set M1=3Da1[T2].y + SW.


And

"M2 MUST be at least the higher of the received M1, and one= more
      than the highest sender value received from= the cluster.  This
      includes any previous received synchronizat= ion messages."
         
At T2, the peer b can set M2 =3D max(M1, 1 + b[T2].x).

M1=3D=3Da1[T2].y + SW =3D> M1 =3D=3D a0[T0].y + SW &n= bsp;=3D> M1 =3D=3D a0[T0].y + 5

Suppose some message exchanges (i.e., 10 messages) have been car= ried out from T0 to T2, it's possible that b[T2].x + 1 > a0[T0].y &#= 43; 5.

Then the peer b sets M2=3D1 + b[T2].x.

At T3, when the new active member a1 receives the Message ID syn= chronization response from the peer b, a1  sets a1[T3].y =3D M2.

a1[T3].y =3D=3D M2 =3D> a1[T3].y =3D=3D1 + b[T2].x.


At T2, a0[T2].y could be b[T2].x+5.
(The reaon is that a0's sent messages with Message IDs b[T2].x&#= 43;1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 may NOT have = reached to the peer b.)

This means a1[T3].y < a0[T2].y.

This means the first five messages sent by the new active member= a1 will have Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].= x+4,b[T2].x+5.

Suppose after T3, the peer receives the old active member a0's s= ent messages with Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[= T2].x+4,b[T2].x+5, and sends response messages.

After that, the new active member a1 sends the first five reques= t messages with Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2= ].x+4,b[T2].x+5.
After receving these request messages, the peer b will regards t= hese requests as resent messages, and returns response messages for
requests of  a0's sent messages with Message IDs b[T2].x= 3;1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 to a1.
(My understanding, according to RFC 5996, is that the peer shoul= d treat the new active member's request messages as resent reqeusts. )
                  &= nbsp;                    =                     &nbs= p;                     &n= bsp;      re-sent    
As a result, the peer b receives acceptable but mismatched respo= nses for its request messages with Message IDs a1[T2].x+1, a1[T2].x+= ;2,a1[T2].x+3,a1[T2].x+4,a1[T2].x+5.
         
For a concrete example, let's assume:

a1[T0].x =3D=3D a0[T0].x =3D 9
a1[T0].y =3D=3D a0[T0].y =3D 20

b[T0].x =3D 19
b[TO].y =3D 10

From T0 to T1, the old active member a0 have sent 10 request mes= sages to the peer b, and 5 messages have been received and acknowledged by = the peer b.

This means that a0[T2].y =3D 30, b[T2].x =3D 24. Note request me= ssages with Message ID 25,26,27,28,29 have been sent by the old active memb= er a0, but have NOT reached the peer b0. (The sender window size of the cluster is 5.)


According to RFC 6311,

"M1 is the next sender's Message ID to be used by the membe= r.  M1
MUST be chosen so that it is larger than any value known to have=
been used.  It is RECOMMENDED to increment the known value = at
least by the size of the IKE sender window."


M1 =3D=3D a1[T2].y + SW =3D=3D 20 + 5 =3D=3D 25
(a1[T2].y =3D=3D a1[T0].y =3D=3D 20)

And
"M2 MUST be at least the higher of the received M1, and one= more
than the highest sender value received from the cluster.  T= his
includes any previous received synchronization messages."
         
M2 =3D=3D max{M1, 1 + b[T2].x)=3D=3D max(25,1+24) =3D=3D= 25

After the new active member a1 receives M2, a1 sets a1[T2].y =3D= =3D 25 < a0[T2].y =3D=3D 30.

The Message ID for the new active member a1 numbers from 25.

The first five Message IDs are 25, 26, 27,28,29.

When the new active member a1 sends request messages with Messag= es IDs 25, 26,27,28,29, since the peer b has processed the request message = with the same Message IDs, the peer b will return response messages for the request messages from the old active member a0.
Then a1 receives acceptable but mismacthed response messages.

       
2. Clarifications for the simultanesous failover case F in Secti= on 2.3
For the simultaneous failover, case F is the most devastating IM= O. So I'd like to clarify it first.
2.1 Notation for the simultanesous failover case F in Section 2.= 3


a0: the old active cluster member of the cluster a
a1: the new active cluster member of the cluster a
b0: the old active cluster member of the cluster b
b1: the new active cluster member of the cluster b


T0: At this time point, the last synchronization between a0/b0 a= nd a1/b1 is carried out,

T1: At this time point, the simultaneous failover event occurs

T2: At this time point, the Message ID synchronization between a= 1 and b1 starts


T3: At this time point, the Message ID synchronization between a= 1 and b1 ends



----T0--------T1----------T2----------T3------------------------= -------------
           
2.2 Analysis for the simultanesous failover case F in Section 2.= 3


It's possible that from T0 to T1, a0 and b0 deletes the old IKE = SA sa0 and creates a new IKE SA sa1.
But at T2, a1 and b1 do NOT know what has happened from T0 and T= 1, and do NOT know the existance of the new IKE SA sa1, and use the old IKE= SA sa0 to carry out Message ID synchronization.
This may bring some more seriouse problem. So  when simulta= neous failover occurs, a simple two-way synchronization  may not be an= appropriate solution.





"Kalyani Garigipati (kagarigi)&quo= t; <kagarigi@cisco.com>
=B7=A2=BC=FE=C8=CB:  ipsec-bounces@ietf= .org

2012-06-14 19:14

=CA=D5=BC=FE=C8=CB<= /p>

"zhang.ruishan@zte.com.cn" <zhang.ruishan@zte.com.cn>, "ipsec@ietf.org" <ipsec@ietf.org> <= /o:p>

=B3=AD=CB=CD

=D6=F7=CC=E2

Re: [IPsec] Updates to the IKEv2 Extension= for IKEv2/IPsec        High        = ;Availablity

 




Hi Zhang,
 
Thanks for going through the RFC 6311 .
 
I have gone through your  proposed draft an= d felt that there is some confusion regarding the message id concept of ike= v2.
 
I have seen that in section 2.3 you were compari= ng the higer sender value of x2 with y2.
That is wrong. when x2 proposes the next higher = message id to be used to send a request ,
then on y2 you shld tally it with the next highe= r message id of the request to be recieved
            (and n= ot with the next higher message id of the request to be sent)
 
in ikev2 the  message id of requests to be = sent are entirely different from message id of requests to be received.
that is why RFC says a message id is used four t= imes on a given device.
 
1. message id X is used while sending a request<= /span>
2. message id X is used while receiving the resp= onse
3. message id X is used to receive a request
4. message id X is used to send a response.
 
 
please find the comments for each section
 
Section 2.1:  This is a known issue and tha= t is why using RFC 6311,  we are synchronising the message id's
 
Section 2.2: The peer is assumed to be proper an= chor point which has correct info of message id of requests sent and reciev= ed,
even when peer is cluster member , among the two= devices one of them would be less wrong and have higher accurate values of= message id's .
so we pick up that value. I dont see any issue h= ere.
 
Section 2.3: First of all there is no relation b= etween M1 and P1.
on a given device.
--- M1 is the proposed message id of the request= to be sent
    P1 is the proposed message id of t= he request to be received.
 
when simulatenous failover happens, x2 might hav= e higher value of M1 when compared to y2 , but x2 might have lower value of= P1 when compared to y2.
It does'nt matter. both are independent. what we= eventually do is compare the M1 value across x2 and y2 and pick the higer = one.
same process is repeated for P1.
 
case 1 to 6 are already handled by basic ikev2 R= FC . like if we receive same message id twice , then we retransmit or drop = it if it is outside the window.
 
 
Section 3:   during simultaneous failover b= oth the cluster and the peer member would be in unreliable state.
Both of them are wrong , but one of them is less= wrong !!! so we want to start from that point to synchronise the message i= d's.
 
so we are allowing both the members to announce = their message id's and then eventually we would synchronise to the higher n= umber.
I dont see any flaw here. Please explain with an= example.
 
By your proposal in case of simultaneous failove= r, both the cluster and peer will be in UNSYNED state and
both would end up sending and rejecting the sync= hronisation request.
This would lead to repeated synchronisation effo= rts and the problem of message synchronisation is never solved.
 
so UNSYNED state is not required.
 
Section 4:
 
I feel that RFC 6311 already solves the message = id synchronisation issue.
I dont think we need to increment M1 by double t= he window size as proposed by you.
Please support your proposal with an example wit= h message id values of numbers instead of variables.
Like M1 is 3 , M2 is 4 etc etc.
 
Numbers make it more clear.
 
regards,
kalyani
 
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of zhang.ruishan@zte.com.cn
Sent: Monday, June 11, 2012 7:36 AM
To: ipsec@ietf.org
Subject: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Av= ailablity
&= nbsp;


Dear All,

 I've submitted a new draft " Updates to the IKEv2 Extension for= IKEv2/IPsec High Availablity". This draft analyzes = some issues in RFC 6311,
and proposes some updates. Look forward to your comments.


BR,

Ruishan Zhang__________________= _____________________________<= br> IPsec mailing list
IPsec@ietf.org
https://www.iet= f.org/mailman/listinfo/ipsec

--_000_52F04C02CB538E4DAAA0B493EBCA4A7503F049EDxmbrcdx11ciscoc_-- From zhang.ruishan@zte.com.cn Wed Jun 20 19:58:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9B911E80DB; Wed, 20 Jun 2012 19:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.656 X-Spam-Level: X-Spam-Status: No, score=-96.656 tagged_above=-999 required=5 tests=[AWL=-1.480, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-RBbB+HPQ2k; Wed, 20 Jun 2012 19:58:18 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2390711E80BE; Wed, 20 Jun 2012 19:58:16 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620433787882; Thu, 21 Jun 2012 10:54:33 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 48305.2301296981; Thu, 21 Jun 2012 10:57:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q5L2vv2T027785; Thu, 21 Jun 2012 10:57:57 +0800 (GMT-8) (envelope-from zhang.ruishan@zte.com.cn) In-Reply-To: <52F04C02CB538E4DAAA0B493EBCA4A7503F049ED@xmb-rcd-x11.cisco.com> To: "Kalyani Garigipati (kagarigi)" MIME-Version: 1.0 X-KeepSent: 70867D1F:F159204A-48257A24:000C202D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.ruishan@zte.com.cn Date: Thu, 21 Jun 2012 10:57:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-21 10:57:58, Serialize complete at 2012-06-21 10:57:58 Content-Type: multipart/alternative; boundary="=_alternative 00104BB748257A24_=" X-MAIL: mse01.zte.com.cn q5L2vv2T027785 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 02:58:20 -0000 This is a multipart message in MIME format. --=_alternative 00104BB748257A24_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgS2FseWFuaQ0KDQpQbGVhc2Ugc2VlIHRoZSBpbmxpbmUgY2xhcmlmaWNhdGlvbnMuDQoNCkJS LA0KDQpSdWlzaGFuDQoNCg0KDQoiS2FseWFuaSBHYXJpZ2lwYXRpIChrYWdhcmlnaSkiIDxrYWdh cmlnaUBjaXNjby5jb20+IA0Kt6K8/sjLOiAgaXBzZWMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0w Ni0yMCAxODoyNg0KDQrK1bz+yMsNCiJ6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24iIDx6aGFuZy5y dWlzaGFuQHp0ZS5jb20uY24+DQqzrcvNDQoiaXBzZWNAaWV0Zi5vcmciIDxpcHNlY0BpZXRmLm9y Zz4sICJpcHNlYy1ib3VuY2VzQGlldGYub3JnIiANCjxpcHNlYy1ib3VuY2VzQGlldGYub3JnPg0K 1vfM4g0KUmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZvciBJS0V2 Mi9JUHNlYyBIaWdoIA0KQXZhaWxhYmxpdHkNCg0KDQoNCg0KDQoNCkhpIFpoYW5nLA0KIA0KRm9y IEFuYWx5c2lzIDEgDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCiANCmEwW3RdLnggIGEwJ3MgbWF4aW11bSBtZXNzYWdlIElEIHJlY2Vp dmVkIGZyb20gdGhlIHBlZXIgYiB1bnRpbCB0aW1lIHQgDQphMFt0XS55ICBhMCdzIG5leHQgc2Vu ZGVyIG1lc3NhZ2UgSUQgIGF0IHRpbWUgdCANCiANCkkgdGhpbmsgdGhlcmUgaXMgY29uZnVzaW9u IGFib3ZlLg0KSSBndWVzcyB3aGF0IHUgYWN0dWFsbHkgd2FudGVkIHRvIGNvbnZleSBpcyANCiAN CmEwW3RdLnggIGEwJ3MgbWF4aW11bSBtZXNzYWdlIElEIG9mIHRoZSByZXF1ZXN0IHNlbnQgYW5k IG9yZGVybHkgcmVzcG9uc2UgDQpyZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgdW50aWwgdGltZSB0 ICwgc2F5IGlmIGEgaGFzIHJlY2VpdmVkIHJlc3BvbnNlcyANCmZvciAyIGFuZCAzIGFuZCA1ICAs IHRoaXMgdmFsdWUgaXMgMy4gU28gbm93IHRoZSB3aW5kb3cgd291bGQgYmUgNC04IA0KKGluY2x1 c2l2ZSkNCmEwW3RdLnkgIGEwJ3MgbmV4dCByZXF1ZXN0IG1lc3NhZ2UgSUQgdG8gYmUgc2VudCBh dCB0aW1lIHQgLCB0aGlzIHZhbHVlIGlzIA0KNiAsIGlmIGl0IGhhcyBhbHJlYWR5IHNlbnQgdGhl IHJlcXVlc3RzIDIsMyw0LDUsIA0KIA0KYlt0XS54ICAgYidzIG1heGltdW0gbWVzc2FnZSBJRCBv ZiB0aGUgb3JkZXJseSByZXNwb25zZSBzZW50IHRvIGNsdXN0ZXIgDQp1bnRpbCB0aW1lIHQgLCBp ZiBpdCBoYXMgc2VudCByZXNwb25zZSB0byAyLDMgYW5kIDUgaWQgcmVxdWVzdHMgLCBpdCBpcyAN CnN0aWxsIDMuDQpiW3RdLnkgICBiJ3MgbmV4dCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRv IGJlIHJlY2VpdmVkLCB3aGljaCBpcyA2IA0KDQovLyAgQSBjbGFyaWZpY2F0aW9uIGFib3V0IHg6 ICBhMFt0XS54IGlzIHJlbGV2YW50IHRvIHRoZSBtYXhpbXVtIE1lc3NhZ2UgDQpJRCBvZiB0aGUg cmVjZWl2ZWQgcmVxdWVzdCBtZXNzYWdlIGZvciB0aGUgb3Bwb3NpdGUgSUtFIHYyIHBhcnR5LiBT YXkgDQp1bnRpbCB0aW1lIFQwLCBhMCBoYXMgcmVjZWl2ZWQgNSAvL3JlcXVlc3QgbWVzc2FnZXMg ZnJvbSBiLCBhbmQgdGhlIA0KTWVzc2FnZSBJRHMgYXJlIDEsIDIsIDMsIDQsIDUuIFRoZW4gYTBb VDBdLnggPT0gNS4gU2F5IHVudGlsIHRpbWUgVDAsIGIgDQpoYXMgcmVjZWl2ZWQgNCByZXF1ZXN0 IG1lc3NhZ2VzIGZyb20gYSwgYW5kIHRoZSBNZXNzYWdlcyBJRHMgYXJlIC8vNCw1LCA2LCANCjcu IFRoZW4gYltUMF0ueCA9PSA3Lg0KLy9BY3R1YWxseSwgIHggaXMgaXJyZWxldmFudCB0byB5LiAN CiANCkkgZ3Vlc3MgdGhlIGV4YW1wbGUgaGFzIHdyb25nIHZhbHVlcy4NCiANCmlmIHdpbmRvdyBz aXplIGlzIDUgDQogDQp0aGVuIA0KIA0KRm9yIGEgY29uY3JldGUgZXhhbXBsZSwgbGV0J3MgYXNz dW1lOiANCiANCmExW1QwXS54ID09IGEwW1QwXS54ID0gOSAtLS0tLS0tLS0tLS0tLS1ob3cgY2Fu IHggYW5kIHkgdmFyeSBieSAxMCB3aGVuIA0KdGhlIHdpbmRvdyBzaXplIGlzIDUgID8NCi8vIFVu dGlsIFQwLCBhMCBoYXMgcmVjZWl2ZWQgOSByZXF1ZXN0IE1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJ RHMgMSwgMiwgDQozLDQsIDUsIDYsNyw4LDkgZnJvbSB0aGUgcGVlciBiIC4gU28gdGhlIGEwW1Qw XS54ID09OSANCg0KDQphMVtUMF0ueSA9PSBhMFtUMF0ueSA9IDIwIA0KIC8vICBVbnRpbCBUMCwg YTAgaGFzIHNlbnQgMTkgcmVxdWVzdCBNZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIDMs NCwgDQo1LCAuLi4sMTkgdG8gdGhlIHBlZXIgYi4gU28gdGhlIGEwW1QwXS55ICA9PTIwDQogDQpi W1QwXS54ID0gMTkgICAtLSBzYW1lIGlzIHRoZSBjYXNlIGhlcmUuLg0KLy8gVW50aWwgVDAsIHRo ZSBwZWVyIGIgaGFzIHJlY2VpdmVkIDE5IHJlcXVlc3QgTWVzc2FnZXMgd2l0aCBNZXNzYWdlIElE cyANCjEsIDIsIDMsLi4uLDE5IGZyb20gdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwIC4gU28gdGhl IGJbVDBdLnggPT0xOSANCmJbVE9dLnkgPSAxMCANCi8vIFVudGlsIFQwLCB0aGUgcGVlciBiIGhh cyBzZW50IDkgcmVxdWVzdCBNZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIA0KMywuLi4s OSB0byB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAgLiBTbyB0aGUgYltUMF0ueSA9PTkgDQogDQpQ bGVhc2UgYWRqdXN0IHRoZXNlIHZhbHVlcyBhbmQgdGhlbiB0aGVyZSB3aWxsIGJlIG5vIGlzc3Vl cyBhcyBtZW50aW9uZWQgDQpieSB5b3UuDQogDQphbHNvIHBsZWFzZSByZWZlciB0byB0aGUgc2Vj dGlvbiA4LjEgYW5kIDkgb2YgdGhlIFJGQyA2MzExIHdoaWNoIHNheXMgdGhhdCANCndoZW4gdGhl IHdpbmRvdyBtb3ZlcyB0byB0aGUgc3luY2hyb25pc2VkIHZhbHVlLA0KYWxsIHRoZSBvbGQgcGVu ZGluZyByZXF1ZXN0cyBhbmQgdG8tYmUgcmV0cmFuc21pdHRlZCByZXNwb25zZXMgc2hvdWxkIGJl IA0KZGVsZXRlZC4gU28gdGhlIGJlbG93IGlzc3VlIHdpbGwgbm90IGhhcHBlbg0KIA0KV2hlbiB0 aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgc2VuZHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3Nh Z2VzIElEcyAyNSwgDQoyNiwyNywyOCwyOSwgc2luY2UgdGhlIHBlZXIgYiBoYXMgcHJvY2Vzc2Vk IHRoZSByZXF1ZXN0IG1lc3NhZ2Ugd2l0aCB0aGUgDQpzYW1lIA0KTWVzc2FnZSBJRHMsIHRoZSBw ZWVyIGIgd2lsbCByZXR1cm4gcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZXF1ZXN0IA0KbWVz c2FnZXMgZnJvbSB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAuIA0KIA0KVGhlbiBhMSByZWNlaXZl cyBhY2NlcHRhYmxlIGJ1dCBtaXNtYWN0aGVkIHJlc3BvbnNlIG1lc3NhZ2VzLg0KIA0KRm9yIEFu YWx5c2lzIDINCiANClRoaXMgaXMgdGhlIHByb2JsZW0gb2YgYmFzaWMgSEEgc2ltdWxhdGVub3Vz IGZhaWwtb3ZlciBhbmQgbm90IGp1c3QgYWJvdXQgDQptZXNzYWdlIElEIHN5bmNocm9uaXNhdGlv bi4NCiANCndoZW4gYm90aCBvZiB0aGUgZGV2aWNlcyBkb26hr3QgaGF2ZSBuZXcgc2EgYW5kIGp1 c3QgaGF2ZSB0aGUgb2xkIHNhLg0KVGhlbiB0aGV5IHdpbGwgIGNvbnRpbnVlIHdpdGggdGhlIG9s ZCBzYSBvciBicmluZyBkb3duIHRoZSBzYSBiYXNlZCBvbiB0aGUgDQphZG1pbmlzdHJhdGl2ZSBj b250cm9sLg0KDQovLyBJJ20gTk9UIHN1cmUgd2hldGhlciBjb250aW51aW5nIHdpdGggdGhlIG9s ZCBzYSB3aWxsIGNhdXNlIHNvbWUgDQpzZWN1cml0eSByaXNrcyBvciBub3QuIA0KIA0KdGhlIHN5 bmMgdGltZSB3aXRoaW4gYSBjbHVzdGVyICBhbW9uZyBhIGFuZCBiIG1pZ2h0IGJlIHNhbWUgb3Ig ZGlmZmVyZW50IA0KZHVlIHRvIHdoaWNoIG9uZSBvZiB0aGVtIHdvdWxkIGhhdmUgb2xkIHNhIGFu ZCBhbm90aGVyIHdvdWxkIGhhdmUgbmV3IHNhLiANCmluIHN1Y2ggDQpjYXNlcyBib3RoIHRoZSBz YSB3b3VsZCBiZSBkZWxldGVkIGV2ZW50dWFsbHkgYW5kIG5ldyBzYSBpcyBlc3RhYmxpc2hlZC4N CiANCm9yIGV2ZW4gaWYgc3luYyB0aW1lcyBhcmUgZGlmZmVyZW50LCBvbmUgd291bGQgaGF2ZSBv bGQgc2Egd2l0aCBsZXNzZXIgDQptZXNzYWdlIGlkJ3MgYW5kIG90aGVyIGhhdmUgc2FtZSBvbGQg c2Egd2l0aCBoaWdoZXIgbWVzc2FnZSBpZCdzIGFuZCB0aGVuIA0KYm90aCB3aWxsIA0Kc3RhcnQg ZnJvbSB0aGUgaGlnaGVyIG1lc3NhZ2UgaWQgdmFsdWVzLg0KIA0KUmVnYXJkcywNCmthbHlhbmkN CiANCkZyb206IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgDQp6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24NClNlbnQ6IFdl ZG5lc2RheSwgSnVuZSAyMCwgMjAxMiA3OjQ0IEFNDQpUbzogS2FseWFuaSBHYXJpZ2lwYXRpIChr YWdhcmlnaSkNCkNjOiBpcHNlY0BpZXRmLm9yZzsgaXBzZWMtYm91bmNlc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZvciBJS0V2 Mi9JUHNlYyBIaWdoIA0KQXZhaWxhYmxpdHkNCiANCg0KSGkgS2FseWFuaSwgDQoNCg0KDQpGaXJz dCBJJ2QgbGlrZSB0byBtYWtlIHNvbWUgY2xhcmlmaWNhdGlvbnMgYWNjb3JkaW5nIHRvIHlvdXIg Y29tbWVudHMsIGFuZCANCmxlYXZlIG90aGVyIGNsYXJpZmljYXRpb25zIHRvIGZ1cnRoZXIgZGlz Y3Vzc2lvbnMuIA0KDQoxLiBDbGFyaWZpY2F0aW9uIGZvciBjYXNlIEMgaW4gU2VjdGlvbiAyLjIg DQooY2FzZSBDIGlzIHRoZSBtb3N0IHRyb3VibGVzb21lIGluIHRoaXMgc2VjdGlvbiBJTU8uU28g SSdkIGxpa2UgdG8gY2xhcmlmeSANCml0LikgDQoxLjEgTm90YXRpb24gZm9yIGNhc2UgQyBpbiBT ZWN0aW9uIDIuMiANCg0KeDogdGhlIG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9tIHRo ZSBwZWVyIHBhcnR5IA0KeTogdGhlIG5leHQgc2VuZGVyIG1lc3NhZ2UgSUQgDQoNCmEwOiB0aGUg b2xkIGFjdGl2ZSBjbHVzdGVyIG1lbWJlciANCmExOiB0aGUgbmV3IGFjdGl2ZSBjbHVzdGVyIG1l bWJlciANCmI6ICB0aGUgcGVlciANCg0KDQphMFt0XS54ICBhMCdzIG1heGltdW0gbWVzc2FnZSBJ RCByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgdW50aWwgdGltZSB0IA0KYTBbdF0ueSAgYTAncyBu ZXh0IHNlbmRlciBtZXNzYWdlIElEICBhdCB0aW1lIHQgDQoNCmExW3RdLnggIGExJ3MgbWF4aW11 bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiAgdW50aWwgdGltZSB0IA0KYTFb dF0ueSAgYTEncyBuZXh0IHNlbmRlciBtZXNzYWdlIElEICBhdCB0aW1lIHQgDQoNCmJbdF0ueCAg IGIncyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3RlciAgdW50aWwg dGltZSB0IA0KYlt0XS55ICAgYidzIG5leHQgc2VuZGVyIG1lc3NhZ2UgSUQgYXQgdGltZSB0IA0K DQoNClQwOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBsYXN0IHN5bmNocm9uaXphdGlvbiBiZXR3 ZWVuIGEwIGFuZCBhMSBpcyANCmNhcnJpZWQgb3V0IA0KDQpUMTogQXQgdGhpcyB0aW1lIHBvaW50 LCB0aGUgZmFpbG92ZXIgZXZlbnQgb2NjdXJzIA0KDQpUMjogQXQgdGhpcyB0aW1lIHBvaW50LCB0 aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYiANCnN0YXJ0cyAN Cg0KDQpUMzogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRp b24gYmV0d2VlbiBhMSBhbmQgYiANCmVuZHMgDQoNClNXOiB0aGUgc2VuZGVyIHdpbmRvdyBzaXpl IG9mIHRoZSBjbHVzdGVyLiBMZXQncyBhc3N1bWUgU1cgaXMgNS4gDQoNCi0tLS1UMC0tLS0tLS0t VDEtLS0tLS0tLS0tVDItLS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIA0KDQoNCjEuMiBBbmFseXNpcyBmb3IgY2FzZSBDIGluIFNlY3Rpb24gMi4yIA0KDQoN CldlIGtub3cgdGhhdDogDQoNCmExW1QwXS54ID09IGEwW1QwXS54IA0KYTFbVDBdLnkgPT0gYTBb VDBdLnkgDQooVGhlIHJlYW9uIGlzIHRoYXQgYXQgVDAsIHRoZSBzeW5jaHJvbml6YXRpb24gYmV0 d2VlbiBhMCBhbmQgYTEgaXMgY2FycmllZCANCm91dC4pIA0KDQpBbmQgDQoNCg0KYTFbVDFdLngg PT0gYTBbVDBdLnggDQphMVtUMV0ueSA9PSBhMFtUMF0ueSANCg0KQW5kIA0KDQphMVtUMl0ueCA9 PSBhMFtUMF0ueCANCmExW1QyXS55ID09IGEwW1QwXS55IA0KDQooVGhlIHJlYW9uIGlzIHRoYXQg ZnJvbSBUMCB0byBUMiwgdGhlIHN0YXRlIGRhdGEgb2YgYTEga2VlcHMgdW5jaGFuZ2VkLikgDQoN CkFjY29yZGluZyB0byBSRkMgNjMxMSwgDQoNCiJNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNz YWdlIElEIHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gIE0xIA0KTVVTVCBiZSBjaG9zZW4gc28g dGhhdCBpdCBpcyBsYXJnZXIgdGhhbiBhbnkgdmFsdWUga25vd24gdG8gaGF2ZSANCmJlZW4gdXNl ZC4gIEl0IGlzIFJFQ09NTUVOREVEIHRvIGluY3JlbWVudCB0aGUga25vd24gdmFsdWUgYXQgDQps ZWFzdCBieSB0aGUgc2l6ZSBvZiB0aGUgSUtFIHNlbmRlciB3aW5kb3cuIiANCg0KQXQgVDIsIHRo ZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBjYW4gc2V0IE0xPWExW1QyXS55ICsgU1cuIA0KDQoNCkFu ZCANCg0KIk0yIE1VU1QgYmUgYXQgbGVhc3QgdGhlIGhpZ2hlciBvZiB0aGUgcmVjZWl2ZWQgTTEs IGFuZCBvbmUgbW9yZSANCiAgICAgIHRoYW4gdGhlIGhpZ2hlc3Qgc2VuZGVyIHZhbHVlIHJlY2Vp dmVkIGZyb20gdGhlIGNsdXN0ZXIuICBUaGlzIA0KICAgICAgaW5jbHVkZXMgYW55IHByZXZpb3Vz IHJlY2VpdmVkIHN5bmNocm9uaXphdGlvbiBtZXNzYWdlcy4iIA0KIA0KQXQgVDIsIHRoZSBwZWVy IGIgY2FuIHNldCBNMiA9IG1heChNMSwgMSArIGJbVDJdLngpLiANCg0KTTE9PWExW1QyXS55ICsg U1cgPT4gTTEgPT0gYTBbVDBdLnkgKyBTVyAgPT4gTTEgPT0gYTBbVDBdLnkgKyA1IA0KDQpTdXBw b3NlIHNvbWUgbWVzc2FnZSBleGNoYW5nZXMgKGkuZS4sIDEwIG1lc3NhZ2VzKSBoYXZlIGJlZW4g Y2FycmllZCBvdXQgDQpmcm9tIFQwIHRvIFQyLCBpdCdzIHBvc3NpYmxlIHRoYXQgYltUMl0ueCAr IDEgPiBhMFtUMF0ueSArIDUuIA0KDQpUaGVuIHRoZSBwZWVyIGIgc2V0cyBNMj0xICsgYltUMl0u eC4gDQoNCkF0IFQzLCB3aGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSByZWNlaXZlcyB0aGUg TWVzc2FnZSBJRCANCnN5bmNocm9uaXphdGlvbiByZXNwb25zZSBmcm9tIHRoZSBwZWVyIGIsIGEx ICBzZXRzIGExW1QzXS55ID0gTTIuIA0KDQphMVtUM10ueSA9PSBNMiA9PiBhMVtUM10ueSA9PTEg KyBiW1QyXS54LiANCg0KDQpBdCBUMiwgYTBbVDJdLnkgY291bGQgYmUgYltUMl0ueCs1LiANCihU aGUgcmVhb24gaXMgdGhhdCBhMCdzIHNlbnQgbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBiW1Qy XS54KzEsIA0KYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1IG1heSBOT1Qg aGF2ZSByZWFjaGVkIHRvIHRoZSBwZWVyIA0KYi4pIA0KDQpUaGlzIG1lYW5zIGExW1QzXS55IDwg YTBbVDJdLnkuIA0KDQpUaGlzIG1lYW5zIHRoZSBmaXJzdCBmaXZlIG1lc3NhZ2VzIHNlbnQgYnkg dGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHdpbGwgDQpoYXZlIE1lc3NhZ2UgSURzIGJbVDJdLngr MSwgYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1LiANCg0KU3VwcG9zZSBh ZnRlciBUMywgdGhlIHBlZXIgcmVjZWl2ZXMgdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwJ3Mgc2Vu dCANCm1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCANCmJbVDJdLngrMixiW1Qy XS54KzMsYltUMl0ueCs0LGJbVDJdLngrNSwgYW5kIHNlbmRzIHJlc3BvbnNlIG1lc3NhZ2VzLiAN Cg0KQWZ0ZXIgdGhhdCwgdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHNlbmRzIHRoZSBmaXJzdCBm aXZlIHJlcXVlc3QgbWVzc2FnZXMgDQp3aXRoIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltUMl0u eCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1LiANCkFmdGVyIHJlY2V2aW5nIHRoZXNl IHJlcXVlc3QgbWVzc2FnZXMsIHRoZSBwZWVyIGIgd2lsbCByZWdhcmRzIHRoZXNlIA0KcmVxdWVz dHMgYXMgcmVzZW50IG1lc3NhZ2VzLCBhbmQgcmV0dXJucyByZXNwb25zZSBtZXNzYWdlcyBmb3Ig DQpyZXF1ZXN0cyBvZiAgYTAncyBzZW50IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0u eCsxLCANCmJbVDJdLngrMixiW1QyXS54KzMsYltUMl0ueCs0LGJbVDJdLngrNSB0byBhMS4gDQoo TXkgdW5kZXJzdGFuZGluZywgYWNjb3JkaW5nIHRvIFJGQyA1OTk2LCBpcyB0aGF0IHRoZSBwZWVy IHNob3VsZCB0cmVhdCANCnRoZSBuZXcgYWN0aXZlIG1lbWJlcidzIHJlcXVlc3QgbWVzc2FnZXMg YXMgcmVzZW50IHJlcWV1c3RzLiApIA0KICAgICAgICAgICAgICAgcmUtc2VudCANCkFzIGEgcmVz dWx0LCB0aGUgcGVlciBiIHJlY2VpdmVzIGFjY2VwdGFibGUgYnV0IG1pc21hdGNoZWQgcmVzcG9u c2VzIGZvciANCml0cyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYTFbVDJdLngr MSwgDQphMVtUMl0ueCsyLGExW1QyXS54KzMsYTFbVDJdLngrNCxhMVtUMl0ueCs1LiANCiANCkZv ciBhIGNvbmNyZXRlIGV4YW1wbGUsIGxldCdzIGFzc3VtZTogDQoNCmExW1QwXS54ID09IGEwW1Qw XS54ID0gOSANCmExW1QwXS55ID09IGEwW1QwXS55ID0gMjAgDQoNCmJbVDBdLnggPSAxOSANCmJb VE9dLnkgPSAxMCANCg0KRnJvbSBUMCB0byBUMSwgdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwIGhh dmUgc2VudCAxMCByZXF1ZXN0IG1lc3NhZ2VzIHRvIA0KdGhlIHBlZXIgYiwgYW5kIDUgbWVzc2Fn ZXMgaGF2ZSBiZWVuIHJlY2VpdmVkIGFuZCBhY2tub3dsZWRnZWQgYnkgdGhlIHBlZXIgDQpiLiAN Cg0KVGhpcyBtZWFucyB0aGF0IGEwW1QyXS55ID0gMzAsIGJbVDJdLnggPSAyNC4gTm90ZSByZXF1 ZXN0IG1lc3NhZ2VzIHdpdGggDQpNZXNzYWdlIElEIDI1LDI2LDI3LDI4LDI5IGhhdmUgYmVlbiBz ZW50IGJ5IHRoZSBvbGQgYWN0aXZlIG1lbWJlciBhMCwgYnV0IA0KaGF2ZSBOT1QgcmVhY2hlZCB0 aGUgcGVlciBiMC4gKFRoZSBzZW5kZXIgd2luZG93IHNpemUgb2YgdGhlIGNsdXN0ZXIgaXMgDQo1 LikgDQoNCg0KQWNjb3JkaW5nIHRvIFJGQyA2MzExLCANCg0KIk0xIGlzIHRoZSBuZXh0IHNlbmRl cidzIE1lc3NhZ2UgSUQgdG8gYmUgdXNlZCBieSB0aGUgbWVtYmVyLiAgTTEgDQpNVVNUIGJlIGNo b3NlbiBzbyB0aGF0IGl0IGlzIGxhcmdlciB0aGFuIGFueSB2YWx1ZSBrbm93biB0byBoYXZlIA0K YmVlbiB1c2VkLiAgSXQgaXMgUkVDT01NRU5ERUQgdG8gaW5jcmVtZW50IHRoZSBrbm93biB2YWx1 ZSBhdCANCmxlYXN0IGJ5IHRoZSBzaXplIG9mIHRoZSBJS0Ugc2VuZGVyIHdpbmRvdy4iIA0KIC8v IE0xIGlzIHNvbWV3aGF0IHJlbGV2YW50IHRvIGFueSB2YWx1ZSBrbm93biB0byBoYXZlIGJlZW4g dXNlZCAoIE1lc3NhZ2UgDQpJRHMgb2YgcmVxdWVzdCBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBz ZW50IHRvIHRoZSBwZWVyIGIuICkNCg0KTTEgPT0gYTFbVDJdLnkgKyBTVyA9PSAyMCArIDUgPT0g MjUgDQooYTFbVDJdLnkgPT0gYTFbVDBdLnkgPT0gMjApIA0KDQpBbmQgDQoiTTIgTVVTVCBiZSBh dCBsZWFzdCB0aGUgaGlnaGVyIG9mIHRoZSByZWNlaXZlZCBNMSwgYW5kIG9uZSBtb3JlIA0KdGhh biB0aGUgaGlnaGVzdCBzZW5kZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4gIFRo aXMgDQppbmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uIG1lc3Nh Z2VzLiIgDQoNCi8vICBVbnRpbCBUMCwgTTIgaXMgc29tZXdoYXQgcmVsZXZhbnQgdG8gdGhlIGhp Z2hlc3Qgc2VuZGVyIHZhbHVlIHJlY2VpdmVkIA0KZnJvbSB0aGUgY2x1c3RlciANCihNZXNzYWdl IElEcyBvZiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIHJlY2VpdmVkIGZyb20gdGhl IGNsdXN0ZXIuIA0KIE0yIGlzIHNvbWV3aGF0IHJlbGV2YW50IGJbVDJdLngpDQoNCiANCk0yID09 IG1heHtNMSwgMSArIGJbVDJdLngpPT0gbWF4KDI1LDErMjQpID09IDI1IA0KDQpBZnRlciB0aGUg bmV3IGFjdGl2ZSBtZW1iZXIgYTEgcmVjZWl2ZXMgTTIsIGExIHNldHMgYTFbVDJdLnkgPT0gMjUg PCANCmEwW1QyXS55ID09IDMwLiANCg0KVGhlIE1lc3NhZ2UgSUQgZm9yIHRoZSBuZXcgYWN0aXZl IG1lbWJlciBhMSBudW1iZXJzIGZyb20gMjUuIA0KDQpUaGUgZmlyc3QgZml2ZSBNZXNzYWdlIElE cyBhcmUgMjUsIDI2LCAyNywyOCwyOS4gDQoNCldoZW4gdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGEx IHNlbmRzIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCBNZXNzYWdlcyBJRHMgMjUsIA0KMjYsMjcsMjgs MjksIHNpbmNlIHRoZSBwZWVyIGIgaGFzIHByb2Nlc3NlZCB0aGUgcmVxdWVzdCBtZXNzYWdlIHdp dGggdGhlIA0Kc2FtZSBNZXNzYWdlIElEcywgdGhlIHBlZXIgYiB3aWxsIHJldHVybiByZXNwb25z ZSBtZXNzYWdlcyBmb3IgdGhlIHJlcXVlc3QgDQptZXNzYWdlcyBmcm9tIHRoZSBvbGQgYWN0aXZl IG1lbWJlciBhMC4gDQoNClRoZW4gYTEgcmVjZWl2ZXMgYWNjZXB0YWJsZSBidXQgbWlzbWFjdGhl ZCByZXNwb25zZSBtZXNzYWdlcy4gDQoNCiANCjIuIENsYXJpZmljYXRpb25zIGZvciB0aGUgc2lt dWx0YW5lc291cyBmYWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjMgDQpGb3IgdGhlIHNpbXVs dGFuZW91cyBmYWlsb3ZlciwgY2FzZSBGIGlzIHRoZSBtb3N0IGRldmFzdGF0aW5nIElNTy4gU28g SSdkIA0KbGlrZSB0byBjbGFyaWZ5IGl0IGZpcnN0LiANCjIuMSBOb3RhdGlvbiBmb3IgdGhlIHNp bXVsdGFuZXNvdXMgZmFpbG92ZXIgY2FzZSBGIGluIFNlY3Rpb24gMi4zIA0KDQoNCmEwOiB0aGUg b2xkIGFjdGl2ZSBjbHVzdGVyIG1lbWJlciBvZiB0aGUgY2x1c3RlciBhIA0KYTE6IHRoZSBuZXcg YWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGEgDQpiMDogdGhlIG9sZCBhY3Rp dmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYiANCmIxOiB0aGUgbmV3IGFjdGl2ZSBj bHVzdGVyIG1lbWJlciBvZiB0aGUgY2x1c3RlciBiIA0KDQoNClQwOiBBdCB0aGlzIHRpbWUgcG9p bnQsIHRoZSBsYXN0IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGEwL2IwIGFuZCBhMS9iMSANCmlz IGNhcnJpZWQgb3V0LCANCg0KVDE6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIHNpbXVsdGFuZW91 cyBmYWlsb3ZlciBldmVudCBvY2N1cnMgDQoNClQyOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBN ZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiMSANCnN0YXJ0cyANCg0K DQpUMzogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24g YmV0d2VlbiBhMSBhbmQgYjEgDQplbmRzIA0KDQoNCg0KLS0tLVQwLS0tLS0tLS1UMS0tLS0tLS0t LS1UMi0tLS0tLS0tLS1UMy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoN CiANCjIuMiBBbmFseXNpcyBmb3IgdGhlIHNpbXVsdGFuZXNvdXMgZmFpbG92ZXIgY2FzZSBGIGlu IFNlY3Rpb24gMi4zIA0KDQoNCkl0J3MgcG9zc2libGUgdGhhdCBmcm9tIFQwIHRvIFQxLCBhMCBh bmQgYjAgZGVsZXRlcyB0aGUgb2xkIElLRSBTQSBzYTAgYW5kIA0KY3JlYXRlcyBhIG5ldyBJS0Ug U0Egc2ExLiANCkJ1dCBhdCBUMiwgYTEgYW5kIGIxIGRvIE5PVCBrbm93IHdoYXQgaGFzIGhhcHBl bmVkIGZyb20gVDAgYW5kIFQxLCBhbmQgZG8gDQpOT1Qga25vdyB0aGUgZXhpc3RhbmNlIG9mIHRo ZSBuZXcgSUtFIFNBIHNhMSwgYW5kIHVzZSB0aGUgb2xkIElLRSBTQSBzYTAgDQp0byBjYXJyeSBv dXQgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24uIA0KVGhpcyBtYXkgYnJpbmcgc29tZSBtb3Jl IHNlcmlvdXNlIHByb2JsZW0uIFNvICB3aGVuIHNpbXVsdGFuZW91cyBmYWlsb3ZlciANCm9jY3Vy cywgYSBzaW1wbGUgdHdvLXdheSBzeW5jaHJvbml6YXRpb24gIG1heSBub3QgYmUgYW4gYXBwcm9w cmlhdGUgDQpzb2x1dGlvbi4gDQoNCg0KDQoNCg0KDQoiS2FseWFuaSBHYXJpZ2lwYXRpIChrYWdh cmlnaSkiIDxrYWdhcmlnaUBjaXNjby5jb20+IA0Kt6K8/sjLOiAgaXBzZWMtYm91bmNlc0BpZXRm Lm9yZyANCjIwMTItMDYtMTQgMTk6MTQgDQoNCg0KytW8/sjLDQoiemhhbmcucnVpc2hhbkB6dGUu Y29tLmNuIiA8emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPiwgImlwc2VjQGlldGYub3JnIiA8DQpp cHNlY0BpZXRmLm9yZz4gDQqzrcvNDQoNCtb3zOINClJlOiBbSVBzZWNdIFVwZGF0ZXMgdG8gdGhl IElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMgICAgICAgIEhpZ2ggIA0KQXZhaWxhYmxp dHkNCiANCg0KDQoNCg0KDQoNCg0KDQpIaSBaaGFuZywgDQogIA0KVGhhbmtzIGZvciBnb2luZyB0 aHJvdWdoIHRoZSBSRkMgNjMxMSAuIA0KICANCkkgaGF2ZSBnb25lIHRocm91Z2ggeW91ciAgcHJv cG9zZWQgZHJhZnQgYW5kIGZlbHQgdGhhdCB0aGVyZSBpcyBzb21lIA0KY29uZnVzaW9uIHJlZ2Fy ZGluZyB0aGUgbWVzc2FnZSBpZCBjb25jZXB0IG9mIGlrZXYyLiANCiAgDQpJIGhhdmUgc2VlbiB0 aGF0IGluIHNlY3Rpb24gMi4zIHlvdSB3ZXJlIGNvbXBhcmluZyB0aGUgaGlnZXIgc2VuZGVyIHZh bHVlIA0Kb2YgeDIgd2l0aCB5Mi4gDQpUaGF0IGlzIHdyb25nLiB3aGVuIHgyIHByb3Bvc2VzIHRo ZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlkIHRvIGJlIHVzZWQgdG8gDQpzZW5kIGEgcmVxdWVzdCAs IA0KdGhlbiBvbiB5MiB5b3Ugc2hsZCB0YWxseSBpdCB3aXRoIHRoZSBuZXh0IGhpZ2hlciBtZXNz YWdlIGlkIG9mIHRoZSANCnJlcXVlc3QgdG8gYmUgcmVjaWV2ZWQgDQogICAgICAgICAgICAoYW5k IG5vdCB3aXRoIHRoZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJl IA0Kc2VudCkgDQogIA0KaW4gaWtldjIgdGhlICBtZXNzYWdlIGlkIG9mIHJlcXVlc3RzIHRvIGJl IHNlbnQgYXJlIGVudGlyZWx5IGRpZmZlcmVudCANCmZyb20gbWVzc2FnZSBpZCBvZiByZXF1ZXN0 cyB0byBiZSByZWNlaXZlZC4gDQp0aGF0IGlzIHdoeSBSRkMgc2F5cyBhIG1lc3NhZ2UgaWQgaXMg dXNlZCBmb3VyIHRpbWVzIG9uIGEgZ2l2ZW4gZGV2aWNlLiANCiAgDQoxLiBtZXNzYWdlIGlkIFgg aXMgdXNlZCB3aGlsZSBzZW5kaW5nIGEgcmVxdWVzdCANCjIuIG1lc3NhZ2UgaWQgWCBpcyB1c2Vk IHdoaWxlIHJlY2VpdmluZyB0aGUgcmVzcG9uc2UgDQozLiBtZXNzYWdlIGlkIFggaXMgdXNlZCB0 byByZWNlaXZlIGEgcmVxdWVzdCANCjQuIG1lc3NhZ2UgaWQgWCBpcyB1c2VkIHRvIHNlbmQgYSBy ZXNwb25zZS4gDQogIA0KICANCnBsZWFzZSBmaW5kIHRoZSBjb21tZW50cyBmb3IgZWFjaCBzZWN0 aW9uIA0KICANClNlY3Rpb24gMi4xOiAgVGhpcyBpcyBhIGtub3duIGlzc3VlIGFuZCB0aGF0IGlz IHdoeSB1c2luZyBSRkMgNjMxMSwgIHdlIA0KYXJlIHN5bmNocm9uaXNpbmcgdGhlIG1lc3NhZ2Ug aWQncyANCiAgDQpTZWN0aW9uIDIuMjogVGhlIHBlZXIgaXMgYXNzdW1lZCB0byBiZSBwcm9wZXIg YW5jaG9yIHBvaW50IHdoaWNoIGhhcyANCmNvcnJlY3QgaW5mbyBvZiBtZXNzYWdlIGlkIG9mIHJl cXVlc3RzIHNlbnQgYW5kIHJlY2lldmVkLCANCmV2ZW4gd2hlbiBwZWVyIGlzIGNsdXN0ZXIgbWVt YmVyICwgYW1vbmcgdGhlIHR3byBkZXZpY2VzIG9uZSBvZiB0aGVtIHdvdWxkIA0KYmUgbGVzcyB3 cm9uZyBhbmQgaGF2ZSBoaWdoZXIgYWNjdXJhdGUgdmFsdWVzIG9mIG1lc3NhZ2UgaWQncyAuIA0K c28gd2UgcGljayB1cCB0aGF0IHZhbHVlLiBJIGRvbnQgc2VlIGFueSBpc3N1ZSBoZXJlLiANCiAg DQpTZWN0aW9uIDIuMzogRmlyc3Qgb2YgYWxsIHRoZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW4g TTEgYW5kIFAxLiANCm9uIGEgZ2l2ZW4gZGV2aWNlLiANCi0tLSBNMSBpcyB0aGUgcHJvcG9zZWQg bWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSBzZW50IA0KICAgIFAxIGlzIHRoZSBwcm9w b3NlZCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHJlY2VpdmVkLiANCiAgDQp3aGVu IHNpbXVsYXRlbm91cyBmYWlsb3ZlciBoYXBwZW5zLCB4MiBtaWdodCBoYXZlIGhpZ2hlciB2YWx1 ZSBvZiBNMSB3aGVuIA0KY29tcGFyZWQgdG8geTIgLCBidXQgeDIgbWlnaHQgaGF2ZSBsb3dlciB2 YWx1ZSBvZiBQMSB3aGVuIGNvbXBhcmVkIHRvIHkyLiANCkl0IGRvZXMnbnQgbWF0dGVyLiBib3Ro IGFyZSBpbmRlcGVuZGVudC4gd2hhdCB3ZSBldmVudHVhbGx5IGRvIGlzIGNvbXBhcmUgDQp0aGUg TTEgdmFsdWUgYWNyb3NzIHgyIGFuZCB5MiBhbmQgcGljayB0aGUgaGlnZXIgb25lLiANCnNhbWUg cHJvY2VzcyBpcyByZXBlYXRlZCBmb3IgUDEuIA0KICANCmNhc2UgMSB0byA2IGFyZSBhbHJlYWR5 IGhhbmRsZWQgYnkgYmFzaWMgaWtldjIgUkZDIC4gbGlrZSBpZiB3ZSByZWNlaXZlIA0Kc2FtZSBt ZXNzYWdlIGlkIHR3aWNlICwgdGhlbiB3ZSByZXRyYW5zbWl0IG9yIGRyb3AgaXQgaWYgaXQgaXMg b3V0c2lkZSB0aGUgDQp3aW5kb3cuIA0KICANCiAgDQpTZWN0aW9uIDM6ICAgZHVyaW5nIHNpbXVs dGFuZW91cyBmYWlsb3ZlciBib3RoIHRoZSBjbHVzdGVyIGFuZCB0aGUgcGVlciANCm1lbWJlciB3 b3VsZCBiZSBpbiB1bnJlbGlhYmxlIHN0YXRlLiANCkJvdGggb2YgdGhlbSBhcmUgd3JvbmcgLCBi dXQgb25lIG9mIHRoZW0gaXMgbGVzcyB3cm9uZyAhISEgc28gd2Ugd2FudCB0byANCnN0YXJ0IGZy b20gdGhhdCBwb2ludCB0byBzeW5jaHJvbmlzZSB0aGUgbWVzc2FnZSBpZCdzLiANCiAgDQpzbyB3 ZSBhcmUgYWxsb3dpbmcgYm90aCB0aGUgbWVtYmVycyB0byBhbm5vdW5jZSB0aGVpciBtZXNzYWdl IGlkJ3MgYW5kIA0KdGhlbiBldmVudHVhbGx5IHdlIHdvdWxkIHN5bmNocm9uaXNlIHRvIHRoZSBo aWdoZXIgbnVtYmVyLiANCkkgZG9udCBzZWUgYW55IGZsYXcgaGVyZS4gUGxlYXNlIGV4cGxhaW4g d2l0aCBhbiBleGFtcGxlLiANCiAgDQpCeSB5b3VyIHByb3Bvc2FsIGluIGNhc2Ugb2Ygc2ltdWx0 YW5lb3VzIGZhaWxvdmVyLCBib3RoIHRoZSBjbHVzdGVyIGFuZCANCnBlZXIgd2lsbCBiZSBpbiBV TlNZTkVEIHN0YXRlIGFuZCANCmJvdGggd291bGQgZW5kIHVwIHNlbmRpbmcgYW5kIHJlamVjdGlu ZyB0aGUgc3luY2hyb25pc2F0aW9uIHJlcXVlc3QuIA0KVGhpcyB3b3VsZCBsZWFkIHRvIHJlcGVh dGVkIHN5bmNocm9uaXNhdGlvbiBlZmZvcnRzIGFuZCB0aGUgcHJvYmxlbSBvZiANCm1lc3NhZ2Ug c3luY2hyb25pc2F0aW9uIGlzIG5ldmVyIHNvbHZlZC4gDQogIA0Kc28gVU5TWU5FRCBzdGF0ZSBp cyBub3QgcmVxdWlyZWQuIA0KICANClNlY3Rpb24gNDogDQogIA0KSSBmZWVsIHRoYXQgUkZDIDYz MTEgYWxyZWFkeSBzb2x2ZXMgdGhlIG1lc3NhZ2UgaWQgc3luY2hyb25pc2F0aW9uIGlzc3VlLiAN CkkgZG9udCB0aGluayB3ZSBuZWVkIHRvIGluY3JlbWVudCBNMSBieSBkb3VibGUgdGhlIHdpbmRv dyBzaXplIGFzIHByb3Bvc2VkIA0KYnkgeW91LiANClBsZWFzZSBzdXBwb3J0IHlvdXIgcHJvcG9z YWwgd2l0aCBhbiBleGFtcGxlIHdpdGggbWVzc2FnZSBpZCB2YWx1ZXMgb2YgDQpudW1iZXJzIGlu c3RlYWQgb2YgdmFyaWFibGVzLiANCkxpa2UgTTEgaXMgMyAsIE0yIGlzIDQgZXRjIGV0Yy4gDQog IA0KTnVtYmVycyBtYWtlIGl0IG1vcmUgY2xlYXIuIA0KICANCnJlZ2FyZHMsIA0Ka2FseWFuaSAN CiAgDQpGcm9tOiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KemhhbmcucnVpc2hhbkB6dGUuY29tLmNuDQpTZW50OiBN b25kYXksIEp1bmUgMTEsIDIwMTIgNzozNiBBTQ0KVG86IGlwc2VjQGlldGYub3JnDQpTdWJqZWN0 OiBbSVBzZWNdIFVwZGF0ZXMgdG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMg SGlnaCANCkF2YWlsYWJsaXR5IA0KICANCg0KDQpEZWFyIEFsbCwgDQoNCiBJJ3ZlIHN1Ym1pdHRl ZCBhIG5ldyBkcmFmdCAiIFVwZGF0ZXMgdG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgDQpJS0V2 Mi9JUHNlYyBIaWdoIEF2YWlsYWJsaXR5Ii4gVGhpcyBkcmFmdCBhbmFseXplcyBzb21lIGlzc3Vl cyBpbiBSRkMgDQo2MzExLCANCmFuZCBwcm9wb3NlcyBzb21lIHVwZGF0ZXMuIExvb2sgZm9yd2Fy ZCB0byB5b3VyIGNvbW1lbnRzLiANCg0KDQpCUiwgDQoNClJ1aXNoYW4gWmhhbmdfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0 DQpJUHNlY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHNlYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQ c2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQo= --=_alternative 00104BB748257A24_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEthbHlhbmk8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSBzZWUgdGhlIGlu bGluZSBjbGFyaWZpY2F0aW9ucy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkJSLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+UnVpc2hhbjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj4mcXVvdDtLYWx5YW5pIEdhcmlnaXBhdGkNCihrYWdhcmlnaSkmcXVvdDsg Jmx0O2thZ2FyaWdpQGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtpcHNlYy1ib3VuY2VzQGlldGYub3JnPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDYtMjAgMTg6MjY8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7emhhbmcucnVpc2hhbkB6dGUuY29tLmNuJnF1b3Q7DQombHQ7emhhbmcucnVpc2hhbkB6 dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7aXBzZWNAaWV0Zi5vcmcmcXVv dDsgJmx0O2lwc2VjQGlldGYub3JnJmd0OywNCiZxdW90O2lwc2VjLWJvdW5jZXNAaWV0Zi5vcmcm cXVvdDsgJmx0O2lwc2VjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW0lQc2VjXSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24NCmZvciBJS0V2Mi9JUHNl YyBIaWdoIEF2YWlsYWJsaXR5PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SGkgWmhhbmcsPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48 Yj5Gb3IgQW5hbHlzaXMgMSA8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0 OTdkIGZhY2U9IkNhbGlicmkiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YTBbdF0ueCAmbmJzcDthMCdzIG1heGltdW0NCm1lc3NhZ2Ug SUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBiIHVudGlsIHRpbWUgdCAmbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YTBbdF0ueSAmbmJz cDthMCdzIG5leHQgc2VuZGVyDQptZXNzYWdlIElEICZuYnNwO2F0IHRpbWUgdCA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkkgdGhpbmsg dGhlcmUgaXMgY29uZnVzaW9uDQphYm92ZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SSBndWVzcyB3aGF0IHUgYWN0dWFsbHkgd2FudGVkDQp0 byBjb252ZXkgaXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj5hMFt0XS54ICZuYnNwO2EwJ3MgbWF4aW11bQ0KbWVzc2FnZSBJRCBvZiB0 aGUgcmVxdWVzdCBzZW50IGFuZCBvcmRlcmx5IHJlc3BvbnNlIHJlY2VpdmVkIGZyb20gdGhlIHBl ZXINCmIgdW50aWwgdGltZSB0ICwgc2F5IGlmIGEgaGFzIHJlY2VpdmVkIHJlc3BvbnNlcyBmb3Ig MiBhbmQgMyBhbmQgNSAmbmJzcDssDQp0aGlzIHZhbHVlIGlzIDMuIFNvIG5vdyB0aGUgd2luZG93 IHdvdWxkIGJlIDQtOCAoaW5jbHVzaXZlKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hMFt0XS55ICZuYnNwO2EwJ3MgbmV4dCByZXF1ZXN0DQpt ZXNzYWdlIElEIHRvIGJlIHNlbnQgYXQgdGltZSB0ICwgdGhpcyB2YWx1ZSBpcyA2ICwgaWYgaXQg aGFzIGFscmVhZHkgc2VudA0KdGhlIHJlcXVlc3RzIDIsMyw0LDUsIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Ylt0XS54ICZuYnNwOyBi J3MgbWF4aW11bQ0KbWVzc2FnZSBJRCBvZiB0aGUgb3JkZXJseSByZXNwb25zZSBzZW50IHRvIGNs dXN0ZXIgJm5ic3A7dW50aWwgdGltZSB0ICwNCmlmIGl0IGhhcyBzZW50IHJlc3BvbnNlIHRvIDIs MyBhbmQgNSBpZCByZXF1ZXN0cyAsIGl0IGlzIHN0aWxsIDMuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmJbdF0ueSAmbmJzcDsgYidzIG5leHQg bWVzc2FnZQ0KaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgcmVjZWl2ZWQsIHdoaWNoIGlzIDYgPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Ly8g Jm5ic3A7QSBjbGFyaWZpY2F0aW9uIGFib3V0DQp4OiAmbmJzcDthMFt0XS54IGlzIHJlbGV2YW50 IHRvIHRoZSBtYXhpbXVtIE1lc3NhZ2UgSUQgb2YgdGhlIHJlY2VpdmVkDQpyZXF1ZXN0IG1lc3Nh Z2UgZm9yIHRoZSBvcHBvc2l0ZSBJS0UgdjIgcGFydHkuIFNheSAmbmJzcDt1bnRpbCB0aW1lIFQw LA0KYTAgaGFzIHJlY2VpdmVkIDUgLy9yZXF1ZXN0IG1lc3NhZ2VzIGZyb20gYiwgYW5kIHRoZSBN ZXNzYWdlIElEcyBhcmUgMSwNCjIsIDMsIDQsIDUuIFRoZW4gYTBbVDBdLnggPT0gNS4gU2F5IHVu dGlsIHRpbWUgVDAsIGIgaGFzIHJlY2VpdmVkIDQgcmVxdWVzdA0KbWVzc2FnZXMgZnJvbSBhLCBh bmQgdGhlIE1lc3NhZ2VzIElEcyBhcmUgLy80LDUsIDYsIDcuIFRoZW4gYltUMF0ueCA9PQ0KNy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4vL0FjdHVh bGx5LCAmbmJzcDt4IGlzIGlycmVsZXZhbnQNCnRvIHkuICZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SSBndWVzcyB0aGUgZXhh bXBsZSBoYXMgd3JvbmcNCnZhbHVlcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmlmIHdpbmRvdyBzaXplIGlzIDUgPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj50aGVuIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Rm9y IGEgY29uY3JldGUgZXhhbXBsZSwgbGV0J3MNCmFzc3VtZTogPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hMVtUMF0ueCA9PSBhMFtUMF0u eCA9IDkNCi0tLS0tLS0tLS0tLS0tLWhvdyBjYW4geCBhbmQgeSB2YXJ5IGJ5IDEwIHdoZW4gdGhl IHdpbmRvdyBzaXplIGlzIDUgJm5ic3A7PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 cmVkIGZhY2U9IkNhbGlicmkiPi8vIFVudGlsIFQwLCBhMCBoYXMgcmVjZWl2ZWQNCjkgcmVxdWVz dCBNZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIDMsNCwgNSwgNiw3LDgsOSBmcm9tIHRo ZSBwZWVyDQpiIC4gU28gdGhlIGEwW1QwXS54ID09OSA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YTFbVDBdLnkgPT0gYTBb VDBdLnkgPSAyMA0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkNhbGli cmkiPi8vDQombmJzcDtVbnRpbCBUMCwgYTAgaGFzIHNlbnQgMTkgcmVxdWVzdCBNZXNzYWdlcyB3 aXRoIE1lc3NhZ2UgSURzIDEsIDIsDQozLDQsIDUsIC4uLiwxOSB0byB0aGUgcGVlciBiLiBTbyB0 aGUgYTBbVDBdLnkgJm5ic3A7PT0yMDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9cmVk IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj5iW1QwXS54ID0gMTkgJm5ic3A7IC0tIHNhbWUNCmlzIHRoZSBj YXNlIGhlcmUuLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkNhbGli cmkiPi8vIFVudGlsIFQwLCB0aGUgcGVlciBiIGhhcyByZWNlaXZlZA0KMTkgcmVxdWVzdCBNZXNz YWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIDMsLi4uLDE5IGZyb20gdGhlIG9sZCBhY3RpdmUN Cm1lbWJlciBhMCAuIFNvIHRoZSBiW1QwXS54ID09MTkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmJbVE9dLnkgPSAxMCA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4vLyBVbnRpbCBUMCwgdGhlIHBl ZXIgYiBoYXMgc2VudA0KOSByZXF1ZXN0IE1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgMSwgMiwg MywuLi4sOSB0byB0aGUgb2xkIGFjdGl2ZSBtZW1iZXINCmEwIC4gU28gdGhlIGJbVDBdLnkgPT05 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+UGxlYXNlIGFkanVzdCB0aGVzZSB2YWx1ZXMNCmFuZCB0aGVuIHRoZXJlIHdpbGwgYmUgbm8g aXNzdWVzIGFzIG1lbnRpb25lZCBieSB5b3UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hbHNvIHBsZWFzZSByZWZlciB0byB0aGUNCnNl Y3Rpb24gOC4xIGFuZCA5IG9mIHRoZSBSRkMgNjMxMSB3aGljaCBzYXlzIHRoYXQgd2hlbiB0aGUg d2luZG93IG1vdmVzDQp0byB0aGUgc3luY2hyb25pc2VkIHZhbHVlLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hbGwgdGhlIG9sZCBwZW5kaW5n IHJlcXVlc3RzDQphbmQgdG8tYmUgcmV0cmFuc21pdHRlZCByZXNwb25zZXMgc2hvdWxkIGJlIGRl bGV0ZWQuIFNvIHRoZSBiZWxvdyBpc3N1ZQ0Kd2lsbCBub3QgaGFwcGVuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzAwNzBjMCBmYWNlPSJDYWxpYnJpIj48aT5XaGVuIHRoZSBu ZXcgYWN0aXZlIG1lbWJlcg0KYTEgc2VuZHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2Vz IElEcyAyNSwgMjYsMjcsMjgsMjksIHNpbmNlIHRoZQ0KcGVlciBiIGhhcyBwcm9jZXNzZWQgdGhl IHJlcXVlc3QgbWVzc2FnZSB3aXRoIHRoZSBzYW1lIDwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+PGk+TWVzc2FnZSBJRHMsIHRoZSBwZWVy DQpiIHdpbGwgcmV0dXJuIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVxdWVzdCBtZXNzYWdl cyBmcm9tIHRoZSBvbGQgYWN0aXZlDQptZW1iZXIgYTAuIDwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+PGk+Jm5ic3A7PC9pPjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNzBjMCBmYWNlPSJDYWxpYnJpIj48aT5UaGVuIGEx IHJlY2VpdmVzIGFjY2VwdGFibGUNCmJ1dCBtaXNtYWN0aGVkIHJlc3BvbnNlIG1lc3NhZ2VzLjwv aT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+ PGk+Jm5ic3A7PC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj48Yj5Gb3IgQW5hbHlzaXMgMjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoaXMgaXMgdGhlIHByb2JsZW0gb2Yg YmFzaWMNCkhBIHNpbXVsYXRlbm91cyBmYWlsLW92ZXIgYW5kIG5vdCBqdXN0IGFib3V0IG1lc3Nh Z2UgSUQgc3luY2hyb25pc2F0aW9uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+d2hlbiBib3RoIG9mIHRoZSBkZXZpY2VzDQpkb26hr3Qg aGF2ZSBuZXcgc2EgYW5kIGp1c3QgaGF2ZSB0aGUgb2xkIHNhLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5UaGVuIHRoZXkgd2lsbCAmbmJzcDtj b250aW51ZQ0Kd2l0aCB0aGUgb2xkIHNhIG9yIGJyaW5nIGRvd24gdGhlIHNhIGJhc2VkIG9uIHRo ZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9cmVkIGZhY2U9IkNhbGlicmkiPi8vIEknbSBOT1Qgc3VyZSB3aGV0aGVyIGNvbnRpbnVp bmcNCndpdGggdGhlIG9sZCBzYSB3aWxsIGNhdXNlIHNvbWUgc2VjdXJpdHkgcmlza3Mgb3Igbm90 LiAmbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj50aGUgc3luYyB0aW1lIHdpdGhpbiBhIGNsdXN0ZXINCiZuYnNwO2Ftb25nIGEg YW5kIGIgbWlnaHQgYmUgc2FtZSBvciBkaWZmZXJlbnQgZHVlIHRvIHdoaWNoIG9uZSBvZiB0aGVt DQp3b3VsZCBoYXZlIG9sZCBzYSBhbmQgYW5vdGhlciB3b3VsZCBoYXZlIG5ldyBzYS4gaW4gc3Vj aCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ Y2FzZXMgYm90aCB0aGUgc2Egd291bGQgYmUNCmRlbGV0ZWQgZXZlbnR1YWxseSBhbmQgbmV3IHNh IGlzIGVzdGFibGlzaGVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+b3IgZXZlbiBpZiBzeW5jIHRpbWVzIGFyZQ0KZGlmZmVyZW50LCBv bmUgd291bGQgaGF2ZSBvbGQgc2Egd2l0aCBsZXNzZXIgbWVzc2FnZSBpZCdzIGFuZCBvdGhlciBo YXZlDQpzYW1lIG9sZCBzYSB3aXRoIGhpZ2hlciBtZXNzYWdlIGlkJ3MgYW5kIHRoZW4gYm90aCB3 aWxsIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij5zdGFydCBmcm9tIHRoZSBoaWdoZXIgbWVzc2FnZQ0KaWQgdmFsdWVzLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UmVnYXJkcyw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+a2FseWFu aTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+ IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj56aGFuZy5ydWlzaGFuQHp0ZS5jb20uY248Yj48YnI+DQpTZW50 OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDIwLCAyMDEyIDc6NDQgQU08Yj48YnI+DQpUbzo8L2I+IEth bHlhbmkgR2FyaWdpcGF0aSAoa2FnYXJpZ2kpPGI+PGJyPg0KQ2M6PC9iPiBpcHNlY0BpZXRmLm9y ZzsgaXBzZWMtYm91bmNlc0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW0lQc2Vj XSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYyL0lQc2VjDQpIaWdoIEF2 YWlsYWJsaXR5PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBLYWx5YW5p LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkZpcnN0IEknZCBsaWtlIHRv IG1ha2Ugc29tZSBjbGFyaWZpY2F0aW9ucyBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cywNCmFu ZCBsZWF2ZSBvdGhlciBjbGFyaWZpY2F0aW9ucyB0byBmdXJ0aGVyIGRpc2N1c3Npb25zLjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCjEuIENsYXJpZmljYXRpb24gZm9yIGNh c2UgQyBpbiBTZWN0aW9uIDIuMjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQooY2FzZSBDIGlzIHRoZSBt b3N0IHRyb3VibGVzb21lIGluIHRoaXMgc2VjdGlvbiBJTU8uU28gSSdkIGxpa2UgdG8gY2xhcmlm eQ0KaXQuKTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjEuMSBOb3RhdGlvbiBmb3IgY2FzZSBDIGluIFNl Y3Rpb24gMi4yPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCng6IHRoZSBtYXhpbXVtIG1lc3Nh Z2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBwYXJ0eTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQp5 OiB0aGUgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmEw OiB0aGUgb2xkIGFjdGl2ZSBjbHVzdGVyIG1lbWJlcjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMTog dGhlIG5ldyBhY3RpdmUgY2x1c3RlciBtZW1iZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYjogJm5i c3A7dGhlIHBlZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMFt0XS54ICZuYnNw O2EwJ3MgbWF4aW11bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiB1bnRpbCB0 aW1lDQp0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTBbdF0ueSAmbmJzcDthMCdzIG5leHQgc2VuZGVy IG1lc3NhZ2UgSUQgJm5ic3A7YXQgdGltZSB0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmEx W3RdLnggJm5ic3A7YTEncyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVl ciBiICZuYnNwO3VudGlsDQp0aW1lIHQgPGJyPg0KYTFbdF0ueSAmbmJzcDthMSdzIG5leHQgc2Vu ZGVyIG1lc3NhZ2UgSUQgJm5ic3A7YXQgdGltZSB0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CmJbdF0ueCAmbmJzcDsgYidzIG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9tIHRoZSBj bHVzdGVyICZuYnNwO3VudGlsDQp0aW1lIHQgPGJyPg0KYlt0XS55ICZuYnNwOyBiJ3MgbmV4dCBz ZW5kZXIgbWVzc2FnZSBJRCBhdCB0aW1lIHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KVDA6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIGxhc3Qgc3luY2hyb25pemF0aW9uIGJldHdl ZW4gYTAgYW5kIGExIGlzIGNhcnJpZWQNCm91dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClQx OiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBmYWlsb3ZlciBldmVudCBvY2N1cnM8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KVDI6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIE1lc3NhZ2UgSUQg c3luY2hyb25pemF0aW9uIGJldHdlZW4gYTEgYW5kIGINCnN0YXJ0czwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPjxicj4NClQzOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5 bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiDQplbmRzPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KU1c6IHRoZSBzZW5kZXIgd2luZG93IHNpemUgb2YgdGhlIGNsdXN0ZXIuIExldCdzIGFz c3VtZSBTVyBpcyA1LiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCi0tLS1UMC0tLS0tLS0tVDEt LS0tLS0tLS0tVDItLS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KMS4yIEFuYWx5c2lzIGZv ciBjYXNlIEMgaW4gU2VjdGlvbiAyLjI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K V2Uga25vdyB0aGF0OiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmExW1QwXS54ID09IGEwW1Qw XS54PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTFbVDBdLnkgPT0gYTBbVDBdLnk8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQooVGhlIHJlYW9uIGlzIHRoYXQgYXQgVDAsIHRoZSBzeW5jaHJvbml6YXRpb24gYmV0 d2VlbiBhMCBhbmQgYTEgaXMgY2FycmllZA0Kb3V0Lik8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpBbmQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtUMV0ueCA9PSBhMFtUMF0u eCA8YnI+DQphMVtUMV0ueSA9PSBhMFtUMF0ueTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFu ZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmExW1QyXS54ID09IGEwW1QwXS54IDxicj4NCmEx W1QyXS55ID09IGEwW1QwXS55PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KKFRoZSByZWFvbiBp cyB0aGF0IGZyb20gVDAgdG8gVDIsIHRoZSBzdGF0ZSBkYXRhIG9mIGExIGtlZXBzIHVuY2hhbmdl ZC4pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFjY29yZGluZyB0byBSRkMgNjMxMSwgPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQomcXVvdDtNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNz YWdlIElEIHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gJm5ic3A7TTE8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KTVVTVCBiZSBjaG9zZW4gc28gdGhhdCBpdCBpcyBsYXJnZXIgdGhhbiBhbnkgdmFsdWUg a25vd24gdG8gaGF2ZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiZWVuIHVzZWQuICZuYnNwO0l0IGlz IFJFQ09NTUVOREVEIHRvIGluY3JlbWVudCB0aGUga25vd24gdmFsdWUgYXQ8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KbGVhc3QgYnkgdGhlIHNpemUgb2YgdGhlIElLRSBzZW5kZXIgd2luZG93LiZxdW90 OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBdCBUMiwgdGhlIG5ldyBhY3RpdmUgbWVtYmVy IGExIGNhbiBzZXQgTTE9YTFbVDJdLnkgKyBTVy4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQpBbmQgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQomcXVvdDtNMiBNVVNUIGJlIGF0IGxl YXN0IHRoZSBoaWdoZXIgb2YgdGhlIHJlY2VpdmVkIE0xLCBhbmQgb25lIG1vcmU8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhbiB0aGUgaGlnaGVzdCBzZW5kZXIg dmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4NCiZuYnNwO1RoaXM8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2 ZWQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2VzLiZxdW90OzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCkF0IFQyLCB0aGUgcGVlciBi IGNhbiBzZXQgTTIgPSBtYXgoTTEsIDEgKyBiW1QyXS54KS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KTTE9PWExW1QyXS55ICsgU1cgPSZndDsgTTEgPT0gYTBbVDBdLnkgKyBTVyAmbmJzcDs9 Jmd0OyBNMSA9PSBhMFtUMF0ueQ0KKyA1PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU3VwcG9z ZSBzb21lIG1lc3NhZ2UgZXhjaGFuZ2VzIChpLmUuLCAxMCBtZXNzYWdlcykgaGF2ZSBiZWVuIGNh cnJpZWQgb3V0DQpmcm9tIFQwIHRvIFQyLCBpdCdzIHBvc3NpYmxlIHRoYXQgYltUMl0ueCArIDEg Jmd0OyBhMFtUMF0ueSArIDUuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlbiB0aGUgcGVl ciBiIHNldHMgTTI9MSArIGJbVDJdLnguPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkF0IFQz LCB3aGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSByZWNlaXZlcyB0aGUgTWVzc2FnZSBJRCBz eW5jaHJvbml6YXRpb24NCnJlc3BvbnNlIGZyb20gdGhlIHBlZXIgYiwgYTEgJm5ic3A7c2V0cyBh MVtUM10ueSA9IE0yLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtUM10ueSA9PSBNMiA9 Jmd0OyBhMVtUM10ueSA9PTEgKyBiW1QyXS54LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQpBdCBUMiwgYTBbVDJdLnkgY291bGQgYmUgYltUMl0ueCs1LiA8YnI+DQooVGhlIHJlYW9u IGlzIHRoYXQgYTAncyBzZW50IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBi W1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUNCm1heSBOT1QgaGF2ZSByZWFj aGVkIHRvIHRoZSBwZWVyIGIuKSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoaXMgbWVhbnMg YTFbVDNdLnkgJmx0OyBhMFtUMl0ueS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhpcyBt ZWFucyB0aGUgZmlyc3QgZml2ZSBtZXNzYWdlcyBzZW50IGJ5IHRoZSBuZXcgYWN0aXZlIG1lbWJl ciBhMSB3aWxsDQpoYXZlIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltUMl0ueCsyLGJbVDJdLngr MyxiW1QyXS54KzQsYltUMl0ueCs1LiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClN1cHBvc2Ug YWZ0ZXIgVDMsIHRoZSBwZWVyIHJlY2VpdmVzIHRoZSBvbGQgYWN0aXZlIG1lbWJlciBhMCdzIHNl bnQgbWVzc2FnZXMNCndpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0u eCszLGJbVDJdLngrNCxiW1QyXS54KzUsIGFuZA0Kc2VuZHMgcmVzcG9uc2UgbWVzc2FnZXMuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQWZ0ZXIgdGhhdCwgdGhlIG5ldyBhY3RpdmUgbWVtYmVy IGExIHNlbmRzIHRoZSBmaXJzdCBmaXZlIHJlcXVlc3QgbWVzc2FnZXMNCndpdGggTWVzc2FnZSBJ RHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCkFmdGVyIHJlY2V2aW5nIHRoZXNlIHJlcXVlc3QgbWVzc2FnZXMs IHRoZSBwZWVyIGIgd2lsbCByZWdhcmRzIHRoZXNlIHJlcXVlc3RzDQphcyByZXNlbnQgbWVzc2Fn ZXMsIGFuZCByZXR1cm5zIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciA8YnI+DQpyZXF1ZXN0cyBvZiAm bmJzcDthMCdzIHNlbnQgbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBiW1QyXS54KzEsIGJbVDJd LngrMixiW1QyXS54KzMsYltUMl0ueCs0LGJbVDJdLngrNQ0KdG8gYTEuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KKE15IHVuZGVyc3RhbmRpbmcsIGFjY29yZGluZyB0byBSRkMgNTk5NiwgaXMgdGhhdCB0 aGUgcGVlciBzaG91bGQgdHJlYXQNCnRoZSBuZXcgYWN0aXZlIG1lbWJlcidzIHJlcXVlc3QgbWVz c2FnZXMgYXMgcmVzZW50IHJlcWV1c3RzLiApPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyByZS1zZW50ICZuYnNwOyAmbmJzcDsgPGJyPg0KQXMgYSByZXN1 bHQsIHRoZSBwZWVyIGIgcmVjZWl2ZXMgYWNjZXB0YWJsZSBidXQgbWlzbWF0Y2hlZCByZXNwb25z ZXMgZm9yDQppdHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIGExW1QyXS54KzEs IGExW1QyXS54KzIsYTFbVDJdLngrMyxhMVtUMl0ueCs0LGExW1QyXS54KzUuPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KRm9yIGEg Y29uY3JldGUgZXhhbXBsZSwgbGV0J3MgYXNzdW1lOiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CmExW1QwXS54ID09IGEwW1QwXS54ID0gOTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmExW1QwXS55ID09 IGEwW1QwXS55ID0gMjA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiW1QwXS54ID0gMTk8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48YnI+DQpiW1RPXS55ID0gMTA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpG cm9tIFQwIHRvIFQxLCB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAgaGF2ZSBzZW50IDEwIHJlcXVl c3QgbWVzc2FnZXMgdG8NCnRoZSBwZWVyIGIsIGFuZCA1IG1lc3NhZ2VzIGhhdmUgYmVlbiByZWNl aXZlZCBhbmQgYWNrbm93bGVkZ2VkIGJ5IHRoZSBwZWVyDQpiLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NClRoaXMgbWVhbnMgdGhhdCBhMFtUMl0ueSA9IDMwLCBiW1QyXS54ID0gMjQuIE5vdGUg cmVxdWVzdCBtZXNzYWdlcyB3aXRoDQpNZXNzYWdlIElEIDI1LDI2LDI3LDI4LDI5IGhhdmUgYmVl biBzZW50IGJ5IHRoZSBvbGQgYWN0aXZlIG1lbWJlciBhMCwgYnV0DQpoYXZlIE5PVCByZWFjaGVk IHRoZSBwZWVyIGIwLiAoVGhlIHNlbmRlciB3aW5kb3cgc2l6ZSBvZiB0aGUgY2x1c3RlciBpcw0K NS4pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQWNjb3JkaW5nIHRvIFJGQyA2MzEx LCA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiZxdW90O00xIGlzIHRoZSBuZXh0IHNlbmRlcidz IE1lc3NhZ2UgSUQgdG8gYmUgdXNlZCBieSB0aGUgbWVtYmVyLiAmbmJzcDtNMTwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQpNVVNUIGJlIGNob3NlbiBzbyB0aGF0IGl0IGlzIGxhcmdlciB0aGFuIGFueSB2 YWx1ZSBrbm93biB0byBoYXZlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmJlZW4gdXNlZC4gJm5ic3A7 SXQgaXMgUkVDT01NRU5ERUQgdG8gaW5jcmVtZW50IHRoZSBrbm93biB2YWx1ZSBhdDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpsZWFzdCBieSB0aGUgc2l6ZSBvZiB0aGUgSUtFIHNlbmRlciB3aW5kb3cu JnF1b3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4gPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Ly8NCk0xIGlzIHNvbWV3aGF0IHJlbGV2 YW50IHRvIGFueSB2YWx1ZSBrbm93biB0byBoYXZlIGJlZW4gdXNlZCAoIE1lc3NhZ2UNCklEcyBv ZiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIHNlbnQgdG8gdGhlIHBlZXIgYi4gKTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KTTEgPT0gYTFbVDJdLnkgKyBTVyA9PSAyMCArIDUgPT0g MjU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KKGExW1QyXS55ID09IGExW1QwXS55ID09IDIwKTwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCkFuZCA8YnI+DQomcXVvdDtNMiBNVVNUIGJlIGF0IGxlYXN0 IHRoZSBoaWdoZXIgb2YgdGhlIHJlY2VpdmVkIE0xLCBhbmQgb25lIG1vcmU8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KdGhhbiB0aGUgaGlnaGVzdCBzZW5kZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUg Y2x1c3Rlci4gJm5ic3A7VGhpczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQppbmNsdWRlcyBhbnkgcHJl dmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2VzLiZxdW90OzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4vLzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7VW50aWwgVDAsIE0yIGlzIHNvbWV3aGF0DQpyZWxldmFudCB0byB0aGUgaGlnaGVzdCBzZW5k ZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3RlciAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4oTWVzc2FnZSBJRHMgb2YgcmVxdWVz dCBtZXNzYWdlcw0KdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4gJm5i c3A7TTIgaXMgc29tZXdoYXQgcmVsZXZhbnQNCmJbVDJdLngpPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YnI+DQpNMiA9PSBtYXh7TTEsIDEgKyBiW1QyXS54KT09IG1heCgyNSwxKzI0KSA9PSAyNTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBZnRlciB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEg cmVjZWl2ZXMgTTIsIGExIHNldHMgYTFbVDJdLnkgPT0gMjUgJmx0Ow0KYTBbVDJdLnkgPT0gMzAu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIE1lc3NhZ2UgSUQgZm9yIHRoZSBuZXcgYWN0 aXZlIG1lbWJlciBhMSBudW1iZXJzIGZyb20gMjUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N ClRoZSBmaXJzdCBmaXZlIE1lc3NhZ2UgSURzIGFyZSAyNSwgMjYsIDI3LDI4LDI5LjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQpXaGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBzZW5kcyBy ZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZXMgSURzDQoyNSwgMjYsMjcsMjgsMjksIHNpbmNl IHRoZSBwZWVyIGIgaGFzIHByb2Nlc3NlZCB0aGUgcmVxdWVzdCBtZXNzYWdlIHdpdGgNCnRoZSBz YW1lIE1lc3NhZ2UgSURzLCB0aGUgcGVlciBiIHdpbGwgcmV0dXJuIHJlc3BvbnNlIG1lc3NhZ2Vz IGZvciB0aGUNCnJlcXVlc3QgbWVzc2FnZXMgZnJvbSB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoZW4gYTEgcmVjZWl2ZXMgYWNjZXB0YWJsZSBi dXQgbWlzbWFjdGhlZCByZXNwb25zZSBtZXNzYWdlcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCjIuIENsYXJpZmljYXRpb25zIGZv ciB0aGUgc2ltdWx0YW5lc291cyBmYWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjMNCjxicj4N CkZvciB0aGUgc2ltdWx0YW5lb3VzIGZhaWxvdmVyLCBjYXNlIEYgaXMgdGhlIG1vc3QgZGV2YXN0 YXRpbmcgSU1PLiBTbyBJJ2QNCmxpa2UgdG8gY2xhcmlmeSBpdCBmaXJzdC48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQoyLjEgTm90YXRpb24gZm9yIHRoZSBzaW11bHRhbmVzb3VzIGZhaWxvdmVyIGNhc2Ug RiBpbiBTZWN0aW9uIDIuMzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMDogdGhl IG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYTwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQphMTogdGhlIG5ldyBhY3RpdmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIg YTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiMDogdGhlIG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXIg b2YgdGhlIGNsdXN0ZXIgYjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiMTogdGhlIG5ldyBhY3RpdmUg Y2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpUMDogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgbGFzdCBzeW5jaHJvbml6YXRpb24g YmV0d2VlbiBhMC9iMCBhbmQgYTEvYjENCmlzIGNhcnJpZWQgb3V0LCA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NClQxOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBzaW11bHRhbmVvdXMgZmFpbG92 ZXIgZXZlbnQgb2NjdXJzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClQyOiBBdCB0aGlzIHRp bWUgcG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBi MQ0Kc3RhcnRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVDM6IEF0IHRoaXMgdGlt ZSBwb2ludCwgdGhlIE1lc3NhZ2UgSUQgc3luY2hyb25pemF0aW9uIGJldHdlZW4gYTEgYW5kIGIx DQplbmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0K PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KLS0tLVQwLS0tLS0t LS1UMS0tLS0tLS0tLS1UMi0tLS0tLS0tLS1UMy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGJyPg0KMi4yIEFuYWx5c2lzIGZvciB0aGUgc2ltdWx0YW5lc291cyBm YWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KSXQncyBwb3NzaWJsZSB0aGF0IGZyb20gVDAgdG8gVDEsIGEwIGFuZCBiMCBkZWxldGVz IHRoZSBvbGQgSUtFIFNBIHNhMA0KYW5kIGNyZWF0ZXMgYSBuZXcgSUtFIFNBIHNhMS48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpCdXQgYXQgVDIsIGExIGFuZCBiMSBkbyBOT1Qga25vdyB3aGF0IGhhcyBo YXBwZW5lZCBmcm9tIFQwIGFuZCBUMSwgYW5kDQpkbyBOT1Qga25vdyB0aGUgZXhpc3RhbmNlIG9m IHRoZSBuZXcgSUtFIFNBIHNhMSwgYW5kIHVzZSB0aGUgb2xkIElLRSBTQQ0Kc2EwIHRvIGNhcnJ5 IG91dCBNZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhp cyBtYXkgYnJpbmcgc29tZSBtb3JlIHNlcmlvdXNlIHByb2JsZW0uIFNvICZuYnNwO3doZW4gc2lt dWx0YW5lb3VzIGZhaWxvdmVyDQpvY2N1cnMsIGEgc2ltcGxlIHR3by13YXkgc3luY2hyb25pemF0 aW9uICZuYnNwO21heSBub3QgYmUgYW4gYXBwcm9wcmlhdGUNCnNvbHV0aW9uLjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZxdW90 O0thbHlhbmkgR2FyaWdpcGF0aSAoa2FnYXJpZ2kpJnF1b3Q7DQombHQ7PC9iPjwvZm9udD48YSBo cmVmPW1haWx0bzprYWdhcmlnaUBjaXNjby5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPjxiPjx1PmthZ2FyaWdpQGNpc2NvLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9u dCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCreivP7IyzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJp YWwiPjogJm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3Jn Ij48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aXBzZWMtYm91bmNlc0Bp ZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MjAxMi0wNi0xNCAxOToxNDwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMl Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD02 JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MyU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4m cXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPjxmb250 IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT56aGFuZy5ydWlzaGFuQHp0ZS5jb20u Y248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0Ozwv Zm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnpoYW5nLnJ1aXNoYW5AenRlLmNvbS5jbjwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OywNCiZxdW90OzwvZm9udD48 YSBocmVmPW1haWx0bzppcHNlY0BpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+PHU+aXBzZWNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFj ZT0iQXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzppcHNlY0BpZXRmLm9y Zz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aXBzZWNAaWV0Zi5vcmc8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+UmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIg RXh0ZW5zaW9uDQpmb3IgSUtFdjIvSVBzZWMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SGln aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdmFpbGFibGl0eTwvZm9udD48L3RhYmxlPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0K PHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpIaSBaaGFuZyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N ClRoYW5rcyBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgUkZDIDYzMTEgLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki Pjxicj4NCkkgaGF2ZSBnb25lIHRocm91Z2ggeW91ciAmbmJzcDtwcm9wb3NlZCBkcmFmdCBhbmQg ZmVsdCB0aGF0IHRoZXJlIGlzIHNvbWUNCmNvbmZ1c2lvbiByZWdhcmRpbmcgdGhlIG1lc3NhZ2Ug aWQgY29uY2VwdCBvZiBpa2V2Mi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJIGhhdmUgc2VlbiB0 aGF0IGluIHNlY3Rpb24gMi4zIHlvdSB3ZXJlIGNvbXBhcmluZyB0aGUgaGlnZXIgc2VuZGVyIHZh bHVlDQpvZiB4MiB3aXRoIHkyLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpU aGF0IGlzIHdyb25nLiB3aGVuIHgyIHByb3Bvc2VzIHRoZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlk IHRvIGJlIHVzZWQgdG8NCnNlbmQgYSByZXF1ZXN0ICw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+PGJyPg0KdGhlbiBvbiB5MiB5b3Ugc2hsZCB0YWxseSBpdCB3aXRoIHRoZSBuZXh0IGhp Z2hlciBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0DQp0byBiZSByZWNpZXZlZCA8YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoYW5kIG5vdCB3aXRoIHRoZSBu ZXh0IGhpZ2hlcg0KbWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSBzZW50KTwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NCmluIGlrZXYyIHRoZSAmbmJzcDttZXNzYWdlIGlkIG9mIHJlcXVlc3Rz IHRvIGJlIHNlbnQgYXJlIGVudGlyZWx5IGRpZmZlcmVudA0KZnJvbSBtZXNzYWdlIGlkIG9mIHJl cXVlc3RzIHRvIGJlIHJlY2VpdmVkLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KdGhhdCBpcyB3aHkgUkZDIHNheXMgYSBtZXNzYWdlIGlkIGlzIHVzZWQgZm91ciB0aW1lcyBv biBhIGdpdmVuIGRldmljZS4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQoxLiBtZXNzYWdlIGlkIFggaXMgdXNlZCB3aGlsZSBzZW5kaW5nIGEgcmVxdWVz dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KMi4gbWVzc2FnZSBpZCBYIGlz IHVzZWQgd2hpbGUgcmVjZWl2aW5nIHRoZSByZXNwb25zZTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KMy4gbWVzc2FnZSBpZCBYIGlzIHVzZWQgdG8gcmVjZWl2ZSBhIHJlcXVl c3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCjQuIG1lc3NhZ2UgaWQgWCBp cyB1c2VkIHRvIHNlbmQgYSByZXNwb25zZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KcGxlYXNlIGZpbmQgdGhlIGNvbW1l bnRzIGZvciBlYWNoIHNlY3Rpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpTZWN0aW9uIDIuMTog Jm5ic3A7VGhpcyBpcyBhIGtub3duIGlzc3VlIGFuZCB0aGF0IGlzIHdoeSB1c2luZyBSRkMgNjMx MSwNCiZuYnNwO3dlIGFyZSBzeW5jaHJvbmlzaW5nIHRoZSBtZXNzYWdlIGlkJ3M8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQpTZWN0aW9uIDIuMjogVGhlIHBlZXIgaXMgYXNzdW1lZCB0byBiZSBwcm9w ZXIgYW5jaG9yIHBvaW50IHdoaWNoIGhhcyBjb3JyZWN0DQppbmZvIG9mIG1lc3NhZ2UgaWQgb2Yg cmVxdWVzdHMgc2VudCBhbmQgcmVjaWV2ZWQsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQpldmVuIHdoZW4gcGVlciBpcyBjbHVzdGVyIG1lbWJlciAsIGFtb25nIHRoZSB0d28g ZGV2aWNlcyBvbmUgb2YgdGhlbSB3b3VsZA0KYmUgbGVzcyB3cm9uZyBhbmQgaGF2ZSBoaWdoZXIg YWNjdXJhdGUgdmFsdWVzIG9mIG1lc3NhZ2UgaWQncyAuIDxicj4NCnNvIHdlIHBpY2sgdXAgdGhh dCB2YWx1ZS4gSSBkb250IHNlZSBhbnkgaXNzdWUgaGVyZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+ DQpTZWN0aW9uIDIuMzogRmlyc3Qgb2YgYWxsIHRoZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW4g TTEgYW5kIFAxLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0Kb24gYSBnaXZl biBkZXZpY2UuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCi0tLSBNMSBpcyB0 aGUgcHJvcG9zZWQgbWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSBzZW50PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7ICZuYnNwO1AxIGlzIHRoZSBwcm9w b3NlZCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHJlY2VpdmVkLjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPjxicj4NCndoZW4gc2ltdWxhdGVub3VzIGZhaWxvdmVyIGhhcHBlbnMsIHgyIG1pZ2h0 IGhhdmUgaGlnaGVyIHZhbHVlIG9mIE0xIHdoZW4NCmNvbXBhcmVkIHRvIHkyICwgYnV0IHgyIG1p Z2h0IGhhdmUgbG93ZXIgdmFsdWUgb2YgUDEgd2hlbiBjb21wYXJlZCB0byB5Mi48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkl0IGRvZXMnbnQgbWF0dGVyLiBib3RoIGFyZSBp bmRlcGVuZGVudC4gd2hhdCB3ZSBldmVudHVhbGx5IGRvIGlzIGNvbXBhcmUNCnRoZSBNMSB2YWx1 ZSBhY3Jvc3MgeDIgYW5kIHkyIGFuZCBwaWNrIHRoZSBoaWdlciBvbmUuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpzYW1lIHByb2Nlc3MgaXMgcmVwZWF0ZWQgZm9yIFAxLjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPjxicj4NCmNhc2UgMSB0byA2IGFyZSBhbHJlYWR5IGhhbmRsZWQgYnkg YmFzaWMgaWtldjIgUkZDIC4gbGlrZSBpZiB3ZSByZWNlaXZlDQpzYW1lIG1lc3NhZ2UgaWQgdHdp Y2UgLCB0aGVuIHdlIHJldHJhbnNtaXQgb3IgZHJvcCBpdCBpZiBpdCBpcyBvdXRzaWRlDQp0aGUg d2luZG93LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NClNlY3Rpb24gMzogJm5ic3A7IGR1cmluZyBzaW11bHRhbmVvdXMgZmFp bG92ZXIgYm90aCB0aGUgY2x1c3RlciBhbmQgdGhlDQpwZWVyIG1lbWJlciB3b3VsZCBiZSBpbiB1 bnJlbGlhYmxlIHN0YXRlLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KQm90 aCBvZiB0aGVtIGFyZSB3cm9uZyAsIGJ1dCBvbmUgb2YgdGhlbSBpcyBsZXNzIHdyb25nICEhISBz byB3ZSB3YW50IHRvDQpzdGFydCBmcm9tIHRoYXQgcG9pbnQgdG8gc3luY2hyb25pc2UgdGhlIG1l c3NhZ2UgaWQncy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpzbyB3ZSBhcmUgYWxsb3dpbmcgYm90 aCB0aGUgbWVtYmVycyB0byBhbm5vdW5jZSB0aGVpciBtZXNzYWdlIGlkJ3MgYW5kDQp0aGVuIGV2 ZW50dWFsbHkgd2Ugd291bGQgc3luY2hyb25pc2UgdG8gdGhlIGhpZ2hlciBudW1iZXIuPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJIGRvbnQgc2VlIGFueSBmbGF3IGhlcmUu IFBsZWFzZSBleHBsYWluIHdpdGggYW4gZXhhbXBsZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpC eSB5b3VyIHByb3Bvc2FsIGluIGNhc2Ugb2Ygc2ltdWx0YW5lb3VzIGZhaWxvdmVyLCBib3RoIHRo ZSBjbHVzdGVyIGFuZA0KcGVlciB3aWxsIGJlIGluIFVOU1lORUQgc3RhdGUgYW5kIDxicj4NCmJv dGggd291bGQgZW5kIHVwIHNlbmRpbmcgYW5kIHJlamVjdGluZyB0aGUgc3luY2hyb25pc2F0aW9u IHJlcXVlc3QuIDxicj4NClRoaXMgd291bGQgbGVhZCB0byByZXBlYXRlZCBzeW5jaHJvbmlzYXRp b24gZWZmb3J0cyBhbmQgdGhlIHByb2JsZW0gb2YNCm1lc3NhZ2Ugc3luY2hyb25pc2F0aW9uIGlz IG5ldmVyIHNvbHZlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpzbyBVTlNZTkVEIHN0YXRlIGlz IG5vdCByZXF1aXJlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpTZWN0aW9uIDQ6IDxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJIGZlZWwgdGhhdCBSRkMg NjMxMSBhbHJlYWR5IHNvbHZlcyB0aGUgbWVzc2FnZSBpZCBzeW5jaHJvbmlzYXRpb24gaXNzdWUu DQo8YnI+DQpJIGRvbnQgdGhpbmsgd2UgbmVlZCB0byBpbmNyZW1lbnQgTTEgYnkgZG91YmxlIHRo ZSB3aW5kb3cgc2l6ZSBhcyBwcm9wb3NlZA0KYnkgeW91LiA8YnI+DQpQbGVhc2Ugc3VwcG9ydCB5 b3VyIHByb3Bvc2FsIHdpdGggYW4gZXhhbXBsZSB3aXRoIG1lc3NhZ2UgaWQgdmFsdWVzIG9mDQpu dW1iZXJzIGluc3RlYWQgb2YgdmFyaWFibGVzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQpMaWtlIE0xIGlzIDMgLCBNMiBpcyA0IGV0YyBldGMuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48 YnI+DQpOdW1iZXJzIG1ha2UgaXQgbW9yZSBjbGVhci48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCnJl Z2FyZHMsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCmthbHlhbmk8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxi cj4NCkZyb206PC9iPiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5v cmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aXBzZWMtYm91bmNl c0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KPC9m b250PjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PlttYWlsdG86aXBzZWMtYm91bmNl c0BpZXRmLm9yZ108L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLnJ1aXNoYW5AenRl LmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnpoYW5nLnJ1 aXNoYW5AenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPjxicj4NClNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTEsIDIwMTIgNzozNiBBTTxiPjxicj4N ClRvOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmlwc2VjQGlldGYub3JnPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aXBzZWNAaWV0Zi5vcmc8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpTdWJqZWN0OjwvYj4gW0lQc2Vj XSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYyL0lQc2VjIEhpZ2gNCkF2 YWlsYWJsaXR5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCjxicj4NCjxicj4NCkRlYXIgQWxsLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K PGJyPg0KIEkndmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0ICZxdW90OzwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPg0KVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZv ciBJS0V2Mi9JUHNlYyBIaWdoIEF2YWlsYWJsaXR5PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+JnF1b3Q7Lg0KVGhpcyBkcmFmdCBhbmFseXplcyBzb21lIGlzc3VlcyBpbiBSRkMgNjMx MSwgPGJyPg0KYW5kIHByb3Bvc2VzIHNvbWUgdXBkYXRlcy4gTG9vayBmb3J3YXJkIHRvIHlvdXIg Y29tbWVudHMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KQlIsPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpSdWlzaGFuIFpoYW5nPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFp bHRvOklQc2VjQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PklQc2VjQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHNlYzwvdT48L2ZvbnQ+PC9hPjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8 YnI+DQpJUHNlY0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXBzZWM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00104BB748257A24_=-- From zhang.ruishan@zte.com.cn Wed Jun 20 19:59:56 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3954811E80BE; Wed, 20 Jun 2012 19:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.035 X-Spam-Level: X-Spam-Status: No, score=-97.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+N6RouHaJDa; Wed, 20 Jun 2012 19:59:54 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 956BA11E8079; Wed, 20 Jun 2012 19:59:49 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 51496433787882; Thu, 21 Jun 2012 10:58:03 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 52926.2301296981; Thu, 21 Jun 2012 10:59:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q5L2xh1Y030312; Thu, 21 Jun 2012 10:59:43 +0800 (GMT-8) (envelope-from zhang.ruishan@zte.com.cn) In-Reply-To: <52F04C02CB538E4DAAA0B493EBCA4A7503F049ED@xmb-rcd-x11.cisco.com> MIME-Version: 1.0 To: "Kalyani Garigipati (kagarigi)" X-KeepSent: 70867D1F:F159204A-48257A24:000C202D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.ruishan@zte.com.cn Date: Thu, 21 Jun 2012 10:59:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-21 10:59:44, Serialize complete at 2012-06-21 10:59:44 Content-Type: multipart/alternative; boundary="=_alternative 0010751848257A24_=" X-MAIL: mse01.zte.com.cn q5L2xh1Y030312 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 02:59:56 -0000 This is a multipart message in MIME format. --=_alternative 0010751848257A24_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgS2FseWFuaQ0KDQpQbGVhc2Ugc2VlIHRoZSBpbmxpbmUgY2xhcmlmaWNhdGlvbnMuDQoNCkJS LA0KDQpSdWlzaGFuDQoNCg0KDQoiS2FseWFuaSBHYXJpZ2lwYXRpIChrYWdhcmlnaSkiIDxrYWdh cmlnaUBjaXNjby5jb20+IA0Kt6K8/sjLOiAgaXBzZWMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0w Ni0yMCAxODoyNg0KDQrK1bz+yMsNCiJ6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24iIDx6aGFuZy5y dWlzaGFuQHp0ZS5jb20uY24+DQqzrcvNDQoiaXBzZWNAaWV0Zi5vcmciIDxpcHNlY0BpZXRmLm9y Zz4sICJpcHNlYy1ib3VuY2VzQGlldGYub3JnIiANCjxpcHNlYy1ib3VuY2VzQGlldGYub3JnPg0K 1vfM4g0KUmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZvciBJS0V2 Mi9JUHNlYyBIaWdoIA0KQXZhaWxhYmxpdHkNCg0KDQoNCg0KDQoNCkhpIFpoYW5nLA0KIA0KRm9y IEFuYWx5c2lzIDEgDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCiANCmEwW3RdLnggIGEwJ3MgbWF4aW11bSBtZXNzYWdlIElEIHJlY2Vp dmVkIGZyb20gdGhlIHBlZXIgYiB1bnRpbCB0aW1lIHQgDQphMFt0XS55ICBhMCdzIG5leHQgc2Vu ZGVyIG1lc3NhZ2UgSUQgIGF0IHRpbWUgdCANCiANCkkgdGhpbmsgdGhlcmUgaXMgY29uZnVzaW9u IGFib3ZlLg0KSSBndWVzcyB3aGF0IHUgYWN0dWFsbHkgd2FudGVkIHRvIGNvbnZleSBpcyANCiAN CmEwW3RdLnggIGEwJ3MgbWF4aW11bSBtZXNzYWdlIElEIG9mIHRoZSByZXF1ZXN0IHNlbnQgYW5k IG9yZGVybHkgcmVzcG9uc2UgDQpyZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgdW50aWwgdGltZSB0 ICwgc2F5IGlmIGEgaGFzIHJlY2VpdmVkIHJlc3BvbnNlcyANCmZvciAyIGFuZCAzIGFuZCA1ICAs IHRoaXMgdmFsdWUgaXMgMy4gU28gbm93IHRoZSB3aW5kb3cgd291bGQgYmUgNC04IA0KKGluY2x1 c2l2ZSkNCmEwW3RdLnkgIGEwJ3MgbmV4dCByZXF1ZXN0IG1lc3NhZ2UgSUQgdG8gYmUgc2VudCBh dCB0aW1lIHQgLCB0aGlzIHZhbHVlIGlzIA0KNiAsIGlmIGl0IGhhcyBhbHJlYWR5IHNlbnQgdGhl IHJlcXVlc3RzIDIsMyw0LDUsIA0KIA0KYlt0XS54ICAgYidzIG1heGltdW0gbWVzc2FnZSBJRCBv ZiB0aGUgb3JkZXJseSByZXNwb25zZSBzZW50IHRvIGNsdXN0ZXIgDQp1bnRpbCB0aW1lIHQgLCBp ZiBpdCBoYXMgc2VudCByZXNwb25zZSB0byAyLDMgYW5kIDUgaWQgcmVxdWVzdHMgLCBpdCBpcyAN CnN0aWxsIDMuDQpiW3RdLnkgICBiJ3MgbmV4dCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRv IGJlIHJlY2VpdmVkLCB3aGljaCBpcyA2IA0KDQovLyAgQSBjbGFyaWZpY2F0aW9uIGFib3V0IHg6 ICBhMFt0XS54IGlzIHJlbGV2YW50IHRvIHRoZSBtYXhpbXVtIE1lc3NhZ2UgDQpJRCBvZiB0aGUg cmVjZWl2ZWQgcmVxdWVzdCBtZXNzYWdlIGZvciB0aGUgb3Bwb3NpdGUgSUtFIHYyIHBhcnR5LiBT YXkgDQp1bnRpbCB0aW1lIFQwLCBhMCBoYXMgcmVjZWl2ZWQgNSAvL3JlcXVlc3QgbWVzc2FnZXMg ZnJvbSBiLCBhbmQgdGhlIA0KTWVzc2FnZSBJRHMgYXJlIDEsIDIsIDMsIDQsIDUuIFRoZW4gYTBb VDBdLnggPT0gNS4gU2F5IHVudGlsIHRpbWUgVDAsIGIgDQpoYXMgcmVjZWl2ZWQgNCByZXF1ZXN0 IG1lc3NhZ2VzIGZyb20gYSwgYW5kIHRoZSBNZXNzYWdlcyBJRHMgYXJlIC8vNCw1LCA2LCANCjcu IFRoZW4gYltUMF0ueCA9PSA3Lg0KLy9BY3R1YWxseSwgIHggaXMgaXJyZWxldmFudCB0byB5LiAN CiANCkkgZ3Vlc3MgdGhlIGV4YW1wbGUgaGFzIHdyb25nIHZhbHVlcy4NCiANCmlmIHdpbmRvdyBz aXplIGlzIDUgDQogDQp0aGVuIA0KIA0KRm9yIGEgY29uY3JldGUgZXhhbXBsZSwgbGV0J3MgYXNz dW1lOiANCiANCmExW1QwXS54ID09IGEwW1QwXS54ID0gOSAtLS0tLS0tLS0tLS0tLS1ob3cgY2Fu IHggYW5kIHkgdmFyeSBieSAxMCB3aGVuIA0KdGhlIHdpbmRvdyBzaXplIGlzIDUgID8NCi8vIFVu dGlsIFQwLCBhMCBoYXMgcmVjZWl2ZWQgOSByZXF1ZXN0IE1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJ RHMgMSwgMiwgDQozLDQsIDUsIDYsNyw4LDkgZnJvbSB0aGUgcGVlciBiIC4gU28gdGhlIGEwW1Qw XS54ID09OSANCg0KDQphMVtUMF0ueSA9PSBhMFtUMF0ueSA9IDIwIA0KIC8vICBVbnRpbCBUMCwg YTAgaGFzIHNlbnQgMTkgcmVxdWVzdCBNZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIDMs NCwgDQo1LCAuLi4sMTkgdG8gdGhlIHBlZXIgYi4gU28gdGhlIGEwW1QwXS55ICA9PTIwDQogDQpi W1QwXS54ID0gMTkgICAtLSBzYW1lIGlzIHRoZSBjYXNlIGhlcmUuLg0KLy8gVW50aWwgVDAsIHRo ZSBwZWVyIGIgaGFzIHJlY2VpdmVkIDE5IHJlcXVlc3QgTWVzc2FnZXMgd2l0aCBNZXNzYWdlIElE cyANCjEsIDIsIDMsLi4uLDE5IGZyb20gdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwIC4gU28gdGhl IGJbVDBdLnggPT0xOSANCmJbVE9dLnkgPSAxMCANCi8vIFVudGlsIFQwLCB0aGUgcGVlciBiIGhh cyBzZW50IDkgcmVxdWVzdCBNZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIA0KMywuLi4s OSB0byB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAgLiBTbyB0aGUgYltUMF0ueSA9PTkgDQogDQpQ bGVhc2UgYWRqdXN0IHRoZXNlIHZhbHVlcyBhbmQgdGhlbiB0aGVyZSB3aWxsIGJlIG5vIGlzc3Vl cyBhcyBtZW50aW9uZWQgDQpieSB5b3UuDQogDQphbHNvIHBsZWFzZSByZWZlciB0byB0aGUgc2Vj dGlvbiA4LjEgYW5kIDkgb2YgdGhlIFJGQyA2MzExIHdoaWNoIHNheXMgdGhhdCANCndoZW4gdGhl IHdpbmRvdyBtb3ZlcyB0byB0aGUgc3luY2hyb25pc2VkIHZhbHVlLA0KYWxsIHRoZSBvbGQgcGVu ZGluZyByZXF1ZXN0cyBhbmQgdG8tYmUgcmV0cmFuc21pdHRlZCByZXNwb25zZXMgc2hvdWxkIGJl IA0KZGVsZXRlZC4gU28gdGhlIGJlbG93IGlzc3VlIHdpbGwgbm90IGhhcHBlbg0KIA0KV2hlbiB0 aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgc2VuZHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3Nh Z2VzIElEcyAyNSwgDQoyNiwyNywyOCwyOSwgc2luY2UgdGhlIHBlZXIgYiBoYXMgcHJvY2Vzc2Vk IHRoZSByZXF1ZXN0IG1lc3NhZ2Ugd2l0aCB0aGUgDQpzYW1lIA0KTWVzc2FnZSBJRHMsIHRoZSBw ZWVyIGIgd2lsbCByZXR1cm4gcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZXF1ZXN0IA0KbWVz c2FnZXMgZnJvbSB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAuIA0KIA0KVGhlbiBhMSByZWNlaXZl cyBhY2NlcHRhYmxlIGJ1dCBtaXNtYWN0aGVkIHJlc3BvbnNlIG1lc3NhZ2VzLg0KIA0KRm9yIEFu YWx5c2lzIDINCiANClRoaXMgaXMgdGhlIHByb2JsZW0gb2YgYmFzaWMgSEEgc2ltdWxhdGVub3Vz IGZhaWwtb3ZlciBhbmQgbm90IGp1c3QgYWJvdXQgDQptZXNzYWdlIElEIHN5bmNocm9uaXNhdGlv bi4NCiANCndoZW4gYm90aCBvZiB0aGUgZGV2aWNlcyBkb26hr3QgaGF2ZSBuZXcgc2EgYW5kIGp1 c3QgaGF2ZSB0aGUgb2xkIHNhLg0KVGhlbiB0aGV5IHdpbGwgIGNvbnRpbnVlIHdpdGggdGhlIG9s ZCBzYSBvciBicmluZyBkb3duIHRoZSBzYSBiYXNlZCBvbiB0aGUgDQphZG1pbmlzdHJhdGl2ZSBj b250cm9sLg0KDQovLyBJJ20gTk9UIHN1cmUgd2hldGhlciBjb250aW51aW5nIHdpdGggdGhlIG9s ZCBzYSB3aWxsIGNhdXNlIHNvbWUgDQpzZWN1cml0eSByaXNrcyBvciBub3QuIA0KIA0KdGhlIHN5 bmMgdGltZSB3aXRoaW4gYSBjbHVzdGVyICBhbW9uZyBhIGFuZCBiIG1pZ2h0IGJlIHNhbWUgb3Ig ZGlmZmVyZW50IA0KZHVlIHRvIHdoaWNoIG9uZSBvZiB0aGVtIHdvdWxkIGhhdmUgb2xkIHNhIGFu ZCBhbm90aGVyIHdvdWxkIGhhdmUgbmV3IHNhLiANCmluIHN1Y2ggDQpjYXNlcyBib3RoIHRoZSBz YSB3b3VsZCBiZSBkZWxldGVkIGV2ZW50dWFsbHkgYW5kIG5ldyBzYSBpcyBlc3RhYmxpc2hlZC4N CiANCm9yIGV2ZW4gaWYgc3luYyB0aW1lcyBhcmUgZGlmZmVyZW50LCBvbmUgd291bGQgaGF2ZSBv bGQgc2Egd2l0aCBsZXNzZXIgDQptZXNzYWdlIGlkJ3MgYW5kIG90aGVyIGhhdmUgc2FtZSBvbGQg c2Egd2l0aCBoaWdoZXIgbWVzc2FnZSBpZCdzIGFuZCB0aGVuIA0KYm90aCB3aWxsIA0Kc3RhcnQg ZnJvbSB0aGUgaGlnaGVyIG1lc3NhZ2UgaWQgdmFsdWVzLg0KIA0KUmVnYXJkcywNCmthbHlhbmkN CiANCkZyb206IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgDQp6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24NClNlbnQ6IFdl ZG5lc2RheSwgSnVuZSAyMCwgMjAxMiA3OjQ0IEFNDQpUbzogS2FseWFuaSBHYXJpZ2lwYXRpIChr YWdhcmlnaSkNCkNjOiBpcHNlY0BpZXRmLm9yZzsgaXBzZWMtYm91bmNlc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZvciBJS0V2 Mi9JUHNlYyBIaWdoIA0KQXZhaWxhYmxpdHkNCiANCg0KSGkgS2FseWFuaSwgDQoNCg0KDQpGaXJz dCBJJ2QgbGlrZSB0byBtYWtlIHNvbWUgY2xhcmlmaWNhdGlvbnMgYWNjb3JkaW5nIHRvIHlvdXIg Y29tbWVudHMsIGFuZCANCmxlYXZlIG90aGVyIGNsYXJpZmljYXRpb25zIHRvIGZ1cnRoZXIgZGlz Y3Vzc2lvbnMuIA0KDQoxLiBDbGFyaWZpY2F0aW9uIGZvciBjYXNlIEMgaW4gU2VjdGlvbiAyLjIg DQooY2FzZSBDIGlzIHRoZSBtb3N0IHRyb3VibGVzb21lIGluIHRoaXMgc2VjdGlvbiBJTU8uU28g SSdkIGxpa2UgdG8gY2xhcmlmeSANCml0LikgDQoxLjEgTm90YXRpb24gZm9yIGNhc2UgQyBpbiBT ZWN0aW9uIDIuMiANCg0KeDogdGhlIG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9tIHRo ZSBwZWVyIHBhcnR5IA0KeTogdGhlIG5leHQgc2VuZGVyIG1lc3NhZ2UgSUQgDQoNCmEwOiB0aGUg b2xkIGFjdGl2ZSBjbHVzdGVyIG1lbWJlciANCmExOiB0aGUgbmV3IGFjdGl2ZSBjbHVzdGVyIG1l bWJlciANCmI6ICB0aGUgcGVlciANCg0KDQphMFt0XS54ICBhMCdzIG1heGltdW0gbWVzc2FnZSBJ RCByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgdW50aWwgdGltZSB0IA0KYTBbdF0ueSAgYTAncyBu ZXh0IHNlbmRlciBtZXNzYWdlIElEICBhdCB0aW1lIHQgDQoNCmExW3RdLnggIGExJ3MgbWF4aW11 bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiAgdW50aWwgdGltZSB0IA0KYTFb dF0ueSAgYTEncyBuZXh0IHNlbmRlciBtZXNzYWdlIElEICBhdCB0aW1lIHQgDQoNCmJbdF0ueCAg IGIncyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3RlciAgdW50aWwg dGltZSB0IA0KYlt0XS55ICAgYidzIG5leHQgc2VuZGVyIG1lc3NhZ2UgSUQgYXQgdGltZSB0IA0K DQoNClQwOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBsYXN0IHN5bmNocm9uaXphdGlvbiBiZXR3 ZWVuIGEwIGFuZCBhMSBpcyANCmNhcnJpZWQgb3V0IA0KDQpUMTogQXQgdGhpcyB0aW1lIHBvaW50 LCB0aGUgZmFpbG92ZXIgZXZlbnQgb2NjdXJzIA0KDQpUMjogQXQgdGhpcyB0aW1lIHBvaW50LCB0 aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYiANCnN0YXJ0cyAN Cg0KDQpUMzogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRp b24gYmV0d2VlbiBhMSBhbmQgYiANCmVuZHMgDQoNClNXOiB0aGUgc2VuZGVyIHdpbmRvdyBzaXpl IG9mIHRoZSBjbHVzdGVyLiBMZXQncyBhc3N1bWUgU1cgaXMgNS4gDQoNCi0tLS1UMC0tLS0tLS0t VDEtLS0tLS0tLS0tVDItLS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIA0KDQoNCjEuMiBBbmFseXNpcyBmb3IgY2FzZSBDIGluIFNlY3Rpb24gMi4yIA0KDQoN CldlIGtub3cgdGhhdDogDQoNCmExW1QwXS54ID09IGEwW1QwXS54IA0KYTFbVDBdLnkgPT0gYTBb VDBdLnkgDQooVGhlIHJlYW9uIGlzIHRoYXQgYXQgVDAsIHRoZSBzeW5jaHJvbml6YXRpb24gYmV0 d2VlbiBhMCBhbmQgYTEgaXMgY2FycmllZCANCm91dC4pIA0KDQpBbmQgDQoNCg0KYTFbVDFdLngg PT0gYTBbVDBdLnggDQphMVtUMV0ueSA9PSBhMFtUMF0ueSANCg0KQW5kIA0KDQphMVtUMl0ueCA9 PSBhMFtUMF0ueCANCmExW1QyXS55ID09IGEwW1QwXS55IA0KDQooVGhlIHJlYW9uIGlzIHRoYXQg ZnJvbSBUMCB0byBUMiwgdGhlIHN0YXRlIGRhdGEgb2YgYTEga2VlcHMgdW5jaGFuZ2VkLikgDQoN CkFjY29yZGluZyB0byBSRkMgNjMxMSwgDQoNCiJNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNz YWdlIElEIHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gIE0xIA0KTVVTVCBiZSBjaG9zZW4gc28g dGhhdCBpdCBpcyBsYXJnZXIgdGhhbiBhbnkgdmFsdWUga25vd24gdG8gaGF2ZSANCmJlZW4gdXNl ZC4gIEl0IGlzIFJFQ09NTUVOREVEIHRvIGluY3JlbWVudCB0aGUga25vd24gdmFsdWUgYXQgDQps ZWFzdCBieSB0aGUgc2l6ZSBvZiB0aGUgSUtFIHNlbmRlciB3aW5kb3cuIiANCg0KQXQgVDIsIHRo ZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBjYW4gc2V0IE0xPWExW1QyXS55ICsgU1cuIA0KDQoNCkFu ZCANCg0KIk0yIE1VU1QgYmUgYXQgbGVhc3QgdGhlIGhpZ2hlciBvZiB0aGUgcmVjZWl2ZWQgTTEs IGFuZCBvbmUgbW9yZSANCiAgICAgIHRoYW4gdGhlIGhpZ2hlc3Qgc2VuZGVyIHZhbHVlIHJlY2Vp dmVkIGZyb20gdGhlIGNsdXN0ZXIuICBUaGlzIA0KICAgICAgaW5jbHVkZXMgYW55IHByZXZpb3Vz IHJlY2VpdmVkIHN5bmNocm9uaXphdGlvbiBtZXNzYWdlcy4iIA0KIA0KQXQgVDIsIHRoZSBwZWVy IGIgY2FuIHNldCBNMiA9IG1heChNMSwgMSArIGJbVDJdLngpLiANCg0KTTE9PWExW1QyXS55ICsg U1cgPT4gTTEgPT0gYTBbVDBdLnkgKyBTVyAgPT4gTTEgPT0gYTBbVDBdLnkgKyA1IA0KDQpTdXBw b3NlIHNvbWUgbWVzc2FnZSBleGNoYW5nZXMgKGkuZS4sIDEwIG1lc3NhZ2VzKSBoYXZlIGJlZW4g Y2FycmllZCBvdXQgDQpmcm9tIFQwIHRvIFQyLCBpdCdzIHBvc3NpYmxlIHRoYXQgYltUMl0ueCAr IDEgPiBhMFtUMF0ueSArIDUuIA0KDQpUaGVuIHRoZSBwZWVyIGIgc2V0cyBNMj0xICsgYltUMl0u eC4gDQoNCkF0IFQzLCB3aGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSByZWNlaXZlcyB0aGUg TWVzc2FnZSBJRCANCnN5bmNocm9uaXphdGlvbiByZXNwb25zZSBmcm9tIHRoZSBwZWVyIGIsIGEx ICBzZXRzIGExW1QzXS55ID0gTTIuIA0KDQphMVtUM10ueSA9PSBNMiA9PiBhMVtUM10ueSA9PTEg KyBiW1QyXS54LiANCg0KDQpBdCBUMiwgYTBbVDJdLnkgY291bGQgYmUgYltUMl0ueCs1LiANCihU aGUgcmVhb24gaXMgdGhhdCBhMCdzIHNlbnQgbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBiW1Qy XS54KzEsIA0KYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1IG1heSBOT1Qg aGF2ZSByZWFjaGVkIHRvIHRoZSBwZWVyIA0KYi4pIA0KDQpUaGlzIG1lYW5zIGExW1QzXS55IDwg YTBbVDJdLnkuIA0KDQpUaGlzIG1lYW5zIHRoZSBmaXJzdCBmaXZlIG1lc3NhZ2VzIHNlbnQgYnkg dGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHdpbGwgDQpoYXZlIE1lc3NhZ2UgSURzIGJbVDJdLngr MSwgYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1LiANCg0KU3VwcG9zZSBh ZnRlciBUMywgdGhlIHBlZXIgcmVjZWl2ZXMgdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwJ3Mgc2Vu dCANCm1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCANCmJbVDJdLngrMixiW1Qy XS54KzMsYltUMl0ueCs0LGJbVDJdLngrNSwgYW5kIHNlbmRzIHJlc3BvbnNlIG1lc3NhZ2VzLiAN Cg0KQWZ0ZXIgdGhhdCwgdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHNlbmRzIHRoZSBmaXJzdCBm aXZlIHJlcXVlc3QgbWVzc2FnZXMgDQp3aXRoIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltUMl0u eCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1LiANCkFmdGVyIHJlY2V2aW5nIHRoZXNl IHJlcXVlc3QgbWVzc2FnZXMsIHRoZSBwZWVyIGIgd2lsbCByZWdhcmRzIHRoZXNlIA0KcmVxdWVz dHMgYXMgcmVzZW50IG1lc3NhZ2VzLCBhbmQgcmV0dXJucyByZXNwb25zZSBtZXNzYWdlcyBmb3Ig DQpyZXF1ZXN0cyBvZiAgYTAncyBzZW50IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0u eCsxLCANCmJbVDJdLngrMixiW1QyXS54KzMsYltUMl0ueCs0LGJbVDJdLngrNSB0byBhMS4gDQoo TXkgdW5kZXJzdGFuZGluZywgYWNjb3JkaW5nIHRvIFJGQyA1OTk2LCBpcyB0aGF0IHRoZSBwZWVy IHNob3VsZCB0cmVhdCANCnRoZSBuZXcgYWN0aXZlIG1lbWJlcidzIHJlcXVlc3QgbWVzc2FnZXMg YXMgcmVzZW50IHJlcWV1c3RzLiApIA0KICAgICAgICAgICAgICAgcmUtc2VudCANCkFzIGEgcmVz dWx0LCB0aGUgcGVlciBiIHJlY2VpdmVzIGFjY2VwdGFibGUgYnV0IG1pc21hdGNoZWQgcmVzcG9u c2VzIGZvciANCml0cyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYTFbVDJdLngr MSwgDQphMVtUMl0ueCsyLGExW1QyXS54KzMsYTFbVDJdLngrNCxhMVtUMl0ueCs1LiANCiANCkZv ciBhIGNvbmNyZXRlIGV4YW1wbGUsIGxldCdzIGFzc3VtZTogDQoNCmExW1QwXS54ID09IGEwW1Qw XS54ID0gOSANCmExW1QwXS55ID09IGEwW1QwXS55ID0gMjAgDQoNCmJbVDBdLnggPSAxOSANCmJb VE9dLnkgPSAxMCANCg0KRnJvbSBUMCB0byBUMSwgdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwIGhh dmUgc2VudCAxMCByZXF1ZXN0IG1lc3NhZ2VzIHRvIA0KdGhlIHBlZXIgYiwgYW5kIDUgbWVzc2Fn ZXMgaGF2ZSBiZWVuIHJlY2VpdmVkIGFuZCBhY2tub3dsZWRnZWQgYnkgdGhlIHBlZXIgDQpiLiAN Cg0KVGhpcyBtZWFucyB0aGF0IGEwW1QyXS55ID0gMzAsIGJbVDJdLnggPSAyNC4gTm90ZSByZXF1 ZXN0IG1lc3NhZ2VzIHdpdGggDQpNZXNzYWdlIElEIDI1LDI2LDI3LDI4LDI5IGhhdmUgYmVlbiBz ZW50IGJ5IHRoZSBvbGQgYWN0aXZlIG1lbWJlciBhMCwgYnV0IA0KaGF2ZSBOT1QgcmVhY2hlZCB0 aGUgcGVlciBiMC4gKFRoZSBzZW5kZXIgd2luZG93IHNpemUgb2YgdGhlIGNsdXN0ZXIgaXMgDQo1 LikgDQoNCg0KQWNjb3JkaW5nIHRvIFJGQyA2MzExLCANCg0KIk0xIGlzIHRoZSBuZXh0IHNlbmRl cidzIE1lc3NhZ2UgSUQgdG8gYmUgdXNlZCBieSB0aGUgbWVtYmVyLiAgTTEgDQpNVVNUIGJlIGNo b3NlbiBzbyB0aGF0IGl0IGlzIGxhcmdlciB0aGFuIGFueSB2YWx1ZSBrbm93biB0byBoYXZlIA0K YmVlbiB1c2VkLiAgSXQgaXMgUkVDT01NRU5ERUQgdG8gaW5jcmVtZW50IHRoZSBrbm93biB2YWx1 ZSBhdCANCmxlYXN0IGJ5IHRoZSBzaXplIG9mIHRoZSBJS0Ugc2VuZGVyIHdpbmRvdy4iIA0KIC8v IE0xIGlzIHNvbWV3aGF0IHJlbGV2YW50IHRvIGFueSB2YWx1ZSBrbm93biB0byBoYXZlIGJlZW4g dXNlZCAoIE1lc3NhZ2UgDQpJRHMgb2YgcmVxdWVzdCBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBz ZW50IHRvIHRoZSBwZWVyIGIuICkNCg0KTTEgPT0gYTFbVDJdLnkgKyBTVyA9PSAyMCArIDUgPT0g MjUgDQooYTFbVDJdLnkgPT0gYTFbVDBdLnkgPT0gMjApIA0KDQpBbmQgDQoiTTIgTVVTVCBiZSBh dCBsZWFzdCB0aGUgaGlnaGVyIG9mIHRoZSByZWNlaXZlZCBNMSwgYW5kIG9uZSBtb3JlIA0KdGhh biB0aGUgaGlnaGVzdCBzZW5kZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4gIFRo aXMgDQppbmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uIG1lc3Nh Z2VzLiIgDQoNCi8vICBVbnRpbCBUMCwgTTIgaXMgc29tZXdoYXQgcmVsZXZhbnQgdG8gdGhlIGhp Z2hlc3Qgc2VuZGVyIHZhbHVlIHJlY2VpdmVkIA0KZnJvbSB0aGUgY2x1c3RlciANCihNZXNzYWdl IElEcyBvZiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIHJlY2VpdmVkIGZyb20gdGhl IGNsdXN0ZXIuIA0KIE0yIGlzIHNvbWV3aGF0IHJlbGV2YW50IGJbVDJdLngpDQoNCiANCk0yID09 IG1heHtNMSwgMSArIGJbVDJdLngpPT0gbWF4KDI1LDErMjQpID09IDI1IA0KDQpBZnRlciB0aGUg bmV3IGFjdGl2ZSBtZW1iZXIgYTEgcmVjZWl2ZXMgTTIsIGExIHNldHMgYTFbVDJdLnkgPT0gMjUg PCANCmEwW1QyXS55ID09IDMwLiANCg0KVGhlIE1lc3NhZ2UgSUQgZm9yIHRoZSBuZXcgYWN0aXZl IG1lbWJlciBhMSBudW1iZXJzIGZyb20gMjUuIA0KDQpUaGUgZmlyc3QgZml2ZSBNZXNzYWdlIElE cyBhcmUgMjUsIDI2LCAyNywyOCwyOS4gDQoNCldoZW4gdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGEx IHNlbmRzIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCBNZXNzYWdlcyBJRHMgMjUsIA0KMjYsMjcsMjgs MjksIHNpbmNlIHRoZSBwZWVyIGIgaGFzIHByb2Nlc3NlZCB0aGUgcmVxdWVzdCBtZXNzYWdlIHdp dGggdGhlIA0Kc2FtZSBNZXNzYWdlIElEcywgdGhlIHBlZXIgYiB3aWxsIHJldHVybiByZXNwb25z ZSBtZXNzYWdlcyBmb3IgdGhlIHJlcXVlc3QgDQptZXNzYWdlcyBmcm9tIHRoZSBvbGQgYWN0aXZl IG1lbWJlciBhMC4gDQoNClRoZW4gYTEgcmVjZWl2ZXMgYWNjZXB0YWJsZSBidXQgbWlzbWFjdGhl ZCByZXNwb25zZSBtZXNzYWdlcy4gDQoNCiANCjIuIENsYXJpZmljYXRpb25zIGZvciB0aGUgc2lt dWx0YW5lc291cyBmYWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjMgDQpGb3IgdGhlIHNpbXVs dGFuZW91cyBmYWlsb3ZlciwgY2FzZSBGIGlzIHRoZSBtb3N0IGRldmFzdGF0aW5nIElNTy4gU28g SSdkIA0KbGlrZSB0byBjbGFyaWZ5IGl0IGZpcnN0LiANCjIuMSBOb3RhdGlvbiBmb3IgdGhlIHNp bXVsdGFuZXNvdXMgZmFpbG92ZXIgY2FzZSBGIGluIFNlY3Rpb24gMi4zIA0KDQoNCmEwOiB0aGUg b2xkIGFjdGl2ZSBjbHVzdGVyIG1lbWJlciBvZiB0aGUgY2x1c3RlciBhIA0KYTE6IHRoZSBuZXcg YWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGEgDQpiMDogdGhlIG9sZCBhY3Rp dmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYiANCmIxOiB0aGUgbmV3IGFjdGl2ZSBj bHVzdGVyIG1lbWJlciBvZiB0aGUgY2x1c3RlciBiIA0KDQoNClQwOiBBdCB0aGlzIHRpbWUgcG9p bnQsIHRoZSBsYXN0IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGEwL2IwIGFuZCBhMS9iMSANCmlz IGNhcnJpZWQgb3V0LCANCg0KVDE6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIHNpbXVsdGFuZW91 cyBmYWlsb3ZlciBldmVudCBvY2N1cnMgDQoNClQyOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBN ZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiMSANCnN0YXJ0cyANCg0K DQpUMzogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24g YmV0d2VlbiBhMSBhbmQgYjEgDQplbmRzIA0KDQoNCg0KLS0tLVQwLS0tLS0tLS1UMS0tLS0tLS0t LS1UMi0tLS0tLS0tLS1UMy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoN CiANCjIuMiBBbmFseXNpcyBmb3IgdGhlIHNpbXVsdGFuZXNvdXMgZmFpbG92ZXIgY2FzZSBGIGlu IFNlY3Rpb24gMi4zIA0KDQoNCkl0J3MgcG9zc2libGUgdGhhdCBmcm9tIFQwIHRvIFQxLCBhMCBh bmQgYjAgZGVsZXRlcyB0aGUgb2xkIElLRSBTQSBzYTAgYW5kIA0KY3JlYXRlcyBhIG5ldyBJS0Ug U0Egc2ExLiANCkJ1dCBhdCBUMiwgYTEgYW5kIGIxIGRvIE5PVCBrbm93IHdoYXQgaGFzIGhhcHBl bmVkIGZyb20gVDAgYW5kIFQxLCBhbmQgZG8gDQpOT1Qga25vdyB0aGUgZXhpc3RhbmNlIG9mIHRo ZSBuZXcgSUtFIFNBIHNhMSwgYW5kIHVzZSB0aGUgb2xkIElLRSBTQSBzYTAgDQp0byBjYXJyeSBv dXQgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24uIA0KVGhpcyBtYXkgYnJpbmcgc29tZSBtb3Jl IHNlcmlvdXNlIHByb2JsZW0uIFNvICB3aGVuIHNpbXVsdGFuZW91cyBmYWlsb3ZlciANCm9jY3Vy cywgYSBzaW1wbGUgdHdvLXdheSBzeW5jaHJvbml6YXRpb24gIG1heSBub3QgYmUgYW4gYXBwcm9w cmlhdGUgDQpzb2x1dGlvbi4gDQoNCg0KDQoNCg0KDQoiS2FseWFuaSBHYXJpZ2lwYXRpIChrYWdh cmlnaSkiIDxrYWdhcmlnaUBjaXNjby5jb20+IA0Kt6K8/sjLOiAgaXBzZWMtYm91bmNlc0BpZXRm Lm9yZyANCjIwMTItMDYtMTQgMTk6MTQgDQoNCg0KytW8/sjLDQoiemhhbmcucnVpc2hhbkB6dGUu Y29tLmNuIiA8emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPiwgImlwc2VjQGlldGYub3JnIiA8DQpp cHNlY0BpZXRmLm9yZz4gDQqzrcvNDQoNCtb3zOINClJlOiBbSVBzZWNdIFVwZGF0ZXMgdG8gdGhl IElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMgICAgICAgIEhpZ2ggIA0KQXZhaWxhYmxp dHkNCiANCg0KDQoNCg0KDQoNCg0KDQpIaSBaaGFuZywgDQogIA0KVGhhbmtzIGZvciBnb2luZyB0 aHJvdWdoIHRoZSBSRkMgNjMxMSAuIA0KICANCkkgaGF2ZSBnb25lIHRocm91Z2ggeW91ciAgcHJv cG9zZWQgZHJhZnQgYW5kIGZlbHQgdGhhdCB0aGVyZSBpcyBzb21lIA0KY29uZnVzaW9uIHJlZ2Fy ZGluZyB0aGUgbWVzc2FnZSBpZCBjb25jZXB0IG9mIGlrZXYyLiANCiAgDQpJIGhhdmUgc2VlbiB0 aGF0IGluIHNlY3Rpb24gMi4zIHlvdSB3ZXJlIGNvbXBhcmluZyB0aGUgaGlnZXIgc2VuZGVyIHZh bHVlIA0Kb2YgeDIgd2l0aCB5Mi4gDQpUaGF0IGlzIHdyb25nLiB3aGVuIHgyIHByb3Bvc2VzIHRo ZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlkIHRvIGJlIHVzZWQgdG8gDQpzZW5kIGEgcmVxdWVzdCAs IA0KdGhlbiBvbiB5MiB5b3Ugc2hsZCB0YWxseSBpdCB3aXRoIHRoZSBuZXh0IGhpZ2hlciBtZXNz YWdlIGlkIG9mIHRoZSANCnJlcXVlc3QgdG8gYmUgcmVjaWV2ZWQgDQogICAgICAgICAgICAoYW5k IG5vdCB3aXRoIHRoZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJl IA0Kc2VudCkgDQogIA0KaW4gaWtldjIgdGhlICBtZXNzYWdlIGlkIG9mIHJlcXVlc3RzIHRvIGJl IHNlbnQgYXJlIGVudGlyZWx5IGRpZmZlcmVudCANCmZyb20gbWVzc2FnZSBpZCBvZiByZXF1ZXN0 cyB0byBiZSByZWNlaXZlZC4gDQp0aGF0IGlzIHdoeSBSRkMgc2F5cyBhIG1lc3NhZ2UgaWQgaXMg dXNlZCBmb3VyIHRpbWVzIG9uIGEgZ2l2ZW4gZGV2aWNlLiANCiAgDQoxLiBtZXNzYWdlIGlkIFgg aXMgdXNlZCB3aGlsZSBzZW5kaW5nIGEgcmVxdWVzdCANCjIuIG1lc3NhZ2UgaWQgWCBpcyB1c2Vk IHdoaWxlIHJlY2VpdmluZyB0aGUgcmVzcG9uc2UgDQozLiBtZXNzYWdlIGlkIFggaXMgdXNlZCB0 byByZWNlaXZlIGEgcmVxdWVzdCANCjQuIG1lc3NhZ2UgaWQgWCBpcyB1c2VkIHRvIHNlbmQgYSBy ZXNwb25zZS4gDQogIA0KICANCnBsZWFzZSBmaW5kIHRoZSBjb21tZW50cyBmb3IgZWFjaCBzZWN0 aW9uIA0KICANClNlY3Rpb24gMi4xOiAgVGhpcyBpcyBhIGtub3duIGlzc3VlIGFuZCB0aGF0IGlz IHdoeSB1c2luZyBSRkMgNjMxMSwgIHdlIA0KYXJlIHN5bmNocm9uaXNpbmcgdGhlIG1lc3NhZ2Ug aWQncyANCiAgDQpTZWN0aW9uIDIuMjogVGhlIHBlZXIgaXMgYXNzdW1lZCB0byBiZSBwcm9wZXIg YW5jaG9yIHBvaW50IHdoaWNoIGhhcyANCmNvcnJlY3QgaW5mbyBvZiBtZXNzYWdlIGlkIG9mIHJl cXVlc3RzIHNlbnQgYW5kIHJlY2lldmVkLCANCmV2ZW4gd2hlbiBwZWVyIGlzIGNsdXN0ZXIgbWVt YmVyICwgYW1vbmcgdGhlIHR3byBkZXZpY2VzIG9uZSBvZiB0aGVtIHdvdWxkIA0KYmUgbGVzcyB3 cm9uZyBhbmQgaGF2ZSBoaWdoZXIgYWNjdXJhdGUgdmFsdWVzIG9mIG1lc3NhZ2UgaWQncyAuIA0K c28gd2UgcGljayB1cCB0aGF0IHZhbHVlLiBJIGRvbnQgc2VlIGFueSBpc3N1ZSBoZXJlLiANCiAg DQpTZWN0aW9uIDIuMzogRmlyc3Qgb2YgYWxsIHRoZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW4g TTEgYW5kIFAxLiANCm9uIGEgZ2l2ZW4gZGV2aWNlLiANCi0tLSBNMSBpcyB0aGUgcHJvcG9zZWQg bWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSBzZW50IA0KICAgIFAxIGlzIHRoZSBwcm9w b3NlZCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHJlY2VpdmVkLiANCiAgDQp3aGVu IHNpbXVsYXRlbm91cyBmYWlsb3ZlciBoYXBwZW5zLCB4MiBtaWdodCBoYXZlIGhpZ2hlciB2YWx1 ZSBvZiBNMSB3aGVuIA0KY29tcGFyZWQgdG8geTIgLCBidXQgeDIgbWlnaHQgaGF2ZSBsb3dlciB2 YWx1ZSBvZiBQMSB3aGVuIGNvbXBhcmVkIHRvIHkyLiANCkl0IGRvZXMnbnQgbWF0dGVyLiBib3Ro IGFyZSBpbmRlcGVuZGVudC4gd2hhdCB3ZSBldmVudHVhbGx5IGRvIGlzIGNvbXBhcmUgDQp0aGUg TTEgdmFsdWUgYWNyb3NzIHgyIGFuZCB5MiBhbmQgcGljayB0aGUgaGlnZXIgb25lLiANCnNhbWUg cHJvY2VzcyBpcyByZXBlYXRlZCBmb3IgUDEuIA0KICANCmNhc2UgMSB0byA2IGFyZSBhbHJlYWR5 IGhhbmRsZWQgYnkgYmFzaWMgaWtldjIgUkZDIC4gbGlrZSBpZiB3ZSByZWNlaXZlIA0Kc2FtZSBt ZXNzYWdlIGlkIHR3aWNlICwgdGhlbiB3ZSByZXRyYW5zbWl0IG9yIGRyb3AgaXQgaWYgaXQgaXMg b3V0c2lkZSB0aGUgDQp3aW5kb3cuIA0KICANCiAgDQpTZWN0aW9uIDM6ICAgZHVyaW5nIHNpbXVs dGFuZW91cyBmYWlsb3ZlciBib3RoIHRoZSBjbHVzdGVyIGFuZCB0aGUgcGVlciANCm1lbWJlciB3 b3VsZCBiZSBpbiB1bnJlbGlhYmxlIHN0YXRlLiANCkJvdGggb2YgdGhlbSBhcmUgd3JvbmcgLCBi dXQgb25lIG9mIHRoZW0gaXMgbGVzcyB3cm9uZyAhISEgc28gd2Ugd2FudCB0byANCnN0YXJ0IGZy b20gdGhhdCBwb2ludCB0byBzeW5jaHJvbmlzZSB0aGUgbWVzc2FnZSBpZCdzLiANCiAgDQpzbyB3 ZSBhcmUgYWxsb3dpbmcgYm90aCB0aGUgbWVtYmVycyB0byBhbm5vdW5jZSB0aGVpciBtZXNzYWdl IGlkJ3MgYW5kIA0KdGhlbiBldmVudHVhbGx5IHdlIHdvdWxkIHN5bmNocm9uaXNlIHRvIHRoZSBo aWdoZXIgbnVtYmVyLiANCkkgZG9udCBzZWUgYW55IGZsYXcgaGVyZS4gUGxlYXNlIGV4cGxhaW4g d2l0aCBhbiBleGFtcGxlLiANCiAgDQpCeSB5b3VyIHByb3Bvc2FsIGluIGNhc2Ugb2Ygc2ltdWx0 YW5lb3VzIGZhaWxvdmVyLCBib3RoIHRoZSBjbHVzdGVyIGFuZCANCnBlZXIgd2lsbCBiZSBpbiBV TlNZTkVEIHN0YXRlIGFuZCANCmJvdGggd291bGQgZW5kIHVwIHNlbmRpbmcgYW5kIHJlamVjdGlu ZyB0aGUgc3luY2hyb25pc2F0aW9uIHJlcXVlc3QuIA0KVGhpcyB3b3VsZCBsZWFkIHRvIHJlcGVh dGVkIHN5bmNocm9uaXNhdGlvbiBlZmZvcnRzIGFuZCB0aGUgcHJvYmxlbSBvZiANCm1lc3NhZ2Ug c3luY2hyb25pc2F0aW9uIGlzIG5ldmVyIHNvbHZlZC4gDQogIA0Kc28gVU5TWU5FRCBzdGF0ZSBp cyBub3QgcmVxdWlyZWQuIA0KICANClNlY3Rpb24gNDogDQogIA0KSSBmZWVsIHRoYXQgUkZDIDYz MTEgYWxyZWFkeSBzb2x2ZXMgdGhlIG1lc3NhZ2UgaWQgc3luY2hyb25pc2F0aW9uIGlzc3VlLiAN CkkgZG9udCB0aGluayB3ZSBuZWVkIHRvIGluY3JlbWVudCBNMSBieSBkb3VibGUgdGhlIHdpbmRv dyBzaXplIGFzIHByb3Bvc2VkIA0KYnkgeW91LiANClBsZWFzZSBzdXBwb3J0IHlvdXIgcHJvcG9z YWwgd2l0aCBhbiBleGFtcGxlIHdpdGggbWVzc2FnZSBpZCB2YWx1ZXMgb2YgDQpudW1iZXJzIGlu c3RlYWQgb2YgdmFyaWFibGVzLiANCkxpa2UgTTEgaXMgMyAsIE0yIGlzIDQgZXRjIGV0Yy4gDQog IA0KTnVtYmVycyBtYWtlIGl0IG1vcmUgY2xlYXIuIA0KICANCnJlZ2FyZHMsIA0Ka2FseWFuaSAN CiAgDQpGcm9tOiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KemhhbmcucnVpc2hhbkB6dGUuY29tLmNuDQpTZW50OiBN b25kYXksIEp1bmUgMTEsIDIwMTIgNzozNiBBTQ0KVG86IGlwc2VjQGlldGYub3JnDQpTdWJqZWN0 OiBbSVBzZWNdIFVwZGF0ZXMgdG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMg SGlnaCANCkF2YWlsYWJsaXR5IA0KICANCg0KDQpEZWFyIEFsbCwgDQoNCiBJJ3ZlIHN1Ym1pdHRl ZCBhIG5ldyBkcmFmdCAiIFVwZGF0ZXMgdG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgDQpJS0V2 Mi9JUHNlYyBIaWdoIEF2YWlsYWJsaXR5Ii4gVGhpcyBkcmFmdCBhbmFseXplcyBzb21lIGlzc3Vl cyBpbiBSRkMgDQo2MzExLCANCmFuZCBwcm9wb3NlcyBzb21lIHVwZGF0ZXMuIExvb2sgZm9yd2Fy ZCB0byB5b3VyIGNvbW1lbnRzLiANCg0KDQpCUiwgDQoNClJ1aXNoYW4gWmhhbmdfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0 DQpJUHNlY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHNlYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQ c2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQo= --=_alternative 0010751848257A24_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEthbHlhbmk8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSBzZWUgdGhlIGlu bGluZSBjbGFyaWZpY2F0aW9ucy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkJSLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+UnVpc2hhbjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj4mcXVvdDtLYWx5YW5pIEdhcmlnaXBhdGkNCihrYWdhcmlnaSkmcXVvdDsg Jmx0O2thZ2FyaWdpQGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtpcHNlYy1ib3VuY2VzQGlldGYub3JnPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDYtMjAgMTg6MjY8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ JnF1b3Q7emhhbmcucnVpc2hhbkB6dGUuY29tLmNuJnF1b3Q7DQombHQ7emhhbmcucnVpc2hhbkB6 dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7aXBzZWNAaWV0Zi5vcmcmcXVv dDsgJmx0O2lwc2VjQGlldGYub3JnJmd0OywNCiZxdW90O2lwc2VjLWJvdW5jZXNAaWV0Zi5vcmcm cXVvdDsgJmx0O2lwc2VjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW0lQc2VjXSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24NCmZvciBJS0V2Mi9JUHNl YyBIaWdoIEF2YWlsYWJsaXR5PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SGkgWmhhbmcsPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48 Yj5Gb3IgQW5hbHlzaXMgMSA8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0 OTdkIGZhY2U9IkNhbGlicmkiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YTBbdF0ueCAmbmJzcDthMCdzIG1heGltdW0NCm1lc3NhZ2Ug SUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBiIHVudGlsIHRpbWUgdCAmbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YTBbdF0ueSAmbmJz cDthMCdzIG5leHQgc2VuZGVyDQptZXNzYWdlIElEICZuYnNwO2F0IHRpbWUgdCA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkkgdGhpbmsg dGhlcmUgaXMgY29uZnVzaW9uDQphYm92ZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SSBndWVzcyB3aGF0IHUgYWN0dWFsbHkgd2FudGVkDQp0 byBjb252ZXkgaXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj5hMFt0XS54ICZuYnNwO2EwJ3MgbWF4aW11bQ0KbWVzc2FnZSBJRCBvZiB0 aGUgcmVxdWVzdCBzZW50IGFuZCBvcmRlcmx5IHJlc3BvbnNlIHJlY2VpdmVkIGZyb20gdGhlIHBl ZXINCmIgdW50aWwgdGltZSB0ICwgc2F5IGlmIGEgaGFzIHJlY2VpdmVkIHJlc3BvbnNlcyBmb3Ig MiBhbmQgMyBhbmQgNSAmbmJzcDssDQp0aGlzIHZhbHVlIGlzIDMuIFNvIG5vdyB0aGUgd2luZG93 IHdvdWxkIGJlIDQtOCAoaW5jbHVzaXZlKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hMFt0XS55ICZuYnNwO2EwJ3MgbmV4dCByZXF1ZXN0DQpt ZXNzYWdlIElEIHRvIGJlIHNlbnQgYXQgdGltZSB0ICwgdGhpcyB2YWx1ZSBpcyA2ICwgaWYgaXQg aGFzIGFscmVhZHkgc2VudA0KdGhlIHJlcXVlc3RzIDIsMyw0LDUsIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Ylt0XS54ICZuYnNwOyBi J3MgbWF4aW11bQ0KbWVzc2FnZSBJRCBvZiB0aGUgb3JkZXJseSByZXNwb25zZSBzZW50IHRvIGNs dXN0ZXIgJm5ic3A7dW50aWwgdGltZSB0ICwNCmlmIGl0IGhhcyBzZW50IHJlc3BvbnNlIHRvIDIs MyBhbmQgNSBpZCByZXF1ZXN0cyAsIGl0IGlzIHN0aWxsIDMuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmJbdF0ueSAmbmJzcDsgYidzIG5leHQg bWVzc2FnZQ0KaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgcmVjZWl2ZWQsIHdoaWNoIGlzIDYgPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Ly8g Jm5ic3A7QSBjbGFyaWZpY2F0aW9uIGFib3V0DQp4OiAmbmJzcDthMFt0XS54IGlzIHJlbGV2YW50 IHRvIHRoZSBtYXhpbXVtIE1lc3NhZ2UgSUQgb2YgdGhlIHJlY2VpdmVkDQpyZXF1ZXN0IG1lc3Nh Z2UgZm9yIHRoZSBvcHBvc2l0ZSBJS0UgdjIgcGFydHkuIFNheSAmbmJzcDt1bnRpbCB0aW1lIFQw LA0KYTAgaGFzIHJlY2VpdmVkIDUgLy9yZXF1ZXN0IG1lc3NhZ2VzIGZyb20gYiwgYW5kIHRoZSBN ZXNzYWdlIElEcyBhcmUgMSwNCjIsIDMsIDQsIDUuIFRoZW4gYTBbVDBdLnggPT0gNS4gU2F5IHVu dGlsIHRpbWUgVDAsIGIgaGFzIHJlY2VpdmVkIDQgcmVxdWVzdA0KbWVzc2FnZXMgZnJvbSBhLCBh bmQgdGhlIE1lc3NhZ2VzIElEcyBhcmUgLy80LDUsIDYsIDcuIFRoZW4gYltUMF0ueCA9PQ0KNy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4vL0FjdHVh bGx5LCAmbmJzcDt4IGlzIGlycmVsZXZhbnQNCnRvIHkuICZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SSBndWVzcyB0aGUgZXhh bXBsZSBoYXMgd3JvbmcNCnZhbHVlcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmlmIHdpbmRvdyBzaXplIGlzIDUgPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj50aGVuIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Rm9y IGEgY29uY3JldGUgZXhhbXBsZSwgbGV0J3MNCmFzc3VtZTogPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hMVtUMF0ueCA9PSBhMFtUMF0u eCA9IDkNCi0tLS0tLS0tLS0tLS0tLWhvdyBjYW4geCBhbmQgeSB2YXJ5IGJ5IDEwIHdoZW4gdGhl IHdpbmRvdyBzaXplIGlzIDUgJm5ic3A7PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 cmVkIGZhY2U9IkNhbGlicmkiPi8vIFVudGlsIFQwLCBhMCBoYXMgcmVjZWl2ZWQNCjkgcmVxdWVz dCBNZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIDMsNCwgNSwgNiw3LDgsOSBmcm9tIHRo ZSBwZWVyDQpiIC4gU28gdGhlIGEwW1QwXS54ID09OSA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YTFbVDBdLnkgPT0gYTBb VDBdLnkgPSAyMA0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkNhbGli cmkiPi8vDQombmJzcDtVbnRpbCBUMCwgYTAgaGFzIHNlbnQgMTkgcmVxdWVzdCBNZXNzYWdlcyB3 aXRoIE1lc3NhZ2UgSURzIDEsIDIsDQozLDQsIDUsIC4uLiwxOSB0byB0aGUgcGVlciBiLiBTbyB0 aGUgYTBbVDBdLnkgJm5ic3A7PT0yMDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9cmVk IGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj5iW1QwXS54ID0gMTkgJm5ic3A7IC0tIHNhbWUNCmlzIHRoZSBj YXNlIGhlcmUuLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkNhbGli cmkiPi8vIFVudGlsIFQwLCB0aGUgcGVlciBiIGhhcyByZWNlaXZlZA0KMTkgcmVxdWVzdCBNZXNz YWdlcyB3aXRoIE1lc3NhZ2UgSURzIDEsIDIsIDMsLi4uLDE5IGZyb20gdGhlIG9sZCBhY3RpdmUN Cm1lbWJlciBhMCAuIFNvIHRoZSBiW1QwXS54ID09MTkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmJbVE9dLnkgPSAxMCA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4vLyBVbnRpbCBUMCwgdGhlIHBl ZXIgYiBoYXMgc2VudA0KOSByZXF1ZXN0IE1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgMSwgMiwg MywuLi4sOSB0byB0aGUgb2xkIGFjdGl2ZSBtZW1iZXINCmEwIC4gU28gdGhlIGJbVDBdLnkgPT05 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+UGxlYXNlIGFkanVzdCB0aGVzZSB2YWx1ZXMNCmFuZCB0aGVuIHRoZXJlIHdpbGwgYmUgbm8g aXNzdWVzIGFzIG1lbnRpb25lZCBieSB5b3UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hbHNvIHBsZWFzZSByZWZlciB0byB0aGUNCnNl Y3Rpb24gOC4xIGFuZCA5IG9mIHRoZSBSRkMgNjMxMSB3aGljaCBzYXlzIHRoYXQgd2hlbiB0aGUg d2luZG93IG1vdmVzDQp0byB0aGUgc3luY2hyb25pc2VkIHZhbHVlLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hbGwgdGhlIG9sZCBwZW5kaW5n IHJlcXVlc3RzDQphbmQgdG8tYmUgcmV0cmFuc21pdHRlZCByZXNwb25zZXMgc2hvdWxkIGJlIGRl bGV0ZWQuIFNvIHRoZSBiZWxvdyBpc3N1ZQ0Kd2lsbCBub3QgaGFwcGVuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzAwNzBjMCBmYWNlPSJDYWxpYnJpIj48aT5XaGVuIHRoZSBu ZXcgYWN0aXZlIG1lbWJlcg0KYTEgc2VuZHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2Vz IElEcyAyNSwgMjYsMjcsMjgsMjksIHNpbmNlIHRoZQ0KcGVlciBiIGhhcyBwcm9jZXNzZWQgdGhl IHJlcXVlc3QgbWVzc2FnZSB3aXRoIHRoZSBzYW1lIDwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+PGk+TWVzc2FnZSBJRHMsIHRoZSBwZWVy DQpiIHdpbGwgcmV0dXJuIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVxdWVzdCBtZXNzYWdl cyBmcm9tIHRoZSBvbGQgYWN0aXZlDQptZW1iZXIgYTAuIDwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+PGk+Jm5ic3A7PC9pPjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNzBjMCBmYWNlPSJDYWxpYnJpIj48aT5UaGVuIGEx IHJlY2VpdmVzIGFjY2VwdGFibGUNCmJ1dCBtaXNtYWN0aGVkIHJlc3BvbnNlIG1lc3NhZ2VzLjwv aT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+ PGk+Jm5ic3A7PC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj48Yj5Gb3IgQW5hbHlzaXMgMjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoaXMgaXMgdGhlIHByb2JsZW0gb2Yg YmFzaWMNCkhBIHNpbXVsYXRlbm91cyBmYWlsLW92ZXIgYW5kIG5vdCBqdXN0IGFib3V0IG1lc3Nh Z2UgSUQgc3luY2hyb25pc2F0aW9uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+d2hlbiBib3RoIG9mIHRoZSBkZXZpY2VzDQpkb26hr3Qg aGF2ZSBuZXcgc2EgYW5kIGp1c3QgaGF2ZSB0aGUgb2xkIHNhLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5UaGVuIHRoZXkgd2lsbCAmbmJzcDtj b250aW51ZQ0Kd2l0aCB0aGUgb2xkIHNhIG9yIGJyaW5nIGRvd24gdGhlIHNhIGJhc2VkIG9uIHRo ZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9cmVkIGZhY2U9IkNhbGlicmkiPi8vIEknbSBOT1Qgc3VyZSB3aGV0aGVyIGNvbnRpbnVp bmcNCndpdGggdGhlIG9sZCBzYSB3aWxsIGNhdXNlIHNvbWUgc2VjdXJpdHkgcmlza3Mgb3Igbm90 LiAmbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj50aGUgc3luYyB0aW1lIHdpdGhpbiBhIGNsdXN0ZXINCiZuYnNwO2Ftb25nIGEg YW5kIGIgbWlnaHQgYmUgc2FtZSBvciBkaWZmZXJlbnQgZHVlIHRvIHdoaWNoIG9uZSBvZiB0aGVt DQp3b3VsZCBoYXZlIG9sZCBzYSBhbmQgYW5vdGhlciB3b3VsZCBoYXZlIG5ldyBzYS4gaW4gc3Vj aCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ Y2FzZXMgYm90aCB0aGUgc2Egd291bGQgYmUNCmRlbGV0ZWQgZXZlbnR1YWxseSBhbmQgbmV3IHNh IGlzIGVzdGFibGlzaGVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+b3IgZXZlbiBpZiBzeW5jIHRpbWVzIGFyZQ0KZGlmZmVyZW50LCBv bmUgd291bGQgaGF2ZSBvbGQgc2Egd2l0aCBsZXNzZXIgbWVzc2FnZSBpZCdzIGFuZCBvdGhlciBo YXZlDQpzYW1lIG9sZCBzYSB3aXRoIGhpZ2hlciBtZXNzYWdlIGlkJ3MgYW5kIHRoZW4gYm90aCB3 aWxsIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij5zdGFydCBmcm9tIHRoZSBoaWdoZXIgbWVzc2FnZQ0KaWQgdmFsdWVzLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UmVnYXJkcyw8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+a2FseWFu aTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+ IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj56aGFuZy5ydWlzaGFuQHp0ZS5jb20uY248Yj48YnI+DQpTZW50 OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDIwLCAyMDEyIDc6NDQgQU08Yj48YnI+DQpUbzo8L2I+IEth bHlhbmkgR2FyaWdpcGF0aSAoa2FnYXJpZ2kpPGI+PGJyPg0KQ2M6PC9iPiBpcHNlY0BpZXRmLm9y ZzsgaXBzZWMtYm91bmNlc0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW0lQc2Vj XSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYyL0lQc2VjDQpIaWdoIEF2 YWlsYWJsaXR5PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBLYWx5YW5p LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkZpcnN0IEknZCBsaWtlIHRv IG1ha2Ugc29tZSBjbGFyaWZpY2F0aW9ucyBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cywNCmFu ZCBsZWF2ZSBvdGhlciBjbGFyaWZpY2F0aW9ucyB0byBmdXJ0aGVyIGRpc2N1c3Npb25zLjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCjEuIENsYXJpZmljYXRpb24gZm9yIGNh c2UgQyBpbiBTZWN0aW9uIDIuMjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQooY2FzZSBDIGlzIHRoZSBt b3N0IHRyb3VibGVzb21lIGluIHRoaXMgc2VjdGlvbiBJTU8uU28gSSdkIGxpa2UgdG8gY2xhcmlm eQ0KaXQuKTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjEuMSBOb3RhdGlvbiBmb3IgY2FzZSBDIGluIFNl Y3Rpb24gMi4yPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCng6IHRoZSBtYXhpbXVtIG1lc3Nh Z2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBwYXJ0eTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQp5 OiB0aGUgbmV4dCBzZW5kZXIgbWVzc2FnZSBJRDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmEw OiB0aGUgb2xkIGFjdGl2ZSBjbHVzdGVyIG1lbWJlcjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMTog dGhlIG5ldyBhY3RpdmUgY2x1c3RlciBtZW1iZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYjogJm5i c3A7dGhlIHBlZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMFt0XS54ICZuYnNw O2EwJ3MgbWF4aW11bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiB1bnRpbCB0 aW1lDQp0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTBbdF0ueSAmbmJzcDthMCdzIG5leHQgc2VuZGVy IG1lc3NhZ2UgSUQgJm5ic3A7YXQgdGltZSB0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmEx W3RdLnggJm5ic3A7YTEncyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVl ciBiICZuYnNwO3VudGlsDQp0aW1lIHQgPGJyPg0KYTFbdF0ueSAmbmJzcDthMSdzIG5leHQgc2Vu ZGVyIG1lc3NhZ2UgSUQgJm5ic3A7YXQgdGltZSB0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CmJbdF0ueCAmbmJzcDsgYidzIG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9tIHRoZSBj bHVzdGVyICZuYnNwO3VudGlsDQp0aW1lIHQgPGJyPg0KYlt0XS55ICZuYnNwOyBiJ3MgbmV4dCBz ZW5kZXIgbWVzc2FnZSBJRCBhdCB0aW1lIHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KVDA6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIGxhc3Qgc3luY2hyb25pemF0aW9uIGJldHdl ZW4gYTAgYW5kIGExIGlzIGNhcnJpZWQNCm91dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClQx OiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBmYWlsb3ZlciBldmVudCBvY2N1cnM8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KVDI6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIE1lc3NhZ2UgSUQg c3luY2hyb25pemF0aW9uIGJldHdlZW4gYTEgYW5kIGINCnN0YXJ0czwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPjxicj4NClQzOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5 bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiDQplbmRzPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KU1c6IHRoZSBzZW5kZXIgd2luZG93IHNpemUgb2YgdGhlIGNsdXN0ZXIuIExldCdzIGFz c3VtZSBTVyBpcyA1LiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCi0tLS1UMC0tLS0tLS0tVDEt LS0tLS0tLS0tVDItLS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGJyPg0KMS4yIEFuYWx5c2lzIGZv ciBjYXNlIEMgaW4gU2VjdGlvbiAyLjI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K V2Uga25vdyB0aGF0OiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmExW1QwXS54ID09IGEwW1Qw XS54PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTFbVDBdLnkgPT0gYTBbVDBdLnk8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQooVGhlIHJlYW9uIGlzIHRoYXQgYXQgVDAsIHRoZSBzeW5jaHJvbml6YXRpb24gYmV0 d2VlbiBhMCBhbmQgYTEgaXMgY2FycmllZA0Kb3V0Lik8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpBbmQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtUMV0ueCA9PSBhMFtUMF0u eCA8YnI+DQphMVtUMV0ueSA9PSBhMFtUMF0ueTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFu ZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmExW1QyXS54ID09IGEwW1QwXS54IDxicj4NCmEx W1QyXS55ID09IGEwW1QwXS55PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KKFRoZSByZWFvbiBp cyB0aGF0IGZyb20gVDAgdG8gVDIsIHRoZSBzdGF0ZSBkYXRhIG9mIGExIGtlZXBzIHVuY2hhbmdl ZC4pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFjY29yZGluZyB0byBSRkMgNjMxMSwgPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQomcXVvdDtNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNz YWdlIElEIHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gJm5ic3A7TTE8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KTVVTVCBiZSBjaG9zZW4gc28gdGhhdCBpdCBpcyBsYXJnZXIgdGhhbiBhbnkgdmFsdWUg a25vd24gdG8gaGF2ZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiZWVuIHVzZWQuICZuYnNwO0l0IGlz IFJFQ09NTUVOREVEIHRvIGluY3JlbWVudCB0aGUga25vd24gdmFsdWUgYXQ8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KbGVhc3QgYnkgdGhlIHNpemUgb2YgdGhlIElLRSBzZW5kZXIgd2luZG93LiZxdW90 OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBdCBUMiwgdGhlIG5ldyBhY3RpdmUgbWVtYmVy IGExIGNhbiBzZXQgTTE9YTFbVDJdLnkgKyBTVy4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQpBbmQgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQomcXVvdDtNMiBNVVNUIGJlIGF0IGxl YXN0IHRoZSBoaWdoZXIgb2YgdGhlIHJlY2VpdmVkIE0xLCBhbmQgb25lIG1vcmU8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhbiB0aGUgaGlnaGVzdCBzZW5kZXIg dmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4NCiZuYnNwO1RoaXM8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2 ZWQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2VzLiZxdW90OzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCkF0IFQyLCB0aGUgcGVlciBi IGNhbiBzZXQgTTIgPSBtYXgoTTEsIDEgKyBiW1QyXS54KS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KTTE9PWExW1QyXS55ICsgU1cgPSZndDsgTTEgPT0gYTBbVDBdLnkgKyBTVyAmbmJzcDs9 Jmd0OyBNMSA9PSBhMFtUMF0ueQ0KKyA1PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KU3VwcG9z ZSBzb21lIG1lc3NhZ2UgZXhjaGFuZ2VzIChpLmUuLCAxMCBtZXNzYWdlcykgaGF2ZSBiZWVuIGNh cnJpZWQgb3V0DQpmcm9tIFQwIHRvIFQyLCBpdCdzIHBvc3NpYmxlIHRoYXQgYltUMl0ueCArIDEg Jmd0OyBhMFtUMF0ueSArIDUuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlbiB0aGUgcGVl ciBiIHNldHMgTTI9MSArIGJbVDJdLnguPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkF0IFQz LCB3aGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSByZWNlaXZlcyB0aGUgTWVzc2FnZSBJRCBz eW5jaHJvbml6YXRpb24NCnJlc3BvbnNlIGZyb20gdGhlIHBlZXIgYiwgYTEgJm5ic3A7c2V0cyBh MVtUM10ueSA9IE0yLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtUM10ueSA9PSBNMiA9 Jmd0OyBhMVtUM10ueSA9PTEgKyBiW1QyXS54LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQpBdCBUMiwgYTBbVDJdLnkgY291bGQgYmUgYltUMl0ueCs1LiA8YnI+DQooVGhlIHJlYW9u IGlzIHRoYXQgYTAncyBzZW50IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBi W1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUNCm1heSBOT1QgaGF2ZSByZWFj aGVkIHRvIHRoZSBwZWVyIGIuKSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoaXMgbWVhbnMg YTFbVDNdLnkgJmx0OyBhMFtUMl0ueS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhpcyBt ZWFucyB0aGUgZmlyc3QgZml2ZSBtZXNzYWdlcyBzZW50IGJ5IHRoZSBuZXcgYWN0aXZlIG1lbWJl ciBhMSB3aWxsDQpoYXZlIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltUMl0ueCsyLGJbVDJdLngr MyxiW1QyXS54KzQsYltUMl0ueCs1LiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClN1cHBvc2Ug YWZ0ZXIgVDMsIHRoZSBwZWVyIHJlY2VpdmVzIHRoZSBvbGQgYWN0aXZlIG1lbWJlciBhMCdzIHNl bnQgbWVzc2FnZXMNCndpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0u eCszLGJbVDJdLngrNCxiW1QyXS54KzUsIGFuZA0Kc2VuZHMgcmVzcG9uc2UgbWVzc2FnZXMuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQWZ0ZXIgdGhhdCwgdGhlIG5ldyBhY3RpdmUgbWVtYmVy IGExIHNlbmRzIHRoZSBmaXJzdCBmaXZlIHJlcXVlc3QgbWVzc2FnZXMNCndpdGggTWVzc2FnZSBJ RHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCkFmdGVyIHJlY2V2aW5nIHRoZXNlIHJlcXVlc3QgbWVzc2FnZXMs IHRoZSBwZWVyIGIgd2lsbCByZWdhcmRzIHRoZXNlIHJlcXVlc3RzDQphcyByZXNlbnQgbWVzc2Fn ZXMsIGFuZCByZXR1cm5zIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciA8YnI+DQpyZXF1ZXN0cyBvZiAm bmJzcDthMCdzIHNlbnQgbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBiW1QyXS54KzEsIGJbVDJd LngrMixiW1QyXS54KzMsYltUMl0ueCs0LGJbVDJdLngrNQ0KdG8gYTEuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KKE15IHVuZGVyc3RhbmRpbmcsIGFjY29yZGluZyB0byBSRkMgNTk5NiwgaXMgdGhhdCB0 aGUgcGVlciBzaG91bGQgdHJlYXQNCnRoZSBuZXcgYWN0aXZlIG1lbWJlcidzIHJlcXVlc3QgbWVz c2FnZXMgYXMgcmVzZW50IHJlcWV1c3RzLiApPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyByZS1zZW50ICZuYnNwOyAmbmJzcDsgPGJyPg0KQXMgYSByZXN1 bHQsIHRoZSBwZWVyIGIgcmVjZWl2ZXMgYWNjZXB0YWJsZSBidXQgbWlzbWF0Y2hlZCByZXNwb25z ZXMgZm9yDQppdHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIGExW1QyXS54KzEs IGExW1QyXS54KzIsYTFbVDJdLngrMyxhMVtUMl0ueCs0LGExW1QyXS54KzUuPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KRm9yIGEg Y29uY3JldGUgZXhhbXBsZSwgbGV0J3MgYXNzdW1lOiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CmExW1QwXS54ID09IGEwW1QwXS54ID0gOTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmExW1QwXS55ID09 IGEwW1QwXS55ID0gMjA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiW1QwXS54ID0gMTk8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48YnI+DQpiW1RPXS55ID0gMTA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpG cm9tIFQwIHRvIFQxLCB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAgaGF2ZSBzZW50IDEwIHJlcXVl c3QgbWVzc2FnZXMgdG8NCnRoZSBwZWVyIGIsIGFuZCA1IG1lc3NhZ2VzIGhhdmUgYmVlbiByZWNl aXZlZCBhbmQgYWNrbm93bGVkZ2VkIGJ5IHRoZSBwZWVyDQpiLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NClRoaXMgbWVhbnMgdGhhdCBhMFtUMl0ueSA9IDMwLCBiW1QyXS54ID0gMjQuIE5vdGUg cmVxdWVzdCBtZXNzYWdlcyB3aXRoDQpNZXNzYWdlIElEIDI1LDI2LDI3LDI4LDI5IGhhdmUgYmVl biBzZW50IGJ5IHRoZSBvbGQgYWN0aXZlIG1lbWJlciBhMCwgYnV0DQpoYXZlIE5PVCByZWFjaGVk IHRoZSBwZWVyIGIwLiAoVGhlIHNlbmRlciB3aW5kb3cgc2l6ZSBvZiB0aGUgY2x1c3RlciBpcw0K NS4pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQWNjb3JkaW5nIHRvIFJGQyA2MzEx LCA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiZxdW90O00xIGlzIHRoZSBuZXh0IHNlbmRlcidz IE1lc3NhZ2UgSUQgdG8gYmUgdXNlZCBieSB0aGUgbWVtYmVyLiAmbmJzcDtNMTwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQpNVVNUIGJlIGNob3NlbiBzbyB0aGF0IGl0IGlzIGxhcmdlciB0aGFuIGFueSB2 YWx1ZSBrbm93biB0byBoYXZlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmJlZW4gdXNlZC4gJm5ic3A7 SXQgaXMgUkVDT01NRU5ERUQgdG8gaW5jcmVtZW50IHRoZSBrbm93biB2YWx1ZSBhdDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpsZWFzdCBieSB0aGUgc2l6ZSBvZiB0aGUgSUtFIHNlbmRlciB3aW5kb3cu JnF1b3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4gPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Ly8NCk0xIGlzIHNvbWV3aGF0IHJlbGV2 YW50IHRvIGFueSB2YWx1ZSBrbm93biB0byBoYXZlIGJlZW4gdXNlZCAoIE1lc3NhZ2UNCklEcyBv ZiByZXF1ZXN0IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIHNlbnQgdG8gdGhlIHBlZXIgYi4gKTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KTTEgPT0gYTFbVDJdLnkgKyBTVyA9PSAyMCArIDUgPT0g MjU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KKGExW1QyXS55ID09IGExW1QwXS55ID09IDIwKTwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCkFuZCA8YnI+DQomcXVvdDtNMiBNVVNUIGJlIGF0IGxlYXN0 IHRoZSBoaWdoZXIgb2YgdGhlIHJlY2VpdmVkIE0xLCBhbmQgb25lIG1vcmU8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KdGhhbiB0aGUgaGlnaGVzdCBzZW5kZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUg Y2x1c3Rlci4gJm5ic3A7VGhpczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQppbmNsdWRlcyBhbnkgcHJl dmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2VzLiZxdW90OzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4vLzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7VW50aWwgVDAsIE0yIGlzIHNvbWV3aGF0DQpyZWxldmFudCB0byB0aGUgaGlnaGVzdCBzZW5k ZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3RlciAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4oTWVzc2FnZSBJRHMgb2YgcmVxdWVz dCBtZXNzYWdlcw0KdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4gJm5i c3A7TTIgaXMgc29tZXdoYXQgcmVsZXZhbnQNCmJbVDJdLngpPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YnI+DQpNMiA9PSBtYXh7TTEsIDEgKyBiW1QyXS54KT09IG1heCgyNSwxKzI0KSA9PSAyNTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBZnRlciB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEg cmVjZWl2ZXMgTTIsIGExIHNldHMgYTFbVDJdLnkgPT0gMjUgJmx0Ow0KYTBbVDJdLnkgPT0gMzAu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIE1lc3NhZ2UgSUQgZm9yIHRoZSBuZXcgYWN0 aXZlIG1lbWJlciBhMSBudW1iZXJzIGZyb20gMjUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N ClRoZSBmaXJzdCBmaXZlIE1lc3NhZ2UgSURzIGFyZSAyNSwgMjYsIDI3LDI4LDI5LjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQpXaGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBzZW5kcyBy ZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZXMgSURzDQoyNSwgMjYsMjcsMjgsMjksIHNpbmNl IHRoZSBwZWVyIGIgaGFzIHByb2Nlc3NlZCB0aGUgcmVxdWVzdCBtZXNzYWdlIHdpdGgNCnRoZSBz YW1lIE1lc3NhZ2UgSURzLCB0aGUgcGVlciBiIHdpbGwgcmV0dXJuIHJlc3BvbnNlIG1lc3NhZ2Vz IGZvciB0aGUNCnJlcXVlc3QgbWVzc2FnZXMgZnJvbSB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoZW4gYTEgcmVjZWl2ZXMgYWNjZXB0YWJsZSBi dXQgbWlzbWFjdGhlZCByZXNwb25zZSBtZXNzYWdlcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCjIuIENsYXJpZmljYXRpb25zIGZv ciB0aGUgc2ltdWx0YW5lc291cyBmYWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjMNCjxicj4N CkZvciB0aGUgc2ltdWx0YW5lb3VzIGZhaWxvdmVyLCBjYXNlIEYgaXMgdGhlIG1vc3QgZGV2YXN0 YXRpbmcgSU1PLiBTbyBJJ2QNCmxpa2UgdG8gY2xhcmlmeSBpdCBmaXJzdC48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQoyLjEgTm90YXRpb24gZm9yIHRoZSBzaW11bHRhbmVzb3VzIGZhaWxvdmVyIGNhc2Ug RiBpbiBTZWN0aW9uIDIuMzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMDogdGhl IG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYTwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQphMTogdGhlIG5ldyBhY3RpdmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIg YTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiMDogdGhlIG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXIg b2YgdGhlIGNsdXN0ZXIgYjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiMTogdGhlIG5ldyBhY3RpdmUg Y2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpUMDogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgbGFzdCBzeW5jaHJvbml6YXRpb24g YmV0d2VlbiBhMC9iMCBhbmQgYTEvYjENCmlzIGNhcnJpZWQgb3V0LCA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NClQxOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBzaW11bHRhbmVvdXMgZmFpbG92 ZXIgZXZlbnQgb2NjdXJzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClQyOiBBdCB0aGlzIHRp bWUgcG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBi MQ0Kc3RhcnRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVDM6IEF0IHRoaXMgdGlt ZSBwb2ludCwgdGhlIE1lc3NhZ2UgSUQgc3luY2hyb25pemF0aW9uIGJldHdlZW4gYTEgYW5kIGIx DQplbmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0K PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KLS0tLVQwLS0tLS0t LS1UMS0tLS0tLS0tLS1UMi0tLS0tLS0tLS1UMy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGJyPg0KMi4yIEFuYWx5c2lzIGZvciB0aGUgc2ltdWx0YW5lc291cyBm YWlsb3ZlciBjYXNlIEYgaW4gU2VjdGlvbiAyLjM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KSXQncyBwb3NzaWJsZSB0aGF0IGZyb20gVDAgdG8gVDEsIGEwIGFuZCBiMCBkZWxldGVz IHRoZSBvbGQgSUtFIFNBIHNhMA0KYW5kIGNyZWF0ZXMgYSBuZXcgSUtFIFNBIHNhMS48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpCdXQgYXQgVDIsIGExIGFuZCBiMSBkbyBOT1Qga25vdyB3aGF0IGhhcyBo YXBwZW5lZCBmcm9tIFQwIGFuZCBUMSwgYW5kDQpkbyBOT1Qga25vdyB0aGUgZXhpc3RhbmNlIG9m IHRoZSBuZXcgSUtFIFNBIHNhMSwgYW5kIHVzZSB0aGUgb2xkIElLRSBTQQ0Kc2EwIHRvIGNhcnJ5 IG91dCBNZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhp cyBtYXkgYnJpbmcgc29tZSBtb3JlIHNlcmlvdXNlIHByb2JsZW0uIFNvICZuYnNwO3doZW4gc2lt dWx0YW5lb3VzIGZhaWxvdmVyDQpvY2N1cnMsIGEgc2ltcGxlIHR3by13YXkgc3luY2hyb25pemF0 aW9uICZuYnNwO21heSBub3QgYmUgYW4gYXBwcm9wcmlhdGUNCnNvbHV0aW9uLjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZxdW90 O0thbHlhbmkgR2FyaWdpcGF0aSAoa2FnYXJpZ2kpJnF1b3Q7DQombHQ7PC9iPjwvZm9udD48YSBo cmVmPW1haWx0bzprYWdhcmlnaUBjaXNjby5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0iQXJpYWwiPjxiPjx1PmthZ2FyaWdpQGNpc2NvLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9u dCBzaXplPTEgZmFjZT0iQXJpYWwiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCreivP7IyzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJp YWwiPjogJm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3Jn Ij48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aXBzZWMtYm91bmNlc0Bp ZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MjAxMi0wNi0xNCAxOToxNDwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMl Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD02 JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MyU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4m cXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPjxmb250 IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT56aGFuZy5ydWlzaGFuQHp0ZS5jb20u Y248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90Ow0KJmx0Ozwv Zm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PnpoYW5nLnJ1aXNoYW5AenRlLmNvbS5jbjwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jmd0OywNCiZxdW90OzwvZm9udD48 YSBocmVmPW1haWx0bzppcHNlY0BpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNl PSJBcmlhbCI+PHU+aXBzZWNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFj ZT0iQXJpYWwiPiZxdW90Ow0KJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzppcHNlY0BpZXRmLm9y Zz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aXBzZWNAaWV0Zi5vcmc8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJBcmlhbCI+UmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIg RXh0ZW5zaW9uDQpmb3IgSUtFdjIvSVBzZWMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SGln aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBdmFpbGFibGl0eTwvZm9udD48L3RhYmxlPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0K PHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpIaSBaaGFuZyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N ClRoYW5rcyBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgUkZDIDYzMTEgLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki Pjxicj4NCkkgaGF2ZSBnb25lIHRocm91Z2ggeW91ciAmbmJzcDtwcm9wb3NlZCBkcmFmdCBhbmQg ZmVsdCB0aGF0IHRoZXJlIGlzIHNvbWUNCmNvbmZ1c2lvbiByZWdhcmRpbmcgdGhlIG1lc3NhZ2Ug aWQgY29uY2VwdCBvZiBpa2V2Mi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJIGhhdmUgc2VlbiB0 aGF0IGluIHNlY3Rpb24gMi4zIHlvdSB3ZXJlIGNvbXBhcmluZyB0aGUgaGlnZXIgc2VuZGVyIHZh bHVlDQpvZiB4MiB3aXRoIHkyLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpU aGF0IGlzIHdyb25nLiB3aGVuIHgyIHByb3Bvc2VzIHRoZSBuZXh0IGhpZ2hlciBtZXNzYWdlIGlk IHRvIGJlIHVzZWQgdG8NCnNlbmQgYSByZXF1ZXN0ICw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+PGJyPg0KdGhlbiBvbiB5MiB5b3Ugc2hsZCB0YWxseSBpdCB3aXRoIHRoZSBuZXh0IGhp Z2hlciBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0DQp0byBiZSByZWNpZXZlZCA8YnI+DQogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoYW5kIG5vdCB3aXRoIHRoZSBu ZXh0IGhpZ2hlcg0KbWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSBzZW50KTwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NCmluIGlrZXYyIHRoZSAmbmJzcDttZXNzYWdlIGlkIG9mIHJlcXVlc3Rz IHRvIGJlIHNlbnQgYXJlIGVudGlyZWx5IGRpZmZlcmVudA0KZnJvbSBtZXNzYWdlIGlkIG9mIHJl cXVlc3RzIHRvIGJlIHJlY2VpdmVkLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KdGhhdCBpcyB3aHkgUkZDIHNheXMgYSBtZXNzYWdlIGlkIGlzIHVzZWQgZm91ciB0aW1lcyBv biBhIGdpdmVuIGRldmljZS4NCjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQoxLiBtZXNzYWdlIGlkIFggaXMgdXNlZCB3aGlsZSBzZW5kaW5nIGEgcmVxdWVz dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KMi4gbWVzc2FnZSBpZCBYIGlz IHVzZWQgd2hpbGUgcmVjZWl2aW5nIHRoZSByZXNwb25zZTwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KMy4gbWVzc2FnZSBpZCBYIGlzIHVzZWQgdG8gcmVjZWl2ZSBhIHJlcXVl c3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCjQuIG1lc3NhZ2UgaWQgWCBp cyB1c2VkIHRvIHNlbmQgYSByZXNwb25zZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KcGxlYXNlIGZpbmQgdGhlIGNvbW1l bnRzIGZvciBlYWNoIHNlY3Rpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpTZWN0aW9uIDIuMTog Jm5ic3A7VGhpcyBpcyBhIGtub3duIGlzc3VlIGFuZCB0aGF0IGlzIHdoeSB1c2luZyBSRkMgNjMx MSwNCiZuYnNwO3dlIGFyZSBzeW5jaHJvbmlzaW5nIHRoZSBtZXNzYWdlIGlkJ3M8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQpTZWN0aW9uIDIuMjogVGhlIHBlZXIgaXMgYXNzdW1lZCB0byBiZSBwcm9w ZXIgYW5jaG9yIHBvaW50IHdoaWNoIGhhcyBjb3JyZWN0DQppbmZvIG9mIG1lc3NhZ2UgaWQgb2Yg cmVxdWVzdHMgc2VudCBhbmQgcmVjaWV2ZWQsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQpldmVuIHdoZW4gcGVlciBpcyBjbHVzdGVyIG1lbWJlciAsIGFtb25nIHRoZSB0d28g ZGV2aWNlcyBvbmUgb2YgdGhlbSB3b3VsZA0KYmUgbGVzcyB3cm9uZyBhbmQgaGF2ZSBoaWdoZXIg YWNjdXJhdGUgdmFsdWVzIG9mIG1lc3NhZ2UgaWQncyAuIDxicj4NCnNvIHdlIHBpY2sgdXAgdGhh dCB2YWx1ZS4gSSBkb250IHNlZSBhbnkgaXNzdWUgaGVyZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+ DQpTZWN0aW9uIDIuMzogRmlyc3Qgb2YgYWxsIHRoZXJlIGlzIG5vIHJlbGF0aW9uIGJldHdlZW4g TTEgYW5kIFAxLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0Kb24gYSBnaXZl biBkZXZpY2UuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCi0tLSBNMSBpcyB0 aGUgcHJvcG9zZWQgbWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSBzZW50PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogJm5ic3A7ICZuYnNwO1AxIGlzIHRoZSBwcm9w b3NlZCBtZXNzYWdlIGlkIG9mIHRoZSByZXF1ZXN0IHRvIGJlIHJlY2VpdmVkLjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPjxicj4NCndoZW4gc2ltdWxhdGVub3VzIGZhaWxvdmVyIGhhcHBlbnMsIHgyIG1pZ2h0 IGhhdmUgaGlnaGVyIHZhbHVlIG9mIE0xIHdoZW4NCmNvbXBhcmVkIHRvIHkyICwgYnV0IHgyIG1p Z2h0IGhhdmUgbG93ZXIgdmFsdWUgb2YgUDEgd2hlbiBjb21wYXJlZCB0byB5Mi48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkl0IGRvZXMnbnQgbWF0dGVyLiBib3RoIGFyZSBp bmRlcGVuZGVudC4gd2hhdCB3ZSBldmVudHVhbGx5IGRvIGlzIGNvbXBhcmUNCnRoZSBNMSB2YWx1 ZSBhY3Jvc3MgeDIgYW5kIHkyIGFuZCBwaWNrIHRoZSBoaWdlciBvbmUuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpzYW1lIHByb2Nlc3MgaXMgcmVwZWF0ZWQgZm9yIFAxLjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPjxicj4NCmNhc2UgMSB0byA2IGFyZSBhbHJlYWR5IGhhbmRsZWQgYnkg YmFzaWMgaWtldjIgUkZDIC4gbGlrZSBpZiB3ZSByZWNlaXZlDQpzYW1lIG1lc3NhZ2UgaWQgdHdp Y2UgLCB0aGVuIHdlIHJldHJhbnNtaXQgb3IgZHJvcCBpdCBpZiBpdCBpcyBvdXRzaWRlDQp0aGUg d2luZG93LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NClNlY3Rpb24gMzogJm5ic3A7IGR1cmluZyBzaW11bHRhbmVvdXMgZmFp bG92ZXIgYm90aCB0aGUgY2x1c3RlciBhbmQgdGhlDQpwZWVyIG1lbWJlciB3b3VsZCBiZSBpbiB1 bnJlbGlhYmxlIHN0YXRlLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KQm90 aCBvZiB0aGVtIGFyZSB3cm9uZyAsIGJ1dCBvbmUgb2YgdGhlbSBpcyBsZXNzIHdyb25nICEhISBz byB3ZSB3YW50IHRvDQpzdGFydCBmcm9tIHRoYXQgcG9pbnQgdG8gc3luY2hyb25pc2UgdGhlIG1l c3NhZ2UgaWQncy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIg Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpzbyB3ZSBhcmUgYWxsb3dpbmcgYm90 aCB0aGUgbWVtYmVycyB0byBhbm5vdW5jZSB0aGVpciBtZXNzYWdlIGlkJ3MgYW5kDQp0aGVuIGV2 ZW50dWFsbHkgd2Ugd291bGQgc3luY2hyb25pc2UgdG8gdGhlIGhpZ2hlciBudW1iZXIuPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJIGRvbnQgc2VlIGFueSBmbGF3IGhlcmUu IFBsZWFzZSBleHBsYWluIHdpdGggYW4gZXhhbXBsZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpC eSB5b3VyIHByb3Bvc2FsIGluIGNhc2Ugb2Ygc2ltdWx0YW5lb3VzIGZhaWxvdmVyLCBib3RoIHRo ZSBjbHVzdGVyIGFuZA0KcGVlciB3aWxsIGJlIGluIFVOU1lORUQgc3RhdGUgYW5kIDxicj4NCmJv dGggd291bGQgZW5kIHVwIHNlbmRpbmcgYW5kIHJlamVjdGluZyB0aGUgc3luY2hyb25pc2F0aW9u IHJlcXVlc3QuIDxicj4NClRoaXMgd291bGQgbGVhZCB0byByZXBlYXRlZCBzeW5jaHJvbmlzYXRp b24gZWZmb3J0cyBhbmQgdGhlIHByb2JsZW0gb2YNCm1lc3NhZ2Ugc3luY2hyb25pc2F0aW9uIGlz IG5ldmVyIHNvbHZlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpzbyBVTlNZTkVEIHN0YXRlIGlz IG5vdCByZXF1aXJlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpTZWN0aW9uIDQ6IDxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJIGZlZWwgdGhhdCBSRkMg NjMxMSBhbHJlYWR5IHNvbHZlcyB0aGUgbWVzc2FnZSBpZCBzeW5jaHJvbmlzYXRpb24gaXNzdWUu DQo8YnI+DQpJIGRvbnQgdGhpbmsgd2UgbmVlZCB0byBpbmNyZW1lbnQgTTEgYnkgZG91YmxlIHRo ZSB3aW5kb3cgc2l6ZSBhcyBwcm9wb3NlZA0KYnkgeW91LiA8YnI+DQpQbGVhc2Ugc3VwcG9ydCB5 b3VyIHByb3Bvc2FsIHdpdGggYW4gZXhhbXBsZSB3aXRoIG1lc3NhZ2UgaWQgdmFsdWVzIG9mDQpu dW1iZXJzIGluc3RlYWQgb2YgdmFyaWFibGVzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQpMaWtlIE0xIGlzIDMgLCBNMiBpcyA0IGV0YyBldGMuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48 YnI+DQpOdW1iZXJzIG1ha2UgaXQgbW9yZSBjbGVhci48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCnJl Z2FyZHMsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCmthbHlhbmk8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxi cj4NCkZyb206PC9iPiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5v cmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aXBzZWMtYm91bmNl c0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KPC9m b250PjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PlttYWlsdG86aXBzZWMtYm91bmNl c0BpZXRmLm9yZ108L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLnJ1aXNoYW5AenRl LmNvbS5jbj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnpoYW5nLnJ1 aXNoYW5AenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPjxicj4NClNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTEsIDIwMTIgNzozNiBBTTxiPjxicj4N ClRvOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmlwc2VjQGlldGYub3JnPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aXBzZWNAaWV0Zi5vcmc8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+DQpTdWJqZWN0OjwvYj4gW0lQc2Vj XSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYyL0lQc2VjIEhpZ2gNCkF2 YWlsYWJsaXR5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCjxicj4NCjxicj4NCkRlYXIgQWxsLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K PGJyPg0KIEkndmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0ICZxdW90OzwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPg0KVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZv ciBJS0V2Mi9JUHNlYyBIaWdoIEF2YWlsYWJsaXR5PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+JnF1b3Q7Lg0KVGhpcyBkcmFmdCBhbmFseXplcyBzb21lIGlzc3VlcyBpbiBSRkMgNjMx MSwgPGJyPg0KYW5kIHByb3Bvc2VzIHNvbWUgdXBkYXRlcy4gTG9vayBmb3J3YXJkIHRvIHlvdXIg Y29tbWVudHMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KQlIsPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpSdWlzaGFuIFpoYW5nPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFp bHRvOklQc2VjQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PklQc2VjQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHNlYzwvdT48L2ZvbnQ+PC9hPjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8 YnI+DQpJUHNlY0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXBzZWM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0010751848257A24_=-- From svanru@gmail.com Fri Jun 22 06:39:45 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B47021F8613; Fri, 22 Jun 2012 06:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tA93icBIgYus; Fri, 22 Jun 2012 06:39:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0BFA21F85EA; Fri, 22 Jun 2012 06:39:41 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3946988lbb.31 for ; Fri, 22 Jun 2012 06:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=fDXW94EyhqQxXZvh2y4eOkpmsRMztoA/mBaHvm4f6iQ=; b=K3WgPqW7jTOnmu0NHiuxiH/DJPLLdInTptHXiq3JEbxrQG23wrtCBTZuzJnxM24YvV +fcKQSUYXfq9HORzvsmBvAG5eU+EovS9shA+SciuUrtzE6HiB23tGnt3wkPjf1exGRMJ MulNbDV1lYg6QCJVJls4xiGNEn/bl2v+D95mWlmEMa/HAnZXtdQ2fLE/1TkBXNqHrolm YWdqkjVpc3GeOsF5PNqu0KFW5f0CYFiWH3eB0qp4eX4+fLj5SIVgksA951dWVm3wDqlS 6qZPVBFJcVHLMCaWrAxM37tpKgXDDbNnVXoXMF4cf9jiNcTDfHRtvqgpf1cGYHeHSTc/ 4yDw== Received: by 10.112.98.225 with SMTP id el1mr1537851lbb.30.1340372380539; Fri, 22 Jun 2012 06:39:40 -0700 (PDT) Received: from svanpc ([93.188.44.200]) by mx.google.com with ESMTPS id pp2sm52452994lab.3.2012.06.22.06.39.37 (version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 06:39:39 -0700 (PDT) Message-ID: <6EBBB1000D07469BB5A124B49979EDF4@trustworks.com> From: "Valery Smyslov" To: "Kalyani Garigipati \(kagarigi\)" , References: <52F04C02CB538E4DAAA0B493EBCA4A7503F03196@xmb-rcd-x11.cisco.com> <52F04C02CB538E4DAAA0B493EBCA4A7503F049ED@xmb-rcd-x11.cisco.com> Date: Fri, 22 Jun 2012 17:39:33 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B3_01CD509D.FC736180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 13:39:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01B3_01CD509D.FC736180 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Hi, I tend to agree with Zhang, that described scenario may take place. It may happen if, for some reason, newly active member picks M1 lower than the highest value used for request by previously active = member. Sure, bullet 1 in section 5.1 of RFC6311 says that newly active member MUST choose M1 larger than any value known to have been used, but the question is - how it can reliably calculate this value? If synchronization channel between members is reliable and = syncronization messages are frequent enough (say, for each changes of Message ID counters), than no problem here. But if synchronization between members is not so = frequent=20 or channel allows message loss, than newly active member can only estimate the highest sender's Message ID used by previously active member. And if its estimation appears to become wrong (less than actually used), than 2 scenarious are possible: 1. If last requests made by previously active member get delayed=20 on their fly to peer and arrive there AFTER Message ID = syncronization is finished, than we have Zhang's scenario - for peer they will look like generated by newly active member and it will respond to them correspondently, but for newly active member those responses will be either unexpected (if it doesn't generate any request yet) or incorrectly processed (if it has already made some requests). In the latter case situation will become unpredictable. 2. The other problem in this situation is that according to bullet 4 in section 5.1 of RFC6311 peer MUST silently drop any message, containing M1 less or equal than the highest value it has seen from the cluster. Again, if newly active member incorrectly estimates the highest value, used by previously active member and send smaller value in M1, than peer will silently drop the message, that will eventually lead to IKE SA deletion. Regards, Smyslov Valery. ----- Original Message -----=20 From: Kalyani Garigipati (kagarigi)=20 To: zhang.ruishan@zte.com.cn=20 Cc: ipsec@ietf.org ; ipsec-bounces@ietf.org=20 Sent: 20 =A7=DA=A7=F0=A7=DF=A7=F1 2012 =A7=D4. 15:26 Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec = High Availablity Hi Zhang, =20 For Analysis 1=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 a0[t].x a0's maximum message ID received from the peer b until time t = =20 a0[t].y a0's next sender message ID at time t=20 =20 I think there is confusion above. I guess what u actually wanted to convey is=20 =20 a0[t].x a0's maximum message ID of the request sent and orderly = response received from the peer b until time t , say if a has received = responses for 2 and 3 and 5 , this value is 3. So now the window would = be 4-8 (inclusive) a0[t].y a0's next request message ID to be sent at time t , this = value is 6 , if it has already sent the requests 2,3,4,5,=20 =20 b[t].x b's maximum message ID of the orderly response sent to = cluster until time t , if it has sent response to 2,3 and 5 id requests = , it is still 3. b[t].y b's next message id of the request to be received, which is 6 = =20 =20 I guess the example has wrong values. =20 if window size is 5=20 =20 then=20 =20 For a concrete example, let's assume:=20 =20 a1[T0].x =3D=3D a0[T0].x =3D 9 ---------------how can x and y vary by = 10 when the window size is 5 ? a1[T0].y =3D=3D a0[T0].y =3D 20=20 =20 b[T0].x =3D 19 -- same is the case here.. b[TO].y =3D 10=20 =20 Please adjust these values and then there will be no issues as = mentioned by you. =20 also please refer to the section 8.1 and 9 of the RFC 6311 which says = that when the window moves to the synchronised value, all the old pending requests and to-be retransmitted responses should = be deleted. So the below issue will not happen =20 When the new active member a1 sends request messages with Messages IDs = 25, 26,27,28,29, since the peer b has processed the request message with = the same=20 Message IDs, the peer b will return response messages for the request = messages from the old active member a0.=20 =20 Then a1 receives acceptable but mismacthed response messages. =20 For Analysis 2 =20 This is the problem of basic HA simulatenous fail-over and not just = about message ID synchronisation. =20 when both of the devices don=A1=AFt have new sa and just have the old = sa. Then they will continue with the old sa or bring down the sa based on = the administrative control. =20 the sync time within a cluster among a and b might be same or = different due to which one of them would have old sa and another would = have new sa. in such=20 cases both the sa would be deleted eventually and new sa is = established. =20 or even if sync times are different, one would have old sa with lesser = message id's and other have same old sa with higher message id's and = then both will=20 start from the higher message id values. =20 Regards, kalyani =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of zhang.ruishan@zte.com.cn Sent: Wednesday, June 20, 2012 7:44 AM To: Kalyani Garigipati (kagarigi) Cc: ipsec@ietf.org; ipsec-bounces@ietf.org Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec = High Availablity =20 Hi Kalyani,=20 First I'd like to make some clarifications according to your comments, = and leave other clarifications to further discussions.=20 1. Clarification for case C in Section 2.2=20 (case C is the most troublesome in this section IMO.So I'd like to = clarify it.)=20 1.1 Notation for case C in Section 2.2=20 x: the maximum message ID received from the peer party=20 y: the next sender message ID=20 a0: the old active cluster member=20 a1: the new active cluster member=20 b: the peer=20 a0[t].x a0's maximum message ID received from the peer b until time t = a0[t].y a0's next sender message ID at time t=20 a1[t].x a1's maximum message ID received from the peer b until time = t=20 a1[t].y a1's next sender message ID at time t=20 b[t].x b's maximum message ID received from the cluster until time = t=20 b[t].y b's next sender message ID at time t=20 T0: At this time point, the last synchronization between a0 and a1 is = carried out=20 T1: At this time point, the failover event occurs=20 T2: At this time point, the Message ID synchronization between a1 and = b starts=20 T3: At this time point, the Message ID synchronization between a1 and = b ends=20 SW: the sender window size of the cluster. Let's assume SW is 5.=20 = ----T0--------T1----------T2----------T3---------------------------------= ----=20 1.2 Analysis for case C in Section 2.2=20 We know that:=20 a1[T0].x =3D=3D a0[T0].x=20 a1[T0].y =3D=3D a0[T0].y=20 (The reaon is that at T0, the synchronization between a0 and a1 is = carried out.)=20 And=20 a1[T1].x =3D=3D a0[T0].x=20 a1[T1].y =3D=3D a0[T0].y=20 And=20 a1[T2].x =3D=3D a0[T0].x=20 a1[T2].y =3D=3D a0[T0].y=20 (The reaon is that from T0 to T2, the state data of a1 keeps = unchanged.)=20 According to RFC 6311,=20 "M1 is the next sender's Message ID to be used by the member. M1=20 MUST be chosen so that it is larger than any value known to have=20 been used. It is RECOMMENDED to increment the known value at=20 least by the size of the IKE sender window."=20 At T2, the new active member a1 can set M1=3Da1[T2].y + SW.=20 And=20 "M2 MUST be at least the higher of the received M1, and one more=20 than the highest sender value received from the cluster. This=20 includes any previous received synchronization messages."=20 =20 At T2, the peer b can set M2 =3D max(M1, 1 + b[T2].x).=20 M1=3D=3Da1[T2].y + SW =3D> M1 =3D=3D a0[T0].y + SW =3D> M1 =3D=3D = a0[T0].y + 5=20 Suppose some message exchanges (i.e., 10 messages) have been carried = out from T0 to T2, it's possible that b[T2].x + 1 > a0[T0].y + 5.=20 Then the peer b sets M2=3D1 + b[T2].x.=20 At T3, when the new active member a1 receives the Message ID = synchronization response from the peer b, a1 sets a1[T3].y =3D M2.=20 a1[T3].y =3D=3D M2 =3D> a1[T3].y =3D=3D1 + b[T2].x.=20 At T2, a0[T2].y could be b[T2].x+5.=20 (The reaon is that a0's sent messages with Message IDs b[T2].x+1, = b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 may NOT have reached to the peer = b.)=20 This means a1[T3].y < a0[T2].y.=20 This means the first five messages sent by the new active member a1 = will have Message IDs b[T2].x+1, = b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5.=20 Suppose after T3, the peer receives the old active member a0's sent = messages with Message IDs b[T2].x+1, = b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5, and sends response messages.=20 After that, the new active member a1 sends the first five request = messages with Message IDs b[T2].x+1, = b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5.=20 After receving these request messages, the peer b will regards these = requests as resent messages, and returns response messages for=20 requests of a0's sent messages with Message IDs b[T2].x+1, = b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 to a1.=20 (My understanding, according to RFC 5996, is that the peer should = treat the new active member's request messages as resent reqeusts. )=20 = re-sent =20 As a result, the peer b receives acceptable but mismatched responses = for its request messages with Message IDs a1[T2].x+1, = a1[T2].x+2,a1[T2].x+3,a1[T2].x+4,a1[T2].x+5.=20 =20 For a concrete example, let's assume:=20 a1[T0].x =3D=3D a0[T0].x =3D 9=20 a1[T0].y =3D=3D a0[T0].y =3D 20=20 b[T0].x =3D 19=20 b[TO].y =3D 10=20 From T0 to T1, the old active member a0 have sent 10 request messages = to the peer b, and 5 messages have been received and acknowledged by the = peer b.=20 This means that a0[T2].y =3D 30, b[T2].x =3D 24. Note request messages = with Message ID 25,26,27,28,29 have been sent by the old active member = a0, but have NOT reached the peer b0. (The sender window size of the = cluster is 5.)=20 According to RFC 6311,=20 "M1 is the next sender's Message ID to be used by the member. M1=20 MUST be chosen so that it is larger than any value known to have=20 been used. It is RECOMMENDED to increment the known value at=20 least by the size of the IKE sender window."=20 M1 =3D=3D a1[T2].y + SW =3D=3D 20 + 5 =3D=3D 25=20 (a1[T2].y =3D=3D a1[T0].y =3D=3D 20)=20 And=20 "M2 MUST be at least the higher of the received M1, and one more=20 than the highest sender value received from the cluster. This=20 includes any previous received synchronization messages."=20 =20 M2 =3D=3D max{M1, 1 + b[T2].x)=3D=3D max(25,1+24) =3D=3D 25=20 After the new active member a1 receives M2, a1 sets a1[T2].y =3D=3D 25 = < a0[T2].y =3D=3D 30.=20 The Message ID for the new active member a1 numbers from 25.=20 The first five Message IDs are 25, 26, 27,28,29.=20 When the new active member a1 sends request messages with Messages IDs = 25, 26,27,28,29, since the peer b has processed the request message with = the same Message IDs, the peer b will return response messages for the = request messages from the old active member a0.=20 Then a1 receives acceptable but mismacthed response messages.=20 =20 2. Clarifications for the simultanesous failover case F in Section 2.3 = For the simultaneous failover, case F is the most devastating IMO. So = I'd like to clarify it first.=20 2.1 Notation for the simultanesous failover case F in Section 2.3=20 a0: the old active cluster member of the cluster a=20 a1: the new active cluster member of the cluster a=20 b0: the old active cluster member of the cluster b=20 b1: the new active cluster member of the cluster b=20 T0: At this time point, the last synchronization between a0/b0 and = a1/b1 is carried out,=20 T1: At this time point, the simultaneous failover event occurs=20 T2: At this time point, the Message ID synchronization between a1 and = b1 starts=20 T3: At this time point, the Message ID synchronization between a1 and = b1 ends=20 = ----T0--------T1----------T2----------T3---------------------------------= ----=20 =20 2.2 Analysis for the simultanesous failover case F in Section 2.3=20 It's possible that from T0 to T1, a0 and b0 deletes the old IKE SA sa0 = and creates a new IKE SA sa1.=20 But at T2, a1 and b1 do NOT know what has happened from T0 and T1, and = do NOT know the existance of the new IKE SA sa1, and use the old IKE SA = sa0 to carry out Message ID synchronization.=20 This may bring some more seriouse problem. So when simultaneous = failover occurs, a simple two-way synchronization may not be an = appropriate solution.=20 "Kalyani Garigipati (kagarigi)" =20 =B7=A2=BC=FE=C8=CB: ipsec-bounces@ietf.org=20 2012-06-14 19:14=20 =CA=D5=BC=FE=C8=CB "zhang.ruishan@zte.com.cn" , = "ipsec@ietf.org" =20 =20 =B3=AD=CB=CD =20 =D6=F7=CC=E2 Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec = High Availablity =20 =20 =20 =20 Hi Zhang,=20 =20 Thanks for going through the RFC 6311 .=20 =20 I have gone through your proposed draft and felt that there is some = confusion regarding the message id concept of ikev2.=20 =20 I have seen that in section 2.3 you were comparing the higer sender = value of x2 with y2.=20 That is wrong. when x2 proposes the next higher message id to be used = to send a request ,=20 then on y2 you shld tally it with the next higher message id of the = request to be recieved=20 (and not with the next higher message id of the request to = be sent)=20 =20 in ikev2 the message id of requests to be sent are entirely different = from message id of requests to be received.=20 that is why RFC says a message id is used four times on a given = device.=20 =20 1. message id X is used while sending a request=20 2. message id X is used while receiving the response=20 3. message id X is used to receive a request=20 4. message id X is used to send a response.=20 =20 =20 please find the comments for each section=20 =20 Section 2.1: This is a known issue and that is why using RFC 6311, = we are synchronising the message id's=20 =20 Section 2.2: The peer is assumed to be proper anchor point which has = correct info of message id of requests sent and recieved,=20 even when peer is cluster member , among the two devices one of them = would be less wrong and have higher accurate values of message id's .=20 so we pick up that value. I dont see any issue here.=20 =20 Section 2.3: First of all there is no relation between M1 and P1.=20 on a given device.=20 --- M1 is the proposed message id of the request to be sent=20 P1 is the proposed message id of the request to be received.=20 =20 when simulatenous failover happens, x2 might have higher value of M1 = when compared to y2 , but x2 might have lower value of P1 when compared = to y2.=20 It does'nt matter. both are independent. what we eventually do is = compare the M1 value across x2 and y2 and pick the higer one.=20 same process is repeated for P1.=20 =20 case 1 to 6 are already handled by basic ikev2 RFC . like if we = receive same message id twice , then we retransmit or drop it if it is = outside the window.=20 =20 =20 Section 3: during simultaneous failover both the cluster and the = peer member would be in unreliable state.=20 Both of them are wrong , but one of them is less wrong !!! so we want = to start from that point to synchronise the message id's.=20 =20 so we are allowing both the members to announce their message id's and = then eventually we would synchronise to the higher number.=20 I dont see any flaw here. Please explain with an example.=20 =20 By your proposal in case of simultaneous failover, both the cluster = and peer will be in UNSYNED state and=20 both would end up sending and rejecting the synchronisation request.=20 This would lead to repeated synchronisation efforts and the problem of = message synchronisation is never solved.=20 =20 so UNSYNED state is not required.=20 =20 Section 4:=20 =20 I feel that RFC 6311 already solves the message id synchronisation = issue.=20 I dont think we need to increment M1 by double the window size as = proposed by you.=20 Please support your proposal with an example with message id values of = numbers instead of variables.=20 Like M1 is 3 , M2 is 4 etc etc.=20 =20 Numbers make it more clear.=20 =20 regards,=20 kalyani=20 =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of zhang.ruishan@zte.com.cn Sent: Monday, June 11, 2012 7:36 AM To: ipsec@ietf.org Subject: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High = Availablity=20 =20 Dear All,=20 I've submitted a new draft " Updates to the IKEv2 Extension for = IKEv2/IPsec High Availablity". This draft analyzes some issues in RFC = 6311,=20 and proposes some updates. Look forward to your comments.=20 BR,=20 Ruishan Zhang_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_01B3_01CD509D.FC736180 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
I tend to agree with Zhang, that = described scenario=20 may take place.
It may happen if, for some reason, = newly active=20 member picks M1
lower than the highest value used for = request by=20 previously active member.
Sure, bullet 1 in section 5.1 of = RFC6311 says=20 that newly active member
MUST choose M1 larger than any value = known to have=20 been used,
but the question is - how it can = reliably calculate=20 this value?
If synchronization channel between = members is=20 reliable and syncronization messages
are frequent enough (say, for each = changes of=20 Message ID counters),
than no problem here. But if = synchronization=20 between members is not so frequent
or channel allows message loss, than newly active = member can=20 only
estimate the highest sender's Message = ID used by=20 previously active
member. And if its estimation appears = to become=20 wrong (less than
actually used), than 2 scenarious are=20 possible:
1. If last requests made by = previously active=20 member get delayed
    on their fly to peer = and arrive=20 there AFTER Message ID syncronization
    is finished, than we = have=20 Zhang's scenario - for peer they will look
    like generated by = newly active=20 member and it will respond to them
   =20 correspondently, but for newly = active member=20 those responses
    will be either = unexpected (if it=20 doesn't generate any request yet)
    or incorrectly = processed (if it=20 has already made some requests).
    In the latter case = situation=20 will become unpredictable.
2. The other problem in this situation = is that=20 according to bullet 4
    in section 5.1 of = RFC6311 peer=20 MUST silently drop any message,
    containing M1 less = or equal than=20 the highest value it has seen from
    the cluster. Again, = if newly=20 active member incorrectly estimates
    the highest value, = used by=20 previously active member and send
    smaller value in M1, = than peer=20 will silently drop the message,
    that will eventually = lead to IKE=20 SA deletion.
 
Regards,
Smyslov Valery.
----- Original Message -----
From:=20 Kalyani=20 Garigipati (kagarigi)
To: zhang.ruishan@zte.com.cn
Cc: ipsec@ietf.org ; ipsec-bounces@ietf.org
Sent: 20 = =A7=DA=A7=F0=A7=DF=A7=F1 2012 =A7=D4. 15:26
Subject: Re: [IPsec] Updates to = the IKEv2=20 Extension for IKEv2/IPsec High Availablity

Hi=20 Zhang,

 

For=20 Analysis 1

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

a0[t].x =20 a0's maximum message ID received from the peer b until time t =20

a0[t].y =20 a0's next sender message ID  at time t

 

I=20 think there is confusion above.

I=20 guess what u actually wanted to convey is

 

a0[t].x =20 a0's maximum message ID of the request sent and orderly response = received from=20 the peer b until time t , say if a has received responses for 2 and 3 = and=20 5  , this value is 3. So now the window would be 4-8=20 (inclusive)

a0[t].y =20 a0's next request message ID to be sent at time t , this value is 6 , = if it=20 has already sent the requests 2,3,4,5,

 

b[t].x  =20 b's maximum message ID of the orderly response sent to cluster  = until=20 time t , if it has sent response to 2,3 and 5 id requests , it is = still=20 3.

b[t].y  =20 b's next message id of the request to be received, which is 6=20

 

 

I=20 guess the example has wrong values.

 

if=20 window size is 5

 

then=20

 

For=20 a concrete example, let's assume:

 

a1[T0].x=20 =3D=3D a0[T0].x =3D 9 ---------------how can x and y vary by 10 when = the window size=20 is 5  ?

a1[T0].y=20 =3D=3D a0[T0].y =3D 20

 

b[T0].x=20 =3D 19   -- same is the case here..

b[TO].y=20 =3D 10

 

Please=20 adjust these values and then there will be no issues as mentioned by=20 you.

 

also=20 please refer to the section 8.1 and 9 of the RFC 6311 which says that = when the=20 window moves to the synchronised value,

all=20 the old pending requests and to-be retransmitted responses should be = deleted.=20 So the below issue will not happen

 

When=20 the new active member a1 sends request messages with Messages IDs 25,=20 26,27,28,29, since the peer b has processed the request message with = the same=20

Message=20 IDs, the peer b will return response messages for the request messages = from=20 the old active member a0.

 

Then=20 a1 receives acceptable but mismacthed response=20 messages.

 

For=20 Analysis 2

 

This=20 is the problem of basic HA simulatenous fail-over and not just about = message=20 ID synchronisation.

 

when=20 both of the devices don=A1=AFt have new sa and just have the old=20 sa.

Then=20 they will  continue with the old sa or bring down the sa based on = the=20 administrative control.

 

the=20 sync time within a cluster  among a and b might be same or = different due=20 to which one of them would have old sa and another would have new sa. = in such=20

cases=20 both the sa would be deleted eventually and new sa is=20 established.

 

or=20 even if sync times are different, one would have old sa with lesser = message=20 id's and other have same old sa with higher message id's and then both = will=20

start=20 from the higher message id values.

 

Regards,

kalyani

 

From:=20 ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = zhang.ruishan@zte.com.cn
Sent: Wednesday, June 20, 2012 = 7:44=20 AM
To: Kalyani Garigipati (kagarigi)
Cc: = ipsec@ietf.org;=20 ipsec-bounces@ietf.org
Subject: Re: [IPsec] Updates to the = IKEv2=20 Extension for IKEv2/IPsec High Availablity

 


Hi = Kalyani,=20



First I'd = like to=20 make some clarifications according to your comments, and leave other=20 clarifications to further discussions.

1.=20 Clarification for case C in Section 2.2
(case C = is the most=20 troublesome in this section IMO.So I'd like to clarify it.) =
1.1 = Notation for=20 case C in Section 2.2

x: the = maximum=20 message ID received from the peer party
y: the = next sender=20 message ID

a0: the = old active=20 cluster member
a1: the = new active=20 cluster member
b: =  the=20 peer


a0[t].x =  a0's=20 maximum message ID received from the peer b until time t =
a0[t].y =  a0's=20 next sender message ID  at time t

a1[t].x =  a1's=20 maximum message ID received from the peer b  until time t=20
a1[t].y =  a1's=20 next sender message ID  at time t

b[t].x =   b's=20 maximum message ID received from the cluster  until time t=20
b[t].y =   b's=20 next sender message ID at time t


T0: At = this time=20 point, the last synchronization between a0 and a1 is carried = out=20

T1:=20 At this time point, the failover event occurs

T2: At = this time=20 point, the Message ID synchronization between a1 and b starts=20


T3: At = this time=20 point, the Message ID synchronization between a1 and b ends=20

SW:=20 the sender window size of the cluster. Let's assume SW is 5.=20

----T0--------T1----------T2----------T3---------------------------= ----------=20

1.2=20 Analysis for case C in Section 2.2


We know = that:=20

a1[T0].x = =3D=3D=20 a0[T0].x
a1[T0].y = =3D=3D=20 a0[T0].y
(The = reaon is that=20 at T0, the synchronization between a0 and a1 is carried out.)=20

And=20


a1[T1].x = =3D=3D=20 a0[T0].x
a1[T1].y = =3D=3D=20 a0[T0].y

And=20

a1[T2].x = =3D=3D=20 a0[T0].x
a1[T2].y = =3D=3D=20 a0[T0].y

(The = reaon is that=20 from T0 to T2, the state data of a1 keeps unchanged.) =

According = to RFC=20 6311,

"M1 is = the next=20 sender's Message ID to be used by the member.  M1 =
MUST be = chosen so=20 that it is larger than any value known to have
been = used.  It=20 is RECOMMENDED to increment the known value at
least by = the size=20 of the IKE sender window."

At T2, = the new=20 active member a1 can set M1=3Da1[T2].y + SW.


And=20

"M2 MUST = be at=20 least the higher of the received M1, and one more
  =  =20   than the highest sender value received from the cluster.=20  This
  =  =20   includes any previous received synchronization = messages."=20
 =20        
At T2, = the peer b=20 can set M2 =3D max(M1, 1 + b[T2].x).

M1=3D=3Da1[T2].y + SW=20 =3D> M1 =3D=3D a0[T0].y + SW  =3D> M1 =3D=3D a0[T0].y + = 5

Suppose = some=20 message exchanges (i.e., 10 messages) have been carried out from T0 to = T2,=20 it's possible that b[T2].x + 1 > a0[T0].y + 5.

Then the = peer b=20 sets M2=3D1 + b[T2].x.

At T3, = when the new=20 active member a1 receives the Message ID synchronization response from = the=20 peer b, a1  sets a1[T3].y =3D M2.

a1[T3].y = =3D=3D M2=20 =3D> a1[T3].y =3D=3D1 + b[T2].x.


At T2, = a0[T2].y=20 could be b[T2].x+5.
(The = reaon is that=20 a0's sent messages with Message IDs b[T2].x+1,=20 b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 may NOT have reached to the = peer b.)=20

This = means a1[T3].y=20 < a0[T2].y.

This = means the=20 first five messages sent by the new active member a1 will have Message = IDs=20 b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5. =

Suppose = after T3,=20 the peer receives the old active member a0's sent messages with = Message IDs=20 b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5, and sends response = messages.

After = that, the new=20 active member a1 sends the first five request messages with Message = IDs=20 b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5.
After = receving=20 these request messages, the peer b will regards these requests as = resent=20 messages, and returns response messages for
requests = of=20  a0's sent messages with Message IDs b[T2].x+1,=20 b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 to a1.
(My = understanding,=20 according to RFC 5996, is that the peer should treat the new active = member's=20 request messages as resent reqeusts. )
  =  =20                     =  =20                     =  =20                     =  =20                   =  re-sent=20    
As a = result, the=20 peer b receives acceptable but mismatched responses for its request = messages=20 with Message IDs a1[T2].x+1,=20 a1[T2].x+2,a1[T2].x+3,a1[T2].x+4,a1[T2].x+5.
  =  =20      
For a = concrete=20 example, let's assume:

a1[T0].x = =3D=3D=20 a0[T0].x =3D 9
a1[T0].y = =3D=3D=20 a0[T0].y =3D 20

b[T0].x = =3D 19=20
b[TO].y =3D=20 10

From T0 = to T1, the=20 old active member a0 have sent 10 request messages to the peer b, and = 5=20 messages have been received and acknowledged by the peer b.=20

This = means that=20 a0[T2].y =3D 30, b[T2].x =3D 24. Note request messages with Message ID = 25,26,27,28,29 have been sent by the old active member a0, but have = NOT=20 reached the peer b0. (The sender window size of the cluster is = 5.)=20


According = to RFC=20 6311,

"M1 is = the next=20 sender's Message ID to be used by the member.  M1 =
MUST be = chosen so=20 that it is larger than any value known to have
been = used.  It=20 is RECOMMENDED to increment the known value at
least by = the size=20 of the IKE sender window."


M1 =3D=3D = a1[T2].y + SW=20 =3D=3D 20 + 5 =3D=3D 25
(a1[T2].y = =3D=3D=20 a1[T0].y =3D=3D 20)

And=20
"M2 MUST = be at=20 least the higher of the received M1, and one more
than the = highest=20 sender value received from the cluster.  This
includes = any=20 previous received synchronization messages."
  =  =20      
M2 =3D=3D = max{M1, 1 +=20 b[T2].x)=3D=3D max(25,1+24) =3D=3D 25

After the = new=20 active member a1 receives M2, a1 sets a1[T2].y =3D=3D 25 < a0[T2].y = =3D=3D=20 30.

The = Message ID for=20 the new active member a1 numbers from 25.

The first = five=20 Message IDs are 25, 26, 27,28,29.

When the = new active=20 member a1 sends request messages with Messages IDs 25, 26,27,28,29, = since the=20 peer b has processed the request message with the same Message IDs, = the peer b=20 will return response messages for the request messages from the old = active=20 member a0.

Then a1 = receives=20 acceptable but mismacthed response messages.

  =  =20    
2. = Clarifications=20 for the simultanesous failover case F in Section 2.3
For the=20 simultaneous failover, case F is the most devastating IMO. So I'd like = to=20 clarify it first.
2.1 = Notation for=20 the simultanesous failover case F in Section 2.3 =


a0: the = old active=20 cluster member of the cluster a
a1: the = new active=20 cluster member of the cluster a
b0: the = old active=20 cluster member of the cluster b
b1: the = new active=20 cluster member of the cluster b


T0: At = this time=20 point, the last synchronization between a0/b0 and a1/b1 is carried = out,=20

T1: At = this time=20 point, the simultaneous failover event occurs

T2: At = this time=20 point, the Message ID synchronization between a1 and b1 starts=20


T3: At = this time=20 point, the Message ID synchronization between a1 and b1 ends=20



----T0--------T1----------T2----------T3---------------------------= ----------=20
 =20          
2.2 = Analysis for=20 the simultanesous failover case F in Section 2.3 =


It's = possible that=20 from T0 to T1, a0 and b0 deletes the old IKE SA sa0 and creates a new = IKE SA=20 sa1.
But at = T2, a1 and=20 b1 do NOT know what has happened from T0 and T1, and do NOT know the = existance=20 of the new IKE SA sa1, and use the old IKE SA sa0 to carry out Message = ID=20 synchronization.
This may = bring some=20 more seriouse problem. So  when simultaneous failover occurs, a = simple=20 two-way synchronization  may not be an appropriate = solution.=20





"Kalyani=20 Garigipati (kagarigi)" <kagarigi@cisco.com><= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 7.5pt">=20
=B7=A2=BC=FE=C8=CB: =  ipsec-bounces@ietf.org =

2012-06-14=20 19:14

=CA=D5=BC=FE=C8=CB

"zhang.ruishan@zte.com.cn"=20 <zhang.ruishan@zte.com.cn>= ,=20 "ipsec@ietf.org" = <ipsec@ietf.org>=20

=B3=AD=CB=CD

=D6=F7=CC=E2

Re:=20 [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec =  =20      High      =20 =  Availablity

 




Hi=20 Zhang,
 =20
Thanks=20 for going through the RFC 6311 .
 =20
I=20 have gone through your  proposed draft and felt that there is = some=20 confusion regarding the message id concept of ikev2.
 =20
I=20 have seen that in section 2.3 you were comparing the higer sender = value of x2=20 with y2.
That=20 is wrong. when x2 proposes the next higher message id to be used to = send a=20 request ,
then=20 on y2 you shld tally it with the next higher message id of the request = to be=20 recieved
 =20           (and not with the next higher = message id of=20 the request to be sent)
 =20
in=20 ikev2 the  message id of requests to be sent are entirely = different from=20 message id of requests to be received.
that=20 is why RFC says a message id is used four times on a given device.=20
 =20
1.=20 message id X is used while sending a request
2.=20 message id X is used while receiving the response
3.=20 message id X is used to receive a request
4.=20 message id X is used to send a response.
 =20
 =20
please=20 find the comments for each section
 =20
Section=20 2.1:  This is a known issue and that is why using RFC 6311, =  we are=20 synchronising the message id's
 =20
Section=20 2.2: The peer is assumed to be proper anchor point which has correct = info of=20 message id of requests sent and recieved,
even=20 when peer is cluster member , among the two devices one of them would = be less=20 wrong and have higher accurate values of message id's . =
so=20 we pick up that value. I dont see any issue here.
 =20
Section=20 2.3: First of all there is no relation between M1 and P1. =
on=20 a given device.
---=20 M1 is the proposed message id of the request to be sent =
 =20   P1 is the proposed message id of the request to be = received.=20
 =20
when=20 simulatenous failover happens, x2 might have higher value of M1 when = compared=20 to y2 , but x2 might have lower value of P1 when compared to = y2.=20
It=20 does'nt matter. both are independent. what we eventually do is compare = the M1=20 value across x2 and y2 and pick the higer one.
same=20 process is repeated for P1.
 =20
case=20 1 to 6 are already handled by basic ikev2 RFC . like if we receive = same=20 message id twice , then we retransmit or drop it if it is outside the=20 window.
 =20
 =20
Section=20 3:   during simultaneous failover both the cluster and the peer = member=20 would be in unreliable state.
Both=20 of them are wrong , but one of them is less wrong !!! so we want to = start from=20 that point to synchronise the message id's.
 =20
so=20 we are allowing both the members to announce their message id's and = then=20 eventually we would synchronise to the higher number.
I=20 dont see any flaw here. Please explain with an example. =
 =20
By=20 your proposal in case of simultaneous failover, both the cluster and = peer will=20 be in UNSYNED state and
both=20 would end up sending and rejecting the synchronisation request.=20
This=20 would lead to repeated synchronisation efforts and the problem of = message=20 synchronisation is never solved.
 =20
so=20 UNSYNED state is not required.
 =20
Section=20 4:
 =20
I=20 feel that RFC 6311 already solves the message id synchronisation = issue.=20
I=20 dont think we need to increment M1 by double the window size as = proposed by=20 you.
Please=20 support your proposal with an example with message id values of = numbers=20 instead of variables.
Like=20 M1 is 3 , M2 is 4 etc etc.
 =20
Numbers=20 make it more clear.
 =20
regards,=20
kalyani=20
 =20
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@iet= f.org]=20 On Behalf Of zhang.ruishan@zte.com.cn<= BR>Sent:=20 Monday, June 11, 2012 7:36 AM
To: ipsec@ietf.org
Subject: = [IPsec]=20 Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity =
 =20


Dear=20 All,=20

 I've=20 submitted a new draft " Updates to the = IKEv2=20 Extension for IKEv2/IPsec High Availablity". This = draft=20 analyzes some issues in RFC 6311,
and proposes some updates. Look = forward=20 to your comments.=20


BR,

Ruishan=20 Zhang_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_01B3_01CD509D.FC736180-- From yaronf.ietf@gmail.com Fri Jun 22 08:21:55 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5B21F8528; Fri, 22 Jun 2012 08:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJt9fQUMrwuw; Fri, 22 Jun 2012 08:21:53 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0AD721F8517; Fri, 22 Jun 2012 08:21:52 -0700 (PDT) Received: by bkty8 with SMTP id y8so1842196bkt.31 for ; Fri, 22 Jun 2012 08:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QW6OmIzZqqukFIGpraMt4ITMcdsAtHJhzWSBfmmQZaU=; b=zr5oMSMBdkLtKZo6YJypxxrncjrncFPkmkeAUN+LSNLxkk1uUuix5bY3DXnSeIf07U IZwHYkd2hQKtAnYtuDRwZHWa6kegpwp/WnSbX1g2XNQtvExu2vpMUAK3L7L7brjlsRjN fnL6mUGwOx/z2rIFLlVP2QjROJxEhdXi+CJpTybTQ+JgCdJ9d7Rby0dhjwZEgPj7XtjC 9i8wTgVgShUiNgk5u8Y+aOh5HT1yKVlHuX8jE5MizBs6ge3kbA/u7WGyNYTStq129lR2 gX2Sm2hPdtKb1J62rKm7yrZrxIIaBL9WeCt66u7ahIYVHAT7jp5N51QTJXwOpAEd7m2y htXw== Received: by 10.205.127.140 with SMTP id ha12mr924665bkc.105.1340378511715; Fri, 22 Jun 2012 08:21:51 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-161-38.red.bezeqint.net. [79.176.161.38]) by mx.google.com with ESMTPS id gm18sm36380842bkc.7.2012.06.22.08.21.49 (version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 08:21:50 -0700 (PDT) Message-ID: <4FE48D8C.2040504@gmail.com> Date: Fri, 22 Jun 2012 18:21:48 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <52F04C02CB538E4DAAA0B493EBCA4A7503F03196@xmb-rcd-x11.cisco.com> <52F04C02CB538E4DAAA0B493EBCA4A7503F049ED@xmb-rcd-x11.cisco.com> <6EBBB1000D07469BB5A124B49979EDF4@trustworks.com> In-Reply-To: <6EBBB1000D07469BB5A124B49979EDF4@trustworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org, "Kalyani Garigipati \(kagarigi\)" , ipsec-bounces@ietf.org, zhang.ruishan@zte.com.cn Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 15:21:55 -0000 Hi Valery, Zhang, I agree that the protocol makes some assumptions regarding the synchronization between peers, which perhaps we should have better clarified in the RFC. - The synchronization channel is reliable. - The standby member can have a reasonably good estimate regarding the the IKE SA Message ID. I think that for most implementations, these assumptions do hold. Most IKE messages will be acknowledged, so we should not expect a large number of messages to be in-flight; "real" changes in the IKE state (addition/deletion of Child SAs) will be synchronized between the cluster members; periodic liveness tests (if any) have a predictable rate. In addition to the MUST rule on setting M1 to the highest known value, there is also a "RECOMMENDED" (SHOULD) rule to increment M1 by the window size. If this rule is followed, I think both scenarios listed below will happen very rarely. Also note that Sec. 8.3 recommends dropping the IKE SA if any inconsistencies are detected in practice. The goal of the protocol is to minimize the number of dropped SAs during a failover. The protocol does not ensure that absolutely no SAs will ever be dropped. Thanks, Yaron On 06/22/2012 03:39 PM, Valery Smyslov wrote: > Hi, > I tend to agree with Zhang, that described scenario may take place. > It may happen if, for some reason, newly active member picks M1 > lower than the highest value used for request by previously active member. > Sure, bullet 1 in section 5.1 of RFC6311 says that newly active member > MUST choose M1 larger than any value known to have been used, > but the question is - how it can reliably calculate this value? > If synchronization channel between members is reliable and > syncronization messages > are frequent enough (say, for each changes of Message ID counters), > than no problem here. But if synchronization between members is not so > frequent > or channel allows message loss, than newly active member can only > estimate the highest sender's Message ID used by previously active > member. And if its estimation appears to become wrong (less than > actually used), than 2 scenarious are possible: > 1. If last requests made by previously active member get delayed > on their fly to peer and arrive there AFTER Message ID syncronization > is finished, than we have Zhang's scenario - for peer they will look > like generated by newly active member and it will respond to them > correspondently, but for newly active member those responses > will be either unexpected (if it doesn't generate any request yet) > or incorrectly processed (if it has already made some requests). > In the latter case situation will become unpredictable. > 2. The other problem in this situation is that according to bullet 4 > in section 5.1 of RFC6311 peer MUST silently drop any message, > containing M1 less or equal than the highest value it has seen from > the cluster. Again, if newly active member incorrectly estimates > the highest value, used by previously active member and send > smaller value in M1, than peer will silently drop the message, > that will eventually lead to IKE SA deletion. > Regards, > Smyslov Valery. > > ----- Original Message ----- > *From:* Kalyani Garigipati (kagarigi) > *To:* zhang.ruishan@zte.com.cn > *Cc:* ipsec@ietf.org ; > ipsec-bounces@ietf.org > *Sent:* 20 июня 2012 г. 15:26 > *Subject:* Re: [IPsec] Updates to the IKEv2 Extension for > IKEv2/IPsec High Availablity > > Hi Zhang, > > *For Analysis 1 * > > ========================================================= > > a0[t].x a0's maximum message ID received from the peer b until time t > > a0[t].y a0's next sender message ID at time t > > I think there is confusion above. > > I guess what u actually wanted to convey is > > a0[t].x a0's maximum message ID of the request sent and orderly > response received from the peer b until time t , say if a has > received responses for 2 and 3 and 5 , this value is 3. So now the > window would be 4-8 (inclusive) > > a0[t].y a0's next request message ID to be sent at time t , this > value is 6 , if it has already sent the requests 2,3,4,5, > > b[t].x b's maximum message ID of the orderly response sent to > cluster until time t , if it has sent response to 2,3 and 5 id > requests , it is still 3. > > b[t].y b's next message id of the request to be received, which is 6 > > I guess the example has wrong values. > > if window size is 5 > > then > > For a concrete example, let's assume: > > a1[T0].x == a0[T0].x = 9 ---------------how can x and y vary by 10 > when the window size is 5 ? > > a1[T0].y == a0[T0].y = 20 > > b[T0].x = 19 -- same is the case here.. > > b[TO].y = 10 > > Please adjust these values and then there will be no issues as > mentioned by you. > > also please refer to the section 8.1 and 9 of the RFC 6311 which > says that when the window moves to the synchronised value, > > all the old pending requests and to-be retransmitted responses > should be deleted. So the below issue will not happen > > /When the new active member a1 sends request messages with Messages > IDs 25, 26,27,28,29, since the peer b has processed the request > message with the same / > > // > > /Message IDs, the peer b will return response messages for the > request messages from the old active member a0. / > > // > > /Then a1 receives acceptable but mismacthed response messages./ > > // > > *For Analysis 2* > > This is the problem of basic HA simulatenous fail-over and not just > about message ID synchronisation. > > when both of the devices don’t have new sa and just have the old sa. > > Then they will continue with the old sa or bring down the sa based > on the administrative control. > > the sync time within a cluster among a and b might be same or > different due to which one of them would have old sa and another > would have new sa. in such > > cases both the sa would be deleted eventually and new sa is established. > > or even if sync times are different, one would have old sa with > lesser message id's and other have same old sa with higher message > id's and then both will > > start from the higher message id values. > > Regards, > > kalyani > > *From:*ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On > Behalf Of *zhang.ruishan@zte.com.cn > *Sent:* Wednesday, June 20, 2012 7:44 AM > *To:* Kalyani Garigipati (kagarigi) > *Cc:* ipsec@ietf.org; ipsec-bounces@ietf.org > *Subject:* Re: [IPsec] Updates to the IKEv2 Extension for > IKEv2/IPsec High Availablity > > > Hi Kalyani, > > > > First I'd like to make some clarifications according to your > comments, and leave other clarifications to further discussions. > > 1. Clarification for case C in Section 2.2 > (case C is the most troublesome in this section IMO.So I'd like to > clarify it.) > 1.1 Notation for case C in Section 2.2 > > x: the maximum message ID received from the peer party > y: the next sender message ID > > a0: the old active cluster member > a1: the new active cluster member > b: the peer > > > a0[t].x a0's maximum message ID received from the peer b until time t > a0[t].y a0's next sender message ID at time t > > a1[t].x a1's maximum message ID received from the peer b until time t > a1[t].y a1's next sender message ID at time t > > b[t].x b's maximum message ID received from the cluster until time t > b[t].y b's next sender message ID at time t > > > T0: At this time point, the last synchronization between a0 and a1 > is carried out > > T1: At this time point, the failover event occurs > > T2: At this time point, the Message ID synchronization between a1 > and b starts > > > T3: At this time point, the Message ID synchronization between a1 > and b ends > > SW: the sender window size of the cluster. Let's assume SW is 5. > > ----T0--------T1----------T2----------T3------------------------------------- > > > 1.2 Analysis for case C in Section 2.2 > > > We know that: > > a1[T0].x == a0[T0].x > a1[T0].y == a0[T0].y > (The reaon is that at T0, the synchronization between a0 and a1 is > carried out.) > > And > > > a1[T1].x == a0[T0].x > a1[T1].y == a0[T0].y > > And > > a1[T2].x == a0[T0].x > a1[T2].y == a0[T0].y > > (The reaon is that from T0 to T2, the state data of a1 keeps > unchanged.) > > According to RFC 6311, > > "M1 is the next sender's Message ID to be used by the member. M1 > MUST be chosen so that it is larger than any value known to have > been used. It is RECOMMENDED to increment the known value at > least by the size of the IKE sender window." > > At T2, the new active member a1 can set M1=a1[T2].y + SW. > > > And > > "M2 MUST be at least the higher of the received M1, and one more > than the highest sender value received from the cluster. This > includes any previous received synchronization messages." > > At T2, the peer b can set M2 = max(M1, 1 + b[T2].x). > > M1==a1[T2].y + SW => M1 == a0[T0].y + SW => M1 == a0[T0].y + 5 > > Suppose some message exchanges (i.e., 10 messages) have been carried > out from T0 to T2, it's possible that b[T2].x + 1 > a0[T0].y + 5. > > Then the peer b sets M2=1 + b[T2].x. > > At T3, when the new active member a1 receives the Message ID > synchronization response from the peer b, a1 sets a1[T3].y = M2. > > a1[T3].y == M2 => a1[T3].y ==1 + b[T2].x. > > > At T2, a0[T2].y could be b[T2].x+5. > (The reaon is that a0's sent messages with Message IDs b[T2].x+1, > b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 may NOT have reached to the > peer b.) > > This means a1[T3].y < a0[T2].y. > > This means the first five messages sent by the new active member a1 > will have Message IDs b[T2].x+1, > b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5. > > Suppose after T3, the peer receives the old active member a0's sent > messages with Message IDs b[T2].x+1, > b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5, and sends response messages. > > After that, the new active member a1 sends the first five request > messages with Message IDs b[T2].x+1, > b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5. > After receving these request messages, the peer b will regards these > requests as resent messages, and returns response messages for > requests of a0's sent messages with Message IDs b[T2].x+1, > b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 to a1. > (My understanding, according to RFC 5996, is that the peer should > treat the new active member's request messages as resent reqeusts. ) > re-sent > As a result, the peer b receives acceptable but mismatched responses > for its request messages with Message IDs a1[T2].x+1, > a1[T2].x+2,a1[T2].x+3,a1[T2].x+4,a1[T2].x+5. > > For a concrete example, let's assume: > > a1[T0].x == a0[T0].x = 9 > a1[T0].y == a0[T0].y = 20 > > b[T0].x = 19 > b[TO].y = 10 > > From T0 to T1, the old active member a0 have sent 10 request > messages to the peer b, and 5 messages have been received and > acknowledged by the peer b. > > This means that a0[T2].y = 30, b[T2].x = 24. Note request messages > with Message ID 25,26,27,28,29 have been sent by the old active > member a0, but have NOT reached the peer b0. (The sender window size > of the cluster is 5.) > > > According to RFC 6311, > > "M1 is the next sender's Message ID to be used by the member. M1 > MUST be chosen so that it is larger than any value known to have > been used. It is RECOMMENDED to increment the known value at > least by the size of the IKE sender window." > > > M1 == a1[T2].y + SW == 20 + 5 == 25 > (a1[T2].y == a1[T0].y == 20) > > And > "M2 MUST be at least the higher of the received M1, and one more > than the highest sender value received from the cluster. This > includes any previous received synchronization messages." > > M2 == max{M1, 1 + b[T2].x)== max(25,1+24) == 25 > > After the new active member a1 receives M2, a1 sets a1[T2].y == 25 < > a0[T2].y == 30. > > The Message ID for the new active member a1 numbers from 25. > > The first five Message IDs are 25, 26, 27,28,29. > > When the new active member a1 sends request messages with Messages > IDs 25, 26,27,28,29, since the peer b has processed the request > message with the same Message IDs, the peer b will return response > messages for the request messages from the old active member a0. > > Then a1 receives acceptable but mismacthed response messages. > > > 2. Clarifications for the simultanesous failover case F in Section 2.3 > For the simultaneous failover, case F is the most devastating IMO. > So I'd like to clarify it first. > 2.1 Notation for the simultanesous failover case F in Section 2.3 > > > a0: the old active cluster member of the cluster a > a1: the new active cluster member of the cluster a > b0: the old active cluster member of the cluster b > b1: the new active cluster member of the cluster b > > > T0: At this time point, the last synchronization between a0/b0 and > a1/b1 is carried out, > > T1: At this time point, the simultaneous failover event occurs > > T2: At this time point, the Message ID synchronization between a1 > and b1 starts > > > T3: At this time point, the Message ID synchronization between a1 > and b1 ends > > > > ----T0--------T1----------T2----------T3------------------------------------- > > > 2.2 Analysis for the simultanesous failover case F in Section 2.3 > > > It's possible that from T0 to T1, a0 and b0 deletes the old IKE SA > sa0 and creates a new IKE SA sa1. > But at T2, a1 and b1 do NOT know what has happened from T0 and T1, > and do NOT know the existance of the new IKE SA sa1, and use the old > IKE SA sa0 to carry out Message ID synchronization. > This may bring some more seriouse problem. So when simultaneous > failover occurs, a simple two-way synchronization may not be an > appropriate solution. > > > > > > *"Kalyani Garigipati (kagarigi)" >* > 发件人: ipsec-bounces@ietf.org > > 2012-06-14 19:14 > > > > 收件人 > > > > "zhang.ruishan@zte.com.cn " > >, > "ipsec@ietf.org " > > > 抄送 > > > > 主题 > > > > Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High > Availablity > > > > > > > Hi Zhang, > > Thanks for going through the RFC 6311 . > > I have gone through your proposed draft and felt that there is some > confusion regarding the message id concept of ikev2. > > I have seen that in section 2.3 you were comparing the higer sender > value of x2 with y2. > That is wrong. when x2 proposes the next higher message id to be > used to send a request , > then on y2 you shld tally it with the next higher message id of the > request to be recieved > (and not with the next higher message id of the request to be sent) > > in ikev2 the message id of requests to be sent are entirely > different from message id of requests to be received. > that is why RFC says a message id is used four times on a given device. > > 1. message id X is used while sending a request > 2. message id X is used while receiving the response > 3. message id X is used to receive a request > 4. message id X is used to send a response. > > > please find the comments for each section > > Section 2.1: This is a known issue and that is why using RFC 6311, > we are synchronising the message id's > > Section 2.2: The peer is assumed to be proper anchor point which has > correct info of message id of requests sent and recieved, > even when peer is cluster member , among the two devices one of them > would be less wrong and have higher accurate values of message id's . > so we pick up that value. I dont see any issue here. > > Section 2.3: First of all there is no relation between M1 and P1. > on a given device. > --- M1 is the proposed message id of the request to be sent > P1 is the proposed message id of the request to be received. > > when simulatenous failover happens, x2 might have higher value of M1 > when compared to y2 , but x2 might have lower value of P1 when > compared to y2. > It does'nt matter. both are independent. what we eventually do is > compare the M1 value across x2 and y2 and pick the higer one. > same process is repeated for P1. > > case 1 to 6 are already handled by basic ikev2 RFC . like if we > receive same message id twice , then we retransmit or drop it if it > is outside the window. > > > Section 3: during simultaneous failover both the cluster and the > peer member would be in unreliable state. > Both of them are wrong , but one of them is less wrong !!! so we > want to start from that point to synchronise the message id's. > > so we are allowing both the members to announce their message id's > and then eventually we would synchronise to the higher number. > I dont see any flaw here. Please explain with an example. > > By your proposal in case of simultaneous failover, both the cluster > and peer will be in UNSYNED state and > both would end up sending and rejecting the synchronisation request. > This would lead to repeated synchronisation efforts and the problem > of message synchronisation is never solved. > > so UNSYNED state is not required. > > Section 4: > > I feel that RFC 6311 already solves the message id synchronisation > issue. > I dont think we need to increment M1 by double the window size as > proposed by you. > Please support your proposal with an example with message id values > of numbers instead of variables. > Like M1 is 3 , M2 is 4 etc etc. > > Numbers make it more clear. > > regards, > kalyani > > *From:*ipsec-bounces@ietf.org > [mailto:ipsec-bounces@ietf.org] > *On Behalf Of > *zhang.ruishan@zte.com.cn * > Sent:* Monday, June 11, 2012 7:36 AM* > To:* ipsec@ietf.org * > Subject:* [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec > High Availablity > > > > Dear All, > > I've submitted a new draft "Updates to the IKEv2 Extension for > IKEv2/IPsec High Availablity". This draft analyzes some issues in > RFC 6311, > and proposes some updates. Look forward to your comments. > > > BR, > > Ruishan Zhang_______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ------------------------------------------------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From zhang.ruishan@zte.com.cn Tue Jun 26 23:29:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CEA21F851B; Tue, 26 Jun 2012 23:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.792 X-Spam-Level: X-Spam-Status: No, score=-95.792 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAF-wI2YemrK; Tue, 26 Jun 2012 23:29:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A0A2C21F8518; Tue, 26 Jun 2012 23:29:48 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620433787882; Wed, 27 Jun 2012 14:24:22 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 50640.498265646; Wed, 27 Jun 2012 14:29:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q5R6TaT7075782; Wed, 27 Jun 2012 14:29:36 +0800 (GMT-8) (envelope-from zhang.ruishan@zte.com.cn) In-Reply-To: <6EBBB1000D07469BB5A124B49979EDF4@trustworks.com> To: "Valery Smyslov" MIME-Version: 1.0 X-KeepSent: 703E5FC2:E7EB14B3-48257A2A:0023651E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.ruishan@zte.com.cn Date: Wed, 27 Jun 2012 14:29:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-27 14:29:38, Serialize complete at 2012-06-27 14:29:38 Content-Type: multipart/alternative; boundary="=_alternative 0023ACFE48257A2A_=" X-MAIL: mse01.zte.com.cn q5R6TaT7075782 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:29:52 -0000 This is a multipart message in MIME format. --=_alternative 0023ACFE48257A2A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgVmFsZXJ5LA0KDQogSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBuZXdseSBhY3RpdmUgY2x1 c3RlciBtZW1iZXIgbWF5IHJlY2VpdmUgDQphbiBhY2NlcHRhYmxlIGJ1dCBtaXNtYXRjaGVkIHJl c3BvbnNlIG1lc3NhZ2UuIEFuZCBpbiBzdWNoIGFuIGNhc2UsIA0KdGhlIHNpdHVhdGlvbiB3aWxs IGJlY29tZSB1bnByZWRpY3RhYmxlIGFuZCBtYXkgY2F1c2Ugc29tZSBzZWN1cml0eSByaXNrcy4N CkluIG15IG9waW5pb24sIGV2ZW4gdGhlIGFib3ZlIGNhc2UgaGFwcGVucyByYXJlbHksIHdlIHNo b3VsZCBsZXQgDQpkZXZlbG9wZXJzIGF3YXJlIG9mIHN1Y2ggYSByaXNrLg0KSSB0aGluayBpdCdz IGJldHRlciBpZiB3ZSBjYW4gbWFrZSBzb21lIHVwZGF0ZXMgdG8gUkZDIDYzMTEuIA0KDQoNCkJS LA0KDQpSdWlzaGFuIFpoYW5nDQoNCg0KDQoNCiJWYWxlcnkgU215c2xvdiIgPHN2YW5ydUBnbWFp bC5jb20+IA0Kt6K8/sjLOiAgaXBzZWMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0wNi0yMiAyMDoz OQ0KDQrK1bz+yMsNCiJLYWx5YW5pIEdhcmlnaXBhdGkgXChrYWdhcmlnaVwpIiA8a2FnYXJpZ2lA Y2lzY28uY29tPiwgDQo8emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPg0Ks63LzQ0KaXBzZWNAaWV0 Zi5vcmcsIGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcNCtb3zOINClJlOiBbSVBzZWNdIFVwZGF0ZXMg dG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMgSGlnaCANCkF2YWlsYWJsaXR5 DQoNCg0KDQoNCg0KDQpIaSwNCiANCkkgdGVuZCB0byBhZ3JlZSB3aXRoIFpoYW5nLCB0aGF0IGRl c2NyaWJlZCBzY2VuYXJpbyBtYXkgdGFrZSBwbGFjZS4NCkl0IG1heSBoYXBwZW4gaWYsIGZvciBz b21lIHJlYXNvbiwgbmV3bHkgYWN0aXZlIG1lbWJlciBwaWNrcyBNMQ0KbG93ZXIgdGhhbiB0aGUg aGlnaGVzdCB2YWx1ZSB1c2VkIGZvciByZXF1ZXN0IGJ5IHByZXZpb3VzbHkgYWN0aXZlIG1lbWJl ci4NClN1cmUsIGJ1bGxldCAxIGluIHNlY3Rpb24gNS4xIG9mIFJGQzYzMTEgc2F5cyB0aGF0IG5l d2x5IGFjdGl2ZSBtZW1iZXINCk1VU1QgY2hvb3NlIE0xIGxhcmdlciB0aGFuIGFueSB2YWx1ZSBr bm93biB0byBoYXZlIGJlZW4gdXNlZCwNCmJ1dCB0aGUgcXVlc3Rpb24gaXMgLSBob3cgaXQgY2Fu IHJlbGlhYmx5IGNhbGN1bGF0ZSB0aGlzIHZhbHVlPw0KSWYgc3luY2hyb25pemF0aW9uIGNoYW5u ZWwgYmV0d2VlbiBtZW1iZXJzIGlzIHJlbGlhYmxlIGFuZCBzeW5jcm9uaXphdGlvbiANCm1lc3Nh Z2VzDQphcmUgZnJlcXVlbnQgZW5vdWdoIChzYXksIGZvciBlYWNoIGNoYW5nZXMgb2YgTWVzc2Fn ZSBJRCBjb3VudGVycyksDQp0aGFuIG5vIHByb2JsZW0gaGVyZS4gQnV0IGlmIHN5bmNocm9uaXph dGlvbiBiZXR3ZWVuIG1lbWJlcnMgaXMgbm90IHNvIA0KZnJlcXVlbnQgDQpvciBjaGFubmVsIGFs bG93cyBtZXNzYWdlIGxvc3MsIHRoYW4gbmV3bHkgYWN0aXZlIG1lbWJlciBjYW4gb25seQ0KZXN0 aW1hdGUgdGhlIGhpZ2hlc3Qgc2VuZGVyJ3MgTWVzc2FnZSBJRCB1c2VkIGJ5IHByZXZpb3VzbHkg YWN0aXZlDQptZW1iZXIuIEFuZCBpZiBpdHMgZXN0aW1hdGlvbiBhcHBlYXJzIHRvIGJlY29tZSB3 cm9uZyAobGVzcyB0aGFuDQphY3R1YWxseSB1c2VkKSwgdGhhbiAyIHNjZW5hcmlvdXMgYXJlIHBv c3NpYmxlOg0KMS4gSWYgbGFzdCByZXF1ZXN0cyBtYWRlIGJ5IHByZXZpb3VzbHkgYWN0aXZlIG1l bWJlciBnZXQgZGVsYXllZCANCiAgICBvbiB0aGVpciBmbHkgdG8gcGVlciBhbmQgYXJyaXZlIHRo ZXJlIEFGVEVSIE1lc3NhZ2UgSUQgc3luY3Jvbml6YXRpb24NCiAgICBpcyBmaW5pc2hlZCwgdGhh biB3ZSBoYXZlIFpoYW5nJ3Mgc2NlbmFyaW8gLSBmb3IgcGVlciB0aGV5IHdpbGwgbG9vaw0KICAg IGxpa2UgZ2VuZXJhdGVkIGJ5IG5ld2x5IGFjdGl2ZSBtZW1iZXIgYW5kIGl0IHdpbGwgcmVzcG9u ZCB0byB0aGVtDQogICAgY29ycmVzcG9uZGVudGx5LCBidXQgZm9yIG5ld2x5IGFjdGl2ZSBtZW1i ZXIgdGhvc2UgcmVzcG9uc2VzDQogICAgd2lsbCBiZSBlaXRoZXIgdW5leHBlY3RlZCAoaWYgaXQg ZG9lc24ndCBnZW5lcmF0ZSBhbnkgcmVxdWVzdCB5ZXQpDQogICAgb3IgaW5jb3JyZWN0bHkgcHJv Y2Vzc2VkIChpZiBpdCBoYXMgYWxyZWFkeSBtYWRlIHNvbWUgcmVxdWVzdHMpLg0KICAgIEluIHRo ZSBsYXR0ZXIgY2FzZSBzaXR1YXRpb24gd2lsbCBiZWNvbWUgdW5wcmVkaWN0YWJsZS4NCi8vIFRo YXQncyB0aGUgcG9pbnQuIEluIHRoaXMgY2FzZSwgUkZDIDYzMTEgbWF5IGVuZCB1cCB3aXRoIGEg d3JvbmcgcmF0aGVyIA0KdGhhbiBhbiB1bnN1Y2Nlc3NmdWwgTWVzc2FnZSBJRCBzeW5jaHJvbml6 YXRpb24uIA0KSW4gbXkgb3BpbmlvbiwgZXZlbiB0aGUgYWJvdmUgY2FzZSBoYXBwZW5zIHJhcmVs eSwgd2Ugc2hvdWxkIGxldCANCmRldmVsb3BlcnMgYXdhcmUgb2Ygc3VjaCBhIHJpc2suDQpJIHRo aW5rIGl0J3MgYmV0dGVyIGlmIHdlIGNhbiBtYWtlIHNvbWUgdXBkYXRlcyB0byBSRkMgNjMxMS4g DQoNCg0KDQoyLiBUaGUgb3RoZXIgcHJvYmxlbSBpbiB0aGlzIHNpdHVhdGlvbiBpcyB0aGF0IGFj Y29yZGluZyB0byBidWxsZXQgNA0KICAgIGluIHNlY3Rpb24gNS4xIG9mIFJGQzYzMTEgcGVlciBN VVNUIHNpbGVudGx5IGRyb3AgYW55IG1lc3NhZ2UsDQogICAgY29udGFpbmluZyBNMSBsZXNzIG9y IGVxdWFsIHRoYW4gdGhlIGhpZ2hlc3QgdmFsdWUgaXQgaGFzIHNlZW4gZnJvbQ0KICAgIHRoZSBj bHVzdGVyLiBBZ2FpbiwgaWYgbmV3bHkgYWN0aXZlIG1lbWJlciBpbmNvcnJlY3RseSBlc3RpbWF0 ZXMNCiAgICB0aGUgaGlnaGVzdCB2YWx1ZSwgdXNlZCBieSBwcmV2aW91c2x5IGFjdGl2ZSBtZW1i ZXIgYW5kIHNlbmQNCiAgICBzbWFsbGVyIHZhbHVlIGluIE0xLCB0aGFuIHBlZXIgd2lsbCBzaWxl bnRseSBkcm9wIHRoZSBtZXNzYWdlLA0KICAgIHRoYXQgd2lsbCBldmVudHVhbGx5IGxlYWQgdG8g SUtFIFNBIGRlbGV0aW9uLg0KDQoNCg0KIA0KUmVnYXJkcywNClNteXNsb3YgVmFsZXJ5Lg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IEthbHlhbmkgR2FyaWdpcGF0aSAoa2Fn YXJpZ2kpIA0KVG86IHpoYW5nLnJ1aXNoYW5AenRlLmNvbS5jbiANCkNjOiBpcHNlY0BpZXRmLm9y ZyA7IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgDQpTZW50OiAyMCCn2qfwp9+n8SAyMDEyIKfULiAx NToyNg0KU3ViamVjdDogUmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9u IGZvciBJS0V2Mi9JUHNlYyBIaWdoIA0KQXZhaWxhYmxpdHkNCg0KSGkgWmhhbmcsDQogDQpGb3Ig QW5hbHlzaXMgMSANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KIA0KYTBbdF0ueCAgYTAncyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2 ZWQgZnJvbSB0aGUgcGVlciBiIHVudGlsIHRpbWUgdCANCmEwW3RdLnkgIGEwJ3MgbmV4dCBzZW5k ZXIgbWVzc2FnZSBJRCAgYXQgdGltZSB0IA0KIA0KSSB0aGluayB0aGVyZSBpcyBjb25mdXNpb24g YWJvdmUuDQpJIGd1ZXNzIHdoYXQgdSBhY3R1YWxseSB3YW50ZWQgdG8gY29udmV5IGlzIA0KIA0K YTBbdF0ueCAgYTAncyBtYXhpbXVtIG1lc3NhZ2UgSUQgb2YgdGhlIHJlcXVlc3Qgc2VudCBhbmQg b3JkZXJseSByZXNwb25zZSANCnJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiB1bnRpbCB0aW1lIHQg LCBzYXkgaWYgYSBoYXMgcmVjZWl2ZWQgcmVzcG9uc2VzIA0KZm9yIDIgYW5kIDMgYW5kIDUgICwg dGhpcyB2YWx1ZSBpcyAzLiBTbyBub3cgdGhlIHdpbmRvdyB3b3VsZCBiZSA0LTggDQooaW5jbHVz aXZlKQ0KYTBbdF0ueSAgYTAncyBuZXh0IHJlcXVlc3QgbWVzc2FnZSBJRCB0byBiZSBzZW50IGF0 IHRpbWUgdCAsIHRoaXMgdmFsdWUgaXMgDQo2ICwgaWYgaXQgaGFzIGFscmVhZHkgc2VudCB0aGUg cmVxdWVzdHMgMiwzLDQsNSwgDQogDQpiW3RdLnggICBiJ3MgbWF4aW11bSBtZXNzYWdlIElEIG9m IHRoZSBvcmRlcmx5IHJlc3BvbnNlIHNlbnQgdG8gY2x1c3RlciANCnVudGlsIHRpbWUgdCAsIGlm IGl0IGhhcyBzZW50IHJlc3BvbnNlIHRvIDIsMyBhbmQgNSBpZCByZXF1ZXN0cyAsIGl0IGlzIA0K c3RpbGwgMy4NCmJbdF0ueSAgIGIncyBuZXh0IG1lc3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8g YmUgcmVjZWl2ZWQsIHdoaWNoIGlzIDYgDQogDQogDQpJIGd1ZXNzIHRoZSBleGFtcGxlIGhhcyB3 cm9uZyB2YWx1ZXMuDQogDQppZiB3aW5kb3cgc2l6ZSBpcyA1IA0KIA0KdGhlbiANCiANCkZvciBh IGNvbmNyZXRlIGV4YW1wbGUsIGxldCdzIGFzc3VtZTogDQogDQphMVtUMF0ueCA9PSBhMFtUMF0u eCA9IDkgLS0tLS0tLS0tLS0tLS0taG93IGNhbiB4IGFuZCB5IHZhcnkgYnkgMTAgd2hlbiANCnRo ZSB3aW5kb3cgc2l6ZSBpcyA1ICA/DQphMVtUMF0ueSA9PSBhMFtUMF0ueSA9IDIwIA0KIA0KYltU MF0ueCA9IDE5ICAgLS0gc2FtZSBpcyB0aGUgY2FzZSBoZXJlLi4NCmJbVE9dLnkgPSAxMCANCiAN ClBsZWFzZSBhZGp1c3QgdGhlc2UgdmFsdWVzIGFuZCB0aGVuIHRoZXJlIHdpbGwgYmUgbm8gaXNz dWVzIGFzIG1lbnRpb25lZCANCmJ5IHlvdS4NCiANCmFsc28gcGxlYXNlIHJlZmVyIHRvIHRoZSBz ZWN0aW9uIDguMSBhbmQgOSBvZiB0aGUgUkZDIDYzMTEgd2hpY2ggc2F5cyB0aGF0IA0Kd2hlbiB0 aGUgd2luZG93IG1vdmVzIHRvIHRoZSBzeW5jaHJvbmlzZWQgdmFsdWUsDQphbGwgdGhlIG9sZCBw ZW5kaW5nIHJlcXVlc3RzIGFuZCB0by1iZSByZXRyYW5zbWl0dGVkIHJlc3BvbnNlcyBzaG91bGQg YmUgDQpkZWxldGVkLiBTbyB0aGUgYmVsb3cgaXNzdWUgd2lsbCBub3QgaGFwcGVuDQogDQpXaGVu IHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBzZW5kcyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVz c2FnZXMgSURzIDI1LCANCjI2LDI3LDI4LDI5LCBzaW5jZSB0aGUgcGVlciBiIGhhcyBwcm9jZXNz ZWQgdGhlIHJlcXVlc3QgbWVzc2FnZSB3aXRoIHRoZSANCnNhbWUgDQpNZXNzYWdlIElEcywgdGhl IHBlZXIgYiB3aWxsIHJldHVybiByZXNwb25zZSBtZXNzYWdlcyBmb3IgdGhlIHJlcXVlc3QgDQpt ZXNzYWdlcyBmcm9tIHRoZSBvbGQgYWN0aXZlIG1lbWJlciBhMC4gDQogDQpUaGVuIGExIHJlY2Vp dmVzIGFjY2VwdGFibGUgYnV0IG1pc21hY3RoZWQgcmVzcG9uc2UgbWVzc2FnZXMuDQogDQpGb3Ig QW5hbHlzaXMgMg0KIA0KVGhpcyBpcyB0aGUgcHJvYmxlbSBvZiBiYXNpYyBIQSBzaW11bGF0ZW5v dXMgZmFpbC1vdmVyIGFuZCBub3QganVzdCBhYm91dCANCm1lc3NhZ2UgSUQgc3luY2hyb25pc2F0 aW9uLg0KIA0Kd2hlbiBib3RoIG9mIHRoZSBkZXZpY2VzIGRvbqGvdCBoYXZlIG5ldyBzYSBhbmQg anVzdCBoYXZlIHRoZSBvbGQgc2EuDQpUaGVuIHRoZXkgd2lsbCAgY29udGludWUgd2l0aCB0aGUg b2xkIHNhIG9yIGJyaW5nIGRvd24gdGhlIHNhIGJhc2VkIG9uIHRoZSANCmFkbWluaXN0cmF0aXZl IGNvbnRyb2wuDQogDQp0aGUgc3luYyB0aW1lIHdpdGhpbiBhIGNsdXN0ZXIgIGFtb25nIGEgYW5k IGIgbWlnaHQgYmUgc2FtZSBvciBkaWZmZXJlbnQgDQpkdWUgdG8gd2hpY2ggb25lIG9mIHRoZW0g d291bGQgaGF2ZSBvbGQgc2EgYW5kIGFub3RoZXIgd291bGQgaGF2ZSBuZXcgc2EuIA0KaW4gc3Vj aCANCmNhc2VzIGJvdGggdGhlIHNhIHdvdWxkIGJlIGRlbGV0ZWQgZXZlbnR1YWxseSBhbmQgbmV3 IHNhIGlzIGVzdGFibGlzaGVkLg0KIA0Kb3IgZXZlbiBpZiBzeW5jIHRpbWVzIGFyZSBkaWZmZXJl bnQsIG9uZSB3b3VsZCBoYXZlIG9sZCBzYSB3aXRoIGxlc3NlciANCm1lc3NhZ2UgaWQncyBhbmQg b3RoZXIgaGF2ZSBzYW1lIG9sZCBzYSB3aXRoIGhpZ2hlciBtZXNzYWdlIGlkJ3MgYW5kIHRoZW4g DQpib3RoIHdpbGwgDQpzdGFydCBmcm9tIHRoZSBoaWdoZXIgbWVzc2FnZSBpZCB2YWx1ZXMuDQog DQpSZWdhcmRzLA0Ka2FseWFuaQ0KIA0KRnJvbTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCnpoYW5nLnJ1aXNoYW5A enRlLmNvbS5jbg0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDIwLCAyMDEyIDc6NDQgQU0NClRvOiBL YWx5YW5pIEdhcmlnaXBhdGkgKGthZ2FyaWdpKQ0KQ2M6IGlwc2VjQGlldGYub3JnOyBpcHNlYy1i b3VuY2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lQc2VjXSBVcGRhdGVzIHRvIHRoZSBJS0V2 MiBFeHRlbnNpb24gZm9yIElLRXYyL0lQc2VjIEhpZ2ggDQpBdmFpbGFibGl0eQ0KIA0KDQpIaSBL YWx5YW5pLCANCg0KDQoNCkZpcnN0IEknZCBsaWtlIHRvIG1ha2Ugc29tZSBjbGFyaWZpY2F0aW9u cyBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cywgYW5kIA0KbGVhdmUgb3RoZXIgY2xhcmlmaWNh dGlvbnMgdG8gZnVydGhlciBkaXNjdXNzaW9ucy4gDQoNCjEuIENsYXJpZmljYXRpb24gZm9yIGNh c2UgQyBpbiBTZWN0aW9uIDIuMiANCihjYXNlIEMgaXMgdGhlIG1vc3QgdHJvdWJsZXNvbWUgaW4g dGhpcyBzZWN0aW9uIElNTy5TbyBJJ2QgbGlrZSB0byBjbGFyaWZ5IA0KaXQuKSANCjEuMSBOb3Rh dGlvbiBmb3IgY2FzZSBDIGluIFNlY3Rpb24gMi4yIA0KDQp4OiB0aGUgbWF4aW11bSBtZXNzYWdl IElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgcGFydHkgDQp5OiB0aGUgbmV4dCBzZW5kZXIgbWVz c2FnZSBJRCANCg0KYTA6IHRoZSBvbGQgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIA0KYTE6IHRoZSBu ZXcgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIA0KYjogIHRoZSBwZWVyIA0KDQoNCmEwW3RdLnggIGEw J3MgbWF4aW11bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiB1bnRpbCB0aW1l IHQgDQphMFt0XS55ICBhMCdzIG5leHQgc2VuZGVyIG1lc3NhZ2UgSUQgIGF0IHRpbWUgdCANCg0K YTFbdF0ueCAgYTEncyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBi ICB1bnRpbCB0aW1lIHQgDQphMVt0XS55ICBhMSdzIG5leHQgc2VuZGVyIG1lc3NhZ2UgSUQgIGF0 IHRpbWUgdCANCg0KYlt0XS54ICAgYidzIG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9t IHRoZSBjbHVzdGVyICB1bnRpbCB0aW1lIHQgDQpiW3RdLnkgICBiJ3MgbmV4dCBzZW5kZXIgbWVz c2FnZSBJRCBhdCB0aW1lIHQgDQoNCg0KVDA6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIGxhc3Qg c3luY2hyb25pemF0aW9uIGJldHdlZW4gYTAgYW5kIGExIGlzIA0KY2FycmllZCBvdXQgDQoNClQx OiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBmYWlsb3ZlciBldmVudCBvY2N1cnMgDQoNClQyOiBB dCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVu IGExIGFuZCBiIA0Kc3RhcnRzIA0KDQoNClQzOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNz YWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiIA0KZW5kcyANCg0KU1c6IHRo ZSBzZW5kZXIgd2luZG93IHNpemUgb2YgdGhlIGNsdXN0ZXIuIExldCdzIGFzc3VtZSBTVyBpcyA1 LiANCg0KLS0tLVQwLS0tLS0tLS1UMS0tLS0tLS0tLS1UMi0tLS0tLS0tLS1UMy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNCg0KMS4yIEFuYWx5c2lzIGZvciBjYXNlIEMg aW4gU2VjdGlvbiAyLjIgDQoNCg0KV2Uga25vdyB0aGF0OiANCg0KYTFbVDBdLnggPT0gYTBbVDBd LnggDQphMVtUMF0ueSA9PSBhMFtUMF0ueSANCihUaGUgcmVhb24gaXMgdGhhdCBhdCBUMCwgdGhl IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGEwIGFuZCBhMSBpcyBjYXJyaWVkIA0Kb3V0LikgDQoN CkFuZCANCg0KDQphMVtUMV0ueCA9PSBhMFtUMF0ueCANCmExW1QxXS55ID09IGEwW1QwXS55IA0K DQpBbmQgDQoNCmExW1QyXS54ID09IGEwW1QwXS54IA0KYTFbVDJdLnkgPT0gYTBbVDBdLnkgDQoN CihUaGUgcmVhb24gaXMgdGhhdCBmcm9tIFQwIHRvIFQyLCB0aGUgc3RhdGUgZGF0YSBvZiBhMSBr ZWVwcyB1bmNoYW5nZWQuKSANCg0KQWNjb3JkaW5nIHRvIFJGQyA2MzExLCANCg0KIk0xIGlzIHRo ZSBuZXh0IHNlbmRlcidzIE1lc3NhZ2UgSUQgdG8gYmUgdXNlZCBieSB0aGUgbWVtYmVyLiAgTTEg DQpNVVNUIGJlIGNob3NlbiBzbyB0aGF0IGl0IGlzIGxhcmdlciB0aGFuIGFueSB2YWx1ZSBrbm93 biB0byBoYXZlIA0KYmVlbiB1c2VkLiAgSXQgaXMgUkVDT01NRU5ERUQgdG8gaW5jcmVtZW50IHRo ZSBrbm93biB2YWx1ZSBhdCANCmxlYXN0IGJ5IHRoZSBzaXplIG9mIHRoZSBJS0Ugc2VuZGVyIHdp bmRvdy4iIA0KDQpBdCBUMiwgdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIGNhbiBzZXQgTTE9YTFb VDJdLnkgKyBTVy4gDQoNCg0KQW5kIA0KDQoiTTIgTVVTVCBiZSBhdCBsZWFzdCB0aGUgaGlnaGVy IG9mIHRoZSByZWNlaXZlZCBNMSwgYW5kIG9uZSBtb3JlIA0KICAgICAgdGhhbiB0aGUgaGlnaGVz dCBzZW5kZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4gIFRoaXMgDQogICAgICBp bmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2VzLiIg DQogDQpBdCBUMiwgdGhlIHBlZXIgYiBjYW4gc2V0IE0yID0gbWF4KE0xLCAxICsgYltUMl0ueCku IA0KDQpNMT09YTFbVDJdLnkgKyBTVyA9PiBNMSA9PSBhMFtUMF0ueSArIFNXICA9PiBNMSA9PSBh MFtUMF0ueSArIDUgDQoNClN1cHBvc2Ugc29tZSBtZXNzYWdlIGV4Y2hhbmdlcyAoaS5lLiwgMTAg bWVzc2FnZXMpIGhhdmUgYmVlbiBjYXJyaWVkIG91dCANCmZyb20gVDAgdG8gVDIsIGl0J3MgcG9z c2libGUgdGhhdCBiW1QyXS54ICsgMSA+IGEwW1QwXS55ICsgNS4gDQoNClRoZW4gdGhlIHBlZXIg YiBzZXRzIE0yPTEgKyBiW1QyXS54LiANCg0KQXQgVDMsIHdoZW4gdGhlIG5ldyBhY3RpdmUgbWVt YmVyIGExIHJlY2VpdmVzIHRoZSBNZXNzYWdlIElEIA0Kc3luY2hyb25pemF0aW9uIHJlc3BvbnNl IGZyb20gdGhlIHBlZXIgYiwgYTEgIHNldHMgYTFbVDNdLnkgPSBNMi4gDQoNCmExW1QzXS55ID09 IE0yID0+IGExW1QzXS55ID09MSArIGJbVDJdLnguIA0KDQoNCkF0IFQyLCBhMFtUMl0ueSBjb3Vs ZCBiZSBiW1QyXS54KzUuIA0KKFRoZSByZWFvbiBpcyB0aGF0IGEwJ3Mgc2VudCBtZXNzYWdlcyB3 aXRoIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgDQpiW1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngr NCxiW1QyXS54KzUgbWF5IE5PVCBoYXZlIHJlYWNoZWQgdG8gdGhlIHBlZXIgDQpiLikgDQoNClRo aXMgbWVhbnMgYTFbVDNdLnkgPCBhMFtUMl0ueS4gDQoNClRoaXMgbWVhbnMgdGhlIGZpcnN0IGZp dmUgbWVzc2FnZXMgc2VudCBieSB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgd2lsbCANCmhhdmUg TWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1Qy XS54KzUuIA0KDQpTdXBwb3NlIGFmdGVyIFQzLCB0aGUgcGVlciByZWNlaXZlcyB0aGUgb2xkIGFj dGl2ZSBtZW1iZXIgYTAncyBzZW50IA0KbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBiW1QyXS54 KzEsIA0KYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1LCBhbmQgc2VuZHMg cmVzcG9uc2UgbWVzc2FnZXMuIA0KDQpBZnRlciB0aGF0LCB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIg YTEgc2VuZHMgdGhlIGZpcnN0IGZpdmUgcmVxdWVzdCBtZXNzYWdlcyANCndpdGggTWVzc2FnZSBJ RHMgYltUMl0ueCsxLCBiW1QyXS54KzIsYltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUuIA0K QWZ0ZXIgcmVjZXZpbmcgdGhlc2UgcmVxdWVzdCBtZXNzYWdlcywgdGhlIHBlZXIgYiB3aWxsIHJl Z2FyZHMgdGhlc2UgDQpyZXF1ZXN0cyBhcyByZXNlbnQgbWVzc2FnZXMsIGFuZCByZXR1cm5zIHJl c3BvbnNlIG1lc3NhZ2VzIGZvciANCnJlcXVlc3RzIG9mICBhMCdzIHNlbnQgbWVzc2FnZXMgd2l0 aCBNZXNzYWdlIElEcyBiW1QyXS54KzEsIA0KYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQs YltUMl0ueCs1IHRvIGExLiANCihNeSB1bmRlcnN0YW5kaW5nLCBhY2NvcmRpbmcgdG8gUkZDIDU5 OTYsIGlzIHRoYXQgdGhlIHBlZXIgc2hvdWxkIHRyZWF0IA0KdGhlIG5ldyBhY3RpdmUgbWVtYmVy J3MgcmVxdWVzdCBtZXNzYWdlcyBhcyByZXNlbnQgcmVxZXVzdHMuICkgDQogICAgICAgICAgICAg ICByZS1zZW50IA0KQXMgYSByZXN1bHQsIHRoZSBwZWVyIGIgcmVjZWl2ZXMgYWNjZXB0YWJsZSBi dXQgbWlzbWF0Y2hlZCByZXNwb25zZXMgZm9yIA0KaXRzIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCBN ZXNzYWdlIElEcyBhMVtUMl0ueCsxLCANCmExW1QyXS54KzIsYTFbVDJdLngrMyxhMVtUMl0ueCs0 LGExW1QyXS54KzUuIA0KIA0KRm9yIGEgY29uY3JldGUgZXhhbXBsZSwgbGV0J3MgYXNzdW1lOiAN Cg0KYTFbVDBdLnggPT0gYTBbVDBdLnggPSA5IA0KYTFbVDBdLnkgPT0gYTBbVDBdLnkgPSAyMCAN Cg0KYltUMF0ueCA9IDE5IA0KYltUT10ueSA9IDEwIA0KDQpGcm9tIFQwIHRvIFQxLCB0aGUgb2xk IGFjdGl2ZSBtZW1iZXIgYTAgaGF2ZSBzZW50IDEwIHJlcXVlc3QgbWVzc2FnZXMgdG8gDQp0aGUg cGVlciBiLCBhbmQgNSBtZXNzYWdlcyBoYXZlIGJlZW4gcmVjZWl2ZWQgYW5kIGFja25vd2xlZGdl ZCBieSB0aGUgcGVlciANCmIuIA0KDQpUaGlzIG1lYW5zIHRoYXQgYTBbVDJdLnkgPSAzMCwgYltU Ml0ueCA9IDI0LiBOb3RlIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCANCk1lc3NhZ2UgSUQgMjUsMjYs MjcsMjgsMjkgaGF2ZSBiZWVuIHNlbnQgYnkgdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwLCBidXQg DQpoYXZlIE5PVCByZWFjaGVkIHRoZSBwZWVyIGIwLiAoVGhlIHNlbmRlciB3aW5kb3cgc2l6ZSBv ZiB0aGUgY2x1c3RlciBpcyANCjUuKSANCg0KDQpBY2NvcmRpbmcgdG8gUkZDIDYzMTEsIA0KDQoi TTEgaXMgdGhlIG5leHQgc2VuZGVyJ3MgTWVzc2FnZSBJRCB0byBiZSB1c2VkIGJ5IHRoZSBtZW1i ZXIuICBNMSANCk1VU1QgYmUgY2hvc2VuIHNvIHRoYXQgaXQgaXMgbGFyZ2VyIHRoYW4gYW55IHZh bHVlIGtub3duIHRvIGhhdmUgDQpiZWVuIHVzZWQuICBJdCBpcyBSRUNPTU1FTkRFRCB0byBpbmNy ZW1lbnQgdGhlIGtub3duIHZhbHVlIGF0IA0KbGVhc3QgYnkgdGhlIHNpemUgb2YgdGhlIElLRSBz ZW5kZXIgd2luZG93LiIgDQoNCg0KTTEgPT0gYTFbVDJdLnkgKyBTVyA9PSAyMCArIDUgPT0gMjUg DQooYTFbVDJdLnkgPT0gYTFbVDBdLnkgPT0gMjApIA0KDQpBbmQgDQoiTTIgTVVTVCBiZSBhdCBs ZWFzdCB0aGUgaGlnaGVyIG9mIHRoZSByZWNlaXZlZCBNMSwgYW5kIG9uZSBtb3JlIA0KdGhhbiB0 aGUgaGlnaGVzdCBzZW5kZXIgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rlci4gIFRoaXMg DQppbmNsdWRlcyBhbnkgcHJldmlvdXMgcmVjZWl2ZWQgc3luY2hyb25pemF0aW9uIG1lc3NhZ2Vz LiIgDQogDQpNMiA9PSBtYXh7TTEsIDEgKyBiW1QyXS54KT09IG1heCgyNSwxKzI0KSA9PSAyNSAN Cg0KQWZ0ZXIgdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHJlY2VpdmVzIE0yLCBhMSBzZXRzIGEx W1QyXS55ID09IDI1IDwgDQphMFtUMl0ueSA9PSAzMC4gDQoNClRoZSBNZXNzYWdlIElEIGZvciB0 aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgbnVtYmVycyBmcm9tIDI1LiANCg0KVGhlIGZpcnN0IGZp dmUgTWVzc2FnZSBJRHMgYXJlIDI1LCAyNiwgMjcsMjgsMjkuIA0KDQpXaGVuIHRoZSBuZXcgYWN0 aXZlIG1lbWJlciBhMSBzZW5kcyByZXF1ZXN0IG1lc3NhZ2VzIHdpdGggTWVzc2FnZXMgSURzIDI1 LCANCjI2LDI3LDI4LDI5LCBzaW5jZSB0aGUgcGVlciBiIGhhcyBwcm9jZXNzZWQgdGhlIHJlcXVl c3QgbWVzc2FnZSB3aXRoIHRoZSANCnNhbWUgTWVzc2FnZSBJRHMsIHRoZSBwZWVyIGIgd2lsbCBy ZXR1cm4gcmVzcG9uc2UgbWVzc2FnZXMgZm9yIHRoZSByZXF1ZXN0IA0KbWVzc2FnZXMgZnJvbSB0 aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAuIA0KDQpUaGVuIGExIHJlY2VpdmVzIGFjY2VwdGFibGUg YnV0IG1pc21hY3RoZWQgcmVzcG9uc2UgbWVzc2FnZXMuIA0KDQogDQoyLiBDbGFyaWZpY2F0aW9u cyBmb3IgdGhlIHNpbXVsdGFuZXNvdXMgZmFpbG92ZXIgY2FzZSBGIGluIFNlY3Rpb24gMi4zIA0K Rm9yIHRoZSBzaW11bHRhbmVvdXMgZmFpbG92ZXIsIGNhc2UgRiBpcyB0aGUgbW9zdCBkZXZhc3Rh dGluZyBJTU8uIFNvIEknZCANCmxpa2UgdG8gY2xhcmlmeSBpdCBmaXJzdC4gDQoyLjEgTm90YXRp b24gZm9yIHRoZSBzaW11bHRhbmVzb3VzIGZhaWxvdmVyIGNhc2UgRiBpbiBTZWN0aW9uIDIuMyAN Cg0KDQphMDogdGhlIG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYSAN CmExOiB0aGUgbmV3IGFjdGl2ZSBjbHVzdGVyIG1lbWJlciBvZiB0aGUgY2x1c3RlciBhIA0KYjA6 IHRoZSBvbGQgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGIgDQpiMTogdGhl IG5ldyBhY3RpdmUgY2x1c3RlciBtZW1iZXIgb2YgdGhlIGNsdXN0ZXIgYiANCg0KDQpUMDogQXQg dGhpcyB0aW1lIHBvaW50LCB0aGUgbGFzdCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhMC9iMCBh bmQgYTEvYjEgDQppcyBjYXJyaWVkIG91dCwgDQoNClQxOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRo ZSBzaW11bHRhbmVvdXMgZmFpbG92ZXIgZXZlbnQgb2NjdXJzIA0KDQpUMjogQXQgdGhpcyB0aW1l IHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYjEg DQpzdGFydHMgDQoNCg0KVDM6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIE1lc3NhZ2UgSUQgc3lu Y2hyb25pemF0aW9uIGJldHdlZW4gYTEgYW5kIGIxIA0KZW5kcyANCg0KDQoNCi0tLS1UMC0tLS0t LS0tVDEtLS0tLS0tLS0tVDItLS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tIA0KDQogDQoyLjIgQW5hbHlzaXMgZm9yIHRoZSBzaW11bHRhbmVzb3VzIGZhaWxv dmVyIGNhc2UgRiBpbiBTZWN0aW9uIDIuMyANCg0KDQpJdCdzIHBvc3NpYmxlIHRoYXQgZnJvbSBU MCB0byBUMSwgYTAgYW5kIGIwIGRlbGV0ZXMgdGhlIG9sZCBJS0UgU0Egc2EwIGFuZCANCmNyZWF0 ZXMgYSBuZXcgSUtFIFNBIHNhMS4gDQpCdXQgYXQgVDIsIGExIGFuZCBiMSBkbyBOT1Qga25vdyB3 aGF0IGhhcyBoYXBwZW5lZCBmcm9tIFQwIGFuZCBUMSwgYW5kIGRvIA0KTk9UIGtub3cgdGhlIGV4 aXN0YW5jZSBvZiB0aGUgbmV3IElLRSBTQSBzYTEsIGFuZCB1c2UgdGhlIG9sZCBJS0UgU0Egc2Ew IA0KdG8gY2Fycnkgb3V0IE1lc3NhZ2UgSUQgc3luY2hyb25pemF0aW9uLiANClRoaXMgbWF5IGJy aW5nIHNvbWUgbW9yZSBzZXJpb3VzZSBwcm9ibGVtLiBTbyAgd2hlbiBzaW11bHRhbmVvdXMgZmFp bG92ZXIgDQpvY2N1cnMsIGEgc2ltcGxlIHR3by13YXkgc3luY2hyb25pemF0aW9uICBtYXkgbm90 IGJlIGFuIGFwcHJvcHJpYXRlIA0Kc29sdXRpb24uIA0KDQoNCg0KDQoNCg0KIkthbHlhbmkgR2Fy aWdpcGF0aSAoa2FnYXJpZ2kpIiA8a2FnYXJpZ2lAY2lzY28uY29tPiANCreivP7IyzogIGlwc2Vj LWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEyLTA2LTE0IDE5OjE0IA0KDQoNCsrVvP7Iyw0KInpoYW5n LnJ1aXNoYW5AenRlLmNvbS5jbiIgPHpoYW5nLnJ1aXNoYW5AenRlLmNvbS5jbj4sICJpcHNlY0Bp ZXRmLm9yZyIgPA0KaXBzZWNAaWV0Zi5vcmc+IA0Ks63LzQ0KDQrW98ziDQpSZTogW0lQc2VjXSBV cGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9yIElLRXYyL0lQc2VjICAgICAgICBIaWdo ICANCkF2YWlsYWJsaXR5DQogDQoNCg0KDQoNCg0KDQoNCg0KSGkgWmhhbmcsIA0KICANClRoYW5r cyBmb3IgZ29pbmcgdGhyb3VnaCB0aGUgUkZDIDYzMTEgLiANCiAgDQpJIGhhdmUgZ29uZSB0aHJv dWdoIHlvdXIgIHByb3Bvc2VkIGRyYWZ0IGFuZCBmZWx0IHRoYXQgdGhlcmUgaXMgc29tZSANCmNv bmZ1c2lvbiByZWdhcmRpbmcgdGhlIG1lc3NhZ2UgaWQgY29uY2VwdCBvZiBpa2V2Mi4gDQogIA0K SSBoYXZlIHNlZW4gdGhhdCBpbiBzZWN0aW9uIDIuMyB5b3Ugd2VyZSBjb21wYXJpbmcgdGhlIGhp Z2VyIHNlbmRlciB2YWx1ZSANCm9mIHgyIHdpdGggeTIuIA0KVGhhdCBpcyB3cm9uZy4gd2hlbiB4 MiBwcm9wb3NlcyB0aGUgbmV4dCBoaWdoZXIgbWVzc2FnZSBpZCB0byBiZSB1c2VkIHRvIA0Kc2Vu ZCBhIHJlcXVlc3QgLCANCnRoZW4gb24geTIgeW91IHNobGQgdGFsbHkgaXQgd2l0aCB0aGUgbmV4 dCBoaWdoZXIgbWVzc2FnZSBpZCBvZiB0aGUgDQpyZXF1ZXN0IHRvIGJlIHJlY2lldmVkIA0KICAg ICAgICAgICAgKGFuZCBub3Qgd2l0aCB0aGUgbmV4dCBoaWdoZXIgbWVzc2FnZSBpZCBvZiB0aGUg cmVxdWVzdCB0byBiZSANCnNlbnQpIA0KICANCmluIGlrZXYyIHRoZSAgbWVzc2FnZSBpZCBvZiBy ZXF1ZXN0cyB0byBiZSBzZW50IGFyZSBlbnRpcmVseSBkaWZmZXJlbnQgDQpmcm9tIG1lc3NhZ2Ug aWQgb2YgcmVxdWVzdHMgdG8gYmUgcmVjZWl2ZWQuIA0KdGhhdCBpcyB3aHkgUkZDIHNheXMgYSBt ZXNzYWdlIGlkIGlzIHVzZWQgZm91ciB0aW1lcyBvbiBhIGdpdmVuIGRldmljZS4gDQogIA0KMS4g bWVzc2FnZSBpZCBYIGlzIHVzZWQgd2hpbGUgc2VuZGluZyBhIHJlcXVlc3QgDQoyLiBtZXNzYWdl IGlkIFggaXMgdXNlZCB3aGlsZSByZWNlaXZpbmcgdGhlIHJlc3BvbnNlIA0KMy4gbWVzc2FnZSBp ZCBYIGlzIHVzZWQgdG8gcmVjZWl2ZSBhIHJlcXVlc3QgDQo0LiBtZXNzYWdlIGlkIFggaXMgdXNl ZCB0byBzZW5kIGEgcmVzcG9uc2UuIA0KICANCiAgDQpwbGVhc2UgZmluZCB0aGUgY29tbWVudHMg Zm9yIGVhY2ggc2VjdGlvbiANCiAgDQpTZWN0aW9uIDIuMTogIFRoaXMgaXMgYSBrbm93biBpc3N1 ZSBhbmQgdGhhdCBpcyB3aHkgdXNpbmcgUkZDIDYzMTEsICB3ZSANCmFyZSBzeW5jaHJvbmlzaW5n IHRoZSBtZXNzYWdlIGlkJ3MgDQogIA0KU2VjdGlvbiAyLjI6IFRoZSBwZWVyIGlzIGFzc3VtZWQg dG8gYmUgcHJvcGVyIGFuY2hvciBwb2ludCB3aGljaCBoYXMgDQpjb3JyZWN0IGluZm8gb2YgbWVz c2FnZSBpZCBvZiByZXF1ZXN0cyBzZW50IGFuZCByZWNpZXZlZCwgDQpldmVuIHdoZW4gcGVlciBp cyBjbHVzdGVyIG1lbWJlciAsIGFtb25nIHRoZSB0d28gZGV2aWNlcyBvbmUgb2YgdGhlbSB3b3Vs ZCANCmJlIGxlc3Mgd3JvbmcgYW5kIGhhdmUgaGlnaGVyIGFjY3VyYXRlIHZhbHVlcyBvZiBtZXNz YWdlIGlkJ3MgLiANCnNvIHdlIHBpY2sgdXAgdGhhdCB2YWx1ZS4gSSBkb250IHNlZSBhbnkgaXNz dWUgaGVyZS4gDQogIA0KU2VjdGlvbiAyLjM6IEZpcnN0IG9mIGFsbCB0aGVyZSBpcyBubyByZWxh dGlvbiBiZXR3ZWVuIE0xIGFuZCBQMS4gDQpvbiBhIGdpdmVuIGRldmljZS4gDQotLS0gTTEgaXMg dGhlIHByb3Bvc2VkIG1lc3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgc2VudCANCiAgICBQ MSBpcyB0aGUgcHJvcG9zZWQgbWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSByZWNlaXZl ZC4gDQogIA0Kd2hlbiBzaW11bGF0ZW5vdXMgZmFpbG92ZXIgaGFwcGVucywgeDIgbWlnaHQgaGF2 ZSBoaWdoZXIgdmFsdWUgb2YgTTEgd2hlbiANCmNvbXBhcmVkIHRvIHkyICwgYnV0IHgyIG1pZ2h0 IGhhdmUgbG93ZXIgdmFsdWUgb2YgUDEgd2hlbiBjb21wYXJlZCB0byB5Mi4gDQpJdCBkb2VzJ250 IG1hdHRlci4gYm90aCBhcmUgaW5kZXBlbmRlbnQuIHdoYXQgd2UgZXZlbnR1YWxseSBkbyBpcyBj b21wYXJlIA0KdGhlIE0xIHZhbHVlIGFjcm9zcyB4MiBhbmQgeTIgYW5kIHBpY2sgdGhlIGhpZ2Vy IG9uZS4gDQpzYW1lIHByb2Nlc3MgaXMgcmVwZWF0ZWQgZm9yIFAxLiANCiAgDQpjYXNlIDEgdG8g NiBhcmUgYWxyZWFkeSBoYW5kbGVkIGJ5IGJhc2ljIGlrZXYyIFJGQyAuIGxpa2UgaWYgd2UgcmVj ZWl2ZSANCnNhbWUgbWVzc2FnZSBpZCB0d2ljZSAsIHRoZW4gd2UgcmV0cmFuc21pdCBvciBkcm9w IGl0IGlmIGl0IGlzIG91dHNpZGUgdGhlIA0Kd2luZG93LiANCiAgDQogIA0KU2VjdGlvbiAzOiAg IGR1cmluZyBzaW11bHRhbmVvdXMgZmFpbG92ZXIgYm90aCB0aGUgY2x1c3RlciBhbmQgdGhlIHBl ZXIgDQptZW1iZXIgd291bGQgYmUgaW4gdW5yZWxpYWJsZSBzdGF0ZS4gDQpCb3RoIG9mIHRoZW0g YXJlIHdyb25nICwgYnV0IG9uZSBvZiB0aGVtIGlzIGxlc3Mgd3JvbmcgISEhIHNvIHdlIHdhbnQg dG8gDQpzdGFydCBmcm9tIHRoYXQgcG9pbnQgdG8gc3luY2hyb25pc2UgdGhlIG1lc3NhZ2UgaWQn cy4gDQogIA0Kc28gd2UgYXJlIGFsbG93aW5nIGJvdGggdGhlIG1lbWJlcnMgdG8gYW5ub3VuY2Ug dGhlaXIgbWVzc2FnZSBpZCdzIGFuZCANCnRoZW4gZXZlbnR1YWxseSB3ZSB3b3VsZCBzeW5jaHJv bmlzZSB0byB0aGUgaGlnaGVyIG51bWJlci4gDQpJIGRvbnQgc2VlIGFueSBmbGF3IGhlcmUuIFBs ZWFzZSBleHBsYWluIHdpdGggYW4gZXhhbXBsZS4gDQogIA0KQnkgeW91ciBwcm9wb3NhbCBpbiBj YXNlIG9mIHNpbXVsdGFuZW91cyBmYWlsb3ZlciwgYm90aCB0aGUgY2x1c3RlciBhbmQgDQpwZWVy IHdpbGwgYmUgaW4gVU5TWU5FRCBzdGF0ZSBhbmQgDQpib3RoIHdvdWxkIGVuZCB1cCBzZW5kaW5n IGFuZCByZWplY3RpbmcgdGhlIHN5bmNocm9uaXNhdGlvbiByZXF1ZXN0LiANClRoaXMgd291bGQg bGVhZCB0byByZXBlYXRlZCBzeW5jaHJvbmlzYXRpb24gZWZmb3J0cyBhbmQgdGhlIHByb2JsZW0g b2YgDQptZXNzYWdlIHN5bmNocm9uaXNhdGlvbiBpcyBuZXZlciBzb2x2ZWQuIA0KICANCnNvIFVO U1lORUQgc3RhdGUgaXMgbm90IHJlcXVpcmVkLiANCiAgDQpTZWN0aW9uIDQ6IA0KICANCkkgZmVl bCB0aGF0IFJGQyA2MzExIGFscmVhZHkgc29sdmVzIHRoZSBtZXNzYWdlIGlkIHN5bmNocm9uaXNh dGlvbiBpc3N1ZS4gDQpJIGRvbnQgdGhpbmsgd2UgbmVlZCB0byBpbmNyZW1lbnQgTTEgYnkgZG91 YmxlIHRoZSB3aW5kb3cgc2l6ZSBhcyBwcm9wb3NlZCANCmJ5IHlvdS4gDQpQbGVhc2Ugc3VwcG9y dCB5b3VyIHByb3Bvc2FsIHdpdGggYW4gZXhhbXBsZSB3aXRoIG1lc3NhZ2UgaWQgdmFsdWVzIG9m IA0KbnVtYmVycyBpbnN0ZWFkIG9mIHZhcmlhYmxlcy4gDQpMaWtlIE0xIGlzIDMgLCBNMiBpcyA0 IGV0YyBldGMuIA0KICANCk51bWJlcnMgbWFrZSBpdCBtb3JlIGNsZWFyLiANCiAgDQpyZWdhcmRz LCANCmthbHlhbmkgDQogIA0KRnJvbTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlw c2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCnpoYW5nLnJ1aXNoYW5AenRlLmNv bS5jbg0KU2VudDogTW9uZGF5LCBKdW5lIDExLCAyMDEyIDc6MzYgQU0NClRvOiBpcHNlY0BpZXRm Lm9yZw0KU3ViamVjdDogW0lQc2VjXSBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNpb24gZm9y IElLRXYyL0lQc2VjIEhpZ2ggDQpBdmFpbGFibGl0eSANCiAgDQoNCg0KRGVhciBBbGwsIA0KDQog SSd2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgIiBVcGRhdGVzIHRvIHRoZSBJS0V2MiBFeHRlbnNp b24gZm9yIA0KSUtFdjIvSVBzZWMgSGlnaCBBdmFpbGFibGl0eSIuIFRoaXMgZHJhZnQgYW5hbHl6 ZXMgc29tZSBpc3N1ZXMgaW4gUkZDIA0KNjMxMSwgDQphbmQgcHJvcG9zZXMgc29tZSB1cGRhdGVz LiBMb29rIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4gDQoNCg0KQlIsIA0KDQpSdWlzaGFuIFpo YW5nX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2Vj IG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBzZWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJUHNlYyBtYWlsaW5nIGxpc3QNCklQc2VjQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg0K --=_alternative 0023ACFE48257A2A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFZhbGVyeSw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0kgYWdyZWUgd2l0 aCB5b3UgdGhhdCB0aGUgbmV3bHkNCmFjdGl2ZSBjbHVzdGVyIG1lbWJlciBtYXkgcmVjZWl2ZSA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuIGFjY2VwdGFibGUg YnV0IG1pc21hdGNoZWQgcmVzcG9uc2UNCm1lc3NhZ2UuIEFuZCBpbiBzdWNoIGFuIGNhc2UsIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlIHNpdHVhdGlvbiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj53aWxsDQpiZWNvbWUgdW5wcmVkaWN0YWJs ZTwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+IGFuZCBtYXkgY2F1c2UNCnNv bWUgc2VjdXJpdHkgcmlza3MuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ SW4gbXkgb3BpbmlvbiwgZXZlbiB0aGUgYWJvdmUgY2FzZSBoYXBwZW5zDQpyYXJlbHksIHdlIHNo b3VsZCBsZXQgZGV2ZWxvcGVycyBhd2FyZSBvZiBzdWNoIGEgcmlzay48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5JIHRoaW5rIGl0J3MgYmV0dGVyIGlmIHdlIGNhbiBtYWtl IHNvbWUgdXBkYXRlcw0KdG8gUkZDIDYzMTEuIDwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlIsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SdWlzaGFuIFpoYW5nPGJyPg0KPC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O1ZhbGVyeSBTbXlz bG92JnF1b3Q7DQombHQ7c3ZhbnJ1QGdtYWlsLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtpcHNlYy1ib3VuY2VzQGll dGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDYt MjIgMjA6Mzk8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+JnF1b3Q7S2FseWFuaSBHYXJpZ2lwYXRpIFwoa2FnYXJpZ2lcKSZxdW90Ow0KJmx0 O2thZ2FyaWdpQGNpc2NvLmNvbSZndDssICZsdDt6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24mZ3Q7 PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5pcHNlY0BpZXRmLm9yZywgaXBzZWMtYm91bmNlc0BpZXRmLm9y ZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtJUHNlY10gVXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0 ZW5zaW9uDQpmb3IgSUtFdjIvSVBzZWMgSGlnaCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtB dmFpbGFibGl0eTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+SGksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5J IHRlbmQgdG8gYWdyZWUgd2l0aCBaaGFuZywgdGhhdCBkZXNjcmliZWQNCnNjZW5hcmlvIG1heSB0 YWtlIHBsYWNlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkl0IG1heSBo YXBwZW4gaWYsIGZvciBzb21lIHJlYXNvbiwgbmV3bHkNCmFjdGl2ZSBtZW1iZXIgcGlja3MgTTE8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5sb3dlciB0aGFuIHRoZSBoaWdo ZXN0IHZhbHVlIHVzZWQgZm9yIHJlcXVlc3QNCmJ5IHByZXZpb3VzbHkgYWN0aXZlIG1lbWJlci48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5TdXJlLCBidWxsZXQgMSBpbiBz ZWN0aW9uIDUuMSBvZiBSRkM2MzExDQpzYXlzIHRoYXQgbmV3bHkgYWN0aXZlIG1lbWJlcjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPk1VU1QgY2hvb3NlIE0xIGxhcmdlciB0 aGFuIGFueSB2YWx1ZSBrbm93bg0KdG8gaGF2ZSBiZWVuIHVzZWQsPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+YnV0IHRoZSBxdWVzdGlvbiBpcyAtIGhvdyBpdCBjYW4gcmVs aWFibHkNCmNhbGN1bGF0ZSB0aGlzIHZhbHVlPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPklmIHN5bmNocm9uaXphdGlvbiBjaGFubmVsIGJldHdlZW4gbWVtYmVycw0KaXMg cmVsaWFibGUgYW5kIHN5bmNyb25pemF0aW9uIG1lc3NhZ2VzPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+YXJlIGZyZXF1ZW50IGVub3VnaCAoc2F5LCBmb3IgZWFjaCBjaGFu Z2VzDQpvZiBNZXNzYWdlIElEIGNvdW50ZXJzKSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj50aGFuIG5vIHByb2JsZW0gaGVyZS4gQnV0IGlmIHN5bmNocm9uaXphdGlvbg0K YmV0d2VlbiBtZW1iZXJzIGlzIG5vdCBzbyBmcmVxdWVudCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj5vciBjaGFubmVsIGFsbG93cyBtZXNzYWdlIGxvc3MsIHRoYW4gbmV3 bHkNCmFjdGl2ZSBtZW1iZXIgY2FuIG9ubHk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj5lc3RpbWF0ZSB0aGUgaGlnaGVzdCBzZW5kZXIncyBNZXNzYWdlIElEDQp1c2VkIGJ5 IHByZXZpb3VzbHkgYWN0aXZlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ bWVtYmVyLiBBbmQgaWYgaXRzIGVzdGltYXRpb24gYXBwZWFycyB0bw0KYmVjb21lIHdyb25nIChs ZXNzIHRoYW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5hY3R1YWxseSB1 c2VkKSwgdGhhbiAyIHNjZW5hcmlvdXMgYXJlIHBvc3NpYmxlOjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjEuIElmIGxhc3QgcmVxdWVzdHMgbWFkZSBieSBwcmV2aW91c2x5 IGFjdGl2ZQ0KbWVtYmVyIGdldCBkZWxheWVkIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgb24gdGhlaXIgZmx5IHRvIHBlZXIgYW5kIGFycml2ZQ0K dGhlcmUgQUZURVIgTWVzc2FnZSBJRCBzeW5jcm9uaXphdGlvbjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgaXMgZmluaXNoZWQsIHRoYW4gd2UgaGF2 ZSBaaGFuZydzDQpzY2VuYXJpbyAtIGZvciBwZWVyIHRoZXkgd2lsbCBsb29rPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyBsaWtlIGdlbmVyYXRlZCBi eSBuZXdseSBhY3RpdmUNCm1lbWJlciBhbmQgaXQgd2lsbCByZXNwb25kIHRvIHRoZW08L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7IGNvcnJlc3BvbmRl bnRseSwgYnV0IGZvciBuZXdseQ0KYWN0aXZlIG1lbWJlciB0aG9zZSByZXNwb25zZXM8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7IHdpbGwgYmUgZWl0 aGVyIHVuZXhwZWN0ZWQgKGlmDQppdCBkb2Vzbid0IGdlbmVyYXRlIGFueSByZXF1ZXN0IHlldCk8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7IG9yIGlu Y29ycmVjdGx5IHByb2Nlc3NlZCAoaWYNCml0IGhhcyBhbHJlYWR5IG1hZGUgc29tZSByZXF1ZXN0 cykuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+Jm5ic3A7ICZuYnNw OyBJbiB0aGUgbGF0dGVyIGNhc2Ugc2l0dWF0aW9uDQp3aWxsIGJlY29tZSB1bnByZWRpY3RhYmxl LjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPi8v IFRoYXQncyB0aGUgcG9pbnQuIEluIHRoaXMgY2FzZSwNClJGQyA2MzExIG1heSBlbmQgdXAgd2l0 aCBhIHdyb25nIHJhdGhlciB0aGFuIGFuIHVuc3VjY2Vzc2Z1bCBNZXNzYWdlIElEDQpzeW5jaHJv bml6YXRpb24uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlh bCI+SW4gbXkgb3BpbmlvbiwgZXZlbiB0aGUgYWJvdmUNCmNhc2UgaGFwcGVucyByYXJlbHksIHdl IHNob3VsZCBsZXQgZGV2ZWxvcGVycyBhd2FyZSBvZiBzdWNoIGEgcmlzay48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkkgdGhpbmsgaXQncyBiZXR0ZXIg aWYgd2UgY2FuDQptYWtlIHNvbWUgdXBkYXRlcyB0byBSRkMgNjMxMS4gPC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Mi4gVGhlIG90aGVyIHBy b2JsZW0gaW4gdGhpcyBzaXR1YXRpb24gaXMNCnRoYXQgYWNjb3JkaW5nIHRvIGJ1bGxldCA0PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyBpbiBzZWN0 aW9uIDUuMSBvZiBSRkM2MzExIHBlZXINCk1VU1Qgc2lsZW50bHkgZHJvcCBhbnkgbWVzc2FnZSw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7IGNvbnRh aW5pbmcgTTEgbGVzcyBvciBlcXVhbA0KdGhhbiB0aGUgaGlnaGVzdCB2YWx1ZSBpdCBoYXMgc2Vl biBmcm9tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNw OyB0aGUgY2x1c3Rlci4gQWdhaW4sIGlmIG5ld2x5DQphY3RpdmUgbWVtYmVyIGluY29ycmVjdGx5 IGVzdGltYXRlczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAm bmJzcDsgdGhlIGhpZ2hlc3QgdmFsdWUsIHVzZWQgYnkNCnByZXZpb3VzbHkgYWN0aXZlIG1lbWJl ciBhbmQgc2VuZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAm bmJzcDsgc21hbGxlciB2YWx1ZSBpbiBNMSwgdGhhbiBwZWVyDQp3aWxsIHNpbGVudGx5IGRyb3Ag dGhlIG1lc3NhZ2UsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7 ICZuYnNwOyB0aGF0IHdpbGwgZXZlbnR1YWxseSBsZWFkIHRvDQpJS0UgU0EgZGVsZXRpb24uPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5SZWdhcmRzLDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlNteXNsb3YgVmFsZXJ5LjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+LS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxi PkZyb206PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86a2FnYXJpZ2lAY2lzY28uY29tPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PkthbHlhbmkNCkdhcmlnaXBh dGkgKGthZ2FyaWdpKTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Ubzo8L2I+ IDwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5ydWlzaGFuQHp0ZS5jb20uY24+PGZvbnQgc2l6 ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhhbmcucnVpc2hhbkB6dGUuY29t LmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48Yj5DYzo8L2I+IDwvZm9udD48 YSBocmVmPW1haWx0bzppcHNlY0BpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT5pcHNlY0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjsgPC9mb250PjxhIGhyZWY9Im1haWx0bzppcHNlYy1ib3Vu Y2VzQGlldGYub3JnIj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT5pcHNlYy1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij48Yj5TZW50OjwvYj4gMjAgp9qn8Kffp/EgMjAxMiCn1C4NCjE1OjI2PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtJUHNlY10g VXBkYXRlcw0KdG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3IgSUtFdjIvSVBzZWMgSGlnaCBBdmFp bGFibGl0eTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj5IaSBaaGFuZyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxiPkZvciBBbmFseXNpcyAxIDwvYj48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5hMFt0XS54ICZuYnNw O2EwJ3MgbWF4aW11bQ0KbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgdW50aWwg dGltZSB0ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj5hMFt0XS55ICZuYnNwO2EwJ3MgbmV4dCBzZW5kZXINCm1lc3NhZ2UgSUQgJm5i c3A7YXQgdGltZSB0IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0iQ2FsaWJyaSI+SSB0aGluayB0aGVyZSBpcyBjb25mdXNpb24NCmFib3ZlLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5JIGd1ZXNzIHdo YXQgdSBhY3R1YWxseSB3YW50ZWQNCnRvIGNvbnZleSBpcyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmEwW3RdLnggJm5ic3A7YTAncyBt YXhpbXVtDQptZXNzYWdlIElEIG9mIHRoZSByZXF1ZXN0IHNlbnQgYW5kIG9yZGVybHkgcmVzcG9u c2UgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlcg0KYiB1bnRpbCB0aW1lIHQgLCBzYXkgaWYgYSBoYXMg cmVjZWl2ZWQgcmVzcG9uc2VzIGZvciAyIGFuZCAzIGFuZCA1ICZuYnNwOywNCnRoaXMgdmFsdWUg aXMgMy4gU28gbm93IHRoZSB3aW5kb3cgd291bGQgYmUgNC04IChpbmNsdXNpdmUpPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmEwW3RdLnkgJm5i c3A7YTAncyBuZXh0IHJlcXVlc3QNCm1lc3NhZ2UgSUQgdG8gYmUgc2VudCBhdCB0aW1lIHQgLCB0 aGlzIHZhbHVlIGlzIDYgLCBpZiBpdCBoYXMgYWxyZWFkeSBzZW50DQp0aGUgcmVxdWVzdHMgMiwz LDQsNSwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj5iW3RdLnggJm5ic3A7IGIncyBtYXhpbXVtDQptZXNzYWdlIElEIG9mIHRoZSBvcmRl cmx5IHJlc3BvbnNlIHNlbnQgdG8gY2x1c3RlciAmbmJzcDt1bnRpbCB0aW1lIHQgLA0KaWYgaXQg aGFzIHNlbnQgcmVzcG9uc2UgdG8gMiwzIGFuZCA1IGlkIHJlcXVlc3RzICwgaXQgaXMgc3RpbGwg My48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ Ylt0XS55ICZuYnNwOyBiJ3MgbmV4dCBtZXNzYWdlDQppZCBvZiB0aGUgcmVxdWVzdCB0byBiZSBy ZWNlaXZlZCwgd2hpY2ggaXMgNiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5JIGd1ZXNzIHRoZSBleGFtcGxlIGhhcyB3cm9uZw0K dmFsdWVzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+aWYgd2luZG93IHNpemUgaXMgNSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPnRoZW4gPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5Gb3IgYSBjb25jcmV0ZSBleGFt cGxlLCBsZXQncw0KYXNzdW1lOiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPmExW1QwXS54ID09IGEwW1QwXS54ID0gOQ0KLS0tLS0tLS0t LS0tLS0taG93IGNhbiB4IGFuZCB5IHZhcnkgYnkgMTAgd2hlbiB0aGUgd2luZG93IHNpemUgaXMg NSAmbmJzcDs/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPmExW1QwXS55ID09IGEwW1QwXS55ID0gMjANCjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YltUMF0ueCA9IDE5ICZuYnNwOyAt LSBzYW1lDQppcyB0aGUgY2FzZSBoZXJlLi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+YltUT10ueSA9IDEwIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UGxlYXNlIGFkanVzdCB0aGVz ZSB2YWx1ZXMNCmFuZCB0aGVuIHRoZXJlIHdpbGwgYmUgbm8gaXNzdWVzIGFzIG1lbnRpb25lZCBi eSB5b3UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj5hbHNvIHBsZWFzZSByZWZlciB0byB0aGUNCnNlY3Rpb24gOC4xIGFuZCA5IG9mIHRo ZSBSRkMgNjMxMSB3aGljaCBzYXlzIHRoYXQgd2hlbiB0aGUgd2luZG93IG1vdmVzDQp0byB0aGUg c3luY2hyb25pc2VkIHZhbHVlLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj5hbGwgdGhlIG9sZCBwZW5kaW5nIHJlcXVlc3RzDQphbmQgdG8tYmUg cmV0cmFuc21pdHRlZCByZXNwb25zZXMgc2hvdWxkIGJlIGRlbGV0ZWQuIFNvIHRoZSBiZWxvdyBp c3N1ZQ0Kd2lsbCBub3QgaGFwcGVuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0 OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzAwNzBjMCBmYWNlPSJDYWxpYnJpIj48aT5XaGVuIHRoZSBuZXcgYWN0aXZlIG1lbWJlcg0KYTEg c2VuZHMgcmVxdWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2VzIElEcyAyNSwgMjYsMjcsMjgsMjks IHNpbmNlIHRoZQ0KcGVlciBiIGhhcyBwcm9jZXNzZWQgdGhlIHJlcXVlc3QgbWVzc2FnZSB3aXRo IHRoZSBzYW1lIDwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDcwYzAgZmFj ZT0iQ2FsaWJyaSI+PGk+TWVzc2FnZSBJRHMsIHRoZSBwZWVyDQpiIHdpbGwgcmV0dXJuIHJlc3Bv bnNlIG1lc3NhZ2VzIGZvciB0aGUgcmVxdWVzdCBtZXNzYWdlcyBmcm9tIHRoZSBvbGQgYWN0aXZl DQptZW1iZXIgYTAuIDwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDcwYzAg ZmFjZT0iQ2FsaWJyaSI+PGk+Jm5ic3A7PC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzAwNzBjMCBmYWNlPSJDYWxpYnJpIj48aT5UaGVuIGExIHJlY2VpdmVzIGFjY2VwdGFibGUN CmJ1dCBtaXNtYWN0aGVkIHJlc3BvbnNlIG1lc3NhZ2VzLjwvaT48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDcwYzAgZmFjZT0iQ2FsaWJyaSI+PGk+Jm5ic3A7PC9pPjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48Yj5Gb3IgQW5h bHlzaXMgMjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPlRoaXMgaXMgdGhlIHByb2JsZW0gb2YgYmFzaWMNCkhBIHNpbXVsYXRlbm91 cyBmYWlsLW92ZXIgYW5kIG5vdCBqdXN0IGFib3V0IG1lc3NhZ2UgSUQgc3luY2hyb25pc2F0aW9u LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+d2hlbiBib3RoIG9mIHRoZSBkZXZpY2VzDQpkb26hr3QgaGF2ZSBuZXcgc2EgYW5kIGp1c3Qg aGF2ZSB0aGUgb2xkIHNhLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj5UaGVuIHRoZXkgd2lsbCAmbmJzcDtjb250aW51ZQ0Kd2l0aCB0aGUgb2xk IHNhIG9yIGJyaW5nIGRvd24gdGhlIHNhIGJhc2VkIG9uIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb250 cm9sLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+dGhlIHN5bmMgdGltZSB3aXRoaW4gYSBjbHVzdGVyDQombmJzcDthbW9uZyBhIGFuZCBi IG1pZ2h0IGJlIHNhbWUgb3IgZGlmZmVyZW50IGR1ZSB0byB3aGljaCBvbmUgb2YgdGhlbQ0Kd291 bGQgaGF2ZSBvbGQgc2EgYW5kIGFub3RoZXIgd291bGQgaGF2ZSBuZXcgc2EuIGluIHN1Y2ggPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmNhc2Vz IGJvdGggdGhlIHNhIHdvdWxkIGJlDQpkZWxldGVkIGV2ZW50dWFsbHkgYW5kIG5ldyBzYSBpcyBl c3RhYmxpc2hlZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i Q2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPm9yIGV2ZW4gaWYgc3luYyB0aW1lcyBhcmUNCmRpZmZlcmVudCwgb25lIHdv dWxkIGhhdmUgb2xkIHNhIHdpdGggbGVzc2VyIG1lc3NhZ2UgaWQncyBhbmQgb3RoZXIgaGF2ZQ0K c2FtZSBvbGQgc2Egd2l0aCBoaWdoZXIgbWVzc2FnZSBpZCdzIGFuZCB0aGVuIGJvdGggd2lsbCA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+c3Rh cnQgZnJvbSB0aGUgaGlnaGVyIG1lc3NhZ2UNCmlkIHZhbHVlcy48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlJlZ2FyZHMsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPmthbHlhbmk8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBpcHNl Yy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8L2I+ IFdlZG5lc2RheSwgSnVuZSAyMCwgMjAxMiA3OjQ0IEFNPGI+PGJyPg0KVG86PC9iPiBLYWx5YW5p IEdhcmlnaXBhdGkgKGthZ2FyaWdpKTxiPjxicj4NCkNjOjwvYj4gaXBzZWNAaWV0Zi5vcmc7IGlw c2VjLWJvdW5jZXNAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtJUHNlY10gVXBk YXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZvciBJS0V2Mi9JUHNlYw0KSGlnaCBBdmFpbGFi bGl0eTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KSGkgS2FseWFuaSw8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpGaXJzdCBJJ2QgbGlrZSB0byBtYWtl IHNvbWUgY2xhcmlmaWNhdGlvbnMgYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMsDQphbmQgbGVh dmUgb3RoZXIgY2xhcmlmaWNhdGlvbnMgdG8gZnVydGhlciBkaXNjdXNzaW9ucy48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48YnI+DQoxLiBDbGFyaWZpY2F0aW9uIGZvciBjYXNlIEMg aW4gU2VjdGlvbiAyLjI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KKGNhc2UgQyBpcyB0aGUgbW9zdCB0 cm91Ymxlc29tZSBpbiB0aGlzIHNlY3Rpb24gSU1PLlNvIEknZCBsaWtlIHRvIGNsYXJpZnkNCml0 Lik8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQoxLjEgTm90YXRpb24gZm9yIGNhc2UgQyBpbiBTZWN0aW9u IDIuMjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQp4OiB0aGUgbWF4aW11bSBtZXNzYWdlIElE IHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgcGFydHk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KeTogdGhl IG5leHQgc2VuZGVyIG1lc3NhZ2UgSUQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMDogdGhl IG9sZCBhY3RpdmUgY2x1c3RlciBtZW1iZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTE6IHRoZSBu ZXcgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmI6ICZuYnNwO3Ro ZSBwZWVyPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0K PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTBbdF0ueCAmbmJzcDthMCdz IG1heGltdW0gbWVzc2FnZSBJRCByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGIgdW50aWwgdGltZQ0K dDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCmEwW3RdLnkgJm5ic3A7YTAncyBuZXh0IHNlbmRlciBtZXNz YWdlIElEICZuYnNwO2F0IHRpbWUgdDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVt0XS54 ICZuYnNwO2ExJ3MgbWF4aW11bSBtZXNzYWdlIElEIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYiAm bmJzcDt1bnRpbA0KdGltZSB0IDxicj4NCmExW3RdLnkgJm5ic3A7YTEncyBuZXh0IHNlbmRlciBt ZXNzYWdlIElEICZuYnNwO2F0IHRpbWUgdDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiW3Rd LnggJm5ic3A7IGIncyBtYXhpbXVtIG1lc3NhZ2UgSUQgcmVjZWl2ZWQgZnJvbSB0aGUgY2x1c3Rl ciAmbmJzcDt1bnRpbA0KdGltZSB0IDxicj4NCmJbdF0ueSAmbmJzcDsgYidzIG5leHQgc2VuZGVy IG1lc3NhZ2UgSUQgYXQgdGltZSB0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClQw OiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBsYXN0IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGEw IGFuZCBhMSBpcyBjYXJyaWVkDQpvdXQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpUMTogQXQg dGhpcyB0aW1lIHBvaW50LCB0aGUgZmFpbG92ZXIgZXZlbnQgb2NjdXJzPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NClQyOiBBdCB0aGlzIHRpbWUgcG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5bmNo cm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiDQpzdGFydHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQpUMzogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJv bml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYg0KZW5kczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N ClNXOiB0aGUgc2VuZGVyIHdpbmRvdyBzaXplIG9mIHRoZSBjbHVzdGVyLiBMZXQncyBhc3N1bWUg U1cgaXMgNS4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQotLS0tVDAtLS0tLS0tLVQxLS0tLS0t LS0tLVQyLS0tLS0tLS0tLVQzLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCjEuMiBBbmFseXNpcyBmb3IgY2Fz ZSBDIGluIFNlY3Rpb24gMi4yPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N Cjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCldlIGtu b3cgdGhhdDogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtUMF0ueCA9PSBhMFtUMF0ueDwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCmExW1QwXS55ID09IGEwW1QwXS55PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KKFRoZSByZWFvbiBpcyB0aGF0IGF0IFQwLCB0aGUgc3luY2hyb25pemF0aW9uIGJldHdlZW4g YTAgYW5kIGExIGlzIGNhcnJpZWQNCm91dC4pPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQW5k PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTFbVDFdLnggPT0gYTBbVDBdLnggPGJy Pg0KYTFbVDFdLnkgPT0gYTBbVDBdLnk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBbmQ8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtUMl0ueCA9PSBhMFtUMF0ueCA8YnI+DQphMVtUMl0u eSA9PSBhMFtUMF0ueTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCihUaGUgcmVhb24gaXMgdGhh dCBmcm9tIFQwIHRvIFQyLCB0aGUgc3RhdGUgZGF0YSBvZiBhMSBrZWVwcyB1bmNoYW5nZWQuKTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBY2NvcmRpbmcgdG8gUkZDIDYzMTEsIDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KJnF1b3Q7TTEgaXMgdGhlIG5leHQgc2VuZGVyJ3MgTWVzc2FnZSBJ RCB0byBiZSB1c2VkIGJ5IHRoZSBtZW1iZXIuICZuYnNwO00xPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N Ck1VU1QgYmUgY2hvc2VuIHNvIHRoYXQgaXQgaXMgbGFyZ2VyIHRoYW4gYW55IHZhbHVlIGtub3du IHRvIGhhdmU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYmVlbiB1c2VkLiAmbmJzcDtJdCBpcyBSRUNP TU1FTkRFRCB0byBpbmNyZW1lbnQgdGhlIGtub3duIHZhbHVlIGF0PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCmxlYXN0IGJ5IHRoZSBzaXplIG9mIHRoZSBJS0Ugc2VuZGVyIHdpbmRvdy4mcXVvdDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQXQgVDIsIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBj YW4gc2V0IE0xPWExW1QyXS55ICsgU1cuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K QW5kIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KJnF1b3Q7TTIgTVVTVCBiZSBhdCBsZWFzdCB0 aGUgaGlnaGVyIG9mIHRoZSByZWNlaXZlZCBNMSwgYW5kIG9uZSBtb3JlPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoYW4gdGhlIGhpZ2hlc3Qgc2VuZGVyIHZhbHVl IHJlY2VpdmVkIGZyb20gdGhlIGNsdXN0ZXIuDQombmJzcDtUaGlzPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7aW5jbHVkZXMgYW55IHByZXZpb3VzIHJlY2VpdmVkIHN5 bmNocm9uaXphdGlvbiBtZXNzYWdlcy4mcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQpBdCBUMiwgdGhlIHBlZXIgYiBjYW4g c2V0IE0yID0gbWF4KE0xLCAxICsgYltUMl0ueCkuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N Ck0xPT1hMVtUMl0ueSArIFNXID0mZ3Q7IE0xID09IGEwW1QwXS55ICsgU1cgJm5ic3A7PSZndDsg TTEgPT0gYTBbVDBdLnkNCisgNTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClN1cHBvc2Ugc29t ZSBtZXNzYWdlIGV4Y2hhbmdlcyAoaS5lLiwgMTAgbWVzc2FnZXMpIGhhdmUgYmVlbiBjYXJyaWVk IG91dA0KZnJvbSBUMCB0byBUMiwgaXQncyBwb3NzaWJsZSB0aGF0IGJbVDJdLnggKyAxICZndDsg YTBbVDBdLnkgKyA1LiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoZW4gdGhlIHBlZXIgYiBz ZXRzIE0yPTEgKyBiW1QyXS54LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBdCBUMywgd2hl biB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgcmVjZWl2ZXMgdGhlIE1lc3NhZ2UgSUQgc3luY2hy b25pemF0aW9uDQpyZXNwb25zZSBmcm9tIHRoZSBwZWVyIGIsIGExICZuYnNwO3NldHMgYTFbVDNd LnkgPSBNMi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTFbVDNdLnkgPT0gTTIgPSZndDsg YTFbVDNdLnkgPT0xICsgYltUMl0ueC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K QXQgVDIsIGEwW1QyXS55IGNvdWxkIGJlIGJbVDJdLngrNS4gPGJyPg0KKFRoZSByZWFvbiBpcyB0 aGF0IGEwJ3Mgc2VudCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltUMl0u eCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1DQptYXkgTk9UIGhhdmUgcmVhY2hlZCB0 byB0aGUgcGVlciBiLikgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpUaGlzIG1lYW5zIGExW1Qz XS55ICZsdDsgYTBbVDJdLnkuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N Cjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoaXMgbWVhbnMg dGhlIGZpcnN0IGZpdmUgbWVzc2FnZXMgc2VudCBieSB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEg d2lsbA0KaGF2ZSBNZXNzYWdlIElEcyBiW1QyXS54KzEsIGJbVDJdLngrMixiW1QyXS54KzMsYltU Ml0ueCs0LGJbVDJdLngrNS4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpTdXBwb3NlIGFmdGVy IFQzLCB0aGUgcGVlciByZWNlaXZlcyB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAncyBzZW50IG1l c3NhZ2VzDQp3aXRoIE1lc3NhZ2UgSURzIGJbVDJdLngrMSwgYltUMl0ueCsyLGJbVDJdLngrMyxi W1QyXS54KzQsYltUMl0ueCs1LCBhbmQNCnNlbmRzIHJlc3BvbnNlIG1lc3NhZ2VzLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCkFmdGVyIHRoYXQsIHRoZSBuZXcgYWN0aXZlIG1lbWJlciBhMSBz ZW5kcyB0aGUgZmlyc3QgZml2ZSByZXF1ZXN0IG1lc3NhZ2VzDQp3aXRoIE1lc3NhZ2UgSURzIGJb VDJdLngrMSwgYltUMl0ueCsyLGJbVDJdLngrMyxiW1QyXS54KzQsYltUMl0ueCs1LjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpBZnRlciByZWNldmluZyB0aGVzZSByZXF1ZXN0IG1lc3NhZ2VzLCB0aGUg cGVlciBiIHdpbGwgcmVnYXJkcyB0aGVzZSByZXF1ZXN0cw0KYXMgcmVzZW50IG1lc3NhZ2VzLCBh bmQgcmV0dXJucyByZXNwb25zZSBtZXNzYWdlcyBmb3IgPGJyPg0KcmVxdWVzdHMgb2YgJm5ic3A7 YTAncyBzZW50IG1lc3NhZ2VzIHdpdGggTWVzc2FnZSBJRHMgYltUMl0ueCsxLCBiW1QyXS54KzIs YltUMl0ueCszLGJbVDJdLngrNCxiW1QyXS54KzUNCnRvIGExLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CihNeSB1bmRlcnN0YW5kaW5nLCBhY2NvcmRpbmcgdG8gUkZDIDU5OTYsIGlzIHRoYXQgdGhlIHBl ZXIgc2hvdWxkIHRyZWF0DQp0aGUgbmV3IGFjdGl2ZSBtZW1iZXIncyByZXF1ZXN0IG1lc3NhZ2Vz IGFzIHJlc2VudCByZXFldXN0cy4gKTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgcmUtc2VudCAmbmJzcDsgJm5ic3A7IDxicj4NCkFzIGEgcmVzdWx0LCB0 aGUgcGVlciBiIHJlY2VpdmVzIGFjY2VwdGFibGUgYnV0IG1pc21hdGNoZWQgcmVzcG9uc2VzIGZv cg0KaXRzIHJlcXVlc3QgbWVzc2FnZXMgd2l0aCBNZXNzYWdlIElEcyBhMVtUMl0ueCsxLCBhMVtU Ml0ueCsyLGExW1QyXS54KzMsYTFbVDJdLngrNCxhMVtUMl0ueCs1LjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCkZvciBhIGNvbmNy ZXRlIGV4YW1wbGUsIGxldCdzIGFzc3VtZTogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtU MF0ueCA9PSBhMFtUMF0ueCA9IDk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQphMVtUMF0ueSA9PSBhMFtU MF0ueSA9IDIwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYltUMF0ueCA9IDE5PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KYltUT10ueSA9IDEwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KRnJvbSBU MCB0byBUMSwgdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwIGhhdmUgc2VudCAxMCByZXF1ZXN0IG1l c3NhZ2VzIHRvDQp0aGUgcGVlciBiLCBhbmQgNSBtZXNzYWdlcyBoYXZlIGJlZW4gcmVjZWl2ZWQg YW5kIGFja25vd2xlZGdlZCBieSB0aGUgcGVlcg0KYi4gPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpUaGlzIG1lYW5zIHRoYXQgYTBbVDJdLnkgPSAzMCwgYltUMl0ueCA9IDI0LiBOb3RlIHJlcXVl c3QgbWVzc2FnZXMgd2l0aA0KTWVzc2FnZSBJRCAyNSwyNiwyNywyOCwyOSBoYXZlIGJlZW4gc2Vu dCBieSB0aGUgb2xkIGFjdGl2ZSBtZW1iZXIgYTAsIGJ1dA0KaGF2ZSBOT1QgcmVhY2hlZCB0aGUg cGVlciBiMC4gKFRoZSBzZW5kZXIgd2luZG93IHNpemUgb2YgdGhlIGNsdXN0ZXIgaXMNCjUuKTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFjY29yZGluZyB0byBSRkMgNjMxMSwgPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQomcXVvdDtNMSBpcyB0aGUgbmV4dCBzZW5kZXIncyBNZXNz YWdlIElEIHRvIGJlIHVzZWQgYnkgdGhlIG1lbWJlci4gJm5ic3A7TTE8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KTVVTVCBiZSBjaG9zZW4gc28gdGhhdCBpdCBpcyBsYXJnZXIgdGhhbiBhbnkgdmFsdWUg a25vd24gdG8gaGF2ZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpiZWVuIHVzZWQuICZuYnNwO0l0IGlz IFJFQ09NTUVOREVEIHRvIGluY3JlbWVudCB0aGUga25vd24gdmFsdWUgYXQ8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KbGVhc3QgYnkgdGhlIHNpemUgb2YgdGhlIElLRSBzZW5kZXIgd2luZG93LiZxdW90 OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpNMSA9PSBhMVtUMl0ueSArIFNXID09 IDIwICsgNSA9PSAyNTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQooYTFbVDJdLnkgPT0gYTFbVDBdLnkg PT0gMjApPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQW5kIDxicj4NCiZxdW90O00yIE1VU1Qg YmUgYXQgbGVhc3QgdGhlIGhpZ2hlciBvZiB0aGUgcmVjZWl2ZWQgTTEsIGFuZCBvbmUgbW9yZTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQp0aGFuIHRoZSBoaWdoZXN0IHNlbmRlciB2YWx1ZSByZWNlaXZl ZCBmcm9tIHRoZSBjbHVzdGVyLiAmbmJzcDtUaGlzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCmluY2x1 ZGVzIGFueSBwcmV2aW91cyByZWNlaXZlZCBzeW5jaHJvbml6YXRpb24gbWVzc2FnZXMuJnF1b3Q7 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGJyPg0KTTIgPT0gbWF4e00xLCAxICsgYltUMl0ueCk9PSBtYXgoMjUsMSsyNCkgPT0gMjU8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQWZ0ZXIgdGhlIG5ldyBhY3RpdmUgbWVtYmVyIGExIHJl Y2VpdmVzIE0yLCBhMSBzZXRzIGExW1QyXS55ID09IDI1ICZsdDsNCmEwW1QyXS55ID09IDMwLjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoZSBNZXNzYWdlIElEIGZvciB0aGUgbmV3IGFjdGl2 ZSBtZW1iZXIgYTEgbnVtYmVycyBmcm9tIDI1LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpU aGUgZmlyc3QgZml2ZSBNZXNzYWdlIElEcyBhcmUgMjUsIDI2LCAyNywyOCwyOS48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KV2hlbiB0aGUgbmV3IGFjdGl2ZSBtZW1iZXIgYTEgc2VuZHMgcmVx dWVzdCBtZXNzYWdlcyB3aXRoIE1lc3NhZ2VzIElEcw0KMjUsIDI2LDI3LDI4LDI5LCBzaW5jZSB0 aGUgcGVlciBiIGhhcyBwcm9jZXNzZWQgdGhlIHJlcXVlc3QgbWVzc2FnZSB3aXRoDQp0aGUgc2Ft ZSBNZXNzYWdlIElEcywgdGhlIHBlZXIgYiB3aWxsIHJldHVybiByZXNwb25zZSBtZXNzYWdlcyBm b3IgdGhlDQpyZXF1ZXN0IG1lc3NhZ2VzIGZyb20gdGhlIG9sZCBhY3RpdmUgbWVtYmVyIGEwLjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpUaGVuIGExIHJlY2VpdmVzIGFjY2VwdGFibGUgYnV0 IG1pc21hY3RoZWQgcmVzcG9uc2UgbWVzc2FnZXMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQoyLiBDbGFyaWZpY2F0aW9ucyBmb3Ig dGhlIHNpbXVsdGFuZXNvdXMgZmFpbG92ZXIgY2FzZSBGIGluIFNlY3Rpb24gMi4zDQo8YnI+DQpG b3IgdGhlIHNpbXVsdGFuZW91cyBmYWlsb3ZlciwgY2FzZSBGIGlzIHRoZSBtb3N0IGRldmFzdGF0 aW5nIElNTy4gU28gSSdkDQpsaWtlIHRvIGNsYXJpZnkgaXQgZmlyc3QuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KMi4xIE5vdGF0aW9uIGZvciB0aGUgc2ltdWx0YW5lc291cyBmYWlsb3ZlciBjYXNlIEYg aW4gU2VjdGlvbiAyLjM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJy Pg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYTA6IHRoZSBv bGQgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGE8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KYTE6IHRoZSBuZXcgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGE8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KYjA6IHRoZSBvbGQgYWN0aXZlIGNsdXN0ZXIgbWVtYmVyIG9m IHRoZSBjbHVzdGVyIGI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KYjE6IHRoZSBuZXcgYWN0aXZlIGNs dXN0ZXIgbWVtYmVyIG9mIHRoZSBjbHVzdGVyIGI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ PGJyPg0KVDA6IEF0IHRoaXMgdGltZSBwb2ludCwgdGhlIGxhc3Qgc3luY2hyb25pemF0aW9uIGJl dHdlZW4gYTAvYjAgYW5kIGExL2IxDQppcyBjYXJyaWVkIG91dCwgPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpUMTogQXQgdGhpcyB0aW1lIHBvaW50LCB0aGUgc2ltdWx0YW5lb3VzIGZhaWxvdmVy IGV2ZW50IG9jY3VyczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpUMjogQXQgdGhpcyB0aW1l IHBvaW50LCB0aGUgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiBhMSBhbmQgYjEN CnN0YXJ0czwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClQzOiBBdCB0aGlzIHRpbWUg cG9pbnQsIHRoZSBNZXNzYWdlIElEIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGExIGFuZCBiMQ0K ZW5kczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCi0tLS1UMC0tLS0tLS0t VDEtLS0tLS0tLS0tVDItLS0tLS0tLS0tVDMtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxicj4NCjIuMiBBbmFseXNpcyBmb3IgdGhlIHNpbXVsdGFuZXNvdXMgZmFp bG92ZXIgY2FzZSBGIGluIFNlY3Rpb24gMi4zPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCkl0J3MgcG9zc2libGUgdGhhdCBmcm9tIFQwIHRvIFQxLCBhMCBhbmQgYjAgZGVsZXRlcyB0 aGUgb2xkIElLRSBTQSBzYTANCmFuZCBjcmVhdGVzIGEgbmV3IElLRSBTQSBzYTEuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+PGJyPg0KQnV0IGF0IFQyLCBhMSBhbmQgYjEgZG8gTk9UIGtub3cgd2hhdCBoYXMgaGFw cGVuZWQgZnJvbSBUMCBhbmQgVDEsIGFuZA0KZG8gTk9UIGtub3cgdGhlIGV4aXN0YW5jZSBvZiB0 aGUgbmV3IElLRSBTQSBzYTEsIGFuZCB1c2UgdGhlIG9sZCBJS0UgU0ENCnNhMCB0byBjYXJyeSBv dXQgTWVzc2FnZSBJRCBzeW5jaHJvbml6YXRpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoaXMg bWF5IGJyaW5nIHNvbWUgbW9yZSBzZXJpb3VzZSBwcm9ibGVtLiBTbyAmbmJzcDt3aGVuIHNpbXVs dGFuZW91cyBmYWlsb3Zlcg0Kb2NjdXJzLCBhIHNpbXBsZSB0d28td2F5IHN5bmNocm9uaXphdGlv biAmbmJzcDttYXkgbm90IGJlIGFuIGFwcHJvcHJpYXRlDQpzb2x1dGlvbi48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mcXVvdDtL YWx5YW5pIEdhcmlnaXBhdGkgKGthZ2FyaWdpKSZxdW90Ow0KJmx0OzwvYj48L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86a2FnYXJpZ2lAY2lzY28uY29tPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48Yj48dT5rYWdhcmlnaUBjaXNjby5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQq3orz+yMs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFs Ij46ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZyI+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1Pmlwc2VjLWJvdW5jZXNAaWV0 Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjIwMTItMDYtMTQgMTk6MTQ8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NiU+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTMlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1 b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLnJ1aXNoYW5AenRlLmNvbS5jbj48Zm9udCBz aXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+emhhbmcucnVpc2hhbkB6dGUuY29tLmNu PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDsNCiZsdDs8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86emhhbmcucnVpc2hhbkB6dGUuY29tLmNuPjxmb250IHNpemU9MSBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT56aGFuZy5ydWlzaGFuQHp0ZS5jb20uY248L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDssDQomcXVvdDs8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86aXBzZWNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i QXJpYWwiPjx1Pmlwc2VjQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9 IkFyaWFsIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86aXBzZWNAaWV0Zi5vcmc+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1Pmlwc2VjQGlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0iQXJpYWwiPlJlOiBbSVBzZWNdIFVwZGF0ZXMgdG8gdGhlIElLRXYyIEV4 dGVuc2lvbg0KZm9yIElLRXYyL0lQc2VjICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hpZ2gg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXZhaWxhYmxpdHk8L2ZvbnQ+PC90YWJsZT4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0 ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSGkgWmhhbmcsPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpU aGFua3MgZm9yIGdvaW5nIHRocm91Z2ggdGhlIFJGQyA2MzExIC48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48 YnI+DQpJIGhhdmUgZ29uZSB0aHJvdWdoIHlvdXIgJm5ic3A7cHJvcG9zZWQgZHJhZnQgYW5kIGZl bHQgdGhhdCB0aGVyZSBpcyBzb21lDQpjb25mdXNpb24gcmVnYXJkaW5nIHRoZSBtZXNzYWdlIGlk IGNvbmNlcHQgb2YgaWtldjIuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQog PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSSBoYXZlIHNlZW4gdGhh dCBpbiBzZWN0aW9uIDIuMyB5b3Ugd2VyZSBjb21wYXJpbmcgdGhlIGhpZ2VyIHNlbmRlciB2YWx1 ZQ0Kb2YgeDIgd2l0aCB5Mi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhh dCBpcyB3cm9uZy4gd2hlbiB4MiBwcm9wb3NlcyB0aGUgbmV4dCBoaWdoZXIgbWVzc2FnZSBpZCB0 byBiZSB1c2VkIHRvDQpzZW5kIGEgcmVxdWVzdCAsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPjxicj4NCnRoZW4gb24geTIgeW91IHNobGQgdGFsbHkgaXQgd2l0aCB0aGUgbmV4dCBoaWdo ZXIgbWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdA0KdG8gYmUgcmVjaWV2ZWQgPGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KGFuZCBub3Qgd2l0aCB0aGUgbmV4 dCBoaWdoZXINCm1lc3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgc2VudCk8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQppbiBpa2V2MiB0aGUgJm5ic3A7bWVzc2FnZSBpZCBvZiByZXF1ZXN0cyB0 byBiZSBzZW50IGFyZSBlbnRpcmVseSBkaWZmZXJlbnQNCmZyb20gbWVzc2FnZSBpZCBvZiByZXF1 ZXN0cyB0byBiZSByZWNlaXZlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N CnRoYXQgaXMgd2h5IFJGQyBzYXlzIGEgbWVzc2FnZSBpZCBpcyB1c2VkIGZvdXIgdGltZXMgb24g YSBnaXZlbiBkZXZpY2UuDQo8YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KMS4gbWVzc2FnZSBpZCBYIGlzIHVzZWQgd2hpbGUgc2VuZGluZyBhIHJlcXVlc3Q8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCjIuIG1lc3NhZ2UgaWQgWCBpcyB1 c2VkIHdoaWxlIHJlY2VpdmluZyB0aGUgcmVzcG9uc2U8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPjxicj4NCjMuIG1lc3NhZ2UgaWQgWCBpcyB1c2VkIHRvIHJlY2VpdmUgYSByZXF1ZXN0 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQo0LiBtZXNzYWdlIGlkIFggaXMg dXNlZCB0byBzZW5kIGEgcmVzcG9uc2UuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48 YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCnBsZWFzZSBmaW5kIHRoZSBjb21tZW50 cyBmb3IgZWFjaCBzZWN0aW9uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQog PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KU2VjdGlvbiAyLjE6ICZu YnNwO1RoaXMgaXMgYSBrbm93biBpc3N1ZSBhbmQgdGhhdCBpcyB3aHkgdXNpbmcgUkZDIDYzMTEs DQombmJzcDt3ZSBhcmUgc3luY2hyb25pc2luZyB0aGUgbWVzc2FnZSBpZCdzPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+PGJyPg0KU2VjdGlvbiAyLjI6IFRoZSBwZWVyIGlzIGFzc3VtZWQgdG8gYmUgcHJvcGVy IGFuY2hvciBwb2ludCB3aGljaCBoYXMgY29ycmVjdA0KaW5mbyBvZiBtZXNzYWdlIGlkIG9mIHJl cXVlc3RzIHNlbnQgYW5kIHJlY2lldmVkLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ PGJyPg0KZXZlbiB3aGVuIHBlZXIgaXMgY2x1c3RlciBtZW1iZXIgLCBhbW9uZyB0aGUgdHdvIGRl dmljZXMgb25lIG9mIHRoZW0gd291bGQNCmJlIGxlc3Mgd3JvbmcgYW5kIGhhdmUgaGlnaGVyIGFj Y3VyYXRlIHZhbHVlcyBvZiBtZXNzYWdlIGlkJ3MgLiA8YnI+DQpzbyB3ZSBwaWNrIHVwIHRoYXQg dmFsdWUuIEkgZG9udCBzZWUgYW55IGlzc3VlIGhlcmUuPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K U2VjdGlvbiAyLjM6IEZpcnN0IG9mIGFsbCB0aGVyZSBpcyBubyByZWxhdGlvbiBiZXR3ZWVuIE0x IGFuZCBQMS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCm9uIGEgZ2l2ZW4g ZGV2aWNlLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQotLS0gTTEgaXMgdGhl IHByb3Bvc2VkIG1lc3NhZ2UgaWQgb2YgdGhlIHJlcXVlc3QgdG8gYmUgc2VudDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KICZuYnNwOyAmbmJzcDtQMSBpcyB0aGUgcHJvcG9z ZWQgbWVzc2FnZSBpZCBvZiB0aGUgcmVxdWVzdCB0byBiZSByZWNlaXZlZC48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0 OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQp3aGVuIHNpbXVsYXRlbm91cyBmYWlsb3ZlciBoYXBwZW5zLCB4MiBtaWdodCBo YXZlIGhpZ2hlciB2YWx1ZSBvZiBNMSB3aGVuDQpjb21wYXJlZCB0byB5MiAsIGJ1dCB4MiBtaWdo dCBoYXZlIGxvd2VyIHZhbHVlIG9mIFAxIHdoZW4gY29tcGFyZWQgdG8geTIuPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJdCBkb2VzJ250IG1hdHRlci4gYm90aCBhcmUgaW5k ZXBlbmRlbnQuIHdoYXQgd2UgZXZlbnR1YWxseSBkbyBpcyBjb21wYXJlDQp0aGUgTTEgdmFsdWUg YWNyb3NzIHgyIGFuZCB5MiBhbmQgcGljayB0aGUgaGlnZXIgb25lLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0iQ2FsaWJyaSI+PGJyPg0Kc2FtZSBwcm9jZXNzIGlzIHJlcGVhdGVkIGZvciBQMS48L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj48YnI+DQpjYXNlIDEgdG8gNiBhcmUgYWxyZWFkeSBoYW5kbGVkIGJ5IGJh c2ljIGlrZXYyIFJGQyAuIGxpa2UgaWYgd2UgcmVjZWl2ZQ0Kc2FtZSBtZXNzYWdlIGlkIHR3aWNl ICwgdGhlbiB3ZSByZXRyYW5zbWl0IG9yIGRyb3AgaXQgaWYgaXQgaXMgb3V0c2lkZQ0KdGhlIHdp bmRvdy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQpTZWN0aW9uIDM6ICZuYnNwOyBkdXJpbmcgc2ltdWx0YW5lb3VzIGZhaWxv dmVyIGJvdGggdGhlIGNsdXN0ZXIgYW5kIHRoZQ0KcGVlciBtZW1iZXIgd291bGQgYmUgaW4gdW5y ZWxpYWJsZSBzdGF0ZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkJvdGgg b2YgdGhlbSBhcmUgd3JvbmcgLCBidXQgb25lIG9mIHRoZW0gaXMgbGVzcyB3cm9uZyAhISEgc28g d2Ugd2FudCB0bw0Kc3RhcnQgZnJvbSB0aGF0IHBvaW50IHRvIHN5bmNocm9uaXNlIHRoZSBtZXNz YWdlIGlkJ3MuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48 Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0Kc28gd2UgYXJlIGFsbG93aW5nIGJvdGgg dGhlIG1lbWJlcnMgdG8gYW5ub3VuY2UgdGhlaXIgbWVzc2FnZSBpZCdzIGFuZA0KdGhlbiBldmVu dHVhbGx5IHdlIHdvdWxkIHN5bmNocm9uaXNlIHRvIHRoZSBoaWdoZXIgbnVtYmVyLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSSBkb250IHNlZSBhbnkgZmxhdyBoZXJlLiBQ bGVhc2UgZXhwbGFpbiB3aXRoIGFuIGV4YW1wbGUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KQnkg eW91ciBwcm9wb3NhbCBpbiBjYXNlIG9mIHNpbXVsdGFuZW91cyBmYWlsb3ZlciwgYm90aCB0aGUg Y2x1c3RlciBhbmQNCnBlZXIgd2lsbCBiZSBpbiBVTlNZTkVEIHN0YXRlIGFuZCA8YnI+DQpib3Ro IHdvdWxkIGVuZCB1cCBzZW5kaW5nIGFuZCByZWplY3RpbmcgdGhlIHN5bmNocm9uaXNhdGlvbiBy ZXF1ZXN0LiA8YnI+DQpUaGlzIHdvdWxkIGxlYWQgdG8gcmVwZWF0ZWQgc3luY2hyb25pc2F0aW9u IGVmZm9ydHMgYW5kIHRoZSBwcm9ibGVtIG9mDQptZXNzYWdlIHN5bmNocm9uaXNhdGlvbiBpcyBu ZXZlciBzb2x2ZWQuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0Kc28gVU5TWU5FRCBzdGF0ZSBpcyBu b3QgcmVxdWlyZWQuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KU2VjdGlvbiA0OiA8YnI+DQogPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSSBmZWVsIHRoYXQgUkZDIDYz MTEgYWxyZWFkeSBzb2x2ZXMgdGhlIG1lc3NhZ2UgaWQgc3luY2hyb25pc2F0aW9uIGlzc3VlLg0K PGJyPg0KSSBkb250IHRoaW5rIHdlIG5lZWQgdG8gaW5jcmVtZW50IE0xIGJ5IGRvdWJsZSB0aGUg d2luZG93IHNpemUgYXMgcHJvcG9zZWQNCmJ5IHlvdS4gPGJyPg0KUGxlYXNlIHN1cHBvcnQgeW91 ciBwcm9wb3NhbCB3aXRoIGFuIGV4YW1wbGUgd2l0aCBtZXNzYWdlIGlkIHZhbHVlcyBvZg0KbnVt YmVycyBpbnN0ZWFkIG9mIHZhcmlhYmxlcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+ PGJyPg0KTGlrZSBNMSBpcyAzICwgTTIgaXMgNCBldGMgZXRjLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KTnVtYmVycyBtYWtlIGl0IG1vcmUgY2xlYXIuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpyZWdh cmRzLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQprYWx5YW5pPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48YnI+ DQpGcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3Jn Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pmlwc2VjLWJvdW5jZXNA aWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4NCjwvZm9u dD48YSBocmVmPSJtYWlsdG86W21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXSI+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5bbWFpbHRvOmlwc2VjLWJvdW5jZXNA aWV0Zi5vcmddPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+DQo8Yj5P biBCZWhhbGYgT2YgPC9iPjwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5ydWlzaGFuQHp0ZS5j b20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT56aGFuZy5ydWlz aGFuQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48 Yj48YnI+DQpTZW50OjwvYj4gTW9uZGF5LCBKdW5lIDExLCAyMDEyIDc6MzYgQU08Yj48YnI+DQpU bzo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzppcHNlY0BpZXRmLm9yZz48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pmlwc2VjQGlldGYub3JnPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFtJUHNlY10g VXBkYXRlcyB0byB0aGUgSUtFdjIgRXh0ZW5zaW9uIGZvciBJS0V2Mi9JUHNlYyBIaWdoDQpBdmFp bGFibGl0eTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQo8YnI+DQo8YnI+DQpEZWFyIEFsbCw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxi cj4NCiBJJ3ZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCAmcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij4NClVwZGF0ZXMgdG8gdGhlIElLRXYyIEV4dGVuc2lvbiBmb3Ig SUtFdjIvSVBzZWMgSGlnaCBBdmFpbGFibGl0eTwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPiZxdW90Oy4NClRoaXMgZHJhZnQgYW5hbHl6ZXMgc29tZSBpc3N1ZXMgaW4gUkZDIDYzMTEs IDxicj4NCmFuZCBwcm9wb3NlcyBzb21lIHVwZGF0ZXMuIExvb2sgZm9yd2FyZCB0byB5b3VyIGNv bW1lbnRzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkJSLDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KUnVpc2hhbiBaaGFuZzwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0 bzpJUHNlY0BpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT5JUHNlY0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBzZWM8L3U+PC9mb250PjwvYT4NCjxwPg0KPGhyPg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KSVBzZWMgbWFpbGluZyBsaXN0PGJyPg0KSVBzZWNAaWV0Zi5vcmc8YnI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPC9mb250Pjx0dD48Zm9udCBz aXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQpJUHNlY0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxwPg0K --=_alternative 0023ACFE48257A2A_=-- From yaronf.ietf@gmail.com Sat Jun 30 05:07:56 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD321F8446 for ; Sat, 30 Jun 2012 05:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZr2naTRFlfE for ; Sat, 30 Jun 2012 05:07:56 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC1B221F8476 for ; Sat, 30 Jun 2012 05:07:55 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2630973wgb.13 for ; Sat, 30 Jun 2012 05:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=sZObdCyGGVRWvQX2wWQdx3sW9XDa0MSJQ8rgzZh1yZI=; b=j8iSzS3ROAnKkQ2dfczkOD1M6ugAclZloX5FFwdR2FM4PzMh8NQuFXy0acLAZHIF9F tTHor09K0N++tFyQG5uRl8AdK0IHfvTWMVxIotncj4XpO9/PEIXIPiqLplrnCCkilurv k1ICmfIQB5mgfrtyRd1+Vct/4aqJuyRbFuLhM4I+rRtaxn+f1+jP7p6VIveSdTFu6rQE tblSpnpIGrCcKZOaTg0blxzF7eDeEGC3tYNymADw6+hTNcH8gb5TlyNSrxh4YACGumQe lrlIbpoprfgxCOCb777ci2MahMu7Mc0g7cm4B4Gz+9Z9/amd3Sz4AozuDoL0QJObTBOM ziGw== Received: by 10.216.74.198 with SMTP id x48mr2638215wed.46.1341058075338; Sat, 30 Jun 2012 05:07:55 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-181-179-177.red.bezeqint.net. [79.181.179.177]) by mx.google.com with ESMTPS id gb9sm11774114wib.8.2012.06.30.05.07.53 (version=SSLv3 cipher=OTHER); Sat, 30 Jun 2012 05:07:54 -0700 (PDT) Message-ID: <4FEEEC18.2030900@gmail.com> Date: Sat, 30 Jun 2012 15:07:52 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecME meeting - call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 12:07:56 -0000 Hi,

According to the draft agenda, the working group will be meeting in Vancouver on Tuesday afternoon. Please let Paul and I know if you would like a presentation slot. As usual, we expect any technical presentation to be based on an Internet draft.

Thanks,
    Yaron